Deliver and maintain › Testing and Debugging
Real-Time Validation
Every check you can make in a browser stops at the same moment: when the request leaves. What Adobe does with it after that is invisible from the page.
Real-time reporting is the quickest way to see the other side. It shows data within about two minutes of collection, which is fast enough to deploy a fix and confirm it in the same sitting.
It is also small, specific, and it will not show you the variable type most implementations care about most. This section covers what it does, what it refuses, and how to plan a test cycle around the wait.
What happens after the request leaves
Once a hit crosses into Adobe, several things run over it in a fixed order.
Bot rules can discard it. Processing rules and VISTA rules can change any variable on it. Marketing channel rules decide which source gets credited. Event deduplication can drop a purchase whose identifier another hit already used. eVar persistence decides how long a value keeps being credited to later hits.
All of that is configuration somebody chose, and none of it reports back to the browser. So a clean network capture proves the implementation on the page did its job, and nothing more.
Real-Time reporting survived, and it moved
Reports & Analytics, the green interface most of this product's history was spent in, stopped working on 17 January 2024. Many people assume the Real-Time report went with it.
It did not. It still runs at the same speed, and it now sits inside Analysis Workspace as a template.
It has to be switched on per report suite in Admin first, and that is the step people miss. A template that has never been configured shows nothing at all, which looks the same as a template that is broken.
Real time reporting is configured at Admin > Report Suites > Edit Settings > Real-Time and read at Workspace > Templates > Adobe templates > Engagement > Real-Time. Configuring or viewing it needs an administrator, or membership of the All Report Access and Advanced Reporting groups. After you enable it, allow up to twenty minutes before data starts arriving. Menu paths in Workspace move more often than product capabilities do, so check the location before deciding the feature has gone.
What it can and cannot do
It is deliberately small. Knowing its shape before you plan a cycle stops it being a disappointment.
| Constraint | The number | What it means for testing |
|---|---|---|
| Reports per suite | Three | You choose in advance what to watch, and changing it is an admin action |
| Shape of each report | One site wide metric, three dimensions | One primary and two secondary, with no dimension repeated in a report |
| Latency | Under two minutes | Fast enough to deploy a fix and retest in one sitting |
| Refresh | Every minute, automatically | You watch it rather than reloading it |
| History held | Two hours | Finest detail for the first thirty minutes, coarser after that |
| Time to start | Up to twenty minutes after enabling | Enable it the day before the cycle, not on the morning of it |
| eVars | Not supported | The variable type most implementations care about most is absent |
Why eVars are not available
The reason is in the drawing above, and it follows from where the feed is taken.
A hit is processed in stages. The early stages need only the hit itself: whether it came from a bot, what the processing rules say, which channel the referrer implies. The later stages need context the hit does not carry, because they depend on the other hits that visitor has made. Whether this is visit four. Whether a purchase identifier has been seen before. And what an eVar should be credited with, which depends on values set on earlier hits.
Real time reporting takes its feed from the early stages, which is exactly why it is fast. An eVar has no value at that point, because persistence has not happened yet. The speed and the absence are the same fact.
Sometimes a value has to be confirmed inside the session rather than an hour later. Put a prop carrying the same value alongside the eVar for the duration of the build. Props are available to real time reporting because they are decided at the hit and never persist, which is the same property that makes them useless for attribution. Many implementations already carry this pairing for other reasons. Where one exists it turns an hour of waiting into ninety seconds, and where one does not, adding a temporary prop is cheaper than it sounds.
What to watch, and what to wait for
Decide this before the cycle rather than during it.
Watch in real time the things decided at the hit. Whether traffic is arriving at all, page names, site sections, props, and events firing. That covers most of what goes wrong in the first hour, and a fix can be deployed and confirmed while everybody is still in the room.
Wait for the report for everything decided later. eVars and their persistence, attribution, visit level channel credit, and anything involving deduplication.
Configuration items belong in that second group too, and they catch people out. A marketing channel rule, a processing rule that buckets a value, a classification upload: none of these can be checked until data has been through the full run. They are usually tested a cycle later than the tracking calls, and a plan that assumes otherwise will show them as failures on the first pass.
Classifications sit outside both. They are applied on top of stored data rather than being a step in this pipeline, so an unclassified value in either view is correct until the file is uploaded.
Planning the wait into the cycle
The commonest way a test cycle overruns is treating processing time as an annoyance instead of a fixed cost to be scheduled.
Complete data appears in reports around two hours after collection. The usual range is thirty to ninety minutes, depending on where the traffic falls relative to the hourly batch. An Analytics for Target integration adds five to ten minutes across the board, and hits carrying custom timestamps follow their own schedule.
Run that against a working day and the shape is clear. Testing done in the morning can be confirmed before lunch. Testing done at half past four is confirmed tomorrow. Cycles roughly a week apart give room to test, fix, and confirm the fix in reporting before the next one starts.
A development report suite costs nothing to create and removes any worry about polluting production figures during a build. It also lets you do the things that are useful and destructive at once. Firing calls from the console, repeating the same purchase twenty times, and leaving obviously fake values in variables so they are easy to find. Give it a name nobody could mistake for the real one. Then check the report suite in the first line of every hit you read. A development suite that quietly stops being used is how test data reaches a month end figure.
Confirming that a value survived
This closes the loop the browser cannot close. It is the step most often skipped, because the hit already looked right.
- Part one, the day before
- Enable real time reporting on the test suite at Admin > Report Suites > Edit Settings > Real-Time. The day before, because data can take twenty minutes to start and a blank report on the morning of a cycle looks like a fault.
- Configure the three reports around what you are testing, not around what is interesting. One metric and three dimensions each. Page and site section for a navigation build, an event and a prop for a checkout build.
- Part two, in the session
- Do the action, confirm the hit in the network tab, then open Workspace > Templates > Adobe templates > Engagement > Real-Time. Both, in that order. The hit tells you what was sent, the report tells you what was kept.
- Watch for your value for a few minutes before deciding anything. Under two minutes is normal. Concluding at forty seconds that a value did not arrive creates a false finding and a wasted investigation.
- If traffic is arriving but your value is absent, check whether it is an eVar before anything else. An eVar will never appear here. That is the design, and hunting for a fault will cost an hour and find nothing.
- Part three, the slow half
- List the solutions that cannot be confirmed in real time and schedule them for the next morning. Written down, not held in anybody's head. These are the ones that get forgotten and signed off untested.
- The next day, open the same values in Workspace and compare them against the hits you captured. A value correct in the hit and wrong here was changed inside Adobe, which points at processing rules, VISTA or deduplication rather than the site.
- Write both halves into the solution row, with their dates, then set the status. Sent correctly on one date, confirmed in reporting on the next, is a complete finding. Either half on its own is an assumption.
That is a round trip proven rather than assumed. For anything that affects revenue, run the same comparison once more a week after go live on production traffic, because that is where bot filtering and consent start to show.
What the round trip proves
A hit that left correctly and a value that arrived correctly are two different claims. Only the second is what a report is built from.
Real time reporting closes part of that gap in under two minutes, for values decided at the hit. Everything decided later needs the wait, and the wait is thirty to ninety minutes whatever anybody would prefer.
Both halves belong in the record. A finding that says only the hit was correct is worth having and it is not a pass. The most awkward conversation in this work is about a solution that passed testing and is wrong in production, and the only defense is having checked the far side.
The tools are now covered and the method is in place. What remains is what experience supplies: knowing what a symptom usually means before you start investigating. Common Issues and Solutions covers the faults that recur, what each looks like from a report, and the two that remove data so quietly nobody notices for a quarter.
Two screens, and both are needed. Configure at Admin > Report Suites, select the suite, then Edit Settings > Real-Time, where you set one metric and three dimensions for each of up to three reports. Read at Workspace > Templates > Adobe templates > Engagement > Real-Time. Both need an administrator, or the All Report Access and Advanced Reporting permission groups.
This article focuses on the concepts, architecture, and practical guidance behind the topic. For the latest UI walkthroughs and step-by-step implementation instructions, use the links below. They leave this site and open Adobe's own documentation in a new tab.