Since AMP pages accessed by search are found in the CDN hosted by Google (this is called “AMP on cache”), they are initially on a Google.com domain. But as the user does more with the publisher site (which I’ll refer to here as “clientsitedomain.com”, they leave the Google cache, and end up in pages on the clientsitedomain.com domain.
This causes a problem as the person arriving at the publisher’s domain is seen as an external referral from the Google CDN, instead of it being seen as a continuation of the same visit. The following graphic illustrates the issue:
The result is a broken analytics implementation that results in the following issues:
- When you add the AMP on cache sessions to the sessions on your main domain, your total session count will be too high. That’s because you’ll be double-counting the AMP on cache visitors that click through to the main site, once as a new AMP on cache session, and once as a new session in the main site analytics.
- The Bounce Rate shown in the AMP on cache analytics will be too high.
- The Pages Per Session shown in the AMP on cache analytics will be too low.
- The Average Session Time shown in the AMP on cache analytics will be too low.
This problem alone caused many publishers to abandon AMP. Accurate analytics is really important in digital marketing! But, Google has since worked through a fix for this. The conceptual solution to this is being referred to many as “session stitching”, and the basic idea is to pass a Client ID from the AMP on cache analytics to your main site analytics so that the visit can be recognized as one single session:
This fix was announced by Google on September 5, 2017. The fix uses the new AMP Client ID API to pass the Client ID information. To implement the fix, you follow these steps (partially taken from Google’s support page):
1. Place this tag in the section of your AMP page:
Do not place this tag on the non-AMP pages on your site.
2. On your non-AMP pages, add the following into the rest of your Google Analytics script, just prior to the tag:
If you’re using Google Tag Manager, do it this way:
- Navigate to Tag Configuration > Fields to Set
- Set useAmpClientId to true
- Save the new tag configuration
- Submit the tag
- Publish the container
Here is how it looks in the UI:
Session Stitching, the Advanced Class
The above outline to address session stitching should allow you to capture all of your users, but it does leave some issues. What it’s doing is taking data from two different sources and tying them together with a Client ID. At this point, you’ll be able to see what’s coming through AMP pages vs. regular pages. There are still some shortcomings:
- You can’t see the difference between your own hosted AMP pages vs. Google CDN-hosted pages.
- If you segment to determine transaction sources, the AMP pages will show as a web data source with zero sessions and some transactions.
- 1. The first step is to make sure that ‘ampproject.org’ is added into the Referral Exclusion List under the Property Settings in the Admin section of the Google Analytics account. This should remove a majority of self-referrals from the CDN. This does not remove the records in GA. It removes the referral (source/medium) override from the user moving from CDN to site on second click. Therefore, if the traffic hits the CDN via google/cpc or google/organic it remains as that for the cross-data source navigation – rather than being overridden by the referral from the CDN.
This referral exclusion will help eCommerce (and other) sites maintain tracking of a user session from initial entry on an AMP page in the CDN all the way through to checkout.
- 2. Google also recommends that you add all subdomains of ampproject.org to your referral exclusion list. This step only applies if you’ve got subdomains on your site (or that are being used as PPC landing pages) that are coded in AMP. If the site does not have a need to specifically track/override the referral currently when navigating between CDN and site, then excluding ‘ampproject.org’ referral sufficiently covers any override from the CDN. Google recommends excluding each subdomain but if you have a large number of subdomains in your setup, this may not be practical.
- 3. Create a hit-level custom dimension called “AMPDOC_HOST” in the Google Analytics property: This enables you to segment traffic that started in CDN versus AMP hosted page.
- 4. Set the pageview in Google Tag Manager for the AMP Container to include the custom dimension set the “Dimension Value” to “AMPDOC_HOST”:
Note: “AMPDOC_HOST” does not need to be defined as a variable in the variable settings. The value can be set just like it is in the above screenshot.
- 5. You are then able to view pages served up in the CDN vs. AMP pages in the content reports. To view landing pages served up by the CDN, filter by “cdn” by landing page:
- 6. Then, finally, exclude “cdn” and include “amp” in the filter to view AMP landing pages:
Final Notes on Session Stitching
Support for AMP by other analytics providers remains a work in progress for most. A Google spokesperson explained that the above outlined solution is available to third party analytics platforms, but that “the best place for info is still the Google Analytics solution, since the AMP team is still working on getting documentation up for other third parties.”