Why the dashboard isn't enough
A platform's own ads-manager reporting reflects what its collection endpoint received and how its attribution model chose to count it - both useful, neither a substitute for confirming the request actually left the browser correctly, with the payload it should have, under the consent state it should have. A tag can be "reporting conversions" in a dashboard while still firing on pages it should not, sending more data than intended, or double-counting against a server-side event with no deduplication. The dashboard tells you the platform's story about the data; the network panel tells you what actually happened.
The method, in five steps
- Open DevTools → Network, and clear it. Reload the page from a cold state so you catch the very first request the pixel makes, not just whatever fired after you started watching.
- Filter by the platform's request host - for example
bzr.openai.comfor OpenAI, the relevant UET or Meta domains for those platforms. Filtering by host, not by request name, catches requests you did not know to expect. - Confirm the configuration or SDK-load request fires on page load, with a success status. This is the pixel announcing it is present and correctly configured - its absence is the single clearest sign of a broken or blocked install.
- Perform the tracked action (add to cart, checkout, purchase - whatever the pixel is meant to capture) and confirm an event request fires, with the expected status, containing the event type you triggered.
- Repeat under each consent state your site supports - consent granted and consent declined, at minimum. A pixel that fires identically in both states has no consent gate at all, whatever the installation checklist claims.
What healthy looks like, by platform
| Platform | Host to filter | Healthy pattern |
|---|---|---|
| OpenAI (ChatGPT Ads) | bzrcdn.openai.com, bzr.openai.com | Config GET (200) on load, events POST (202) per tracked action |
| Google (AI Mode / Gemini Shopping) | Existing Google Ads / GA4 tag hosts | Standard gtag conversion event, plus an Enhanced Conversions hashed-data payload on the same event |
| Perplexity (Buy with Pro) | None to verify on the wire - no merchant-facing pixel found | Verification here means confirming the order-tag value appears correctly in your own order-management system |
| Microsoft Copilot (Copilot Checkout) | Existing UET tag host | UET tag fires on the checkout-confirmation page; CAPI call as a separate server-side check if enrolled in the pilot |
| Meta (AI-enriched Pixel + CAPI) | Existing Meta Pixel host | Pixel event fires with enrichment fields populated; matching server-side CAPI event with a shared event ID for deduplication |
The four failure modes worth naming
- Missing configuration request. The pixel is not installed, or something (a consent tool, an ad blocker, a content-security policy) is blocking it before it can load.
- Event request with no prior configuration request. The SDK is firing without having initialized correctly - a misconfiguration, not a working pixel that happens to look incomplete.
- Firing regardless of consent state. The most consequential failure - not a measurement gap but a compliance one, and the exact scenario the illustrative story in our pixel-installation use case is built around.
- Duplicated events with no shared identifier. Common wherever both a browser pixel and a server-side conversions API report the same action - inflates every downstream number until deduplication is confirmed working, not just configured.
Any agency can point a client at a platform's help article. What we do differently is confirm the request on the wire before a number goes into a board report - the same standard we apply to our own estate's crawler and answer-tracking instruments, extended to every vendor conversion tag we install.