AMP Pages not picking up _sp query parameters

1

Hello,

Wondering if anyone has run into this issue - hoping for some guidance.

I am navigating from my main page to an AMP page on the for eg. “www-website-name-com.cdn.ampproject.org”, and the destination url is being decorated with “?_sp=…” query parameter. I have noticed that the amp pages are not using the “_sp=…” value and are leaving both domainUserId and userId blank.

I can confirm amp pages are properly set up with snowplow analytics and have been sending data for a while now. I confirm events from the amp hits such as pageviews and page_pings. The version running the AMP tracker is the latest. 1.0.1

The values that I am not seeing being populated are.
1- domainUserid
2-userId

ampClientId is being created.

Thanks in advance!

2

What configuration do you currently have setup for the AMP / cross-domain linking?

3

Settings on the AMP pages:

            "linkers": {
            "enabled": true,
            "proxyOnly": false,
            "destinationDomains": [
            "domain1",
            "domain2"
            ]
            },
4

Just to cover off the possible gotchas:

  • can you confirm that you’re looking for the values in the amp_id context, rather than the domain_userid field of atomic.events?

  • Can you also confirm that the javascript tracker’s cross-domain linker is enabled, and that the _sp= parameter is in the url of the page you’re landing on?

  • Does your destinationDomains list include the cdn.ampproject.org domain also (It’s a long while since I’ve looked at AMP so I’m not 100% sure if this is likely to be the issue)

Also, just to explain - the domainUserId value should come through when the JS tracker passes it via the cross-domain linker, but the user_id field on AMP is only populated when set in as a var in the amp tracking config. It might be worthwhile for us to look at changes to this behaviour, but for the moment those are the confines we work within.

So, I would narrow it down to investigating the domainUserId.

5

Thanks Colm,

  • Yes, I am seeing the amp_id context and both domainUserId and userId are blank.

  • Yes the _sp= parameter is in the browser. generated by the cross-domain linker in the javascript tracker.

  • Do you mean destinationDomains on the AMP tracker and page must include “cdn.ampproject.org”? my understanding is that’s going from AMP page to another page (domain or other amp). “cdn.ampproject.org” is added in the linked domains on the Javascript tracker only. from

And yes, that’s good advice. Getting domainUserId working is our goal for now.

6

Apologies for the delay coming back to you on this one.

Do you mean destinationDomains on the AMP tracker and page must include “cdn.ampproject.org”?

The honest answer is I’m not sure exactly where I was going with this - I was trying to narrow down the possibilities and figured that some configuration of the linker might be at root. But having reflected on that, this is not a good line to pursue, the value is in the querystring already. Apologies for the wild goose chase on that one.

I have since reaquainted myself with the project (like I mentioned it’s been a while so I’m rusty on AMP), and I have a hunch what might be going wrong here - the logic in there currently is to first write the value to a cookie, then try to read the cookie and send. If for some reason writing to the cookie isn’t allowed on the amp domain (eg secure cookie settings, or pre-existing cookie conflicts), then I think we miss the value when we try to send it.

I think we have a further problem with this since the order of operations isn’t necessarily deterministic.

There are two things that might help me confirm/deny this thinking:

Could you send across the exact value of the _sp parameter in the url?

Could you tell me if an _sp_duid cookie is being set in the browser, and if so what’s the value?

Ps. it would also be helpful to take a look at the actual page in question - since you’ve redacted domains in your message I understand you might not want to share.

If you’re able to send a link in a private message, that’d be helpful. If not, absolutely no worries :slight_smile:

7

@Yazan a quick update. I’ve now been able to reproduce the issue and have created this issue on our fork’s issue tracker. We’ve identified the fix and have bumped this into the current sprint. I’m optimistic we can test the fix and get a PR open early next week.

Once merged into the AMP project there is a slight lag before changes get deployed to production, while they go through the AMP release process. If you volunteer with them to participate in dev releases, you get it a week earlier.

However, once they’ve gone to production, changes will take effect without any action on your part.

Apologies for the inconvenience, and thank you for reporting this behaviour. :slight_smile:

1 Like
8

Thanks a lot @Colm . This is great news, I’ll keep an eye out on the issue!
All the best

9

Quick update on this - the PR for the AMP project which fixes the issue has been merged: https://github.com/ampproject/amphtml/pull/32636

However, since Wednesday’s AMP release had to be rolled back for a bugfix, they haven’t yet created the release tracker for next week’s one (which I expect to contain our changes).

I’ve asked them for clarity on this, but for the moment I’m assuming that it’ll get released the following week, rather than this Wednesday coming (but I could be wrong!).