Identity stitching: connect anonymous events to customer profiles

A shopper browses three product pages, leaves your website and later returns to create an account. Your CRM now knows who they are. Can it also connect the interactions that happened before they signed up?

Identity stitching connects activity recorded under different identifiers to reconstruct a customer journey. Within the broader field of identity resolution, this article focuses on anonymous events: how can earlier interactions become part of a known customer's history after login?

The aim is to retain useful behavioural history while avoiding the attribution of one person's activity to somebody else.

Identity stitching establishes continuity between interactions carrying different identifiers. In a web journey, it can connect a browser identifier with a customer identifier captured at login.

The term event stitching emphasises the records being connected: visits, searches, purchases or support interactions. Terminology varies between products, so always check the actual scope and rules.

Three operations serve different purposes:

An identity graph represents relationships between identifiers. It can support stitching, but does not replace collection or the definition of rules about time.

🟰 Deterministic matching relies on explicit rules and observed identifiers. A login that carries both an anonymous browser ID and a customer ID can provide the connection needed for stitching.

An email address may also connect customer records across systems, where its ownership and use are sufficiently reliable. Exact matching is still only as trustworthy as the source data: shared email addresses and recycled identifiers can produce incorrect matches.

🎲 Probabilistic matching estimates whether activity belongs to the same person using a combination of signals. It introduces uncertainty that must be assessed for the intended use. A likely association should not automatically become a confirmed identity.

For a marketing team sending personalised email based on purchase history, a mistaken match could use another customer's interests or transactions.

It is therefore essential to prioritise clear, auditable links for individual actions. Keep inferred associations distinguishable from confirmed matches in analytics and customer profiles.

Before identification, an event may carry a browser identifier without a customer identifier. This provides limited technical continuity within the context where that identifier was created.

An anonymous identifier is not proof of a person's identity. Several people may share one device, while one person may use several browsers.

Retain the information needed for matching within the applicable collection and usage permissions.

A login event may contain both the browser identifier and the account identifier. Their presence together provides a link that the system can use.

Having an email address in your CRM does not, by itself, reveal all of that person's website visits. An observable connection is needed between the identity and the relevant events.

Depending on the product, earlier events may be associated with the identified journey within defined limits.

Keep the time of the interaction separate from the time of its association. A Monday visit connected on Thursday remains a Monday visit.

The output should support analysis and segmentation rules. For example, a retailer might calculate the product categories viewed before a first purchase.

Before activating those signals, check data freshness, business exclusions and the customer's eligibility for the intended channel.

Consider this fictional retail example.

Where the rules permit it, Thursday's observed connection associates the earlier browsing activity with C42's journey.

The marketing team can see that the size guide formed part of the observed path before purchase. It can also exclude the customer from a reminder intended for visitors who have not yet ordered.

Stitching does not prove that the guide caused the sale. It improves the observed journey; measuring the effect of content or a campaign remains a separate task.

If somebody else used B17 on Tuesday, the association could be wrong. This is why rules must address conflicts rather than simply maximise the number of matches.

Stitching can connect an anonymous visitor's product research with a later purchase. Analytics teams can then examine the observed sequence instead of treating the visitor and the buyer as records without a connection.

For example, compare the journeys of customers who consulted delivery information with those who did not. This can help identify questions for further investigation. It does not establish that the information caused the purchase.

Once matching has been validated, eligible browsing history can enrich customer profiles with useful signals, such as recent interest in a product category. Marketing teams can use those signals to make content more relevant.

Keep the action proportionate to the evidence. A single anonymous page view is a weak basis for a lasting preference, even when it has been correctly linked to a known customer.

A purchase recorded in one system may need to exclude the customer from a reminder prepared in another. Stitching helps connect the earlier activity with the purchase; the campaign still needs fresh data and an explicit exclusion rule.

This supports a more unified view across marketing channels, but does not automatically update every destination. Check when profiles and audience memberships reach the email or advertising system.

Reliable results start with consistent event tracking.

For each source, document at least:

Document what each identifier actually identifies. A browser cookie, a mobile app installation and a customer account have different scopes. A user can have multiple device identifiers, and one device can be shared.

First-party data collected through your company's own website or app provides the starting point for this workflow. It does not mean that every event is identified, accurate or eligible for every use. Keep privacy choices, access controls and retention rules alongside the matching design.

Also define the entity you want to understand. Are you reconstructing the journey of a person, a shared account or a business? Mixing these levels can create inconsistent segments.

In B2B, several people from the same company may research the same product. A shared company domain or office network is not enough to establish that they are one person. Keep user-level journeys distinct from account-level activity. This lets teams analyse interest across an organisation without copying one contact's browsing history into another contact's profile.

Late-arriving events need an explicit policy too. An order ingested after an audience was prepared should not be confused with an order that never happened.

Write down ownership of these decisions. Marketing can define the intended audience and exclusions, while data teams verify which identifiers and timestamps make those rules possible.

Create test journeys in which two customers use the same browser in succession. Check what happens at logout and when the next account signs in.

A technical connection should not automatically merge all historical behaviour. Document situations that remain excluded or unattributed.

Also test a customer who researches a product on mobile and buys on a laptop. If both devices later carry a suitable customer identifier, the observed links may support a unified journey. Without that evidence, the mobile activity may remain anonymous. Unresolved activity is preferable to a false match.

The Identifier policy step sets identifier priority, limits and the time window used for stitching.

Define which events can be reconsidered and which outputs are recalculated. Check whether corrections can reach tools that have already received the data.

Updating analytical history should not accidentally trigger an old campaign. Agree whether a newly associated event may initiate an action or should only enrich a profile.

Monitor the proportion of attributed events alongside conflicts, unresolved events and unusual changes in audience size.

Define each metric's denominator. A rate calculated from eligible events is not directly comparable with one calculated from the entire collection.

Before expanding the scope, review a sample of both successful matches and exclusions. This helps explain whether a change reflects better coverage, a broken source or an overly permissive rule.

Start with a small set of customer journeys whose expected results are known. Use the same records to evaluate each solution; a feature labelled “identity stitching” can behave differently across systems.

Ask whether the solution produces a stitched event dataset, unified customer profiles or an identity graph. These outputs support different workflows. An analytics team may need a stable key for grouping interactions, while a marketing team needs a profile that can support audience rules.

Inspect an anonymous visitor, a returning customer and a shared-device case. Check which records change, which original identifiers remain available and how a correction affects the output.

Request an explanation for individual matches. Which identifier connected the records? Which source supplied it? Was the decision based on a deterministic rule or a probabilistic model?

A confidence score needs a documented meaning and validation. A high score is not a substitute for checking known examples. Confirm whether the system can keep uncertain activity separate and whether teams can correct a mistaken association without rebuilding unrelated profiles.

Ask how customer profiles or stitched events become available to analytics, email and other marketing channels. Check refresh schedules, late-arriving data and the handling of deletions or corrections.

For example, a unified profile can show a purchase while an email audience still reflects yesterday's data. Test the complete flow from source records to the destination, including exclusions. Matching alone does not resolve delivery delays.

Decide who can inspect customer identifiers, configure rules and approve changes. Use a test dataset with controlled examples for evaluation instead of exposing unnecessary personal data.

Privacy controls should cover the resulting profiles as well as the source events. Ask how the solution handles retention, access restrictions and changes in permitted use. Document which team owns each control and how exceptions are reviewed.

In DinMo, Event Stitching reconstructs journeys from anonymous and identified events. It addresses a practical question: which interactions can belong to the same journey, particularly when a visitor logs in after several visits?

Configuration involves selecting event models, mapping their fields and defining how identifiers should be used.

In our retail example, the aim is to determine how to use the observed link between browser B17 and customer C42. Data teams define the matching conditions; marketing teams specify the intended use, such as analysing browsing activity before a purchase.

In DinMo, the Mapping step connects event model fields with the identifiers used for stitching.

The project overview shows processed events, the stitching rate and the breakdown of known and anonymous profiles. These indicators help teams track changes in the results.

Quality checks add information about identifiers and reasons for exclusion. An increase in the matching rate should always be considered alongside the quality of the associations, particularly when devices are shared.

The reconstructed history can contribute to analytics and, once connected to the appropriate customer data, segmentation rules: interest in a category, browsing before purchase or exclusions after an order.

Event Stitching remains separate from the Profile Resolution capability, which reconciles customer records into profiles. The two capabilities produce independent outputs, so their relationship must be defined through reliable shared identifiers.

Identity stitching is useful when it connects activity from unrecognised visitors to usable customer profiles. It needs understandable, testable rules.

Start with one bounded journey, test ambiguous situations and inspect the effect on audiences. From there, you can expand the scope with a clearer view of data quality and how the resulting signals will be used in DinMo.