AARRR pirate metrics name five stages a user passes through: acquisition, activation, retention, referral and revenue. Dave McClure's model is still the most quoted growth funnel, and its appeal is that every stage reduces to a count or a ratio of two counts. That is also its weak point. Each stage rests on one or two events, so when one moves, the stage moves with it, and the chart cannot tell you which one changed.

How it works

Acquisition counts people arriving. Activation counts the share who reach a first moment of value, retention the share who come back, referral the ones who bring someone else, and revenue the ones who pay. McClure ordered the stages so that a team fixes the earliest leak first, because work on revenue is wasted while activation loses most of the people who arrive.

The model says nothing about how each count is produced. In practice every stage after acquisition is a ratio of two events, and the definitions sit across a tracking plan, an analytics tool and somebody's memory. Activation is the most fragile stage because it is the one teams redesign most often. A new onboarding flow changes which event means activated, and the old event can stop firing with nobody told.

What it assumes your events already do

Event	What the framework uses it for	What it reports when the event breaks
Acquisition source on signup `utm_source, referrer`	Splits acquisition by channel.	Signups lose their source, every channel looks equally weak, and spend is cut in the wrong place.
Activation or First Impact event `first_report_shared`	The numerator of the activation rate.	A renamed activation event reads as a collapse on release day, or as a jump if the new flow fires the old event for everyone.
Return visit `session_started`	Defines who counts as retained.	If the return event stops on one platform, retention falls for that platform and the chart blames the cohort.
Invite sent and accepted `invite_sent, invite_accepted`	The referral stage.	Invites from a new share button go uncounted, so referral looks flat while it grows.
Plan change `plan_changed`	The revenue stage.	Upgrades through a new billing page are missed, and funnel revenue drifts away from finance's revenue.

Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.

The week activation more than doubled

Illustrative example. The company and the figures are invented to show the mechanism.

A team ships a redesigned onboarding flow. The old flow fired project_created when a user finished setup. The new one creates a sample project automatically at signup, so project_created now fires for every user who reaches the dashboard, whether or not they did anything.

Activation jumps from 38% to 97% on release day, and the team celebrates for a week. When someone finally reads the event definition, the real figure for the new flow turns out to be lower than the old one. The jump was not a change in user behaviour. It was a change in what one event meant.

Checks before you trust it

Write down the exact event and properties behind each of the five stages, in one place, with an owner.
After any release that touches onboarding, compare the activation event's daily volume with signups before reading the rate.
Count users or accounts consistently across stages; mixing the two makes every ratio meaningless.
Treat a step change on release day as a tracking question before it is a product question.

What Dave Boyce adds in Freemium

Dave Boyce's Freemium builds on the same stages and makes one event carry more weight than the rest. In his PLG Bowtie, activation and what he calls First Impact come before any payment, so the First Impact event is the dependency nearly every later metric relies on. His setup advice is to name every step of the journey as an event, since nobody is in the room when a user activates (Ch 3 and Ch 11).

Heard in The Question

Interviews in The Question that bear on this framework:

Interview 01: the founder who uses product data to retire a recurring idea. Product data confirms or kills a hypothesis that people formed first, and the expensive gap is the number nobody collects.
Dino Repo: one metric, five numbers, and a ten-minute fix. Untrustworthy data is an ownership problem before it is a tooling problem, and the cheapest fix is a product-data check that runs every time the build loop turns.
John Adib: when agents read your analytics, event names break first. Once an agent rather than an analyst queries the analytics, ambiguous event names stop being hygiene and start producing wrong numbers in the business review.
The sponsor answers The Question: Teemu Kinos, cross-examined. Nobody wants to track things; they have questions, and the questions arrive while someone is using the product or talking to a user, never at development time.

Check the events under it

Before AARRR (pirate metrics) goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.