Home›Research methodology

How AuditTag research measures tracking tags

By Sam ParkinsonVersion 1.2, updated 5 October 2026First published 19 September 20269 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.

On-page findings

A study can also report on-page findings from the same pages: meta descriptions, page titles, alt text, headings and structured data. These use the thresholds the AuditTag audit uses, which are not Google limits. A title over 60 characters, a meta description over 160 characters and alt text over 125 characters are rules of thumb, and Google measures width and not characters. A finding is counted for a store when it appears on at least one page we read.

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.
• Most Shopify app pixels and Customer events pixels. Shopify loads app pixels and Customer events pixels itself after the page arrives, most of them in a sandbox, so the served page carries only a settings entry for each one. The Facebook & Instagram app's entry names its pixel, so it is counted (from version 1.1). The Google & YouTube app's entry usually lists its ids, and a G- or AW- id there matches the patterns above. A custom pixel from Customer events appears only as the name the merchant gave it, and other tracking apps often as an account key or a link to their own settings, so neither is counted. 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, and says whether it is a defined sample or a convenience sample (see below). A defined sample is fixed 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.

Two kinds of sample

We use two kinds of sample, and every study says which one it used. The four rules above describe a defined sample, drawn from one named list with every exclusion counted. That is the preferred kind.

A convenience sample is a set of stores we chose because we had a practical reason to look at them. It does not meet the rule against hand-picking. A study that uses one says so near the top, says how the stores were found and what we filtered on, and never describes the result as stores in general. Its figures describe those stores on the day they were scanned.

The first on-page study

The first study to include on-page checks uses a convenience sample of 100 independent UK stores on Shopify, in seven categories. We found them through public lists and searches and kept the stores that were on Shopify and that our crawler could read. For 89 of them we also required a published contact address, because we were looking for stores we could write to. The other 11, all jewellery stores, were added later and were not filtered that way. We took "independent" and "UK" from the lists and from each store's own pages, and we did not check the ownership of every store.

One store that was in the sample at the first scan refused our crawler on the final scan. We do not work around a refusal, so we dropped it and took the next store on our list in its place. We did not keep a full count of every store we looked at and passed over while building the lists.

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. The crawler reads the homepage first, then pages in the order the store's sitemap lists them, then pages it finds by following links. Tags are almost always site-wide, so a tag counts as present if it appears on any page we read. A store with more than 10 pages is sampled, so a store counted as clear may still have a problem on a page we did not 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.

The same check found a false negative on 24 September 2026. A Shopify store using the Facebook & Instagram app read as having no Meta Pixel, because that app's pixel is not in the served HTML as fbevents.js or fbq('init'. Shopify adds it after the page arrives. The pattern added in version 1.1 was checked against the public homepages of live Shopify stores before it went in. It matched each store whose page carried the app's pixel entry, and nothing on the others.

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.

The hand check of the first on-page study

We picked 20 of the 100 stores at random with a fixed seed. We fetched every page the crawler had read a second time and read it with a separate parser, then compared nine findings for each store, 180 comparisons in all.

The first run agreed on 178 of 180. Of the two that did not agree, one was our detector being wrong: it counted blank lazy-load placeholder images as images missing alt text. We fixed it and scanned the whole sample again from the start. The other was our check being wrong, because it counted a GA4 ID that sits only inside a consent app's settings and is not an installed tag. Run again after the fix on the same 20 stores, 179 of 180 agreed, and the one that did not was the same check being too loose. All 20 stores were also confirmed as Shopify stores. We did not independently verify that the stores are UK based or independent. We do not publish the names of the 20 stores.

A study is a dated snapshot

The findings of a study describe the stores as read in one final scan, on a stated date and time, with a stated build of the detector. They are not a lasting assessment of those stores. Pages, themes, sitemaps and tracking setups change, and which pages the crawler reads shifts with the sitemap, so a later scan can give different results.

We measured how much. When 20 of the stores were scanned a second time hours later, 8 of 100 store results changed across five on-page findings. Comparing two full scans of the whole sample hours apart, the number of stores whose result changed on any one on-page finding ranged from 1 to 18, while the tracking results did not change at all. So a study keeps one final scan and uses nothing from any earlier scan. It does not read a difference between two scans as a store getting better or worse.

If the detector changes, the study is scanned again from the start with the new build. Figures are never mixed across detector builds.

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.2, 5 October 2026. Added the on-page findings and their thresholds, the convenience sample and how the first on-page study's 100 stores were chosen, the order in which pages are read, the dated snapshot rule with the measured scan to scan variation, and the hand check of 20 stores with its result. The hand check found a detector false positive, blank lazy-load placeholder images counted as missing alt text, which was fixed and the whole sample scanned again. No study had been published under 1.1, so no published figure changes.
• 1.1, 25 September 2026. Meta Pixel is also counted when a Shopify store's page carries the pixel entry written by Shopify's Facebook & Instagram app. Shopify adds that app's pixel after the page arrives, so neither fbevents.js nor fbq('init' is in the served HTML, and under 1.0 every store using it would have read as having no Meta Pixel. No study had been published under 1.0, so no figure changes.
• 1.0, 19 September 2026. First version, published before any study.