ConvRadar: CRO for GA4

ConvRadar (GA4 analytics): detect anomalies in traffic mix and per-source sessions over time. Source share is measured against all recorded source sessions in each equal-length window; top_n_sources only selects which sources are monitored. Flags large shifts in that share or anomalous spikes/drops in monitored sources' daily sessions. If either comparison window has no source data or the row cap is exceeded, the response says the mix verdict is unavailable. Use when the user asks "did my traffic mix change", "is one channel acting weird", "did paid traffic drop", "what's happening with my organic traffic". Limited to top sources by volume so the response stays focused. top_n_sources caps how many sources we monitor (default 8, max 25).

cr_detect_traffic_quality_change

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; measurable entries can then be re-measured against the corrected window. If edited text is no longer a measurable change, its prior impact verdict is invalidated without scheduling a new measurement. Dismissing keeps the entry on the timeline but out of the impact loop.

cr_update_change

ConvRadar (GA4 analytics): progress and download links for an export started with cr_export_facts. While it runs this returns {status, months_done, months_total, retry_after_s}; call again after retry_after_s. When ready it returns the files with 24-hour links and manifest_url (every file's sha256 and when its rows were last synced). If it stopped, retry_mode and can_resume explain whether the same arguments resume a table export from its last finished month (only on its original UTC day) or start a new export; comparisons run again.

cr_get_export

ConvRadar (GA4 analytics): export the rows ConvRadar stores for a property as CSV files, one or more per month, for up to 400 days and 2,000,000 rows. Use it instead of paging cr_query_metrics (100 rows a call) when the user needs history or a raw snapshot. With compare_property_id it compares two properties after a GA4 migration: each event's status, the month it moved, and one stitched daily event series. ASYNCHRONOUS when rows exist. Returns {status, request_id, retry_after_s} at once; the files are written in the background. An empty date/table selection returns data.written=false without creating a job or using an export allowance. Poll cr_get_export(request_id) for progress and the download links, and give the user the links rather than reading rows into the conversation. The same arguments on the same UTC day return the same export; a stopped table export continues from its last finished month only on that same UTC day. Later retries start a new export; a stopped comparison runs again.

cr_export_facts

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", "aov", "abandoned_checkouts"}. Default: available metrics from the first four. Unsupported names are rejected. 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; stored snake_case names or exact GA4 API names from cr_describe_data(live=True, search=...). Never guess a field or substitute a similar metric without clarifying its meaning. - `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 — full customer-journey audit. Use for a full audit, where people stop, or what to improve. Returns headline KPIs, traffic sources, landing pages, observed customer paths, supported findings, observations and measurement questions. Observations and aggregate event counts are not automatically problems or sequential funnels. Zero findings is valid. Ambiguous existing events require goal selection, not a missing-tracking diagnosis; present measurement questions after business findings. date_from/date_to are optional ISO YYYY-MM-DD; default last 30 days vs prior 30 days. Read-only. Targeted GA4 sequence checks may take up to 120 seconds; partial results identify unavailable checks.

cr_full_audit

ConvRadar (GA4 analytics): same-window funnel event counts, directional count ratios, and the largest observed count drops. These ratios are not user-cohort conversion rates. 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). Missing or non-monotonic steps are flagged and excluded from drop ranking. An observed count drop does not establish its 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", "conversions", "conversion_rate"}. Returns up to top_n (capped at 25) countries. A conversion-rate ranking includes only countries with enough measured purchases and sessions; when none qualify, the response names the fallback to sessions.

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. The account_fit field reports whether catalog model and vertical filters fit this connected property. A direct ID lookup can return a reference outside this property's catalog; do not present one marked not_applicable as a recommendation or measured finding. 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", "conversions", "conversion_rate", "bounce_rate"} (bounce_rate ranks worst-first). 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 (verification): list capture-set IDs and page types. Provide capture_set_id to see its exact observable keys and manual evidence keys before cr_record_verification. An unknown ID returns status `not_found`, not a checklist. Use cr_get_hypothesis for the checklist specific to one hypothesis.

cr_list_capture_sets

ConvRadar (CRO library): browse the hypothesis catalog. Filter by category (e.g. 'pdp_information', 'checkout_friction') or vertical (e.g. 'dtc_apparel', 'beauty_ecom'). Returns a paginated list with id, title, category, expected impact range. Follow meta.next_offset because the response size cap can reduce a requested page. 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 within the same affected_segment and hypothesis_id: retrying the same change on the same day resolves to one entry. Invalid input returns data.written=false.

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 a saved AI hypothesis, pass source='ai_suggested' and its user_hypothesis_id; for a new AI hypothesis, pass the full ai_suggested_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 ~20s 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 — group counts for every SKU classified as underperforming / watchlist / healthy / no_purchases / low_data, with up to 25 product rows from the requested status. Rows include 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", "non_product"} or omit for the overall priority sample. An unknown status returns `invalid_filter`. top_n caps at 25. A filtered response reads the saved per-status sample; it does not filter the overall top 10. 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", "views", "add_to_carts", "purchases", "cart_to_view_rate", "purchase_to_view_rate"} — items have no session count, so there is no 'sessions' or session-based conversion rate here. 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 extracted from a page (HTML, screenshot, or browser tool). Each call adds a new verification record and returns one verdict per applicable hypothesis; one capture can produce many verdicts. Earlier verification records are kept unchanged and nothing is deleted. A complete, substantive verdict becomes the hypothesis's latest verdict; the user's status and notes on it are left as they are. For manual observables, use method='manual' and notes naming the independent evidence source. Screenshot, browser, and fetch methods can submit visible page facts only. When method='screenshot' pass screenshot_id from cr_get_screenshots; it must resolve to a successful stored screenshot for this account and URL. Other methods record submitted observations but cannot independently prove the page was seen. quality ∈ {complete, partial, failed, insufficient}. Empty complete observations are rejected; incomplete or inconclusive attempts never replace a prior hypothesis verdict. A failed persistence operation returns written=false and no verdict.

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}. A new row starts surfaced; an exact sequential retry returns the existing row and its current status. 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 (tracking plan): read the site's tracking plan, the GA4 events to add or fix, each with when it fires, its parameters, what GA4 records today and who adds it (the developer, a Tag Manager tag, or GA4 Admin); a v2 plan ranks them P1/P2/P3. Use when the user asks what to track, which GA4 events or key events are missing, why a form, lead, signup or checkout step is not showing in GA4, for a tracking or measurement plan, or what to hand a developer or Tag Manager specialist. Also use when an audit or funnel shows a step GA4 does not record. Conversion numbers and drop diagnosis belong to the analytics tools. Call this before cr_build_tracking_plan: a ready plan is the answer, and a new build spends the account's build allowance. recorded_by_ga4 covers eight automatic events with their 28-day counts; for other events use cr_describe_data or cr_query_metrics. site_structure shows sitemap path families and crawl coverage. Missing evidence is marked unavailable, including in legacy plans; response_schema_version names this response format. fix_url opens the plan page and the developer export. Read-only. Available on paid Basic and Pro accounts; Free cannot read stored plans. With no plan or a failed attempt, next_tool suggests cr_build_tracking_plan while allowance remains and no cooldown applies; recent failures return retry_after; an exhausted allowance returns no next_tool.

cr_get_tracking_plan

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", "conversions", "conversion_rate"}. 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" / "balanced" (60), "aggressive" (45)}. Date window default last 30 days; max 90. comparison_days default 28.

cr_assess_traffic_quality

ConvRadar (diary): check the observed before/after result of a shipped change — "did my change help?", "проверь эффект изменения". Given a change diary entry id (from cr_log_change or cr_list_changes), compares the property's selected primary conversion over 7 days before deployment and `days_after` days after. Verdict ∈ {improved, regressed, no_change, insufficient_data}; this observational comparison does not establish causality. System events, unmeasurable notes, segment-targeted changes without segment measurements, missing baseline, and incomplete post windows return insufficient_data without a significance claim. Use after a change has been live ≥ 14 days. Default `days_after=14`.

cr_verify_change_impact

ConvRadar (message research): find what customers in this category actually complain about, then check whether the page answers it. Researches independent sources (Reddit, forums, review sites; the brand's own reviews are excluded), ranks the pains by how often they recur, and marks each one addressed_well / addressed_poorly / missing against the page's copy. Use when the user asks what customers care about, why the message isn't landing, what objections the page fails to answer, or wants copy angles grounded in real customer language rather than invented personas. THE USER STARTS THIS, NEVER YOU. Call it only when they have just asked for it in their own words. Do not call it inside an audit, a "what should I fix" sweep, a page review, or to enrich an answer they asked for about something else — the account gets one run a week and a run you started on your own spends their week. The first call leaves confirm=false: nothing is started, you get the quote back and show it to them. Only after they say yes, call again with confirm=true. ASYNCHRONOUS AND RATE-LIMITED. Returns {status:'researching', request_id} in about two seconds; the run takes 3-6 minutes and you must poll cr_get_voice_of_customer(request_id) for the report — the acknowledgement is NOT the answer. One run per account per week while the tool is free; a capped call returns status:'rate_limited' with the date the next run unlocks and a link to the previous report, which is usually still the answer.

cr_voice_of_customer

ConvRadar (message research): fetch the Voice of Customer report for a request_id returned by cr_voice_of_customer. While the background run is still going this returns {status:'researching', retry_after_s} — call again after that many seconds. When done it returns the top themes with a verbatim customer quote each, whether the page addresses them, the ranked content actions, and the fidelity score behind the evidence. A failed response includes retry_policy: a new run uses monthly quota on a paid plan; failed free-beta runs are excluded from the weekly cap. Quote the fidelity score and the low_confidence flag when you report findings: they are how this tool tells you the research leg was thin, and a confident summary of thin evidence is exactly what the flag exists to prevent.

cr_get_voice_of_customer