Tracking Gap

Tracking gap, defined as a systems boundary

A tracking gap is a missing, duplicated, inconsistent, or unjoinable record in an intended measurement path. Analytics platforms document events as records of user interactions, tag managers document how measurement tags are configured and deployed, and advertising platforms document conversion actions as events selected for reporting ^{[google_analytics_events] [google_tag_manager_overview] [google_ads_conversion_measurement]}. A gap appears when the records those layers are expected to exchange do not reconcile.

That definition is deliberately narrower than a diagnosis. A missing event can be evidence that the current report is incomplete; it is not evidence that a customer, sale, or payment existed outside the report. A duplicated event can make a count unreliable; it does not identify which business decision was affected. The existing revenue tracking and attribution systems owner keeps the wider rule explicit: tracking records what can be observed, while attribution models how credit is assigned ^{[fp_tracking_attribution_owner]}.

Four forms a tracking gap can take

These forms can overlap, but they should not be collapsed. A tag can fire correctly while the receiving report applies a different conversion definition. A CRM record can exist while the click identifier needed for a later join is absent. A platform can include modeled conversions while a first-party ledger contains only confirmed records. Each case needs a different verification question ^{[google_ads_conversion_measurement] [google_ads_conversion_modeling]}.

What can be checked from a public surface

A public-surface review can inspect visible page paths, measurement requests emitted by the browser, response status, obvious duplicate requests, and whether a visible handoff preserves a parameter. It cannot read unpublished tag-manager versions, ad-account conversion definitions, consent records, CRM fields, import jobs, or ledger entries. The Revenue Scan therefore frames public signals as questions for internal verification rather than as proof of commercial impact ^{[fp_revenue_scan_boundary]}.

The same boundary applies when nothing visible appears wrong. A browser request returning successfully establishes that a request was made; it does not establish that the receiver accepted the intended event, attributed it correctly, deduplicated it, or reconciled it against an internal record. Those are account and system-state questions.

A bounded verification sequence

1. Name the decision and the exact event it depends on before inspecting tools.
2. Write the event definition for every system that reports it; record disagreements rather than averaging them away.
3. Trace one bounded cohort through collection, tag deployment, platform receipt, CRM creation, and the relevant downstream record.
4. Check whether one durable identifier survives every handoff where an identity-level conclusion is required.
5. Separate observed records, imported downstream records, and modeled platform records in the closeout language.
6. Record the remaining unknowns beside any reported count or reconciliation.

How the related measurement entities differ

An offline conversion import is one documented mechanism for returning a confirmed downstream event to an advertising platform. A modeled conversion is a platform estimate used where an observable link is unavailable. Neither term is interchangeable with tracking gap: the first is a possible return path, the second is a reporting method, and the gap is the boundary that prevents the current evidence from reconciling ^{[google_ads_offline_imports] [google_ads_conversion_modeling]}.

What a tracking gap does not prove

• It does not prove that an unrecorded lead, conversion, customer, or payment existed.
• It does not quantify revenue, loss, ROI, ROAS, traffic, rankings, or AI visibility.
• It does not establish that a vendor, employee, campaign, page, or workflow caused the disagreement.
• It does not establish that adding more instrumentation is worthwhile; the proposed record should support a named decision.
• It does not replace internal access, consent review, operator judgement, or reconciliation against first-party records.

Where to continue

Use the Tracking, Attribution & Measurement Systems domain for portfolio context, the canonical tracking and attribution guide for the full measurement model, and the Revenue Scan for the public-signal boundary. The adjacent glossary entities explain offline conversion import and modeled conversion.