Bugzilla

We're in the process of integrating Nimbus into many more of our applications, following the new Nimbus on the Web architecture, which relies on server-side integration and a request to Cirrus [1]. This request carries a unique ID and targeting context, and returns a set of active features.

This unique ID cannot be Glean's client_id, because it is not currently exposed to consuming applications. It is also not desirable to expose Glean's client_id due to data integrity concerns, and to prevent accidental misuse.

Applications therefore need to generate or derive a new unique ID used for experimentation/enrolment, or rely on an existing one such as the Firefox Account ID. Defining this ID in our applications is desired anyway as it allows for more advanced use cases e.g., running a single experiment across multiple applications. 

However, this prompts the requirement that this new ID is included in all recorded Glean events. Otherwise, partitioning of data (or experiment analysis more generally) becomes impossible. In our Firefox clients, which rely on client-side Nimbus integration, the Nimbus SDK calls `Glean.setExperimentActive` to achieve this connection. However, in this new integration scenario the clients are unaware of experiment slugs.

In our discussions, we concluded that adding some minimal new API surface to the Glean SDK would be ideal on the client. If we left it up to each individual client development team to "manually" add this ID to all existing and future events, we would very likely end up with diverging names and implementation gaps, which will have a negative impact on data quality and therefore experimentation and analysis.

The API discussed so far was a simple call e.g., `glean.set_experiment_id(id)` to be used on the client.

We will have a follow-up discussion to verify if we need server-side API, but all felt that divergence is less of a concern there (e.g., it's much easier to fix and roll out changes), and that it can be addressed independently at a later point. NB: Since server-side logic for recording events will likely run as part of a user session we can't just rely on a simple "global" call to `glean.set_experiment_id`. The client-side solution seems simple enough to address our biggest concerns, and we will discuss and file a follow-up enhancement for the server, if needed.

[1] https://github.com/mozilla/experimenter/tree/main/cirrus#cirrus-server-to-get-feature-configuration-api-structure

We're in the process of integrating Nimbus into many more of our applications, following the new Nimbus on the Web architecture, which relies on server-side integration and a request to Cirrus [1]. This request carries a unique ID and targeting context, and returns a set of active features.

This unique ID cannot be Glean's client_id, because it is not currently exposed to consuming applications. It is also not desirable to expose Glean's client_id due to data integrity concerns, and to prevent accidental misuse.

Applications therefore need to generate or derive a new unique ID used for experimentation/enrolment, or rely on an existing one such as the Firefox Account ID. Defining this ID in our applications is desired anyway as it allows for more advanced use cases e.g., running a single experiment across multiple applications. 

However, this prompts the requirement that this new ID is included in all recorded Glean events. Otherwise, partitioning of data (or experiment analysis more generally) becomes impossible. In our Firefox clients, which rely on client-side Nimbus integration, the Nimbus SDK calls `Glean.setExperimentActive` to achieve this connection. However, in this new integration scenario the clients are unaware of experiment slugs.

In our discussions, we concluded that adding some minimal new API surface to the Glean SDK would be ideal on the client. If we left it up to each individual client development team to "manually" add this ID to all existing and future events, we would very likely end up with diverging names and implementation gaps, which will have a negative impact on data quality and therefore experimentation and analysis.

The API discussed so far was a simple call e.g., `glean.set_experimentation_id(id)` to be used on the client.

We will have a follow-up discussion to verify if we need server-side API, but all felt that divergence is less of a concern there (e.g., it's much easier to fix and roll out changes), and that it can be addressed independently at a later point. NB: Since server-side logic for recording events will likely run as part of a user session we can't just rely on a simple "global" call to `glean.set_experiment_id`. The client-side solution seems simple enough to address our biggest concerns, and we will discuss and file a follow-up enhancement for the server, if needed.

[1] https://github.com/mozilla/experimenter/tree/main/cirrus#cirrus-server-to-get-feature-configuration-api-structure

We're in the process of integrating Nimbus into many more of our applications, following the new Nimbus on the Web architecture, which relies on server-side integration and a request to Cirrus [1]. This request carries a unique ID and targeting context, and returns a set of active features.

This unique ID cannot be Glean's client_id, because it is not currently exposed to consuming applications. It is also not desirable to expose Glean's client_id due to data integrity concerns, and to prevent accidental misuse.

Applications therefore need to generate or derive a new unique ID used for experimentation/enrolment, or rely on an existing one such as the Firefox Account ID. Defining this ID in our applications is desired anyway as it allows for more advanced use cases e.g., running a single experiment across multiple applications. 

However, this prompts the requirement to include this new ID in all recorded Glean events. Otherwise, partitioning of data (or experiment analysis more generally) becomes impossible. In our Firefox clients, which rely on client-side Nimbus integration, the Nimbus SDK calls `Glean.setExperimentActive` to achieve this connection. However, in this new integration scenario the clients are unaware of experiment slugs.

In our discussions, we concluded that adding some minimal new API surface to the Glean SDK would be ideal on the client. If we left it up to each individual client development team to "manually" add this ID to all existing and future events, we would very likely end up with diverging names and implementation gaps, which will have a negative impact on data quality and therefore experimentation and analysis.

The API discussed so far was a simple call e.g., `glean.set_experimentation_id(id)` to be used on the client.

We will have a follow-up discussion to verify if we need server-side API, but all felt that divergence is less of a concern there (e.g., it's much easier to fix and roll out changes), and that it can be addressed independently at a later point. NB: Since server-side logic for recording events will likely run as part of a user session we can't just rely on a simple "global" call to `glean.set_experiment_id`. The client-side solution seems simple enough to address our biggest concerns, and we will discuss and file a follow-up enhancement for the server, if needed.

[1] https://github.com/mozilla/experimenter/tree/main/cirrus#cirrus-server-to-get-feature-configuration-api-structure

We're in the process of integrating Nimbus into many more of our applications, following the new Nimbus on the Web architecture, which relies on server-side integration and a request to Cirrus [1]. This request carries a unique ID and targeting context, and returns a set of active features.

This unique ID cannot be Glean's client_id, because it is not currently exposed to consuming applications. It is also not desirable to expose Glean's client_id due to data integrity concerns, and to prevent accidental misuse.

Applications therefore need to generate or derive a new unique ID used for experimentation/enrolment, or rely on an existing one such as the Firefox Account ID. Defining this ID in our applications is desired anyway as it allows for more advanced use cases e.g., running a single experiment across multiple applications. 

This then prompts the requirement to include this new ID in all recorded Glean events. Otherwise, partitioning of data (or experiment analysis more generally) becomes impossible. In our Firefox clients, which rely on client-side Nimbus integration, the Nimbus SDK calls `Glean.setExperimentActive` to achieve this connection. However, in this new integration scenario the clients are unaware of experiment slugs.

In our discussions, we concluded that adding some minimal new API surface to the Glean SDK would be ideal on the client. If we left it up to each individual client development team to "manually" add this ID to all existing and future events, we would very likely end up with diverging names and implementation gaps, which will have a negative impact on data quality and therefore experimentation and analysis.

The API discussed so far was a simple call e.g., `glean.set_experimentation_id(id)` to be used on the client.

We will have a follow-up discussion to verify if we need server-side API, but all felt that divergence is less of a concern there (e.g., it's much easier to fix and roll out changes), and that it can be addressed independently at a later point. NB: Since server-side logic for recording events will likely run as part of a user session we can't just rely on a simple "global" call to `glean.set_experiment_id`. The client-side solution seems simple enough to address our biggest concerns, and we will discuss and file a follow-up enhancement for the server, if needed.

[1] https://github.com/mozilla/experimenter/tree/main/cirrus#cirrus-server-to-get-feature-configuration-api-structure

We're in the process of integrating Nimbus into many more of our applications, following the new Nimbus on the Web architecture, which relies on server-side integration and a [request to Cirrus](https://github.com/mozilla/experimenter/tree/636b828f17d78185858348808a38c1b21145a9a8/cirrus#cirrus-server-to-get-feature-configuration-api-structure). This request carries a unique ID and targeting context, and returns a set of active features.

This unique ID cannot be Glean's client_id, because it is not currently exposed to consuming applications. It is also not desirable to expose Glean's client_id due to data integrity concerns, and to prevent accidental misuse.

Applications therefore need to generate or derive a new unique ID used for experimentation/enrolment, or rely on an existing one such as the Firefox Account ID. Defining this ID in our applications is desired anyway as it allows for more advanced use cases e.g., running a single experiment across multiple applications. 

This then prompts the requirement to include this new ID in all recorded Glean events. Otherwise, partitioning of data (or experiment analysis more generally) becomes impossible. In our Firefox clients, which rely on client-side Nimbus integration, the Nimbus SDK calls `Glean.setExperimentActive` to achieve this connection. However, in this new integration scenario the clients are unaware of experiment slugs.

In our discussions, we concluded that adding some minimal new API surface to the Glean SDK would be ideal on the client. If we left it up to each individual client development team to "manually" add this ID to all existing and future events, we would very likely end up with diverging names and implementation gaps, which will have a negative impact on data quality and therefore experimentation and analysis.

The API discussed so far was a simple call e.g., `glean.set_experimentation_id(id)` to be used on the client.

We will have a follow-up discussion to verify if we need server-side API, but all felt that divergence is less of a concern there (e.g., it's much easier to fix and roll out changes), and that it can be addressed independently at a later point. NB: Since server-side logic for recording events will likely run in the context of a user session, we can't rely on a "global" call to `glean.set_experiment_id`. The client-side solution seems simple enough to address our biggest concerns, and we will discuss and file a follow-up enhancement for the server, if needed.

We're in the process of integrating Nimbus into many more of our applications, following the new Nimbus on the Web architecture, which relies on server-side integration and a [request to Cirrus](https://github.com/mozilla/experimenter/tree/636b828f17d78185858348808a38c1b21145a9a8/cirrus#cirrus-server-to-get-feature-configuration-api-structure). This request carries a unique ID and targeting context, and returns a set of active features. The unique ID cannot be Glean's client_id, because it is not currently exposed to consuming applications. It is also not desirable to expose Glean's client_id due to data integrity concerns, and to prevent accidental misuse.

Applications therefore need to generate (or derive) a new unique ID used for experimentation/enrolment, or rely on an existing one such as the Firefox Account ID. Defining this ID in our applications is desired anyway as it allows for more advanced use cases such as running a single experiment across multiple applications. 

This then prompts the requirement to include the new experimentation ID in all recorded Glean events. Otherwise, partitioning of data (or experiment analysis more generally) becomes impossible. In our Firefox clients, which rely on client-side Nimbus integration, the Nimbus SDK calls `Glean.setExperimentActive(experiment)` to achieve this connection. However, in this new integration scenario the clients are unaware of experiment details.

In our discussions, we concluded that adding some minimal new API surface to the Glean SDK would be ideal. If we left it up to each individual client development team to "manually" add this ID to all existing and future events, we would very likely end up with diverging names and implementation gaps, which would negatively impact data quality and therefore impede experimentation and analysis.

The API discussed so far was a simple call e.g., `glean.set_experimentation_id(id)` to be used on the client.

We will have a follow-up discussion to verify if we need server-side API, but felt that divergence is less of a concern there e.g., it's much easier to fix and roll out changes. NB: Since server-side logic for recording events will likely run in the context of a user session, we can't rely on a "global" call to `glean.set_experiment_id`. The client-side solution seems simple enough to address our biggest concerns, and we will discuss and file a follow-up enhancement for the server, if needed.