Adsense and the Facebook Like button

[rlopes]

Let me tell you a curious story of rise and fall.

On April 10th, my Adsense earnings went to the roof. I couldn't tell the reason for that, but I decided to be glad and do not bother about it.

Much to my surprise, my earnings kept going up over the last days (with a quick weird drop on the 16th), until they came back to the regular levels on April 20th.

As it couldn't be different, I decided to investigate the sudden drop (yes, only after it started hurting my pocket).

The only unusual thing that I could find was an amazing raise on the number of times the page "?fb_xd_fragment=" was opened on that golden period. For those who don't know, that's an URL that shows due to a bug on the Facebook Like button, which doesn't support some browsers.

The rest of the site's traffic was exact the same, so why the Facebook Like button error started showing up A LOT more often on the logs? And even weirder, why did it impact on the Adsense earnings?

I wish I knew.

Here's a screen shot of GA: [imageupload.org...]

[Atomic]

IE users see a blank page when the redirect is done. So no one can see your Adsense ads. You bet that will impact earnings!

[JoePublisher]

You're saying you earned MORE money during the problem with the ?fb_xd fragment? in what you described as a 'golden period'.

This is not a good thing, trust me, in fact if you do not get it sorted out, i.e. stopped, you are either going to be smart priced back to the stone age or your account suspended ...

@Atomic ... The I.E. 8 bug does not just show a blank page, it CAN also refresh the page (and the adverts on it) hundreds of times per unique visitor, (if they cause the bug to activate - and particularly when they hit refresh a few times on seeing a blank page).

I was alerted to this by one of my team who saw this on my site for two days before we acted quickly to stop the problem - I also checked it out using a computer using I.E.8 (one that activated the problem, not all I.E.8 browsers do, I estimated it at around 1 in 50 visitors with I.E.8) to see exactly how the page was viewed. The problem also came out of the blue, I had used the 'like' button previous to this for months.

An unintended consequence of this problem can see the page impressions (and your adsense impressions) multiply a thousand fold with just 10 or so visitors; I found 12 visitors to a page could record it as being seen 800 times etc. all with the ?fb_xd fragment attached to the url. Page Impressions in adsense also reflected this increase for the two days it was happening on my site, ads were being reported as being shown in correlation with the increased ?fb_xd fragment, an increase of thousands of impressions (not good!) with no CTR.

---- The image given as a link by the OP shows this happening, the page given as an example is being registered as being seen 31,800 times from just 4331 unique visitors, (i.e. each person on average wants to see this same page about 10 times, for just 12 seconds?) therefore something is wrong ... particularly when adsense also says this page displayed ads 31,800 times, especially if CPM ads are being shown (which register as needing to be paid) and not CPC ads ----

It also has a knock on effect of throwing out your analytics by a huge factor, page impressions appear 90% improved, while bounce rate appears reduced by 90% and time on site is reduced by 90% etc. (Remove the fragment from being identified by analytics and under webmaster tools as a legitimate url)

There is nothing that is good in allowing this problem to fester and do nothing about ... The only way you would earn more money is if you were showing CPM ads and each 'fake' view (totalling in the thousands) were being recorded as 'natural' - and this would only last for a small period of time before your account was suspended - because a closer examination by adsense at the end of the month would show each view of the page only lasts a fraction of a second.

The best way to stop it cold is to add this to your .htaccess file ...

#Facebook Redirect For Added String
RewriteCond %{QUERY_STRING} ^fb_xd_fragment=.*$
RewriteRule ^(.*)$ http://yourwebsitename.com\/$1? [R=301,L]

My advice to anyone who see the ?fb_xd fragment get attached to their urls because of using the 'like' button etc. it to sort it out, and quick, before it does damage to your analytics, your direct advertiser stats and perhaps your adsense account.

[rlopes]

You're saying you earned MORE money during the problem with the ?fb_xd fragment?

Yes, I was earning A LOT more due to this bug.
Thanks for clarifying it...

[Andem]

I noticed this a few days ago when impressions sky-rocketed. I wasn't quite sure what the problem was and just added

deny from

to my httpd.conf. I've now coded in showing fb like buttons based on browser.

Are you sure this was only from MSIE 8? The problem I saw was only MSIE 6.0. What about 7.0?

[JoePublisher]

@Andem ... it could easily be triggered from previous versions of IE. However, most people (still do) use I.E.8 rather than 6 or 7 or indeed 9 - so this to me was the main source of the problem - and I used a computer with I.E.8 loaded to see how it was affecting my site, and this version triggered the problem for me.

Facebook have had over 1 years notice about this 'problem' but have done 'nothing' about it, (not that I could research) because they have no idea what causes 'some' IE browsers to trigger the problem, and, not all sites experience it ...

The computer using I.E.8 that I used to 'see' the problem being trigged on my site was not a regularly updated version, (i.e. the latest versions of I.E.8) but it was certainly version 8. Later versions of 8 (with updates) seemed not to trigger the problem, although I did not hang around longer than two days to see if this problem was more widespread on my site.

Here is the problem from the users end ... What you see is the page being created normally as it loads, (including the adverts) then it automatically refreshes after the page loads to a 'new' page url with the ?fb_xd fragment, which is blank. But because you have 'seen' the page load, and 'seen' the information you are seeking come up before going to a blank page you automatically want to hit the browsers 'refresh' button thinking that it was a one off problem.

'A Perfect Storm' ... However this time you see the page load much quicker, the information you want is seen for a fraction of a second (because now it is in your browser's 'cache') before going to the blank ?fb_xd fragment page. This prompts your visitor to keep hitting refresh in annoyance because they can briefly 'see' the info they want, before it goes to the blank page.

Sometimes the page will refresh twice or three times (or more) on each hit of the refresh button ... hence literally one visitor, (who triggers the problem) in a matter of seconds, can make that page load (with any adverts and analytical tracking software on it) at least thirty or forty times before they give up, never to bother with your site again - A 'PERFECT STORM' OF A BUG!

Couple this with a popular site or page and 500 visitors to a page of 4000 unique visitors who trigger the problem (because not all of them do) can refresh that page upwards of 30,000 times! Doh! However although each refresh is calculated by your analytics program, (I think) adsense only counts ad impressions on fully loaded (refreshed) pages before going to the blank page, so the count is somewhat lower, although this is still in the thousands ...

Note: Rather than using a browser specific solution (I want to have the 'like' button used by everyone), I used the solution I suggested, which I checked works on all browsers creating the problem, while still allowing the 'like' button to be used.

[DirigoDev]

This fb_xd_fragment issue is a big problem. Facebook should step-up to the plate and fix this and other issues. Shame on Facebook for not fixing these bugs!

It took us a bit of time to figure out how to fix the issue in .NET - our Facebook component is in a user control. What a pain in the ass.

[derivative]

You can also just use the iFrame version of the Like button to solve this issue -- happened to me as well. Implemented iFrame and stripped the FBML version, problem solved.

[Play_Bach]

@derivative

Thanks very much for posting this important distinction!

[freejung]

Thanks, JoePublisher, just implemented your fix and it works great! Fantastic idea.

Also, I noticed something interesting. My site has apparently been "Pandalized," losing about 50% of Google search referrals around April 11. I just noticed (I hadn't looked for this before) that right before the Panda hit, there was a huge spike in pageviews for these fragment bug pages. They more than doubled. After Pandalization, these pageviews dropped to less than a third of their normal volume, indicating that a disproportionate number of users experiencing this problem are not being sent to my site by Google. Makes me wonder if this had something to do with the loss in the first place. I'll report back if fixing this leads to a recovery of traffic.

[JoePublisher]

@derivative, you are 100% correct. And I looked at this, but this solution is (I felt) a 'compromise'.

The functionality of the FBML version (when you also use the correct facebook meta tags - coupled with a facebook 'recommend box' to encourage users to see what other people are recommending) is fantastic for a publisher. It really pushes your brand and posts out to other facebook users who in turn spread the 'word'.

When a visitor clicks on the 'recommend' button, and it is the fully functioning FBML version (with the bells and whistles) it is of a great benefit; while to me the iFrame version is far less useful, less intuitively social and provides less visitor data feedback to analyse, although, yes, it is still of value ....

The solution I suggested allows you to have the fully functioning XFBL version running rather than the 'comparatively' less useful iFrame version.

[JoePublisher]

@freejung ... when dealing with Panda issues I think everyone will give you the same answer 'perhaps' ... if you do a little research on this ?fb_xd_fragment you will see it gets attached to a url, making it in effect a new and 'unique' page - 'perhaps' one of the major issues is that you are creating 'duplicate' content which could be getting indexed - especially if this problem was not treated for a long time. These new ?fb_xd fragment url's are certainly making their way into the index from high profile sites like CNN so duplicate content would be a concern of mine ...

And duplicate content, coupled with a very high bounce rate of visitors back to the SERPs - to find a site which does not infuriatingly show a 'blank' page (bounce rate figures not from your google analtics data being used against you, but other indicators) - could certainly indicate a 'poor' user experience and a Panda Penalty ... but again I say 'perhaps'.

[davec]

Many thanks for the fix JoePublisher.

[JoePublisher]

thanks @davec ... but I have to give credit to that .htaccess file to someone else who wrote it :) I'm just glad I found it.

I have been free of this problem for over three months now, whilst still being able to use the full functionality of the FBML version of the button and other important FBML facebook 'boxes' ... it still doesn't absolve the facebook developers who should really 'fix' this issue rather than hoping it goes away.

[DirigoDev]

We fixed the fb_xd_fragment issue by using asynchronous script loading techniques. If you search G on "asynchronous script loading, facebook" you'll find a host of solutions. This also helps page load time.

[Atomic]

@JoePublisher - thanks for the clarification. I removed the code before I noticed the increase in AdSense impressions. Looking back, yep, each visitor appears to have refreshed the page as many as 9 times before giving up.


I also found this fix, which has fixed the problem for me:

Put this right before </body>

<!-- Correct fb_xd_fragment Bug Start -->
<script>
document.getElementsByTagName('html')[0].style.display='block';
</script>
<!-- Correct fb_xd_fragment Bug End -->

[Atomic]

Whoops. I spoke too soon. The page is no longer blank, but the page still redirects to that URL.

[Play_Bach]

@Atomic

Has this bug affected your earnings? I ask because unlike a lot of us here, you've been reporting solid gains. Thanks.

[mromero]

Would someone post an example on the code here to properly load the XFBML Like button on a page?

[Atomic]

Not really. I see a handful of these refreshes a day despite that fact that IE 8 os used by least 20% of all visitors. The only time I saw real poblems was when I added the new "Send" button. That affected several browsers and a large number of total impressions. I yanked it right away.

The Like button problem hasn't hit me much because I went with the iframe version for a short term solution.

[JoePublisher]

@Atomic the code you gave was one of the first things I tried, without 100% success, after going to the iFrame version, deciding I wanted to stick with the XFBML version, and then using the newer SDK asynchronous script as suggested by @DirigoDev the only thing I found which bullet proofed the site 100% (for the last 3 months) was the addition in the .htaccess file which uses a 301 redirect to the 'clean' canonical url just for those visitors (the minority) who trigger the bug - just remember to alter the last line of the code to include your full website home page - either with or without www - i.e. whatever string you use.

either - http://www.example.com
or - http://example.com

Or if you are successful using another method then use what works for you. Just don't leave the problem, it creates duplicate content and really annoys your visitors who trigger the bug - plus any issues that adsense finds.

[edited by: JoePublisher at 6:17 pm (utc) on May 13, 2011]

[Atomic]

Yeah, that's why I yanked the code.

People should be aware that the commenting code has the same problem as the Like button. And there is no iframe version.

[Sgt_Kickaxe]

The like button code acts buggy in older Firefox browsers occasionally too, it's not an IE only issue. I've seen it cause the box to open and close rapidly over and over again and there isn't much you can do to stop it besides closing the browser or clicking a link (but you have to be quick as the page is reset extremely quickly).

The OP "got lucky" because people were clicking on an adsense unit to "save themselves". The bug is serious, it essentially hijacks the browser.

[Panthro]

Surprised I haven't heard more about this. Thanks for posting guys.

[levo]

Use the "Custom Channel URL" to prevent page reloading. And also fix fb_xd_bust/fb_xd_fragment pageviews...

[developers.facebook.com...]

It will use the channel.html for cross domain communication and won't reload the page.

[edited by: levo at 6:46 pm (utc) on May 13, 2011]

[freejung]

@freejung ... when dealing with Panda issues I think everyone will give you the same answer 'perhaps'

Yes, of course, nothing is known for certain yet. I mention it just to throw another datapoint into the mix.

It makes sense though -- you have lots of low quality (in fact blank) "pages" being served from the site (mine were not listed in the index, but Google probably knew about them anyway), lots of frustrated bouncers, false adsense impressions, probably various other "low quailty" indicators arising from this. Obviously Google would rather send visitors to a site without this bug than to a site with it, resulting in a higher percentage of satisfied searchers.

I am currently of the opinion that several factors led to my Pandalization -- this may well be one of them, but of course there is no way to tell for sure.

[Atomic]

@levo - thanks for that!

I see that my frame busting code caused the page to be blank.

[rlopes]

@ JoePublisher
#Facebook Redirect For Added String
RewriteCond %{QUERY_STRING} ^fb_xd_fragment=.*$
RewriteRule ^(.*)$ [yourwebsitename.com\...] [R=301,L]

Seems like this will prevent the wrong version from being indexed, but the users affected by the bug will be still annoyed by clicking the Like button and being redirected back to the page, instead of actually "Liking" the page.

[JoePublisher]

@freejung, you are quite correct, this could have unforseen consequences that you describe, particularly if left for an extended period of time without being tackled.

@rlopes it seems to work fine for me, it redirects the affected user to the clean url and when they press the XFBML 'like' button it works as intended, in other words a 'like' is registered - (from what I have seen and understand the bug is not triggered on pressing the 'like' button it is triggered by merely landing on a page with the like button XFBML code on it). I just went and checked on a computer that I know triggers this bug on my site and it still works for me ...

@levo, this is a good suggestion, but when I instituted this 'fix' (back when researching this problem) I tested it out before going 'live' and I got 2 visitors landing on a newly created 'channel' url on my site, and the analytics I use recorded this as being seen 30 times by these 2 unique visitors ? why they were unique when they were both me testing it out, and why it should end up as 30 page views is beyond me ... it might / should work for others, but for now I am sticking with what works for me. As a side note the facebook coders themselves have doubts about it working for everyone, they introduce using channels as a possible 'help' and not a 'fix'. Give it a go though, it might work.

I think, unless facebook institutes a 'fix' within their existing SDK code (not a 'channel') which gets pulled on page load, I, personally, am slightly out of luck and will have to make the best of it. You might fare better.

[Andem]

>> This prompts your visitor to keep hitting refresh in annoyance because they can briefly 'see' the info they want, before it goes to the blank page.

This IE 6.0 user must have been pretty anxious to see one particular page. They reloaded the page over 8000 times throughout the entire night (in their timezone).

Look at this:

200.90.#*$!.#*$! - - [04/May/2011:10:33:35 -0500] "GET #*$!XX.html HTTP/1.1" 200 4239 "http://www.google.com/search?hl=pt-BR&source=hp&q=#*$!XX" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
200.90.#*$!.#*$! - - [04/May/2011:10:33:45 -0500] "GET #*$!XX.html?fb_xd_fragment HTTP/1.1" 200 4220 "http://www.facebook.com/plugins/like.php?channel_url=#*$!XX%3Ffb_xd_fragment%23%3F%3D%26cb%3Df3d143e5c17a0d%26relation%3Dparent.parent%26transport%3Dfragment&font=trebuchet%20ms&href=#*$!XX&layout=box_count&locale=en_US&node_type=1&sdk=joey&send=false&show_faces=false&width=55" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"

(details are blanked out)

and it went on all night long until I noticed in the morning and I blocked it.