--- name: conversion-patterns version: 1.0.0 author: Personify Labs description: Condition-gated paywall, checkout, retention, referral, and monetization-awareness patterns sourced from published A/B test case studies (abtest.design / Mobbin). Routes structure to vois-patterns, copy to righter, and instrumentation to metrics-tagging. Use when a ticket touches paywalls, trials, checkout, upsells, streaks/habit loops, or referral flows. Not a rulebook — every entry is a single validated hypothesis, not a universal law. --- # conversion-patterns ## What this skill actually is Every rule in `data/conversion-rules.json` is a real, published result — but each one is a single case study from one company, on one audience, at one funnel stage. None of them are controlled multi-trial findings, and the source only publishes winners, never the losing variants. Several of the rules in this file directly contradict each other (require a credit card vs. remove all friction; gate the paywall immediately vs. let users taste the product first) because they assume opposite starting conditions, not because one is right and one is wrong. **This skill's job is not to hand you a lever. It's to force you to name your condition before you're allowed to pick one.** If you skip the condition-check and just grab the highest-lift rule, you're using this skill wrong. ## When this skill triggers Use this skill whenever a ticket touches: paywalls, trial structure or length, checkout flow, cart abandonment, upsell/upgrade prompts, streaks or habit loops, referral flows, or pricing-page/CTA display. If the ticket is about onboarding sequencing instead, that's `onboarding-flow`'s job, not this one — check there first if you're not sure which one owns the ticket. For pricing pages specifically, `vois-patterns` (PATH-F, `references/pricing-pages.md`) owns layout and structure. This skill owns the test-backed levers: whether to show a billing timeline, how to frame the CTA, whether to gate immediately. Use both: structure from vois-patterns, levers from here. ## Mode 1: Diagnose a Ticket (new feature or screen being planned) Before touching `data/conversion-rules.json`, answer these against the actual ticket: 1. **Funnel stage** — is the user a cold visitor, an engaged free user, a paying user about to lapse, or a referred user? (This alone rules out most of the contradicting pairs.) 2. **Trust/intent level already present** — has the user already decided to act (picked a plan, added to cart) or are they still evaluating? 3. **Product type** — is the value experiential (needs to be used/tasted to be believed) or legible up front (obvious from a screenshot or description)? 4. **Is this actually a bug?** — before reaching for a psychological lever, check CHECKOUT-07 and RETENTION-04's `check_first` flag: rule out that the current flow is just broken or confusing. 5. **What would disprove this?** — every rule you pick needs a metric that would show it failed, not just one that would show it worked. Then: - Filter `data/conversion-rules.json` by category and condition match. Surface only rules whose `condition` field actually matches what you found in steps 1-3. - If two candidate rules appear in each other's `contradicts` list, that's a sign you haven't pinned the condition down yet — go back to step 1-2, don't average the two. - Hand the picked lever's structural implications (placement, gating type, modal vs. full-screen) to **vois-patterns**. - Hand the picked lever's copy implications (framing, tone, badge text) to **righter**, along with the `mechanism` field so righter is writing copy in service of a specific effect, not generic UI text. - Always close with **metrics-tagging**: whatever lever is shipped gets tagged as an experiment with a defined success metric and a defined kill condition, not shipped as settled fact. This step is mandatory, not optional — the case studies in this file only became "proven" because someone measured them in their own context, and yours is the only context that counts for your product. ## Mode 2: Audit an Existing Screen Use when reviewing something already built, not proposing something new. 1. Identify which rule(s), if any, the current design already resembles. 2. Check whether the *condition* for that rule actually holds for this product/audience — flag mismatches explicitly (e.g. "this screen gates immediately like PAYWALL-05, but the product's value isn't legible without hands-on use, which is PAYWALL-05's stated failure condition"). 3. If the design doesn't match any rule and conversion is a known problem, run Mode 1 against it as if it were a new ticket. 4. Output a short table: current pattern → matching/mismatched rule ID → recommended test, not a redesign. This skill proposes experiments, it doesn't declare winners. ## Output format Both modes end in the same shape: ``` Condition: Candidate rule(s): Rejected rule(s) and why: Structure → vois-patterns: Copy → righter: Instrumentation → metrics-tagging: ``` ## Rule index (quick reference — full detail lives in the JSON) **Paywall:** PAYWALL-01 billing timeline · PAYWALL-02 trial tied to annual · PAYWALL-03 single-tap gain-framed start · PAYWALL-04 yearly-only default · PAYWALL-05 immediate paywall · PAYWALL-06 vivid cost-of-inaction · PAYWALL-07 credit-card-required trial · PAYWALL-08 taste-before-gate · PAYWALL-09 pre-expiry reminder · PAYWALL-10 badge/framing on unchanged offer · PAYWALL-11 review over marketing copy · PAYWALL-12 identity-tuned visuals/copy **Checkout:** CHECKOUT-01 remove mandatory account creation · CHECKOUT-02 single point-estimate price · CHECKOUT-03 restate incentive at decision point · CHECKOUT-04 benefit copy/reviews above the fold · CHECKOUT-05 countdown discount for cart abandoners · CHECKOUT-06 values/storytelling panel · CHECKOUT-07 (check_first) rule out a plain bug before testing a lever **Retention:** RETENTION-01 decouple streak from full goal · RETENTION-02 ambient social proof mid-use · RETENTION-03 concrete per-item numbers over aggregate · RETENTION-04 (check_first) test icon/interaction choices against your own audience **Referral:** REFERRAL-01 real-time referral progress · REFERRAL-02 longer trial for referred users **Monetization awareness:** MONETIZE-01 badges on gated features · MONETIZE-02 gate what power users already hit **CTA / pricing display:** CTA-01 reframe CTA toward trial value · CTA-02 monthly-equivalent price · CTA-03 distinctive button in a crowded layout · CTA-04 contrast + emphasis across pricing tiers · CTA-05 (check_first) "simplify" is not a guaranteed win ## Rule data `data/conversion-rules.json` is the single source of truth. Categories: `paywall`, `checkout`, `retention`, `referral`, `monetization-awareness`, `cta-pricing`. Each rule has `lever`, `mechanism`, `condition`, `evidence`, `routes_to`, and `contradicts`. A `check_first: true` flag means this rule is a caution/verification step, not a lever to apply — always check it before applying anything else in its category. Run `scripts/check-rule-sync.mjs` after any edit to this file or the JSON — it verifies every rule ID mentioned here exists in the JSON and vice versa, matching the consistency-check convention used in `onboarding-flow` and the Righter/Vois skills.