Add new parameter for tracking entrypoint experiments

[davismtl]

Specific ask:
Add two parameters for tracking experiments on entrypoints and pass those parameters and their values to Amplitude as user properties.

Context and explanation
Currently, these are the various parameters that are passed to us and get used in Amplitude for understanding attribution and context of authentication funnels:
https://mozilla.github.io/application-services/docs/accounts/metrics.html

Up until now, we've asked relying parties and marketing to use utm parameters to specify variations or experiments they want to track.

There's a problem with that. utm parameters are mostly supposed to indicate how a user got to an entrypoint and if they are actually used and passed to us, it prevents the entrypoint from passing us an experiment name and variation.

Ideally, they would not be creating lots of entrypoint names for this or it will make a mess of our metrics.

Specific example:

• The mozilla.org team owns this page: https://www.mozilla.org/en-US/firefox/accounts/
• The email and snippet teams drive traffic to it. Those teams are really good at including all of their utm parameters to the page.
• Mozilla.org will forward those parameters to us so email and snippets can measure the impact of their efforts.
• Mozilla.org wants to run experiments and optimize that page. They have no means to pass us that information without either polluting our entrypoints or overwriting utm parameters.
• After two months of going back and forth, we can't figure out a workaround.

Proposed parameters
In order to make it clear that these experiments are specific to the entrypoint, I propose something like:

• entrypoint_experiment OR entrypoint_exp
• entrypoint_variation OR entrypoint_var*

CC @irrationalagent @hoosteeno

[juliemccracken]

Need Alex's input on this for actual name and priority. Amplitude export scripts will need updated.

[philbooth]

Fwiw the import script won't need to change, just the common lib code in fxa-shared.

@davismtl, do you want these to be user properties or event properties?

[davismtl]

I think user properties would make more sense, similarly to the utm params.

[hoosteeno]

We have code ready to send this data from www, and need 2 things before we can land it.

1. A decision on the parameter names. I think code verbosity is helpful, so I prefer entrypoint_experiment and entrypoint_variation.
2. We need to know if landing these parameters before the FxA work is done will break anything. Can we send parameters to Amplitude that Amplitude doesn't handle, without breaking metrics?

[shane-tomlinson]

This is in train-136 but nobody is assigned to it. Will it really get done?

[shane-tomlinson]

This is in train-136 but nobody is assigned to it. Will it really get done?

Oh, scratch that, @philbooth is on it.

[philbooth]

@hoosteeno:

A decision on the parameter names. I think code verbosity is helpful, so I prefer entrypoint_experiment and entrypoint_variation.

Agreed, let's go with those names.

We need to know if landing these parameters before the FxA work is done will break anything. Can we send parameters to Amplitude that Amplitude doesn't handle, without breaking metrics?

I only have the FxA half of the context here, so I'm not sure I fully understand the concern. But fwiw I'm not aware of any way in which you can break metrics by including these parameters before we've done our part. We'll just ignore them in the query string until we're ready to pull them out, and if you're sending them directly to Amplitude some other way that's fine too, as long as they're in the user_properties object (which is where we'll be putting them).

[davismtl]

@philbooth they'd be passing it to us as a Get param when directing to account.firefox.com