Webenize

Debugging Tools at the Zone Level

There are some advantages to not running your ad server’s zone calls directly on the page but creating a wrapper for your own ad calls. By creating your own zone wrappers you are creating a gate way onto the page that are running those calls therefore you are creating a way for you to streamline executions in the future.

You can update these ad calls in one fell swoop across the network as well as create a set of tools for debugging. Some interesting quick wins for passing different style flags into the zones for different style functionality:

-       ?display=visual – This query_string command invokes overlays on the zones with their Zone ID, Zone Size. If an overlay is too much for a quick win perform a document.write of the zone calls.  Business Reason – Provides the ability to quickly see who is running our zones on the page.  There is no need for Firebug that only works on some browsers.

-       ?pid_override=3020 – Forces the placement_id 3020 into the zone and potentially skips the ad server entirely.  This is a quick test to see how an ad unit fits within a sites template. Business Reason – Ability to test new ad sizes in their templates on a live site.

-       ?zone_find=3000&fm_zone_replace=3020 – Allows you to find an the zone and replace it with another.  Business Reason – Simple search and replace to test new ad units being trafficked to a test zone.

-       ?ad_monitor=true&runtime=10 – Writes a log file out to monitor all the ads that runs through it for a set time period.  Business Reason – Very helpful for debugging what some authors may be seeing – should also write out browser information and location.  Would prevent a user from constantly having to hit refresh.

-       ?ad_monitor=true&pid=1234&alert=Michael@Bendell.com&screenshot=1 – Writes a log file out to monitor looking for a particular ad, in this case one with a placement_id of 1234.  If it finds it an alert will be sent to an email address and ideally with an attachment of a screenshot.  A timeout can be created if needed.. Business Reason – We spend an awful lot of time waiting for an ad to show up.  This would deliver to us what we are looking for instantly.

So DFA seems to choke on the “#” sign for certain browsers Safari & IE.  See the note below from Google they are aware of the issue but do not look out for it.

“The # sign issue isn’t something that comes up as a result of Studio -
it’s a DFA limitation, so it’s tough to catch in Studio or in our QA since
the units work as expected in Studio when we QA. It’s not something that
we’d be able to see until after units are trafficked in DFA.

When this has come up with clients in the past, it’s an easy fix because
most URLs are updatable in DFA or pulled in from a feed. In this case,
part of the URL was static in the Flash and that piece happened to have a
# sign, which is why you were seeing an issue and why it had to be
rectified via a revision.

It’s something I look for when you send me static click through URLs, and
I usually tell XXXX or XXXX to replace the URL including the # with a short
URL, but this would not have been easy for us to catch given how it was
set up. …..”