Detect Experience Platform anomalies
Use Adobe CX Enterprise Coworker Chat to identify spikes and drops in supported Adobe Experience Platform metrics. Ask about data flows and audiences to find deviations from a baseline.
Start with a broad question, then focus on a flow or audience that needs attention. Review the reported metric and its baseline before deciding what to investigate.
Available diagnostic skills
Use the baseline-anomalies plugin to detect anomalies, compare trends, and review flow health or current job failures. The plugin is configured by default with the Experience Platform and Apps offering in Coworker.
Choose the type of question based on the information you need.
Trend summaries describe changes but do not determine whether those changes are anomalies. Use anomaly questions when you need a spike or drop assessment.
Before you begin
The plugin is configured by default. To check its status before asking diagnostic questions, follow these steps.
-
Go to Customizations.
-
Select Plugins.
-
Open baseline-anomalies and confirm that its status is Active.
Identify the sandbox and area you want to check. For a specific resource, have its flow, segment, or destination name or identifier ready.
For general chat instructions, see Get started with Chat.
Ask about anomalies
Describe the area or resource you want to check and the time period you want to examine.
Use the following example prompts as a starting point. Replace example names with names from your organization.
The broad question checks both data flows and audiences. Confirm the sandbox and time period identified in the response.
Review anomaly results
Compare the reported value with its baseline for the affected resource and time period. Use the difference to identify what needs further investigation, rather than treating an anomaly as a confirmed cause.
For example, a decrease in ingestion input records identifies a volume change. That change alone does not explain why fewer records arrived.
Results can appear as tables or a written summary. Tables can group anomalies under High risk and Medium risk.
This example groups flow anomalies by risk and suggests investigating run counts or trend history. Resource names and values are redacted.
Review the explanation alongside the risk grouping. For audience anomalies, High indicates a large departure from normal. Medium indicates a clear but moderate departure. Only High and Medium anomalies are returned.
Audience results exclude Medium anomalies when the baseline history is highly variable. Any returned anomaly with highly variable history therefore has a High risk tier.
Use risk tiers to prioritize investigation, not to establish a root cause.
For example, one response identifies 10 input records against an expected range of one to four as a medium risk spike. The usual level is about one record, so the deviation is large relative to the baseline. The absolute volume remains small.
Check event times before treating a historical anomaly as a current issue. An event outside the last 24 hours does not establish whether the underlying condition recovered.
Baselines and expected ranges
Hourly anomaly comparisons use the same hour over the previous 14 days. This accounts for typical patterns by hour, but does not account for broader seasonality.
For audience anomalies, the expected range centers on the median and widens according to variation in the historical counts. If the calculated lower bound is negative, the range uses the lowest historical count instead. The range can therefore extend farther above the median than below it.
Realized profile counts above the expected range are spikes. Counts below the range are drops. A count of zero when profiles are normally present is a High risk drop.
Exited profile counts produce spike verdicts only. Fewer exits are treated as normal, not as drop anomalies.
No anomalies returned
A response can report that no High or Medium anomalies were returned for the requested audience and period.
This example includes a warning about insufficient or mostly zero history. It does not confirm that every hour was evaluated or that this audience was excluded. The audience name and identifier are redacted.
Insufficient baseline history
Baseline history affects whether an audience can be evaluated for anomalies.
Audience anomaly detection does not evaluate rows with fewer than five days of history or a history containing mostly zeros.
Refine your question
Focus your next question on the affected resource. For example, after a broad ingestion check, ask about anomalies for a named flow.
After asking about the last 24 hours, extend the period with this follow-up:
What about in the past two weeks?
The response can identify historical anomalies even when none appear in the last 24 hours.
For a closer investigation, ask about flow run counts, flow trends, audience trends, or currently failed jobs. You can also ask about individual jobs as you investigate.
Choose your next question based on the information you need. Trend and health summaries do not provide anomaly verdicts.
Audience trend history is retained for approximately two weeks, or 336 hours. The typical value is the median for that hour over the previous 14 days.
For currently failed jobs, an empty result means that no jobs are currently failing within the requested scope. It does not mean that no failures occurred during the requested period. Jobs that failed and later succeeded are excluded.
Continue investigating with health check skills, or use alert skills to enable an alert for a supported asset. These actions use separate skills, not anomaly detection itself.
For related alert workflows, see Customer alert skills.
Metric reference
The limited release includes the following seven metrics across ingestion, segmentation, and destination activation. Use this reference to identify the counts associated with each area.
input_record_countfailed_record_count__segment_{segment_id}__realized_profiles__segment_{segment_id}__exited_profiles{destination}_input_record_count{destination}_skipped_record_count{destination}_output_record_countScope and limitations
Use anomaly detection to identify deviations, not to confirm a root cause or repair a resource.
You can ask about flows, segments, and destinations by name or identifier. Flow anomaly detection covers ingestion, segmentation, export, and destination stages.
Use the failed job skill for currently failed jobs and their failure reasons. Recovered failures are excluded. Job diagnostics do not include details for individual records or anomaly verdicts.
Flow health provides aggregate counts, not failure reasons. Trend summaries describe recent and typical values, not anomaly verdicts. Audience trend summaries cover batch segmentation only.
Anomaly detection does not change your data or configuration. Use separate skills for supported alert actions and deeper health investigations.