Deliver and maintain › Testing and Debugging
Debugging Tools Overview
On 22 May the first test cycle on the Kestrel and Co. website reached the product pages. The page name was empty on every one of them.
Nothing had failed. The pages loaded normally, the tracking call fired, and Adobe accepted it. The page name was missing because the site set it in a script that ran after the call had already gone.
That cycle tested twenty eight solutions and found something wrong with twenty six of them. Two were correct first time. This is what a first test cycle normally looks like, and this module is about how you find those twenty six and prove you have fixed them.
The company and the documents used here
Kestrel and Co. is a fictional online homeware retailer. Furniture, kitchen, bedding, twelve showrooms, and a trade account scheme for interior designers. The company does not exist and the project never happened, but the requirements are ones businesses ask for and the faults are ones that occur.
Its implementation was designed in a set of five documents, covered in Solution Design Reference. One of the five is the validation report, and that document is what this module fills in. Every fault above was recorded in it, against the solution it belonged to, on the date it was found.
The validation report is the document this module works in, so it is worth having open beside you. It is filled in with a finished Kestrel test cycle: twenty eight rows, three dated cycles and four statuses. If you cannot download it now, the sections still read on their own, and you can come back to this page later and follow along then. The other four documents are here because the validation report refers to them.
What testing an implementation means
Testing is not browsing the site and looking for problems. It is working down a list of solutions and checking each one.
The list comes from the design document. Each row is one solution with an identifier, such as KES-S004 for a product detail page view, and a sentence saying what it is supposed to do. You exercise that solution on the site, read what the tracking call actually carried, and write down what you found.
Testing against a list matters for one reason. It makes coverage countable. Every solution in the design either appears in the validation report with a status, or it is missing, and missing is visible. Browsing the site and looking for problems gives you no way to know what you did not check.
The five stages a value travels
A value that reaches a report has been through five stages. Any of them can drop it.
The value starts as something the website knows, such as the delivery option a customer picked, held in a data layer object. A rule in the tag manager reads that object and puts it into a variable. The library builds a request and sends it to Adobe. Adobe processes what arrives, running bot rules, processing rules, VISTA rules and marketing channel rules in a fixed order. What survives all of that appears in a report, usually an hour or two later.
The product page fault above sat at stage one. The site had not put the page name into the data layer by the time the rule read it. A rule that reads an empty object and a rule that never ran produce the same result in the report, so the stages are what tell them apart.
Which tool sees which stage
Four tools cover the five stages. What matters about each is what it can prove.
| Tool | Proves | Cannot tell you |
|---|---|---|
| Browser developer tools | Exactly what left the browser, and whether it left at all | What any of it means, or what Adobe did with it |
| Experience Platform Debugger | Which rules fired, which data elements resolved, and what each variable is called | Anything on a browser it is not installed in, which includes every customer's |
| Analysis Workspace, including real time reporting | What Adobe kept, after all its own rules have run | Why something is missing, or which stage lost it |
| Experience Platform Assurance | The same for a mobile app, over a session paired by PIN | Anything happening in a web browser |
The first two tools show the same event from different sides. Developer tools give you the facts without the names. The debugger gives you the names, but only works on a machine you control. Most debugging moves between those two views, and the third tool settles whether anything survived.
Start at the request
Look at what left the browser first, before forming any theory about what is wrong. Not the data layer, not the rule, and not the report.
The request is the only stage that is a fact. Everything before it is intention: a data layer that should have been populated, a rule that should have fired, a mapping somebody wrote in a document. Everything after it happens inside Adobe, where you cannot watch.
Starting there also halves the search in one step. If the value is in the request but wrong in the report, the fault is inside Adobe and reading the site will not find it. If the value is missing from the request, nothing Adobe does can put it back, and the report is a distraction.
Follow that order for your first cases. After a dozen of them you will start recognizing faults by their symptoms and jumping straight to the likely stage, which is quicker and occasionally wrong. The order is what you go back to when the shortcut fails.
The first instinct on being handed a problem is to reason about it, and reasoning produces four possible causes and no answer. Go to the page, do the thing, and look at the request. A fault you can reproduce on demand is usually solved within the hour, because each theory can now be tested in thirty seconds. A fault you cannot reproduce is a much harder job, and it is worth finding out which of the two you have before you start.
Three questions, in this order
Once the request is on screen, three questions cover almost everything.
Did the call fire at all? If there is no request, nothing after it matters. The rule did not trigger, the library did not load, consent blocked it, or a browser extension stopped it. Settle this before anything else.
Did it carry the right values? The call fired, and a variable is empty, or holds a code where a name was expected. Now you need to know where the value should have come from, and whether the site failed to provide it or the rule failed to read it.
Did Adobe keep it? The call fired, the values were right, and the report is still wrong. Something between collection and reporting removed it or changed it. The list of things that can do that is short.
The first two are answered in the browser, in Browser Developer Tools and the Adobe Experience Platform Debugger. The third cannot be answered there at all, and is covered in Real-Time Validation.
Where the finding gets written
Every answer goes into the validation report, in the row for that solution. Four things go with it.
| Column | What you write | Example from the Kestrel cycle |
|---|---|---|
| Status | Passed, Partly passed, Failed or Ignored, as at the latest cycle | KES-S013 payment failure is Partly passed |
| Findings by cycle | The date, then what you observed. Add to the cell, never overwrite it | 22 May: Payment method arrives as the gateway code rather than the name. |
| Action on | Who does the next thing, on every row that is not Passed | Kestrel web dev |
| ETA | A date, on every row that is not Passed | 19 Jun |
Write what you observed rather than what you concluded. "Quantity was 2 when one product was added" stays true even if your diagnosis turns out to be wrong. "Quantity is broken" does not help anybody and cannot be retested.
Testing works down a list and records what happened, whether or not anything turns out to be wrong. Debugging starts from one symptom and works backward to a cause. A project needs both, at different times. Testing is planned into cycles against a signed design, which is covered in Validation and Sign-off. Debugging happens whenever somebody reports a number they do not believe. The tools are the same and the approach is not, and running a debugging session as though it were a test cycle is how one fault takes a week.
Testing one solution, end to end
This is one row of a test cycle. Run it on KES-S004, the product detail page view, using the validation report as your record.
- Open the validation report at the Tracker sheet and find the row you are testing. Read the requirement sentence beside it. The requirement tells you what to check. Testing without reading it is how somebody confirms the call fired and misses that it carried the wrong value.
- Open the network tab, switch on Preserve log, then do the action on the site. Preserve log first. A checkout that navigates will clear the request you needed, and you will walk the journey again to get it back.
- Read the request. Check the report suite, then the hit type, then the variables the design names for that moment. In that order. A perfect set of variables landing in the wrong report suite looks exactly like no data at all.
- If a value is missing, open the console and read the data layer object it should have come from. This one check decides everything. A populated data layer with an empty request means the rule. An empty data layer means the site.
- Write the finding into the row, starting with today's date, below anything already there. Below, not over. Three dated lines show whether a fix worked or moved the problem, and one line cannot.
- Set the status. If it is not Passed, fill in Action on and ETA before you move to the next row. Before, not at the end of the day. An owner assigned in a review meeting is an owner chosen by whoever stayed quiet.
That is one solution tested and recorded. Repeat it down the sheet and you have a cycle. Go further where the case needs it. A solution that fails for only some visitors wants a second run, on a different browser or a slower connection, before you write it down as passed.
What you have now
A way of working that does not depend on any particular tool. A value travels five stages, no tool sees all five, the request is the only fact, and three questions tell you which stage to investigate. Each answer goes into a row with a date, a status and an owner.
The tools change. The bookmarklet everybody used ten years ago is no longer maintained, and the extension that replaced it gained a new capability in 2026. The five stages have not moved, and somebody who understands them can pick up whatever tool exists in five years.
The next tool turns a request full of numbered parameters into names you recognize, and shows which rules fired. Adobe Experience Platform Debugger covers what it reads, what it cannot see, and one setting that changes what it can prove.
Mostly outside the product. The debugger is a Chrome extension, the network tab belongs to the browser, and Assurance is reached at assurance.adobe.com with a session paired to a running app. Only the reporting end is inside Adobe Analytics, under Workspace, with real time reporting switched on per suite from Admin > Report Suites > Edit Settings > Real-Time.
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.