cr_assess_traffic_quality
ChatGPTConvRadar (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_build_tracking_plan
ChatGPTConvRadar (tracking plan): build a new tracking plan for the GA4 property, the events to add or fix, ranked, with who adds each one. ConvRadar reads 28 days of GA4 and walks up to 25 public pages of the site with analytics blocked (no forms sent, no login); the plan is ready in about 10 minutes. Use when the user asks for a tracking plan and cr_get_tracking_plan has none, or wants a fresh one after changing the site or its tracking. Start a build only when the user asked for one or agreed to it, since Basic gets one build per paid month. The response is an acknowledgement (status queued, plan_id, fix_url) and holds no plan: read it with cr_get_tracking_plan after about 10 minutes, or give the user fix_url, which follows the build live. Describe the plan only after reading it. Nothing is changed in GA4, Tag Manager or on the site. Available on paid Basic and Pro accounts: one build per paid month in Basic, five in Pro. One attempt per property per 24 hours, failed attempts included, and one build at a time. When no build starts, the response gives a neutral reason, including not_in_plan, quota_used, built_recently and in_flight.
cr_capture_screenshots
ChatGPTConvRadar (visual proof): capture and SEE real desktop + mobile screenshots of a problematic page via an anti-bot browser, to VISUALLY confirm a CRO hypothesis before concluding. Use whenever a funnel diagnosis implicates a specific page (bad add-to-cart, weak PDP, long form, buried CTA) — HTML alone can't show how the page looks on mobile or above the fold. Returns FAST with {status:'capturing', request_id, retry_after_s} on the default (worker-less) deployment: a real anti-bot browser renders the page on a BACKGROUND thread (~20s) and you MUST then call cr_get_screenshots(request_id=...) to receive the images — there is NOTHING inline in THIS response, so do not claim to have seen the page yet. The one exception is a fresh (<7 day) cache hit, which returns the stored screenshot inline immediately. (The separate async-worker deployment, SCREENSHOT_SERVICE_URL set, uses the same request_id → cr_get_screenshots contract.)
cr_capture_via_web_fetch
ChatGPTConvRadar (verification): fetch a URL server-side and return its HTML body so Claude can extract observables. Cached by (capture_set_id, url) for 7 days; UTM params are stripped before caching. capture_set_id: one of the 7 seeded capture sets (e.g. 'CS-pdp-desktop'). url: the page to inspect. Returns raw HTML only. Cannot see: (1) JS-rendered DOM (SPA frameworks inject content client-side after hydration); (2) mobile-specific layout (responsive sites return identical markup — only media queries differ); (3) cross-step flow (modals / walls / gates between funnel steps). When any of these matter, ask the user for a screenshot — list specific URLs and viewports, not a conditional "if it's a SPA, send one". Forbidden conclusions and the full protocol: /verification-policy.
cr_check_page_speed
ChatGPTConvRadar (page speed): measures a page's Core Web Vitals via Google PageSpeed Insights and joins the result to the property's own GA4 conversion data. Returns the mobile performance score, LCP/CLS, the top fixes, and — when there's enough data — how much the mobile-vs-desktop conversion gap slow loading likely contributes to. Numbers are lab (Lighthouse) by default; real-user (CrUX field) data is used and labeled when available — small sites usually have none, so a "lab" label is normal. Reads a cached measurement first (7-day freshness); on a miss it measures mobile live (~10-30s). Also returns observables in the shape cr_record_verification accepts, so the page-speed hypothesis (H-NAV-001) can be recorded in one hop. Use when the user asks if their site/page is fast, why mobile converts worse, or to re-check after optimizing; and to confirm a slow-page suspicion from a funnel drop or audit.
cr_compare_segments
ChatGPTConvRadar (GA4 analytics): compare two segments side-by-side on the same metrics with computed deltas. Use when the user asks "is mobile underperforming desktop", "is paid worse than organic", "how does the US compare to UK", "is new traffic converting like returning". dimension ∈ {"device", "source", "country", "new_vs_returning"}. value_a / value_b are the two values to compare (case-insensitive for device/new_vs_returning; for source pass "google / organic" syntax). The response includes a significance block — a two-proportion z-test on the conversion-rate gap (z, two-sided p, 95% CI on the A−B difference in percentage points, plus significant and low_power flags). Read it off the response; do NOT recompute the z-test by hand. low_power true means too few purchases to trust the verdict. This output quantifies the gap between segments but not the on-page cause. Recommendations require fetching the page implicated by the worse segment via cr_capture_via_web_fetch, a mobile screenshot if the dimension is device and mobile is worse, and asking the user about between-step differences. Full policy: /verification-policy.
cr_compare_to_benchmark
ChatGPTConvRadar (GA4 analytics): compare your headline metrics against industry benchmarks for your vertical. E-commerce: conversion rate, AOV, bounce, engagement. Lead-generation: visitor→lead rate + form-completion vs lead-gen verticals (the purchase metrics are omitted automatically). Use when the user asks "how do I compare to industry", "are my numbers good", "benchmark my site", "is my conversion/lead rate normal". vertical: when omitted, auto-detected from the connected property (its vertical, or a lead_gen_* default for lead-generation sites). Override with one of: ecommerce_general, dtc_apparel, beauty_ecom, ecom_electronics, saas, marketplace, subscription_ecom, lead_gen_general, lead_gen_b2b_saas, lead_gen_professional_services, lead_gen_financial_insurance, lead_gen_healthcare, lead_gen_realestate_home, lead_gen_education.
cr_describe_data
ChatGPTConvRadar (GA4 analytics): describe what data is available for the connected GA4 property — list of fact tables with their queryable dimensions and metrics, distinct event names actually present, and the date window of the data. Use this once at the start of an analysis session before composing a cr_query_metrics call. The output tells Claude exactly which dimensions and metrics are valid combinations.
cr_detect_traffic_quality_change
ChatGPTConvRadar (GA4 analytics): detect anomalies in traffic mix and per-source sessions over time. Flags large shifts in traffic-source share (e.g., paid traffic dropped from 40% to 15%) or anomalous spikes/drops in any top source's daily sessions. 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_diagnose_funnel_drop
ChatGPTConvRadar (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_export_facts
ChatGPTConvRadar (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. Returns {status, request_id, retry_after_s} at once; the files are written in the background. 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, and a stopped comparison runs again.
cr_find_conversion_anomalies
ChatGPTConvRadar (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_full_audit
ChatGPTConvRadar (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_get_account_info
ChatGPTConvRadar (GA4 analytics): the connected GA4 property's name, currency, timezone, available data window, AND the property's website origin (scheme://host) derived from page_location data. Always call this at the start of a session. Combine website_url with paths returned by cr_get_landing_pages, cr_get_product_performance, or cr_query_metrics to build absolute URLs for cr_capture_via_web_fetch — no need to ask the user for the domain unless website_url comes back null.
cr_get_current_state
ChatGPTConvRadar (cross-session continuity): per-tenant snapshot of what's already in flight — last 30-day overview metrics, up to 10 active hypotheses (status surfaced/testing/confirmed sorted by marked_at DESC), last 5 logged changes, and ≤3 most recent open findings. Call this at the start of any session, especially when the user asks "what's in work / in progress / pending / what was I doing", before re-running diagnostics. Lets you continue prior work without making the user re-explain.
cr_get_device_breakdown
ChatGPTConvRadar (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_export
ChatGPTConvRadar (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, calling cr_export_facts with the same arguments continues a table export from the last finished month, or runs a comparison again.
cr_get_funnel
ChatGPTConvRadar (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_geo_breakdown
ChatGPTConvRadar (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.
cr_get_heuristic_check
ChatGPTConvRadar (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_hypothesis
ChatGPTConvRadar (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_landing_pages
ChatGPTConvRadar (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_overview_metrics
ChatGPTConvRadar (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_product_analysis
ChatGPTConvRadar (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_performance
ChatGPTConvRadar (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_screenshots
ChatGPTConvRadar (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_tracking_plan
ChatGPTConvRadar (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_traffic_breakdown
ChatGPTConvRadar (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_voice_of_customer
ChatGPTConvRadar (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_heuristic_check
ChatGPTConvRadar (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_list_capture_sets
ChatGPTConvRadar (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_changes
ChatGPTConvRadar (diary): the user's change diary/journal/changelog — what they shipped and when, with impact verdicts where measured. Use before attributing any metric move ("conversion dropped — did anything change?"), or when the user asks "what did I change", "что я менял", "show my diary/journal". Entries come from cr_log_change, the web diary, audits, and detectors.
cr_list_hypotheses
ChatGPTConvRadar (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_log_change
ChatGPTConvRadar (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_mark_hypothesis_status
ChatGPTConvRadar (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_query_metrics
ChatGPTConvRadar (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_record_verification
ChatGPTConvRadar (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_save_ai_suggested
ChatGPTConvRadar (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_update_change
ChatGPTConvRadar (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_verify_change_impact
ChatGPTConvRadar (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_voice_of_customer
ChatGPTConvRadar (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_assess_traffic_quality
Claudecr_capture_screenshots
Claudecr_capture_via_web_fetch
Claudecr_check_page_speed
Claudecr_compare_segments
Claudecr_compare_to_benchmark
Claudecr_describe_data
Claudecr_detect_traffic_quality_change
Claudecr_diagnose_funnel_drop
Claudecr_export_facts
Claudecr_find_conversion_anomalies
Claudecr_full_audit
Claudecr_get_account_info
Claudecr_get_current_state
Claudecr_get_device_breakdown
Claudecr_get_export
Claudecr_get_funnel
Claudecr_get_geo_breakdown
Claudecr_get_heuristic_check
Claudecr_get_hypothesis
Claudecr_get_landing_pages
Claudecr_get_overview_metrics
Claudecr_get_product_analysis
Claudecr_get_product_performance
Claudecr_get_screenshots
Claudecr_get_traffic_breakdown
Claudecr_heuristic_check
Claudecr_list_capture_sets
Claudecr_list_changes
Claudecr_list_hypotheses
Claudecr_log_change
Claudecr_mark_hypothesis_status
Claudecr_query_metrics
Claudecr_record_verification
Claudecr_save_ai_suggested
Claudecr_update_change
Claudecr_verify_change_impact
Claude
