IdentityCustom Identity Types

Custom Identity Types

Datafly Signal resolves every event to a person using a fixed chain of identifiers — user ID, hashed email, hashed phone, device ID, cookie ID. Custom identity types let you extend that chain with identifiers your business already owns: a loyalty ID, a CRM ID, an account number, a subscriber ID.

Declare a type once for your organisation and it becomes a first-class join key everywhere: any pipeline can bind an event field to it, and events carrying the same value — from the website, the app, a POS terminal, a kiosk — resolve to the same person.

Declaring a type

Go to Settings → Identity. Each type you declare has:

FieldMeaning
ID typeThe machine name, lowercase snake_case (e.g. loyalty_id). Immutable after save — it names the graph key that events join on.
LabelDisplay name used in coverage tables and pickers (e.g. “Loyalty ID”).
Hash moderaw — the value is used as-is; or normalised SHA-256 — the value is trimmed, lowercased, and SHA-256 hashed before it is stored or matched. Use hashing for email-like or otherwise sensitive values.
Priority1–5. Where the type slots into the resolution chain — see below.
Consent category (optional)When set, the type only participates in identity joins when the event’s consent state grants that category. Without the required consent, joins and writes fail closed — the event is still delivered, but it neither reads nor extends the graph on this type.

The schema is organisation-wide. Every pipeline uses the same type definitions — a pipeline cannot override a type’s hash mode or priority. That is deliberate: if two pipelines disagreed on how loyalty_id is hashed, their events could never join.

The resolution chain

With custom types declared, the full chain Signal walks to resolve an event to a person is:

  1. User ID — from identify() or a server event’s userId. Always the strongest signal; a custom type never outranks it.
  2. Hashed email
  3. Hashed phone
  4. Custom identity types — in priority order (1 is checked first).
  5. Device ID — the device-recognition identifier.
  6. Cookie ID — the first-party anonymous ID.

The first identifier that matches an existing person wins. Priority only orders your custom types among themselves within their slot — they always sit after phone and before the device ID.

Deleting a type

A type cannot be deleted while any pipeline still binds an event field to it. Remove the bindings first (on each pipeline’s Identity tab), then delete the type. This prevents a delete from silently breaking joins on live pipelines.

What declaring a type does not do

Declaring a type creates the vocabulary; it does not collect anything or join anything by itself. To put a type to work you need, per pipeline:

  • A way for the value to arrive on events — sent by your code (properties.loyalty_id), or read from the browser with a custom sync.
  • An Identity Graph binding that maps the event field to the type — see Identity Graph & Join Keys.

Next steps

OverviewIdentity Graph & Join Keys