Platform · Blocks · Identity Stitching
Every device
One customer
The same customer shows up as a phone in the store, a laptop at checkout, and an anonymous browser. Blocks matches identifiers across devices, channels, and sessions in real time, and joins them into one profile the moment evidence lands
- Multi-identifier
- Real-time merge
- History back-fill
- False-merge guardrails
Playable · The stitch
A week in the life of one customer
Drag through it
Six moments across one week. Scrub the timeline or press play, and watch three "anonymous" records snap into one golden profile, history back-filling in gold as they merge. One moment refuses to merge: that's the guardrail
Monday hasn't happened yet: press play, or drag the week below
Every appearance starts as a separate record in your tools. Watch the two numbers above disagree until the stitching begins
- Mon 7:41 PMweb visit
- Wed 12:03 PMonline order
- Thu 8:17 AMnewsletter click
- Fri 7:43 PMapp login
- Sat 2:02 PMin-store purchase
- Sat 6:55 PMshared kiosk
An illustrative simulation: the mechanics (match, merge, back-fill, guardrail) are the real product behavior
When Thursday's click stitched the cookie to the inbox, Monday's "anonymous" session stopped being anonymous, retroactively. That is what back-fill means
How identity stitching works
Real-time graph resolution
As signals arrive, Blocks matches identifiers, merges profiles, and back-fills history across all linked IDs. Guardrails make sure the graph never merges two different customers into one
-
01
Real-time graph building
As events arrive, identifiers are matched and profiles merged in real time. The customer graph grows with every new signal, not overnight in a batch job
-
02
Multi-identifier matching
Match on email, device ID, app ID, ticket number, loyalty ID, custom identifiers, or any combination, instead of forcing identity onto one hard key that is often missing
-
03
Automatic history back-fill
When profiles merge, new resolutions back-fill history across all linked identifiers, so the complete relationship reads as one story, starting at the first touch
-
04
Guardrails against false merges
Per-identifier limits stop a shared device from over-merging distinct customers. When a limit would be crossed, records hold apart instead of guessing: correct beats complete-but-wrong
Under the hood
Match, merge, back-fill
-
01
Match on evidence, not hope
Every event carries the identifiers its source can see. When a new event shares an identifier with an existing thread (a login, a loyalty scan, a clicked email), that is evidence, and evidence is the only thing that ever joins two records
-
02
Merge in the moment
The matched profiles fold into one golden record immediately, with identifiers, attributes, and consent state combined, so the very next event anywhere in your stack already sees the full customer
-
03
Back-fill the past
Everything the separate records saw before the merge is rewritten onto the customer: Monday's anonymous session becomes their session. And when a shared device would cross a per-identifier limit, the records hold apart, because a smaller true graph beats a bigger wrong one
Why it matters
One identity across
every device and channel
Customers shift between devices and channels constantly. Blocks stitches these appearances together in real time, so one person reads as one relationship, and activation can reach them wherever they appear next
See how resolution works- Recognize customers instantly across all touchpoints, not after a nightly batch matches yesterday's events
- Reduce abandoned profiles by matching on multiple identifier types instead of one hard key
- Improve targeting accuracy by preserving distinct identities and preventing false merges
- Accelerate response by updating profiles in real time as customers switch devices or channels
See your anonymous traffic become known customers
Watch Blocks stitch devices, channels, and sessions into one governed profile, live on your own data. Book a walkthrough and we'll trace a real customer journey from your stack