Engagement report

The Engagement report shows how many shoppers your assistant reaches on the site, and how many of them actually engage with it. Open Reports in the sidebar and choose Engagement, or go to /dashboard/sites/{siteId}/reports/engagement. It's the fourth item in the Reports section, after Overview, Conversations, and Sales, before Quality.

The report has four tabs under its title, each its own page:

• Report: the engagement funnel and rate, the charts and the per-widget and per-device breakdowns. This is the page the sidebar opens. Everything under What it shows is on it.
• Starter performance: a table of the starter questions shown in the period. See Starter performance tab.
• Exposures: the raw funnel events, newest first. See Exposures tab.
• Page views: the most viewed pages of the site over the last 30 days. See Page views tab.

The first three tabs share the filter bar's date range and Device selection. See How the tabs share the period and the device. The Page views tab has no filter bar: its window is always the last 30 days.

Just below the filter bar, a population statement states in plain language what's counted: every session exposed to the embedded tag on your site, with the Playground and the AI Storefront writing no engagement events into it. The same statement sits under the filter bar of the Starter performance and Exposures tabs, so the three never describe the population differently.

If no stage of the funnel has a session in the selected range, the funnel shows an empty state in place of its bars. The other cards keep their own empty states, so a quiet range never shows zeroed figures.

How the engagement rate is definedCopy Anchor Link

Engagement rate is the sessions that viewed a widget and opened the conversation from it, divided by the sessions that viewed a widget. Both sides count distinct sessions, so a shopper who sees the widget three times and opens the panel twice counts once on each side.

The same figure, under the same name, shows on every surface: the KPI tile here and on the Overview report, the per-widget table, the by-device card, a widget's Performance tab, the Engagement rate (7d) column of the widgets list and the engagement report of the MCP server.

• Only opens from a widget count. An open with no widget behind it, such as one started from a trigger you added yourself or from the loader's open command, is left out.
• The view has to be recorded. A session that opened from a widget but has no recorded view (a blocker stopped the page-side signal) is left out of the numerator, so the rate never goes above 100%.
• One decimal, rounded up. The rate is shown to the next tenth of a point: 7.01% reads 7.1%, and an exact 7.1% stays 7.1%. The displayed rate can sit up to 0.1 point above the true one.
• Variations are in points, with one decimal. The change against the previous period is computed on the rates as displayed, so 7.1% to 7.4% reads +0.3 pts.
• No widget views, no rate. A range with no widget view shows a dash (—) on the tile and in the tables, and the tile says "No widget views in this period". It is never rendered as 0%.

What it showsCopy Anchor Link

Everything in this section is live, scoped to the current site and the selected date range.

KPIsCopy Anchor Link

The top of the Report tab is one Engagement funnel: six figures in the order a visitor reaches them, with the engagement rate beside it. Every figure counts distinct sessions in the selected range.

• Exposures: sessions where the iAdvize script loaded on a page of your site. It is the base of every share on the Report tab.
• Widgets loaded: sessions where a widget's configuration was applied and it could show on that page. Before 21 October 2026 this counts only sessions that saw a widget.
• Widgets mounted: sessions where the spot for a widget exists in the visitor's page.
• Widget views: sessions where the visitor actually saw a widget on screen. It is the base of the engagement rate.
• Conversations opened: sessions where the visitor opened the chat from a widget.
• Conversations started: sessions where the visitor sent a first message, from a widget or not. The engagement rate doesn't read it.

Each stage shows its count and its share of exposures ("N % of exposures"), printed beside the figure on the bar. The tooltip also gives the share of the stage above ("N % of the previous step"). The first stage has no share, and a stage whose previous stage is zero shows none. Each stage has an i control that gives its definition on hover or focus.

A stage can be higher than the one above it. The report shows the measured figure and doesn't clamp it. When that happens, the stage's bar has a note on hover or focus:

• Widgets loaded: an ad blocker can stop the script without stopping the widget.
• Widget views: a view was not recorded, for example because a blocker stopped the widget's own signal.
• Conversations started: the chat started without a widget open, such as from a button on the page.

Conversations started has no figure for a range that ends before 27 August 2026, the day it began to be recorded. Its bar reads Not tracked, and its note reads "Recorded from" that date. A range that starts before that day and runs past it shows the count for the days it covers, with the same "Recorded from" note.

If no session reached any stage in the range, the funnel shows the empty state "No widget traffic in this period" instead of its bars.

Engagement rate is the tile beside the funnel. It's a dash, with the tile saying "No widget views in this period", when the range has no widget view. When comparison is on, it shows the change in points against the previous period (e.g. "+3 pts"). The badge is omitted when the previous period had no rate. The funnel stages have no delta badge.

Widgets loaded is counted from the tag's widget_loaded and widget_mounted events, plus the sessions that saw a widget: a session that saw a widget necessarily mounted one, and one that mounted one was necessarily loaded. So Widget views never exceeds Widgets loaded. These counts are exact from 21 October 2026. Before that date the stage reads low, and when the selected range starts earlier, a line under the funnel says so.

Widgets mounted is the third step: the sessions in which the spot for a widget exists in the visitor's page. The mounted count also decides which widgets the mount-failure card reports as Never appeared. The per-widget table shows each widget's views and engagement rate.

Engagement over timeCopy Anchor Link

A chart with one point per day for the selected range, plotting Exposed, Widget views, Opened, and Started as four separate lines rather than stacking them: they're successive funnel stages, not parts that add up to a whole, so overlaying them side by side is the right read. A day with no events of any kind still appears on the chart at zero rather than being skipped. On a range of two calendar days or fewer the chart has one point per hour instead, labelled in your time zone, with hours that haven't started yet without a value rather than at zero. Each stage is counted in the hour of its own event, so an hour can show more Opened than Widget views when the view happened an hour earlier. The days are still UTC days. See Charts per hour on a short period. Like the other reports' charts, this always reflects the current period only. The comparison toggle affects the KPI deltas above, not this chart.

Widgets: per-widget engagement rateCopy Anchor Link

A table listing every engagement widget on the site, sorted by engagement rate (best first): its name, format, views in the selected range, and its own engagement rate (sessions that viewed this widget and opened it ÷ sessions that viewed it); a dash, sorted last, when it had no views, or Not configured in the format column for a widget with no version at all. Each row links to that widget's own Performance tab for the deeper per-widget funnel. A widget's figures roll up every version that was live during the range, not just its current one, so republishing mid-range doesn't split its history across two rows.

By deviceCopy Anchor Link

A small table (one row per device: Desktop, Mobile, Tablet, or Unknown, whichever recorded a widget view) showing Views, Opened, and the Engagement rate for that device, with the same definition as the site tile. A device with no widget view has no row. It's a table rather than a chart because three figures per device don't fit one chart axis cleanly, and the rate is the one that actually answers "does device matter here."

With the Device filter set, this table narrows like every other figure on the page, so picking Mobile leaves one row. To compare devices side by side, clear the filter.

What the Device filter narrowsCopy Anchor Link

Pick one to three devices and every figure, chart, table and list on the page covers those devices only: the funnel, the engagement rate, the volume chart, the widgets table, the widgets that failed to mount, the by-device table and the page-type bar. The Starter performance and Exposures tabs follow the same selection. Checking all four devices is the same as checking none. The one exception is Running experiments.

If nothing in the period matches, the by-device table and the page-type bar say "No data for these devices" and "No session in this period matches the selected devices", rather than the usual "no data yet" wording, so you can tell a filter from a lack of traffic. The Exposures tab reads "No exposure matches the selected devices" when it is empty, and the Starter performance tab reads "No question was shown" with a note that the device selection may be the reason.

On this report, Unknown is an event that recorded no identifiable device. The AI Storefront and the Playground write no events here at all. iPads running Safari count as Tablet. Events recorded before that detection shipped (see the changelog) keep Desktop for those iPads, so a period that spans the change shows Tablet rising and Desktop falling with no change in traffic.

Running experimentsCopy Anchor Link

When a widget on the site has an experiment running, a Running experiments section lists it: the widget, its two versions (the champion against the candidate), when it started, how far it is toward the traffic floor and whether the result is conclusive. Each row links to the widget. The section doesn't appear when no experiment is running.

The device filter does not apply to it. An experiment's arm counts are its own population, and they must match what the widget's Experiment tab shows. While a device is selected, the section says "Experiment figures are not filtered by device." so it isn't read as narrowed.

Conversations opened by page typeCopy Anchor Link

A bar showing how opens split across the five page types (Home, Category, Product, Content, Blog), plus a No page type bucket. The type recorded for an open is the page's effective type: the one you declare on the page or, when you declare nothing, the one your site's Pages hold for that address.

No page type counts opens with no type attached: a page with no declaration and none held in Pages, or an older tag bundle. It also holds opens recorded as checkout before that stopped being a page type, so the report never shows a type that no longer exists.

Widgets that failed to mountCopy Anchor Link

Appears only when at least one widget recorded a mount failure in range: an inline button or Starters widget whose configured mount point wasn't found on the page. This is a configuration signal, not a performance one: a widget with no mounted session in range and at least one mount failure reads as "Never appeared", distinct from a widget that mounted fine and simply had nobody click it. The rule uses mounted sessions, not views, so a widget placed below the fold, with a mount failure on another page, is not called never appeared. A widget with some mounted sessions and some mount failures elsewhere reads as "Mounts on some pages and not others": partially broken, not fully. Each row links to the widget's own page. See Place an inline button on your pages to fix a mismatched selector.

Starter performance tabCopy Anchor Link

The Starter performance tab, at /dashboard/sites/{siteId}/reports/engagement/starter-performance, lists every starter question that was shown at least once in the selected period. It is a table of questions, not a chart, and it carries the same population statement as the report.

Each row holds the question's wording (in the site's default language, or its first available text if it has none in that language), its performance verdict, its click-through rate on each surface it rendered on (welcome screen, question bar, chat bubble, and the inline Starters card, labelled Starter questions), and three columns for all surfaces combined: Impressions, Clicks and Click-through. A click is a conversation started from that question, so this click-through rate is a different measure from the engagement rate.

• Cells are shaded from pale to deep green by rate. The shading is scaled on every question of the period, not only the page you are looking at, so one shade means the same rate on every page and under every sort.
• A surface a question never rendered on reads Not shown here, never a 0% rate.
• Each surface cell also shows the impressions and clicks behind its rate.

Sorting. The Impressions, Clicks and Click-through headers sort the whole table, not just the page on screen. The default is impressions, largest first. A first click on a header sorts largest first, a second click on the same header reverses it. The per-surface columns don't sort. Changing the sort goes back to the first page.

Paging. The table shows 50 questions per page, with Previous and Next under it and a "1 to 50 of 120" count. The sort and the page position live in the address, so you can bookmark or share a page.

Questions shown to nobody. A question with no impression in the period, under the current device selection, has no row.

Empty states. A site with no starter question reads "No starter questions yet", with a Go to Questions button. A site whose questions were all unseen in the period reads "No question was shown". When a device is selected, that message adds that the device selection may be the reason.

Only the date range and Device apply. This tab has no comparison toggle. The questions grid and a question's own page stay fixed to the last 14 days. This tab follows the period you pick.

Exposures tabCopy Anchor Link

The Exposures tab, at /dashboard/sites/{siteId}/reports/engagement/exposures, shows the raw funnel events the period's Exposed, Widget views, Conversations opened and Conversations started figures are computed from, one row per event, not aggregated into any rate. The Report tab no longer carries a preview of this list, so there is no See all link: switch to the tab.

Its filter bar offers the date range and Device, same as the report. There's no other filter, search box, or sorting on this table; it's always newest-first, and no row is clickable: the Conversation column shows the raw id as text, not a link to the transcript. A result count above the table shows how many events match the period. Empty for the period shows an explicit message rather than falling back to older events. The same population statement appears here too.

Each row shows:

• Type: one of Tag loaded, Chat bubble seen, Widget seen, Widget applied, Widget mounted, Widget mount not found, Starter question shown, Conversation opened, or one of the three Panel reduced state button events: Reduced button shown, Opened from the reduced button and Reduced button hidden, each recorded at most once per tab session.
• Session: the session id the event was recorded under, or a dash for none.
• Conversation: the id of the conversation the event is tied to; a dash when none exists yet (a Tag loaded row, for instance).
• Device: the shopper's device: desktop, mobile, tablet, or unknown.
• Occurred at: when the event was recorded.

This list reads its own underlying events rather than the exposed count, so it is independent of the funnel on the Report tab.

Page views tabCopy Anchor Link

The Page views tab, at /dashboard/sites/{siteId}/reports/engagement/page-views, lists the most viewed pages of your site over the last 30 days. Its figures are the same as the Views (30 d) column of the Pages list, so the two screens always agree.

The tab has no date range, device or comparison control. Page views carry no device, and the window is fixed.

Each row shows:

• Page: the page's address, its path without the domain and without the query string, in bold. The page's title sits beside it when the page has one.
• Views (30 days): the page's views in the window, with a bar scaled to the most viewed page in the list.

The list is sorted most viewed first. It shows at most 50 pages, with no paging and no sorting. A page with no view in the window is left out.

The figures are recomputed once a day, not on each view. The tab says when they were last computed ("Figures computed" followed by the date). A view from after that run is not in the table until the next one.

Pages that differ only in their query string share one path, so they show the same figure. The table then lists them as two rows with the same address.

When the tab shows no tableCopy Anchor Link

The tab shows one of two explanations instead of a table. Neither shows zeros.

• Page-view counting is off for this site. The tab says so and points you to Settings, Site access, where you switch counting on or off for each site. Switching counting off hides the table at once. The figures drop to zero at the next daily run, and switching it back on brings them back at the next run.
• No page was viewed in the last 30 days. Counting is on, but no page of the site has a view in the window. Pages appear here once shoppers view them.

Over the API and MCPCopy Anchor Link

The Starter performance and Exposures tabs can be read outside the dashboard, for a period of at most 366 UTC days and one device at a time, one page per call. The Page views tab can be read there too, with no period, device or paging.

• Starter performance: GET /api/v1/sites/{siteId}/starter-questions/performance, or the starter_questions report of the MCP tool get_report.
• Exposures: GET /api/v1/sites/{siteId}/exposures, or the MCP tool list_exposures.
• Page views: GET /api/v1/sites/{siteId}/page-views, or the MCP tool list_page_views. Both take only the site. They return the same rows, and countingOn tells you whether counting is on, so an empty list is not read as no views.

The Report tab's figures are in the engagement report of get_report.

How the tabs share the period and the deviceCopy Anchor Link

The date range and the Device selection are one setting for the Report, Starter performance and Exposures tabs, not one per tab. The Page views tab is not part of it. The filter bar remembers what you pick in a browser cookie, and every tab reads it back when its address names no period or device. So a period or a device you choose on one tab is still there when you click another.

Two limits:

• The tab links carry no period. They rely on that remembered setting. A period or device that only exists in an address you were sent (a shared link, for example) is not carried to the other tabs until you change something in the filter bar.
• Comparison stays on the Report tab. The compare-to-previous-period checkbox only appears there, and the other tabs ignore it. The sort and the page of the Starter performance table are not carried either.

What this report doesn't cover (yet)Copy Anchor Link

The report always shows a note at the bottom about what's still missing, even when the KPIs and charts above are showing real data:

• No revenue or commerce outcomes. Add-to-cart, order, and revenue figures have no writer in the events ledger yet, so they're left out entirely rather than shown as an empty chart.

Choosing a range and comparingCopy Anchor Link

The Engagement report uses the same header as the other reports: the same date range picker and compare-to-previous-period checkbox.