Deliver and maintain › Testing and Debugging
Adobe Experience Platform Debugger
On 22 May the payment step on the Kestrel and Co. website was tested. The call fired and the variable holding the payment method contained AUTH_CC_3DS.
That is a gateway code. The design asked for the payment method name, so that a report would show Visa, PayPal and Klarna rather than codes nobody outside the payments team can read. The fault was recorded that day against solution KES-S011.
Finding it took one thing that a raw request does not give you: knowing that this particular variable is Payment Method.
Row KES-S011 in the Tracker sheet carries this fault across all three cycles, and it is worth reading beside this section. If you have not downloaded the file, you can get it now or come back to it later.
Why the variable names matter
Here is part of that payment step call, exactly as it left the browser.
&v18=Next%20day&v19=AUTH_CC_3DS&v20=KES-88213&c4=checkout%3Apayment &events=scCheckout&pe=lnk_o&pev2=payment%20continue
The request carries slot numbers, not names. To know that v19 is wrong you have to know three things that are not in it. That v19 is eVar19. That eVar19 is Payment Method. And that the design asks for the name here rather than the code.
The Adobe Experience Platform Debugger supplies that missing half. It reads the same request and shows it with the names attached.
That matters during a test cycle. A raw request can only be read by somebody holding the variable map in their head or on a second screen. A named one can also be read by the analyst who asked for the variable, and by the client sitting beside you. The people most likely to notice that a payment method is wrong are the people who work with payment methods.
The Variable Map in the design document is the paper version of the same translation. Reading the two side by side is the quickest way to find a value that was implemented into the wrong slot.
What the extension is
It is a Chrome extension, installed from the Chrome Web Store. It examines a web page and reports on how the Adobe Experience Cloud products on it are implemented. It opens in its own window rather than inside the browser developer tools, and you attach it to a tab.
Once attached, it splits what it finds into one tab per product. Analytics is one. Beside it sit Experience Platform Web SDK, Target, Audience Manager, Experience Platform Tags, Experience Cloud ID, and Dynamic Tag Management for older sites. A Summary view says which of those are present on the page. A Logs view collects the messages the libraries produce.
Which rules fired, and which did not
The naming is useful. The Experience Platform Tags tab is the part nothing else can replace, because it shows the middle of the chain.
A value moves from a data layer object into a request in two steps. A data element reads the object, and a rule fires and maps it. Both steps happen inside the tag manager, in memory, in a few milliseconds. The request shows the result and says nothing about how it was produced.
The Tags tab shows which library is loaded, which environment it came from, and which rules ran on this page. Two faults from the Kestrel cycle show why that matters.
Solution KES-S003 was a product click on a listing page. On 22 May the direct call fired twice on every click, so product clicks were exactly double. The request looked correct both times. Only the list of rules that fired showed two rules responding to the same click.
Solution KES-S006 was a cart addition from the quick view overlay. The cart source arrived as Product Page rather than Quick View, so the two could not be told apart in reporting. Again the request was well formed. The rule that fired was the product page rule, not the quick view one, and that is visible in the Tags tab and nowhere else.
Run _satellite.setDebug(true) once in the console and the tag library starts reporting what it does: which rules fire, in what order, and what each one sets. The setting stays on for the rest of the browser session and applies to that one site, so it survives a checkout journey without following you elsewhere. Set it before you do the action. The messages describe events as they happen, and there is no way to ask for them afterward.
Post-processed hits, and what changed in 2026
For most of this tool's history there was a hard wall at the moment the request left the browser. Anything Adobe did after that was invisible from a page. That covers bot rules, processing rules and VISTA rules.
There is now a window in that wall. The Analytics section of the debugger has a toggle that switches the view between the hit as sent and the hit after Adobe's own rules have run.
The post processed hits toggle arrived in the Analytics section of the debugger in June 2026, and the current version is 1.7.1, released 24 June 2026. Tooling here changes faster than the product it inspects, so check the release notes before assuming a colleague's older install behaves like yours. An extension that has not updated is one of the more confusing differences between two people looking at the same page.
That toggle turns a whole class of investigation into one comparison. If a variable is correct in the sent hit and different in the post processed one, a rule inside Adobe changed it, and the search moves off the website. If it is wrong in both, it was wrong when it left.
Two limits go with it. The comparison covers rules that run at collection, not the visitor level work that happens later, so eVar persistence and attribution are still not shown. And it tells you that a rule changed something without telling you which rule, so you get a direction rather than a name.
What the debugger cannot show you
Three limits are worth planning around.
It only sees browsers it is installed in. That means your machine and your colleagues' machines. Faults that happen to real visitors and not to you are invisible to this tool. It is a Chrome extension, so a problem that only occurs in Safari is also out of reach.
Some views need you to be signed in. Reading non-public data through the extension requires an authenticated Experience Cloud session in an open browser tab. A debugger showing less than a colleague's is usually a logged out session rather than a difference in the page.
It runs inside the page it is watching. Version 1.7.1 exists partly to fix a defect where Analytics debugging could corrupt context data in Analytics requests. So when a hit looks wrong in a way that makes no sense, close the debugger, reload, and read the raw request in the network tab before believing it.
Reading a hit in the debugger
This is the routine for one row of a test cycle when you have the debugger available. The order is deliberate: it catches the expensive faults before you start reading individual variables.
- Part one, set up
- Install the extension from the Chrome Web Store, then sign in to Experience Cloud in another tab of the same browser. The sign in is not optional for the useful views. Non-public data needs an authenticated session in an open tab.
- Open the page you are testing, open the debugger, and lock it to that tab. Locking lets you walk a checkout without the debugger following you somewhere else halfway through.
-
Run
_satellite.setDebug(true)in the console before doing anything on the page. Before. The library reports as it goes and cannot be asked afterward what it did. - Part two, read the hit
- Do the action, then open the Analytics tab and read the report suite first. Always first. Every variable can be correct and land in a suite nobody reports on, and that looks exactly like no data at all.
- Check the hit type next: a page view, or a link with its own link name. A page view where a link was intended inflates page views everywhere, and no single variable will show it.
- Read the variables the design names for this moment, and check that the ones it does not name are absent. A variable arriving where the design does not ask for it is a real finding, and it is the one nobody looks for.
- Open the Experience Platform Tags tab and confirm which rules fired and which environment the library came from. Testing a staging fix against a production library wastes an afternoon and looks exactly like a fix that did not work.
- Part three, record it
- Switch the Analytics section to post processed hits and compare the two views of the same hit. Any variable that differs was changed by a rule inside Adobe. That comparison moves the search off the website.
- Write the finding into the solution row with today's date, naming the variable and the value you saw. Payment method arrives as the gateway code rather than the name is a finding. Payment method wrong is not, and cannot be retested.
- Set the status, and add an owner and a date if it is anything other than Passed. KES-S011 was Failed on 22 May, Partly passed on 29 May with one provider still wrong, and Passed on 4 June. Three lines, one row.
That is a hit read and recorded. Where a page carries Target or an identity service as well, give those tabs the same pass, because a fault in one product often looks like a fault in another.
What the debugger can prove
The fastest way to read an implementation, and the clearest view of the middle of the chain. Names on the variables, a list of the rules that fired, and a comparison across the boundary into Adobe.
Each of those advantages has the same limit. The debugger shows you a page as your own browser experienced it. Your browser is signed in, unblocked, running current Chrome with an extension installed, on a fast connection. It is not representative of the traffic a report is built from. The tool answers whether the implementation can work. It does not answer whether it does work for everybody.
The next tool needs no installation and is present in every browser, including ones you do not control. Browser Developer Tools covers how to find a hit, how to read one without help, and the test that separates a data layer fault from a rule fault.
Not inside Adobe Analytics. The debugger installs into Chrome from the Chrome Web Store and opens in its own window. The variables it names are configured back in the product, under Admin > Report Suites > Edit Settings > Conversion > Conversion Variables. Its useful views also need an Experience Cloud session open in another tab of the same browser.
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.