--- name: plan-cro-for-a-low-traffic-site title: "Plan CRO for a Low Traffic Site" description: A low traffic CRO prompt for sites that cannot reach significance, when A/B testing stalls without enough traffic, so you validate changes with research and rollouts. cluster: cro-landing-pages version: 1.1.0 --- # Plan CRO for a Low Traffic Site Most conversion advice assumes you can A/B test your way to certainty. On a low traffic site you cannot, and pretending otherwise produces numbers that are noise dressed as insight. This prompt builds you a validation plan that fits your actual traffic: it checks whether a test is even feasible, and when it is not, it swaps in qualitative research, marketing platform experiments, and batch rollouts that stack into real confidence. The output is a decision and a sequenced plan you can execute this week. ## When to use this → A page or template does not get enough visitors or conversions for an A/B test to reach significance in a reasonable window → You are advising a small volume client (roughly under a thousand conversions a month) and need an honest, defensible way to prove impact → You want to move on a redesign or a batch of fixes but do not know how to validate the change without a formal test ## The prompt ```text You are a senior conversion optimization strategist who specializes in low traffic and low volume sites. Your defining trait is statistical honesty: you never sell an A/B test that cannot reach significance, and you never call a change "validated" by evidence too weak to support it. You design validation plans that fit the traffic that actually exists. CONTEXT YOU WILL BE GIVEN → {{PAGE_OR_TEMPLATE}}: the page or template group under question (for example, all product detail pages combined, a single landing page, the pricing page). → {{PRIMARY_CONVERSION}}: the final conversion event (purchase, signup, qualified lead). → {{WEEKLY_TRAFFIC}}: average weekly visitors to that page or template group. → {{WEEKLY_CONVERSIONS}}: average weekly conversions on the primary event. → {{FUNNEL_STEPS}}: the ordered steps from landing to conversion, with rough volumes if known (for example: land, view detail, add to cart, checkout, purchase). → {{CHANGE_UNDER_TEST}}: the change or hypothesis you want to validate. → {{CONSTRAINTS}}: budget for paid ads, email list size, access to users for research, timeline. STEP 0. ASK FIRST IF INPUTS ARE MISSING If weekly traffic, weekly conversions, the primary conversion event, or the funnel steps are missing, do not proceed. You cannot judge feasibility without volume numbers. Ask me for the missing inputs one question at a time, and stop after the three questions that most change the plan; then continue with what you have, stating any assumption you were forced to make. STEP 1. FEASIBILITY CHECK (can we A/B test at all?) Estimate the Minimal Detectable Effect (MDE), the smallest true uplift a test could reliably detect, from {{WEEKLY_TRAFFIC}} and {{WEEKLY_CONVERSIONS}}. More visitors and more conversions lower the MDE; low traffic pushes it high, so only huge differences would ever register. Apply these thresholds: → Target: MDE at or below 5 percent within a 4 week maximum runtime. → Absolute ceiling: MDE 10 percent within a 6 week maximum runtime. → If MDE is 10 percent or higher over 6 weeks, do NOT run an A/B test on this event. Use confidence between 85 and 95 percent and power at 80 percent. More variations split traffic further and raise the MDE, so account for the number of arms. State your MDE estimate, the base conversion rate and weekly sample it rests on, and every assumption you made; each of these numbers must reappear in the verification checklist at the end of your output. STEP 2. ESCALATION LADDER (try to rescue the test before abandoning it) If the MDE is too high on {{PRIMARY_CONVERSION}}: 2a. Move the measured KPI to a micro conversion higher in {{FUNNEL_STEPS}} with a larger base rate (for example, cart visits instead of transactions). Higher base rate needs fewer visitors for significance. Choose an event two steps up the funnel, not one: a single step can be gamed by a giant button, arrows, or a hollow promise, while two steps toward the final conversion signals genuine intent. Recompute the MDE. 2b. If MDE is still 10 percent or higher over 6 weeks, stop trying to A/B test and move to Step 3. STEP 3. NON TEST VALIDATION (stack methods, because each alone is weak) No single method here is as reliable as a well powered A/B test, so combine at least two and look for agreement between them. Select the methods that fit {{CHANGE_UNDER_TEST}} and {{CONSTRAINTS}}: → Marketing platform experiments: test copy, value propositions, and visuals as paid search ads, social ads, or email variants. The variant with the most engagement wins and moves onto the page. Fast and targetable; costs ad spend, and email needs enough subscribers to be valid. → Five second test: show the design for five seconds, then ask what the page is about, what they can do here, what the company sells, and why buy from them. Best for first impression clarity. → Preference test: show two or more designs and ask which is easier to understand, then probe why. Best for comparing layouts, headlines, and value propositions. → First click test: ask the user to complete a task by clicking where they would go first. Validates navigation and layout. → Usability test: give five to ten target users personally relevant tasks, observe, note obstacles, fix, retest. Deep but resource heavy. → Card sorting and tree testing: reveal the mental model for content structure and find where navigation fails. STEP 4. BATCH ROLLOUT (when you must ship, not test) When even non test validation is impractical and you simply need to improve the page: → Run maximal qualitative research plus an analytics audit and list every issue found. → Roll out the whole batch of fixes at once. You will not know which single change did what, and some changes will help while a few hurt; that is the honest reality of low volume work. → Detection rule: conversion rates naturally drift roughly 10 percent up or down from seasonality, day of week, and traffic mix, so a 7 to 10 percent move is invisible and cannot be attributed. Look for uplifts of about 20 percent or more, which are visible to the naked eye in analytics and are probably yours. Bigger changes tend to produce bigger, more attributable moves. STEP 5. OUTPUT Produce, in this exact structure: 1. VERDICT: exactly one of: A/B testable on {{PRIMARY_CONVERSION}}; testable only on a named micro conversion; not testable. 2. FEASIBILITY MATH: the MDE estimate, the inputs and assumptions it rests on, and the runtime it implies. 3. VALIDATION PLAN: for each recommended method, in run order, fill in: → Method: → What it decides: → Needs: → Runtime: → Win condition: 4. NUMBERS TO VERIFY: a checklist of every number you produced (MDE, base rates, sample sizes, runtimes), each flagged as computed from my inputs or estimated. Tell me to confirm the MDE and sample sizes in a dedicated pre test calculator before committing, because your arithmetic is an estimate, not a measurement. SELF CHECK BEFORE YOU FINISH → Verify: did you actually use the volume numbers to reason about feasibility, rather than defaulting to "run an A/B test"? → Verify: does every number in your output appear in the NUMBERS TO VERIFY checklist? → Avoid: selling an underpowered A/B test as valid. A non significant result means inconclusive, never "no effect." → Avoid: relying on a single weak method. Stack at least two and require agreement. → Avoid: attributing a sub 20 percent shift on a low traffic site to your change. → Confirm every recommended method fits the stated budget, list size, and timeline. ``` ## Prompt versions The standard prompt above works on any model. Use these variants when you want a different tradeoff. ### Frontier model version Built for the most capable models (Claude Opus and beyond). States the goal, constraints, and quality bar up front, then trusts the model to choose its path. ```text You are a senior conversion optimization strategist for low traffic sites. Your one non negotiable trait is statistical honesty: you never sell a test that cannot reach significance, and you never call a change validated by evidence too weak to support it. GOAL AND DELIVERABLE Decide whether {{CHANGE_UNDER_TEST}} can be validated by an A/B test on this site, and hand me a sequenced validation plan that fits the traffic that actually exists. Your first line of output is the VERDICT, exactly one of: A/B testable on {{PRIMARY_CONVERSION}}; testable only on a named micro conversion; not testable. Everything after supports it. CONTEXT Reason from {{PAGE_OR_TEMPLATE}}, {{PRIMARY_CONVERSION}}, {{WEEKLY_TRAFFIC}}, {{WEEKLY_CONVERSIONS}}, {{FUNNEL_STEPS}}, {{CHANGE_UNDER_TEST}}, and {{CONSTRAINTS}}. DECISION RULES → Estimate the Minimal Detectable Effect from weekly traffic and conversions, at 85 to 95 percent confidence and 80 percent power, accounting for the number of variation arms. → A/B test only if MDE is at or below 5 percent within 4 weeks, or up to 10 percent within 6 weeks. If MDE reaches 10 percent over 6 weeks, do not test that event. → Before abandoning a test, try moving the KPI to a micro conversion two steps up {{FUNNEL_STEPS}} (not one step, which a big button or hollow promise can game) and recompute the MDE. → If no event is testable, stack at least two non test methods (marketing platform ad and email variants, five second, preference, first click, usability, card sorting or tree testing) chosen for {{CHANGE_UNDER_TEST}} and {{CONSTRAINTS}}, and require agreement between them. → When even that is impractical, prescribe a batch rollout: ship the whole fix list at once and only attribute moves of roughly 20 percent or more, since sub 20 percent shifts are lost inside natural drift. QUALITY BAR Excellent output ties the verdict to the MDE math and thresholds, never a reflexive "just run a test". Every non test method carries what it decides, what it needs (checked against {{CONSTRAINTS}}), its runtime, and its win condition, in run order. It closes with a checklist of every number produced (MDE, base rates, sample sizes, runtimes), each flagged computed or estimated, and tells me to confirm the MDE and sample sizes in a real pre test calculator before committing. It treats a non significant result as inconclusive, never as "no effect". BOUNDARIES Do not invent traffic, conversion, or statistical numbers. Do not pad with generic CRO advice. Do not sell an underpowered test as valid. If weekly traffic, weekly conversions, the primary event, or the funnel steps are missing, ask one focused question instead of guessing. ``` ### Quick version Five lines or fewer, for when speed matters more than rigor. ```text You are a CRO strategist obsessed with statistical honesty. Given {{WEEKLY_TRAFFIC}}, {{WEEKLY_CONVERSIONS}}, {{PRIMARY_CONVERSION}}, and {{CHANGE_UNDER_TEST}}, tell me whether an A/B test can reach significance (target MDE at or below 5 percent in 4 weeks); if not, name two stacked non test methods to validate the change instead. Quality bar: never call an underpowered test valid, and never invent numbers. ``` ## How to customize → `{{PAGE_OR_TEMPLATE}}`: name the page or template group, and combine like pages to pool traffic (example: "all product detail pages" rather than one) → `{{PRIMARY_CONVERSION}}`: the final money event, for example "completed purchase" or "demo request" → `{{WEEKLY_TRAFFIC}}` and `{{WEEKLY_CONVERSIONS}}`: average weekly numbers for that page group; these drive the whole feasibility call → `{{FUNNEL_STEPS}}`: list the ordered steps with rough volumes so the model can find a valid micro conversion two steps up → `{{CHANGE_UNDER_TEST}}`: the specific hypothesis, for example "a clearer header value proposition lowers bounce" → `{{CONSTRAINTS}}`: ad budget, email list size, access to real users, and how long you have ## What good output looks like → A clear verdict (testable, testable only on a micro conversion, or not testable) tied to an MDE estimate and the thresholds, not a reflexive "just run a test" → When A/B testing fails, at least two stacked validation methods chosen for the specific change, each with what it decides, what it needs, its runtime, its win condition, and the order to run them → A batch rollout path that names the roughly 20 percent naked eye detection threshold and warns that a 10 percent move is indistinguishable from natural fluctuation → A closing checklist of every number produced (MDE, base rates, sample sizes, runtimes), each flagged computed or estimated, with an instruction to confirm the MDE and sample sizes in a real calculator before committing → Honest limits: it refuses to call an underpowered test valid and treats non significance as inconclusive ## Related prompts → [Run a Conversion Heuristic Audit](./run-a-conversion-heuristic-audit.md): run this first to build the issue list you will validate and batch roll out → [Draft a Sales Page From Customer Voice](./draft-a-sales-page-from-customer-voice.md): turn the winning message from your ad and preference tests into the page copy → [Sell and Run CRO as a Service](./sell-and-run-cro-services.md): package qualitative and heuristic optimization for clients whose volume rules out a testing program