Lifecycle Results — Closing the Loop

The engine generates journeys and KPIs; this skill reads what actually happened and feeds it back. It recommends — promotion, demotion, and deletion are always the user's call. Doctrine: ${CLAUDE_PLUGIN_ROOT}/knowledge/measurement.md — every rule there binds this skill.

When NOT to use this

• No performance data exists yet — the journey hasn't launched, or has launched but no measurement window has closed — there's nothing to ingest; using this skill early just returns "insufficient data" against every journey instead of a real verdict.
• The ask is whether the CRM setup fires correctly BEFORE launch — that's lifecycle-qa (trigger correctness), not this skill (outcome measurement after real users have gone through it).
• The ask is a structural or methodological review of a journey's design — that's lifecycle-audit. This skill evaluates measured outcomes against the incrementality doctrine; it doesn't review the design itself.

Step 1 — Ingest

Accept results in any form the user has: CSV export, pasted table, or plain description. Per journey, collect what exists:

• entered / exposed / control counts, conversions per group, window covered
• per-step diagnostics (opens, clicks, unsubscribes) if available
• which copy variant ran (A/B) and its strategy/hypothesis labels from the copy output

Missing fields are recorded as missing — never interpolated.

Pull instead of paste, when the data allows it. If a GA4 connection is live (the same MCP lifecycle-connect uses) and holdout membership is recorded in GA4 — a user property or event param such as lifecycle_group = control|exposed, plus the journey id — pull entered/control counts and conversions per group with run_custom_report over the journey's measurement window, instead of asking the user to paste them. State the report's date range and dimensions in the output so the numbers are reproducible. If either condition is missing, ask for the export as above, and add one tracking-plan item: "record holdout group as a GA4 user property", since that single change is what turns every future results run from a paste into a pull. The CRM stays the source of truth for who was sent what; this only reads outcomes, it never writes anywhere.

Step 2 — Validate before judging (the gate)

Apply measurement.md's honesty rules before any verdict:

1. Sample size: control group below ~200 conversions → verdict is capped at "insufficient data — extend window / reduce holdout / keep running", regardless of how bad the lift looks. Zero lift on an underpowered test means unmeasured, not failed.
2. Window: results read before the journey family's measurement window closed (recovery 1–7d, activation 7–14d, winback 30–90d) are provisional.
3. Contamination check: ask whether holdout users could have been reached by an overlapping journey (portfolio conflict review names the overlaps).
4. External factors: price changes, PR spikes, seasonal peak (playbook Seasonality section) — flag if the window overlaps one; attributed numbers inflate on elevated baselines.

Step 3 — Verdict per journey

For journeys that pass the gate, compute lift and iROI per measurement.md and recommend exactly one of:

Materiality, not just direction, gates "keep". "Positive lift, iROI ≥ 0" is a direction check, not a size check — a lift of +0.1% with iROI barely above zero is statistically a win and economically noise. Before a keep verdict, state the lift's practical materiality against the brand's own sense of a meaningful move (or, absent one, iROI comfortably above zero, not just non-negative). A positive-but-trivial result is still reported honestly — never demoted to "insufficient data," it was measured — but labeled keep — marginal rather than a plain keep, so a later portfolio review doesn't read it as equivalent to a strong win.

An underpowered result with a large observed effect is not the same finding as an underpowered result with a small one, even though Step 2's sample-size gate caps both at "insufficient data." When the observed lift is large (well above the MDE the test was sized for) but the gate hasn't cleared, say so explicitly — insufficient data, but observed effect is large (+8%) — worth extending the window before assuming null — rather than the generic caveat alone. This doesn't change the verdict (the gate still holds; a promising underpowered result is not a "keep"), but it changes what gets prioritized for a follow-up run, which is exactly what keeps a real signal from being deprioritized the same way as a flat one. (The failed-strategies log already excludes underpowered results by construction — Step 4 logs only powered failures — so this distinction is about follow-up prioritization, not a log-correctness issue.)

Guardrail breaches (unsubscribe/complaint over ceiling) override everything — recommend pause even on positive lift.

Before a demote/kill verdict on borderline or zero overall lift: check whether lift holds in any major segment the data supports (RFM tier, acquisition channel, platform, and trigger context — the journey's first-instance vs repeat-instance entrants behave differently, and pooling them can hide a real win in one). A real win in one segment can cancel against a loss in another and read as "no difference" in aggregate. Segment-level groups are smaller than the overall test by definition, so the sample-size gate (Step 2, rule 1) applies per segment too — a segment split that's itself underpowered is a lead worth naming for a future test, not grounds to override an already-clear overall kill.

Step 4 — Write the memory

Three files under output/<brand>/ (gitignored; linked from the brand config):

1. results-log.md — append one row per verdict: date, journey id, window, exposed/control, lift, iROI, verdict, decision taken by user.
2. failed-strategies.md — append an entry for (a) powered failures (sample-size gate passed, lift negative/zero) or (b) guardrail-class absolute signals (complaint, suppression trigger, unsubscribe spike) which are exempt from the sample gate but must be labeled guardrail-class with the n stated honestly. Format: segment | journey/pattern | strategy label (from copy metadata) | what failed | evidence class | status. This is a do-not-repropose list: lifecycle-journeys and copy-writer must check it and not offer the same strategy to the same segment again. Entries carry evidence so a human can overrule; the log recommends, it doesn't legislate.
3. winning-strategies.md — the positive counterpart: append an entry when a hypothesis is confirmed (a keep/promote verdict where the copy metadata's hypothesis held, or a fix-copy verdict's surviving sibling variant clearly won). Same format as failed-strategies: segment | journey/pattern | strategy label (from copy metadata) | what worked | evidence class | status. This is a prefer-this-precedent list, not a do-only-this list — copy-writer treats a matching entry as a starting-point hint for one variant, never as a reason to stop testing genuinely different angles for the other.

Step 5 — Feed forward

• Tell the user which blocked journeys/depth upgrades the results now justify prioritizing (tracking plan cross-reference).
• If a hypothesis from the copy metadata was confirmed/refuted, say so explicitly — that is the entire point of labeling variants with hypotheses.

Never do

• Never auto-demote or auto-delete — recommend with evidence, the user decides.
• Never judge an underpowered test (gate rule 1) or edit sector playbooks/lexicons based on one account's results.
• Never prescribe a fix without naming the layer the diagnostics indict: strong clicks + weak conversions usually indicts the surface AFTER the message (landing page, checkout, form) — rewriting copy for a downstream funnel problem is the wrong surgery. Strong opens + weak clicks → content/CTA; weak opens → subject/timing/list.
• Never read a diagnostic (open rate) as a primary result — a great open rate on zero lift is a well-performing message inside a worthless journey.
• Never let the failed-strategies log silently veto without saying so — when the engine skips a strategy because of the log, it states which entry caused the skip.