Most stores spending real money on ads are optimising against numbers that are wrong in a specific, findable way. The evidence is usually sitting in public page source.
Teardown 001 · shopify · apparel
One counter tag, fourteen firings, one page view
Audited 7 September 2026
| Beacons sent for a single page view | Value |
|---|---|
| As counted | 14 |
| Expected | 1 |
| Difference | +1300.0% |
| Confidence | high |
Basis Counted from the browser network log on three separate loads of the same page, with no clicking or scrolling. One Floodlight counter tag fired 14, 13 and 13 distinct times across those three loads. The figure above is the highest of the three. The estimate of 1 is what a counter tag is supposed to send for one page view. This counts beacons leaving the browser, which is what I could see. It is not the number Floodlight ends up reporting, which I could not see from outside the account.
- 01critical · finding 1.1
The same counter tag fired 14 times in one page load
One Floodlight counter tag, identified by the same advertiser id, type and category on every request, was sent 14 separate times for a single view of the page. Each firing carried its own cache busting value and produced four logged requests, two formats mirrored to the redirect target Floodlight uses, for 56 requests in total. Reproduced on all three captures at 14, 13 and 13 firings.
ad.doubleclick.net/activity;src=<masked>;type=sitev0;cat=<masked>;num=<differs on every firing> - 02major · finding 1.2
All 14 firings landed inside the same second
Every one of the 56 requests carried the same dc_random value, which Floodlight stamps to the second. So this is not one firing at load and another on scroll, and it is not a slow drip across the observation window. It is a single burst at page load, finished before a visitor could have done anything. No scrolling or clicking was performed.
dc_random=1788753190_<...> (identical across all 56 requests) - 03major · finding 1.3
Nothing in the requests ties the 14 firings together
No shared identifier appears across the firings. Each has its own cache buster and carries nothing that would let anything reading the wire recognise them as one page view rather than fourteen. Whether Floodlight collapses them later using its own session cookie is a separate question that the network cannot answer.
num= differs on every firing; no event id, order id or dedup key shared between them - 04minor · finding 1.4
No other ad platform beacon appeared on this page
Across all three captures, 100 percent of the tracker traffic on this page was this one tag. No Meta, GA4, Google Ads or TikTok requests were observed at all. That is an absence inside a short window on one page, not proof those tags are absent from the account. They may be consent gated, may fire later than I watched, or may live on other pages.
0 requests to facebook.com/tr, analytics.google.com/g/collect, googleads.g.doubleclick.net or analytics.tiktok.com, in 3 of 3 captures
Read the full teardown: One counter tag, fourteen firings, one page view
A Floodlight counter tag is a request to Google's ad server that says someone loaded this page. That is its whole job, and the job is meant to be done once per page view, because a campaign report counts those requests. On this store's homepage it was done fourteen times.
I loaded the page three times, waited, and clicked nothing. Every load looked the same. One counter tag, and nothing else at all. Fourteen firings on the first load, thirteen on the second, thirteen on the third. Each firing is logged four times, in two formats, each mirrored to the redirect host Floodlight uses, so the totals came out at 56, 52 and 52 requests for three views of one page.
On the load that fired fourteen times, all 56 of its requests carried the same one second timestamp. I did not record the timestamps on the other two loads, so this is what I can say about that one. It rules out the ordinary explanations. That load is not a tag firing once and again when someone scrolls, and it is not a slow drip across the nine seconds I watched. It is one burst, at load, over before a person could have reacted to the page.
Why this matters if you are buying ads
There are two possibilities and they have very different bills. Either Floodlight collapses these server side, in which case the reporting is fine and the store is sending fifty six requests to get one count. Or it does not, in which case anything derived from this tag reads about fourteen times too high, and the inflation is invisible in the report because it arrives looking exactly like traffic. Someone reading that dashboard has no way to tell the two apart. Neither did I.
Where my knowledge stops
Two places, and both of them matter.
I watched fourteen beacons leave the browser. I did not watch the number that came out at the other end. Floodlight keeps its own session state and can collapse repeat activity before it reaches a report. If it does that here, this is noise rather than a wrong number. Nobody outside the account can settle that from the network alone, so I am not going to tell you the reported figure is wrong. What I can tell you is what left the browser: fourteen beacons where the tag's own job called for one.
I also do not know the cause. A homepage with fourteen promotional tiles, each wired to the same site wide counter, would produce this exactly. So would one snippet pasted twice into a template, or a listener rebound on every render. All three leave the same trace on the wire. Separating them means opening the tag manager, which is inside the account and not something I can see.
What I will say is that fourteen firings of one counter, inside one second, for one page view, with nothing connecting them, is not what a correctly wired counter looks like. It is worth twenty minutes in the account to find out which of the three it is.
Teardown 002 · custom · accessories
Two vendors counted the same page view twice
Audited 7 September 2026
| TikTok Browse events for a single page view | Value |
|---|---|
| As counted | 2 |
| Expected | 1 |
| Difference | +100.0% |
| Confidence | moderate |
Basis TikTok's fallback request carries its payload as base64 in the query string, which decodes to plain JSON. I read the event name and the event_id straight out of the decoded body rather than inferring them from the parameters around it. Two captures decoded far enough to show both copies, the first observation and one of three later re-checks, each giving two Browse events milliseconds apart with an empty event_id on each. The other two re-checks neither reproduced nor contradicted that: their bodies arrived as POSTs my tooling could not read, so the events in them could not be identified either way. The estimate of 1 is the single Browse a page view should produce.
- 01major · finding 2.1
TikTok received the same Browse event twice with no dedup key
Two Browse events reached the same pixel code within a few milliseconds of each other, 4 milliseconds apart in the first observation and 2 milliseconds apart in the capture that reproduced it. The event_id was an empty string on both, so there is nothing in either request that would let TikTok recognise them as one event. This was read from the decoded payload, not inferred from surrounding parameters.
{"event":"Browse","event_id":"","message_id":"messageId-<...>866-<...>"} {"event":"Browse","event_id":"","message_id":"messageId-<...>870-<...>"} - 02major · finding 2.2
GA4 received page_view twice from a single named tag
Two page_view hits reached the same GA4 property in one load, both stamped with the same tag manager tag name. Their _et and _s values differ, and those two fields are written per request, which is what shows these were two separate firings of the tag rather than one request logged twice. Reproduced in two of three captures.
en=page_view&_s=1&_et=2 then en=page_view&_s=3&_et=1 (same property, same page load id) - 03minor · finding 2.3
A third tag fired once and typed its second call as a dedup event
The Bing tag on this page sent its page load action and then a second call explicitly typed as a dedup event. The typed request is what was observed. My reading of it is that the tag deduplicates on the client, which is a reading of one label rather than something I confirmed against how Bing's script behaves. I am including this because it argues against the easy conclusion. No duplicate of this tag's page load action was observed, so the page is not uniformly broken. Two vendors received one view twice and a third, on the same page, did not.
bat.bing.com/actionp/0?<...>&evt=dedup
Read the full teardown: Two vendors counted the same page view twice
An event_id is the field a pixel uses to say this is the same thing you already heard about. When two copies of an event arrive carrying the same id, the vendor keeps one. When they arrive with no id, the vendor has no basis for deciding they are the same thing, so it keeps both. On this store's homepage that happened twice over, to two different vendors, on one page load.
TikTok sent its Browse event twice, a few milliseconds apart, to the same pixel code, with an empty event_id on both copies. I did not work that out from the timing or the request count. TikTok's fallback request carries the payload as base64 in the query string, so I decoded it and read the event name and the empty id out of the JSON.
Separately, and from a different vendor, GA4 received page_view twice for the same property, both hits stamped with the same tag manager tag name. The two hits differ in their _et and _s values. That detail is the whole proof: those fields are written per request, so two hits carrying different values are two firings of the tag, not one request that got logged twice somewhere along the way.
On the same page load, the Bing tag sent its page load action and then a second call explicitly typed as a dedup event. That typed request is what I saw. I read it as Bing's own client side deduplication working, sitting on the same page as the two that are not, but reading a label is not the same as watching it dedupe, and I did not watch that. I mention it because it is the honest shape of the finding. This is not a page where every tag is broken.
Where my knowledge stops
I saw two vendors receive one page view twice. I did not see what either of them reported afterwards, and I have no access to the accounts that would show me. A duplicate on the wire is a duplicate that could be counted, not a duplicate I have watched being counted.
The TikTok pair decoded fully twice, in the first observation and in one of three later re-checks. The other two re-checks did not disagree with them. Their payloads arrived as POST bodies my tooling could not read, so the events inside them are unidentified rather than absent. That is a limit of my instrument and I will not dress it up as evidence that the fault comes and goes. I do not know how often it happens. I know it happened, and that a second look reproduced it.
One more distinction worth keeping straight. I said TikTok sent an empty event_id, and that is a real omission, because TikTok has that field and it was left blank. GA4 is different. Its hit protocol has no per event dedup field at all, so the absence of one there is how the protocol is built rather than a safeguard anyone skipped. The GA4 duplicate is still a duplicate. It just is not the same kind of mistake.
Method
What $500 buys, and what I need from you
I read your storefront the way the ad platforms read it: from the public page source, plus screenshots of your own reporting that you send me. I identify which events fire more than once, which fire not at all, and which report to two systems that disagree. You get a written audit in the format of the teardowns on this page: numbered findings, severity, the evidence line, and an estimate of how wrong each reported number is with the basis stated.
- For the audit No access. Nothing at all.
- For the repair Read-only GA4 and ads reporting.
- For production Nothing until the first two have earned it.
About
Who is doing the work
I am Awwab Tahir. I have spent years fixing storefronts for store owners, which is how I ended up here: the same broken pixel, the same double-counted purchase, the same consent banner silently deleting revenue, store after store. The teardowns above are that pattern written down.
I have not published client attribution case studies because I do not have permission to name anyone. Rather than invent social proof, I audit real stores from public source and show the work, so you can judge the method instead of taking my word for the outcome.
Client reviews
Muhammad was fast efficient and knowledgeable. He was able to fix my woocommerce / Facebook pixel issue very quickly and helped me to get my reporting working correctly. Excellent!
His proficiency and expertise in Gravity Forms as well as Wordpress showed through in every action he took to remedy the situation. I am proud to recommend Mr. Tahir, to anyone trying to make a decision whom to hire.