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: <funnel stage, trust level, product type — one line>
Candidate rule(s): <rule ID(s) + one-line lever>
Rejected rule(s) and why: <any contradicting rule ruled out, and the condition mismatch that ruled it out>
Structure → vois-patterns: <what's being handed off>
Copy → righter: <what's being handed off, plus the mechanism it needs to serve>
Instrumentation → metrics-tagging: <success metric + kill condition>

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.