5 ms·

Facebook Bots Are Not Stealing Your Ad Spend

24 points by kloncks 14y ago

learc83 14y ago
So this article is claiming that 80% of people clicking on Facebook ads have chosen to use https? Seems way too high to me.
- ceejayoz 14y ago
  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-browsing-home-page/ http://www.insidefacebook.com/2011/06/02/https-secure-browsi... I'd be surprised if the number was as low as 80%.
  - devindotcom 14y ago
    I have to say, I think you are VASTLY overestimating the average facebook user.
  - deleted 14y ago
    [deleted]
  - alainbryden 14y ago
    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:// 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.
    - ceejayoz 14y ago
      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.
  - joshlegs 14y ago
    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.
ryan_f 14y ago
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.
- nakor 14y ago
  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.
  - tijs 14y ago
    How do you reliably check that javascript is turned off without resorting to javascript? edit: never mind; an img in a noscript tag.
    - kordless 14y ago
      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.
  - devdazed 14y ago
    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.
rfergie 14y ago
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
- devdazed 14y ago
  I've checked a handfull of the facebook ads and I didn't find any querystring paramete attached.
gwern 14y ago
> 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.
- mikeryan 14y ago
  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.
  - veyron 14y ago
    "wrap an image call in a noscript tag" Although the author of the original post said nothing, i assume that's what they did.
  - thraxil 14y ago
    You can also just look at the server logs. That's what most of us did before Google Analytics (and still do).
  - MichaelApproved 14y ago
    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.
deleted 14y ago
[deleted]
- devdazed 14y ago
  You're assuming that he did set up a landing page or modified the url. There is no evidence to suggest he did that. Also, this article says nothing about facebook. It was ad-networks that the blank was run on.
allwein 14y ago
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.
- devdazed 14y ago
  This is an interesting theory.
- xentronium 14y ago
  If this worked like you think, bad things would happen. Think about all the "?action=delete" or "/logout" links spread all over the internet.
  - vampirechicken 14y ago
    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.
bimr 14y ago
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

24 points by kloncks 14y ago

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

ceejayoz 14y ago
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-browsing-home-page/ http://www.insidefacebook.com/2011/06/02/https-secure-browsi... I'd be surprised if the number was as low as 80%.
- devindotcom 14y ago
  I have to say, I think you are VASTLY overestimating the average facebook user.
- deleted 14y ago
  [deleted]
- alainbryden 14y ago
  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:// 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.
  - ceejayoz 14y ago
    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.
- joshlegs 14y ago
  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.

ryan_f 14y ago

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.

nakor 14y ago
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.
- tijs 14y ago
  How do you reliably check that javascript is turned off without resorting to javascript? edit: never mind; an img in a noscript tag.
  - kordless 14y ago
    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.
- devdazed 14y ago
  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.

rfergie 14y ago

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

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

gwern 14y ago

> 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.

mikeryan 14y ago
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.
- veyron 14y ago
  "wrap an image call in a noscript tag" Although the author of the original post said nothing, i assume that's what they did.
- thraxil 14y ago
  You can also just look at the server logs. That's what most of us did before Google Analytics (and still do).
- MichaelApproved 14y ago
  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.

deleted 14y ago

[deleted]

devdazed 14y ago
You're assuming that he did set up a landing page or modified the url. There is no evidence to suggest he did that. Also, this article says nothing about facebook. It was ad-networks that the blank was run on.

allwein 14y ago

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.

devdazed 14y ago
This is an interesting theory.
xentronium 14y ago
If this worked like you think, bad things would happen. Think about all the "?action=delete" or "/logout" links spread all over the internet.
- vampirechicken 14y ago
  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.

bimr 14y ago

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