Customer Journey Analytics: Conversation Insights, consent, alerts

Adobe's September 2026 Customer Journey Analytics notes bring chat data into Analysis Workspace, add consent policy filtering and reporting, tighten how alerts are delivered, and add a segment option that keeps results inside the reporting date range. The common thread is that CJA is being asked to answer for things that used to sit outside it: AI-driven conversations, privacy rules and data that arrives late. Some of it needs action this quarter. Some of it you can safely watch.

Key takeaways

• Conversation Insights brings prompts, responses and agent metadata from custom agents or Adobe Brand Concierge into Analysis Workspace. General availability is listed as September 30, 2026, slipped from September 22.
• Consent policy filtering can exclude non-consenting visitors before ingestion. That is a governance decision, so involve privacy and legal before switching it on.
• Alerts now fire at the end of the delay window you set, and late-arriving data is left out. Set the delay from measured latency.
• The new segment option that limits results to the reporting date range removes a quiet source of over-reporting in Person-level segments.
• Hourly alerts, Adobe Brand Visibility and the Coworker skills are listed for September or September 30 without a stated rollout start, and their documentation is still to come. Pilot them; don't build plans on them yet.

What changed in Customer Journey Analytics in September 2026?

The release notes list nine feature entries. Four are about data and governance, three are about alerting and segmentation, and two are about AI. The table below groups them by who is likely to care and what a sensible first move is. Dates are as the notes state them; where a rollout start is not stated, the table says so.

The notes are careful in one respect: several rows say documentation links will follow. That matters for how you treat them, and we come back to it in the rollout section.

How does Conversation Insights change LLM chat analytics?

Conversation Insights is the headline. Adobe says CJA can now bring unstructured chat data into Analysis Workspace so you can report on LLM-powered browsing and buying experiences across your properties. The data comes from conversational agents, either your organisation's own custom agents or Adobe Brand Concierge, and it is collected through Web SDK. The notes name three things you can do with it: analyse intent, tone and sentiment; analyse at scale using your existing schema, datasets and data views; and connect conversations to outcomes by tying agent interactions to broader customer journeys.

The last point is the one that matters. Most teams running a chat assistant today can tell you how many conversations happened and maybe a satisfaction score from the chat vendor. What they can't easily say is whether people who talked to the assistant converted at a different rate, or whether a conversation that went badly preceded a support call. CJA's strength is stitching events across channels into a person-level journey, so putting chat into the same data views is the natural way to answer that.

Be realistic about what this asks of you. The notes say the data arrives through Web SDK and lands in your schema, datasets and data views. Someone has to decide how prompts and responses are represented in the schema, how agent metadata is modelled, and what is sent at all. Prompts can contain whatever customers type, including things they should not have typed. Before any of that flows, your privacy team should decide what is collected and how long it is kept.

Also note the date. General availability moved from September 22 to September 30, and the documentation link is still marked to follow. If you have a chat agent in production, the sensible step now is a design conversation, not a build sprint. Sketch the schema fields you would need, list who would consume the reports, and hold the implementation until the documentation lands.

What should teams do about consent policy filtering and data usage labels?

Two entries here belong together. The first adds support for more data usage labels on dataset elements: C2 (restrict third-party data export) and C3 (restrict directly identifiable data combination) are available now, and C9 (restrict data science) is described as planned for August or September. The second adds consent policy filtering and reporting: you can report on which visitors match your Adobe Experience Platform consent policies, with consent policy dimensions and metrics added to the data views in your connection, and you can exclude non-consenting visitors before their data is ingested.

There are two very different uses hiding in that second entry, and the choice between them is not technical.

1. Report only. You keep the data and add consent dimensions so analysts can see how much of your traffic falls under each policy and compare behaviour. Low risk, and useful as a first step.
2. Exclude before ingestion. Non-consenting visitors never reach CJA. That is cleaner from a compliance stance, but your totals will drop, trend lines will shift at the moment you switch it on, and history ingested earlier will not look like history ingested afterwards.

Our position: start with reporting. Understand the size of the consent gap first, then decide whether exclusion belongs in CJA or upstream. Turning on exclusion without warning stakeholders is how a Monday dashboard review becomes a debate about why visits fell by a fifth, when nothing about the business changed.

For the labels, the practical work is a mapping exercise. Which datasets carry fields that should be barred from third-party export, or from being combined with directly identifiable data? Those are the C2 and C3 questions. Adobe's Labels, policies and marketing actions documentation is the place to confirm how they behave. Don't apply C9 in your plans until it ships; the notes only say it is planned.

Why do the alert changes matter more than they look?

Two alert entries look like housekeeping and are not. Hourly alerts let you set an alert's time granularity to Hourly. The notes say they are intended for data that arrives within a given hour, and that if your data has latency longer than an hour, a longer granularity ensures the alert evaluates complete data. Separately, alert delivery now strictly adheres to the configured delay. Alerts go out at the end of the delay window you set, whether or not data is complete. Anything arriving later is not included. Before, a background check waited for late data, even if that meant delivery after your configured delay.

Here is what that means in practice. Suppose you have an alert on checkout completions with a short delay, and your commerce events reach CJA about forty minutes late on a busy day. Under the old behaviour, the alert might quietly wait and arrive later, but with fuller numbers. Under the new behaviour, it arrives on time with whatever is there, so a perfectly healthy hour can look like a drop. The alert didn't get worse; the trade changed from completeness to punctuality.

So do this:

• List your existing alerts and note the delay on each.
• For each one, find out how long its data actually takes to arrive. The notes suggest checking with a data engineer, and that is right.
• Lengthen the delay on any alert where late data is normal, or keep the shorter delay and accept that it is a rough early signal.
• Only then consider Hourly granularity, and only for feeds that reliably land within the hour.

Don't switch everything to hourly because it sounds more responsive. An alert that fires falsely every morning trains people to ignore it.

Does the segment date-range option change your reports?

Yes, if you use segments with date components. The notes explain that data in a Workspace report can extend beyond the reporting date range when a segment includes date range components. A new option lets you limit results to the reporting date range regardless of any date components in the segment. It is available when you create or modify a segment whose top-level container is Person. The notes give August 26, 2026 as rollout start and September 9, 2026 as general availability.

The classic case is a segment such as 'people who visited in the last 90 days', used in a report that only covers last week. Without the option, the report can pull in data outside last week, because the segment's own date logic reaches beyond the panel's range. Someone reads the number as last week's figure, and it isn't.

What to do: find your most reused Person-level segments and check whether any carry date components. For those, decide whether you want the segment's own window to win, which is sometimes the point of a cohort definition, or the report's range to win. Then set the option deliberately. Don't flip it on everywhere. Some cohort-style analyses depend on the segment reaching outside the panel, and changing them silently would alter results people already trust. Record the decision in the segment description so the next analyst knows.

What about the MCP server plugin, Brand Visibility and Coworker skills?

Three entries sit under AI, and they deserve different levels of attention.

The Customer Journey Analytics MCP server plugin, for ChatGPT and Claude, is listed with rollout and general availability both on September 1, 2026. The notes say it lets you quickly access your data, and point to Adobe's Connect to ChatGPT and Connect to Claude pages. The real question for most organisations is not whether it works but who may use it. Any route that lets an AI assistant query analytics data is an access-control decision. Decide who is permitted to connect, which data views are exposed, and how you review what is being asked. Your admin team, not the enthusiast who found it first, should own that call. Use Adobe's connection guides for the specifics.

Adobe Brand Visibility integration is listed for September 2026, with a documentation link to follow. The stated purpose is to connect Brand Visibility with your CJA data so you can measure how AI-driven discovery translates into website engagement and business outcomes. It's a sensible idea, but with no rollout start and no documentation yet, there is nothing to configure. Note it and move on.

The Coworker skills are listed for September 30, 2026: implementation guide skills that generate a tailored list of upgrade or implementation steps, checklist skills that turn that into a Coworker Project to track progress, assign tasks and add approval gates, and data validation skills that check your implementation against best practice. If you are planning a CJA upgrade or a new implementation, these could be a useful starting checklist. Treat the output as a draft to challenge, not a plan to accept, until you have seen the documentation and tried it against your own setup.

How should you roll these changes out and test them?

Stage the work by risk, not by feature order.

This week (low effort, high value). Audit alerts and their delay settings. Audit Person-level segments with date components. Both changes are already described as generally available or landing in September, and both can quietly alter numbers people rely on.

This month (needs a decision). Get privacy, legal and data engineering together on consent policy filtering. Agree report-only or exclude-before-ingestion, and agree the date you will announce it. Review dataset labels against C2 and C3.

When documentation exists. Conversation Insights, hourly alerts, Brand Visibility and the Coworker skills. Build a small pilot first: one agent, one property, one data view, a handful of reports.

A simple checklist with owners keeps this from drifting:

Test in a sandbox or a non-critical data view where you can, and compare before and after on a few known reports. If a number moves, you want to know whether the cause is the feature or your data.

How do you measure whether any of this worked?

Pick a few plain measures per change, and record the baseline before you touch anything.

For alerts, count false alarms and missed events over a month before and after adjusting delays. If people started ignoring an alert, that is a measure too, just an informal one. For segments, take three or four reports that use date-component segments and note their totals before and after applying the new option; explained differences mean it worked, unexplained ones mean stop.

For consent reporting, the first outcome is simply a number you didn't have: the share of visitors under each policy. For exclusion, measure how your headline metrics shift on the switch-over date and annotate that date on your dashboards.

For Conversation Insights, the useful question is whether chat interactions relate to outcomes you already track, such as conversion or support contact. Start with a comparison you can defend, for example people who used the agent versus comparable people who did not, and be cautious about causal claims. People who choose to chat may already be more likely to buy, and no dashboard will tell you otherwise. The notes describe the capability as connecting conversations to outcomes; they don't promise any particular result, and neither should you.

Where does an implementation partner actually help?

Most of the September items are admin work a capable in-house team can do: alert delays, segment settings, label mapping. Don't pay anyone to read your alert list.

A partner earns their fee where the work crosses teams or needs design judgement. Conversation Insights is the clearest case. Deciding how prompts, responses and agent metadata fit an existing schema, what gets sent through Web SDK, and how conversations join journeys without breaking current reports is architecture work with privacy consequences. Consent design is the second: getting Adobe Experience Platform consent policies, data usage labels and CJA ingestion to line up is a cross-system job where mistakes are expensive and hard to see. A third is upgrade or implementation planning if you are starting from scratch, where an experienced partner will have seen the traps that a generated checklist may not.

If you go that route, brief them properly. Say which agents produce chat data, which consent regimes apply, what your current latency is and what decisions the reports must support. Our Customer Journey Analytics RFP template is a starting point for that brief. To see who works in this area, the Customer Journey Analytics partners page lists options, and find partners lets you narrow by need.

What should you avoid doing?

• Don't build on undocumented features. Hourly alerts, Brand Visibility, Coworker skills and the Conversation Insights documentation are all marked as following. Wait for them.
• Don't turn on consent exclusion silently. Announce it, date it and annotate dashboards.
• Don't shorten alert delays to feel faster. With strict delay adherence, a delay shorter than your data latency produces misleading alerts.
• Don't apply the segment date option blanket-style. Decide per segment.
• Don't open MCP access to everyone. Treat it as an access decision, and confirm details against Adobe's own guides.
• Don't plan around C9. The notes call it planned, not shipped.

The release notes update several times a month under Adobe's continuous delivery model, so check the page again before you commit dates to a project plan. The status of anything marked September, and the Conversation Insights date in particular, may change.

Sources

• Adobe Experience League: Current Customer Journey Analytics release notes — September 2026 release notes, last updated September 28, 2026; source for every feature, date and behaviour described.