writeCapture overall reliability

[Matthew Cieplak]

Hello, 

We've recently had some issues with advertisers claiming underdelivery on certain campaigns we've scheduled for them, and have traced the issue back to an unreliability in some custom framebuster code we've written using writeCapture. Over the past several weeks I've conducted a number of tests to determine the reliability of various techniques for writing an <img> tag to a parent frame from within an iframe. I conducted this test across a random sampling of visitors to our site. Here are the results - each test included about 2500 users; margin of error is +/- 1%:

91% = Tags directly in frame (control)

91% = InnerHTML with string vars

89% = InnerHTML with textarea containing html string

67% = writeCapture with with string vars

67% = writeCapture with textarea containing html string

41% = writeCapture2 with textarea containing html string

I was unable to find any particular browser incompatibilities when testing across Chrome, Firefox, Safari, and IE7-9, and my exception tracking turned up no glaring errors, so at this point I am attributing these dropouts to "random failure" within the writecapture script. Given that innerHTML appears to extremely reliable, it seems sensible to switch to this approach, were it not for the fact that it would prohibit us from running remote script tags. I was hoping writeCapture2 would solve this issue but it only appears to have worsened it. 

Is there any known way to improve reliability for framebusting scripts when executing arbitrary javascript? Alternately, can anyone think of a test that would more conclusively determine the point-of-failure with writeCapture for remote logging? At this point I am considering abandoning the framebuster technique altogether in favor of a frame-resizing script that doesn't move any HTML around. 

Thanks for your insight.

[Sean Ford]

Why use frames at all? The beauty of writeCapture is that it allows you to asynchronously load an ad into your document while removing the danger of a doc.write statement overwriting the entire document. Using frames is just a different way of loading ads after your document is loaded, seems like your solving a problem that doesn't exist.

Something along the lines of:

$(document).ready(function() {
$("#ad_div").writeCapture().html(http://your.adserver.com/key=value;key=value?);
});

Instead of:
<iframe height=600 width=300 src=http://your.adserver.com/key=value;key=value></iframe>

Obviously your ad server would need to send back JavaScript ads, but we've had a lot of success using this method

Sean Ford

[Matthew Cieplak]

That's an interesting idea, and it may be the case that WC is more reliable when writing within the same frame. The innerHTML test suggests that it would not make a difference, but that may not be true.

The primary reason we are using iframe tags is that DFP has 2 modes - synchronous and asynchronous (iframe), and only the latter supports refreshing ad units. Our app is becoming more stateful and will soon require no page refreshes at all to navigate throughout. Additionally, people often remain on one page for a long time as they are streaming media from it. We use the ad refresh feature to generate new impressions when users interact with the application without a page reload.

As it stands, this reliability rate only affects our rich media ads that run in non-standard sizes. Given the numbers, I am afraid that if we began using WC/2 to write synchronous tags and perform "refreshes" by overriding document.writes then it will affect our entire inventory.

M

[Matthew Cieplak]

To clarify, by DFP I mean Google Doubliclick for Publishers, and their new Google Publisher tags:

http://doubleclickpublishers.blogspot.com/2011/10/introducing-next-generation-of-dfp-ad.html

[Sean Ford]

I wrote my own ad refresh function using writeCapture in conjunction with DFP adj JavaScript ad tags. All you really need to do is set a timer to loop over your document and reapply the ad request string to your ad divs with a new ord value.

Google's SRA ad methods are going to make writeCapture unnecessary for ad calls, and it forces iframes as well. I'm not a fan of SRA really, and we've had good luck with the existing ad architecture until we tried using Googles Adx network ads.

Sean Ford