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!

  • http://yuhuibc.blogspot.com Yuhui

    I don’t know if it was the Dig­i­talPulse Debug­ger or some other tab/page that was act­ing up, but when I repeat­edly checked/unchecked “Friendly Names” about 3–4 times (to see how it tog­gles), sud­denly Fire­fox (3.6, Win­dows) became unre­spon­sive, eat­ing up 25% of CPU (and grow­ing). Had to force quit it to regain control.

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Inter­est­ing. It seems to be work­ing 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 Win­dows ver­sion. Thanks for the error report!

  • Hen­rik Schack

    Looks really really nice :-)

    A few ideas:
    Warn­ings when vars are exceed­ing allowed length.

    Would be nice if I could “build” my own Company/RS spe­cific debug­ger with my own friendly names for eVars/Props/events.

    /@schack

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      A few—@alexbrasil comes to mind—have crafted their own debug­gers. Using the Admin API to get vari­able names is def­i­nitely some­thing we are con­sid­er­ing for future devel­op­ment on the Debug­ger, as are enhance­ments like your idea to note the vari­able length. Maybe it’s time to cre­ate an Idea Exchange cat­e­gory for the Debug­ger! For now you can list these things under Dig­i­talPulse in the Idea Exchange, and I have also taken note of them.

  • http://www.rudishumpert.com Rudi

    Nice work. A huge improve­ment over the old debugger.

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Agreed! Thanks, Rudi.

  • Vic­tor Forman

    Thanks for shar­ing this Ben. We’ve been using WASP, but this seems like a nice alter­na­tive (espe­cially for those of us that like to use Chrome). I just tried it out in Chrome. It was work­ing 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?

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      I’m very glad to hear that you like it, Vic­tor. It has been a tremen­dous help to me when work­ing in Chrome as well. I haven’t seen the issue you described… does the same thing hap­pen on any site or pages that you test?

  • Jason Paulsen

    Very nice! I’m glad I’ve got some­thing for Chrome now.

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Me too! The old Debug­ger also worked in Chrome, I believe, but we’re mak­ing an active effort to sup­port this one across all major browsers and oper­at­ing systems.

  • http://yuhuibc.blogspot.com Yuhui

    Ben, try this in Fire­fox:
    1. Load a page
    2. Launch Dig­i­talPulse Debug­ger
    3. (optional) Open Win­dows Task Man­ager
    4. In the debug­ger, uncheck the “Friendly Names” check­box
    5. Back in the debug­ger, check the “Friendly Names” check­box
    6. Scroll the debug­ger win­dow –> Task Man­ager should now jump to 22% CPU uti­liza­tion, Fire­fox stalls before scrolling the win­dow
    7. Repeat steps 4–6 a few more times to make Fire­fox absolutely unresponsive

  • Dasha

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

  • http://www.rumble.net/ Simon Rum­ble

    Love the new debug­ger but, unfor­tu­nately, it’s unus­able in Fire­fox. I’ve got some apps that _only_ work in Fire­fox too :(

    I’ve tried dis­abling exten­sions like Fire­bug and even with NO exten­sions, unus­able. Com­pletely locks up the browser every time it refreshes.

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Simon,

      Inter­est­ing. I use the Debug­ger almost exclu­sively in Fire­fox with no issues. Have you tried it on other machines? I didn’t men­tion this in the blog post, but we beta-tested this thing heav­ily among our con­sul­tants world­wide, many of whom use Fire­fox. I’m not say­ing there isn’t an issue with the Debug­ger, but I think we can con­fi­dently con­clude that it isn’t an across-the-board Fire­fox thing (i.e., it doesn’t affect every ver­sion of Fire­fox every­where, on every com­puter). If it also isn’t work­ing on other machines, let me know. I’ll pass this along to our devel­op­ers, and they can look into per­for­mance in Firefox.

      Thanks,
      Ben

  • Mausam

    Nice post Ben.
    I have a doubt. The val­ues shown in Dig­i­tal Pulse Debug­ger are the val­ues that has reached the Site­Cat­a­lyst server and is under pro­cess­ing or are they the val­ues as sent from my site?
    Basi­cally, i am look­ing for a way to con­firm whether the val­ues I am send­ing from my site are reach­ing Site­Cat­a­lyst server or not.

  • Rajeev

    I can­not see click events on dig­i­talpulse debug­ger tool.
    Omnibug (fire­fox) shows these click events.

  • http://www.findbankonline.com John wills

    Dig­i­talPulse Debug­ger is very nice tool for dubug­ging javascript. It is great achive­ment in script­ing dubug­ing. I am new learner of javascript so it is very ben­e­fi­cial for me.

  • http://consideringselfemployment.blogspot.com/feeds/8386034538783633330/comments/default con­sid­er­ing self employment

    Good post , I respect a great site like this one. Keep up the good work..