Profile Attachment
Store on receipt, append on lookup. Once an event resolves to a person, Datafly Signal does two things:
- Store — any person-level identifiers the event carries (user ID, email, custom join-key values such as a loyalty ID) are saved to that person’s profile, encrypted at rest.
- Append — the person’s full known profile is attached to the event before delivery, filling in whatever the event did not carry itself.
The result: an in-store purchase that arrives with nothing but a loyalty ID leaves the pipeline carrying the customer’s user ID, email, vendor IDs, and every other identifier the graph has for them — and a web event from an anonymous session that later identifies is retroactively as rich as a logged-in one.
What gets attached
On every resolved event, Signal appends:
userId— when the event has none.properties.email— when the event has none.- Custom identity values — into the event’s
collected_idsmap (e.g.collected_ids.loyalty_id). - Vendor IDs — the person’s stored vendor identifiers (see Vendor IDs).
- Collected IDs — previously collected values the browser did not resend.
Attachment never overwrites a value the event already carries. If the event arrives with its own properties.email, that value wins.
Controlling what a pipeline attaches
Some destinations should not receive everything the graph knows. On Pipelines → your pipeline → Identity → Profile attachment you can restrict which profile fields this pipeline appends:
| Setting | Behaviour |
|---|---|
| Attach everything (default) | The full profile is appended to every resolved event. |
| Attach nothing | Events are resolved (for delivery continuity) but no profile fields are appended. |
| Selected fields | Only the listed fields are appended — e.g. just user_id and loyalty_id. |
For pipelines whose destinations must not receive raw PII, choose hashed email (email_sha256) instead of the raw email — Signal computes the standard trimmed, lowercased SHA-256 at attach time.
Blueprints remain the delivery filter
Profile attachment decides what is available on the event. What each vendor actually receives is still decided by that integration’s blueprint mapping — unmapped fields are dropped by default. Attaching the full profile does not spray identifiers at every destination; it makes them available for the mappings you have configured.
Blueprints can also map canonical_id — Signal’s stable person key — as a top-level source field. This is the natural delivery key for CDPs and warehouses that want one column that is always the same person, regardless of which identifier the event arrived with.
Interaction with data governance
Organisation-level Data Governance PII rules run before identity. If a rule hashes properties.email, the graph stores and attaches the hashed value — everywhere downstream. Set governance rules with that in mind: they define the most raw form of a field the platform will ever hold.
Next steps
- Custom Identity Types and Identity Graph & Join Keys — how events resolve to a person in the first place.
- Server & In-Store Sources — profile attachment is what makes minimal server events deliverable.