The formula
The score is a weighted average of six components, each scored 0 to 100:
| Component | Weight | Source | Score |
|---|---|---|---|
| Consent | 0.20 | share of accepted events carrying an explicit consent signal | share × 100; 50 when no events yet |
| Coverage | 0.25 | planned critical events that produced at least one event in the window | seen ÷ planned × 100 |
| Schema | 0.15 | share of events without schema or PII findings | share × 100; 50 when no events yet |
| Dedup | 0.10 | share of duplicates among received events | 100 − duplicate share × 400 (so 25 % duplicates is 0) |
| Delivery | 0.20 | share of successful deliveries, minus a credential penalty | success × 100 − (unhealthy ÷ total integrations) × 50 |
| Liveness | 0.10 | minutes since the last accepted browser event | 100 under 60 min, 70 under 24 h, 20 beyond, 0 when never |
score = Σ(component × weight) ÷ Σ(weight), rounded and clamped to 0–100. The same function feeds the dashboard, the assistant's read-only tools and alerting, so the number you see in the dashboard is the number the assistant reasons about.
Why "no data yet" scores 50, not 0
A site that was created an hour ago has no consent coverage, no schema findings and no deliveries. Scoring those as zero would make every new site look broken; scoring them as perfect would hide real problems later. The neutral 50 keeps the total informative while the detail line says "No events yet" so nobody mistakes it for a measurement. Liveness is the exception: never having received a browser event scores 0, because that is the problem to fix first.
What moves each component
Consent (0.20). Events without an explicit consent record usually mean the CMP integration is missing on some pages or the SDK loads before the CMP answers. Check the consent page for pages with low signal coverage.
Coverage (0.25). The tracking plan lists critical events (purchase, generate_lead, sign_up …). A critical event with zero occurrences in the window is either broken or wrongly marked critical. The detail line names the missing ones.
Schema (0.15). Findings come from the event schema (unknown properties, wrong types) and the PII scanner (e-mails in URLs, phone numbers in properties). The data quality page groups findings by field so a single bad form handler is one fix, not a hundred.
Dedup (0.10). Duplicates above a few percent mean the same event id is sent twice — typically a tag firing on both DOMContentLoaded and route change, or a webhook replay without an order id. The steep penalty is deliberate: duplicates inflate every downstream number.
Delivery (0.20). Failed deliveries are grouped by destination and error class. The credential penalty makes an expired token visible even when traffic is low; reconnecting the account removes it immediately.
Liveness (0.10). A site that stops sending browser events for a day has usually lost its snippet in a deployment. The kill switch also produces this, on purpose, and the detail line says so.
Issues
Schema findings and failed deliveries are recorded as issues on the data quality page, with counts of open and critical items next to the score. An issue can be marked resolved or ignored with a reason, and the change is audited. The assistant's health tool reads the same components and issues when you ask it to explain a drop; it does not guess.
What the score is not
It is not a vanity metric and it is not comparable across sites with different tracking plans. A landing-page site with two critical events and a shop with twelve are measured against their own plans. Use it to notice change, then use the components to find the cause.