Determine which advertisement made a request to /eyeblaster/addineyev2.html

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!

Instead of building a workaround, you should contact the provider and ask them to fix their creative. — Daniel W., Nov 09 '15 at 11:09

score 10 · Answer 1 · answered Nov 20 '12 at 14:42

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!

So you found the ad, but how does this solve the problem? Won't you have the problem over and over in the future? Isn't it more harmful to write all this data whenever the problem occurs rather than just return a 404 for it? — Julian, May 14 '13 at 18:11
@Julian, the code is not continually running on our live website. Once the offending ad was removed from rotation there was no further need or desire to collect the data. You are coming from a viewpoint of the developer having complete control over the running web application. In my case, I could not 'just return a 404 for it' as the proprietary web application running the website is closed source, and 'in the cloud' at a vendor-provided facility. The only method of returning a 404 at my disposal was to return a nicely formatted 404 error page, that contained our tracking code on it. — Tal, May 14 '13 at 22:34
makes sense. My problem with that is there's no way to ensure I get the same broken ad someone else will - in my test environment, I get a whole different set of ads. Someone else may get ads on their browsing behavior that I would never see. Anyway, I think both solutions have merit, depending on the situation. — Julian, May 15 '13 at 15:29
Agreed. Both solutions have merit. If I could have sent a plain 404 page, or nothing at all, I would have chosen that solution. — Tal, May 15 '13 at 22:04

Miguel · Accepted Answer · 2013-03-27T20:59:48.230

10

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();
}

edited Mar 27 '13 at 20:59

answered Mar 21 '13 at 18:55

Miguel

566
1
5
16

1

This does little to help prevent the offending ad from coming onto your site. It also does nothing to help you report the ad to the ad networks running the code. It would only sweep the problem under the rug. In our case, modifying the webserver to throw a 404 or placing a dummy file would have been impossible.. a third-party vendor controls the server infrastructure, and prevents static html hosting. – Tal Mar 26 '13 at 13:39
Sure, it would be nice to track it all the way back to the source and stop it from happening, but I just need a defensive position that doesn't rely on third parties. This is that - technical - solution. – Julian May 14 '13 at 17:21
2

@Miguel, just reread your post. You are correct, a conditional on the javascript tracking code itself would work to prevent catching any analytic information for that page. It would permanently fix the issue, without any chance of it returning. While I felt joy finding the ad responsible, it was time better spent elsewhere. +1 for a faster and better solution! – Tal May 15 '13 at 22:16

score 2 · Answer 3 · answered Dec 04 '12 at 18:28

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.

You are correct, MindMind is the company behind the offending script. In our case, the ad was for IKEA's Sieze The Days advertising campaign. It does not surprise me that AdSense is getting these types of remnant ads too. Adding the "/eyeblaster/addineyev2.html" to your website would do the trick too. In my case, My employer has a large proprietary CMS, and that wasn't possible. After determining it was the Sieze The Days advertisement, I was able to have our remnant provider (Centro/BrandExchange) block the IKEA ads from our website. — Tal, Dec 05 '12 at 15:42

score 1 · Answer 4 · answered Dec 14 '12 at 01:02

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.

Absolutely. There appear to multiple issues with the software as well. In our case, the software wasn't redirecting users -- merely causing many errors on our end. I would have been hand-over-fist more upset if our users were actually being redirected elsewhere. In our case, the user was unaware. — Tal, Dec 14 '12 at 15:14
I'm seeing it from bs.serving-sys.com (bursting pipe). Gotta love those ad agency names. My eyes are being blasted by a bursting pipe! Aigghh.. — Julian, May 14 '13 at 17:22

Determine which advertisement made a request to /eyeblaster/addineyev2.html

4 Answers4

Linked