External-impact event
An external-impact event is something recorded in the product's own analytics whose significance lies outside the product: an invoice sent, a commit shipped, a post published. It's measured like any other in-app event, and what distinguishes it is that the action does work in the user's world past the product's surface.
Definition
A behavioral proxy keyed to impact-differentiated activity — an event in the provider's own instrumentation whose significance is an effect outside the offering.
External effect, internal measurement
The tier is named for where the event's significance lives, not where the event is recorded. Instrumentation stays inside the product: the provider logs a click, a send, a publish, exactly as they would log any other action. What distinguishes the event is that the action's point is something that happens elsewhere — an invoice arrives in a client's inbox, a commit lands in a repository, a post reaches an audience.
That outward effect is theorized rather than observed. The provider records that the invoice was sent; whether it moved the user toward their sought state is an inference from the nature of the action. Some outward effects are trackable — a payment coming back, an open receipt — but tracking them still doesn't establish that the user's intent advanced. The tier requires no instrumentation outside the offering and gets no confirmation from any that exists.
Who fires the event
The event doesn't have to be performed by the user being measured. What qualifies an event for this tier is its relation to that user's pursuit. An invoice marked paid when the user's client completes payment is an external-impact event for the user who sent it. A meeting booked on a scheduling link is an external-impact event for the link's owner, even though the invitee did the booking.
This is the same property that makes these events strong double proxies: the source of the event is irrelevant, and its bearing on what the user came for is what counts.
Why this tier is most reliable
External-impact events carry the highest intent-based explanatory power of the three tiers, because the behavior is progress aligned to what the user is pursuing — conditional on the intent being diagnosed correctly. When a team knows why the event correlates with conversion, interventions built on it act on a mechanism rather than a bare correlation.
They're also durable against product change. What the event is keyed to sits outside the offering's surface, so redesigns, renames, and navigation changes don't disturb the relationship the way they disturb a feature-usage event. The behavior is tied to the user's sought state rather than to the offering's internal structure, which is why candidates at this tier tend to survive scale verification more often than candidates at the feature-usage or engagement tiers.
The tiers are predictive heuristics rather than definitional gates. An external-impact event can still fail verification, and a feature-usage event can still hold. The tier tells you where to look first, not what you'll find.
Example
An invoicing tool instruments "sent an invoice." The send is recorded in the provider's analytics like any other button press, but the invoice itself leaves the product and does the work the user signed up for: it asks a client for money. A user who sends one has done the thing they came to do, and the provider can check whether senders reach first paid conversion at a higher rate than the rest of the signup cohort.
Compare "opened the invoice editor." Both events are logged the same way and both live inside the product. The editor open indicates the user found a feature; the send indicates the user's client is now being asked to pay. Only one of those has an effect the user would care about if the product disappeared the next day.