Getting good answers
A capable model with 37 tools and no guidance produces a tidy list of observations. What you want is a ranked profit-and-loss. The server closes most of that gap for you — this page explains how, and what is left for you to do.
What your assistant is told before you type anything
At handshake, the server sends an instruction set that most clients inject into the model's context for the whole session. It is not documentation for you — it is a working brief for the assistant. Three rules sit at the top of it:
- Every finding carries a number in your reporting currency.A finding without an estimated revenue impact is an observation, not a finding. “Rage clicks on the subscribe toggle” is worthless. “Subscribe toggle fails on roughly 46% of taps; that page drives 8 of 31 orders; at a recovered 20% of failed taps this is roughly €180–400 a month” is actionable.
- Never report a store-wide number without splitting it. A 1.3% store conversion rate can be 2.0% mobile and 0.0% desktop, and the second fact is the entire story. Most large wins are a broken segment, not a mediocre site.
- Distinguish what the data proves from what it infers. State the sample behind every rate. A confidently stated artefact of 30 sessions costs real money.
The triage sequence
Your assistant is told to work top-down rather than dumping every tool. Knowing the order helps you tell a thorough answer from a lazy one.
- get_cro_overview — one call for the headline funnel, sized opportunities, anomalies, UX issues and failing vitals.
- get_anomalies — what changed recently.
- get_opportunity_sizing — the leaks ranked in currency. This ranking orders everything after it.
- get_funnel_analysis segmented by device — names the exact failing step, with a significance test built in.
- get_conversion_correlations — the statistically vetted factors. The most rigorous tool on the server.
- Then drill, with the diagnostic tools, into whatever those flagged.
For a specific page, the highest-yield pairing is get_page_dom_snapshot plus get_element_click_analysis: structure, plus which selectors received the bad clicks. That combination resolves most UX questions without opening a browser.
The statistical gates
Small stores generate small numbers, and most apparent insights at that scale are sampling noise. The server tells your assistant to apply these before claiming anything.
- Minimum samples. A conversion-rate comparison is not stated as fact below roughly 200 sessions and 10 conversions in each arm. Below that it is a signal to watch. Per-product add-to-cart rates need roughly 100 product views.
- Zero is not automatically noise. If an event occurred 0 times in n trials, the 95% upper bound on its true rate is about 3/n. Zero orders in 1,142 desktop sessions puts the true desktop rate below 0.26%. Against a 1.3% mobile rate, that gap is proven, not suspicious.
- Comparing two rates uses a two-proportion z-test, not eyeballed percentages.
- Multiple comparisons. Scan 20 pages and one will look significant by chance. Findings from a pre-formed hypothesis outrank findings from a scan.
- Rates need denominators. A 46% rage-click rate over 70 clicks is a different claim than over 7,000.
- Do not double-count. A JavaScript error, a high bounce rate and a low scroll depth on the same page are usually one problem, not three.
How to ask
Ask the question you actually have. Do not name tools, do not specify date ranges unless you mean them, and do not pre-chew the analysis.
When you want to steer
These are worth saying, because they change the answer:
- “Split that by device.” If a store-wide number came back unsplit, this is the fix.
- “What is the sample behind that?” Forces the denominator into the open.
- “Size that in euros per month, and show the arithmetic.” Turns an observation into a decision.
- “Is that distinguishable from noise?” Cheap, and it kills a lot of bad findings.
- “Check dataCoverage first.” Use it the moment a result comes back empty.
What a good answer looks like
Ranked by estimated revenue impact, and for each finding:
- What is happening — one sentence, with numbers and denominators.
- What it costs — currency per month, arithmetic shown.
- Confidence — proven, probable or hypothesis, and why.
- The fix — a named selector, page or setting.
- How to verify — which metric should move, and by when.
Anti-patterns
- Listing every metric retrieved. Retrieve widely, report narrowly.
- “Improve your copy” — non-actionable filler.
- Presenting three symptoms of one root cause as three findings.
- Quoting a percentage without its denominator.
- Hedging everything. If the rule of three proves it, state it plainly.
- Blaming tracking or consent for empty data before checking the coverage envelope.
Close the loop
CRO is find, fix, then measure. After you ship something, come back and run get_before_after with the date it went live. It returns an improved, regressed or no-detectable-change verdict with a significance test — and it will tell you honestly when your volume is too low to say.