Unknown-to-known profile resolution

What it does

A tracking script on the client's website creates an unknown profile for every anonymous visitor, keyed on a cookie ID, and records what they browse on a timeline. When that visitor identifies themselves, a setUser call ties the cookie ID to a customer record, and the next unification run merges the anonymous history into the known profile.

Key facts

This is a preview capability. Access is requested through a Microsoft form rather than simply switched on, and it is not intended for production use in its current state.
Unknown profiles are identified by a cookie ID. The tracking cookie has a rolling one-year expiry that refreshes on each visit, and each device and browser combination gets its own GUID — so one person browsing on a phone and a laptop is two unknown profiles until they authenticate on both.
Unknown profiles appear on the Unknown tab of the Customers page, typically within about 30 seconds of activity, with the activity streamed to Dataverse in real time.
The profiles documentation states that unknown profiles expire after seven days of inactivity unless they are converted to known profiles.
Unknown profiles are free and do not count towards billed profile volume.
Setup is: choose the source table that identifies known web customers (it must be one that participates in unification), copy the tracking script, and paste it into the site's <head>. Google Tag Manager custom HTML tags and CMS script-injection features both work.
Identification is done by calling window["MSCI"].setUser({ "authId": "<identifier>" }) at the moment of authentication or form submission — typically wired to a submit button handler.
The merge uses the same matching logic as data unification, matching on the selected table's primary key. It is not a separate identity engine.
After the merge, the known profile inherits the unknown profile's activity history, the cookie ID becomes an identifier on the known profile, and the unknown profile expires. Segments, measures and API consumers all reference the known profile from that point.
Web personalisation activities are not rendered on the standard customer activity timeline in the same way as configured activity tables.

When to use / skip

Use it where the client runs a content or ecommerce site with a real authentication moment — account creation, checkout, gated content download, webinar signup — and genuinely intends to act on pre-authentication browsing behaviour. The value is entirely in that history stitching backwards onto the known profile; without a plan for what to do with it, you have built a very expensive analytics package.

Skip it on most projects, and say so plainly. It is preview, it requires the client's web team to change site code and keep the setUser call correct through every future release, and it introduces a cookie and a processing purpose that UK and EU clients must handle in their consent management. If the site already has a decent web analytics stack and the marketing team is not yet acting on known-profile data, this is not the next thing to build.

Configuration decisions

Which source table represents known web customers. It must take part in unification, and its primary key is what setUser passes, so this decision constrains the web team's implementation.
What identifier the site passes as authId. A stable internal customer ID is right; an email address is tempting and fragile.
Every point on the site where identification happens, and whether setUser fires at all of them. Missing one means those sessions never stitch.
How the tracking script is deployed — inline in the template, through the tag manager, or via a CMS plugin — and who owns it when the site is redeployed.
How this cookie is presented in the consent banner and privacy notice, and whether the script should be gated behind consent.
Whether unknown-profile browsing history is in scope for segmentation at all, or whether it is being captured purely for future use.

Gotchas

Stitching only happens at unification. It is not real time, so a customer who identifies at 10am will not have a merged profile until the next run, and stakeholders shown a real-time demo will expect otherwise.
The setUser call lives in the client's website code, outside your solution and outside ALM. A site release that drops it fails silently — visitors keep tracking, nothing ever merges, and nobody notices for weeks.
One person on three devices produces three unknown profiles. Only the devices where they authenticate get merged; the rest sit as orphaned unknowns until they expire.
The seven-day inactivity expiry means slow-converting audiences lose their pre-authentication history entirely. For a considered purchase with a long research cycle, that may be most of the value.
Cookie behaviour is at the mercy of browsers and consent tooling. Safari and Firefox restrictions, plus a consent banner that blocks the script, will cut coverage substantially versus what a demo implies.
Preview status means the surface can change and there is no production support commitment. Do not build a client-visible commitment on it without saying so in writing.

Consultant notes

Get the client's web team into the design conversation on day one. This feature is delivered by them, not by you, and treating it as a Customer Insights configuration task is how it ends up half-implemented.
Involve the DPO before the script goes anywhere near production. Anonymous behavioural tracking joined to identified customer records is exactly the processing that needs a lawful basis and a consent story.
Demo the merge with a scripted walkthrough — browse anonymously, sign in, run unification, show the history on the known profile. Anything less and the point does not land.
Set the expectation about batch stitching explicitly. "Real-time web personalisation" in the product name does a lot of work that the merge behaviour does not support.
Before go-live, add a monitoring check that unknown-to-known conversions are actually happening. A count of merged profiles per run is the only early warning you will get that the site-side call has broken.

Worth another look when this leaves preview, or if stitching moves off the unification schedule.