How the pieces fit

The Quickstart got one event flowing. This page is the system around it: the pieces you work with, and what Fidero does with a single event as it travels through them.

There are three. The SDK you install in the browser. The one endpoint your events reach. And one piece of configuration, held on the server, that governs both. Why the server sits at the centre is on the platform overview: the architecture, and the case for it. This page stays at the level of what you install, what you send and what comes back.

The shape of it

  YOUR SOURCES         ONE ENDPOINT        ON FIDERO'S SERVER    YOUR TOOLS
  ------------         ------------        ------------------    ----------
  Fidero SDK    --+                        read your config      Google Ads
                  +-->  POST /v1/t   -->   enrich + format  -->  GA4
  your servers  --+                        deliver               warehouse, CRM

One endpoint takes everything, whether it comes from a browser or straight from your servers. One config, held on Fidero’s server, governs both the SDK and what happens to an event after it lands. Everything else is built into the platform, not wired up by you: the formatting each tool needs, deduplication, identity and consent.

The three pieces

The SDK

The Fidero SDK is the script you drop into your site’s <head>. From the first page load it captures page views, click IDs and the campaign context around a visit, and it establishes a first-party identity for the visitor before any of that can be lost. You talk to it through a small set of methods: track, page, updateIdentity, updateConsent, reset and ready. Everything you send goes to the endpoint below.

The install is the whole of the Quickstart. The full method surface is on SDK methods.

The endpoint

Every event lands at a single endpoint:

POST /v1/t

The SDK posts here for you. Your own servers post here too, for events that never touch a browser – a subscription renewing, a webhook firing, a CRM record changing. One endpoint and one event shape, authenticated per project. The envelope and auth are on the HTTP API.

The config

A single configuration file on Fidero’s server is the source of truth for both the SDK and the endpoint. It’s deliberately light: which destinations are on, the credentials they need, and the occasional override. The opinionated parts live in the platform, not in your config. Fidero decides how each event is mapped and formatted for each tool.

Because it’s server-held, you change behaviour by asking for an outcome (“send purchases to TikTok”, “send server events to GA4”), and it propagates to the SDK and the endpoint on their next request, with no redeploy on your side. How we work covers that model, and Projects & configuration covers the config boundary.

One event, traced end to end

Start weeks before the conversion. Someone clicks a Google ad and lands on your site:

https://yoursite.com/?gclid=Cj0KCQjw...aAmsL&utm_source=google&utm_medium=cpc&utm_campaign=spring_subs

The SDK captures gclid and the campaign parameters on the first page load, before a redirect can drop them, and sends them to Fidero against this visitor’s anonymous profile. Nothing has converted yet. The context is simply kept.

Weeks later, they subscribe. Here the conversion fires from the browser:

fidero.track({
  event: "subscription_started",
  userId: "user_8f3a91",
  properties: {
    transaction_id: "sub_4Qb1Z7",
    value: 29.99,
    currency: "GBP",
  },
});

Here’s what reaches POST /v1/t. Notice what isn’t in it: no campaign context. That was a different visit weeks ago, so this event doesn’t carry it.

{
  "event": "subscription_started",
  "messageId": "2f9c1b7a-4e08-4c2a-9b1d-7a0e5d2c44af",
  "anonymousId": "a3f2c9d4...e91",
  "userId": "user_8f3a91",
  "properties": {
    "transaction_id": "sub_4Qb1Z7",
    "value": 29.99,
    "currency": "GBP"
  },
  "context": {
    "traits": {}
  }
}

Now Fidero looks up this person’s profile, finds the context captured on that first visit, and re-attaches it. It resolves the anonymous browsing to user_8f3a91, counts the conversion once using transaction_id, and formats the result for each destination. The delivered event carries what the raw event never did:

{
  "event": "subscription_started",
  "messageId": "2f9c1b7a-4e08-4c2a-9b1d-7a0e5d2c44af",
  "anonymousId": "a3f2c9d4...e91",
  "userId": "user_8f3a91",
  "properties": {
    "transaction_id": "sub_4Qb1Z7",
    "value": 29.99,
    "currency": "GBP"
  },
  "context": {
    "traits": {},
    "attribution": {
      "firstTouch": {
        "touchpointId": "7a1e6d3b-4f28-49c0-9e5a-b81c3f7d2e60",
        "channel": "Paid Search",
        "source": "google",
        "medium": "cpc",
        "isDirect": false,
        "referringDomain": "google.com",
        "referrerUrl": "https://www.google.com/",
        "landingUrl": "https://yoursite.com/",
        "landingTimestamp": "2026-06-04T10:02:11Z",
        "campaign": { "source": "google", "medium": "cpc", "name": "spring_subs" },
        "clickIds": { "gclid": "Cj0KCQjw...aAmsL" },
        "otherParams": null
      },
      "lastTouch": {
        "touchpointId": "7a1e6d3b-4f28-49c0-9e5a-b81c3f7d2e60",
        "channel": "Paid Search",
        "source": "google",
        "medium": "cpc",
        "isDirect": false,
        "referringDomain": "google.com",
        "referrerUrl": "https://www.google.com/",
        "landingUrl": "https://yoursite.com/",
        "landingTimestamp": "2026-06-04T10:02:11Z",
        "campaign": { "source": "google", "medium": "cpc", "name": "spring_subs" },
        "clickIds": { "gclid": "Cj0KCQjw...aAmsL" },
        "otherParams": null
      },
      "currentTouch": {
        "touchpointId": "c93d0f7e-2b5a-4e18-a6c4-5f9e1d3b8a72",
        "channel": "Direct",
        "source": null,
        "medium": null,
        "isDirect": true,
        "referringDomain": null,
        "referrerUrl": null,
        "landingUrl": "https://yoursite.com/",
        "landingTimestamp": "2026-06-25T09:15:42Z",
        "campaign": null,
        "clickIds": null,
        "otherParams": null
      }
    }
  }
}

That gclid arrived weeks before the subscription started, on a different visit. The visit the subscription fired on was direct, so it sits under currentTouch with no campaign on it. The ad click lives on under firstTouch and lastTouch – both the same visit here, because it’s the only marketing touchpoint Fidero has seen for this person. The channel on each touchpoint is derived on Fidero’s server, not captured from the URL. Fidero kept the context and added it back, so Google Ads can match the conversion to the click, GA4 sees one continuous journey, and your warehouse gets a complete row. It works the same when there’s no browser at all – a renewal posted from your server picks up its context on the way through. The platform overview covers the architecture that lets the server hold that context.

Where to go next

You’ve seen the pieces and one event move through them. From here:

The concepts Each piece of the trace in depth, one page per concept.

Server-side events Send events straight from your backend, and Fidero completes them with the context it kept.

Destinations Where the enriched event goes (ad platforms, analytics, your warehouse), and how you turn one on.

Straight to a concept: events, identity, attribution and data quality.