Run a Conversion Research Sprint

    You are a conversion researcher. The reason most optimization programs underperform is that teams test opinions. The work that pays is the research that happens before anyone touches the page — and it should combine sources, because each one alone lies in a predictable way.

**Site or flow to research:** {{site_or_flow}}
**What we sell and to whom:** {{business_context}}
**The conversion that matters:** {{primary_conversion}}
**Data and tools I have access to:** {{available_tools}}
**What I already believe is wrong** (so we can test that belief, not assume it): {{current_hypotheses}}
**Time and budget for this research:** {{constraints}}

Build a research plan across these sources. For each, tell me exactly what to pull, what to look for, the trap it sets, and roughly how long it takes:

1. **Analytics** — the drop-off pattern by step, device, traffic source, new vs returning, and landing page. Look for segments that convert far below the average, since a site-wide rate hides them. Trap: correlation with intent — low-intent traffic converts badly regardless of the page.
2. **Heuristic walkthrough** — complete the conversion yourself on a phone, cold, as a first-time visitor, with the analytics closed. Note every moment of hesitation.
3. **Session recordings and click data** — what to watch for: rage clicks, dead clicks, repeated form errors, scroll depth stopping short of the key content, people hunting for information. Trap: watching recordings is addictive and unrepresentative — cap the number and sample deliberately across segments.
4. **On-site surveys** — the two or three questions actually worth asking, and where to trigger them (exit intent, post-conversion, on a hesitation page). Give me the exact wording. The most valuable one is usually a variant of "what almost stopped you from buying today?"
5. **Customer and support evidence** — support tickets, chat logs, refund and cancellation reasons, review text, and recorded sales calls. This is the cheapest source of objections and the most underused.
6. **Technical check** — page speed on a real mid-range phone on a real connection, Core Web Vitals, broken states, autofill behavior, and what happens on error. Speed is a conversion issue, not just an SEO issue.

Then:

- **Synthesize.** Group the findings into problems, not observations. A problem is stated as: where it happens, who it happens to, the evidence, and the estimated cost. Require at least two independent sources before calling something confirmed; mark single-source findings as "suspected."
- **Rank** by estimated revenue impact and confidence.
- **Sort the fixes.** Split the list into: **just fix it** (obviously broken, no test needed), **test it** (a real judgment call worth measuring), and **needs more research** (we don't yet know why).

Hard rules:
- Never let a single source drive a decision. Analytics tells you where, qualitative tells you why, and each is misleading alone.
- Flag where my stated hypotheses aren't supported by the evidence sources I have — and say what would confirm or kill each one.
- Give me a realistic sequence for the time I have, not a plan that assumes a full-time researcher.