A dashboard can continue to look perfectly normal
A Tracking anomaly does not necessarily break your site.
And that's exactly what makes it hard to spot.
An event no longer goes back to a part of the tunnel. A parameter disappears after a production run. A new path is deployed but is not collected as planned.
However, GA4, Piano or your home dashboard continues to show something.
The number is there.
The question is what is it still worth.
Behind a conversion rate, a turnover or an acquisition cost, there is a collection chain.
And as soon as a link in this chain changes, the KPI can change with it without the anomaly being immediately obvious.
This is where, for us, Tracking ceases to be only a technical subject.
Because as soon as this data is used to cut a campaign, move a budget or prioritize product evolution, the quality of Tracking becomes a condition of the decision.
A small technical anomaly can have a much wider scope.
Let's take a very simple case.
The value parameter no longer returns correctly to the purchase event.
For the person working on the tagging plan, the problem is clear: a parameter is missing.
But this parameter can feed behind:
- e-commerce turnover the
- average basket the average basket
- the conversion rate
- an attribution model
- a report presented to the Management
It is precisely for this reason that a purely technical alert seems incomplete to us.
Say,
“The value parameter is missing.”
it's useful.
But that is only the beginning of the response.
What we really want to know is: What does it change?
Go from “what broke?” to “what does that put at risk?”
For a long time, Tracking tools have mainly answered a technical question:
what tag, what event or what parameter no longer works?
It is essential.
But after years of working on these topics, we also know that this is not the question that helps to prioritize the most.
Two anomalies can be technically very similar and have completely different consequences.
A parameter that is not present on a secondary page.
And the same parameter was absent at the time of purchase.
On paper: two collection errors.
In reality: not at all the same urgency.
That's why we chose to link the elements of the tagging plan to the KPIs they feed.
The same incident can then be read on two levels.
Technical side: what event, parameter, or control failed?
On the business side: what KPI depends on this element, on what scope and since when?
The KPI becomes the other end of the chain: it allows you to know what you lose when an element of the plan breaks.
It is exactly this logic that structures Netvigie Tracking.
What it really means on a daily basis
A campaign suddenly shows a drop in conversion.
The first instinct may be to look at the auctions, the creations, the audience or the course.
Then someone ends up checking the collection.
The buying event is still going back.
But not everywhere.
On a part of the tunnel, a parameter disappeared after the last production run.
So the problem is not necessarily that the campaign is performing less well.
The problem may be that you are no longer measuring all of its performance.
And from there, the subject is no longer simply correcting a tag.
You need to know since when the data has been affected, what part of the journey is concerned and what KPIs are based on it.
This is the kind of situation that we have been encountering for years in Data Quality issues.
And it's also what prompted us to change our own way of presenting anomalies.
Detecting has never been the most difficult part.
After ten years of Data Quality, we always find the same limit:
detecting a discrepancy is not enough.
Fixing 50 mistakes doesn't help much if the team then has to spend an hour figuring out which one really deserves attention.
On Data Quality, you need to be able to quickly answer four questions:
- What? What event, parameter, or control is affected?
- Where? On which site, which page, which template or which course?
- Since when? When did the collection start to diverge?
- What KPI? Which indicator depends on the element in question?
This last piece of information completely changes how to prioritize.
An anomaly that threatens the conversion rate of the main tunnel is not treated as an error on a secondary element.
Even if, technically, both are Tracking anomalies.
Knowing since when the data is no longer reliable
This is another question that comes up almost systematically when an anomaly is discovered: since when?
Because discovering today that a KPI is affected does not yet say which reporting period to question.
At Netvigie, each alert keeps its first observation, its last failed observation and its resolution.
You therefore know over which period and on what precise perimeter the collection was affected.
This makes it possible to answer very concrete questions:
- Should we reprocess the data from the last few hours?
- Questioning a week of reporting?
- Correcting an attribution model?
- Warn a team that relied on these numbers to decide?
Without this information, doubt often ends up spreading to a lot more data than necessary.
A common reading for teams that do not have the same needs The same
anomaly does not tell the same story depending on who looks at it.
The developer is looking for the cause.
Data seeks reliability.
Marketing looks at the impact on its indicators.
Our role is to keep these readings in the same incident, without requiring each team to retranslate it on their own.
Because an incident must be able to be understood by the person who is going to correct it but also by the person who must decide if it deserves to be given priority.
Relating Tracking to what it is really used to control
It is this logic that we integrated into Netvigie Tracking: an anomaly should never be isolated from what it really puts at risk.
KPIs are directly linked to the events, parameters, and rules on which they depend.
So when a discrepancy occurs, you don't just see what broke.
You can also identify:
- the KPIs concerned
- the perimeter affected
- the moment when the gap started
- the technical elements at the origin of the problem
Tracking remains a technical subject.
But as soon as the data collected is used to arbitrate a campaign, a product or an investment, its quality becomes a subject of management.
This is probably one of the most important observations we have drawn from these years spent working on Data Quality:
Detecting the problem is necessary. Understanding what it really puts at risk is what makes it possible to take action.
And now?
Netvigie Tracking makes it possible to link your tagging plan to the KPIs that drive your activity and then to identify the indicators concerned when a discrepancy occurs.
Discover how Data Quality makes it possible to go from a technical anomaly to its real impact on your data.
