Tracking

tracking_reports_event_volume

Traffic for a date range as TWO headline figures plus a data-quality block.

Tool

tracking_reports_event_volume

Traffic for a date range as TWO headline figures plus a data-quality block.

Traffic for a date range as TWO headline figures plus a data-quality block. totalEvents counts events. visitorsDeduplicatedPerUtcDay counts PEOPLE, over both populations at once: visitors who consented are deduplicated by their anonymous_id, visitors who declined by a server-derived daily_visitor_key. It is one COUNT DISTINCT, not a sum of two figures, and there is no second set of numbers to add to it. READ THE FIELD NAME LITERALLY — the caveat is the metric, not a footnote. The daily key is rebuilt from a salt that is destroyed every UTC midnight, so the same declining visitor gets a DIFFERENT key tomorrow and is counted again. Consequences you must state whenever you report this number over more than one day: (1) weekly and monthly unique-visitor counts are OVERSTATED, and the longer the window the worse it gets — a visitor who comes back on ten days counts as ten people; (2) returning-visitor, retention, frequency and loyalty analysis DO NOT WORK on this traffic at all, because the identity that would link the days was never created. This is not a defect awaiting a fix and no post-processing recovers the real figure; Plausible, PostHog and Matomo concede the same limitation about their own daily keys. dataQuality.visitorsOverstated tells you whether it bites for the window you asked for (true when the range spans more than one UTC day and there is declining traffic in it), and dataQuality.utcDaysInRange is how many UTC days the range spans. For an exact people count, ask for a single UTC day. dataQuality describes how COMPLETE the two headline figures are and contains no metric of its own — never present anything inside it as a headline number and never add it to anything. cookielessShare and noBannerShare are the fractions of events that arrived from declining visitors and from sites running no consent banner. consentGrantedEvents + cookielessEvents + noBannerEvents = totalEvents. noBannerEvents (nobody was ever asked) is deliberately kept apart from cookielessEvents (the visitor declined); merging them would tell a customer people refused when nobody was asked. identifiedEvents is a DIFFERENT cut — events carrying an anonymous_id — that overlaps the consent buckets and is NOT the complement of cookielessEvents; never add those two together.

Behavior

HTTP: GET /tracking/reports/event-volume

Arguments

Name	Type	Required	Description
to	string	•	No description in the catalog.
from	string	•	No description in the catalog.
domain	string	—	No description in the catalog.

Response

Field	Type	Always
to	string	•
from	string	•
domain	string	•
computedAt	string	•
dataQuality	object	•
totalEvents	number	•
visitorsDeduplicatedPerUtcDay	number	•

Try it

Traffic for a date range as TWO headline figures plus a data-quality block.

When to use

Example

Ask your agent something like this:

Traffic for a date range as TWO headline figures plus a data-quality block.

The agent will invoke tracking_reports_event_volume with these arguments:

{
  "to": "<to>",
  "from": "<from>"
}