Home›Research methodology

How AuditTag research measures tracking tags

By Sam ParkinsonVersion 1.0, published 19 September 20267 min read

We are publishing this page before any results, on purpose. A statistic is only as good as the method behind it, and a method written after the numbers are in is easy to bend to fit them. This is the method, fixed in advance.

What a study measures

For each store in a sample, we record whether each of these tags is present in the served HTML of any page we read:

Only the parts of a page that can load a tag are read: every <script> (its attributes and its body) and every <noscript> fallback. Visible page text is ignored, and so is JSON-LD structured data. A blog post that quotes fbq('init' as an example is writing about a tag, not running one, and is not counted as having it.

From those five, a study reports these figures:

• Analytics detected: GA4, Tag Manager or Universal Analytics present.
• Ad conversion tag detected: Meta Pixel or Google Ads present.
• Universal Analytics only: Universal Analytics present with no GA4. Google stopped processing Universal Analytics in 2023, so that tag collects nothing.
• Universal Analytics leftover: Universal Analytics still loading alongside GA4.
• No tag detected: none of the five found.

The detection rules are the same ones the free AuditTag audit uses. They are fixed patterns, not a model or a guess, so the same page always gives the same answer.

What the scan cannot see

This section matters more than any other on the page. A presence check reads what the server sends. Anything that happens after that is invisible to it.

Specifically, the scan does not detect:

• Tags loaded by Tag Manager. A Meta Pixel or GA4 tag configured inside a Tag Manager container does not appear in the page source. We see the container, not its contents. So "Tag Manager present, no Meta Pixel detected" does not mean the store has no Meta Pixel.
• Tags added by JavaScript at runtime, including by apps, plugins and consent tools. The scan does not run JavaScript.
• Shopify customer events and app pixels. Shopify's own integrations, and pixels added through Customer events, run in a sandbox and may not appear in the HTML in any form our patterns match. Shopify stores are therefore reported as their own group, never blended into an overall "not detected" rate.
• Server-side tagging and first-party proxies, where the browser talks to the store's own domain rather than to Google or Meta.
• Checkout and thank-you pages. We read public pages only. Nothing behind a cart, a login or a payment step is fetched.
• Other platforms, such as TikTok, Pinterest, Microsoft Ads or Klaviyo. They are outside the five tags a study counts.

Every one of these makes the scan under-count, not over-count. So "detected" figures are floors, and "not detected" figures are ceilings. Each published figure says which it is.

How stores are chosen

Each study uses one sample, defined before any store is scanned:

1. A named, public source. For example, a published list of stores on one platform or in one category. We name the source and the date we took the list, so anyone can rebuild the same sample.
2. Written inclusion rules. A store is included if it is a live store selling to the public from its own domain. Marketplace listings, parked domains and password-protected pre-launch stores are excluded.
3. No hand-picking. Once the list and rules are fixed, every store on the list is scanned. We do not drop stores because of what the scan found.
4. Every exclusion is counted. Stores that were unreachable, blocked our crawler in robots.txt, or failed the inclusion rules are reported as numbers next to the results, with the reason.

A sample drawn from one list describes that list, not "all online stores". A study's title and every figure in it are scoped to the sample it actually used.

How the scan runs

• Same crawler as the public audit. It identifies itself as AuditTagBot, reads robots.txt first and honours it. A store that disallows the crawler is excluded and counted, never worked around.
• A small number of pages per store. Up to 10 public HTML pages, starting from the homepage and using the store's sitemap and internal links. Tags are almost always site-wide, so a tag counts as present if it appears on any page we read.
• Polite pacing. One store at a time, at most four requests at once to that store, a twelve second timeout per request, and no retries against a store that refuses us.
• Plain HTML only. No JavaScript runs, no forms are submitted, no accounts are used, nothing is bought.
• A fixed window. Every store in a study is scanned within a stated date range, published with the results. Sites change, so results describe that window, not today.
• Kept apart from customer data. Research scans run through a separate operator tool. They are not audits requested by the stores, and they are never counted as prospects or sales.

How we check the detector before trusting it

Before each study, the detector is run against pages whose tags we have confirmed by hand. Two false positives were found and fixed this way on 18 September 2026: visible page text being read as an installed tag, and Shopify paths mentioned in page text being read as a Shopify store. No research figure will use scans run before that fix.

After each study, we take a random subset of at least 20 stores from the sample, check their page source by hand, and publish how many disagreed with the scan and in which direction.

How results are reported

• Every percentage comes with its sample size, for example "31 of 200 stores (16%)". Percentages are rounded to whole numbers.
• No figure is reported for a group of fewer than 30 stores. Small groups are described in words or not at all.
• Shopify stores are reported separately, for the reason given above.
• Findings are worded to what was measured: "not detected in the page source", never "does not track".
• Results are published as aggregates. No store is named in connection with a finding unless the store has agreed to it.
• Each study links back to the version of this page it followed.

Corrections and changes

If you think a figure is wrong, or your store was scanned and you would like it left out of future samples, email hello@audittag.com. Corrections are published on the study itself, with the date and what changed.

If this method changes, the version number above goes up and the change is listed below. Earlier studies keep pointing at the version they used.

Change log

• 1.0, 19 September 2026: first version, published before any study.