ConvRadar: CRO for GA4

ConvRadar (GA4 analytics): mobile vs desktop vs tablet for the connected GA4 property — session shares, per-device conversion rate, engagement, revenue. Use when the user asks about device performance, mobile vs desktop comparison, why mobile underperforms, or device-level conversion rates.

cr_get_device_breakdown

ConvRadar (GA4 analytics): given a current vs prior period, find which segments contribute most to a drop (or rise) in conversion_rate / revenue / purchases. Splits across device, source, country, landing_page. Use when the user asks "why did my conversion drop", "where is the leak", "diagnose my checkout drop", "what's hurting my numbers", "what changed". This is the core 'find the leak' tool. Compares the last N days vs the immediately-preceding N days. metric ∈ {"conversion_rate", "revenue", "purchases"}. This output names the segments contributing most to a drop but not the on-page cause. Recommendations require fetching the implicated page via `cr_capture_via_web_fetch`, a mobile screenshot if a mobile segment is the dominant gap, and asking the user about between-step blockers when the leak concentrates at a single transition. Full policy: `/verification-policy`.

cr_diagnose_funnel_drop

ConvRadar (diary): edit or remove a diary entry — "fix the date on that change", "that was actually last Tuesday", "delete/remove my last entry", «удали последнюю запись», «поменяй дату». Corrects a wrong description, category, segment, or deployment date, or dismisses a mistaken entry. Changing the date clears any prior verdict so impact is re-measured against the corrected window; dismissing keeps the entry on the timeline but out of the impact loop.

cr_update_change

ConvRadar (GA4 analytics): finds statistically-significant anomalies (spikes and drops) in your daily metrics over the last N days. Uses a 28-day rolling baseline with weekly seasonality adjustment. Use when the user asks "is anything weird in my data", "find anomalies", "is something broken", "did anything spike or drop". Returns flagged dates with severity (notable | severe). metrics ∈ {"sessions", "purchases", "revenue", "conversion_rate"}. Default: all four. This output flags an anomaly's date and severity but not its cause. Attributing the cause requires localizing the segment via `cr_diagnose_funnel_drop`, fetching the implicated page via `cr_capture_via_web_fetch`, a mobile screenshot if the anomaly concentrates there, and asking the user what changed around the date (deploys, content swaps, paid-traffic changes, tracking edits). Full policy: `/verification-policy`.

cr_find_conversion_anomalies

ConvRadar (GA4 analytics): flexible aggregation over any ga4_fact_* table — pick metrics + optional dimensions and the tool finds the right fact table, runs the query, and aggregates. Use this for ad-hoc questions like "how many users yesterday", "revenue by day", "purchase events by country last week", "sessions by device for april". For the fixed dashboards (overview, traffic, landing, etc.) prefer the dedicated `cr_get_*` tools — they're tuned for those shapes. - `metrics`: required, snake_case column names (e.g. `["total_users", "purchase_revenue"]`). Run `cr_describe_data` first if you don't know the names. - `dimensions`: optional. Use `["date"]` for a time series, `[]` (or omit) for a grand total. Multi-dim grouping is supported. - `filters`: optional dict — value can be scalar (`"mobile"`), list (`["purchase","add_to_cart"]`), or 2-tuple (range). - Date window default last 30 days, max 90. This is an ad-hoc aggregation tool — its output is metrics, not diagnoses. If the user's question leads to a recommendation, the recommendation requires fetching the implicated page via `cr_capture_via_web_fetch`, a mobile screenshot when mobile-skewed, and asking the user about between-step blockers. Full policy: `/verification-policy`.

cr_query_metrics

ConvRadar (golden first-run audit): runs a complete diagnostic in one call — headline KPIs vs prior period, biggest funnel leak, top 3 traffic sources, top 3 landing pages, anomalies, segment drops, and benchmark comparison. Returns 2–5 ranked actionable findings with next-step actions and matched hypotheses. Use as the first tool on a new connection or whenever the user asks for a full audit. Trigger phrases: "run a full audit", "audit my analytics", "where do I start", "give me the diagnostic", "what's wrong with my conversion", "first-time analysis", "complete check". date_from/date_to are optional ISO YYYY-MM-DD; defaults to last 30 days vs prior 30 days. Read-only. Output ≈ 4–8 KB. Findings reference the next tool to call (cr_capture_via_web_fetch, cr_diagnose_funnel_drop) — full guardrails: `/verification-policy`.

cr_full_audit

ConvRadar (GA4 analytics): step-by-step e-commerce funnel with conversion rate at each step, the biggest leak, and the top N leaks ranked by drop %. Use when the user asks about the conversion funnel, drop-off, where users stop, "why aren't people buying", "top problems in my funnel", checkout abandonment. Default funnel: page_view → view_item → add_to_cart → begin_checkout → purchase (4 transitions). Override `steps` for sites with non-standard events. `top_leaks` caps the ranked list (default 4 = all transitions of the default funnel; max equals number of transitions). This output names the leakiest step transitions but not the on-page cause. Recommendations require fetching the implicated page via `cr_capture_via_web_fetch`, a mobile screenshot when mobile-skewed, and asking the user about between-step blockers (sign-up walls, address modals, age gates, KYC). Full policy: `/verification-policy`.

cr_get_funnel

ConvRadar (GA4 analytics): top countries by sessions or revenue, with conversion rate per country. Use when the user asks about geographic performance, "where are my users from", country-level conversion, international markets. sort_by ∈ {"sessions", "revenue", "purchases"}. Returns up to top_n (capped at 25) countries.

cr_get_geo_breakdown

ConvRadar (CRO library): full content for one hypothesis by id (e.g. 'H-PDP-001'). Returns description, applicable verticals, inspection targets, conclusion rules, expected impact range, A/B test design, remediation hint, capture-set info, and which triggers it's attached to. Use when the user asks "tell me more about H-PDP-001", "what's the test for this hypothesis", "how do I verify it".

cr_get_hypothesis

ConvRadar (page speed + UX): fetch the result of a cr_heuristic_check run by its request_id. While the background check is still running this returns {status:'checking', retry_after_s:15} — call again in ~15 seconds. When done it returns the full report: the top-line verdict, the ranked fix order, per-page measured speed plus hedged "likely issues" with grounded fixes and a free-form AI page review, the mobile-vs-desktop conversion-cost ceiling, and a shareable report_url. Measured speed is a fact; visual issues are hedged hypotheses behind a confidence gate.

cr_get_heuristic_check

ConvRadar (visual proof): poll for and fetch the screenshots for a request_id returned by cr_capture_screenshots. Call this ~20s after cr_capture_screenshots — BOTH the worker-less async path and the async-worker path issue a request_id you resolve here. While the capture is still running you get {status:'capturing', retry_after_s} — call again after that many seconds. When ready, returns the desktop screenshot (tiled top-to-bottom) so you can SEE the page, plus the observable checklist and the per-observable verdict contract; then call cr_record_verification(method='screenshot', screenshot_id=...). A failed/absent job yields an honest failure — ask the user for a manual screenshot rather than claiming to have seen the page.

cr_get_screenshots

ConvRadar (GA4 analytics): top landing pages on the connected GA4 property — sessions, engagement rate, bounce rate, avg session duration, purchases, revenue. Use when the user asks about landing-page performance, which pages drive traffic, high-bounce pages, top-converting pages. sort_by ∈ {"sessions", "revenue", "purchases"}. Returns up to top_n (capped at 25). Pages that are blank or "(not set)" are flagged `unattributed: true` — their conversion rate is unreliable (missing page attribution), so caveat any CR you quote for them. This output identifies which pages have problems but not why. Fixing specific UI / copy / layout issues requires the page itself: fetch via `cr_capture_via_web_fetch`, ask for a mobile screenshot if a mobile segment is the dominant gap, and ask the user about pop-ups or walls between landing and conversion. Full policy: `/verification-policy`.

cr_get_landing_pages

ConvRadar (visual proof): list the capture sets you can verify a page against — each has an id, the page type it covers, and the exact observable keys to extract from a screenshot. Pick the matching set before cr_record_verification: e.g. CS-landing-page for a lead-gen/landing page, CS-pdp-desktop / CS-pdp-mobile for an ecommerce product page, CS-cart for a cart, CS-checkout-flow for checkout, CS-homepage for a homepage.

cr_list_capture_sets

ConvRadar (CRO library): browse the hypothesis catalog. Filter by category (e.g. 'pdp_clarity', 'checkout_friction') or vertical (e.g. 'dtc_apparel', 'beauty_ecom'). Returns a paginated list with id, title, category, expected impact range. Use when the user asks "what hypotheses do you have", "show me PDP hypotheses", "what tests can I run for cart abandonment". Returns the catalog itself, not matches against a specific finding — call cr_get_hypothesis for full detail on one entry.

cr_list_hypotheses

ConvRadar (diary): record a change the user shipped into their change diary/journal — a redesign, copy edit, price change, new product, campaign launch, tracking or infra change. Use when the user says they changed/launched/shipped/fixed something, asks to log/record/note it, or says «залогируй»/«запиши изменение»/"add to my diary". Captures deployed_at so impact can be measured (cr_verify_change_impact) ~14 days later; entries also appear in cr_list_changes and annotate other tools' readings. change_type ∈ {design, copy, pricing, flow, infrastructure, experiment, marketing, product, content, other}. deployed_at ISO datetime; defaults to now. Duplicate-safe: the same change logged twice on the same day resolves to one entry.

cr_log_change

ConvRadar (state): mark a hypothesis as surfaced/testing/confirmed/rejected/dismissed/archived for this tenant. Use after the user agrees to test a hypothesis, ships a fix, or dismisses one. For library hypotheses, pass hypothesis_id; for AI-suggested, pass source='ai_suggested' and the payload. status ∈ {surfaced, testing, confirmed, rejected, dismissed, archived}.

cr_mark_hypothesis_status

ConvRadar (GA4 analytics): headline KPIs for the connected GA4 property — sessions, conversion rate, revenue, AOV — for a date window with deltas vs the prior period of equal length. Use when the user asks about overall performance, "how is the site doing", week-over-week or month-over-month conversion/revenue trends. date_from/date_to are ISO YYYY-MM-DD. Default = last 30 days. Max window 90 days. When a big AOV swing rests on a small purchase base (< 200 purchases in either window), the response sets `aov_small_sample_volatile: true` and adds a caution note — AOV is revenue/purchases, so a couple of large orders distort the % change. In that case lean on revenue and purchase count, not the AOV delta.

cr_get_overview_metrics

ConvRadar (page speed + UX): measures a page's speed via Google PageSpeed Insights AND reads a mobile screenshot against the conversion hypothesis library — returning the speed grade plus specific, hedged "likely issues" with grounded fixes and a free-form AI page review, all from the live page with no GA4 needed. When GA4 data exists it also flags where the page really leaks. The full check (speed + screenshot + AI vision reads) takes ~2–3 minutes, so this runs it in the background and returns FAST: a {status:'checking', request_id}. Call cr_get_heuristic_check(request_id=...) after ~30s for the report, then poll it every ~15s until status is 'complete'. A recent identical check returns its full report inline immediately; an app-only or invalid URL returns a not-applicable answer with no wait. One page by default; pass max_pages=2–3 to also check the next most-visited/leakiest pages. Honest by design: measured speed is a fact; visual issues are hedged hypotheses behind a confidence gate. Use when the user asks what's slowing a page or hurting its conversions, or wants concrete fixes for a specific URL.

cr_heuristic_check

ConvRadar (GA4 analytics): pre-computed product diagnosis — every SKU classified as underperforming / watchlist / healthy / no_purchases / low_data, with broken-funnel-step (view→cart, cart→checkout, checkout→purchase), weekly revenue opportunity, and anomaly flags (3-week declines, drop %). Use when the user asks "which products are problem children", "where am I losing money on SKUs", "underperforming items", "anomalies", or wants the diagnostic view rather than raw metrics. Filter to one classification with `status`. Returns the latest completed run; if none exists, advises running it from the ConvRadar web panel. status ∈ {"underperforming", "watchlist", "healthy", "no_purchases", "low_data"} or omit for all. top_n caps at 25. This output classifies underperforming SKUs and the broken funnel step but not the on-PDP cause. Recommendations require fetching each implicated PDP via `cr_capture_via_web_fetch`, a mobile screenshot if the broken step is view→cart and the SKU's traffic skews mobile, and asking the user about between-step blockers for cart→checkout / checkout→purchase issues. Full policy: `/verification-policy`.

cr_get_product_analysis

ConvRadar (GA4 analytics): top products by revenue, views, or purchases — with cart-to-view + purchase-to-view rates per item. Use when the user asks about product/SKU performance, best/worst sellers, which items convert, item-level analysis, e-commerce catalog insights. sort_by ∈ {"revenue", "items_purchased", "items_viewed"}. Optional `category` filter narrows to a single item_category. Returns up to top_n (capped at 25).

cr_get_product_performance

ConvRadar (verification): submit observables Claude extracted from a page (HTML, screenshot, or browser tool). Server (a) writes a verifications cache row, (b) iterates every hypothesis using this capture_set, (c) applies its conclusion_rules to the observables, (d) UPSERTs user_hypotheses with verdicts. Returns one verdict per applicable hypothesis. **One capture → many verdicts in a single call.** method ∈ {web_fetch, user_screenshot, claude_browser, screenshot}. When method='screenshot' pass screenshot_id from cr_get_screenshots. quality ∈ {complete, partial, failed, insufficient}. observables_extracted keys must come from the capture_set's observable definitions.

cr_record_verification

ConvRadar (Q7 fallback): persist an AI-generated hypothesis when no library match exists for a finding. payload must include {title, description, expected_impact_metric, expected_impact_min_pct, expected_impact_max_pct, suggested_test}. Stored with source='ai_suggested', status='surfaced'. CRITICAL: in chat, surface these hypotheses with the marker "💡 Not in our verified library — based on general CRO principles." (FOUNDATION Q7).

cr_save_ai_suggested

ConvRadar (GA4 analytics): top traffic sources for the connected GA4 property, broken down by (source, medium) with sessions, users, purchases, revenue, conversion rate. Use when the user asks about traffic sources, channels, where users come from, top-performing campaigns, organic vs paid mix. sort_by ∈ {"revenue", "sessions"}. Returns up to top_n combos (capped at 25). Rows whose source/medium is blank or "(not set)" are flagged `unattributed: true` — their conversion rate is unreliable (usually direct/branded/internal traffic that lost attribution), so caveat any CR you quote for them.

cr_get_traffic_breakdown

ConvRadar (GA4 analytics): scores how much of the property's traffic looks like analytics noise (referral spam, internal/test traffic, datacenter sources, low-quality paid) and estimates how that noise distorts headline conversion rate and revenue. Use this BEFORE any CRO / funnel diagnosis. If estimated_noise_share ≥ 15%, the conversion-rate "drop" the user is worried about may be partially a tracking issue, not a real funnel problem. Each finding carries inline GA4 cleanup instructions (regex for unwanted-referrals filter, internal traffic filter setup, etc.). sensitivity ∈ {"conservative" (default, threshold 75), "normal" (60), "aggressive" (45)}. Date window default last 28 days; max 90. comparison_days default 28.

cr_assess_traffic_quality

ConvRadar (diary): measure whether a logged change worked — "did my change help?", "проверь эффект изменения". Given a change diary entry id (from cr_log_change or cr_list_changes), computes pre/post overview metrics (sessions, purchases, conversion_rate, revenue) — pre = 7 days before deployment, post = `days_after` days after — and a two-proportion z-test verdict ∈ {improved, regressed, no_change, insufficient_data}. Use after a change has been live ≥ 14 days. Default `days_after=14`.

cr_verify_change_impact