How the audit scores your tracking
A score you can't audit is just marketing. This page documents every check our free tracking audit runs, exactly how the number is calculated, and, just as important, what an external scan cannot see. When the methodology changes, the version number above changes with it.
The verified health score
The score is a verified health score: your setup only gets credit for what we can prove from the outside. Every applicable check starts you at 100 per category; findings subtract from it:
| Finding type | Deduction | Meaning |
|---|---|---|
| critical | −16 in its category | A leak actively costing you signal or money. |
| needs verification | −9 in its category | Something we couldn't prove healthy from outside. Unproven ≠ fine. This is the honesty tax. |
| warning | −6 in its category | Working, but leaving efficiency on the table. |
The overall score weights the four categories: Foundation 30% · Event coverage 30% · Data quality 20% · Resilience 20%. Three hard caps keep the headline honest:
- No pixel found anywhere → score capped at 18. There is no partial credit for tracking that doesn't exist.
- Limited visibility (tracking sealed inside layers we can't open) → a graduated cap, described below.
- Any critical finding → capped at 74, minus 9 for each additional critical. A ship with a hole in it isn't "tight."
Grades: A ≥ 90 · B ≥ 78 · C ≥ 62 · D ≥ 45 · F below that.
The graduated sealed-sandbox cap
Some setups (Shopify's pixel sandbox, custom tag templates) seal most of their tracking away from any external scanner. A flat cap would hand every one of those stores the same D, which punishes good setups for our lack of visibility rather than theirs. So the cap is graduated: it starts at 55 and earns credit for things we can verify from outside:
- +8 when the pixel sandbox inventory is readable (we can enumerate every registered app and custom pixel).
- +5 when an independent analytics tool (GA4 or equivalent) is present for cross-checking.
- +4 when consent handling checks out clean.
The cap never exceeds 72. Full marks still require the things only a live look can prove.
Verified score, potential score
Limited-visibility reports show two numbers. The verified score is what we could prove, and the letter grade always follows it. The potential score is where the number lands if every pending needs-verification check passes a live look: the verified score plus the deductions those pending checks cost, capped at 95. It is printed next to the dial with the count of pending checks, so a capped report reads as "prove the rest" instead of a flat failing grade.
Dollar estimates follow the same honesty rule: needs-verification findings never carry a dollar figure. Every dollar amount in a report is labeled "estimated monthly signal at risk," is tagged with the spend assumption behind it, and the headline number is always the exact sum of the itemized findings below it. No spend bracket picked, no dollar figures at all.
Every check we run
Checks only count when they apply to your setup (a lead-gen site isn't graded on Purchase values). Your report shows each one as verified clean, failed, warning, or needs-verification.
| Check | If it fails | What we actually read |
|---|---|---|
| FOUNDATION | ||
| Meta pixel installed | critical | Your page HTML, inline + same-origin scripts, GTM container JS, Shopify's pixel-sandbox registry |
| Pixel ID valid with Meta | critical | Meta's live per-pixel config endpoint (connect.facebook.net/signals/config) |
| One pixel, not strays | warning | Every pixel ID found across all install layers |
| Single install layer (no duplicate firing) | critical | Hardcoded vs GTM vs platform-native installs of the same ID |
| Shopify pixel-sandbox X-ray | verify | The web-pixels-manager bootstrap JSON: every registered app + custom pixel |
| Ad landing page carries tracking | critical | The landing-page URL you give us, scanned like any other page |
| EVENT COVERAGE | ||
| PageView base signal | warning | fbq calls in your code + GTM tag templates |
| Funnel conversion events wired | critical | ViewContent / AddToCart / InitiateCheckout / Purchase (or Lead-path) across up to 6 pages |
| Custom events mapped to standards | warning | trackCustom calls + GTM custom event names |
| DATA QUALITY | ||
| Purchase carries value + currency | critical | The parameter objects on your actual event calls |
| Content IDs on browse events | warning | content_ids / content_name / content_type parameters |
| Leads carry a value | warning | value parameter on Lead events |
| Advanced Matching enabled | warning | Meta's live config (selectedMatchKeys) + manual match data in your init call |
| No Meta data restrictions | critical | The restrictedData flag in Meta's live config. Meta silently strips data from restricted pixels |
| Product pages catalog-ready | warning | JSON-LD Product schema, OpenGraph product tags, SKU/GTIN presence on your product page |
| Event parameter quality readable | verify | Applies to sealed setups (sandboxed pixels / opaque templates): whether value, currency and content parameters can be read externally at all |
| RESILIENCE | ||
| Conversions API (server-side signal) | critical | Server-side GTM signals, Shopify native channel, tagging-provider fingerprints |
| Browser/server deduplication keys | critical | eventID parameters on conversion events when server-side tracking exists |
| Consent banner not silently blocking | warning | CMP detection + consent-blocked script markup (type="text/plain", consent-default-denied) |
| Domain verified with Meta | warning | The facebook-domain-verification meta tag |
| noscript fallback present | warning | The image-tag fallback in your HTML |
| Pixel loads early | warning | Position of the init snippet relative to </head> |
| Independent analytics for cross-checking | warning | GA4 (or equivalent) presence. Without it, Meta grades its own homework |
| No dead tracking scripts | warning | Universal Analytics and other shut-down tags still loading |
What an external scan cannot see
Anyone who tells you a URL scan verified everything is selling something. Honestly out of reach from the outside:
- Checkout events on hosted checkouts (Shopify et al.). Purchase and InitiateCheckout fire on pages a scanner can't enter. We mark them "needs verification," never "verified."
- Inside custom sandbox pixels. We can enumerate them (and do), but not read their code.
- CAPI internals. We detect server-side infrastructure, but only Events Manager shows whether events actually arrive and deduplicate.
- Event volume and match quality. That data lives in your ad account, not on your website.
That's exactly what the free 20-minute walkthrough covers: we open Events Manager together and verify the things a scan can't. It's also why the score says verified. We'd rather undersell your setup than invent a number.
Version log
v1.1 · July 2026: graduated sealed-sandbox cap (55 base, verifiable credits up to 72),
verified + potential score display (potential capped at 95), itemized dollar estimates.
v1 · July 2026: initial public methodology. 24 checks, category weights 30/30/20/20,
caps for no-pixel (18), limited visibility (55), and criticals (74 − 9/critical).