IdentityOverview

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-side

Each 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 graph

All 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