Features

Data quality and health score

Know when tracking breaks, see which part broke and jump straight to the fix — before a campaign runs on bad data.

Tracking health

Example data: Static example state — not live traffic, no real customer data.

Score

86 / 100

Components

  • Consent coverage91 · 20% weight

    91% of events carry an explicit consent signal

  • Critical events78 · 25% weight

    7 of 9 planned critical events observed

  • Schema quality74 · 15% weight

    74% of events pass schema and PII checks

  • Duplicates96 · 10% weight

    1.0% duplicates

  • Delivery88 · 20% weight

    94% delivered, 1 integration with credential problems

  • Freshness100 · 10% weight

    Last browser event 4 min ago

Open issues

  • purchase without currency

    12 events in the last 24 h are missing the required parameter

    Fix: update the event mapping
  • Consent signal missing

    9% of events arrived without an explicit consent state

    Fix: connect the CMP adapter

Weighted components; a lower score always points at its cause.

Example score with its six components and two open issues, each naming the tool that fixes it.

Six components, one explainable score

The worker computes a tracking health score from consent coverage, critical event coverage, schema quality, duplicate rate, delivery success and freshness. Each detected issue names the assistant tool that resolves it.

The score is computed from the events of the last period: how many carry an explicit consent signal, which planned critical events were seen, how many pass schema and PII checks, the duplicate rate, the delivery success per destination and when the last browser event arrived. The weights are shown next to the score, so a lower number always points at its cause.

Six components, one explainable scoreEvents of the last period run through the checks; six weighted components form the score, and each open issue names the tool that fixes it.Eventslast periodChecksconsent · schema · deliveryScore 866 weighted components2 issueseach names its fix
Events → checks → weighted components → score with the issues that lowered it.

How it is built

The technical decisions behind the capability — the proof after the benefit.

  1. 01

    Issues with fingerprints

    Recurring problems are grouped, counted and timestamped so you see trends instead of noise.

  2. 02

    Schema guardrails

    Standard events have required parameters; custom events follow naming rules; PII in properties is blocked before storage.

  3. 03

    Benchmarks only with opt-in

    Anonymised, aggregated benchmarks are available only for organizations that opt in.

Noticing problems versus being told

How a broken purchase event surfaces with and without the health score.

Noticing problems versus being told
Noticing problems versus being toldWithout monitoringWith the health score
DetectionSomeone notices a dip in the ads dashboard days laterThe score drops and an issue is opened
DiagnosisWhich tag, which page, which browser?The component that dropped and the events behind it
FixTicket, tag change, re-publish, waitThe issue names the assistant tool; you approve the change
TrendNo historyGrouped, counted and timestamped issues

What you can verify

Product facts you will find in the dashboard, the docs and the audit log.

  • Score per site with its components
  • Resolve or ignore issues with an audit trail
  • Consent coverage and duplicate rate as first-class metrics

Questions

Is the score comparable across sites?
The components are identical for every site; weights are documented in the score card so teams can reason about differences.

More capabilities

Built on the same signed configuration and event schema.

Try it on your domain

Create a site, install one snippet and let the assistant configure the first destination in minutes.