search

mozilla / addons

☂ Umbrella repository for Mozilla Addons ✨
Other
125 stars 41 forks source link

Use UTM parameters instead of `?src=` #13787

Closed willdurand closed 4 years ago

willdurand commented 4 years ago

According to this PRD, we want to use UTM parameters instead of the unique src query parameter to track attribution:

AMO use of the src param should be replaced to use UTM instead. For instance, a homepage link should replace src=homepage-primary-hero with utm_source=addons.mozilla.org&utm_medium=referral&utm_content=homepage-primary-hero (the content param is the only one that would change depending on the circumstance).

We'll implement this feature behind a feature flag (enabled in local dev/-dev). This is going to touch many parts of the website so let's make sure we don't break anything. Installs should continue to work, navigation from search results/homepage to add-on detail pages should also work as before. In addition, we should have UTM parameters passed for each sub-page of an add-on detail page (cf. https://github.com/mozilla/addons/issues/13272)

For QA: in -dev only, we should see the src parameter anymore when clicking links in the pages like homepage, landing pages, search results, etc. All visible links should have UTM parameters as per the PRD. In short, we use utm_source=addons.mozilla.org&utm_medium=referral&utm_content=<src value> instead of src=<src value>.

It is also possible for users to use their own UTM parameters in URLs of add-on detail pages. See this page for more information: https://extensionworkshop-dev.allizom.org/documentation/manage/monitoring-extension-usage-statistics/#tracking-external-sources

When a user adds its own UTM parameters, we won't modify them so if there is only 1 UTM param for instance, we'll only set this UTM param to the links in the detail page (like we do for the src param on -prod).

In -dev, if we use src in the URL, we should not pass it to the other links and we should not have UTM params (src in the url of the xpi on the install button will be updated, though).

willdurand commented 4 years ago

@jvillalobos it looks like we pass src=dp-btn-primary to the install button link. This won't work anymore but I think it's fine, considering that we're not going to rely on src anymore or even the logs to infer the attribution data.

jvillalobos commented 4 years ago

Yeah, I think that's okay.

AlexandraMoga commented 4 years ago

@willdurand I hope I covered all the URLs that should contain utm parameters.

Here is a list:

If manually add a src=<value> parameter to a URL, that parameter is not passed to any subsequently opened URLs - this is also valid for the behavior added in mozilla/addons#13272

If the add-on contains custom utm parameters (the users can add one or more utm's) they are not overridden by AMO and the behavior added in mozilla/addons#13272 continues to work. An example: https://addons-dev.allizom.org/en-US/firefox/addon/web-page-annotator/?utm_source=utmTests&utm_medium=homepage&utm_content=dlc

(*) Not a new issue, just something we didn't notice before: In Extensions/Themes landing pages, we have the Top rated and the Trending shelves. If you click on an addons from either of those shelves, the utm_content param will be rating, respectively hotness, which is correct. If you click on the 'See more' links from either of the two shelves and then open an add-on detail page from the 'See more' results, the utm_content param will be set to featured in both instances. It will be more accurate if the utm_content param reflected the actual search filter, namely rating and hotness. I can address this issue in a follow up if it sounds valid to you also.

willdurand commented 4 years ago

I can address this issue in a follow up if it sounds valid to you also.

Yes, file a new issue for that please.

willdurand commented 4 years ago

Thanks!