Identity
Datafly Signal’s identity system solves a fundamental problem: when you remove vendor JavaScript tags from your site, you also remove the mechanisms those vendors use to identify visitors. No vendor tag means no vendor cookie, no vendor pixel fire, and no vendor-generated ID flowing back to their servers.
Signal replaces all of this with a comprehensive server-side identity layer that generates, captures, and manages vendor-compatible IDs entirely from your own infrastructure.
The Problem
Traditional client-side tag management works because each vendor’s JavaScript tag runs in the browser and sets its own cookies. When Google Analytics loads, it creates the _ga cookie. When Meta’s pixel fires, it creates _fbp. These cookies are then sent back to the vendor on subsequent requests, maintaining identity continuity.
When you move to server-side tag management and remove those vendor scripts, the cookies are never created. The vendor APIs still accept events, but without matching identity values, the vendor cannot stitch your server-sent events to the user sessions it sees from other sources. Attribution breaks, audience building fails, and conversion data becomes unreliable.
The Solution
Signal provides three methods for resolving vendor identity without loading vendor JavaScript:
1. Self-Generation — Generate IDs in the exact format vendors expect
2. Click ID Capture — Extract attribution IDs from URL parameters
3. Server-Proxied Enrichment — Call credential-protected vendor APIs server-sideEach method targets a different category of vendor identity. Together, they cover the full spectrum of ID types that vendor server-side APIs require.
Self-Generated IDs
For vendors whose server-side APIs accept externally-generated identifiers (GA4, Meta, TikTok, Pinterest, Snapchat), Signal generates IDs in the correct format and sets them as server-side first-party cookies. Because the cookies are set via Set-Cookie headers rather than JavaScript, they are exempt from Safari’s Intelligent Tracking Prevention (ITP) restrictions.
Click ID Capture
When a user arrives on your site via a paid ad, the URL contains a click ID parameter (gclid, fbclid, ttclid, etc.). Signal captures these automatically on every request and stores them in Redis. Click IDs are the strongest attribution signal for most ad platforms and require no vendor JavaScript to obtain.
Server-Proxied Enrichment
Some identity vendors (Acxiom RealID, LiveRamp ATS, UID2, The Trade Desk) require API credentials to resolve an identity. Signal handles this by proxying the request through the Ingestion Gateway: the browser sends a request, the gateway adds credentials server-side, calls the vendor API, and returns the result — all without exposing credentials to the client.
Fire-Once Vendor SDK (Fallback)
For the small number of vendors that have no server-side identity path and require their own JavaScript to generate an ID, Signal supports a fire-once pattern: the vendor SDK loads a single time to generate the ID, Signal captures it, and the SDK is never loaded again. This is a last resort — the vast majority of vendors are covered by the three primary methods.
How IDs Flow Through the System
Browser request arrives at Ingestion Gateway
→ Read _dfid cookie (or generate new one)
→ Read/set vendor cookies (_ga, _fbp, _ttp, etc.)
→ Capture click IDs from URL parameters
→ Store all IDs in Redis keyed by anonymous_id
→ Publish event to Kafka (raw-events)
Event Processor picks up the event
→ Look up all known IDs for this anonymous_id from Redis
→ Attach vendor-specific IDs to the event per integration
→ Publish to delivery topic
Delivery Worker sends to vendor API
→ Include the correct vendor ID in the API payload
→ Vendor can stitch the event to the user's identity graphAll IDs are stored server-side in Redis, keyed by the _dfid anonymous identifier. When the Event Processor prepares an event for delivery to a specific vendor, it looks up the relevant vendor IDs and attaches them to the outbound payload.
The identity system operates transparently. Once configured, vendor IDs are generated, captured, and attached to events automatically — no per-event configuration is needed.
Sections
- Anonymous ID — The
_dfidcookie and how Signal establishes persistent first-party identity - Vendor Identity Sync — How the sync engine orchestrates all identity resolution methods
- Self-Generated IDs — Generating vendor-compatible IDs server-side
- Click ID Capture — Extracting attribution IDs from URL parameters
- Server-Proxied Enrichment — Calling credential-protected vendor APIs from the server
- Cross-Domain Identity — Maintaining identity across multiple domains with the Identity Hub