Segments on Journeys interaction data

What it does

Behavioural interaction data from Customer Insights - Journeys — email opens, link clicks, form submissions, event check-ins — shows up in the segment builder against unified profiles, so you can build audiences on what people actually did in campaigns rather than on profile attributes alone.

Key facts

Preview at the time of writing. The docs carry the prerelease notice and no GA wave is named.
Both apps have to be deployed in the same environment, and the data has to be unified so that contacts or leads have become unified customer profiles.
In the segment builder the interaction fields sit under a Behavioral tab in the side panel. Drag a field into a rule, then set operator, value and an optional time window such as the last 7 or 30 days.
Email interaction types include sent, delivered, opened, link clicked, bounced, blocked, and consent not given. Push notification types cover sent, not sent, opened and link clicked. Text message types cover sent, not sent, delivered, bounced and link clicked.
Event and form types cover marketing event check-in, event registration created, event registration cancelled, form submitted and form visited.
Each interaction type exposes fields including journey, email, email address, email client, timestamp, profile ID and profile type.
Batch only. Interaction data lands on the Customer Insights - Data system refresh, so segments reflect interactions as of the last successful refresh, never live.
Only interactions linked to a unified customer profile are visible. Anything against a contact or lead that didn't make it through unification is not there.
The interaction data does not appear on the customer profile timeline in Customer Insights - Data — it exists for segments and measures and nowhere else in the app.
Initial ingestion takes anywhere from 30 minutes to several hours depending on volume, so don't judge an empty Behavioral tab in the first hour after setup.

When to use / skip

Use this when the client's segmentation needs engagement signals that live in Journeys and their profile data can't express — re-engagement audiences, non-responders, event attendees, people who clicked a specific product link and also carry a high value score. Combining a behavioural condition with a profile or measure condition in one rule is exactly the case this exists for, and it's genuinely hard to do any other way without exporting interaction data and re-ingesting it.

Skip it where the requirement is real-time or near-real-time reaction. Journeys itself does that with its own triggers and segments; pulling the signal into CI Data adds a refresh cycle of latency for no benefit. Skip it too on projects where Journeys and CI Data sit in different environments — the prerequisite is not negotiable and the workaround is an ingestion pipeline, which is a different piece of work.

Because it's preview, keep production dependencies on it deliberate and few, and make sure the client understands what preview means for support.

Configuration decisions

Whether the audience logic belongs in CI Data or in Journeys. Draw that line explicitly at design time rather than letting each team build in whichever tool they know.
Which interaction types the segmentation model will actually use. All of them are available; using all of them makes segments nobody can explain later.
The time windows on behavioural conditions, and whether they're floating (so a scheduled segment stays meaningful) or fixed to a campaign period.
How unification handles contacts and leads, since anything that doesn't resolve to a unified profile is invisible here. That's a data unification decision with a direct segmentation consequence.
Whether to express the behaviour as a measure first — count of email opens in 60 days, say — and then use the measure as a segment condition, which is more reusable than repeating the same behavioural condition in a dozen segments.
What refresh cadence the behavioural segments need, given they can never be fresher than the system refresh.

Gotchas

The latency question is where expectations break. Business users hear "email opens are in segments" and assume minutes. It's the system refresh, and saying so early avoids an awkward conversation later.
Interactions from non-unified contacts and leads are silently absent. Counts will be lower than the equivalent report in Journeys, and the explanation is unification coverage, not a bug.
Nothing shows on the profile timeline, so support agents looking at a customer in CI Data won't see the interactions that put them in a segment.
Preview status means the field list and behaviour can shift between waves. Segments built on a specific interaction type are exposed to that.
The 30-minutes-to-several-hours initial ingestion means a fresh environment looks broken. Set that expectation with whoever is doing the first configuration.
Consent-related types such as email consent not given are available as conditions, which tempts people into rebuilding consent logic in segments. Consent belongs where it's governed, not scattered through segment definitions.

Consultant notes

Demo a combined segment — behavioural condition plus a measure or profile attribute — because that's the thing neither product does alone and it's what justifies the integration.
Say "preview" out loud to the client's sponsor and get it minuted. Preview features in a go-live scope need a documented fallback.
Check unification coverage for contacts and leads before promising behavioural segmentation. If half the contact base doesn't unify, the feature underdelivers and it won't look like a unification problem.
Where the same behavioural condition appears in several segments, build it once as a measure. It's less work at build time and much less work when the definition changes.
Before go-live, compare a behavioural segment's count against the equivalent view in Journeys and be ready to explain the gap in terms of refresh timing and profile linkage.

Worth another look once this reaches GA, or if the interaction type and field list expands.