Data
Events
Event schema, properties and naming conventions
Anatomy of an event
{
"uuid": "3f1a5c2e-9b7d-4e21-8c44-1d2f3a4b5c6d",
"user_uuid": "0c9e6c1a-2b3d-4e5f-8a90-1b2c3d4e5f60",
"project_uuid": "27e1acd1-4d09-406d-86da-8525723430bb",
"parent_name": "page_view",
"type": "page_view",
"created_at": "2026-09-11T12:00:00Z",
"properties": { "page": "/", "referrer": "https://example.com" }
}parent_name is the name you sent as event_name; type is one of track (default), page_view or identify.
Types
| Type | Use it for | Dashboard |
|---|---|---|
track | Any custom action | Events, top events, funnels, segments |
page_view | Screen or page views (the Flutter navigator observer sends these) | Page views and views-per-visit cards |
identify | Recorded automatically when a user is identified | User timelines |
Properties
- Flat objects only; nested objects are stringified.
- Values are stored as strings: send
"79"or79, both read back as"79". - Keys are case sensitive. Pick a convention (
snake_case) and keep it. - There is no fixed cap on the number of keys, but the whole request body is limited to a few hundred kilobytes; keep events small.
Naming conventions
- One verb per event, past tense or imperative:
signup_completed,checkout_started. - No identifiers or values in names (
purchase_prod_123becomespurchasewithproduct_id). - Reuse names across platforms so web and mobile land in the same funnel step.
Timestamps
Single events are stamped on arrival. Batch items may carry created_at (ISO 8601), which is how you import history or flush a client-side queue with the original times.
Where events show up
New events appear on the Events page within seconds; daily aggregates behind the overview cards and the time series refresh continuously from the materialized views.