Skip to content

Events

Everything Fidero does starts with an event – a record of one thing that happened. A page view, a signup, a purchase, a renewal in your billing system: each one arrives as an event, and events are what Fidero enriches, connects and delivers to your tools.

This page covers the envelope that record travels in. Standard events covers the names, and Data schema covers the fields.

The envelope

Section titled “The envelope”

Every event shares one envelope, whether the SDK sent it from a browser or your server posted it directly. Here’s a signup, complete:

{
  "event": "signup_completed",
  "anonymousId": "c81f4a2e...b07",
  "userId": "user_7d21c4",
  "timestamp": "2026-03-02T14:07:31Z",
  "properties": {
    "method": "google"
  },
  "context": {
    "traits": {
      "email": "leo@example.com"
    }
  },
  "channel": "web"
}

Six parts:

  • What happened. event – a name from the standard vocabulary, such as signup_completed. Standard events lists the full set.
  • Who. userId is the person’s ID in your system. anonymousId is the first-party ID Fidero gives every visitor before they’re known. This signup carries both – it’s the moment the two meet. Identity covers how they resolve into one profile.
  • When. timestamp, an ISO 8601 string. If you leave it out, it defaults to when the event arrives.
  • The detail. properties – what the event has to say about itself. Money events carry value, currency and a transaction_id. Product events carry items[]. Data schema lists every field.
  • The person. context.traits – facts about the person rather than the event, such as email or name. Traits stick to the profile, not just the event that carried them.
  • Where it happened. channel – web, mobile or server.

Those six parts are the event itself. The transport fields alongside them (authToken, projectId, type, messageId) are on the HTTP API.

Where events come from

Section titled “Where events come from”

Most events start in the browser: the SDK captures page views from the first load, and you fire the rest with track. When something happens away from a browser – a renewal in your billing system, a webhook from a payment provider, a change in your CRM – your backend posts the event straight to the HTTP API.

Either way it’s the same envelope, with channel recording where it started. A server event arrives with no browser session behind it, so Fidero connects it to the person’s profile and fills in the context it already holds for them. Server-side events covers why those events matter. Attribution covers the context that comes back.

Between arrival and delivery

Section titled “Between arrival and delivery”

Every event gets the same treatment on the way through, and each part of that treatment has its own page:

  • Identity – the event joins one unified profile for the person, anonymous or known
  • Attribution – the campaign context Fidero holds for that person rides along to every destination
  • Consent & privacy – the person’s consent decides which destinations the event may reach
  • Data quality & delivery – the event is formatted for each tool, counted once and delivered

How the pieces fit traces one event through all of it, and the platform overview covers the architecture behind the treatment.

Section titled “Related”
Standard events The event names Fidero recognises and maps, browser and server.
Data schema Every field an event can carry: properties, line items and user traits.
Identity How anonymous visitors and known users become one profile.