Cross-account data leakage
Cross-account data leakage is when events meant for one property land in another. It happens when a measurement ID is copied to the wrong site, a shared GTM container loads on multiple unrelated domains, or a tag template references the wrong destination. The result is inflated, contaminated data in the receiving property and missing data in the intended one. This page explains the causes and the hostname checks that catch it.
How hits cross accounts
A property is just a destination identified by a measurement ID. Anything that points the wrong ID at a site sends that site's hits to the wrong place: copy-pasting a snippet from another project, a shared GTM container deployed across unrelated domains, a hard-coded ID in a reused template, or a staging environment still wired to production. The receiving property then logs hostnames and paths it has no business seeing.
Detecting and containing leakage
The primary signal is the hostname dimension. Filtering reports by hostname surfaces any domain that is not yours; legitimate properties should only see their own hostnames (plus expected subdomains). Unexpected hostnames mean either leakage or referral/ghost spam hitting the ID directly.
Containment combines a hostname allow-list filter, removing the ID from places it does not belong, separating staging from production IDs, and not sharing containers across unrelated sites. Left unfixed, leakage both inflates the receiving property and starves the intended one.
- Wrong/copied measurement ID sends hits to the wrong property
- Shared containers and reused templates spread the mistake
- Detect via the hostname dimension: foreign domains appear
- Contain with hostname filters and per-environment IDs
How it appears in analytics and logs
Hostnames or page paths in a property that do not belong to that site indicate cross-account leakage: another property's tag is pointing at this destination.
Diagnostic use case
Diagnose unfamiliar hostnames or unexpected traffic in a property, traced to another site sending hits to your measurement ID.
What WebmasterID can help detect
WebmasterID scopes events to the site that generated them, so traffic from an unrelated domain is visible as a hostname anomaly rather than silently blended in.
Common mistakes
- Copying a tracking snippet between projects without changing the ID.
- Deploying one GTM container across unrelated domains.
- Leaving staging wired to the production measurement ID.
Privacy and accuracy notes
Leakage can move user data into the wrong account; treat it as a data-governance incident and review what was collected. This page is educational, not legal advice.
Related pages
- Hostname leakage across properties
Your measurement ID is visible in page source, so anyone can paste it on another site and have that traffic report into your property. Staging copies, scraped clones, and proxies do this too. The leaked hits inflate and pollute your data with another domain's traffic. This page explains hostname/property leakage and the valid-hostname filtering that contains it.
- Tag Manager misconfiguration
Google Tag Manager (GTM) sits between your site and analytics, so a misconfigured container quietly distorts every downstream metric. Typical faults include triggers that fire on the wrong pages, tags that fire twice, dataLayer values pushed after the tag reads them, and changes left in Preview but never published. This page catalogs the misconfiguration classes and how to verify a container.
- Referral spam and ghost traffic
Referral spam and ghost traffic are fake hits crafted to appear in your reports. Crawler spam loads pages to leave a referrer in your logs; ghost spam sends hits straight to a measurement endpoint without ever visiting your site. Both add phantom sessions with no engagement. This page explains the mechanics and the filtering that removes them.
- Multi-site analytics
Keep each site's data scoped to its own property.
Sources and verification notes
- Google — [GA4] Set up a Google tag / measurement ID
- Google — [GA4] Filter out unwanted hostnames (data filters)
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.