Skip to content

Guarantees & coverage

Fidero commits to two kinds of number, and keeps them separate. What the platform controls outright is guaranteed: stated as rules with their preconditions, not as percentages. What your audience and setup determine is measured as coverage, against a named denominator, with targets set per engagement rather than published as universal figures.

This page states both, plus the one commitment that stays a percentage (the delivery SLA) and the levers that raise coverage.

Fidero is deterministic end to end: no probabilistic matching, no fuzzy joins, no fingerprinting. So where the platform controls the outcome, the commitment is a rule conditioned on a precondition – not a percentage that implies a failure rate that doesn’t exist.

Guarantee The rule Conditioned on
Identity resolution 100% – one profile per person, resolved on exact keys only The user is identified at init, or a stable userId has been set
Consent enforcement Every resolvable consent signal enforced exactly, per third-party destination A consent object is on the event or on file – absent is a deliberate passthrough
Deduplication Each conversion counted once, at the SDK and via each destination’s native dedup key A stable transaction_id on the event

The precondition is the honest part: the guarantee holds for every event or user that meets it, and the share meeting it is the coverage measured below. The mechanics behind each rule live on their own pages – Identity for exact-key resolution, Consent & privacy for why absent isn’t all-denied, and Data quality & delivery for the dedup keys.

Coverage is the share of your events or users that meet a guarantee’s precondition. That share depends on your audience and setup: ad-blocker rates, iOS share, how early users identify. So Fidero measures the ceiling in your stack and sets the target per engagement, during onboarding. Fidero publishes no universal coverage figure, because across different audiences an honest one doesn’t exist. The platform overview makes the fuller case for this split.

The share of attributable conversion events that carry a recorded acquisition source. The denominator is named deliberately: attributable means the user has at least one non-direct touch on record. Direct and dark traffic is excluded, because no platform can attribute a conversion that has no touch to attribute it to. Against that denominator, Fidero guarantees a floor of ≥70% of attributable. Your target is set against the measured ceiling. Attribution covers what a touch is and how it’s kept.

The share of users who reach a stable userId rather than staying anonymous-only. Anonymous identity lives in browser storage, and browsers bound how long that survives – so this coverage is mostly a function of how early your users identify. That makes it your lever as much as Fidero’s measurement: Identity covers why the userId is what endures.

Delivery is a process – queues, retries, monitoring – rather than a per-event rule, so it’s the one commitment that stays a percentage: ≥99.5% delivery success to reachable destinations, excluding your own broken endpoints. The “reachable” qualifier is deliberate: a destination outage, or an endpoint on your side that stops accepting events, isn’t counted against the platform. The machinery behind the number is on Data quality & delivery.

Coverage is the lever you hold, and three moves raise it:

  • Identify users earlier. Every user with a stable userId crosses the identity guarantee’s precondition, and a userId outlives browser storage – see Identity
  • Put a stable transaction_id on every conversion, from every source that reports it, so deduplication applies everywhere – see Standard events
  • Send conversions server-side, where ad blockers and browser limits can’t drop them – see Server-side events