Personyze

The account's automation rules: what starts each one - a date and time, this campaign's numbers or the whole site's - and what it does: email somebody, post to Slack, call a webhook, pause or publish a campaign (its own, another, or a campaign group), pause or resume one action (of its campaign or another), pause or resume one A/B variation, or set the A/B traffic split. A date rule runs once, once with a switch back at an end date, or repeats - every day, weekdays, weekends or chosen days at a time, optionally switching back at a later time (its "repeats" field; "does" names the actions). Read it when someone asks why they got an alert, why they did not, or why a campaign switched itself off — each row carries what the last check actually measured and why it was skipped, which is usually the answer. Read-only. Creating and changing rules stays in the panel - a campaign's Automation step, or Automation in the menu for the account's own: a rule can email an address or call a URL, and those are not things to set from a conversation. Say that plainly if asked to make one, and say where.

list_automation_rules

Browse Personyze's gallery of ready-made action designs — popups, banners, forms, countdowns, recommendation layouts — plus any this account has saved itself. This is how to start "build me a popup": show a few templates, let the person pick, then create the action from it and tailor the wording. Filter by "query" (matches the name), "tag" (Lead Capture, Countdown, Newsletter, Urgency, Promotion, ...) or "action_type" (Image, HTML Form, Recommendations, ...). Call with no filter to see what the tags are. Returns [{id, name, action_type, tags, preview_image_url}] plus the tags available for narrowing. Present a SHORT list — five or six with their names and tags — rather than everything; the person is choosing a look, not reading a catalogue. Then SHOW the shortlist with get_template_preview, which returns the actual screenshots as inline images. Chat clients do not auto-load a markdown  — it renders as a click-to-load placeholder, so someone choosing between designs ends up opening them one at a time. Templates whose content is a recommendation TEMPLATE can be used as-is but their wording cannot be rewritten afterwards from here; say so if the person picks one.

list_action_templates

Create the campaign one of list_campaign_ideas describes — its targeting compiled, its design attached, and for an A/B idea both variants with traffic split 50/50 by user. In STAGING mode: real visitors keep seeing whatever is live now, and the person publishes it themselves. Always give them the returned url. Supply the idea's required "ask" field; supply "page" only if they want it confined to one URL; supply "placeholder_id" from placeholder_choices when the idea renders inside the page. Give them BOTH returned links: "url" opens the campaign in the panel, "preview_url" opens their own site with the campaign forced on so they can see it — it bypasses the audience rules, which is the only practical way to view something targeted at, say, third-session visitors. If preview_url comes back empty the account has no root page configured: ask them for a page URL and pass it as "page". Read the compiled targeting back to them — a rule that says something slightly different from what was asked for looks identical from the outside. Ask before calling. Creating things is not a read-only lookup.

build_campaign_idea

Build one of suggest_designs_for_my_site's suggestions, end to end, in STAGING MODE - what the panel's "Use this" makes: a new staging campaign that shows only on the suggestion's page, holding its gallery design with the suggestion's words already in it (the design and its editor controls kept). A promotion's row is also added to their Promotions list as a DRAFT. A landing page takes two calls: the first draws it in the look of their site (a few minutes, a little AI credit), the next - with the same token - makes it a landing page campaign. Nothing goes live; publishing stays theirs, in the panel. Only after the person picked the suggestion. A design shown INSIDE the page needs "placeholder" (list_placeholders shows theirs; create_placeholder makes one - where the suggestion's "where" says); one shown OVER the page takes an optional "position" and "show_after_seconds". Then do its next_steps - for a design for one audience, ADD that audience to the page rule with edit_campaign_rules, never in place of it.

build_suggested_design

What is worth BUILDING on this account, as opposed to what is missing from its setup (list_recommendations covers that). Each idea is already matched to a real design from the gallery and carries the targeting it would be built with, so nothing here is a suggestion the platform cannot carry out. Read-only. Every idea names the data it needs: one whose data is not flowing yet carries "pending" saying what to switch on, and still builds into staging. "setup" (light/medium/heavy) says how much building it takes; "addon" names a paid module the idea rides on. An empty list still means the site has no type yet. Report the "ask" and "ask_page" fields to the person: those are the values only they can supply, and build_campaign_idea refuses without the required one.

list_campaign_ideas

Daily performance summary of personalization actions, aggregated per action over the requested date range. Returns campaign_id, campaign_name, action_id, action_name and the counters below. Dates are YYYY-MM-DD. What the counters mean -- use these definitions rather than guessing from the names: n_delivered = times it was VIEWED - the visitor had it on screen, or clicked, closed or converted on it; this is the panel's headline number, "Viewed", so lead with it; n_executed = times it was SENT to the page, including pages where it had nothing to show or no place to appear (the panel's "Sent", formerly called impressions) - never call it views; an action that cannot report a view (Run JavaScript, a redirect, a JSON feed) has no views: report its n_executed as "ran"; n_extra = CLICKS on the action, so "most clicked" means the highest n_extra (two exceptions: on a Web Push Subscribe action n_extra counts subscriptions, not clicks; and on a form action - a Survey, Review Form, Feedback question, HTML Form, Live Form, Popup Builder Form or Recommendations Form - it counts forms SENT, which are submissions, not clicks: report them as "forms sent" and leave them out of clicks and CTR); n_closed = times the visitor dismissed it; n_failed = times it could not run. On an EMAIL: n_executed = emails sent; n_replied = replies people sent to it that day (an out-of-office is not one) and n_answered = how many of those are answered (by the team, the email's automatic reply or the AI) - both left off a row where they are 0, so a row without them had no replies. Click-through rate = n_extra / n_delivered - clicks per view, as the panel measures it since 28 September 2026 (for an action that cannot report a view, per n_executed). Only quote a CTR when its denominator is at least 100 -- below that the rate is noise, so say the sample was too small instead. Every counter also has an n_sessions_* variant counting distinct sessions rather than events. CONVERSIONS: pass goals: true. You then get {rows, goals, campaign_only_goals}: rows carry goal_event_<n>_n_sessions / _n_times for every goal slot this account has, "goals" names each slot once, and "campaign_only_goals" holds the conversions of goals dedicated to particular campaigns (those use no slot, so they never appear as goal_event columns). Do not guess goal_event_<n> numbers - the slots differ per account. An A/B test's variants are its actions, so per-action rows ARE the per-variant split; a control group that shows nothing has no action and no row. products_goal_value / products_recom_goal_value are revenue-style totals.

get_campaign_performance

The conditions that decide when a campaign fires — which pages, which visitors, which sessions — in readable form, plus whether it is active and any start/end dates. Use this for "which campaigns run on my home page", "why isn't this campaign showing", "what targets mobile visitors", or any question about where or to whom something applies. Omit campaign_id to get every campaign, which is what you need to search by page or by rule. Returns [{id, name, state, is_active, active_since, active_till, targeting}] where targeting is the rule text, e.g. "Include on current page: Contains /pricing and not Full URL contains login". state is "live", "staging", "draft (not running)", or a staging/unpublished edit saved on top of a campaign that is still live - that campaign then appears twice: the rules visitors get, and the edit waiting to be published. An empty targeting means the campaign has no conditions and applies everywhere. With campaign_id it also returns "rules" (numbered - edit_campaign_rules removes by that number) and "frequency_cap" (its "How often" limit).

get_campaign_targeting

Switch on reading product events straight out of the site's data layer — no per-event source and no change to the site — for a site whose Tag Manager or gtag already pushes ecommerce events. The item id is taken out of each push. Give "product_id_key" when their pushes name the id something particular ("sku", "item_id"); left empty the id field is guessed per push, which is usually right and occasionally quietly wrong. "data_layer_name" is only needed when the site does not call it dataLayer. This is the first thing to try on a site with GTM: views, cart adds, favourites, purchases and categories at once. It changes what is recorded for REAL visitors immediately — say so before calling.

set_gtm_tracking

How the crawl that fills this account's PRODUCT or ARTICLE catalog from its own site is doing (the catalog screens' "Crawl my site"; not the AI chat's crawl). Reports its settings (start pages, item address pattern, page limit and the highest one the plan allows, schedule), when it last ran and completed, the queue (read, waiting, failed, and the commonest failure reasons), WHETHER THE LAST CRAWL STOPPED AT ITS PAGE LIMIT and which sections of the site the queue holds - a limit reached in sitemap order can leave a whole section, such as the blog, uncrawled - and how much of the crawled catalog is junk: login walls, error pages and titles repeated across many rows, which a widget would recommend. Call it when a crawled catalog seems to be missing items or a content widget recommends the wrong pages.

get_catalog_crawl_status

Change the settings of an action built from a gallery template, exactly as its editor sidebar would: the design and its template controls stay, and the action's HTML is rendered again from the design. THE way to make a widget look like the customer's site and to set up a recommendation. In one call: "settings" (controls by key from get_widget_settings, applied in order — switch a block on before setting controls inside it), "recommendation" (page, algorithm, options, items, fallbacks — the full ordered list, quick_filters, exclude, rules, fill_empty, group_by), "heading" (the widget's own heading — templates spell it three different ways and this picks the right one) and "titles" (the heading per algorithm: main, and one entry per fallback, null keeps the main title). CSS style slots take declarations for one element ("color: #333; font-size: 14px !important"), not rules. A catalog-field control takes "column" and/or "functions" instead of a value — e.g. functions "text_before(' Size ')" to cut sizes off product names; it applies to every copy of that field. A "recommendation" change also settles WHICH PAGES the widget runs on, as the panel's editor does, and the answer's note says what it did - repeat it. "page_group_id" sets that yourself. Recommendation widgets whose algorithm starts from the item being viewed (Cross-Sells, Similar, Others Who Viewed…): never pick the "Product viewed on this page" / "Article viewed on this page" groups when the widget has a fallback that needs no item (Best Sellers, Most Popular, Trending, Recently Published, or fill up with any items) - those groups hide the WHOLE widget, fallbacks included, on every page where no item view was reported (a post missing from the catalog), so that choice is refused. Use a URL page group for the item pages ("Product pages", "Articles") or none. With no such fallback, leave it out: the widget gets that group automatically, as the panel's editor does. Every campaign showing the action must be in staging. Tell the person what you will change before calling, and report the changes returned.

change_widget_settings

Change the settings of an AI Product Finder or AI Content Finder action, exactly as its designer in the panel would - keys and values from get_finder_settings. "values" is an OBJECT of key to new value, e.g. {"finder_title": "Find your next pair", "finder_chips": ["Trail shoes", "A gift under $50"], "voice_input": true, "finder_theme": "light", "accent": "#1e40af", "finder_strategies": ["bestsellers", "new"]}. Texts take the account's variables (${...}); "" gives a text back to the finder's own words. Lists (examples to tap, titles taking turns) are up to four lines. Switches are true/false. A choice takes its stored value or its label. Colours are hex. "finder_only" is the recommendation filter syntax over the item's own fields (p->brand='Acme', Locate('/guides/', p->content_url)) and a rule the finder cannot read is refused, because it would recommend nothing. "languages" adds, rewords or removes a language: {code, path_prefix (its pages start with /<prefix>/) or browser: true (the browser asks for it first), words: {text key: its words there}} or {code, remove: true}. Everything is checked before anything is written, and every problem is named at once. Every campaign showing the finder must be in staging (or a draft). Tell the person what you will change before calling, and report the changes returned.

change_finder_settings

Set how many pages the product or article catalog crawl may queue - the "Page limit" in the panel's Crawl my site. Takes effect on the next crawl (start_catalog_crawl runs one now). Refused above the account's plan cap or the crawler's own ceiling (get_catalog_crawl_status says the highest allowed), and for a crawl rendered in a browser, whose budget Personyze sets. Ask before raising it a lot: every page is a request to their web server.

set_catalog_crawl_page_limit

Open a page of the account's site with a campaign forced on — its staging version, as a first-time visitor, no staging IP needed — and check what its actions rendered: whether each appeared and how fast, where it sits (inside/after which element), its size, heading, how many items and pictures it shows, whether pictures are broken, whether it overflows the screen, errors from the tag, and whether the site elements it should replace ("hidden") are really hidden — on a desktop and on a phone, with a picture of each widget. USE THIS AFTER BUILDING OR CHANGING an in-page widget, before telling the person it is done, and on a product page that should show it. slow: true adds a run as a mid-range phone on a poor connection — where a placement that races the site's own rendering fails. Each run also reports FLICKER and why the tag arrives when it does: the page's first paint and largest paint, when the Personyze tag was requested and loaded, when the tracker answered, when each action appeared, how long the site's own content was visible before an "inside"/"replace" action swapped it, how the tag is loaded (in the HTML <head>, Google Tag Manager, Tealium - which utag.N.js and whether it waits for DOM ready - or other) and whether Anti-flicker is on, with a plain-language "flicker:" verdict and the fix for the site's developer. Use it when someone says the original content shows and then changes. It accepts the site's cookie banner first (accept_consent, default true) - most sites load the tag only after consent - and then reports both the visit where the banner was clicked and a reload with consent remembered; say "measured after accepting cookies" when it did. A LIVE campaign is checked as live visitors get it, and an action of it that has no live version (tagged staging only) is reported by name: real visitors get nothing from it while staging-IP visitors see it - the "works on my phone, not on theirs" report. Takes 30-60 seconds per device (more when slow) — say so before calling.

check_widget_on_site

What a recommendation widget on this account will run into, measured on its catalog — call it BEFORE building one, and tell the person what it finds. Works for a PRODUCT catalog and for a CONTENT catalog (articles, blog posts, pages), and says which this account has. Reports: WHAT A FILTER CAN BE WRITTEN ON — every catalog column and every field the feed adds, with how much of the catalog has a value and, where there are few, which values (a filter on a field nothing carries matches nothing, silently, which is how two widgets on our own account showed nothing for months); which image column is actually filled, because the templates default to image_big_url and it is often not the best one; how much of the catalog is in stock, priced and linked; whether sizes or variants are stored as separate products (the same product twice, and a size in every name — with the exact name function that removes it); how many items each algorithm has data for, which decides the fallback order; and real page addresses to test on. Large catalogs are sampled and it says so. When the algorithm data looks empty or out of date for the catalog there is, check_recommendation_build says why.

check_catalog_for_recommendations

Create or change how the visitor chat behaves. Every field is optional and anything you leave out is LEFT ALONE — send only what is changing, because sending an empty string blanks that setting for real. On an account with no chat yet this creates the configuration, ON when the account holds the AI Chat add-on (its chat already is, by default) and off without it, unless you send "enabled". A chat still meets visitors only where a published campaign places it (create_chat_campaign makes one in staging). "instructions" is the main one — how it should sound, what it should push, what it must never say. It is the account-wide voice; a campaign can add to it but never loosen it. "share_data" says which categories of visitor data the assistant may be told about, and defaults to none: widen it only when the person asks, and tell them what it means. Ask before calling. This changes what real visitors are answered by.

update_chat_settings

What this account counts as a conversion, and whether each one is switched on. Read this before answering anything about conversion rate or value: an account with no goals has no conversion numbers at all, and saying "your conversion rate is 0%" when the truth is "nothing is being measured" is the wrong answer. Also read it before create_goal — there is a ceiling of 12, and a goal that already exists under another name should be reused.

list_goals

Start the product or article catalog crawl now - the panel's "Crawl now": find the item pages from the saved start pages (sitemap, or links) and queue them to be read into the catalog. Optionally saves a new page limit first (same rules as set_catalog_crawl_page_limit). "full" re-reads every page already read, not only new ones. The crawl must already be set up (start pages) in the panel. QUEUED, NOT READ: a background job reads the pages one at a time, so report it as queued and use get_catalog_crawl_status for progress. Ask before calling: it sends many requests to their web server.

start_catalog_crawl

Create a new campaign in STAGING MODE. Call it "staging mode", which is what the panel calls it — saying "draft" sends people looking for a draft screen that does not exist. It is shown only to visitors arriving from a staging IP — real traffic keeps seeing whatever is live now, and the person has to publish it in the panel themselves. Say that plainly when you report back, and ALWAYS give them the returned url so they can open it — a campaign they cannot find is one they cannot publish. Optionally give targeting in plain words ("visitors on the pricing page who have not bought") and it is compiled into real rules — always read the compiled targeting back to the person, because a rule that says something slightly different from what they asked for looks identical from the outside. Ask before calling this. Creating things is not a read-only lookup.

create_campaign_draft

Create a new audience (user segment). Returns the new audience id.

create_audience

Create or update a visitor (user) profile. Provide "fields" with at least internal_id or email so the profile can be matched/deduplicated; other fields (first_name, last_name, phone, custom columns...) are merged into the existing profile (patch semantics). Returns the numeric user_id.

save_visitor

Turn the page types found by a deep site reading (rescan_site with "deep") into real page groups, so campaigns can target "the pricing page" as an object rather than as a sentence. Each group's URL rule is derived ONLY from addresses that were actually read: one observed page becomes an exact rule, several sharing a directory become a prefix rule, and a page type whose addresses have nothing in common is skipped rather than guessed at. Say which you are creating and what rule each carries before calling this. Creating a group changes nothing a visitor sees — nothing references it until an action does — but it does write to the account, so ask first. Already-named groups are left alone, so calling it twice is safe.

create_page_groups

Create a placeholder — a named page location (matched by a CSS selector) where personalization actions can render. Returns the new placeholder id. "place" decides where an action goes relative to that element, and two of its values DELETE page content: "inside" replaces everything already inside the element, and "replace" removes the element itself. For an element that already shows something — a header, a main column, a product section, a shelf — use "after" or "before", which add a sibling and remove nothing. Use "inside" only for an empty element the site added for this purpose. When unsure, "after".

create_placeholder

Turn the conversions found by a deep site reading (rescan_site with "deep") into real goals, so campaigns can be judged on outcomes instead of clicks. This is the highest-value thing to set up on an account with none. Each goal watches either a URL path the crawl actually reached or a CSS selector observed in the markup — nothing invented — and one this account already measures is skipped, so calling it twice is safe. There is a ceiling of 12 goals and this will not exceed it; it creates as many as there are slots for. Conversions are counted from the moment a goal exists and are not backfilled. Use create_goal instead when the person describes a conversion themselves. Say which you are creating first.

create_goals_from_reading

Turn the content locations found by a deep site reading (rescan_site with "deep") into real placeholders, so an action has somewhere to render other than a floating popup. Every selector was checked against the page's actual markup when the reading was stored — nothing here is composed — and a placement whose selector or name this account already has is skipped, so calling it twice is safe. Creating a placeholder changes nothing a visitor sees: it is inert until an action names it. Use create_placeholder instead when the person names a location themselves. Say which you are creating first.

create_placeholders_from_reading

Delete an audience (user segment) by id. This removes the audience definition; visitor profiles are not deleted. Returns the number of rows deleted.

delete_audience

Hide a discovered audience from the suggestions. It stays dismissed even if later passes find it again.

dismiss_discovered_audience

Copy an existing campaign, including its targeting rules, into a NEW campaign in staging mode. Works on any campaign, live or staging — the copy is always staging, so duplicating a live campaign is safe. This is the way to answer "make one like that but for X": duplicate, then use update_campaign_draft to change the name or retarget it. actions='copy' gives the new campaign its own actions to edit independently; actions='link' shares the originals, so editing one changes both — say which you used. THEN ADAPT IT, rather than handing back a copy and stopping. A duplicate is almost never wanted as-is: the point is a campaign like that one, for something else. Read the copy's targeting back a rule at a time (get_campaign_targeting) and its wording (get_action_content), and walk the person through what should change — "this one targets amex.ourvacationcenter.com; which site is this for?", "it says 50% off; what should the new one say?". Ask about the things that are actually IN it; do not offer a generic list of options it does not use. Change what they answer with update_campaign_draft and update_action_content, and leave the rest alone — a copy is a copy precisely because most of it was already right. Ask before calling. Give the person the returned url. SLOW: copying a campaign takes roughly 15-30 seconds, because every action is duplicated. Tell them it will take a moment BEFORE you call it, so the silence is expected rather than a hang, and do not call it a second time while the first is still running — that makes two copies.

duplicate_campaign

Rename a staging-mode campaign, switch it on or off, or replace its targeting rules. A campaign already in staging mode is edited as it is. A LIVE one is refused first, and the refusal offers the person both ways: move it to staging and change it there (it shows nothing to real visitors until they publish again, which is one click), or leave it live and change a copy made with duplicate_campaign. Pass take_off_live only for the first, and only once they have said yes. Give the person the returned url. Give targeting in plain words and it REPLACES every existing rule (a date range from set_campaign_schedule included); the compiled result comes back, with what it replaced, so you can read both to the person. To add or drop one rule and keep the rest, use edit_campaign_rules instead. Ask before calling this.

update_campaign_draft

The copy-paste HTML that puts a recommendation ACTION into an email or an external banner — the panel's Get-Code step, as a tool. This is NOT the site tracking code: when someone asks for "the email code" or "the embed code" of a campaign, this is the tool. It works for the external-media action types ("Offline email", per-item recommendation designs — the ones create_action_from_template says render per recommended item). The snippet is per-slot <a><img> tags whose images are rendered per recipient by the platform; recipients are identified by the email platform's merge tag spliced into the URLs. Pass email_platform so the tag arrives filled in; without it the snippet carries an {INSERT EMAIL HERE} placeholder and you must SAY it needs replacing. An unknown recipient gets the account's fallback items, never a broken image. This is also the flow where going live is safe: an external-media action renders nowhere until this code is pasted somewhere, so publishing its campaign changes nothing on the site.

get_email_embed_code

The account's FEEDBACK answers (the one-question Feedback widgets and forms that save private feedback) over a date range - read-only, as the panel's Feedback page and Feedback tab compute them: NPS (score, promoters, passives, detractors) for 0-10 answers, average and distribution for stars and faces (1-5), % helpful for yes/no, answers and how many carried a comment, the same figures for the period of the same length before (for "is it going up"), the NPS trend (per day up to a month, per week up to half a year, else per 30 days, each point with its own NPS and the running NPS from the start of the range), per question (action) its answers, scores and - for the Feedback type - visits asked, answered and the response rate, and the newest comments. Narrow with action_id or campaign_id. Dates are YYYY-MM-DD, default the last 30 days. An NPS from a handful of answers swings wildly: always say how many answers it rests on. Comments are the visitors' own words, kept private.

get_feedback_scores

Every field a visitor profile can hold in this account — the built-in ones and any custom fields added here. Read this BEFORE save_visitor: that tool can only write fields that already exist, so a value sent to a field nobody defined is silently nowhere. "built_in: false" means somebody added it for this account.

list_visitor_fields

Fetch one personalization action with its editable HTML content (content_begin/content_end) and presenting rules. For a Popup Builder (canvas) design it also returns "texts": every visible text in the design (headline, subtitle, button labels, coupon code, captions) exactly as stored - those are the "find" values replace_action_text takes to put agreed copy into the design.

get_action_content

Give a Surveys campaign its own web page - on the account's own verified domain (go.brand.com/<address>), else on the account's personyze.info address (acme.personyze.info/<address>), which needs no add-on - to share as a link, a QR code or in a text message, exactly as the panel's Sharing step does. The survey's emails and get_survey_email_code need this page. The campaign must be a Surveys campaign (create_campaign_draft with campaign_type surveys) holding a Survey, in staging. only_on_its_page also takes its Survey off the site, so it is shown ONLY on this page and in emails - for a survey meant for a receipt, a package or an email rather than for visitors browsing. The page answers the public once the person publishes the campaign in the panel; until then preview_url shows the staging version. The QR code is on the campaign's Sharing step. Ask before calling.

add_survey_page

Add one web page or one piece of pasted text to the chat's knowledge, and read it immediately — the assistant can answer from it as soon as this returns. Use "url" for a page on their site (a returns policy, a delivery page, an FAQ) and "text" for something they typed or pasted at you. For a whole site use crawl_site_for_chat instead — this is one thing at a time. A page that cannot be fetched is still stored, with the reason: check "status" in the answer and say so, because a source that failed silently is a knowledge base missing a chunk of itself with nothing on screen to say so.

add_chat_knowledge

Set the parts of the customer's own page that are hidden while an in-page action or popup is on the page — for content that TAKES THE PLACE of something: a recommendation widget instead of the store's related-products shelf, a banner instead of its hero. Each selector's elements are hidden only while the action is on the page and visible; when it has nothing to show, or does not run for a visitor, the site stays as it was. Give the parts to hide — the shelf's title, its items, its arrows — never the element the action itself sits inside (that one is skipped, or the action would hide itself). Pick selectors with inspect_page, and afterwards check with check_widget_on_site, passing the same selectors as "hidden". Only when the person asked for their own content to be replaced — never on your own initiative. An empty list removes it. Staging only, like the other draft tools. The same setting is in the panel under the action's placement: "While it shows".

hide_site_elements

Limit how often one visitor gets this campaign: "at most once per session" (max_views 1), "stop after they close it" (stop_after_closes 1), "no more than 3 times a week, then leave them alone for a month" (max_views 3, within_days 7, hide_days 30). Counts views, clicks and/or closes of the campaign's actions (all of them, or action_ids) within this session (the default), within_sessions or within_days; once a limit is reached the whole campaign is hidden for one session (the default), hide_sessions or hide_days. A view counts when the visitor saw it; count: "delivered" counts every delivery, seen or not. This is the campaign's "How often" setting in the panel, and it replaces any cap already there; clear: true removes it. Staging only, like the other draft tools; a live campaign needs take_off_live (ask first) or duplicate_campaign. get_campaign_targeting with campaign_id reads the current cap back. On-site campaigns only: an email, SMS or push campaign has no cap and is refused.

set_frequency_cap

The whole state of this account's visitor chat in one answer: whether it is configured and switched on, how it is told to behave, what it has been given to read (and which of those failed to read), which campaigns put it in front of a visitor, and how much of the conversation allowance is spent. READ THIS FIRST before changing anything about the chat, and read the "note" — it names the ONE thing standing between this account and a working chat, which is usually "switched on but no campaign carries it" rather than anything in the settings. "next_steps" is the rest of the job in order, each step naming the tool that does it: work it to the end rather than stopping at the first success, because a chat that is switched on but unplaced and with nothing to read is indistinguishable from a broken one. A step with "tool": null is a screen, not something you can do — say so and link it. Answers for an account that has never set the chat up too: "configured": false is a normal state, not an error.

get_chat_setup

What tells us that a visitor looked at a product, put one in the cart, bought one, or read an article — and what is MISSING. Everything downstream rests on it: recommendations learn from views, cart targeting needs cart events, "visitors who looked at X" needs views, and a catalog nothing arrives against matches nobody. Read it before promising any of those, and before adding a source, so a second source does not start counting the same event twice. It also says whether each source WORKS, not only that it is set: "health" per source (receiving, quiet, never_received, broken, …) from the same evidence the panel's tracking screens use, a "problem" in plain words for each one that is not working, and "health_summary" for the account. A source can show as switched on and record nothing — a mask cut short or not compiling, a selector that no longer matches — so CALL THIS FIRST whenever someone says recommendations show nothing or the same items, targeting on viewed products or articles "does nothing", or product/article reports are empty, and read any "problem" out before looking elsewhere. A product-view source that reads the URL path is also MEASURED: "product_page_match" says how many recent product-page views it tied to a catalog product, and when language or collection prefixes (/en-us/…, /collections/<c>/products/…) lose them, its "problem" gives the exact mask that would tie them - a change to a live source, so ask before anyone sets it. Takes a few seconds more on such an account. Read-only.

list_tracking_sources

Whether the tracker is actually reporting, per domain. This is what answers "I installed it, did it work" and "why is my campaign not showing" — a campaign on a domain with no traffic is not a targeting problem. "ever_tracked" is the account-level fact: false means no visit has EVER been recorded, which is a missing or broken install rather than a quiet day. The per-domain figures come from the live visit table, so they cover the last day only — a busy site that shows zero there is worth investigating, a brand-new one is not. Read-only.

check_tracking_status

Save an action's design into this account's own template gallery, so the next campaign can start from it instead of being written again. It appears in list_action_templates beside the stock designs, marked as the account's own, and create_action_from_template builds from it. Worth doing when something has been tuned until the person is happy with it and they will want it again — a house banner style, a promo strip, a form they like. Not worth doing for one-off content: a gallery of near-identical designs is worse than none, so check list_action_templates for one of theirs that already covers it and say so rather than adding another. It copies the design as it is now; later edits to the action do not reach the template, and editing the template does not touch the campaigns already built from it. Nothing a visitor sees changes. Ask before calling, and tell them the name you are saving it under.

save_action_as_template