Not every 200 was a person

Prefetch and prerender

Browsers and CDNs prefetch documents they think you will navigate to. Chrome prerender can run enough of the page to fire tags. Speculation rules and rel=prefetch are explicit versions of the same idea. If your conversion pixel is in the head of a page a bot might prefetch, you will mint conversions. Gate conversion tags on a real user action or on a server-side order id, not on DOM Ready of a public URL.

Link prefetch from an email client or a search result is enough to GET an img pixel. sendBeacon and fetch on load are enough to POST a Purchase if you put them on load. The 200 is real. The user is not. PageView on landing is usually acceptable noise. Purchase on landing is a model poison.

Slack unfurls and scanners

Slack, iMessage, Twitter, and LinkedIn fetch URLs to build a preview card. They follow redirects, they load og:image, and some of them execute enough HTML to fire a 1x1. Antivirus and enterprise URL scanners do the same from data-center IPs, often with a browser-like user-agent. A click tracker that 302s to your landing page will be walked by the scanner. Your landing PageView fires. If Purchase is on that page, Purchase fires.

Slack-unfurl user-agents are sometimes obvious (Slackbot). Many scanners are not. Rate-limit S2S endpoints that mint conversions. Require a signature or a shared secret on postbacks. Do not treat User-Agent as authentication. Do not fire conversions from a robots-accessible preview query string (?utm_preview=1, ?gtm_preview=) that a crawler can hit.

Email proxies and Mail Privacy Protection

Gmail serves images through googleusercontent.com proxies. Apple Mail Privacy Protection prefetches images when the message arrives, from Apple IPs, which mints opens with no human. Corporate gateways rewrite img src. An open pixel that 302s to a conversion URL will convert on delivery. Keep open pixels on an open collector, and conversion pixels on a conversion collector, with no redirect from one to the other.

Cache-busting an email pixel with the recipient's email address publishes that email to the proxy logs. Use an opaque send id. The proxy will still prefetch. Your dashboard will still over-count opens. That is a known product limit, not a broken img. Do not fire a site Purchase from the footer image as a workaround.

IVT in the UI versus BigQuery

Google, Meta, and the MRC ecosystem filter invalid traffic in their reports. General IVT, sophisticated IVT, datacenter traffic, and pre-bid filters never show in the ads manager the way they show in raw logs. Your BigQuery export of GA4 or your warehouse of /g/collect hits will not match the UI. That gap is not always a broken pixel. It is often the filter doing its job.

When the UI is lower than the warehouse, do not raise the pixel fire rate to compensate. When the UI is higher, look for duplicate tags, Strict Mode, and thank-you reloads before you accuse IVT of adding people. Compare on event_id uniqueness, not on row counts. MRC accreditation is a vendor claim about their filter, not a guarantee that your thank-you pixel is clean.

What you can actually do

Conversions from a server-side order id. Impression pixels that 204 and do not redirect. Click chains that do not land on a URL that converts on GET. Ignore hits with empty user-agent only if you know your real app never sends one; many in-app webviews send odd UAs that are still users. Rate-limit MMP postbacks. Keep staging pixels off production ids so Slack-unfurled staging links do not train the model.

Core will tell you if the URL is not absolute, if it has userinfo, if the scheme is not http or https, if a fired macro did not expand. It will not tell you the GET came from Slackbot. That check is your log, your UA parser, and your rule that Purchase requires an order id the scanner does not have.

Check the artifact

Paste the pixel URL or JSON body into the playground. Same engine as pixellint validate. Nothing leaves the tab.