feat: add logAttributionCapturedEvent option #295
Conversation
…vents when attribution data is captured
kelsonpw
force-pushed
the
GROWTH-1094
branch
from
3bcdc39 to
689e117
Compare
There was a problem hiding this comment.
Only 1 syntax suggestion. I think @haoliu-amp and @kelvin-lu have more to say application wise
src/amplitude-client.js
Outdated
| gclidProperties = this._saveGclid(this._getUrlParams()); | ||
| } | ||
| if (this.options.logAttributionCapturedEvent) { | ||
| const attributionProperties = Object.assign( |
There was a problem hiding this comment.
I believe you could make this more concise/readable by using the ... spread operator instead of Object.assign
const attributionProperties = { ... utmProperties, ... referrerProperties, ...gclidProperties }
kelsonpw
force-pushed
the
GROWTH-1094
branch
from
2393a2e to
fcf683c
Compare
src/constants.js
Outdated
| UTM_CONTENT: 'utm_content' | ||
| UTM_CONTENT: 'utm_content', | ||
|
|
||
| ATTRIBUTION_EVENT: 'attribution captured' |
There was a problem hiding this comment.
open to feedback on a better event name
There was a problem hiding this comment.
maybe DEBUG: attribution captured or $attributionCaptured so it's clearer to our customers that this is autogenerated by the SDK and/or
There was a problem hiding this comment.
Updated to $attributionCaptured
|
@kelsonpw The very first question. Is this something other users might want to use? Do we have any users requesting this? Usually we want to make |
@haoliu-amp We do not currently have any users asking for this, but according to Tanner it is very likely that others would like to use this in the future. I did however talk to @kelvin-lu about an alternative solution that will allow us to access the captured UTM's and send our own event without forcing the SDK to send events. Will have a PR for that in 5-10 mins. |
|
Closing in favor of PR #296 |
kelsonpw
changed the title
kelsonpw
changed the title
kelsonpw
force-pushed
the
GROWTH-1094
branch
2 times, most recently
from
37399e5 to
a9c7dc0
Compare
kelsonpw
force-pushed
the
GROWTH-1094
branch
2 times, most recently
from
7097a06 to
fa40657
Compare
kelsonpw
force-pushed
the
GROWTH-1094
branch
from
fa40657 to
d39a803
Compare
Description
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).
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.
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 signify that attribution actually changed (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. The only way for us to accurately fire this event is VIA the sdk.