AMP and Analytics — Everything you Need to Know

How Accelerated Mobile Pages will impact Analytics Tracking

Hanna Johnson
WebTales
5 min readMar 19, 2019

--

We’ve heard some concerns regarding the impact of AMP on website analytics, and particularly the ability to keep track of the user journey across AMP and non-AMP pages. While implementing AMP does mean some changes on the analytics front, we are here to reassure that you can have your high-speed, super-optimised, super-awesome AMP website and accurate tracking of your visitor behaviour too!

What about AMP?

Accelerated Mobile Pages is a format designed for the mobile web making it possible for your pages to load almost instantly. What makes AMP different than regular HTML webpages, is that AMP can be cached and served from any domain, for example, an article can originate on examplenews.com and also be served in an AMP viewer on google.com (such as in the Google News Carousel). Aside from improved speed, AMP is known to provide a host of other SEO and website performance benefits.

How AMP is Different than HTML in Analytics

AMP is different than regular HTML web pages, because AMP content can be served on multiple domains. This means, a single user can engage with the same website or business across multiple domains.

There are 4 distinct ways in which a user can land on a website with AMP — each implicating the Client ID in Google Analytics:

  1. Google Search Viewer: AMP page is accessed via a Google Search result and displayed inside an “AMP viewer”.
  2. AMP Cache Hosted Page: AMP page is accessed from a proxy/cache.
  3. Site Hosted AMP Page: AMP page is directly visited on publisher domain.
  4. Normal site page / Non-AMP (paired mode): non-AMP page is accessed on publisher domain.

Problems with Analytics and AMP

When a user has a continuous interaction with content from the same publisher, but the interaction continues across 2 separate domains — it results in:

  • Artificially higher user counts, session counts, and bounce rate
  • Artificially lower values for page views per session and session duration

Let’s look at an example.

Example Scenario of tracking across AMP / Non-AMP Pages

A single user views an article in the AMP viewer on (google.com — News Carousel), and then from within the AMP Viewer, clicks to another page on the article owners domain (say, www.examplenews.com).

Data collection for this single user would look like this:

This results in 2 user counts, 2 x 30 second session counts and 1 page view per session. When in reality there was 1 user conducting 1 x 1 minute session with 2 page views. The latter, obviously depicting a more desirable user visit.

Fortunately, these issues have been addressed, and enhancements have been made to ensure more accurate tracking across AMP and non-AMP content

AMP Analytics Enhancements

In 2017, in response to the above situation, Google made enhancements to GA (Google Analytics) so that Non-AMP and Direct-AMP would be served as the same Client ID, *however this change did not impact the AMP cache (i.e, users seeing your content on a google.com domain, or in the AMP Viewer such as the Google News Carousel). This resulted in a solution as follows:

During the first enhancements, only the AMP to non-AMP exchanges were impacted.

AMP Client ID API — Analytics Enhancements

Later in the year (2017), Google launched the AMP Client ID API which allowed us to track that multiple site events belong to the same user when those users visit AMP or non-AMP pages on the site owners domain via a Google AMP viewer (i.e, Google Search Result). This change drastically improved analytics measurements including user counts, session counts and other session-based metrics. The consolidated information provided a more accurate picture of user journeys.

This Client ID API enhanced Analytics tracking, looks something like this:

The AMP Client ID API solved the most common of use cases, where users visit a page inside the AMP Viewer (google.com), and then go directly to either an AMP or non-AMP page on the publishers domain. As long as publishers avoided sending the AMP Cache link out directly, it worked fine.

The AMP Linker — Analytics Enhancements

In September 2018, the AMP Project introduced Amp Linker. The AMP Linker works by decorating the URL of outgoing links from the AMP cache. Anyone using the AMP Client ID API today, will also have the benefits of the AMP Linker.

The AMP Linker has further improved Analytics measurements, and results in a more complete solution looking like this:

Analytics in AMP Today

Today, the AMP Project and Google Analytics Teams have brought these tracking solutions near to perfection. That being said, there are still a couple of use cases where tracking has not quite yet been perfected such as the following:

(1) Visitor views an AMP page in the AMP-Viewer
(2) The visitor does not click to another page on the publisher domain from within the AMP viewer
(3) Visitor clicks back to google.com and does another search
(4) Visitor clicks a search result that lands on publisher’s domain (non-AMP)

Once again, this type of scenario results in 2 separate users/session counts(as we have 2 page views in two separate domains.

Whats Next for Analytics in AMP?

There are a lot of factors impacting analytics today, such as the increased demand for user privacy, resulting in changes such as the Safari update with Intelligent Tracking Prevention. These kinds of changes can impact the ability for accurate analytics. (Fortunately, the AMP Linker still functions properly with this update).

While the AMP project commits to continue improving analytics functionality, and Google makes waves with cross-device features for Google Analytics , we can confidently anticipate further improvements and increased capabilities for GA.

At WebTales, we continue to support all analytics vendors, and integrations. As an AMP Third Party Partner, we maintain our software to the latest technical standards and ensure that these technical updates are available for our clients to use ASAP.

--

--