Marketing Cloud Personalization keeps two profile types per person: an anonymous visitor profile and an identified user profile. Knowing when MCP merges them and when it does not is the foundation of every behavioral signal the platform records.
Marketing Cloud Personalization keeps two distinct profile types for each real person who interacts with a site. The visitor profile is everything the platform learns before it knows who someone is. The user profile is what it knows about the same person once they have signed in, signed up, or otherwise identified themselves. Most production issues with personalization quality come down to one of these two profiles being wrong, or the merge between them happening at the wrong moment.
A visitor profile is keyed by a cookie. The first time a browser arrives at the site, MCP issues a visitor ID and starts attaching behavioral data to it: page views, items viewed, searches, cart adds, dwell time, affinity signals. The visitor profile lives as long as the cookie does, which in practice is the cookie expiry set by the integration (typically 12 to 24 months) or until the user clears storage.
A user profile is keyed by an identifier the site provides when a person identifies themselves. Most commonly this is an email address or an internal customer ID. The user profile is durable across devices and sessions because it is keyed off something stable.
The platform treats these as separate records on purpose. Two browsers that share a household share visitor profiles only by accident. The same person in two browsers shares a user profile if and only if both browsers have at some point identified the same person.
The merge happens at the moment the integration tells MCP "this visitor is now this user." Concretely, that is a setUser call (legacy Evergage SDK) or the equivalent identity beacon on the modern client.
The trigger has to be explicit. Logging in is the obvious case. Newsletter signup with email capture is another. Adding an email to a checkout flow before account creation often is. Any moment the site newly learns who the visitor is should fire an identify call.
Once that call lands, MCP merges the visitor's behavioral history into the user profile. Every product view, every affinity signal, every cart add the visitor recorded becomes part of the user's history. Recommendations, segments, and cross-device coordination all start working from the merged record.
Three patterns silently break identity merge in production.
First, the identify call fires before MCP loads. On pages with deferred SDK loading, the login event runs against an SDK that has not initialized. The call is a no-op. The visitor never gets associated with the user. The fix is to queue identify calls and replay them once MCP confirms ready.
Second, the integration uses the wrong identifier. A site that uses email as the user ID at the front end but customer-ID as the user ID in the catalog feed will produce two disconnected user profiles for the same person. Pick one identifier system-wide, lock it in, document it. Every system that touches MCP user records uses the same key.
Third, the identify call has no user ID at the moment of execution. A common bug: the page fires identify with userId: "" or userId: undefined because the auth state had not hydrated yet. MCP either rejects or, worse, accepts the empty value as a valid identity. Guard the call. Skip it if there is no real ID.
The user profile is the cross-device anchor. A person who logs in on their phone, then later logs in on their laptop, ends up with two visitor profiles (one per device cookie) but one user profile shared between them. The merge happens device-by-device the moment each device fires its identify call.
What does not transfer cleanly: behavioral data accumulated on a device before that device ever identified. If a user browsed anonymously on the laptop for three weeks, then signed in for the first time, the prior three weeks of laptop behavior get retro-merged into the user profile. That is good. But if the user later clears cookies on the laptop and never signs back in, the next anonymous session on that laptop is a fresh visitor profile, disconnected from the user profile that already exists.
For programs that depend heavily on cross-device continuity, the rule is to encourage signed-in browsing. Every additional anonymous session is a chunk of behavioral data the platform may lose track of.
Visitor profiles age out with the cookie. Cookie clear, browser change, private window, all break the visitor profile chain.
User profiles age out only by data retention policy. If MCP retains user data for two years (configurable), a user who has not been seen in 25 months is purged. Behavioral history is lost. The next sign-in starts a new user profile with the same ID but no history.
Most teams underestimate how often visitor profiles churn. On consumer sites with a privacy-conscious audience, anonymous visitor profiles routinely turn over every two to four months even when the site cookie expiry is nominally 12 months. The implication is that affinity learning has less time to develop than the configured cookie suggests, which is one of the reasons cold-start performance matters more than the marketing material implies.
The discipline that protects against profile-merge bugs is short and worth writing down once per project:
The visitor-versus-user distinction is one of those concepts that feels obvious on the slide deck and produces six months of subtle data quality issues in production. Understanding which profile owns a given behavior, and the rules that move data between them, is foundational to everything else MCP does. Sapota's Salesforce team rebuilds this clarity into every Personalization engagement before touching campaigns.
Implementing or auditing identity logic in Marketing Cloud Personalization? Sapota's Salesforce team handles identity strategy, merge configuration, and cross-device coordination on production engagements. Get in touch ->
See our full platform services for the stack we cover.
Marketing CloudApr 25, 2026
SFMC's built-in tracking covers opens, clicks, bounces. It doesn't cover the business context you need to reconcile with a CRM. Send Log DE is how we capture the extra fields that matter.
Read More
AI AgentsApr 21, 2026
A founder's chat product had a problem: users were abandoning the conversation before the AI agent finished responding. The p95 latency was 31 seconds. The team's instinct was to switch to a smaller model. The actual fix was four changes that did not touch the model at all. Here is the latency stack most teams overlook.
Read More
Dynamics 365May 12, 2026
Enterprises upgrading from Dynamics AX 2012 to Dynamics 365 Finance & Operations face a specific decision about existing customizations. Migrating overlays as-is preserves short-term function and breaks every One Version update going forward. The right path is redesign through fit-gap and the extensibility model.
Read More
ShopifyApr 29, 2026
A freelancer helping a small business pick an ecommerce platform - tight budget, limited technical expertise, minimal maintenance tolerance - lands on Shopify for specific reasons. Understanding why it fits this profile (and where it doesn't) is the first conversation.
Read MoreWe build trust by delivering what we promise – the first time and every time!
We'd love to hear your vision. Our IT experts will reach out to you during business hours to discuss making it happen.
"Collaborate, Elevate, Celebrate where Associates - Create Project Excellence"
SapotaCorp beyond the IT industry standard, we are
