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 IDs matter
A first-party signal platform means vendor JavaScript never runs in the browser. That is the whole point — better performance, stronger privacy, and complete data control.
But those vendor scripts do more than track events. They establish user identity. Google's gtag.js creates and maintains the _ga cookie. Meta's Pixel generates _fbp and _fbc. Without these identifiers, server-side event delivery is effectively anonymous — vendors cannot attribute conversions back to ad clicks or user sessions.
Datafly Signal solves this with three vendor ID resolution methods that generate, capture, and enrich identifiers entirely server-side — plus three identity mechanisms (device recognition, OIDC cross-domain flow, and link decoration) that ensure the right identity is maintained across sessions, domains, and cookie resets.
Identity capabilities that set Signal apart
One cookie (_dfid), multiple ways to ensure it contains the right value. Signal gives you three powerful identity mechanisms that work together to solve the hardest problems in first-party data.
Device Recognition
Re-identify returning visitors even after they clear cookies. Signal's server-side device recognition uses SHA-256 hashed signals from the HTTP request itself — no fingerprinting scripts, no raw signals stored. Configurable confidence thresholds and TTL per organisation.
OIDC Cross-Domain Flow
Industry-standard authorization code flow with PKCE unifies identity across any TLD. A server-to-server backchannel exchanges the anonymous ID — it never appears in the URL. 50–150ms invisible redirect, works in every browser.
Link Decoration
When users click between your sites, the collector automatically decorates outbound links with a short-lived identity token. Zero redirect latency. Immune to Safari 17+ bounce tracking protection because the user initiates the navigation directly.
Self-generated vendor IDs
For the top vendors, Datafly Signal generates IDs in the correct format without any vendor JavaScript. This covers the vast majority of customer needs.
| Platform | Identifier Generated | Why it matters for attribution |
|---|---|---|
| Google Analytics 4 | GA4 Client ID | Required for GA4 Measurement Protocol attribution. Without it, every server-side event arrives anonymous. |
| Meta / Facebook | Browser Pixel ID (_fbp) | Increases Meta Event Match Quality and conversion attribution. Meta CAPI performance degrades significantly without it. |
| Meta / Facebook | Click ID (_fbc) | Ties server-side purchase events back to specific ad clicks. Critical for ROAS calculation accuracy. |
| TikTok | Browser ID (_ttp) | Required by TikTok Events API for user-level match. Without it, TikTok cannot deduplicate or attribute conversions. |
| Anonymous Browser ID | Pinterest Conversions API match quality depends on this identifier for users who have not logged in. | |
| Snapchat | Browser ID (_scid) | Required for Snap Conversions API. Enables conversion deduplication and attribution across Snapchat campaigns. |
All IDs are set as server-side first-party cookies — making them fully exempt from Safari's ITP restrictions, with a 400-day maximum lifetime. That's 57× longer than client-side cookies in Safari. Every event arriving within those 400 days carries the full set of vendor identifiers, maximising match rates and attribution accuracy across every platform.
Automatic click ID capture
When a user arrives from a paid ad, the landing page URL contains a click identifier. Datafly Signal automatically extracts these parameters and stores them as first-party cookies for use in server-side event delivery.
gclid, gbraid, wbraid
Google Ads
fbclid
Meta
ttclid
TikTok
epik
li_fat_id
msclkid
Microsoft / Bing
ScCid
Snapchat
rdt_cid
UTM parameters
All channels
Click IDs are critical for conversion attribution. By capturing them server-side and persisting them as first-party cookies, Datafly Signal ensures they survive Safari's ITP restrictions and remain available for the full attribution window.
Server-side identity enrichment
For vendors that require API credentials for identity resolution — such as Acxiom, Amperity, LiveRamp, and UID2 — Datafly Signal proxies the resolution entirely server-side. Credentials are stored securely in your cluster configuration and never reach the browser.
How it works
- 1The browser sends a first-party request to your Datafly Signal endpoint.
- 2Your cluster calls the vendor's identity API using credentials stored in your secure config.
- 3The resolved identity is stored securely for fast lookups on all subsequent events.
- 4All events for that user are automatically enriched with the resolved identity before delivery.
A persistent identity profile for every visitor
Every vendor identifier — self-generated, captured from URLs, or resolved via match-pixel sync — 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.
What this means for match rates
Vendors like Meta, Google, and TikTok build internal match tables from every signal you send. The more identifiers present on each conversion event — pixel ID, click ID, hashed email, external user ID — the higher the probability that the event is matched to a known user in their advertising system. Unmatched conversions cannot be attributed. They cannot be used to train optimisation algorithms. They are invisible.
By automatically enriching every event with every stored vendor ID, Datafly Signal maximises match quality on every single conversion — not just the ones where users happened to accept all cookies on a recent visit.
Cross-domain identity that works in every browser
Traditional cross-domain tracking relies on third-party cookies or cookie-based redirects — both of which Safari's Intelligent Tracking Prevention blocks. Datafly Signal provides two complementary mechanisms that work together or independently.
OIDC Authorization Code Flow
On first visit, the collector redirects through the Identity Hub using an industry-standard authorization code flow with PKCE. The hub issues a short-lived code that is exchanged server-to-server for the anonymous ID — the ID never appears in the URL or browser history. The entire round-trip takes 50–150ms and is invisible to the user.
Link Decoration
When a user clicks a link to another domain you own, the collector decorates the URL with a short-lived encrypted identity token. Because the user initiates the navigation directly, this is immune to Safari 17+ bounce tracking protection — no redirect, no interstitial, no tracking query parameter that expires after 24 hours.
Both mechanisms are opt-in and configurable per organisation. All cookies are set via server-side Set-Cookie headers, making them fully ITP-exempt with 400-day lifetimes.
How vendors match your data
Vendors like Meta and TikTok build internal match tables from the signals you send. Each conversion event can include multiple identifiers — fbc, fbp, external_id, hashed email, hashed phone — and the vendor uses these to match the event to a known user in their system.
Match quality improves over time
The more signals you send consistently, the better the vendor's match rate becomes. Even if a single identifier is missing on one event, the vendor can use other signals to match. This is why Datafly Signal sends every available identifier on every event.
Always send external_id alongside vendor IDs
Your internal user ID (hashed as external_id) is the most durable identifier. It survives cookie resets, browser changes, and device switches. Pair it with vendor IDs for the highest possible match rate.
Never lose a visitor. Even when they clear cookies.
When a visitor clears their cookies and returns, most platforms see a brand new user. Signal's device recognition re-identifies them server-side using signals that are already present in every HTTP request — no additional JavaScript, no canvas fingerprinting, no privacy trade-offs.
Server-side only
No fingerprinting scripts run in the browser. All signals come from the HTTP request headers that the browser sends naturally. Nothing additional is collected or stored client-side.
Configurable confidence
Set your threshold per organisation: high confidence for accuracy-critical use cases, or medium for broader coverage. Only matches above your chosen threshold trigger re-identification.
SHA-256 hashed device signatures
Device 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, adjustable per organisation.
Automatic and opt-in
Zero configuration in the JS collector — all signals are already part of every HTTP request. The feature is opt-in per organisation with GDPR Legitimate Interest basis documented.
One identity across all your sites
Whether your customers visit site1.com or site2.co.uk, Signal maintains a single consistent _dfid — no more fragmented analytics or duplicated conversion counts.
OIDC Authorization Code + PKCE
The same protocol trusted by Google, Microsoft, and Okta. On first visit the collector redirects through the Identity Hub, which issues a single-use authorization code. The code is exchanged server-to-server via a backchannel — the anonymous ID never touches the URL or browser history. 50–150ms, invisible to the user.
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. The user initiates the navigation directly, so Safari 17+ bounce tracking protection does not apply. Zero redirect latency, zero interstitial.
Server-Side Identity Graph
When users log in on multiple domains, Signal automatically merges their anonymous profiles. All vendor IDs and traits are unified into a single identity — enriching every event regardless of which domain it originates from.
All three methods are opt-in and work together. OIDC handles first-visit resolution, link decoration handles click-through navigation, and the identity graph unifies authenticated sessions. Enable the combination that fits your architecture.
Identity security built on industry standards
Every identity mechanism in Signal is built on protocols and cryptographic primitives trusted by the world's largest identity providers. No proprietary black boxes.
OIDC Authorization Code + PKCE
The same protocol used by Google, Microsoft, and Okta for cross-domain single sign-on. PKCE prevents authorization code interception. The anonymous ID is exchanged via a server-to-server backchannel — it 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 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.
Enterprise privacy controls, built in
Every identity feature is configurable per organisation. Enable only what you need, set retention periods, choose confidence thresholds, and maintain full GDPR compliance with opt-in controls and transparent data practices.
Per-Organisation Controls
Device recognition, cross-domain identity, and ID enrichment are all opt-in per organisation. Enable exactly the features you need and nothing more.
Configurable Retention
Set data retention periods that match your privacy policy. 30-day defaults for device recognition, with full control to adjust per feature.
Confidence Thresholds
Choose how aggressively identity is matched. High confidence for accuracy-critical use cases, or medium for broader coverage.
GDPR Compliance
Consent enforcement at collection and delivery. DSAR support for identity data. Legitimate Interest basis documented for every feature.
Transparent Data Practices
No hidden tracking. No opaque algorithms. Every signal used for identity is documented, auditable, and under your control.
Hashed and Irreversible
Device recognition signals are hashed with SHA-256 before storage. Raw signals are never persisted and cannot be reverse-engineered.
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.