I read this discussion that ended around 2018 regarding updates for linking the Snowplow DUID to Google Amp components, have there been any further analysis or updates on this?
Currently I am following this to try out linking DUID’s that are currently in production to an AMP component that emits events to our enricher. The events seem to be emitting fine but the DUID’s appear to come up blank in Redshift. Thank you!
Assuming that you’re using the v2 Snowplow extension for AMP, then using the cross-domain linker will pass the domain_userid to the AMP tracker, but this will not populate the domain_userid field in the events table. Rather it will attach an amp_id context to the event, which contains the AMP client ID, the domain_userid it has been passed (if present), and the user_id (if present).
The domain_userid is not guaranteed to be present for all events for the user, but rather provides a way to map the domain_userid to the AMP client ID, which is the permanent identifier for users on the AMP platform. So the strategy for attaching domain_userid to users on AMP is to build a mapping table at data modeling stage, and join on AMP client ID.
Could you check that you’re using the v2 version of the extension, and then check whether the domain_userid is attached to events via the amp_id context?
PS - the release post for that update has taken a while to come (quite a lot of features to write up), and is in review, so should be up soon. Apologies for the fact that this information wasn’t clear sooner.
That’s curious - could you provide the full page_url for one of the events in question (the first AMP page view after moving across from a normal site, with the cross-domain linker set).
Additionally, if any of the pages in question are live, it’d be useful if I were able to take a look.
I’d like to figure out if this is to do with how we parse the querystring on AMP, how the cross-domain linker behaves, or something else.
First up, I forgot to mention the other way of attributing users. Passing the domain_userid into AMP via the cross-domain linker covers users moving from a normal website to AMP. The other way around is slightly different - the url is decorated with the AMP client ID using the AMP linker - this can then be parsed at datamodeling stage and added to a mapping table.
Ideally we’ll instrument tooling to parse it out in the JS tracker or enrich, but for now it’s manual.
Secondly, it’s been brought to my attention that the JS tracker’s cross-domain linker doesn’t always reliably work with GTM, because of how GTM allows/disallows certain methods of link decoration. It might well be the case that this is true for the AMP platform too. We’re looking into that issue, but there’s a chance this is what you’ve run into.
1 question- do people have to transition directly from a page that had a JS tracker to an amp page for the DUID handoff? Or can the DUID be floating around in the client and get picked up by the AMP tracker?
Direct transition from non-AMP to AMP is needed. To replicate the “floating” behaviour you need to save JS generated DUID into _sp_duid cookie (right now JavaScript tracker doesn’t support this cookie out of the box).
However due to how AMP works depending where the page is served from (i.e. your AMP server, Google’s AMP server or AMP Project server) your page might not have access to that cookie. Cookie will only be available if page is served from your server.
Jumping on to this as well.
What about connecting the session_id of the AMP analytics component and the main site?
More simply, how do connect a user session across from AMP to your site?
I understand that linker is used to identify the user, but how do you identify the session?
Products like Google Analytics and Adobe Analytics don’t maintain cookie with session ID and since AMP is something that was thought of by Google they applied the same logic there (which not necessarily works with Snowplow). Since session maintained in a cookie in Snowplow you have the same issue with maintaining it as with domain user id. The best solution here is to have linker on links to your site from AMP pages and then apply modelling logic based on AMP ID (backfilling session ID, domain user id and session number).
Thanks for jumping in @mbondarenko! I got quite busy, glad to see you were on hand to answer.
@jbdoster the advice you were given is sound, if you set the _sp_duid cookie yourself that’s as close as you can get to floating domain_userid - but cookies are unreliable on AMP, which is why the primary recommended AMP strategy for user identification is to map across the available ids, with an ‘at least once mapped’ assumption. It’s quite awkward but it’s what the platform gives us.
@Yoav_Ganbar - again, you’ve got a correct steer - I’ll just add the context that in the recent releases we decided not to try to solve the sessionisation problem, primarily because there have been a lot of other important problems to solve around tracking on AMP (the latest version of the tracker is still quite new). Passing session id across would require a change to the javascript tracker as well as the AMP tracker, so the call we made was that it’s better to release something functional than to block a release pending a solution to this one.
So this feature isn’t not out of the question, it’s just one that still needs some ironing out.
If you’re keen to get something in place that passes the session id to AMP, it is possible to instrument some JS which retrieves the session id using the JS tracker’s getDomainUserInfocallback method, then pass that in the querystring to AMP, and parse it on your AMP page to pass into a custom context. Also, there’s an AMP issue to allow session ids on AMP itself, which is something I’m keen to see happen - so giving that a thumbs up can’t do any harm if you’re interested in it. (it seems there is intent to do it, at least!)
