Offering drift
Offering drift is what happens to a tracked behavior when the product itself changes underneath it. A team adds a feature, renames a button, or restructures a flow; the event still fires and the number still moves, but what users are doing when they trigger it has shifted from what it meant when the team picked the metric.
Definition
A mechanism of correlation drift where the offering evolves — features added, removed, or reorganized — and a behavioral proxy's correlation with the commercial outcome shifts because the surface the threshold sits on has changed.
How the threshold's meaning shifts
A behavioral threshold is defined relative to the offering at a moment in time. "Created 3 projects," "followed 30 accounts," "completed checkout twice" — each names an observable action against a specific configuration of the offering. When the offering changes, what produces that observable action can change with it. The threshold keeps firing, the count keeps moving, but the user activity producing the firing has shifted. The proxy's correlation with the commercial outcome held under the prior configuration; under the new one, the same threshold reflects different user pursuits, and the prior correlation no longer holds.
The shift can be small or large. A new "quick-create" button can turn a previously-deliberate action into something effectively free. A reorganized feature hierarchy can move a threshold from intermediate-step territory into onboarding-step territory. Splitting a feature into two can mean the previous threshold no longer covers what it used to. None of these requires the team to retire the proxy — the proxy keeps computing exactly what it computes. The damage lives in what the firing now means.
Why some proxies hold
Offering drift attacks proxies internal to the offering's surface. A feature-usage event — a threshold inside the offering with no outcome outside the offering underneath it — is fully exposed: every feature change is a candidate for shifting its meaning. An external-impact event — a threshold whose completion advances the user's pursuit outside the offering — sits on different ground. "Sent an invoice" continues to mean the invoice did work for the user in the world beyond the offering, regardless of how the invoicing UI gets reorganized. The proxy's connection to user value lives outside the offering's surface and isn't sensitive to surface changes.
The proxy tiers are ordered the way they are for this reason. Outcome-tier proxies survive offering drift better because they're anchored to where the user's transition actually lands, not to internal arrangements the team will change.
Example
A team running activation on a project-management tool has scale-tested "created 3 projects in the first week" as a value milestone. The correlation with first paid conversion holds across two years of intervention work. The team then redesigns onboarding to include a "quick-start" flow that creates three sample projects with one click as part of account setup. Post-change, "3 projects" fires for nearly every signup. The threshold computes correctly; the count moves predictably. Before the change, hitting 3 projects signaled a user committing to set up three streams of work; after the change, it signals dismissing onboarding prompts. The same threshold tracks a meaningfully different user pursuit, and its correlation with first paid conversion comes apart.