Inconsistent event names prevent joining data across versions

What it is

Comparing versions requires that the same name point at the same trigger and the same properties across time. Renames, splits, changing a property from a string to an enum, or keeping an old name while changing its meaning all make a name-joined series concatenate two different things. Apparent breaks or sudden improvements are then dictionary changes. This is not the same gap as never logging the event: the rows exist, they just cannot be summed as one metric.

Why it happens

Queries align on string keys. A warehouse does not know that click_buy and purchase_tap are synonyms, nor that view once fired on page open and later only after first paint. More hidden is an unchanged name with a changed predicate: test accounts filtered out, login now required, or one swipe split into start and end. When series are merged, numerator and denominator change definition on an unknown date, and the version contrast absorbs semantic drift. Without a versioned event dictionary the drift is invisible and shows up only as “the data changed.”

Studying it

Give each event an immutable identifier, a human name, a trigger predicate, a property schema, and an effective version. When the predicate or the name changes, mint a new identifier, deprecate the old one, and record in a mapping table whether and how they translate. Before a version comparison, align schemas: do same-named events still share trigger and required properties; if not, keep two series. Spot-check raw examples around the rename window to confirm the mapping did not stack two actions into one count.

Where it stops holding

Display-only aliases on a dashboard do not break joins if the underlying identifier is stable. Traffic-mix changes from experiments or feature flags are not a naming problem and should be handled separately. When a third-party SDK renames events on its own, the product may be unable to keep the old identifier, and cross-version claims should drop to segmented description. Freezing names forever also blocks needed clarification; the requirement is a bridge when changing, not immortality.

Applying it

• Never reuse a production event name for a new meaning; ship a new name and a deprecation date.
• Footnote every definition change on the dashboard and cut the series that day rather than drawing one continuous line.
• In code review, require event strings to be defined in one place so client and server do not invent near-synonyms.
• Anyone comparing versions receives a mapping table first; names not on the table must not be “close enough” to sum.

Related

• Same group: Q3.11.1 Logs record behavior but not motive · Q3.11.2 Instrumentation design determines which questions can later be answered · Q3.11.3 Missing events cannot be backfilled after the fact · Q3.11.5 Sampling and dropped reports systematically undercount rare actions · Q3.11.6 Ad blockers and privacy settings permanently omit some users · Q3.11.7 The same event may fire under unequal conditions across platforms
• Adjacent: Q6.12 Ongoing tracking and alerting · Q3.18 Experimental design and controls
• Search terms: event-name semantic drift · analytics schema versioning · event dictionary