Activities
An activity is one thing that happened to a person: a page viewed, an order completed, a ticket scanned. The catalogue below is generated from the service's own definitions, so it is what the service enforces today. A page per activity lists its fields, an example and a live form.
Three things decide what a sender may put in one: the write key's class (browser, server, platform), the activity's mode (open or strict) and its fields' classes (plain, identifier, attribute). Money travels in the revenue block, the campaign in the touch block, places in the geo block.
Web and forms
What the browser SDK and the shop send, with a browser key, and what a backend may send with a server key. A browser key is public, so these activities never carry revenue, and the identity evidence they produce is only claimed until something verified confirms it. The basket activities trace a purchase from the first item to the payment redirect; together they are what an abandoned-basket journey reads.
| Activity | Sent with | Mode | Revenue | Identity evidence | What it says |
|---|---|---|---|---|---|
viewed_page | browser, server | open | — | — | A page was viewed. The SDK's page() call becomes this; it is what web analytics is made of. |
started_session | browser, server | strict | — | — | A visitor's session began. Carries the touch: how they arrived, and with which consent. |
started_basket | browser, server, platform | strict | — | — | A visitor started shopping: the first item went into an empty basket. |
added_to_basket | browser, server, platform | strict | — | — | An item went into the basket: a ticket type or a product, with its quantity and shown price. |
removed_from_basket | browser, server, platform | strict | — | — | An item was taken out of the basket, with the quantity removed. |
entered_details | browser, server, platform | strict | — | yes | The buyer entered their details in the checkout: an email, a phone number, a name. |
placed_basket | browser, server, platform | strict | — | — | The buyer placed the basket: the shop created the order and sends the browser to the payment. Replaces started_order. |
identified | browser, server | strict | — | yes | A visitor told the site who they are: a login, or an email typed into a form. |
submitted_form | browser, server | open | — | — | A form on the site was submitted. |
subscribed_newsletter | browser, server, platform | strict | — | yes | Someone signed up for a mailing list. |
started_order (retired) | browser | strict | — | — | Retired on 2026-10-17: use placed_basket. Sent directly it is quarantined with reason retired; as a tracking call it stays raw. Stored rows stay. |
Ticketing
Derived from orders by the ticketing supplier's mapper (Weeztix today), sent with a platform key. Money and identity evidence live here, so every activity is strict.
| Activity | Sent with | Mode | Revenue | Identity evidence | What it says |
|---|---|---|---|---|---|
completed_order | platform | strict | — | yes | An order was paid: the buyer and what was bought, with the campaign it came through. |
issued_ticket | platform | strict | positive | yes | A ticket was issued as part of a paid order: one per ticket, with the ticket's own revenue. |
issued_product | platform | strict | positive | — | An order-level product was bought (parking, merchandise, a drink voucher): one per product line, with its revenue. |
refunded_ticket | platform | strict | negative | — | A ticket was refunded: negative revenue against the ticket's event. |
personalised_ticket | platform | strict | — | yes | A ticket was personalised: the holder gave their details, which may differ from the buyer's. |
Scanning
Derived from scan records at the gate, sent with a platform key.
| Activity | Sent with | Mode | Revenue | Identity evidence | What it says |
|---|---|---|---|---|---|
scanned_ticket | platform | strict | — | — | A ticket was scanned in at the gate. |
scanned_product | platform | strict | — | — | A product was consumed at a scan: a drink voucher, a parking entry. |
Cashless
From a cashless partner on a platform integration or an organiser's own system, with a server or platform key.
| Activity | Sent with | Mode | Revenue | Identity evidence | What it says |
|---|---|---|---|---|---|
activated_wristband | server, platform | strict | — | yes | A cashless wristband (chip) was linked to a ticket. |
made_cashless_payment | server, platform | strict | positive | — | A cashless payment at a bar or stand: revenue on the chip. |
topped_up_wallet | server, platform | strict | — | — | Money was loaded onto a cashless wallet. |
refunded_wallet | server, platform | strict | — | — | The unspent balance of a wallet was returned. |
Mail
From the mail webhook of a sending platform, with a server or platform key. The message id ties them together.
| Activity | Sent with | Mode | Revenue | Identity evidence | What it says |
|---|---|---|---|---|---|
received_email | server, platform | strict | — | — | A message was delivered to an address. |
opened_email | server, platform | strict | — | — | A message was opened (as far as the mail platform can tell). |
clicked_email | server, platform | strict | — | yes | A link in a message was clicked. |
bounced_email | server, platform | strict | — | — | A message bounced. |
unsubscribed | server, platform | strict | — | — | The person unsubscribed through the mail platform. |
confirmed_subscription | server, platform | strict | — | yes | The double opt-in link was clicked: the subscription is confirmed. |
Consent
The raw consent facts: what was shown, what was ticked, under which text. Who is reachable is resolved by the CRM, never here.
| Activity | Sent with | Mode | Revenue | Identity evidence | What it says |
|---|---|---|---|---|---|
granted_consent | server, platform | strict | — | — | Consent was given, for a purpose on a channel: the raw fact, with the text and the box. |
withdrew_consent | server, platform | strict | — | — | Consent was withdrawn, for a purpose on a channel. |