Client IDs in AMP pages

In order for Google Analytics to determine that two distinct hits belong to the same user, a unique identifier, associated with that particular user, is sent with each hit via the client ID field. The unique identifier is a randomly generated string.

For non-AMP pages Google Analytics uses a single, first-party cookie named _ga to store the client ID (on the publisher domain).

For AMP pages, things are a bit different. Pages can be viewed via a browser in multiple ways causing client ID generation and management to vary.

Client ID Scenarios

The various ways users might access an AMP page and the client ID implications are as follows:

  1. Google Search: AMP page is accessed via a Google Search result.

    • In this case the user performs a Google Search and the selected search result is an AMP page. The google.com page contains an IFRAME that points to cdn.ampproject.org and the content is loaded from cdn.ampproject.org.
    • The client ID is stored on google.com and is passed along to cdn.ampproject.org. cdn.ampproject.org is the 3rd party in this case.
    • This is likely the most common way AMP pages will be accessed.
  2. Proxy/Cache: AMP page is accessed from a proxy/cache.

    • In this case the user goes directly to cdn.ampproject.org.
    • The client ID is stored on cdn.ampproject.org. When user revisits (within some time), the client id is reused. cdn.ampproject.org is the 1st party in this case.
    • This is not expected to be a common scenario for accessing AMP pages.
  3. Direct: AMP page is directly visited on publisher domain.

    • In this case the user goes directly to publisher's domain to view an AMP page.
    • The client ID is stored on publisher's domain in a cookie called AMP_ECID_GOOGLE.
      • If the AMP_ECID_GOOGLE cookie does not exist, one might be created. The cookie will have 1 year expiration and be scoped to the top level domain.
    • If a publisher provides both non-AMP and AMP pages for equivalent content then this is not expected to be a common scenario for accessing AMP pages since the canonical URL will likely be the non-AMP page. If only AMP pages are published then this will be the common scenario for the publisher.
  4. Non-AMP: non-AMP page is accessed on publisher domain.

    • In this case the user goes directly to publisher's domain to view a non-AMP page.
    • The client ID is stored in cookie(_ga) and is used/reused as needed.

Client ID Considerations

There are some consideration to take into account based on the scenarios described above.

Multiple client IDs

In all scenarios, the client IDs are different, even if the user is accessing content from a single client/browser. As a result, a user who accesses content as described in each scenario above, from a single publisher, will be counted as four separate users in Google Analytics.

Scenario interactions

The following list provides notes and considerations for how interactions are handled when a user accesses content from the same publisher via multiple scenarios:

Google Search & Direct, Google Search & Non-AMP, Proxy/Cache & Direct, and Proxy/Cache & Non-AMP

  • IDs are kept separate because one of the cases uses local storage which is not accessible from the other case.

Direct & Non-AMP

  • Two separate cookies exist on the same domain but the formats are different (AMP_ECID_GOOGLE is used as the cookie name in the Direct scenario). The user will be counted as two separate users.