Event collection
Torno collects product events first-party, on endpoints you control, and validates everything before it can reach analytics, Experiments, or Loops. This page covers the four core calls and the checks that sit between the wire and your data.
The four calls
| Call | What it records |
|---|---|
track |
A named event with properties |
identify |
The link between a Subject and a signed-up person, with traits — honored in profile mode only |
expose |
That a Subject saw a specific Change variant; the basis for measurement |
goal |
A conversion tied to a Metric |
Consent updates and historical imports arrive at the same boundary and pass the same checks. The SDKs wrap these calls; the wire protocol supports partial batch acceptance, page-exit beacons, and compressed payloads with strict decompression limits.
Endpoints and write keys
Browser batches arrive at first-party collect endpoints, typically served from your own domain through a proxy or CNAME. An environment write key selects the Property and environment, and the two key types are constrained differently:
- client keys work only from origins you have registered;
- server keys can require HMAC request signing, and signed requests are rejected on clock skew, replay, or tampering.
Revoking a key takes effect immediately, and every key has its own rate window.
The accepted envelope carries a stable event ID, type and name, timestamps, the Subject key, properties, and consent state. Country is derived from the request and the IP address is then discarded. Client timestamps outside tolerance are clamped and labeled rather than believed.
The event dictionary
The dictionary is a versioned tracking plan: which events, goals, properties, and identify traits are valid. Incoming data is validated against the active version. Enforcement is per environment — development warns, production quarantines or rejects — and loosening it is an owner-audited action. The dictionary can also live in your repository and change through code review; see Loops as code.
Integrity checks
- Dedup: duplicate event IDs within a 24-hour window are dropped, including duplicates inside a single batch.
- Bot rules: declared crawlers are dropped at the edge; behaviorally suspicious traffic is quarantined, not silently deleted.
- Quarantine: held batches go through review, then release or purge. Quarantined events are excluded from aggregates, and releasing them restores those aggregates deterministically.
Consent at collection
The collect boundary consults the same consent authority as the rest of Torno, so an event that lacks the required consent is refused at the door rather than filtered at query time. Each accepted event records the consent state it was collected under. Details in Identity and privacy.
Where accepted events go
Accepted events fan out through registered seams to Cohorts and Subjects, Change exposure, the Customer handoff, Signal derivation, analytics, Experiments, and revenue. One deliberate asymmetry: identify forwards traits to the Customer handoff but stores none of them on the event or the Subject.
Health and tail
The ingest surfaces show health and volume, accept and quarantine verdicts, alerts, the active dictionary version, bot rules, and the quarantine review queue. A live tail of raw arrivals exists for debugging; access to it is scope-gated and audited. Agents get the same health, dictionary, and quarantine operations over API, CLI, and MCP — see Agent interface.