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 page contains an IFRAME that points to and the content is loaded from
    • The client ID is stored on because is the 1st party in this case. The Client ID passed from the AMP viewer to the page served off of so that it can be transmitted via amp-analytics.
    • 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
    • The client ID is stored on When user revisits (within some time), the client id is reused. is the 1st party in this case.
    • This is a somewhat common scenario for accessing AMP pages that’s implemented by some non-Google Search referral sources.
  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 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 referral sources that support AMP will typically prefer to serve the page according to one of the two methods described above. If only AMP pages are published then this will be the common scenario for the publisher. This case may also be common if a publisher frequently chooses to link to the AMP version of their pages (for instance, as part of onward journey experiences).
  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 as needed.
    • It will be common for users to visit a non-AMP page after visiting an AMP page (i.e. as part of the same session) if a publisher frequently includes links to non-AMP pages on their AMP pages.

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 AMP scenario). The user will be counted as two separate users.