Feature-usage event
A feature-usage event is a metric that counts whether someone did a particular thing inside the product, like creating three projects, following thirty accounts, or adding seven friends in their first ten days, and treats hitting that number as the sign the product worked.
Definition
Feature-usage event
A behavioral proxy keyed to feature-differentiated activity — which in-app feature a user engaged, and how many times — used as a stand-in for first paid conversion or another commercial outcome.
What the event is keyed to
What separates users who fire a feature-usage event from users who don't is which part of the product they touched. "Created 3 projects." Facebook's "7 friends in 10 days." Twitter's "follow 30." The structural shape is the same as any behavioral proxy — a binary or a count over an observable action — and what makes it this tier is that the action lives entirely on the offering's surface.
That places it between the two neighboring tiers. Engagement events are keyed to undifferentiated activity, meaning presence alone. External-impact events are keyed to actions whose significance is an effect outside the offering. Feature usage differentiates more than presence and less than outward effect.
Where the correlation comes from
The behavior is available to everyone in the signup cohort. Nothing in the product stops a user from creating three projects; the feature is right there. So when converters create three projects at a higher rate than non-converters, what distinguishes the two groups is the intent that led some of them to the feature, not the act of using it. The correlation is real and the explanatory power is severely diluted, because the thing doing the predicting sits upstream of the thing being measured.
What happens under intervention
Teams treat the correlation as a lever and try to raise the rate — an onboarding checklist, a prompt, a preloaded default. The lift usually works: the share of users who create three projects goes up. The conversion rate doesn't follow, because the intervention produced the behavior in users who never had the intent that made the behavior predictive. Accumulated hold failures across diverse interventions is the operational signature of proxy failure, and this tier is where it happens most.
The tier is a heuristic
Tier membership predicts survival rates through scale verification rather than settling the question in advance. A feature-usage candidate that lifts and holds across multiple interventions is a verified lever regardless of tier. What the tier tells you is where to spend generation effort: candidate behaviors sourced at the external-impact tier survive verification more reliably, so starting there costs less than working through the feature-usage tier first.
Example
Twitter's "follow 30 accounts" is the canonical case. In the folklore version, the number reads as an external-impact event wearing feature-usage clothes — a user who organically followed 30 accounts that mattered to them had assembled a feed worth returning to, and the assembled feed is the outward effect. Twitter's onboarding later preloaded 30 celebrity accounts behind a select-all checkbox, which produced the count without necessarily producing the feed. What survives from the case isn't a verified proxy failure — nobody outside Twitter knows what else was tried — but the general shape: optimizing a proxy without knowing what drives the correlation hits the number and misses what the number was standing in for.