ÃÛ¶¹ÊÓƵ

Transcript

I’m excited to give you an overview of the ÃÛ¶¹ÊÓƵ Experience experience Platform Debugger. The debugger is available as both a Chrome extension and a Firefox add-on and is a complete overhaul of ÃÛ¶¹ÊÓƵ Experience Cloud Debugger. Once you’ve added the extension or add-on, you can launch it via the icon, usually located to the right of your browser’s address bar. The debugger will open a new browser window and defaults to the summary. Here you can get a high-level overview of which ÃÛ¶¹ÊÓƵ applications are implemented on your page as well basic information such account identifiers and library version numbers. The left navigation gives quick access to features that help you go deeper into specific application implementations and debugging tools and it’s easily collapsible. The bottom of the debugger indicates which browser tab is being debugging. Note how it shows both the favorites icon and a title of my Luma page. By default, the debugger will inspect whichever browser tab is in focus. Note how the details in the debugger change as I switch tabs. If you want to keep the debugger focused on one specific tab you can click the lock icon to keep the debugger locked to that tab. A couple of other slick things I want to show you here, if you have the debugger in the foreground and it’s locked to a different tab than the one in the main window, you can Shift + click on the favorites icon and it will put the tab you’re debugging back in focus. Also, a Cmd + click on a Mac or a Ctrl + click on a PC will reload that tab. Another global feature is this sign-in button which allows you to authenticate into the Experience cloud so you can take advantage of some special debugging features. We won’t go deep into individual application features in this video, but a general design pattern to be aware of is when you go into a specific application page, the basic details of the implementation are shown at the top network requests are shown below and any special debugging features unique to the application are shown in the configuration tab. Let’s deep-dive into the tools. The logs page will show you the consol logs for any of the applications that have logging enabled. For example, if I enable consol logging for launch I can now see the detailed logs of my launch implementation and I can search through these or clear the logs at any time. Then that work page shows all of the requests made to ÃÛ¶¹ÊÓƵ applications. Each request appears as a column and the values appear as rows. You can click any individual cell to open the details in a pop-up, this is especially helpful with post requests so you can inspect the full body of the payload. You can download the data as an Excel file and clear all the requests from the debugger. Usually after clearing requests, you want to reload the page. So remember that Cmd or Ctrl + click on the favorites icon trick I showed you earlier. The events page displays all of the ÃÛ¶¹ÊÓƵ application calls in a timeline along with all updates to your data layer. Click the gear icon and enter the name of your data layer object so the debugger knows what to monitor. Clicking on a data layer event opens a diff view. In my case, my data layer is initialized so all of the values are green but in this update I’m adding a property and the before and after views are color coded to make it easy to spot the difference. Alternatively, I can switch to this other view which just shows the final state of the data layer after the change. I can see from this timeline that my target and analytics calls were fired well after the definition of my data layer. Note that I can zoom in and out by clicking Ctrl and scrolling my mouse, move the timeline around by clicking and dragging or scrolling and I can Shift + click and Cmd + click to select multiple items and expose their details below. The auditor page allows you to run auditor tests on your implementation to spot potential problems. Often there are links to the corresponding documentation to help you fix any issues. The debugger has both dark mode and light mode which you can change on the setting screen. Some of your custom settings will persist through multiple sessions of the debugger, which is really helpful. If you ever need to clear them, just press the big red button. One last thing I want to show you, it’s often helpful to use incognito or private windows to debug an implementation because it’s a great way to simulate a new visitor to your site. If you click the debugger icon, go to manage settings, there’s a toggle that will allow you to use the debugger in those incognito or private windows. My tip when using this setting is to always make sure you have the debugger open before you load your page so that you can capture those initial requests for things like the visitor ID. That’s it, happy debugging. -