Facebook Bots Are Not Stealing Your Ad Spend | Hacker News Reader

Facebook Bots Are Not Stealing Your Ad Spend

simplereach.com

24 pointskloncks26 comments

> The first is that the traffic coming in had JavaScript disabled. If this was the case then the JavaScript analytics software would not detect the incoming traffic and therefore would not be able to log the result at all.

Did you read their post? To quote:

> Here's what we found: on about 80% of the clicks Facebook was charging us for, JavaScript wasn't on. And if the person clicking the ad doesn't have JavaScript, it's very difficult for an analytics service to verify the click. What's important here is that in all of our years of experience, only about 1-2% of people coming to us have JavaScript disabled, not 80% like these clicks coming from Facebook. So we did what any good developers would do. We built a page logger. Any time a page was loaded, we'd keep track of it.

Emphasis added.

If this was the case then the JavaScript analytics software would not detect the incoming traffic and therefore would not be able to log the result at all.

Most Javascript analytics packages also wrap an image call in a noscript tag to capture hits for browsers which do not have JS enabled. So yes, you can log the result with JS turned off.

"wrap an image call in a noscript tag"

Although the author of the original post said nothing, i assume that's what they did.

You can also just look at the server logs. That's what most of us did before Google Analytics (and still do).

That still won't detect bots. If you build a click-bot, you're probably only going to click the link and download the source. You wouldn't care about loading any images so the 1x1 pixel image still won't track the page load.

To track bots effectively, you need to check your server logs. In fact, you could build a strong case for a bot click if the requesting IP pulled the source HTML but didn't follow up with any image requests from the page. Not loading images is typical bot behavior.

Yes that would definitely tell him that people without JS turned on were viewing his page. It would not magically tell him that these came from facebook (or should have).

I was hoping the article would be a little more informative and definitive according to the title. It is based on assumptions itself with a little theory behind it.

As for the statement - "The first is that the traffic coming in had JavaScript disabled. If this was the case then the JavaScript analytics software would not detect the incoming traffic and therefore would not be able to log the result at all." You can track incoming requests outside of javascript through the server. That is possibly what they had wrote.

I can't believe someone who has 'delivered highly scalable solutions' actually managed to write this line on his blog with a straight face. How were you not able to deduce that the devs likely detected disabled javascript without the use of javascript?

His whole post is devoid of content and nothing but statements without any real substance or evidence.

How do you reliably check that javascript is turned off without resorting to javascript?

edit: never mind; an img in a noscript tag.

Or. Hits to a website result in a list of unique IPs accessing the site. Remove any IPs from the list which are known to be running JavaScript. The remaining IPs aren't running JavaScript or are ignoring/breaking your script.

This begs the question whether or not there was a scenario where there was a hit to the site, the referrer was set to Facebook, JS was enabled in the browser, but the resulting hit didn't result in a JS enabled request to the analytics software.

Another poster mentioned prefetching as a likely culprit. Google is known to prefetch search results for you, but it requires the use of the rel="prerender" tag. I find it highly unlikely that is what's happening here.

The point of my article was not on how the dev was detecting JS. So I didn't want to go into detail on it. Even if he did that (which he never claims he does) He would only see that people are coming in with JS turned off, not that they came from facebook.

He does make the claim that 80% the clicks they were paying for had JS disabled. That would imply the referrers were set on those requests to be from Facebook and the IPs hitting the pages weren't registering in his JS based analytics package. We know he's logging the hits to a file, so presumably that data is there.

You claimed 'There were a few false assumptions made in the post. The first is that the traffic coming in had JavaScript disabled.' Care to elaborate on how it's a false assumption if the implied statement above is true?

I'll give you that he may be wrong, but I really don't see where there's concrete evidence to support your claim he's making false assumptions!

Here's another possibility that popped into my head while reading this article. What about browser prefetches? Is it possible that a browser, say Chrome, is prefetching linked pages and that prefetching is being detected by Facebook as an ad click?

I'll admit I know little to nothing about how prefetching works.

This is an interesting theory.

If this worked like you think, bad things would happen. Think about all the "?action=delete" or "/logout" links spread all over the internet.

Bad things deserve to happen to web app operators who do not protect delete and logout by putting them behind POST[1] request.

[1] pedantry - PUT, POST, DELETE implement it however you want. Just don't change database state using GET.

So this article is claiming that 80% of people clicking on Facebook ads have chosen to use https? Seems way too high to me.

Facebook has been strongly recommending people switch this on (a one-step process, prompted in your news feed) for over a year now. http://www.insidefacebook.com/2011/06/02/https-secure-browsi...

I'd be surprised if the number was as low as 80%.

I have to say, I think you are VASTLY overestimating the average facebook user.

I've never received that prompt. If you read further down in that misleading article you linked to, you would see that they don't show the prompt to all their users:

> we're displaying this prompt when a user who has not enabled secure browsing (through the account settings option) manually changes their browser's address bar to https://, which does not fully protect their Facebook traffic.

I just had to go hunting through privacy and security settings for 5 minutes to figure out how to enable HTTPS.

So no, I would guess fewer than 0.1% of Facebook users have this enabled.

It's a year-old article. My company builds (among other things) Facebook apps and we definitely receive this alert these days on test accounts that are purely accessing via HTTP.

I tend to agree with the parent of this comment. Most people on facebook are clueless when it comes to even simple privacy fixes, and even the technorati have trouble tweaking things properly.

I thought the same thing as parent. It seems the poster is suggesting that tons of people are using https, and I can almost certainly say that just about everyone I know does not use that feature.

I believe the poster of that facebook post (Limited Run) said they would post their analytics details or something like that. I'd kind of like to see them, myself.

All the Facebook campaigns I have run use url parameter tagging to track clicks (i.e. for Google Analytics append &utm_source=facebook...) to the url.

I think this is fairly standard practice so it seems unlikely to me that they'd have to use the referrer exclusively

I've checked a handfull of the facebook ads and I didn't find any querystring paramete attached.

Umm... the facebook post already stated that javascript analytics could only verify 20% of the traffic. They also explained that they wrote their own analytics sans javascript to verify that javascript was disabled.

How did he miss that? Self-inflicted black-eye for simplereach.com

Reply on news.ycombinator.com