When I started at Omni­ture nearly five years ago, one of the first basic tools I got to know was the JavaScript Debugger—you know, that book­marklet you install among your browser book­marks so that you can quickly and eas­ily see exactly what is being cap­tured in Site­Cat­a­lyst any web page. Over the years, I have moved on to more advanced (and com­plex) debug­ging tools, such as packet mon­i­tors and Google Chrome’s devel­oper con­sole. But when I just need to see the vari­ables and val­ues that a page is pass­ing into Site­Cat­a­lyst, I still click the lit­tle entry in my book­mark toolbar.

I am pleased to share with you the lat­est ver­sion of this nifty lit­tle util­ity: the Dig­i­talPulse Debug­ger. We’ve given it the name “Dig­i­talPulse Debug­ger” because it fits in nicely with Adobe Dig­i­talPulse, our implementation/site audit­ing prod­uct which will auto­mat­i­cally crawl your site and detect places where Site­Cat­a­lyst and/or Test&Target code has not been placed, or where it may have been placed with errors of var­i­ous kinds (vari­ables receiv­ing the wrong val­ues, vari­ables that are too long, image requests that are too long, etc.). It seemed like a nat­ural fit. We’ve also changed the loca­tion of the Debug­ger, which does mean that you’ll need to update your book­marklets. We did this for a few rea­sons, but most impor­tantly the new loca­tion allows the Dig­i­talPulse team to add amaz­ing new fea­tures much more quickly. We think you’ll agree that it’s worth updat­ing your book­marklets for that.

So, how do you install the Dig­i­talPulse Debug­ger? If you don’t already have the JavaScript Debug­ger installed, just cre­ate a sim­ple book­mark or favorite in your browser of choice (we’ve tested in IE, Fire­fox, Safari, and—your developer’s favorite—Chrome). Then, replace the URL of the book­mark with the fol­low­ing code (and make sure you get all of the code!):

javascript:void(window.open(%22%22,%22dp_debugger%22,%22width=600,height=600,location=0,menubar=0,status=1,toolbar=0,resizable=1,scrollbars=1%22).document.write(%22%3Cscript%20language=\%22JavaScript\%22%20id=dbg%20src=\%22https://www.adobetag.com/d1/digitalpulsedebugger/live/DPD.js\%22%3E%3C/%22+%22script%3E%22));

If you do have the Debug­ger already, just replace the URL with the code above. (You can also down­load the Debug­ger and addi­tional infor­ma­tion from Knowl­edge Base ID 534.)

Then just go to any page on your site that has been tagged Adobe Online Mar­ket­ing Suite code and click the book­mark. You should see a small pop-up win­dow look­ing some­thing like this:

DigitalPulse Debugger

You’ll notice that the Dig­i­talPulse Debug­ger still does every­thing you have come to expect from the JavaScript Debug­ger, but now offers some help­ful new features:

  • Reports on Test&Target, Rec­om­men­da­tions, and Sur­vey in addi­tion to Site­Cat­a­lyst data collection
  • Pro­vides the total length of the Site­Cat­a­lyst request on the page
  • Shows the “friendly names” for image request ele­ments (e.g. “eVar7” instead of “v7,” and “Cur­rent URL” instead of “g”)
  • Gives addi­tional request infor­ma­tion, such as whether the the imple­men­ta­tion uses first-party cookies
  • Allows you to change and save set­tings based on the prod­ucts and fea­tures you wish to use

One impor­tant thing to note is that, due to a change in data col­lec­tion code begin­ning with H.21, the old ver­sion of the Debug­ger may not cor­rectly decode multi-byte char­ac­ters in vari­able val­ues if your site is using this (or a newer) code ver­sion. The new Dig­i­talPulse Debug­ger does dis­play these vari­able val­ues cor­rectly for inter­na­tional char­ac­ter sets, so you can get a clearer sense of the data being col­lected from pages that use multi-byte characters.

The Dig­i­talPulse Debug­ger will refresh as you move from page to page, show­ing you the data col­lected across your entire site, but it still requires you to walk through your site man­u­ally. If you’d like a more pow­er­ful debug­ging tool that will scan your site for you, sav­ing you time and uncov­er­ing a wide vari­ety of poten­tial issues with your data before these issues rear their ugly heads, check out Adobe Dig­i­talPulse.

Huge shout-out to Adam Egbert of Adobe Con­sult­ing for his hard work on this project, as well as to every­one else who con­tributed to the improve­ment of this handy lit­tle tool.

(Note: The old JavaScript Debug­ger will con­tinue to be avail­able for your use indefinitely.)

As always, if you have any ques­tions about any­thing in this post, or about any­thing else related to the Adobe Online Mar­ket­ing Suite, please leave a com­ment here or con­tact me on Twit­ter and I’ll do my best to get you the infor­ma­tion that you need. In par­tic­u­lar, feel free to share feed­back about this new Dig­i­talPulse Debug­ger and we’ll do our best to imple­ment your requests in a future release!

21 comments
ClarrissaWhite
ClarrissaWhite

This suddenly stopped working for Chrome. Any ideas

lpena238
lpena238

Hi @Ben Gaines,
I am a bit confused by something you mentioned above. You mentioned that "DigitalPulse can crawl your site and search any URLs that are missing SiteCatalyst tags or that are mistagged". How can I get a hold of this crawler? Is it something different than DigitalPulse debuger?


Thanks!

John wills
John wills

DigitalPulse Debugger is very nice tool for dubugging javascript. It is great achivement in scripting dubuging. I am new learner of javascript so it is very beneficial for me.

Rajeev
Rajeev

I cannot see click events on digitalpulse debugger tool. Omnibug (firefox) shows these click events.

Mausam
Mausam

Nice post Ben. I have a doubt. The values shown in Digital Pulse Debugger are the values that has reached the SiteCatalyst server and is under processing or are they the values as sent from my site? Basically, i am looking for a way to confirm whether the values I am sending from my site are reaching SiteCatalyst server or not.

Simon Rumble
Simon Rumble

Love the new debugger but, unfortunately, it's unusable in Firefox. I've got some apps that _only_ work in Firefox too :( I've tried disabling extensions like Firebug and even with NO extensions, unusable. Completely locks up the browser every time it refreshes.

Dasha
Dasha

Is it me, or is it way slower than the old one? Although LOVE the new look!

Yuhui
Yuhui

Ben, try this in Firefox: 1. Load a page 2. Launch DigitalPulse Debugger 3. (optional) Open Windows Task Manager 4. In the debugger, uncheck the "Friendly Names" checkbox 5. Back in the debugger, check the "Friendly Names" checkbox 6. Scroll the debugger window --> Task Manager should now jump to 22% CPU utilization, Firefox stalls before scrolling the window 7. Repeat steps 4-6 a few more times to make Firefox absolutely unresponsive

Jason Paulsen
Jason Paulsen

Very nice! I'm glad I've got something for Chrome now.

Victor Forman
Victor Forman

Thanks for sharing this Ben. We've been using WASP, but this seems like a nice alternative (especially for those of us that like to use Chrome). I just tried it out in Chrome. It was working fine for a few pages and then seemed to stop auto-refreshing as I moved from page to page. Is this a known issue? Any thoughts?

Rudi
Rudi

Nice work. A huge improvement over the old debugger.

Henrik Schack
Henrik Schack

Looks really really nice :-) A few ideas: Warnings when vars are exceeding allowed length. Would be nice if I could "build" my own Company/RS specific debugger with my own friendly names for eVars/Props/events. /@schack

Yuhui
Yuhui

I don't know if it was the DigitalPulse Debugger or some other tab/page that was acting up, but when I repeatedly checked/unchecked "Friendly Names" about 3-4 times (to see how it toggles), suddenly Firefox (3.6, Windows) became unresponsive, eating up 25% of CPU (and growing). Had to force quit it to regain control.

davidsoncd
davidsoncd

same for me...just opens a about:blank screen

Ben Gaines
Ben Gaines

Simon, Interesting. I use the Debugger almost exclusively in Firefox with no issues. Have you tried it on other machines? I didn’t mention this in the blog post, but we beta-tested this thing heavily among our consultants worldwide, many of whom use Firefox. I’m not saying there isn’t an issue with the Debugger, but I think we can confidently conclude that it isn’t an across-the-board Firefox thing (i.e., it doesn’t affect every version of Firefox everywhere, on every computer). If it also isn’t working on other machines, let me know. I’ll pass this along to our developers, and they can look into performance in Firefox. Thanks, Ben

Ben Gaines
Ben Gaines

Me too! The old Debugger also worked in Chrome, I believe, but we're making an active effort to support this one across all major browsers and operating systems.

Ben Gaines
Ben Gaines

I'm very glad to hear that you like it, Victor. It has been a tremendous help to me when working in Chrome as well. I haven't seen the issue you described. . . does the same thing happen on any site or pages that you test?

Ben Gaines
Ben Gaines

A few—@alexbrasil comes to mind—have crafted their own debuggers. Using the Admin API to get variable names is definitely something we are considering for future development on the Debugger, as are enhancements like your idea to note the variable length. Maybe it's time to create an Idea Exchange category for the Debugger! For now you can list these things under DigitalPulse in the Idea Exchange, and I have also taken note of them.

Ben Gaines
Ben Gaines

Interesting. It seems to be working okay for me as I check and uncheck the boxes, but I'll keep an eye on it. I'm in OS X, so maybe I need to try the Windows version. Thanks for the error report!