Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are a conversion rate optimisation consultant auditing an ecommerce page.
Context:
- Page type and URL: {{page}}
- Full page content in order, including headings, copy, imagery descriptions and buttons: {{page_content}}
- Traffic and conversion rate: {{metrics}}
- Traffic source mix: {{traffic_sources}}
- Device split: {{devices}}
- Known objections and return reasons: {{objections}}
- Analytics observations, such as drop-off points: {{analytics}}
Task: Produce:
1. The decision sequence a shopper must complete on this page, in order
2. For each decision, whether the page currently supports it, with the specific element quoted
3. Gaps: decisions the page does not support, ranked by how many shoppers they block
4. Friction inventory: every extra click, unexplained field, hidden cost or unanswered question
5. Ranked fixes, each as a testable hypothesis in the form "If we change X, then Y will improve, because Z", with the success metric and effort
6. Mobile-specific issues, called out separately
7. What to leave alone and why
Rules:
- Quote the actual page element in every finding, no generic best-practice lists.
- Rank by expected impact on the supplied traffic volume, not by ease.
- Do not recommend a redesign, recommend changes that can be tested individually.
- If a finding needs data you were not given, say what data and why.
Finish with: the top three tests to run in order, and the minimum sample each needs to be readable.Estimated results
Editor's note
Why this prompt matters
An ecommerce page can answer every internal stakeholder’s question while leaving shoppers unable to decide whether to buy. A backpack page may describe materials beautifully but never establish laptop fit. A checkout may collect addresses correctly while revealing delivery charges only after customers have invested effort. Analytics shows where people leave; it rarely explains which unresolved decision caused the exit.
This prompt connects those two views. Supply the page in visual order, its traffic context, known objections and observed drop-offs. The audit then reconstructs the buying sequence, checks the evidence available at each step and turns specific gaps into individually testable changes. It is designed for a backlog review, not a redesign presentation.
Use the result to choose what deserves investigation, what can be corrected directly and what warrants an experiment. Treat impact rankings as provisional wherever shopper counts or behavioural evidence are missing: a persuasive explanation is not proof of a conversion problem.
Anatomy
Prompt engineering breakdown
Role
Focuses judgement on purchase decisions.
Context
Connects page evidence with shopper behaviour.
Goal
Produces ranked, measurable conversion hypotheses.
Constraints
Requires quotes and acknowledges missing data.
Output format
Decision audit, friction inventory, test backlog.
Why this structure works
Separates diagnosis from intervention and measurement.
What you'll get
Expected output
What the audit should return
Expect a decision audit, a friction inventory and a ranked experiment backlog. Each finding should quote supplied copy or identify a supplied visual element, distinguish observation from inference and name missing evidence. Mobile findings and the leave-alone list should remain separate.
Worked example: a backpack product page
Suppose your supplied page contains “Fits most laptops,” “Shipping calculated at checkout,” a collapsed “Returns” accordion and an “Add to cart” button. Support enquiries mention laptop fit; analytics shows shoppers moving between product details and checkout. No experiment baseline or mobile screenshots are supplied.
The decision sequence might be: confirm intended use, verify laptop fit, understand delivered cost, assess return risk, then choose an option and buy. “Fits most laptops” supports compatibility only partially; it does not establish compartment dimensions. “Shipping calculated at checkout” explicitly postpones cost certainty. A collapsed “Returns” section is not necessarily friction: its contents and interaction data need inspection.
Provisional test order
- Compatibility: If we replace “Fits most laptops” with verified compartment dimensions, then purchase conversion will improve, because shoppers can check fit. Effort: low after measurement. Guardrail: fit-related returns.
- Delivery cost: If we add an accurate delivery estimate beside “Shipping calculated at checkout,” then purchase conversion will improve, because fewer shoppers encounter unexpected totals. Effort: medium; location-dependent pricing requires implementation checks.
- Return visibility: If we expose the key terms from “Returns” near the purchase controls, then purchase conversion will improve, because buyers can assess reversal risk. Effort: low; retain access to full terms.
Keep “Add to cart” unchanged without contrary evidence. Request mobile captures before alleging layout defects. For each test’s minimum sample, request eligible traffic, baseline conversion, minimum detectable effect, allocation, significance threshold and power; do not fabricate visitor counts.
Under the hood
Why this prompt works
The Role sets a conversion consultant’s remit: explain purchase barriers rather than polish language indiscriminately. Context ties that judgement to page evidence, traffic sources, devices, objections and analytics. Together, these inputs help distinguish an acquisition mismatch from a page problem; visitors seeking specifications may behave differently from returning buyers ready to checkout.
The Task forces decisions into sequence before proposing fixes. That matters because reassurance about returns cannot compensate for uncertainty about whether the product fits. The Rules require quoted evidence, individually testable changes and explicit data requests, preventing generic advice from masquerading as diagnosis.
The final experiment shortlist creates a handoff to implementation and measurement. Requiring effort and success metrics exposes tradeoffs, while the leave-alone section protects supported decisions. Sample planning is a feasibility check, not a guarantee that every store should run an A/B test.
Model fit
Best AI models for this prompt
ChatGPT
Use it to organise mixed page copy and analytics notes. Request a final quote-verification pass.
Claude
A practical primary choice for reviewing long page evidence. Ask it to label inferred blockers separately from observations.
Gemini
Useful when supplying screenshots alongside analytics exports. Label device, page state and reporting period explicitly.
Grok
Use it to challenge the proposed test order. Restrict findings to supplied evidence, excluding general ecommerce commentary.
When to use
- Product-page traffic converts poorly despite relevant acquisition.
- Checkout exits increase after delivery costs appear.
- Support repeatedly answers missing purchase questions.
- A redesign proposal needs narrower test alternatives.
When not to use
- You need verified live checkout debugging.
- Missing economics make pricing recommendations speculative.
- Policy wording needs legal review.
- Traffic cannot support the proposed experiment.
Get more from it
Pro tips
- 1
Capture validation errors and expanded accordions.
- 2
Separate mobile and desktop page states.
- 3
Define the denominator in {{metrics}}.
- 4
Date observations in {{analytics}}.
- 5
Verify dimensions before testing compatibility copy.
- 6
Estimate sample requirements before scheduling tests.
Don't ship this
Common mistakes
✗ Treating absent screenshots as absent content.
Fix — Request the missing page state.
✗ Ranking solely by implementation ease.
Fix — Use affected traffic and evidence strength.
✗ Changing several barriers together.
Fix — Isolate the proposed causal mechanism.
People also ask
Frequently asked questions
Q.How much traffic do I need before optimising?
Enough for a test to reach significance, which the output estimates for you. Below that, act on the clarity and friction findings directly rather than trying to A/B test them.
Q.Why hypotheses instead of a list of recommendations?
Because a hypothesis states a prediction and a metric, so it can be proven wrong. A recommendation cannot, which is why checklist audits produce activity rather than measurable improvement.
Q.Does this cover mobile?
Yes, as a separate section. Most ecommerce conversion problems are mobile-specific, so supply your device split and the audit calls out mobile issues rather than averaging them away.