When i send tracking in AMP page amp-analytic type=snowplow tag, there is way to send also the user id and session id?
i have problem how to determine which user send the events.For example if user click on button and then scroll down how should i know that it’s the same user (because right now when i send it i don’t have user_id or session_ud).
On more question i read that there is two type of events one pageview and one unstructEvent there isn’t one for ping i success to create event that work same as ping but it send the event also when the user not in the specific tab so there is option to create this ping event same as it work on none AMP page ?
I know Simo Ahava has written a couple of guides on how to access the GA cookie/Client ID in AMP pages, to help this issue within GA, but I’m not sure how possible it is to do something similar with the Snowplow tracker.
If it’s possible to provide any kind of bridge into the richer capabilities of the Snowplow JS Tracker from AMP (e.g. sessionization, automatic event types), then that would be super-interesting too - perhaps somebody with a good grasp of AMP’s internals could share their thoughts on the feasibility of this?
The clientId and sessionId needs some more magic. the values should come from the cookie clientId(sp_id_XXXX).
the hazzle is, we must split the string of the cookie value, to get the domain_uid and session_id.
But this is not so easy in amphtml. Maybe it’s possible to use the extension amp-bind which has some whitelisted String functions.
One more PR on amphtml where the ClientID scope is added named as
In this cases the value should be taken from this cookie.
But since there are cookie names like
it would be nice to make the cookiename configurable. this could be done in the amp-analytics code block as additional var.
Then we come to another issue, the cookie value is a concatenation of domain_uid,timestamps,session id … and there is no way to break it into single values on the amphtml side, maybe this could be done in the enrich/shredding process? what would be the best way?
you are right, this will not fetch the most of the origin domain_uids.
If i understand correct the first argument of CLIENT_ID() is the scope or namespace on the amphtml side, and the 3rd argument is the fallback cookie name, if the 3rd isn’t provided the first is used, described here:
I think it would be good to make the fallback cookie name configurable like:
but then the issue with the other metadata still exists.
For now we should be able to get the clientID of the amp-pages as duid. But there will be a lag between duid in amp pages and origin domain pages. For the configuration of the cookie name i can make a new PR, maybe someone creates an issue for that.
Would be also nice, if someone has some ideas how to proceed with the metadata issue.
Maybe projects with amphtml pages stores the domain_uid in an additional cookie without the other metadata.
I think the cookieName idea makes sense. I might use cookieNameWithHash because in the JS Tracker, cookieName just means "_sp_id". I would not try and retrieve the cookie if the cookieNameWithHash argument is not provided, as it’s impossible to predict the cookie name.
On the metadata issue - you cannot continue to use the duid field because what you are sending in is not a duid - it is just a cookie value. My gut feel is that this problem is bound to come again with another field, so it would be worth:
Defining an amp_context in Iglu Central that contains the cookie value as a field (and we can add other fields to this if other fields need post-processing)
Writing an AMP enrichment which works on the amp_context and post-processes its contents for Snowplow (e.g. extracting the duid from the amp_context.cookieValue)
Hey @alex@ecoron. As far I could see this issue has not been resolved so far. We tested the integration of the AMP tracker and found it breaks the pipeline due to invalid duids. (I guess AMP is returning the standard AMP client ids if the _sp_id cookie can not be found?)
However effectively hat means the AMP tracker is broken and unusable in my understanding. I can not find any open issue or fix related to this.
As the thread is about one year old I wonder if we are really the only ones ever attempted again to use SnowPlow for AMP tracking or if there is a fix/workaround I failed to find ?