A privacy change can make an analytics report smaller. It should not make the report feel haunted. When conversions appear and disappear erratically after Consent Mode is introduced, treating the volatility as the unavoidable price of compliance is an expensive mistake. The first suspect should be the implementation.

That distinction matters because a broken consent setup can poison two decisions at once. Marketing teams may distrust data that is behaving inconsistently, while technical teams may defend the inconsistency as normal data loss. Budget moves, campaign comparisons, and performance explanations then rest on a measurement layer nobody has actually proved is stable.

Missing data and unstable data are different problems

Consent denial removes some observable activity. In broad terms, that should create a lower or differently modelled view of performance. It does not explain why otherwise comparable days swing without a plausible business reason.

Choppiness points toward state and timing. The default consent state may be set after a Google tag begins loading. A consent update may fire inconsistently. A page transition may reset a value. Different tag types may not be reading the same state. The useful question is therefore whether the same consent choice produces the same tag behaviour every time—not simply whether tracking declined.

A bounded before-and-after report illustrates why this is easy to misread. After a custom Consent Mode implementation, GA4 and Semrush data reportedly became noticeably less consistent over roughly two weeks. Reverting to the previous plugin improved the picture, though not completely. That sequence does not establish responsibility for every change. It does justify treating the deployment as a measurement incident until the implementation is cleared.

Test the consent state before choosing a new dashboard story

A sensible audit starts before any trend analysis. Repeat the same journeys with consent granted and denied. Check the initial state before tags load, the update after a choice, persistence across navigation, and the requests actually sent—not merely what a tag-manager preview says should happen. Compare identical journeys rather than two noisy calendar periods.

Then separate three possible outcomes:

  • A stable reduction is compatible with changed consent and measurement boundaries.
  • A stable technical implementation with weaker totals may require a reporting and modelling decision.
  • Inconsistent state or requests are an engineering defect, not an analytics insight.

This is also why choosing a consent platform by feature checklist or popularity is weak procurement. A supported platform can reduce custom-code risk, but a familiar logo does not guarantee a correct deployment. Reliability depends on how it handles the site's actual tags, regions, navigation model, and consent categories. Custom HTML and unusual tag sequences can still create gaps inside a mainstream setup.

Compliance is not a tracking configuration

There is a tempting overcorrection here: once the implementation is stable, marketers may treat maximum measurable data as the goal. It is not. The legally appropriate consent design depends on the business, location, and obligations involved. Another company's tool choice is not legal guidance, and an analytics audit cannot decide which consent should be requested.

The marketing decision is narrower and more practical. Do not accept erratic reporting merely because consent is involved. Establish the required policy, implement it consistently, and then measure the resulting boundary. If the numbers shrink, plan around the honest limitation. If they jump around, fix the instrumentation before anyone uses them to explain performance. Privacy changes the amount of data you may observe. It does not excuse a measurement system that cannot repeat itself.