Segmenting on Customer Insights – Data profiles

What it does

When Customer Insights – Journeys is connected to Customer Insights – Data, you can target unified customer profiles instead of Dataverse contacts or leads, use CI-Data segments directly as a journey audience, and pull unified attributes and customer measures into segment criteria and message personalisation. It's the answer for clients whose customer data doesn't live in Dataverse.

Key facts

The connection is GA. The CI-Data environment has to sit in a region where Customer Insights – Journeys is available.
Data sharing between CI-Data and the Dataverse organisation must be enabled in CI-Data's advanced settings, and map, match and merge rules must be configured so profiles actually unify.
If CI-Data was set up before Journeys was provisioned, discovery is automatic. Otherwise you go to Settings > Data management > Customer Insights - Data connector and select Connect.
At least one segment must exist in CI-Data before the integration is useful.
CI-Data segments appear alongside native segments in the journey Audience dropdown; you don't rebuild them in Journeys.
Unified profiles have no default recipient fields. You must nominate which attribute is the preferred email and which is the preferred phone number, in audience configuration, or nothing can be sent.
To use profiles in a trigger-based journey, set the custom trigger's Customer Data property Data type to Profile (Customer Insights - Data).
Building Journeys segments that mix contact data with unified profile attributes and customer measures requires CustomerId backstamping (COLA stamping) to be set up and completed — a requirement from the January 2025 release.
Customer measures are calculated metrics defined in CI-Data. The segment builder presents them as though they were one-to-many, but only single-dimension measures are supported: one value comes back per customer.
Changing unification rules in CI-Data can affect or break live journeys, because the profiles underneath them shift.

When to use / skip

Use it when the customer view genuinely lives outside Dynamics — an e-commerce platform, a loyalty system, a banking core — and the marketing team needs to segment on data that will never be a Dataverse column. Also use it when the client already owns and runs CI-Data; there's no sense rebuilding their measures as Dataverse rollups.

Skip it if the client's customer data is already in Dataverse and reasonably clean. CI-Data is a substantial piece of platform in its own right, with its own licensing, its own ingestion, its own unification design and its own team. Bolting it on to solve a segmentation problem that three related-table conditions would fix is the most expensive mistake available in this product area.

Also skip the profile audience type if the client mostly wants personalisation rather than targeting. You can pull CI-Data attributes into content without making profiles the audience of every journey.

Configuration decisions

Whether unified profile is the audience type for journeys at all, or whether CI-Data is only a source of attributes and measures for contact-based journeys.
Which unified attribute serves as the preferred email and preferred phone. Get this wrong and you send to a stale address at scale.
Who owns the map/match/merge rules, and what the change control around them is, given live journeys depend on them.
Which measures need to exist in CI-Data before segmentation design starts, and confirming each is single-dimension.
Whether CI-Data segments or Journeys segments are the system of record for a given audience — running both invites two definitions of "active customer".
Sequencing: CI-Data connection, unification and backstamping all need to be complete before segment build starts, not in parallel with it.

Gotchas

Unification rule changes are a live-journey risk with no warning in the Journeys UI. Treat CI-Data unification as a production change, not a data-team experiment.
Backstamping is a genuine prerequisite, not a nicety. Without it, mixed contact-plus-profile segments won't behave, and the failure mode is confusing rather than explicit.
The measures picker implies you can bring back multiple values per customer. You can't. Anyone designing on that assumption will need to redesign.
Consent and compliance for profile-based sends depend on the recipient fields you nominated. A profile whose preferred email attribute is empty is simply unreachable, and it won't shout about it.
Region matters. A CI-Data environment in a region Journeys doesn't cover is a hard stop, discovered late and expensively.
If the connector wasn't auto-discovered, nothing in the UI tells you the integration is missing — you just don't see the audience options you were expecting.

Consultant notes

Establish whether the client has CI-Data licensed before designing anything that depends on it. This is the most common source of a mid-project scope collapse in this area.
Insist the unification design is signed off and stable before journey build starts. Marketing's timeline and the data team's timeline are rarely the same, and marketing loses.
Demo a personalised message using a customer measure early. It's the clearest illustration of why the client paid for CI-Data, and it validates the connection end to end.
Check the preferred email and phone attribute mapping as a specific go-live item. It's one dropdown and it's the difference between a campaign and an incident.
Where the client only needs one or two external attributes, make the case for ingesting them into Dataverse instead. Cheaper, simpler, and one fewer platform to run.

Worth another look if multi-dimension measures land, or if the CI-Data connector setup changes again.