The Analytics Changes That Corrupt Your History Without Breaking Anything

A.Redefining what counts as a conversion

Somebody decides the signup conversion should fire on email confirmation rather than form submit. Reasonable, more accurate, and it puts a step change into a series that everybody will read as a performance drop.

Six months later a quarterly review compares against the period before the change and reaches a confident wrong conclusion. Nobody involved remembers the change, because it took ten minutes and did not break anything.

B.Renaming an event

The cleanest-looking change and one of the worst. Depending on the platform, renaming either splits the series in two or retroactively relabels history so the old name never existed.

Both are bad and the second is worse, because it removes the evidence that anything happened. Prefer creating the new name, running both briefly, and retiring the old one with a note.

C.Filters, which are the irreversible ones

The most destructive category, because in most analytics platforms filtered data is not collected rather than hidden. An over-broad internal-traffic filter does not conceal those sessions; they never arrive, and no amount of later correction recovers them.

An IP range that later gets reassigned to a co-working space, or a filter written against a staging domain that becomes a customer-facing one, deletes real traffic silently and permanently.

Test every filter against historical data before applying it, and check how much it would have removed. Anything above a couple of percent deserves a second pair of eyes. Related: the GA4 settings that decide whether your data is usable.

4.Session and attribution settings, and backfilled imports

Changing a session timeout or an attribution model rewrites how every historical figure is computed, often retroactively across the whole property. The numbers all move, nothing errors, and the reason is a setting nobody logged.

Backfilled imports are the fifth. Loading historical orders or replaying events to fix a gap is sometimes necessary and reliably produces a spike on the day of the import rather than on the dates the data belongs to, unless the timestamps are set explicitly. Half the time they are not.

A.Annotate in the tool, on the date

The single highest-value habit available, and it takes thirty seconds. Every definition, filter or setting change gets an annotation in the analytics property itself, dated to the day it landed.

Not in a document. In the tool, where the person reading the chart in eleven months is standing. A changelog in Notion is a changelog nobody opens while looking at a step change in a graph.

B.Never change a definition mid-quarter

If a change has to happen, land it on a period boundary. A series that shifts on 1 January is explicable. One that shifts on 14 February will be misread by somebody in every review for the next year.

Where the change is significant, run both definitions in parallel for a month. The overlap is what lets you state the ratio between old and new, which is the only thing that makes the two halves of the series comparable at all.

C.Reconcile monthly against something that cannot drift

Once a month, compare your primary conversion count against the billing system. It takes ten minutes and it is the only check that catches every category of corruption at once, including the ones nobody thought to look for.

A ratio that has been stable for six months and moves is a signal regardless of cause. The method is in what your analytics hides.

A.The realistic threat model

Analytics access tends to be all or nothing: view, or edit everything. So the marketer who needs to add a UTM exclusion has the same permissions as someone who could delete the property.

The realistic risk is not someone acting badly. It is a new hire tidying up event names in their first week because the list looked untidy, which is a defensible instinct and destroys a year of comparability.

The fix is mostly social: a short list of settings that require a second person, and somebody named as owning the schema. Access control helps where the platform offers it, and most of the protection is knowing who to ask.

B.Offboarding, which is where properties get orphaned

The unglamorous one. Properties created under a personal account, filters written by somebody who left, integrations authorised with an individual's credentials.

The failure arrives months later when an integration stops and nobody can re-authorise it. Audit ownership annually and move everything to shared credentials.

C.What an immutable event stream changes

Several of these are consequences of one design choice: platforms that let you reshape the meaning of already-collected data. Retroactive renames and recomputed attribution are only possible because the stored thing is interpreted rather than fixed.

Kissmetrics stores events as an immutable record of what happened, with properties fixed at the moment they were recorded. Reporting definitions can change, and the underlying history does not, so a redefinition changes the report going forward rather than rewriting what last March meant. There is also no filtering layer that discards data before storage, so the irreversible category above does not arise.

It does not protect you from the human half. Somebody can still redefine a conversion without telling anyone, and no product supplies the annotation.