A profile is a container for everything known about a person: their identity, attributes, and behavioral history. Understanding how to create, update, and unify profiles helps you build audiences and journeys that work correctly.
Identity resolution connects signals that arrive under different identifiers, so targeting and journeys can operate on the intended customer. It allows anonymous website behavior, CRM attributes, and backend events to refer to the same person, rather than living in separate silos.
A profile typically includes 3 types of data:
Data type | What is it | Examples |
|---|---|---|
Attributes | State of the person that persists until changed | Customer status, loyalty tier, consent preferences |
Events | Time-stamped actions the person has taken | Page view, purchase, login, support ticket |
Identifiers | Links that tie signals to this profile | Customer ID, email, device ID |
Profiles can have multiple identifiers linked together through identity resolution. Identifiers allow events from different sources (web, mobile, backend) to be associated with the same person.
There are 2 ways to create profiles:
From web tracking: When a visitor arrives on your site, an anonymous profile is created based on a device identifier. This profile collects behavioral events until a known identifier is captured. Web tracking alone does not create profile-level identity.
From server-side ingestion: Profiles can be created directly from backend systems (CRM, billing) before a customer ever visits the website. These profiles contain attributes and events from business systems.
Both paths are valid. Many implementations use both, with identity resolution linking them when an identifier becomes available.
Profile lifecycle patterns
Pattern 1: Business system first, web later
A profile is created from CRM data with a stable customer ID.
Attributes like customer status and contract dates are added.
Later, the customer visits the website and logs in.
Identity resolution links the web activity to the existing profile.
The profile now contains both business data and web behavior.
Pattern 2: Web first, business system later
An anonymous profile is created when a visitor arrives on the site.
Web events (page views, product views) are captured.
The visitor logs in or submits a form, providing a known identifier.
Identity resolution links the anonymous activity to a known profile.
Server-side ingestion adds business attributes to the same profile through the known identifier.
Profile lifecycle in practice
Audiences use both attributes and events. You can build audiences based on profile attributes (for example, "loyalty tier is gold"), on events (for example, "viewed product in last 7 days"), or both.
Journeys can trigger on profile changes. When an attribute changes (for example, the contract end date crosses a threshold) or when a specific real-time event occurs, journeys can execute steps you have configured based on the change or event.
Identity affects activation. The identifiers on a profile determine where the profile can be sent:
A profile with only an anonymous device ID can be activated in cookie-based destinations, such as Meta, Google, or TikTok.
A profile with a known identifier can be used for activation on both cookie-based and identifier-based platforms, such as Braze, HubSpot, or Dotdigital.
Identity resolution with anonymous, known, and stitched profiles
Data Activation links identifiers to a single profile when a deterministic signal is available – it doesn't guess who someone is.
Common identifiers for deterministic signals include:
Browser or device ID from web tracking
Customer ID from a CRM or billing system
Email address captured through a form or login
Mobile app user ID
Here's a basic example flow of identity resolution:
A visitor arrives on a website. Web tracking collects events tied to an anonymous browser identifier.
The visitor becomes known when an identifier becomes available through login, account creation, or email capture.
The known identifier is linked to the earlier anonymous activity. The anonymous and known identities are connected.
Data Activation uses the unified view. Audiences and journeys can use both browsing intent and business context.
Profile types
Identity coverage limits which destinations you can activate the data in, and what you can do with the data. Basically, anonymous profiles allow you to target based on behavior, but known and stitched profiles add customer data to the mix, providing more granularity and accuracy to the process, such as cross-device continuity.
Note that identity resolution isn't the same as destination matching. A profile can be unified internally while still failing to match in an external destination due to that platform's own rules. These issues can be caused by, for example, incorrect phone format, identifier hashing requirements, or match thresholds.
Anonymous profiles
Anonymous profiles represent visitors who haven't been identified with a stable business identifier. The system creates anonymous profiles when a visitor arrives on a tagged site, and events are collected under a browser or device identifier.
Anonymous profiles contain:
Recent interactions (page views, product views, cart activity)
Page and content context (category, product ID, locale)
Session information (referrer, campaign parameters)
Anonymous profiles don't contain:
Confirmed customer ID
Confirmed email address
Deterministic link to the same person on another device
With anonymous profiles, you can:
Retarget based on recent product or category interest
Suppress ads for recent converters (if purchase events are collected)
Trigger on-site messages based on browsing behavior
Activate to cookie-based destinations (for example, display retargeting)
Known profiles
Known profiles have a stable business identifier associated with them. A profile becomes known when a visitor shares an identifier, such as their email address or username, on the website or app.
What known profiles enable:
Activating data in destinations that require an email address or phone number (for example, email platforms, CRM-matched ad audiences)
Cross-device continuity when the same identifier appears on multiple devices
Suppression and targeting based on customer status, value, or other business attributes
Stitched profiles
Stitched profiles combine anonymous and known activity on a single profile. When a previously anonymous visitor provides an identifier, the Data Activation links the two identities.
Example stitching flow:
An anonymous visitor views products on a website.
The visitor logs in and provides their customer ID.
Data Activation links anonymous browsing to the known profile.
The profile now contains both web behavior and business attributes.
You can increase the proportion of known profiles to anonymous profiles (known as the stitch rate) by linking the anonymous profiles with known identifiers:
Encourage login earlier in the customer journey.
Capture email through value exchanges (newsletters, gated content).
Use deep links in owned channels that carry customer identifiers.
Instrument backend systems to send known identifiers on key events.
How identifiers become available in known and stitched profiles
Common events when anonymous profiles become known:
Login: Yields a customer ID.
Account creation: Establishes a new known identity.
Email capture: The form submission provides the email address as the identifier.
Checkout: Order completion provides a customer ID.
Deep links from email: Links containing customer identifiers.
Mobile app login: Provides a stable app user ID.
Cross-device behavior
Cross-device continuity depends on whether the same deterministic identifier appears on both devices, such as a computer and a mobile phone.
If a customer logs in on a new device, the same customer ID becomes available and can be linked. Data Activation treats the two device identities as the same customer.
If a customer never logs in on the new device, the identity remains separate. Activity on that device is associated with an anonymous profile.
Common issues
Duplicate profiles: If different systems, such as CRMs, data warehouses, or ESPs, use different identifiers without a mapping strategy, you may end up with multiple profiles for the same person. Use consistent identifiers and identity resolution to avoid duplicate profiles.
Stale attributes: Profile attributes reflect only what was ingested during the last sync. If the sync intervals are too far apart, targeting will be based on outdated data.
Missing identifier links: If a customer uses multiple devices but never logs in on one of them, their activity on that device may be recorded under a separate anonymous profile.