Determine which advertisement made a request to /e

Question

I have a large website that is using two large online advertisement "Remnant" providers. These providers are such that they start and stop ad campaigns on a regular basis that run on our website.

One of the ads coming from one of the providers is incorrectly making a request to:

/eyeblaster/addineyev2.html

I have determined that the file being requested is used by some websites when the ads on the website are served via iframes. This file in theory would circumvent the cross domain restrictions so that the ad provider could resize the iframe using javascript within the iframe.

I determined this use of the file by stumbling upon this support document:

http://support.google.com/dfp_premium/bin/answer.py?hl=en&answer=1085693

My problem is that our websites do not use iframes to deliver advertisements, so the requests going to the "/eyeblaster/addineyev2.html" URI results in a 404 error, and is unnecessary. Because the error is coming from a large vendor-provided CMS the error renders with our Google Analytics tracking code on it. This has the result of inflating our apparent pageviews.

The pageview inflation can be very severe, because the 404 error page also contains ads. That 404 page could also load the faulty ad, resulting in a recursive loop of ads loading the exact same "/eyeblaster/addineyev2.html" 404 page.

I have thus far been unable to witness an ad making a direct request to this url via Firebug or similar developer tools. Yet, the traffic to this non-existent page is gigantic so the offending ad is certainly still in the mix. The problem is that I cannot figure out which ad is broken, so I can't tell our remnant providers to remove it. Both vendors are feigning ignorance of the issue.

I cannot remove the Google tracking code on the 404 error page, but I can add additional JavaScript to the page.

Is there any way that I could identify the ad causing a request to "/eyeblaster/addineyev2.html" by adding some javascript to the 404 error that results when trying to request that page inside an iframe?

Essentially almost a "frame buster" script that instead of busting the frame, gives information on the HTML nodes nearby the iframe element? I think it's mildly possible, but I'm not seeing a clear path at the moment.

Thanks!

Answer 1

I have found my own answer, and I'll share it here for the rare event another Web Developer is trying in vain to pinpoint an ad doing this same thing to them.

The offending digital ad was coming in with an iframe that was pointed toward "/eyeblaster/addineyev2.html" I used this knowledge, and coded the following javascript to gather information about the page that contained the iframe (ie the page with the ad on it).

if(top != self) {
    $.post("/ad_diagnose/log.php", {
        a: $('#ad-div-one', top.document).html(),
        b: $('#ad-div-two', top.document).html(),
        c: $('#ad-div-three', top.document).html(),
        d: $('#ad-div-four', top.document).html(),
        e: $('#ad-div-five', top.document).html(),
    });
}

This JavaScript uses JQuery (which our CMS provider includes on every page anyway). It checks to see if the error page exists in an iframe (top != self), and then it grabs the raw html for every html element on the parent page that should contain an ad.

That data is wrapped into an object, and posted to a simple php script that would write a log of every value posted to it to a file.

In the end, I received a log file with a high likelihood that the offending ad code was within. I was able to do a quick grep on the file and discovered the ad with an iframe pointing toward "/eyeblaster/addineyev2.html"

I hope this helps someone else out there!

Answer 2

Just thought I would share that this is happening over at our Ozzu website as well. I was first aware of the issue when some of our members were complaining, but I didn't look too deeply as I first thought it was an isolated instance.

Over the past month I have also noticed that my error log files on the server have been higher than normal pushing the /usr partition to around 82% of its usage. I didn't put two and two together until today as I finally started looking through the errors and it appears that this is not an isolated instance with this eyeblaster type ads. There are many thousands of users coming to our site and then getting redirected to a 404 page on our website because of this. Here is a sample of one of the errors in our log file, and it appears that numerous networks are using this eyeblaster software from Media Mind:

[Thu Dec 13 16:36:51 2012] [error] [client 123.123.123.123] File does not exist: /public_html/eyeblaster, referer: http://lax1.ib.adnxs.com/if?enc=AAAAAAAAAAAAAAAAAAAAAAAAAGC4Hvs_AAAAAAAAAAAAAAAAAAAAAMqchzp-qp9L_vlliXOoLV2gdMpQAAAAAEMUDABGAQAAQAEAAAIAAADXo0AA-FcCAAAAAQBVU0QAVVNEAKAAWAIAeAAAYk4AAgMCAQUAAIIA5BXJnQAAAAA.&cnd=%21QxtEWwidpzIQ18eCAhgAIPivCTAEOIDwBUABSMACUMOoMFgAYL4FaABwKngAgAH6AYgBAJABAZgBAaABAqgBALABALkBAAAAAAAAAADBAQAAAAAAAAAAyQEgEFk1j_LCP9kBAAAAAAAA8D_gAQA.&udj=uf%28%27a%27%2C+15986%2C+1355445408%29%3Buf%28%27c%27%2C+824221%2C+1355445408%29%3Buf%28%27r%27%2C+4236247%2C+1355445408%29%3B&ccd=%21mgWjMAidpzIQ18eCAhj4rwkgAQ..&vpid=18&referrer=http%3A%2F%2Fwww.ozzu.com%2F&dlo=1
[Thu Dec 13 16:36:56 2012] [error] [client 123.123.123.123] File does not exist: /public_html/eyeblaster

I have just contacted the Media Mind company as well to see if they have any further input. The errors in our logs are at least coming from a few ad servers such as:

lax1.ib.adnxs.com
showads.pubmatic.com
ad.yieldmanager.com

So it is my impression that numerous Media companies are using this Eye Blaster software. I looked more into what Eye Blaster supposedly does, and it is some sort of technology that syncs numerous ads on the page as if they are one big ad. For instance an animation will start in one ad and end in another. Anyway it must be popular as numerous ad companies seem to be using it and as such I would probably have to disabled alot of advertisers.

I think the best way to fix the problem would be to have Media Mind address it, but I am not sure.

Anyway just wanted to share my experience and that this problem seems to be affecting numerous websites.

Answer 3

To avoid that unwanted tracking you should place a dummy empty file on /eyeblaster/addineyev2.html, or, if you use nginx do something like

server {
  ...

  location = /eyeblaster/addineyeV2.html { echo ""; }
}

or, better

server {
  ...

  location = /eyeblaster/addineyeV2.html { return 404 "404 - page not found";}
}

If you don`t have static hosting and cannot configure a proxy server you can put a condition in your 404 page tracking via javascript

if (document.URL.indexOf('/eyeblaster/addineyeV2.html') == -1) {
   doAnalyticsTracking();
}

Answer 4

It looks like there are more publishers having this issue. I do too. Following Tals instructions I was able to log information when pointing an iframe to a 404-page on purpose, but wasn't able to catch this problem as it appears randomly and I can't check why the script is not catching it.

How about adding /eyeblaster/addineyev2.html and log from this file?

I was able to determine the owner of the script doing a simple web search. It is coming from http://www.mediamind.com/ But disabling "mediamind" in Google AdSense doesn't do the trick, so I asked their support to send me the file.

I am going to test the script and if 404-calls are getting lower. Maybe I will also use the script to check for the content being loaded and determine the exect ad url to shut it down.