--- name: activation-design description: "Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'." status: active tier: senior source: package domain: product context_spine: [product, customer-segment, funnel-stage] workspaces: - product packs: - product-discovery lifecycle: active trust: level: professional confidence: high human_review_required: false install: default: false removable: true --- # activation-design ## When to use - The activation event is *"signed up"* or *"logged in"* and the funnel looks healthy while retention sinks — the event does not correlate with paid or D30, so the metric is a vanity surface. - A new segment is being routed against an activation event built for a previous segment — the aha moment differs by segment and the metric needs to be re-keyed. - A product loop redesign needs activation to complete the loop's first cycle (handover from `retention-loops`) — the activation event must match the binding loop's first reward, not an arbitrary product step. Do NOT use to design the day-0-to-day-30 milestone path (route to `onboarding-design`), the long-running retention loops themselves (route to `retention-loops`), or the full visitor-to-paid funnel diagnosis (route to `funnel-analysis`). ## Cognition cluster - **Mental model 9 — Hypothesis-driven thinking.** *"Event E is the activation moment because users who reach E retain at \ vs \"* is a falsifiable claim with evidence. *"E feels important"* is not. Pick the event that survives the hypothesis test. See [`docs/contracts/mental-models.md`](../../../docs/contracts/mental-models.md) § 9. - **Mental model 16 — Leading vs. lagging indicators.** Paid is lagging; the activation event must be leading — observable *before* the user has paid, and correlated with the lagging outcome. An activation event that is itself lagging cannot drive a decision in time. See `mental-models.md` § 16. - **Mental model 13 — Occam's razor.** When candidate events compete, the simpler one (single observable action) wins if it correlates as well as a composite. Composite events hide noise behind apparent precision. See `mental-models.md` § 13. - **Context-spine — product + customer-segment + funnel-stage.** Read the **product** slot for what counts as a *meaningful buyer action* in-product (the action must be observable in instrumentation), the **customer-segment** slot for the segment's switch-event (the aha moment is the segment's job done once), and the **funnel-stage** slot for activation's position relative to signup and paid. See [`context-spine`](../../../docs/contracts/context-spine.md). ## Procedure ### Step 0: Inspect — name the current activation event and its correlation Inspect the existing definition. **Verify** by computing correlation between the event and paid conversion / D30 retention on the trailing four cohorts. If r < 0.4 with paid, the event is mis-defined; if r > 0.4 but the event is downstream of paid, it is lagging and useless for in-funnel decisions. ### Step 1: Generate three candidate activation events Each candidate is one observable user action that: 1. **Is in-product, in-instrumentation, in-segment-shape.** No surveys, no proxies, no inferences from secondary signals. 2. **Sits upstream of paid in the funnel.** Activation that requires paid is a retention metric, not an activation metric. 3. **Maps to the segment's switch-event.** The candidate is the segment's *"job done once"* — not the vendor's vision of value. ### Step 2: Compute correlation per candidate For each candidate, compute on the trailing four cohorts: 1. **Correlation with paid conversion** (point-biserial r). 2. **Correlation with D30 retention** among paid users. 3. **Coverage** — what fraction of paid users ever fire the event? A candidate with high r and low coverage is a niche aha, not the segment's aha. The candidate that maximises (r-paid × r-retention × coverage) is the binding event. **Verify** it passes the simplicity check (Occam): if a composite event wins by < 10 % over a simpler single-action event, pick the simpler one. ### Step 3: Lock the falsifiable definition Write: *"For \, activation = \ within \ after signup."* The time-to-event window is the median time from signup to event among activated, retained users — not an aspiration. The window is part of the definition; events outside the window do not count. ### Step 4: Hand back to onboarding and retention The activation event is the **target** of onboarding milestones (route to `onboarding-design` for the milestone path that ends at this event) and the **first cycle** of the binding retention loop (route to `retention-loops` for the loop that begins from this event). Activation work without these two handoffs is metric theatre. ### Step 5: Run the recheck every quarter Each quarter, recompute the correlation on the latest four cohorts. Segment shape, pricing, or packaging shifts can move the aha moment by one step. **Verify** the binding event still maximises r × coverage; if a new candidate now wins, propose a redefinition, do not silently switch the event mid-quarter. ## Related Skills **WHEN to use this** - Defining or auditing the activation event for a segment. - Verifying correlation with paid / D30 against alternatives. **WHEN NOT to use this** - Designing the days 0–30 milestone path itself — route to [`onboarding-design`](../onboarding-design/SKILL.md). - Designing the retention loops that begin at activation — route to [`retention-loops`](../retention-loops/SKILL.md). - Full visitor → paid funnel diagnosis — route to [`funnel-analysis`](../funnel-analysis/SKILL.md). ## When the agent should load this - "What is our aha moment?" - "Redefine activation for the mid-market segment." - "Does our activation event actually correlate with paid?" - "Welches Event ist der echte Aha-Moment?" ## Output 1. **`activation-definition.md`** — segment · observable action · time-to-event window · trailing-cohort correlation with paid and D30 · coverage. 2. **`candidates-shortlist.md`** — three candidate events scored by r-paid × r-retention × coverage; simplicity check noted. 3. **`recheck-cadence.md`** — quarterly recheck plan: which cohorts feed the recompute · what would force a redefinition · who owns it. ## Gotcha - An activation event that does not correlate with paid is a vanity event; the funnel looks fine while D30 keeps falling. Correlation comes before celebration. - *"Composite"* activation events that combine three actions hide noise behind apparent precision; the simpler single-action event usually carries the segment's switch-event better. - Switching the activation event mid-quarter without an A/B holdout destroys longitudinal comparison; propose a redefinition between quarters, with the recompute as evidence. ## Do NOT - Do NOT pick activation by vendor narrative or pitch deck; the event must be observable in-product and falsifiable against retention. - Do NOT define activation as something that requires paid status; activation is the leading event, paid is the lagging event. - Do NOT use an industry-standard activation event ("first dashboard viewed", "first integration") without verifying segment correlation; segment shape dominates the choice. ## Runnable example B2B mid-market analytics tool, current activation = *"user viewed dashboard"*, D30 retention 58 % despite activation rate 71 %. - Step 0 inspect — *"viewed dashboard"* correlation with D30 paid retention r = 0.18; activation is decoupled from outcome. Flagged for redefinition. - Step 1 candidates — *(C1)* connected one data source + rendered one dashboard (single action chain); *(C2)* saved one query; *(C3)* shared one dashboard with one teammate (network proxy). - Step 2 scores — C1: r-paid 0.54 · r-retention 0.61 · coverage 0.78. C2: r-paid 0.34. C3: r-paid 0.41 · coverage 0.22 (niche). Winner: C1. Simplicity check: passes (single action chain). - Step 3 definition — *"Mid-market activation = first data source connected and first dashboard rendered, within 24 hours of signup."* - Hand-off — onboarding milestone path retargeted at C1 (`onboarding-design`); retention loop L1 from `retention-loops` begins at C1's first cycle. Quarterly recheck owned by RevOps.