How to audit every tracking pixel on a page in one view

Why is a pixel audit so hard in the plain Network tab?

Because the Network tab has no idea what a tracking request is. It gives you hundreds of rows sorted by time, with no grouping by vendor, no notion of category, and no consent context.

"What exactly is this page loading?" is a simple question with a miserable answer in plain DevTools. Tracking hides behind hostnames you have to recognize on sight (bat.bing.com, ct.pinterest.com for Pinterest, px.ads.linkedin.com for LinkedIn, sc-static.net), plus CNAME-cloaked first-party endpoints that don't look like tracking at all. A manual pixel audit means keeping a mental map of several hundred ad-tech domains.

Event Watcher recognizes 590+ platforms and turns the same traffic into a named, categorized, consent-checked inventory: the audit becomes reading a list instead of decoding one.

What do you need before you start?

Event Watcher installed, DevTools open on the Event Watcher panel, and a clean session, because the stack a site loads before consent and after consent are two different stacks.

Start from incognito or cleared cookies. Plan two passes: one without touching the banner, one after accepting.

How do you audit every tracking pixel, step by step?

Reload the page with the panel open and read the filter toolbar: one chip per detected platform, grouped by category and carrying that platform's event count. That toolbar is the inventory, and the seven steps below turn it into an audit you can hand over.

1. Reload the page and let it settle. The filter toolbar fills with a colored chip per detected tool, grouped into categories: Analytics, Advertising, Ad Tech, Tag Managers, CDPs, Session Replay, Consent, and so on. Each chip's count badge shows how many events that tool fired. This toolbar is the audit summary: every chip is a platform present on the page.

2. Switch the view mode to Tool (the Grouped view's tool pivot). Events organize by category, then platform. Expand any platform to see every request it made. Right-click a platform chip and choose "Show Only" to isolate a single vendor's traffic, including its script loads.
3. Interact with the page: scroll, click, add to cart. Pixels that fire on interaction rather than load (remarketing tags, scroll trackers) join the inventory as they fire.
4. Check the consent dimension. With the Consent filter on Auto, every tracking event carries a granted / denied / pre-consent verdict, and tools that fired violations show a red or yellow pill on their chip with the violation count. On your pre-consent pass, this instantly separates "loads before consent" from "waits properly". Dig into specifics with the pre-consent GA4 guide.

5. Switch to Stack view for the structural picture: one card per platform, arranged as a tree by who loaded what: page → GTM → vendor tools. This answers "how did this pixel get here?" for every platform at once. A pixel hanging off another vendor's script (a CMP loading an ad pixel, or a Meta Pixel piggybacking on a tag you did approve) stands out immediately.

6. Inspect anything suspicious. Click any event for decoded parameters, the cookies it set or sent (with Set/Sent direction badges and an ePrivacy flag on cookies expiring beyond 13 months), and an About Tool section explaining what the platform is. Events Event Watcher can't identify are labeled as unknown rather than silently dropped. Those are your CNAME proxies and exotic vendors, and you can map them to a platform via a custom endpoint.
7. Export the inventory. The toolbar Export button offers Copy for Human (curated overview), Copy Markdown Table (pastes into Notion, GitHub, or a client doc), and Copy Complete (raw detail). In Stack view the same button exports the platform tree as Markdown, a Mermaid diagram, SVG, or JSON, a ready-made stack diagram for the audit report.

What does a clean audit look like, and what does a problem audit look like?

Clean means every chip maps to a vendor the site owner can name a purpose and a contract for, and only consent-exempt infrastructure fires before the banner is answered. A problem audit shows violation pills, unapproved piggybacking, or a cluster of unknown events.

Good: every chip in the toolbar maps to a vendor the site owner can name a purpose and a contract for. Before consent, only exempt infrastructure (tag manager, dataLayer, CMP) plus explicitly consent-exempt tools fire; marketing pixels appear only on the post-accept pass. No unknown events, and no chips with red violation pills.

Bad: more platforms than anyone expected (the classic audit finding); chips with red or yellow pills showing pixels firing pre-consent or after denial; advertising pixels loaded by another vendor's script in Stack view (piggybacking nobody approved); marketing cookies with Set badges before consent; or a cluster of unknown events pointing at an unmanaged CNAME-cloaked collector. Each of those is a line item for the remediation list.