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. Because of this, site/app metrics are impacted.

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 and displayed inside an "AMP viewer".

    • 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 because google.com is the 1st party in this case. The Client ID passed from the AMP viewer to the page served off of cdn.ampproject.org so that it can be transmitted via amp-analytics.
    • Cookies are only reused if the original AMP pages have the same origin, which is a combination of schema, host, and port.
  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.
    • Cookies are only reused if the original AMP pages have the same origin, which is a combination of schema, host, and port.
  3. Direct AMP: 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 in cookie (_ga) and is used/reused regardless of whether the ID is in traditional or AMP format.
    • If a client ID is generated by an AMP page, the client ID follows the AMP format (amp- followed by a randomly generated string).
  4. Non-AMP: non-AMP page is accessed on publisher domain.

    • In this case the user directly views a non-AMP page on the publisher's domain.
    • The client ID is stored in cookie (_ga) and is used/reused regardless of whether the ID is in traditional or AMP format.
    • If a client ID is generated by a non-AMP page, the client ID follows the traditional client ID format.

Client ID Considerations

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

Multiple client IDs

In all the scenarios, the client IDs used for a user depend on the domain the user visits, even if the user is accessing content from a single client/browser. As a result, a user who accesses a publisher's content as described in the scenarios above will be counted as three separate users in Google Analytics (one each for search, proxy/cache and publisher origin scenario).

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

  • A single cookie is used for a given user. The format of the client ID depends on whether the user's first visit was to an AMP page or a non-AMP page.