Where segmentation should live: CI Data, Journeys, or the source system

What it does

Segments can be built in three places on a typical Microsoft estate: Customer Insights - Data, over unified profiles and measures; Customer Insights - Journeys, over Dataverse contacts and leads with real-time behaviour; or in the source system itself. Journeys interaction data flows into CI Data segments and measures on the Behavioral tab, and CI Data segments flow into Journeys through Dataverse — so the two are joined, but not symmetrically.

Key facts

Journeys interaction data (email opened, link clicked, form submitted, event check-in, push and text message events) appears in CI Data under the Behavioral tab in both segment builder and measure builder.
That flow is batch, on the system refresh schedule. It is not real time. Real-time branching stays in Journeys.
Only interactions linked to unified customer profiles are visible. Interactions against contacts or leads that never made it into unification don't appear.
Interaction data isn't shown on customer profile timelines in CI Data, and isn't available anywhere except segments and measures.
Initial ingestion of interaction data can take from 30 minutes to several hours depending on volume.
CI Data segments sync to Dataverse as msdynci_segmentmembership, and Journeys picks them up under "Customer Insights segments". If the segment doesn't appear, check Settings > Data sharing.
Segments are static (manual refresh) or dynamic (refreshed on schedule), and you can flip between them with Make static and Make dynamic.
Segments unused in an export, measure, another segment or Journeys for 45 days or more are auto-deactivated. Admins can set Disable auto cleanup on a segment to prevent it.
Active segments and active measures share a combined limit of 1,000, and approaching it shows up as slower refreshes or out-of-memory failures.
Both products need to be in the same environment for the interaction data flow to work, and the Journeys contacts or leads need to be part of unification.

When to use / skip

The rule I give clients: segment where the data lives, activate where the customer is.

Build in Customer Insights - Data when the definition needs more than one source system — spend across channels, a measure combining transactions with service history, a predicted score. That's the whole point of the unified profile and nothing else on the estate can do it.

Build in Journeys when the segment is about campaign behaviour and timing, particularly anything that needs to react within minutes. The batch nature of the interaction data flow is the deciding fact: "opened an email in the last hour" belongs in Journeys, "opened five emails in 60 days and has a high lifetime value" belongs in CI Data. Trying to force real-time reactions through CI Data segments produces a segment that's correct and hours late, which in practice is wrong.

Leave it in the source system when the segment is operational rather than customer-facing — a service queue, a dunning list, a stock notification. Those need the source system's own state, and round-tripping through a CDP adds latency and a support conversation for no benefit.

Where I'd break my own rule: a client with a small marketing team and no appetite for governing two segmentation tools. Pick one, usually CI Data, accept the batch latency, and keep Journeys segmentation for the handful of triggered scenarios that genuinely need it. Two tools with unclear ownership produces contradictory numbers in meetings, which costs more credibility than the latency costs revenue.

Configuration decisions

Which product owns each segment type, written down as a short rule the marketing team can apply themselves.
Whether Journeys contacts and leads are included in unification, since interaction data is only usable for profiles that are.
Static or dynamic per segment, and the refresh cadence for the dynamic ones relative to the system refresh.
Whether measures are built in CI Data and shared, or recreated per segment — recreating them is how the 1,000 combined ceiling gets eaten.
Which segments get Disable auto cleanup, and who reviews the rest.
Whether Dataverse data sharing is enabled, without which nothing reaches Journeys at all.

Gotchas

The one-way asymmetry catches people out: segments and measures flow to Journeys, but interaction data only reaches CI Data in batch. Clients hear "integrated" and assume both directions are live.
A segment showing zero members in Journeys usually just hasn't refreshed yet, not a broken configuration. Check the last refresh before debugging.
Interaction data not appearing on the profile timeline surprises service users who expected a single view of engagement.
Auto-deactivation at 45 days quietly kills seasonal segments — the Christmas segment nobody touched since January.
Every segment counts against the shared 1,000 limit with measures. Marketing teams generate segments fast, and the symptom of approaching the limit is slow refreshes, not an error message.
Duplicate definitions in both tools drift apart within a quarter and then two dashboards disagree, which becomes your problem regardless of who built them.

Consultant notes

Agree the split at design time and put it in the operating model document. This decision is organisational, and if you leave it to build phase the tools decide it for you.
Demo the Behavioral tab to the marketing team — it's the thing that makes the CI Data and Journeys relationship concrete, and it changes how they scope requests.
Push back on "we'll rebuild every source-system list in the CDP". Most of them are operational and belong where they are.
Before go-live, verify the Dataverse sync and check msdynci_segmentmembership populates, and name someone who reviews auto-deactivated segments monthly.
Tell the client the latency figure in plain terms — segments are as fresh as the last system refresh. It's better heard from you now than from a campaign manager later.

Worth revisiting if the Journeys interaction flow into segments ever becomes near real time, or if the combined segment and measure ceiling changes.