Description

This PR introduces a refactor to _trackParamsAndReferrer. It seperates the collecting of raw attribution values (utm, gclid, referrer) into pure functions, and then adds a new function _collectParamsAndReferrer that is almost identical to _trackParamsAndReferrer but just avoids making an additional identify call. credit to @kelvin-lu for helping think of this.

Here is how I would use this in the product/corpsite:

    amplitude.getInstance().onInit((client) => {
      const isNewSession = client.isNewSession();
      if (isNewSession) {
        const attributionProperties = client._collectParamsAndReferrer();
        client.logEvent('attribution captured', attributionProperties);
      }
    });

This is related to a recent Growth Eng effort to audit and optimize our UTM tracking and attribution. We would like a way to log an Amplitude event whenever attribution data is captured (utm, referrer, gclid). This is to compare our Amplitude SDK attribution with our alternative UTMz tracking setup on the corpsite & blog (already added a similar event here: https://github.com/amplitude/amplitude.com/pull/133). The SDK does not need to be the one logging the event, we just need access to the data.

Jira Ticket

Why we need this

We want to be able to get a full picture of every UTM/attribution state that a user has had during their Journey with Amplitude. Because Identify calls are not queryable, we are unable to devise a query that returns the information we are looking for. Also, because attribution consists of many properties (utm_source, utm_medium, utm_campaign, etc.), not all of them will have values. We do not require the SDK to send the event, we just need access to the data.

Updated Context:

I met with @kelvin-lu last week to discuss this PR. He suggested that it might be possibly to query using pre-existing events such as pageview. I spent sometime investigating this approach and determined that it is not viable. Even though pageview events have the attribution state present in user properties, they do not signal that attribution was actually captured at that exact point (which is what we are looking for). Another idea I discussed with Kelvin was the ability to query identify events, but after speaking with Tanner, this approach has been explored and is impossible.

New solution

I proposed a solution in PR #295, but it is not ideal. Until we fully determine that other users might like the auto attribution logging behavior, I believe this solution is a better alternative in the meantime. cc @haoliu-amp