4.2 Live & All-Time Reporting Dashboards

4.2 Live and All-Time Reporting

Journey reports answer two different needs: “What is happening now?” and “How did the journey perform over a broader period?” Understand the processing window before diagnosing a number.

Live report

The Live report focuses on journey activity during the last 24 hours. It is designed for operational monitoring of entrances, people in progress, exits, actions, errors, and discards. Data is not instantaneous; Adobe documents a minimum processing latency of about two minutes.

Use Live after publication to verify that expected entries begin, branches receive plausible volume, and actions do not show an unusual failure spike. Do not declare a defect because a message sent seconds ago is absent; first allow the reporting pipeline to process it.

Live reporting is a rolling recent view, not long-term trend storage.

All-time report

The All-time report provides broader performance analysis and is powered by Customer Journey Analytics. It supports journey and channel metrics over the report's available date range. Use it to compare versions, paths, content performance, and outcomes rather than treating a single recent count as the full story.

“Global report” is sometimes used informally or in older materials, but the important distinction is recent operational Live versus broader All-time analysis.

Interface horizon versus retention

Do not confuse three concepts:

1. Live window: the most recent 24 hours.
2. Journey reporting interface horizon: approximately 91 days for the relevant UI view.
3. Underlying system-dataset retention: controlled by Journey Optimizer time-to-live settings and data-store behavior.

Current Journey Optimizer documentation describes default system-dataset retention of 90 days in Profile Store and 13 months in the Data Lake. Data is not permanent merely because it is written to an AEP dataset. Retention can evolve, so operations should verify current documentation and organizational policy rather than promise indefinite access.

If the business needs longer analysis, design an approved analytics and data-retention strategy. Do not disable retention casually; privacy, cost, and governance apply.

Read the execution funnel

Interpret metrics as a funnel:

• Entrances: people or executions that started.
• In progress: currently active, often in waits or downstream processing.
• Exits/completions: executions that reached an end or otherwise left.
• Action executions: attempts at channel or custom actions.
• Successful delivery or engagement: channel-specific downstream outcomes.
• Errors: technical failures in activities or dependencies.
• Discards: a profile or event was not processed for a documented reason, such as eligibility or journey rules.

These counts need not be equal. An entrant may wait, follow a branch with no action, be capped, be ineligible for a channel, hit an error, or time out. Reconcile each split rather than assuming “entries minus sends” means a platform failure.

Example investigation

A journey shows 10,000 entrances and 8,100 email sends.

1. Check profiles still in waits or in progress.
2. Compare branch counts; some paths may intentionally end.
3. Inspect channel eligibility, consent, suppression, and missing addresses.
4. Review frequency caps.
5. Inspect action errors and discard reasons.
6. Confirm report time windows and latency match.
7. Compare the correct journey version.

If 1,000 people are in a 24-hour wait and 700 followed a no-message path, most of the difference is explained before investigating technical failures.

Version and time discipline

New journey versions can overlap with old closed versions that still contain people. Filter or label reports by version when evaluating a change. Compare equivalent date ranges and account for seasonality and audience composition. A metric change after publication is not automatically caused by the version change.

Operational dashboard routine

• Check Live shortly after launch, allowing processing latency.
• Establish expected entry and action ranges.
• Alert on unusual errors and discards, not merely total volume.
• Review content and conversion metrics in All-time.
• Document retention and reporting windows.
• Export or analyze through approved tools when the UI horizon is insufficient.
• Avoid storing sensitive report extracts without governance.

Metric definitions

Write a short data dictionary for the launch: what counts as an entrance, action execution, send, delivery, display, click, conversion, error, and discard. Record the source report and latency for each. Without those definitions, two teams can quote different “conversion rates” from different denominators and both appear correct while diagnosing the wrong stage.