Skip to content

Configuration

The install snippet calls fidero.init() with your project ID and nothing else, which is all the configuration most sites need. To do more, pass a second argument: turn on verbose logging while you build, or seed identity for a visitor who’s already logged in.

Pass options as the second argument to the init() call in your install snippet.

fidero.init("YOUR_PROJECT_ID", {
debug: true,
});
projectId string required

Your project’s unique ID, provisioned during onboarding. The install snippet already passes it.

options object

Optional client-side settings. Everything else about your project is configured server-side.

debug boolean default: false

Enable verbose console logging.

userId string

Seed a known user’s ID at startup, so the first events on the page already carry their identity.

traits object

Seed traits for a known user at startup, such as email or name.

delivery object

Tuning for the browser delivery queue that stores each track event until the server confirms it. The defaults suit most sites: maxQueueSize (100 events), maxAttempts (10), maxEventAgeMs (24 hours), maxEventSizeBytes (32 KB), backoffBaseMs (1 second) and backoffCapMs (60 seconds). Data quality & delivery covers the queue.

With debug: true, Fidero logs its progress to the browser console with a [Fidero …] prefix: boot, integration loading and the full payload of each dispatched event. Every track call also appears in your Network tab as a request to Fidero. Between the two, you can confirm the whole install without a dashboard.

If the page already knows who the visitor is (they’re logged in), pass their identity to init(). Every event on the page then goes out already identified, with no separate updateIdentity call.

fidero.init("YOUR_PROJECT_ID", {
userId: "user_5d21c8",
traits: {
email: "grace@example.com",
name: "Grace Hopper",
},
});

For anonymous visitors, pass nothing. Fidero creates the anonymous ID and looks after it. To set or change identity after startup, use updateIdentity. Identity covers how one profile follows a visitor from anonymous to known.

Everything that decides what Fidero does with your events lives server-side, keyed to your project ID: your destinations and their mappings, your consent rules and which integrations load. None of it goes in init(), which is why this surface stays small. To add or change a destination, you request it and your configuration updates on the server, with no redeploy on your side.

How we work covers the model, Configuration & changes the request flow. The case for holding configuration on the server rather than in your code is on the platform overview.