Quick answer
Data observability is the practice of continuously measuring the health of data, such as its freshness, volume, schema, value distribution and lineage, so that problems are detected early and traced to the step where they started.
What is data observability?
Data observability is the ability to tell, at any moment, whether your data is healthy (fresh, complete, correctly structured and plausible) and, when it is not, to find where it broke. The term borrows from software observability, applied to data pipelines instead of servers.
The five pillars
| Pillar | Question | Analytics example |
|---|---|---|
| Freshness | Is the data up to date? | Today's events have not arrived since 09:00 |
| Volume | Is the amount normal? | Purchases dropped 90% after a release |
| Schema | Did the structure change? | price started arriving as a string |
| Distribution | Are values in the expected range? | country is suddenly 60% "unknown" |
| Lineage | Where did it come from, what depends on it? | Which dashboards use the broken event |
Observability vs monitoring vs data quality
- Data quality is the goal: data that is accurate, complete and consistent enough to use.
- Monitoring checks conditions you set in advance ("alert if events < 1,000 per hour").
- Observability adds the context to investigate what you did not anticipate: history, distributions, lineage and where data was dropped.
Failure modes in analytics tracking
Tracking is a pipeline too, and it fails silently: no error appears on the chart, the numbers just get smaller.
| Failure | What you see | Signal that catches it |
|---|---|---|
| Script removed or blocked on some pages | Pageviews drop on a set of URLs | Volume by page; collection-gap alert |
| Event renamed in code | Old event falls to zero, new "unplanned" event appears | Unplanned events; volume per event |
| Required property missing | Breakdowns show "(none)" | Property completeness |
| Property value explosion (ids in a name field) | Slow reports, unusable breakdowns | High-cardinality check |
| Domain or exclusion rule rejecting traffic | Totals fall, nothing obvious in reports | Collector reject reasons |
| Click selector stops matching after a redesign | Autocaptured event falls, page traffic does not | Stale-rule detection |
A weekly checklist
- Compare event volumes with the same weekday last week.
- Review new "unplanned" events and decide: claim, rename or block.
- Check completeness of required properties on key events.
- Look at collector rejects and their reasons.
- Confirm that data latency is normal (today's data is arriving).
Data observability in TapCub
The data quality page (All-platform analytics › Data › Data quality) shows where data was lost before or during storage: ingestion warnings, collector rejects by reason (domain mismatch, exclusion rule, monthly quota, rate limit, invalid payload, bots), high-cardinality properties, quarantine, and stale detection, which flags a click rule whose hits fell more than 80% week over week while autocapture on the same page did not. The tracking plan with live verification shows 24-hour hits and required-property completeness per event. For alerts, a monitor with the collection-gap condition fires when no data arrives for longer than the minutes you set, and the anomaly condition catches unusual volumes. See also data dictionary and anomaly detection.
Was this explanation clear?
We use your answers to fix and expand this page.
Couldn’t send. Please try again in a minute.
Thanks for the feedback. We’ll use it to improve this page.You’ve already sent feedback on this page. Thanks.
Technical Engineer
Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.