Troubleshoot with the Experience Cloud Debugger

Hi, I want to show you all of the Target features in the Adobe Experience Cloud Debugger. Here’s a page where I have Target implemented. I’ll go ahead and launch the Debugger Chrome extension. The summary tab will detect the presence of the Target implementation and show some basic info about the library. The client code is Target’s account identifier, yours will probably be your company’s name. If you open a ticket with Customer Care, they’ll probably ask you for your client code, so it’s handy to know that you can get this here on this summary tab, also I can see which library and version I’m using. ATJS1.5 Finally, I can see that the name of my global MBox is Target global MBox. This doesn’t mean that my global MBox just fired, although it did. This just indicates that my library is configured to use this name. Next, I want to show you Target in the network tab. On my page, two Target requests fired. I have a global request named Target global MBox, and a wrapping request named “wrappingMBoxExample”. The network tab is useful if you’re using Target, in addition to other Experience Cloud solutions. I can confirm the order of my calls in relation to the analytics request. And I can confirm that my Experience Cloud visitor ID and supplemental data IDs match what’s being passed to analytics. This is really critical for Experience Cloud integrations like shared audiences, and A for T. One thing that the network tab doesn’t show at the moment though, are your custom parameters, or profile parameters. Which are obviously very important, so I encourage you to use the Target tab to see these values. Here on the Target tab, the requests are grouped by client code. When I expand the client code, you’ll see the requests and parameters organized similar to the network tab, but all of them custom parameters will be visible at the bottom. So this is a great place to make sure your Target implementation is firing requests with the expected parameters. Let’s look at the Target tools in the tools tab. The two I’m going to show you both require ATJS096 or above. They’re all toggles that are easy to turn off and on. Target console login will expose Target’s logs to your browser. At the moment, these don’t show up in the logs tab of the Debugger, so you’ll need to open up your developer toolbar and look at the console. The Target logs statements all begin with AT: so they’re easy to filter. In my page, you can see that one of my actions in my activity wasn’t applied correctly. This is because one of the elements I’ve modified in the visual experience composer, was removed from the page. Also, I see that I have an error in one of my custom code offers, instead of typing console.log, I typed console.loog. So, if your activity was delivered, but you’re not seeing the expected results. Turn on console logging and check those console statements for clues as to what’s going wrong. Another handy tool is disable Target, this basically stops ATJS from making any calls, you’ll see a message like this in your console logs when its been disabled. And you won’t see any new Target requests being made. Use this to confirm the default experience of your website. It’s also handy for diagnosing Java script errors and determining whether or not they’re related to any of your Target activities. Basically, if you disable Target and the Java script error is still there, then it’s probably unrelated to your Target activities. MBox highlight is a tool for older implementations that’s still use what are called wrapping, or regional MBoxes. I don’t recommend that you implement these, but some customers still have them so I have included one on this page to demonstrate how this tool will draw a red box around the wrapping MBox. So you know where it is. The last tool I wanna show you is the crown jewel of Target Debugging, MBox trace. But there’s a lot to show you so I’m gonna do that in a separate video. Thanks for watching, I’m Daniel Wright, technical marketing engineer.