Skip to main content
Every published widget records a small set of events from your visitors’ browsers: page views, opens, suggested-question clicks, conversations and cart adds from chat. A widget’s Analytics page counts them, and an experiment’s results show the same numbers per variant. Every number is a plain count of what visitors did, so you can check it against your own view. Rates are always shown with the counts behind them (for example 412 / 5,210).

​
Where to find it

  • A widget’s Analytics page. Open the widget and switch from Builder to Analytics at the top, or click the chart icon in the widgets list. Pick the last 7, 30 or 90 days and filter by device, new or returning visitors, UTM source, UTM campaign and landing page. The source, campaign and landing page lists offer the 50 most common values in the range, with their visit counts. The daily series uses your browser’s time zone.
  • An experiment’s results. While an experiment runs or after it ends, its page shows the same metrics with one column per variant, over the time it ran (up to the last 90 days of it). An experiment that covers several widgets can show one of them at a time. Experiments that ran before analytics was collected show their conversation outcomes instead.
Results refresh every few minutes: they include activity up to the time shown beside Refresh (the last 5-minute mark), and Refresh reads them again. The page’s address keeps the range and filters, so a link opens exactly what you see. New or returning is decided once per visitor, by their first visit in the range: new if the widget had never seen them before it, returning if it had. All of their visits in the range count under that choice, so new and returning visitors add up to the total.

​
Metrics

​
Headline

Visitors are not comparable to your site analytics. The visitor id is kept per site address, so www. and shop. count as two visitors (who can see different experiment variants); Safari clears it after 7 days without a visit; visitors who block the widget, haven’t consented or use browser automation aren’t counted. Other bots are, as in any script-based analytics.

​
Panels

List value added from chat is an estimate. It uses the product’s list price when it was added, before discounts, shipping and tax. Items removed later still count, items added outside the chat don’t, and it doesn’t mean an order was placed. It is shown per currency, with no conversion.

​
Counting rules

  • A visitor is counted once for anything they did at least once in the range. Rates are over every visitor in the range (or assigned to the variant), whether or not they opened the widget.
  • A conversation counts once the visitor sends a message or clicks a quick action: opening the widget starts one by itself. A resumed chat is part of the conversation it resumes.
  • Experiments compare variants per visitor, the unit that is assigned. There are no significance tests; the experiment page warns when the variants’ visitor counts are further from their weights than chance allows (chi-square, p < 0.001), which means assignment is broken.

​
What Anyreach receives

The embed loader sends these events, in batches, to POST /core/public/web-widgets/{id}/events: The envelope sent with each is the visitor, session, widget, conversation and experiment ids, the page path, device type, UTM source, medium and campaign, and whether the visitor is returning. Never sent: message text, the question text a visitor saw (it can carry values read from your page), form and feedback answers, identify traits and user ids, your track goals, full URLs, query strings, page titles, the page’s referrer (where the visitor came from), and the journey events (session_started, page_left, session_ended). Page paths are stored with identifiers masked: a path segment that is all digits, a UUID, contains @, or is a long token with digits becomes * (/account/orders/1234 → /account/orders/*); readable slugs such as /products/ooni-koda-16 stay. Anyreach drops a batch without telling the browser when the widget is unpublished or not collecting, the page’s origin is not in the widget’s allowed domains, or the sender looks like a crawler. An event stamped with an experiment is dropped unless that experiment runs on the widget (or stopped less than an hour ago) and assigns that visitor that variant. Each batch carries your site’s origin (never the path) in its Origin and Referer headers, whatever referrer policy your page sets. Under a no-referrer or same-origin policy some browsers would otherwise send Origin: null, and the allowed-domains check would drop every event from that page.

​
Turning it off

  • Collect analytics, on the widget’s General tab, turns it off for every visitor of that widget: nothing is sent, and your own page still receives the widget’s events. It isn’t part of the widget’s settings that presets and experiment variants change. An experiment can’t start on a widget that is unpublished or not collecting, and the switch can’t be turned off while an experiment on the widget is running or paused.
  • config({ analytics: false }) on your page stops it for that visitor, for example until your consent banner is answered. Switching it back on reports the current page once; nothing from while it was off is ever sent.
  • config({ pageEvents: false }) stops Anyreach counting page views, and your page’s journey events, while widget and conversation events still count.
Collection is on by default.

​
Stored data and deletion

Nothing expires automatically yet. A widget’s analytics are deleted with the widget. To delete one visitor’s analytics across your organization, for a data-subject request, call DELETE /core/widget-analytics/visitors/{anonymous_id} with the web_widgets:manage scope; the visitor’s anonymous_id is what window.anyreach.getContext() returns in their browser.

​
API