Privatrak

Add a chart to a dashboard. A widget is a saved insights query (the same event_type, filters, breakdown, group_by, measure and measure_property as run_insights_query: an event count, or the sum or average of a numeric detail, scroll_depth or time_on_page_seconds; or up to 4 series) shown over the dashboard's date range as a chart, a single value (visualization number) or a table, so run the query with run_insights_query first and only add it if it shows what the title says. Uses one of that dashboard's widget slots (get_project slots_left). Placed below the other widgets unless x and y are given (12-column grid). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Create an empty dashboard, then fill it with add_widget. Uses a dashboards slot, and every dashboard has its own widget slots (get_project slots_left). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Save a feature rule: events matching its conditions count as feature_name, in past and future feature counts alike (they are worked out from the events). Check it with preview_feature_rule first. Every event it matches counts toward feature_name, including events other features already count: an event counts toward every feature that names it, and no rule takes events from another. Group pages with starts_with or matches on page_path (e.g. matches /products/*), or list pages in one any group (rather than several same-name rules), to give a funnel step a single feature to match. Funnels and flows only pick a rule up from today on. Uses a feature_rules slot (get_project slots_left). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Save a funnel of 2 to 10 ordered steps. Its steps and trait_scope are final (update_funnel changes only its name and goal settings), and it counts visitors only from the day it is created: there is no history to fill in. So check every step with preview_funnel first, and create the funnels that matter early. A step on a data-track name that is not deployed yet matches nothing until the code ships: expected, not broken; tell the user. Uses a funnels slot (get_project slots_left). is_goal makes it a goal in the same call, with an optional goal_value (see update_funnel). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Delete a dashboard and all its widgets. undo_setup_run recreates both. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Delete a feature rule. Its events stop counting as the feature everywhere, past included, unless a data-track name or another rule of the same name covers them; other features are unaffected. undo_setup_run recreates it exactly, with its original id and creation time. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Delete a funnel and every day it has counted. Those days cannot be recovered: undo_setup_run recreates the funnel's steps, but it counts again from zero. Ask the user before deleting a funnel that has been counting. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Search the pages and feature events that appear in user paths, with how often each occurs. Returns each node's key, which is what get_flow takes as root or path. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

Every goal (funnel marked is_goal) for one campaign of list_campaigns: the campaign's visitor-days at each step, and numbers: its conversions, rate and revenue, exactly the row's goal numbers in list_campaigns with that goal. Step 1 is the campaign's visitors when the funnel starts with any page view (first_step_is_any_pageview), else null. Each goal counts from its own goal.data_from: read its coverage, and goal_note, before quoting. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. Quote counts with every percentage; a big change on a small count is noise, not a finding.

One dashboard and its widgets. Each widget's query_config is an insights query: pass its fields to run_insights_query to get the widget's numbers (for a single value, visualization number, with compare_previous). Widgets are what the team chose to watch, which makes them a good place to start.

Daily or hourly usage counts for the top features in a date range, plus totals (interactions, visitors, interactions per visitor) for the range and for the equally long period before. Features are only events with a data-track name or matched by a feature rule; untagged clicks are not features. By hour: the current hour is incomplete, later hours read 0. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. unique_sessions (visitors) is approximate: counted per day from a daily-rotating hash and summed over days, so a returning visitor counts once per day, and shared or changing networks merge or split people.

What visits did next, as a tree up to 4 steps deep from a starting node (default: where visits enter the site). Every count is conditioned on the whole path above it, so it can be read as a journey. Each box lists its top branches plus 'other', 'rare' and 'exit' rows that sum to its visits. Boxes with below_threshold set are too thin to interpret: say so. Expand a branch by passing its key in path; find a root with find_flow_nodes. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

One funnel's steps for a date range: visitors reaching each step, how many dropped from the previous step, conversion from the previous and from the first step, and median time between steps. worst_step_order: the lowest conversion from the previous step. trait_scope says how trait counts (see trait). is_goal, goal_value: as in list_funnels. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. unique_sessions (visitors) is approximate: counted per day from a daily-rotating hash and summed over days, so a returning visitor counts once per day, and shared or changing networks merge or split people. Quote counts with every percentage; a big change on a small count is noise, not a finding.

One funnel's overall conversion and per-step visitor counts per day, week, month or year across a date range -- to tell whether a drop-off changed and when. Buckets with few entering visitors swing wildly; say so rather than reading a trend into them. Buckets marked partial cover only part of their week/month/year (see covers_from/covers_to) or contain today: never read a partial bucket as a drop. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. A period marked starts_before_data begins before the project has data (see data_from): those days read as zero, not as a quiet period.

Headline numbers for a date range (events, unique_sessions, feature interactions, active features) against the equally long period before, with the percentage change, a daily series, top pages (page views) and features. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. A period marked starts_before_data begins before the project has data (see data_from): those days read as zero, not as a quiet period. unique_sessions (visitors) is approximate: counted per day from a daily-rotating hash and summed over days, so a returning visitor counts once per day, and shared or changing networks merge or split people. Quote counts with every percentage; a big change on a small count is noise, not a finding.

The project (the API key's, or the one named by project): name, timezone, plan and how many days of raw events it retains, plus today's date in the project's timezone and the default 28-day range. currency: every goal value and revenue is in it. Also the plan's limits, what the project uses of them, and slots_left: how many more feature rules, funnels and dashboards (and widgets on each dashboard) can be created; null means unlimited. reviews_left: how many more AI reviews save_review can store this month (the account's, all its projects together; null unlimited), until reviews_reset_at. Call it first: every date in every other tool is a calendar day in this timezone.

One saved AI review in full, as plain text with its numbers filled in: scope, key action (goal), period, short answer, confidence, what stands out (or the explanations), each recommendation with its id (update_review keeps a recommendation, with its status, when given its id), status (open, done or dismissed) and status_changed_at, what else was checked, the method, the evidence (label, kind, params and the fields it holds) and the review data it was written from, summarised. The numbers are the values when the review was saved, not today's.

The numbers an AI review of one scope is built on, built by Privatrak: the whole site, one page or one funnel's flow, optionally against a key action (a feature or a funnel). Fixed sections for the scope, each with a plain summary; checks (candidates for what stands out, sorted by the views they affect); and data notes (automated share, origins that began reporting mid-period, a previous period that cannot be compared, bursts). save_review builds the same data again and stores it with the review. Views by people leave out automated visits; flow numbers include them. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. At most 92 days.

For a saved review, every recommendation whose status is done, with the numbers its watch text names read again now (each {{eN.field}} from that evidence, each {{d[REF].field}} from the review data built again for the review's scope and key action; without any, its watch_evidence's main number): over the complete days from the day after it was marked done to yesterday (at most 92), against as many days just before. One row each, with a state (measured, too_early, not_comparable, no_number, unavailable), a plain sentence, the window and the numbers now and before. It compares two periods and never says what caused a difference. Open and dismissed recommendations have no row.

One setup run's changes in the order they were made, each with the definition before and after. A click_problem change is an element's resolve or ignore: created (resolved or ignored), updated (switched, or resolved again) or deleted (set back to open with reopen_click_problem), with the element's identity and kind in before/after. A review change is a saved AI review (created) or an updated one (updated): either a recommendation's status set (update_review_recommendation; before/after hold every recommendation's status) or an edit of the review (update_review; before also carries the whole earlier version).

Mark a click problem as intended, e.g. a heading people habitually click: hidden for good, and nothing that happens later brings it back. When something was fixed use resolve_click_problem instead, so a recurrence shows. Overwrites a resolve on the same element; on an element already ignored it changes nothing and says so. Hides rows only: no count changes and no event is deleted. identity: the row's identity from list_click_problems, all five fields exactly as returned (null stays null; a different text or a null for "" is a different element). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Per AI assistant: answer_fetches (pages read to answer someone; not proof anyone saw the link), search_crawler_requests (its search crawler, PerplexityBot and meta-webindexer too) and visitors (clicked through: list_sources rows in source_keys): different units, never add them. Fetches need server reporting (else 0: fetches_unavailable); robots.txt, llms.txt and sitemaps are not fetches; scanners' requests for secrets (/.env, .git, backups) count nowhere. unconfirmed: AI fetchers their vendor doesn't document, not in total_answer_fetches. *_change: vs comparison_from..comparison_to; null: not comparable (before server_data_from, sources_from). Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days.

Visitors from links tagged with utm_campaign or utm_source, grouped by utm_campaign, utm_source and utm_medium of their first page view that day, paged, with top utm_content, utm_term and landing pages; total_visitors is all of them. No data before sources_from. goal adds a goal's conversions per row: read goal_note. get_campaign_goals: every goal's steps for one row. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. unique_sessions (visitors) is approximate: counted per day from a daily-rotating hash and summed over days, so a returning visitor counts once per day, and shared or changing networks merge or split people.

Click problems (dead clicks, rage clicks and more), worst first, paged. Four signals, each with the dashboard's name for the user: dead (No effect: nothing visibly happened), rage (Repeated clicks: a rapid burst), error (Errors: an uncaught error followed), slow (Slow responses). Each counts once per element per page view: page views, not clicks or visitors. Default status: open and reopened (Happened again): a dead or error click after it was resolved, even outside the period (since counts); rage and slow clicks never reopen. Pass a row's identity as is to resolve, ignore_ or reopen_click_problem; element_selectors: the exact selectors that had problems, to find them in code. changes compare total_with_signals. Max 92 days. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

The project's saved dashboards, with how many widgets each has.

What people clicked and submitted in a date range: one row per element (event type, page, text, tag, generalized selector), most events first. features lists every feature counting its events today, with via (data_track or rule): an event counts toward every feature naming it, so these can sum to more than events. unassigned_events: events no feature names; unassigned=true keeps only rows where that is all of them. total_events sums events over every matching row, all pages. Events, not visitors. Pageviews and custom events are not listed. At most 92 days per call. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Quote counts with every percentage; a big change on a small count is noise, not a finding.

The rules that name events as features (conditions on page, element, text, referrer and URL query parameters; every item of conditions must match, and an item {any: [...]} matches when one of its conditions does). Together with data-track attributes in the site's markup they decide what counts as a feature. An event counts toward every feature that names it, so rules may overlap; a feature with no events may simply have no rule.

Features ranked by use (event count) in a date range, paged. compare_previous adds each feature's count in the equally long period before and the change (the biggest movers), plus stopped: features used before with no events now, which the ranking cannot show and which is the clearest sign something broke. Features are only events with a data-track name or matched by a feature rule; untagged clicks are not features. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. A period marked starts_before_data begins before the project has data (see data_from): those days read as zero, not as a quiet period. Quote counts with every percentage; a big change on a small count is noise, not a finding.

The project's saved funnels with step counts, trait_scope (how each counts when read for one trait: visitor or step, see get_funnel), is_goal (a goal: its conversions per source and campaign are in list_sources and list_campaigns with goal = its id) and goal_value (what a conversion is worth, in get_project's currency; shown while it is a goal), and each one's entering and completing visitors and conversion over counts_period: the 31 days up to and including today, NOT the 28 complete days the other tools default to. Use it to pick funnels, never to quote or compare numbers; call get_funnel for comparable per-step counts.

Pages by views, paged; search; sort_by views, entries, time_on_page, scroll_depth, page. A page is origin + path (no query/anchor). views: pageview events, not visitors. entries: visitors landing there, from entries_from. avg_time_on_page_seconds, avg_scroll_depth (% down): mean of views reporting one; null: none. avg_scroll_depth_change is in points. Null average change: engagement_change_unavailable, else no previous value. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. A period marked starts_before_data begins before the project has data (see data_from): those days read as zero, not as a quiet period. Quote counts with every percentage; a big change on a small count is noise, not a finding.

The projects this connection can use: each one's id, name, timezone and access (read, or write: read and set up). Pass an id as project to any other project tool; when there is more than one project, every such tool needs it. An API key reaches exactly one project.

The properties that can be filtered or broken down by: the standard ones, plus the detail names (attribute_keys; use them as attrs.KEY: data-track-* attributes and track() details) and URL parameter names (query.PARAM) seen in a date range. Standard entries with kind number (scroll_depth, time_on_page_seconds: a page view's scroll depth in percent and active seconds, null where no value arrived) take only their operators (equals, greater_than, less_than, exists; the two comparisons strict) with a whole number from minimum to maximum, can be the measure_property of their measures, and are no breakdown. Details (attrs.KEY) also take greater_than and less_than, as numbers: attrs.order_value greater_than 100. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

The values a property has taken in a date range, e.g. the page paths or feature names that occurred -- for building exact filters for run_insights_query. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

The project's saved AI reviews (written by the customer's assistant with the product_review prompt), newest first, paged: scope with its page or funnel, key action (goal), title, period, confidence, when it was saved, and its recommendations counted by status (open, done, dismissed). Find the previous review of a scope here; read it in full with get_review.

The project's setup runs, newest first: when, by which key, what each created, changed and deleted, and whether it has been undone. Use it to find a run to undo, or to see what an earlier session already set up.

Where visitors came from, paged: search, social, AI, sites, campaign tags, direct (withheld referrers too). A visitor counts once a day, by their first page view: its utm_source/ref, else the referrer; landing_pages are those pages. internal_visitors (from the site itself) and unattributed_visitors (no page view) are not in total_visitors. No sources before sources_from. goal adds a goal's conversions to rows, hosts and tags: read goal_note. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. Today is still in progress: a range including it reads as a drop against complete days. unique_sessions (visitors) is approximate: counted per day from a daily-rotating hash and summed over days, so a returning visitor counts once per day, and shared or changing networks merge or split people.

Check a feature rule before saving it; saves nothing. matched_events: events the conditions match in the range, pageviews included. Rules have no precedence: saving counts all of them toward feature_name, whatever else names them. already_in_feature: those feature_name already counts; new_events: the rest; unassigned_events: those no feature names yet. also_counted_as: other features that also count some of them and keep doing so (not a conflict; a long list can mean too broad). With feature_name, feature_total_after_save is what list_features will show once saved. top_elements shows what matched. Events, not visitors. At most 92 days per call. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

Check draft funnel steps before create_funnel; saves nothing. Per step, how many events it matched in the range, matched exactly as a saved funnel matches them. Events, not visitors, and no conversion: past conversion cannot be computed for steps that were not a funnel then. A step with 0 matched_events would count nobody: fix page_path (exact, as stored, e.g. /products/:id; see list_property_values; for many pages use a feature rule with starts_with or matches and step on its feature) or the feature name, unless it is a data-track name that is not deployed yet. At most 92 days per call. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday.

One page of Privatrak's documentation as Markdown, in full, with its title and URL. page is a slug such as no-code-tracking, or a docs URL from search_docs; an unknown page answers with the valid slugs. Use it when a search_docs snippet is not enough, and to follow the documented instructions (tracker attributes, framework setup) exactly instead of recalling them. Quote the URL when pointing the user there.

Remove a widget from its dashboard. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Rename a dashboard. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Take back resolving or ignoring an element: its resolve or ignore is removed and it is back to open (never dismissed), as if it had never been resolved or ignored. This is not the status reopened (Happened again), which the API sets by itself when a resolved element recurs; a Happened again row needs nothing from this tool. Fails when the element is not resolved or ignored. identity: the row's identity from list_click_problems, all five fields exactly as returned (null stays null; a different text or a null for "" is a different element). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Mark a click problem fixed, once you have fixed the element in the code. It leaves the default list and comes back by itself as reopened (Happened again) when a dead (No effect) or error (Errors) click on it arrives after now; rage (Repeated clicks) and slow (Slow responses) clicks do not bring it back. On an element already resolved, reopened (Happened again) or ignored it overwrites that and moves the cutoff to now, which hides a Happened again row: only resolve after a real fix. Hides rows only; no count changes. identity: the row's identity from list_click_problems, all five fields exactly as returned (null stays null; a different text or a null for "" is a different element). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Count events or sum/average a numeric detail by day/week/month/hour, filtered, split by a property (top 10; table 100) or as 1-4 series (A-D); compare_previous adds the change vs the prior period. Counts events, not visitors. Use summary_total or a series' total. Non-numbers skipped: say if left_out set. Buckets marked partial cover only part of their week/month/year (see covers_from/covers_to) or contain today: never read a partial bucket as a drop. By hour: the current hour is incomplete, later hours read 0. Dates are the project's calendar days, YYYY-MM-DD (timezone: get_project); timestamps are UTC. Omit from/to for the last 28 complete days, ending yesterday. A period marked starts_before_data begins before the project has data (see data_from): those days read as zero, not as a quiet period. Quote counts with every percentage; a big change on a small count is noise, not a finding.

Save an AI review, which the customer reads in the dashboard. Scope, key action and period as for get_review_data (Privatrak stores those numbers with the review; never send them), then the short answer, confidence, what stands out, 1-3 recommendations, what else was checked, method. Call it with dry_run true first and fix every problem it lists. Numbers: every number from a tool result is a placeholder, marked in the dashboard as looked up by Privatrak: {{d[REF].field}} for the review data (from get_review_data's refs, no evidence needed), {{eN.field}} for evidence. Only dates, step numbers and your own arithmetic stay plain text. A placeholder is shown with its own unit and sign, so never write a unit (%, s, seconds, points) or a + sign right before or after one. Counts toward the plan's reviews per month (get_project reviews_left). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Search Privatrak's own documentation and get the best-matching sections: page, section heading, URL and the start of the section's text. Use it before telling a user how Privatrak works or how to set something up (data-track and data-track-* syntax, track() and custom events, the tracker's options, framework setup, how funnels, sessions and features count, plans and limits, connecting an AI assistant) instead of answering from memory, and quote the URL when pointing the user there. Search in the product's own words: dead clicks and rage clicks are click problems (/docs/click-problems), shown on the click map too. read_docs_page returns a whole page. The docs describe the product, not this project's data.

Start a setup run: a group of changes that undo_setup_run (or the customer, in the dashboard) reverts in one step. Returns run_id; pass it to every create_, update_, rename_, delete_, add_, remove_, resolve_, ignore_, reopen_ and save_ call that belongs together, so one undo covers the whole setup. Before changing anything call get_project (slots_left: how many rules, funnels, dashboards and widgets the plan still allows) and read what exists already (list_feature_rules, list_funnels, list_dashboards, list_click_problems), so a second pass updates instead of duplicating.

Undo a setup run in one step: delete what it created, restore what it changed, recreate what it deleted; click problems it resolved or ignored are open again (never dismissed), and ones it set back to open are resolved or ignored as before; a review it saved is deleted unless a recommendation's status changed since or the review was updated since; recommendation statuses it set are put back, and a review it edited gets its whole earlier version back, unless the review was updated again or a status set since. dry_run defaults to true and changes nothing: always run it first and tell the user what the undo would do, above all any funnel_history (days a funnel counted are deleted with it and cannot come back) and anything skipped. Then call again with dry_run false. Changes someone else made after the run are never overwritten; they are skipped and reported. A run can be undone once.

Replace a feature rule's name and conditions. This re-labels the feature's events back to the start of retention, so preview the new conditions with preview_feature_rule first. undo_setup_run puts the old definition back. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Change a funnel's name, whether it is a goal, and its goal_value; what you omit stays. Steps and trait_scope never change: a different step means a new funnel. A goal's conversions (visitor-days reaching its last step that day) show per source and campaign in list_sources and list_campaigns; unmarking keeps the funnel and its history. At most 5 goals per project, and a goal still uses a funnels slot. goal_value: none, fixed (an amount per conversion, applied to past days too) or detail (an attrs.KEY of the last step's event summed as revenue, counted only from the day it is set). Amounts are decimal strings in the project's currency (get_project). Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Update a saved AI review in place after the user's feedback, however far it takes the review, instead of saving another (save a new one only when the user asks for a separate one). Read it with get_review first, then give the whole review as it should now be: save_review's arguments plus review_id; nothing of the old one is kept unless given again. Give each recommendation that stays its id: it keeps its status. from and to are required. Changing the scope, page, funnel, key action or period counts toward the plan's reviews per month; text, evidence or recommendations alone do not. Call it with dry_run true first (counts_as_review says whether it counts) and fix every problem it lists. A placeholder is shown with its own unit and sign, so never write a unit (%, s, seconds, points) or a + sign right before or after one. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Set a saved review recommendation's status: done (the customer acted on it; the next review of the same scope reports it), dismissed (they decided against it) or open again. Only when the user says so. Setting the status it already has changes nothing. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.

Change a widget's title, query (its visualization included: number is a single value) or position; what you omit stays. A new query replaces the old one whole, measure, measure_property and series included (left out, the widget counts events): test it with run_insights_query first. Pass run_id from start_setup_run so this undoes together with the rest of the setup; leave it out (never "") to start a new chat run, whose run_id is returned and should go on every later change.