Amphtml: CID API: sessions begun in viewer not stitching in GA

[daauerbach]

What's the issue?

The value of 'cid' in an AMP viewer pageview collect differs from that in the subsequent click-link-to-canonical pageview collect.

How do we reproduce the issue?

With the CID API enabled (and not showing errors in GA debugger), inspecting the collect beacons shows a different cid is being passed when a user clicks onward from an AMP page in the viewer. Rather than a single "stitched" organic session (with data source "AMP"), this shows in Analytics reports as distinct & duplicate referral sessions (or, as "direct" sessions if a referral exclusion is set for ampproject.org). This behavior occurs for both new users and those returning with established "amp-...." or canonical cid values. But these values are correctly maintained in back and forth traffic between non-viewer AMP and canonical.

If this is intended, it's unclear from current documentation how it reconciles with the expected behavior as illustrated here

On a simple test site we reproduce this by navigating to the AMP viewer and onward, preserving the network log, filtering for "collect", and comparing the query string parameter values.

AMP version:
http://amp.ampcid.wompmobile.com/amp.html

HTML Version:
http://ampcid.wompmobile.com/test.html

And viewer preview

(As well as cache version)

Viewer start

Followed by canonical

And how it looks in GA after a few rounds of testing

Maybe related somehow #11060 #11888 #12716 ?

Clarification welcome on why this is not an issue...

What browsers are affected?

Testing has been on Chrome

Which AMP version is affected?

1515614886756

[aghassemi]

/to @lannka
/cc @rudygalfi

[lannka]

@daauerbach thanks for reporting.

Cache page does emit right CID.
However, canonical page got an empty response {} for its call to
https://ampcid.google.com/v1/publisher:getClientId

@Gregable can you take a look?

[Gregable]

@daauerbach , I believe this is an instance of https://github.com/ampproject/amphtml/pull/12716 which should be resolved soon. This should not happen if the AMP and non-AMP (canonical) origins are the same. In your case, one is prefixed by amp.

[lannka]

@Gregable is right.

@daauerbach please wait for the next AMP release and check back

[daauerbach]

okay, thanks @lannka @Gregable, we'll continue to monitor

[daauerbach]

@Gregable, after looking at the code changes, we're still hoping to pin down exactly what you mean regarding #12716 and the CID API more generally. Can you clarify/confirm what's expected for an amp property
https://amp.example.com
set up with amp-analytics reporting to the UA for the canonical
https://example.com
when a user goes from the viewer to the linked canonical?

After the recent changes, should we expect the CID to report these two pageviews as one session on the https://example.com property?

Or will there be a different expected behavior because the amp page is hosted at https://amp.example.com?

thanks

[rudygalfi]

@daauerbach There's a current known issue for the scenario of an AMP page being on a different origin than the non-AMP canonical. After these changes, we expect to report these pageviews as one session. Note that this won't be true for all (AMP origin, canonical origin) pairs, but when the AMP origin matches the canonical origin except it has amp. in front of it, then it will work.

[daauerbach]

@rudygalfi Thanks, that's helpful confirmation. We're looking forward to seeing how things look after 1515617716922 becomes the active release.

[daauerbach]

@lannka @Gregable @rudygalfi It looks like pages with the most recent release (1516337355291) still send different _cid_ values in pageview beacons after the viewer (i.e., the same behavior as OP). And the sessions do not appear to be stitched in GA. We see this for the simplified testing site as well as production sites with the cdn.ampproject.org referral exclusion. FWIW, the "viewer:getClientId" and "publisher:getClientId" POSTs are both 200, so the connection to ampcid.google.com seems to be working...

Any further suggestions and can you clarify what the "On Deck for Next Sprint" status implies for this? Thanks!

[Gregable]

@daauerbach Can you try this again today. I'm not sure if the matching search viewer changes were in place when you tried this on Friday. My testing today, using your excellent test cases, shows that the same CID is being sent to GA on both sides, starting w/ a clean incognito window. I want to confirm that you see the same.

[daauerbach]

@Gregable Yes! Looks like you were correct that things hadn't gotten into place.

For the tester, I'm now seeing both 1) the same _cid_ value throughout a session, including in direct jumps to the non-viewer AMP url, and 2) correctly stitched sessions in GA with appropriate behavior metrics.

And in production, it looks like a correctly configured referral exclusion is now producing full "google/organic, amp" sessions instead of generating "direct/none, web" ones.

Thanks and kudos. Let me know if I should close this or if you'd prefer to.

[rudygalfi]

Thanks for confirming @daauerbach! I'll close this out.