[← Data Observability](/category/data-observability)

# Data observability for marketing: what to monitor and who owns it

[David Pombar](/about-me) · October 21, 2026 · 9 min read

Data observability for marketing data means checking every day, not once a quarter, that your tags, events, parameters, consent signals and pixels still match what you specified, and sending each break to a named owner. By the end of this post you will know what to monitor, how to route alerts, and how to judge the tools that sell this.

*Disclosure: I work at Trackingplan, one of the tools in this category. I evaluate it with the same criteria as the others, and I say where it is not the best fit.*

## Audits only tell you what was broken on audit day

A marketing implementation changes far more often than anyone audits it. Developers ship releases, someone publishes a new Google Tag Manager (GTM) container version, a consent management platform (CMP) updates its script, and an agency adds a pixel for a campaign. Each change can break tracking, and none of them waits for the next audit.

A one-off audit, or a QA pass before launch, answers a narrower question: was the implementation right at that moment, on the pages you tested? That question matters, and QA before publishing is still the cheapest place to catch an error. But the failures that cost the most are the ones that appear after the audit. The release that renames a data layer key. The checkout redesign that drops `transaction_id`. The CMP update that starts firing ad pixels before consent.

Those breaks are usually partial, which is why nobody notices them. The page still loads and the event still fires. For example, a `purchase` event keeps arriving in GA4 but its `value` parameter is empty on one payment method. Revenue reports drop slightly, the paid media team blames seasonality, and the bidding algorithms in Google Ads and Meta Ads learn from incomplete conversion values for weeks.

**Observability changes the default from "assume it works until someone complains" to "assume it breaks, and find out first."** It borrows the idea from software engineering: you watch the system continuously, compare it with a baseline and a specification, and alert on the difference.

There is a second distinction worth making. General data observability tools watch tables in the warehouse: freshness, volume, schema, lineage. Marketing data observability watches the collection layer: what the browser, the app and the server actually send to analytics and ad platforms. The warehouse view cannot see a pixel that fired without consent, and the collection view cannot see a broken dbt model. Most mature teams need to know which of the two problems they have.

## How to set up observability for marketing data

The order matters. A tool without a specification produces alerts nobody can judge, and alerts without an owner produce noise.

1.  **Write down what "correct" means.** The analytics lead owns this. The artifact is a tracking plan or a [solution design document](/what-is-a-solution-design-document-sdd-in-digital-analytics-the-complete-guide): every event, its required parameters, their types, where each one fires, and which destinations receive it. Without it, a monitor can only tell you that something changed, not whether the change is wrong.
    
2.  **Pick the signals to monitor, by layer.** Start with the events that feed money decisions: purchases, leads, sign-ups, and the parameters that bidding and reporting use. The table below is the minimum set.
    
3.  **Set baselines before thresholds.** Watch a few weeks of normal traffic before you decide what counts as an anomaly. Weekday patterns, campaign bursts and sales periods all move volume. A fixed threshold set on day one will either miss real breaks or fire every Monday.
    
4.  **Route every alert to one owner and one channel.** The artifact is a short routing table: alert type, owner, channel, expected response time. Tag and data layer breaks go to the analytics or development team. Pixel and conversion breaks go to paid media. Consent breaks go to whoever owns privacy, plus legal if your process requires it. An alert that goes to "the marketing channel" belongs to nobody.
    
5.  **Connect monitoring to the release process.** Ask development to share the release calendar, and check the key events after each deploy. If you have a staging environment, run the same checks there before the release ships. This turns observability from a detector into a gate.
    
6.  **Review the alerts monthly.** Remove monitors nobody acts on, tighten the ones that missed a real break, and update the tracking plan when the business adds an event. The artifact is a short incident log: what broke, when it was detected, when it was fixed, and who found it first.
    

### What to monitor in a marketing implementation

| Layer | What breaks | What to check |
| --- | --- | --- |
| Tags and pixels | A tag stops firing, fires twice, or fires on the wrong pages | Presence per page type, duplicates, new unknown vendors |
| Events | Volume drops or spikes; an event disappears after a release | Volume against baseline, by platform (web, iOS, Android) |
| Parameters and schema | Required parameters arrive empty, renamed or with the wrong type | Required fields, types, allowed values, new fields |
| Consent | Tags fire before consent, or ignore a refusal; Consent Mode signals are missing | Firing order against the consent state, by region |
| Campaign tagging | UTMs missing or malformed; click IDs stripped by redirects | UTM format against your convention, presence of click IDs on landing |
| Destinations | Conversions stop reaching an ad platform or the server-side container | Delivery per destination, server-side payloads, Meta Conversions API (CAPI) events |

## How to evaluate a data observability tool for marketing

The criteria come from what the tool has to do for the steps above. They apply to every vendor, including the one I work for.

-   **What it detects:** tags, events, parameters, consent, pixels, campaign tagging.
-   **When it detects:** before publishing, on a schedule, or continuously on live traffic.
-   **Coverage:** web, native apps, server-side.
-   **How it learns "correct":** from a specification you maintain, from rules you write, or by inferring a baseline from traffic.
-   **Alerting:** channels, routing by owner, and how it handles noise.
-   **Maintenance effort:** what someone has to update when the site or the tracking plan changes.
-   **Price model:** public or not, and what drives it.

**How I compared them.** I used the criteria above and grouped the tools by the job they do, not by preference. The data comes from each vendor's public website and documentation, read as of October 2026. I have not run a side-by-side test of these tools, so the weaknesses below are structural, not benchmark results.

### Continuous monitoring of live collection: Trackingplan

[Trackingplan](https://www.trackingplan.com/) says it monitors the requests that sites, apps and servers send to analytics and ad vendors, including the data layer, pixels, server-side payloads, consent signals and GTM releases. It says it is installed with a tag, an SDK or a server-side hook, and that it infers the schema from live traffic instead of requiring a tracking plan first. Alerts go to Slack, Teams, email, webhooks and an API, according to the vendor. Coverage includes web, iOS and Android apps, and server-side endpoints.

-   **Best for:** teams that ship often and want to detect breaks on real traffic across many destinations without writing rules for each one.
-   **Weaknesses:** an inferred baseline learns from what the site already sends, so an event that has always been wrong can look normal until someone defines the expected value. Monitoring live traffic detects a break after it reaches production, unless you also run it before release: its documentation describes running it on staging, development or any other environment, set in the install call, with each environment's data kept apart ([Trackingplan, environments](https://docs.trackingplan.com/environments)). There is no free plan, only a trial.
-   **Pricing (public, October 2026):** Starter from €89 a month (300k sessions), Growth from €699, Enterprise from €2,000 on an annual contract; priced by monitored sessions plus agent credits ([Trackingplan](https://www.trackingplan.com/pricing)).

### Scheduled audits and simulated journeys: ObservePoint

[ObservePoint](https://www.observepoint.com/) describes audits that scan pages for broken tags, unapproved cookies and privacy risks, and journeys that follow configured paths through a site. It also tests consent banners with configurable consent profiles and validates analytics from several vendors, according to its website as of October 2026. Its help center describes [alerts on audit rules](https://help.observepoint.com/en/articles/9090775-alerts-for-tag-and-variable-rules), with thresholds on rule failures.

-   **Best for:** teams that need documented, repeatable audits, especially for privacy and consent compliance across large sites.
-   **Weaknesses:** a scan or a simulated journey checks the paths you configured, not the traffic that real users generate, so breaks in untested flows can go unseen between runs. Audits and journeys can be scheduled from every few minutes to monthly ([ObservePoint, scheduling](https://help.observepoint.com/en/articles/10030129-data-source-scheduling-and-calendaring)), and app traffic is validated through a device proxy ([ObservePoint, mobile app validation](https://help.observepoint.com/en/articles/9106718-observepoint-applications-mobile-app-validation)), not from real users. Rules and journeys need someone to maintain them when the site changes.
-   **Pricing (October 2026):** not public; the pricing page offers a calculator and a sales contact ([ObservePoint](https://www.observepoint.com/pricing/)).

### Warehouse data observability: Monte Carlo and similar tools

General data observability tools such as [Monte Carlo](https://montecarlo.ai/platform/data-quality) watch the warehouse. Its documentation for [BigQuery](https://docs.getmontecarlo.com/docs/bigquery) describes automatic checks on freshness, volume and schema, with opt-in checks for distribution and field health, plus lineage across tables, as of October 2026.

-   **Best for:** analytics teams whose marketing reporting runs on BigQuery or Snowflake, where the risk is a broken pipeline or model rather than a broken tag.
-   **Weaknesses:** it starts where the data lands. It cannot see a pixel that fired before consent, a parameter that never left the browser, or a conversion that never reached Meta. Its documentation describes setup through warehouse metadata and permissions, which usually means a data engineering team owns it.
-   **Pricing (October 2026):** not public. Monte Carlo sells tiers (Start, Scale, Enterprise, Business Critical) paid in credits consumed by usage and by monitor ([Monte Carlo](https://montecarlo.ai/pricing)).

Many teams need two of these jobs covered, not one: collection-layer monitoring for what is sent, and warehouse monitoring for what is modeled. The broader landscape of [tools to detect implementation errors in GA4](/the-best-tools-to-detect-implementation-errors-and-audit-google-analytics-4-ga4), from browser extensions to scheduled audits, covers the manual end of the same spectrum.

## How you know observability is working

Three signals tell you more than the number of monitors.

-   **Who finds the break first.** In the incident log, count how often a break was found by an alert versus by a stakeholder looking at a dashboard. The second number should go down quarter over quarter.
-   **Time to detect and time to fix.** Measure both, from the release or change that caused the break. Detection should drop to hours. Fixing depends on the release cycle, but it should have an owner within a day.
-   **Alerts acted on.** If most alerts get no action, the thresholds are wrong or the routing is. Review them monthly and cut the ones nobody uses.

For a CMO, the question to ask the analytics team is short: "When did tracking last break, how did we find out, and how long did it take?" A team with observability answers with dates. A team without it answers with "I think it's fine."

## When this does not apply

-   **Small sites with few releases.** If the site changes twice a year and runs a handful of tags, a QA checklist before each change and a quarterly audit may be enough.
-   **No specification yet.** If nobody can say which events and parameters are expected, start with the tracking plan. Monitoring before that measures change, not correctness.
-   **Warehouse-first reporting with server-side collection you fully control.** If every event goes through your own pipeline, warehouse observability plus contract tests in that pipeline may cover most of the risk. Pixels and consent on the client still need a check.

## What to check this week

-   Pick your three most important conversion events and check whether every required parameter has arrived complete for the past 30 days.
-   Ask development for the last three release dates and look at those events on the day after each one.
-   Write the routing table: for tags, pixels and consent, name one owner and one channel each.

![](/images/about-me/davidpombar_profile.jpg)

Written by [David Pombar](/about-me). Lives in A Coruña, Galicia, and works at Trackingplan.