Standard events

Fidero recognises a fixed set of standard event names. Send one and Fidero maps it to the format each destination expects (ad platform, analytics tool or warehouse) with no per-event mapping to configure. That’s why the naming is decided for you: the standard name is the contract that makes the mappings automatic.

You fire the everyday events from the browser with the SDK. Anything mission-critical belongs on your backend, and two events only exist there. This page lists them all.

The platform overview covers why mapping is Fidero’s job rather than something you configure.

Using standard events

Pass a standard name as the event in a track call. Use the fidero.Event constant for typo-safety, or the string directly. From your backend, the same string goes in the event field of an HTTP API request.

// with the constant
fidero.track({ event: fidero.Event.SIGNUP_COMPLETED });

// or the string
fidero.track({ event: "signup_completed" });

The standard set

Each of these has a fidero.Event constant, and the name is accepted from the browser and from your backend alike – same string, same mappings, whichever side sends it.

Constant	String	Fire when
`LEAD_FORM_COMPLETED`	`lead_form_completed`	Someone submits a form to express interest
`SIGNUP_COMPLETED`	`signup_completed`	Someone creates an account
`USER_LOGGED_IN`	`user_logged_in`	Someone logs in
`SEARCH_PERFORMED`	`search_performed`	Someone runs a search
`ITEM_LIST_VIEWED`	`item_list_viewed`	Someone views a list of items, like a category page
`ITEM_VIEWED`	`item_viewed`	Someone views a single item
`ITEM_ADDED`	`item_added`	Someone adds an item to their cart
`CHECKOUT_STARTED`	`checkout_started`	Someone starts checkout
`PAYMENT_INFO_ADDED`	`payment_info_added`	Someone enters payment details
`PURCHASE_COMPLETED`	`purchase_completed`	Someone completes a purchase
`TRIAL_STARTED`	`trial_started`	Someone starts a free trial
`SUBSCRIPTION_STARTED`	`subscription_started`	Someone starts a paid subscription without a trial
`SUBSCRIPTION_CANCELLED`	`subscription_cancelled`	Someone cancels their subscription

Where to send from

Send mission-critical events from your backend – that’s anything tied to revenue: purchase_completed, subscription_started and trial_started. Your billing system is the authoritative record for all three, and a page that fires an event and immediately navigates away can drop it, but a webhook can’t. The browser is the fallback when no server path exists.

signup_completed matters just as much, but it’s the event that merges someone’s anonymous browsing into their new profile, and the SDK carries the anonymous ID for you – so fire it from the browser. Sending it from your backend means capturing the anonymous ID client-side and passing it with the auth event yourself. Identity stitching shows that pattern.

Server-only events

trial_converted and subscription_renewed have no fidero.Event constant: your billing system generates them, so there’s nothing to fire from a browser. Send them from your backend with the HTTP API.

String	Fire when
`trial_converted`	A free trial converts to paid
`subscription_renewed`	A paid subscription renews

Server-side events covers how to send these, and why a renewal from your billing system still arrives with its attribution.

Acquisition and lifecycle

Some business concepts span more than one event. For a subscription business, acquiring a paying subscriber is two events: subscription_started for a paid signup with no trial, and trial_converted for a trial that becomes paid. Any metric built on that – new-subscriber revenue, customer acquisition cost – has to read both events, or it misses every subscriber who came in through a trial. subscription_renewed and subscription_cancelled are lifecycle events, not acquisition: they belong in retention metrics.

Event properties

Properties carry the detail of an event. The money events (purchases, subscriptions, renewals) lean on three in particular.

fidero.track({
  event: fidero.Event.PURCHASE_COMPLETED,
  properties: {
    transaction_id: "ord_9Fh4",
    value: 42.0,
    currency: "GBP",
  },
});

value number

The monetary value of the event, such as order revenue.

currency string

ISO 4217 currency code, such as GBP. Fidero fills in your project’s default if you leave it out and there’s a value.

transaction_id string

A unique ID for the transaction. Fidero uses it to count the same purchase exactly once – in Fidero, and in destinations that receive it through both a browser and a server channel.

For the full set of properties, line items and user traits Fidero recognises, see Data schema.

Custom events and overrides

You’re not limited to the standard set: track accepts any event name. A custom event has no built-in mapping, so you request how it should map to each destination. The built-in mappings are defaults, not fixed behaviour – if a standard event needs to reach a destination differently in your setup, you request that override the same way. Configuration & changes covers how.

Methods How to call track(), and the rest of the browser API.

Data schema The full field reference – properties, line items and user traits, plus the envelope.

Server-side events Send events from your backend, including trial conversions and renewals.