AMP analytics gaps
Accelerated Mobile Pages restrict JavaScript and require the amp-analytics component instead of standard tags. Because AMP pages are frequently served from a cache (e.g. a Google AMP cache) on a different origin, the client identifier and referrer differ from the canonical page, so the same user can look like two users and a session can split when they move from AMP to canonical. This page explains the gaps and the linking that mitigates them.
Why AMP tracking differs
AMP forbids author JavaScript, so analytics run through the amp-analytics component with a declarative config rather than a normal tag. AMP documents are also commonly served from a cache on a separate domain for speed, which means the analytics client sees a different origin than your canonical site.
Identity, referrers, and session splits
Two consequences follow from the cache origin. First, the client/visitor identifier set on the cache origin is not the same one used on your canonical domain, so a user who reads an AMP page and then clicks through can be counted twice. Second, the referrer for the canonical hit may show the AMP cache rather than the true source, producing self-referral-like noise.
AMP provides a Client ID API and analytics linking specifically so the AMP and canonical identifiers can be reconciled; without it, AMP-to-canonical journeys fragment into separate users and sessions.
- amp-analytics replaces standard JavaScript tags
- Cache serving puts AMP on a different origin
- Client ids differ → users double-counted
- AMP Client ID linking reconciles AMP and canonical
How it appears in analytics and logs
Inflated users or self-referrals on AMP traffic usually reflect cache-origin and client-id differences, not real new visitors; AMP Client ID linking is the documented mitigation.
Diagnostic use case
Explain why AMP traffic shows inflated user counts or odd referrers, and why AMP-to-canonical journeys appear as separate sessions.
What WebmasterID can help detect
WebmasterID records page_view events first-party on whichever origin serves the page, so you can see AMP and canonical traffic distinctly and judge how much arrives via cache.
Common mistakes
- Treating AMP and canonical visitors as already-unified without linking.
- Reading AMP-cache referrers as real traffic sources.
- Forgetting amp-analytics config differs from the standard tag.
Privacy and accuracy notes
AMP client identifiers are governed by the AMP framework's privacy model; do not attempt cross-site stitching beyond documented linking. This page is educational, not legal advice.
Related pages
- Self-referrals and lost attribution
A self-referral is when your own site shows up as a referring source in your reports. It usually means a session was broken and a new one started attributed to your domain, often when a visitor crosses subdomains or returns from a payment provider. Self-referrals fragment sessions and steal credit from the real source. This page explains the causes and the fix.
- Subdomain tracking issues
Subdomains under the same registrable domain (blog.example.com, shop.example.com) typically share a first-party cookie set on the parent domain, so a user stays continuous. Problems arise when the cookie domain is scoped too narrowly, when subdomains use separate properties, or when one subdomain appears as a referrer to another. This page distinguishes subdomain handling from true cross-domain tracking.
- Redirect and referrer loss
The referrer tells analytics where a visit came from, but it is fragile. A redirect hop can replace the original referrer with the redirector's URL, and Referrer-Policy or HTTPS-to-HTTP downgrades can suppress it entirely. When the referrer is empty, the visit falls into direct; when it is the redirector's domain, it can look like a self-referral. This page explains referrer loss in transit.
- Web analytics
First-party measurement across page variants.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.