Skip to main content
Card class: HeroCategory: Ad Platform

At a glance

A real-time tracking-health alert that fires when Criteo’s One Tag is firing on your site but failing to set or persist a first-party cookie on a meaningful share of sessions. Criteo’s entire retargeting model lives or dies on first-party signal: every PDP view, basket-add, and abandonment event the One Tag captures is what fills the retargetable audience pool for the next sync. When the tag fires without a cookie set, that signal is lost, the usual cause is Safari ITP or browser privacy enforcement catching up, and the visible consequence is an audience that quietly shrinks at the next audience refresh. This card catches the tag-without-cookie pattern in the hour it starts, before the shrinking audience shows up as a ROAS or conversion drop days later.
What it countsThe share of tracked sessions where the Criteo One Tag fired but no first-party cookie was set or persisted. The alert is the breach state when that share crosses the configured ceiling for a sustained period; the displayed value is the current tag-without-cookie rate.
Cost basisNot a spend metric. This is a signal-integrity metric. Its downstream effect is on retargeting efficiency, which is CPC-billed.
CurrencyNone. The unit is a count or share of sessions, not money.
Conversion attributionDirectly affected. A lost cookie means lost post-view attribution capacity, so a decaying tag depresses Criteo-attributed conversions even when real orders are unchanged.
Attribution windowN/A for the tag-health reading itself. The decay it detects erodes the 30-day click + 7-day view attribution that retargeting depends on.
Bot / invalid trafficBot sessions are excluded where Criteo’s filtering identifies them, so the rate reflects genuine human traffic losing cookie persistence.
iOS 14.5+ ATT impact on the cardThis card exists because of ATT and ITP. Safari’s Intelligent Tracking Prevention caps or clears first-party cookie lifetime, and iOS ATT removes cross-site identity. A rising tag-without-cookie rate is the operational fingerprint of that enforcement tightening on your specific traffic mix.
Catalogue-feed dependencyNone directly. Feed health and tag health are independent failure modes; this card isolates the identity-signal side.
Time windowRT (real-time). The breach evaluates over a sustained window (illustratively more than an hour) to avoid firing on transient deploy blips.
Alert triggerOne Tag firing without cookie set (ITP) on >20% of sessions for >1h. An illustrative threshold; the breach fires when the tag-without-cookie share stays above the ceiling for the sustained window.
Rolesowner, marketing, engineering

Calculation

Calculated automatically from your Criteo data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A US apparel DTC retailer with a heavily iOS / Safari audience deployed a storefront theme update on 09 Jun 26. The Criteo One Tag is present on every page. The card watches the share of sessions where the tag fires but no cookie persists.
Hour (09 Jun 26)SessionsTag firedCookie setTag-without-cookie rateState
08:004,1004,0603,7807%OK
09:004,3004,2503,9407%OK
10:00 (theme deploy)4,2004,1502,99028%BREACH
11:004,4004,3503,10029%BREACH
12:004,2504,2103,02028%BREACH
What the pattern tells you:
  1. The breach starts exactly at the theme deploy. A sharp step-change aligned to a release almost always means a code-level regression: the cookie consent banner now blocks the tag, a cookie domain or SameSite attribute changed, or the tag moved behind a deferred script that fires after the page navigation completes. This is an engineering fix, not a Criteo settings change.
  2. A gradual creep instead of a step would mean ITP, not a deploy. If the rate climbed slowly over weeks with no release, that is Safari ITP enforcement tightening on your traffic as cookie lifetimes get capped. The fix there is different: deploy first-party identity and server-side signal rather than patch the tag.
  3. The tag is still firing. That is what makes this subtle. A naive tag-presence check would show green because the tag fires; the failure is in cookie persistence, which is invisible without this card. A marketer watching ROAS would only notice three to five days later when the shrunken audience syncs and retargeting efficiency drops.
  4. The downstream clock has started. Every breached hour is signal not captured. The retargetable pool feeding the next audience sync is smaller than it should be, so expect the retargeting ROAS card to soften within a few days if this is not fixed quickly.
  5. First action is to reproduce in a Safari private window and a consent-rejected session. That tells you whether the cause is consent-banner blocking, a cookie-attribute regression, or genuine ITP. Reproduce, fix, and watch the rate fall back toward the single-digit baseline.
Quick sanity tests:
  • Sharp step-change at a release = code regression, roll back or patch the tag.
  • Slow creep over weeks with no release = ITP enforcement, deploy first-party identity.
  • Rate high only on Safari / iOS split = ITP, expected, mitigate rather than fix.
  • Rate high across all browsers after a consent-tool change = consent banner blocking the tag.
  • Rate returns to baseline after the fix = signal capture restored, audience recovers at next sync.

Sibling cards merchants should reference together

CardWhy it matters next to Criteo One Tag / First-Party Audience DecayWhat the combination tells you
Retargeting ROAS Dropped Below ThresholdThe downstream consequence of audience decay.This card firing first, then the ROAS breach a few days later, confirms the causal chain: lost signal then lost efficiency.
Conversion Rate TrendThe conversion-side symptom of a poorly matched audience.Falling conversion rate alongside tag decay means the audience pool is degrading, not just measurement.
Conversions TrendAbsolute Criteo-attributed conversion volume.Some apparent conversion loss is lost attribution capacity rather than lost orders; cross-check the store ledger.
Conversion Drop AlertThe conversions-volume alert.Both firing together points squarely at a tracking or identity fault rather than a demand or pricing problem.
Conversion LagView-through latency.Rising lag plus tag decay means post-view credit is both slower and smaller, a double hit to retargeting measurement.
Total RevenueCriteo-attributed revenue.If attributed revenue fell while store-realised revenue held, the loss is measurement, fix the tag and signal rather than the budget.

Reconciling against Criteo

Where to look in Criteo’s own dashboard:
Criteo Management Centre → Audiences → Audience size / match rate, and the One Tag health view under Assets → Tags, filtered to the same advertiser account.
Criteo’s Audiences view shows retargetable audience size and match rate over time, the lagging indicator that this card predicts. When the tag-without-cookie rate breaches here, expect Criteo’s reported audience size to step down at the next sync. Criteo’s own tag-health surface reports whether the tag is firing, but it is weaker at distinguishing fired-but-no-cookie from fired-and-cookied, which is exactly the gap this card closes. Reconcile by correlating a breach window on this card with a subsequent dip in Criteo’s reported audience size or match rate. Why our number may legitimately differ from Criteo itself: A gap is expected here because the two surfaces measure different points in the chain.
ReasonDirectionWhy
Leading vs laggingOurs leadsThis card measures cookie-set failure at the session level in real time; Criteo’s audience-size view updates at sync cadence, so it confirms the decay days later.
SamplingEither directionTag-health sampling rates and session definitions can differ between the storefront measurement and Criteo’s server-side view.
Consent scopeOurs may read higherConsent-rejected sessions where the tag is intentionally suppressed can inflate the tag-without-cookie rate depending on how consent is wired; this is correct behaviour, not an error.
Bot filteringMinorDifferent bot-exclusion logic between surfaces can shift the denominator slightly.
Cross-connector reconciliation: This card is Criteo-only. Tracking-health failures often share a root cause with other on-site tags, so the useful comparison is operational rather than mathematical:
CardExpected relationshipWhat causes legitimate divergence
google_analytics.ga_sessionsIf a consent-banner or theme change broke the Criteo tag, it often dented other on-site tags at the same time; a simultaneous analytics-tag anomaly corroborates a site-wide tagging regression.Criteo’s first-party cookie is more ITP-exposed than analytics measurement, so Criteo can decay while analytics holds.
facebook_ads.fac_total_revenueMeta’s pixel faces the same ITP pressure; parallel attribution decay across both vendors points at a browser-enforcement step rather than a Criteo-specific bug.Closed identity graphs decay differently from Criteo’s open-exchange first-party model.

Known limitations / merchant FAQs

The tag is firing, so why does this card say there is a problem? Firing and cookie-setting are two different things. The tag can execute on every page and still fail to set or persist a first-party cookie, because Safari ITP capped the cookie lifetime, a consent banner blocked it, or a code change altered the cookie attributes. A tag-presence check shows green; this card looks one level deeper at whether the signal actually persisted. That is the whole point of the card. How do I tell ITP decay from a code regression? Look at the shape. A sharp step-change aligned to a deploy is a code regression, fix or roll back. A slow creep over weeks with no release is ITP enforcement tightening, which you mitigate with first-party identity and server-side signal rather than patch. The worked example above shows the step-change pattern. Why does this matter so much more on Criteo than on a search platform? Search platforms capture intent at the moment of the query and do not depend on a persistent first-party retargeting cookie to the same degree. Criteo is a retargeting and commerce-media platform: its audience pool is rebuilt continuously from first-party on-site signal. Lose the cookie and you lose the pool, which is the entire asset. The dependency is structural, not incidental. My rate is high only on Safari and iOS, is that fixable? Not fully, and that is expected. Safari ITP deliberately limits first-party cookie persistence, so an elevated baseline on that traffic is the new normal rather than a bug. The mitigations are first-party identity deployment and server-side conversion signal, which recover a meaningful share of the lost measurement. The goal is to keep the rate from rising further and to claw back signal server-side, not to drive it to zero. If this fires, has my revenue already dropped? Not yet, and that is the value of the card. The tag decay happens now; the shrunken audience only affects retargeting efficiency days later at the next sync. Catching the breach early means you can fix the tag before the loss reaches the ROAS and conversion cards. Treat a sustained breach as urgent precisely because the damage is still in the pipeline rather than already realised. Could a high rate be a false alarm from consent-rejected traffic? Possibly, depending on how your consent management is wired. If the tag is intentionally suppressed for consent-rejected sessions but those sessions still count in the denominator, the rate reads higher by design. That is not an error, but it does mean you should interpret the absolute level against your consent-acceptance mix rather than against a universal benchmark.

Tracked live in Vortex IQ Nerve Centre

Criteo One Tag / First-Party Audience Decay is one of hundreds of KPI pulses Vortex IQ tracks across Criteo and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.