Data quality & delivery
Delivery is the wrong test of whether tracking works. An event can return a 200, land in a dashboard and still be useless: wrong format, missing identifiers, unmatchable at the destination. Nothing errors, so nobody notices until numbers stop reconciling.
This page is the model behind that: what “useful” actually requires, the five layers where data breaks, and the machinery Fidero runs so events arrive deduplicated, correctly formatted and delivered.
Delivered ≠ useful
Section titled “Delivered ≠ useful”Every event has two parts: whether it arrived, and what’s inside. Destinations only confirm the first. Meta accepts a conversion without a click ID or hashed identifiers – it just can’t match it to the ad. GA4 accepts an event that never joins a session. A warehouse accepts a row with no attribution context. In each case the request succeeds, the dashboard populates and the data is quietly worthless.
The platform overview walks one such event field by field – what a “successful” delivery looks like next to a useful one. The rest of this page is the systematic version: where the breakage happens and what prevents it.
Where data breaks
Section titled “Where data breaks”Tracking breaks in five places, and each layer depends on the ones before it – a failure early on propagates through everything downstream:
| Layer | What has to be right | What breaks when it isn’t |
|---|---|---|
| 1. Browser collection | Events fire, schemas stay consistent, identity holds across pages and domains | Missing or inconsistent events, fragmented identity |
| 2. Browser consent | What fires matches what the visitor consented to | Under-tracking, or non-compliant over-tracking |
| 3. Server delivery | Identifiers, formatting, hashing, dedup keys and client-server coordination meet each destination’s requirements | Events deliver but don’t match |
| 4. Server consent | Server events honour the consent captured in the browser | Webhooks fire without consent, or block wrongly |
| 5. Memory | Server-only events get the browser context re-attached | Hollow events – delivered, unmatchable |
Each layer has its own home in these docs: collection is Events and Identity, the two consent layers are Consent & privacy, and memory is Attribution and Server-side events. All five are handled in the platform rather than in configuration you maintain. The platform overview makes that argument. What’s left is layer 3, and that’s the rest of this page: deduplication, per-destination formatting and delivery.
Counted once
Section titled “Counted once”The same conversion often reaches Fidero twice – the browser reports the purchase and your server reports it again from the payment webhook. That’s by design: dual delivery is more reliable than either path alone. It only works if the copies collapse back into one conversion.
Fidero deduplicates on IDs, not heuristics. Give every conversion a stable
transaction_id and the SDK blocks client-side repeats of the same transaction.
Every event also carries a messageId Fidero generates, which stands in as the
dedup key when no transaction ID applies. Each destination then receives its own
native dedup key – Meta’s event_id, for example, is set from the
transaction_id, so the browser and server copies of a purchase count once in
Ads Manager rather than twice.
There’s nothing probabilistic in any of this. What that lets Fidero guarantee is on Guarantees & coverage.
Formatted per destination
Section titled “Formatted per destination”Arriving in the right shape is destination-specific work. Ad APIs want identifiers hashed exactly right (SHA-256 email, normalised phone numbers). GA4 wants its own event names and parameter vocabulary. Each platform has required fields.
Fidero’s adapters carry those requirements, so the formatting, hashing, normalisation and event-name mapping happen in the platform rather than per event in your configuration. Events a destination can’t use – unmapped names, non-eligible types – are dropped by its adapter instead of being sent as noise. And when a destination changes its API, we publish an adapter update on our end, so it reaches every project with no action from your team. What each destination delivers and needs is on Destinations.
Delivered, and known to be
Section titled “Delivered, and known to be”Reliability starts in the browser: the SDK writes each event to a durable queue before any network activity, then delivers it with retries and backoff. A flaky connection or an abandoned page doesn’t lose the event – it drains on a later page view.
Server-side, delivery to each destination is retried and monitored. Fidero tracks delivery success per destination, so a failing integration surfaces as an alert rather than a quiet gap in your numbers. The delivery figures Fidero commits to are on Guarantees & coverage.