Identity

Datafly Signal manages identity for vendor server-side APIs without loading vendor JavaScript on your site. This page covers the five identifier types Signal maintains, which vendors are covered, and where to configure each.

The five identifier types

Every event Signal collects is tagged with the relevant identifiers from each of these layers. You don’t configure them per event — Signal selects the right identifiers for each destination automatically based on what the vendor’s API accepts.

1. Anonymous ID (always present)

A stable first-party identifier minted on the visitor’s first event and persisted as a first-party cookie on your domain. The anonymous ID:

• Is the join key for every other identifier (vendor IDs, device ID, user ID).
• Persists across sessions on your domain — typically two years, governed by your cookie policy.
• Carries no PII; it’s a random opaque value.
• Is sent to analytics and warehouse destinations that expect a stable per-visitor identifier (Amplitude device_id, Mixpanel distinct_id, BigQuery anonymous_id, etc.).

2. Device ID (optional, per pipeline)

Device recognition is an opt-in capability that recognises a returning physical device even after the anonymous-ID cookie has been cleared (private browsing, manual cookie wipe, browser switch on the same machine). It uses privacy-respecting device signals — no fingerprinting, no browser-storage tricks — and is governed by the visitor’s consent state.

• Enabled per pipeline in Collector → Device recognition.
• When the device is recognised, Signal re-attaches the previous anonymous ID to the new session, restoring continuity for analytics and attribution.
• When it’s not recognised (new device, low-confidence match, consent withheld), the visitor gets a fresh anonymous ID and is treated as a new visitor.

3. Authenticated user ID

When your application calls datafly.identify(userId, traits) (web) or Datafly.identify(...) (mobile), the user ID is stitched to the anonymous ID server-side, and:

• All subsequent events for that visitor carry both the anonymous and user IDs.
• The visitor’s prior anonymous events are reattributed to the now-known user in vendors that support back-attribution (Amplitude, GA4 Enhanced Conversions, partner CDPs).
• Optional traits are SHA-256 hashed and sent to vendors that accept hashed PII for matching — email, phone, name, address. Raw PII never leaves your infrastructure. See the hashed-PII coverage table below.

4. Vendor IDs (per destination)

For ad platforms and analytics tools whose server-side APIs accept externally-provided identifiers, Signal generates and maintains the right ID in the right format for the right vendor. You don’t add vendor pixels or JavaScript SDKs to your site to make this work — see the vendor coverage matrix below.

5. Cross-domain ID

If you operate multiple domains as a single customer experience (e.g. brand-a.com + brand-b.com, or marketing.example.com + shop.example.com), Signal can carry the anonymous ID across them so a visitor isn’t seen as two separate users. The Management UI controls which domains are linked and what consent rules apply — see Cross-Domain Identity for setup.

Vendor ID coverage

Signal handles the right identifier for each vendor server-side. The table groups vendors by how identity is sourced.

Vendor IDs Signal generates and maintains server-side

Signal generates the vendor’s expected ID format on the first event, stores it as a first-party cookie on your domain, and sends it back to the vendor on every subsequent event. The vendor sees a stable identifier without their JavaScript running.

Vendor IDs Signal captures from the browser and forwards

For these, Signal reads existing vendor cookies that were set elsewhere (for example by a server-rendered page or by the customer’s own code) and forwards them with each event.

Click IDs captured automatically

When a visitor lands on your site from a paid ad, Signal pulls the click ID from the URL and attaches it to every subsequent event for that session:

Partner enrichment

Signal can call a connected CDP server-side on every event, attach resolved profile attributes to the event, and optionally expose an allow-listed subset to the browser as window.datafly.profile.amperity (or the equivalent partner namespace) for client-side personalisation. The Profile API token never touches the browser.

Mobile attribution platforms

For mobile apps using the Datafly mobile SDKs, Signal forwards conversion events to the major attribution networks. Each receives the IDFA/AAID (when consent permits), the SDK’s anonymous ID, and the captured click/click-through identifiers.

Authenticated identity (hashed PII)

When you call datafly.identify(userId, traits), Signal can pass user-provided identity values to vendors that support them for matching — always SHA-256 hashed server-side before delivery. Raw PII never leaves your infrastructure.

Where to configure it

How to verify it’s working

1. Open Pipelines → your pipeline → Live Events in the Management UI.
2. Trigger a test event on your site (a page view or test conversion).
3. Click the event in the live feed; the destination preview shows the exact payload sent to each vendor, identifiers included.
4. Cross-reference in the vendor’s own debugger:
   • Meta Test Events (Events Manager)
   • GA4 DebugView (Admin → DebugView)
   • TikTok Events Manager Test Events
   • Pinterest Conversions Health
   • Snapchat Events Manager Test Events
   • …and equivalent tools for each vendor.

For partner-enrichment integrations, the event’s partner_attrs.amperity (or the equivalent partner namespace) block in the live feed shows the attributes resolved on that event.

More detail

Detailed identity architecture, the full supported-vendor matrix, and the underlying mechanisms are shared with customers in the onboarding pack. Contact your account team for the identity reference document.