Identity
Maximum match rates. Zero vendor JavaScript.
Every conversion is enriched with 30+ vendor identifiers, automatically. Higher match rates. Better attribution. More conversions counted. None of it requires a single third-party script in the browser.
Why vendor identity is the hard part
Vendor JavaScript does more than track events. It establishes user identity. Google’s gtag.js creates and maintains _ga. Meta’s Pixel generates _fbp and _fbc. Without these identifiers, server-side event delivery is effectively anonymous and vendors cannot attribute conversions back to ad clicks or user sessions.
Vendors like Meta, Google, and TikTok build internal match tables from every signal you send. The more identifiers present on each conversion (pixel ID, click ID, hashed email, external user ID) the higher the probability the event is matched to a known user. Unmatched conversions cannot be attributed, cannot train optimisation algorithms, and are effectively invisible.
Datafly Signal solves this with three vendor ID resolution methods that generate, capture, and enrich identifiers entirely server-side, plus three identity mechanisms that maintain the right identity across sessions, domains, and cookie resets.
How we get the IDs
Three vendor ID resolution methods
Self-generated, captured from URLs, or proxied via vendor APIs. Every identifier ends up as a server-side, ITP-exempt, 400-day first-party cookie on your subdomain.
Self-generated
Set-Cookie
+ 2 more, all 400-day, ITP-exempt
For top vendors, Signal generates IDs in the correct format with no vendor JavaScript. Covers GA4, Meta CAPI, TikTok, Pinterest, Snapchat. Set as server-side cookies via Set-Cookie headers, fully ITP-exempt with 400-day lifetimes.
Click ID capture
Captured automatically
When a user lands from a paid ad, Signal extracts click parameters from the landing page URL and stores them as first-party cookies. Survives Safari ITP for the full attribution window across every paid channel.
Server-side enrichment
Server-to-server
Credentials never reach the browser
For vendors that require API credentials (Acxiom, Amperity, LiveRamp, UID2), Signal proxies resolution server-side. Credentials live in your cluster config and never reach the browser. The resolved identity is cached and re-enriched on every event.
| Platform | Cookie | Why it matters |
|---|---|---|
| Google Analytics 4 | _ga | Required for GA4 Measurement Protocol attribution. |
| Meta / Facebook | _fbp | Increases Meta Event Match Quality and conversion attribution. |
| Meta / Facebook | _fbc | Ties server-side purchase events back to specific ad clicks. |
| TikTok | _ttp | Required by TikTok Events API for user-level match. |
_pin_unauth | Pinterest CAPI match quality depends on this for unauthenticated users. | |
| Snapchat | _scid | Required for Snap Conversions API deduplication and attribution. |
How we keep the IDs
Three identity mechanisms
One first-party cookie (_dfid) and three mechanisms that ensure it always carries the right value, even across cookie clears, browser updates, and different domains you own.
Device Recognition
Re-identifies returning visitors after they clear cookies, using SHA-256 hashed signals already present in every HTTP request. No fingerprinting scripts run in the browser. No raw signals stored. Configurable confidence thresholds and TTL per organisation.
OIDC Cross-Domain Flow
The same authorization code + PKCE flow Google, Microsoft, and Okta use for SSO. The Identity Hub issues a single-use code that is exchanged server-to-server, so the anonymous ID never appears in the URL. Round-trip 50–150ms, invisible to the user, works in every browser.
Link Decoration
When a user clicks a link to another domain you own, the collector decorates the URL with a short-lived AES-256-GCM encrypted token (60-second TTL). Because the user initiates the navigation directly, this is immune to Safari 17+ bounce tracking protection. Zero redirect latency.
All three are opt-in and configurable per organisation. They work together (OIDC for first-visit resolution, link decoration for click-through, device recognition for cookie-clear recovery) or independently.
Built to outlast the cookie
A visitor's identity stays intact when their browser doesn't
Stored vendor IDs aren't pinned to a fragile cookie. They're anchored to a durable, server-side identity that any of three signals can re-derive on the next event — logged-in user, recognised device, or anonymous cookie. Lose any one and the rest still resolve to the same profile.
Cookies cleared
Device recognition restores the profile
When the same device returns, server-side device recognition matches the visitor against their existing profile and re-issues the cookie linked to it. No vendor IDs lost, no fingerprinting JavaScript in the browser.
New device
Logged-in identity bridges devices
Once a visitor has identified (login, signup, even a soft email capture), their profile is anchored to that user identity for life. The next session on a different device, browser, or after months of inactivity resolves to the same profile and every vendor ID it carries.
First-time visitor
Self-generating IDs work from event one
GA4, Meta, TikTok, Pinterest, and Snapchat IDs are minted server-side on the first event and persist on the same first-party cookie. No vendor JavaScript runs to create them, so ITP and ad blockers can't prevent them.
The result: server-side attribution that doesn't reset every time a visitor opens an Incognito window or clears their browser data.
A persistent identity profile for every visitor
Every vendor identifier (self-generated, captured from URLs, or resolved via API proxy) is stored persistently in your identity profile for that visitor. On every subsequent event, the full profile is automatically re-enriched and sent to every vendor. No manual lookups. No missing identifiers. No lost attribution.
30+
Vendor IDs stored
GA4, Meta, TikTok, Trade Desk, Criteo, LiveRamp, and 25+ more, all stored and re-enriched on every event.
400
Day profile lifetime
Identity profiles are retained server-side and survive cookie clears, browser updates, and ITP restrictions.
0
Extra configuration
ID enrichment is automatic. Every event is enriched with every stored identifier for that visitor, no rules to write.
Built on industry standards. Configurable per organisation.
Every identity mechanism uses protocols and cryptographic primitives trusted by the world’s largest identity providers. Every feature is opt-in with clear retention, consent, and DSAR controls.
OIDC Authorization Code + PKCE
The same protocol used by Google, Microsoft, and Okta for cross-domain SSO. PKCE prevents authorization code interception. The anonymous ID is exchanged via a server-to-server backchannel and never appears in the URL.
AES-256-GCM encryption
Link decoration tokens are encrypted with per-customer AES-256-GCM keys, 60-second TTL, single-use nonces to prevent replay. Even if intercepted, tokens cannot be decoded without your cluster's encryption key.
Ed25519 signed JWTs
Identity tokens are signed with Ed25519 and verifiable offline via a published JWKS endpoint. No network call needed to verify authenticity. Compact, fast, and tamper-proof.
SHA-256 hashed signals
Device recognition signals are hashed with SHA-256 before storage. Raw signals are never persisted and cannot be reverse-engineered. Configurable TTL with a 30-day default.
Per-organisation controls
Device recognition, cross-domain identity, and ID enrichment are all opt-in per organisation. Retention periods, confidence thresholds, and signal sources are configurable.
GDPR & DSAR ready
Consent enforcement at collection and delivery. DSAR support for identity data. GDPR Legitimate Interest basis documented for every feature. Transparent, auditable, opt-in.
See identity resolution in action
Request a demo and we'll walk you through device recognition, cross-domain identity, and enterprise privacy controls, plus how Signal generates 30+ vendor IDs without a single line of vendor JavaScript.