Hacker News new | comments | show | ask | jobs | submit login
A guide to using the Facebook Pixel (github.com)
151 points by zappo2938 on Nov 13, 2016 | hide | past | web | favorite | 46 comments



This, btw, is where the EU cookie law applies, and what it was intended to prevent.

You can not embed that tracking pixel without first having approval from the user.

(This – third party cookies for tracking – is the entire reason the damn law was written in the first place, and yet we still haven’t gotten rid of them).


Isn't it crazy how the cookie law requires all web sites to be honest and provide opt-in mechanisms, while still doing nothing to protect against shadier outfits ignoring it all, when a browser setting could solve the problem in a 100% failsafe way?


Well, it doesn’t require all websites. Only those who use additional technical means purely to track the user.

A login cookie doesn’t require approval, nor do settings cookies.

Only once you start loading Google Analytics, Piwik, Facebook, etc the law starts to apply.


Does this cookie law only apply to sites that operate offices within the EU? Won't all US-only sites be unaffected?


A guide to blocking the Facebook Pixel

Add the following to your HOSTS file:

https://github.com/panicsteve/facebook-hosts-file-additions/...


because the law was shitty.

the boiler plate message it allows fails to explain anything. who is receiving the information? for what uses?

the silly message is expertly conceived by published as to fog the reason. most people in the audience think that is a paranoid warning about first party cookies, which are perfectly fine.


Plus it's basically too late by the time you show the message... cookies have already been set and sent...


Eh, no.

Tracking cookies and code can only be set and loaded after the user has accepted them.


Interesting. I'm new to this. What do I need to know to make this legal?


Get consent, full opt-in. I think most people just do a "do you accept this page uses cookies? Yes, No, Read more" and on the read more page you specify what you use the cookies for, and how you interact with Facebook.

On top of that you can also start respecting the Do Not Track header sent by some browsers https://en.wikipedia.org/wiki/Do_Not_Track


Simply, you first present the user with a dialog asking them for approval to track them, (and you have to make that explicit), and only once given approval, you actually load the tracking code from Facebook, and interact with their third-party cookies.

If the user says no, well, just redirect to Google, or something – but you can’t load or set that tracking data before the user has clicked "Yes, I agree", and you can’t hide the fact that users are actively tracked in the ToS or somewhere.

If you don’t care about breaking european law, you can just leave the tracking there, never asking the user, but, well, you’re breaking european law then.


Has anyone actually been prosecuted for this? I can imagine that in Germany they might follow up on this but elsewhere in Europe I see plenty of sites not informing users.


Actually, yes. And, yes, it was in Germany. And it was in fact for using Facebook tracking pixels and "like" buttons by large newspapers.

Which is why every newspaper then switched to "2-click Like", where the Facebook button is first shown in grey, you click it, it loads the actual button, and you can like.

It was also recently confirmed in a court case from this year (15'000€ fine for using it): http://www.verbraucherzentrale.nrw/mediabig/239773A.pdf


No-one cares about this. The cookie law is dead.


Interesting claim, considering someone has been sentenced to a 15'000€ fine for violating it just this year. http://www.verbraucherzentrale.nrw/mediabig/239773A.pdf

If you want to ensure you don't get fined, I'd rather let the user opt-in than risk a legal confrontation.


And you never will get rid of them. Laws are not that effective at changing the internet. It's called the Wild Wild Web for a reason.


This is what sometimes is called a "third party cookie"


which you should disable as soon as you install your browser.

unless you bought into the Google one. since Google also benefit a lot from 3rd party cookie, it paid Mozilla so they enabled it by default (use to be off by default) and i think recently chrome ever removed the option to disable it.

disabling 3rd party cookie is a million times more effective than enabling the joke of the do no track settings in the browser.


> it paid Mozilla so they enabled it by default

Sources please.


It's not true, Mozilla actually tried to block them by default back in 2013 but was threatened by the ad industry and backed down. http://www.computerworld.com/article/2495739/internet/ad-ind...

I think it was mistaken for Google paying Mozilla to keep it as default search engine.


And yet desktop Safari continues to block most third-party cookies, last I checked.


most?


Chrome still has the option, though they're not disabled by default. I disable them and also set up another person/profile in Chrome that allows 3rd party cookies but deletes all cookies when quitting. If I encounter a site that doesn't work with 3rd party cookies disabled, I can easily launch another window with the other profile and view the site without having to change settings.


There is a cookie icon in the adressbar if 3rd party cookies are blocked. You can click it and go to show cookies or something (first blue link) and unblock the blocked.


This setting is in the latest versions of desktop and mobile Chrome.


I think it was very revealing that they never had this setting for a long time, despite it being available in just about every other browser before then...


This isn't true. Chrome launched with a setting called "Restrict how third party cookies can be used" which was almost the same thing:

> First-party and third-party cookies can be set by the website you're visiting and websites that have items embedded in the website you're visiting. But when you next visit the website, only first-party cookie information is sent to the website. Third-party cookie information isn't sent back to the websites that originally set the third-party cookies.

As far as I can tell, this difference was due to the fact that Chrome (at the time) was a WebKit fork (see https://bugs.chromium.org/p/chromium/issues/detail?id=12969#... and https://bugs.chromium.org/p/chromium/issues/detail?id=16658#...). Both the comments I mention are from 2009 (less than a year after Chrome was publicly announced).

I searched through chromium's source to see if I could figure out when this option/feature changed. I didn't find it, but I find plenty of examples of Chromium developers adding functionality and features to make blocking and monitoring third-party cookies easier.

I did find a thread on Hacker News from 2011 (https://news.ycombinator.com/item?id=3034295), by which point Chrome's third party cookie blocking was actually stricter than WebKit/Safari due to changes in Chromium's cookie management. Note that the main argument there isn't that Chrome should expose their strict cookie blocking as a setting (their current behavior), but that Chrome should default to Safari's looser handling (which seems similar to Chrome's original "restrict.." setting). It is worth noting that Firefox did eventually implement the latter solution - but two years later, in 2013 (https://blog.mozilla.org/netpolicy/2013/02/25/firefox-gettin...).

It's possible I have missed something and there is evidence somewhere on the Internet that there was a point where Chromium's handling of third party cookie blocking was significantly different than all other major browsers, but I haven't seen it.


> First-party and third-party cookies can be set by the website you're visiting and websites that have items embedded in the website you're visiting. But when you next visit the website, only first-party cookie information is sent to the website. Third-party cookie information isn't sent back to the websites that originally set the third-party cookies.

This mess of words is merely an excuse to say that the 3rd party cookie protection didn't really work. Are you seriously raising this as a feature in some way as good as 'block 3rd party cookies'? As the bugs you linked show, Chrome's behaviour broke sites where Safari worked, yet leaked cookie data to sites.


> Are you seriously raising this as a feature in some way as good as 'block 3rd party cookies'? As the bugs you linked show, Chrome's behaviour broke sites where Safari worked, yet leaked cookie data to sites.

My point was that your previous claim that Chrome didn't have a third-party cookie blocking feature until after other browsers because Google hates privacy is wrong, since Chrome launched with a similar feature and its developers explicitly tried to maintain cookie-blocking parity with Safari.

The site breakage you referenced was because Chrome was blocking cookies where Safari wasn't. The data leakage bug also explicitly states Safari was subject to the same data leakage. Neither issue supports your initial claim, since they are proof that Chrome developers wanted parity with Safari, which suggests the point of Chrome wasn't to create a browser with less privacy protections than the competition.


I don't even see an option in Firefox ESR 45.4.0 to disable 3rd party cookies.


Nice write up! As what you have is a catalogue of sorts you should have a look into Dynamic Product ads: https://www.facebook.com/business/a/online-sales/dynamic-pro.... This is Facebook's programmatic play which does all the segmentation work in the background.


This is a great overview. I find it interesting that there is still significant friction with setting up arguably one of FB's most useful ad tools....I also find it interesting that tracking pixels pretty much haven't changed since the late 90s.


Out of the box, all you need to do is drop the default code onto your web page and it will call the 'PageView' event. Pretty much the same deal as Google Analytics (and Twitter also have their own version). @palmdeezy has taken it a little further to include extra metadata in order to segment website visitors.

And I agree that these snippets have been around for a while but how else could you facilitate passing data back to ad exchanges? JavaScript seems to be the perfect tool to get the scale required to handle these types of interactions.


As a consumer I can totally read that and understand what I've given up. Totally.


This is unnecessarily complicated. You can create a custom audience with url definitions and don't need custom events for that. Unless you are using a single page site there's no need to over complicate this with more JavaScript.


This example is a single page site.


I have found the FB pixel to be both awesome and not fully baked in terms of reporting.

The general concept of allowing custom events is awesome. It means it plays really nicely with situations that don't fit nicely into their standard events. By the same token, custom events feel like second class citizens in FB ad reporting.

Here is a scenario and I'd love any suggestions if people have them because there is no documentation on this and FB has basically done away with access to a live person for ads (while interestingly enough Google now goes out of its way to connect you with a live person, even if only via chat).

I work on a product with a free trial with subscriptions of multiple plan levels and terms. I can track a custom event on subscription and pass plan and term params along with the revenue data, but there is no easy way to drill into those dimensions keyed off of custom params with their reporting. The only manual hack I've found is to create an aggregate custom event for all subscriptions for top level reporting, and then individual custom events for each plan/term permutation (plan1/annual, plan1/monthly, plan2/annual, plan2/monthly, etc.).

This is manageable for now as there are only 8 events plus the aggregate one, but I then have to add each of those as custom columns to reports which gets super messy.

The not fully baked part is that as an advertiser, my ideal reporting dashboard in FB would let me drill in at multiple levels and segment reporting by these custom dimensions just by using a single custom event's params. So I'd have a report segment option for plan and term that then broke those out in the table and then the chart (and their charting capabilities are also sorely lacking right now for serious advertisers).

Instead, I need to dump this to a spreadsheet and pivot it if I want to do any serious analysis.

Has the author or anyone else solved for this differently outside of using a PMD with better reporting? We'll end up switching to one soon enough, but I feel like FB has really failed to go the final steps with this. Adding custom parameters but then not allowing advertisers to report and segment by them is a huge opportunity for them. And they clearly have the data parsed already because offer it in the custom conversion and audience builder tools.

Also, and this applies to most ad platforms...I wish there were better support for recurring up and LTV tracking and reporting. Helping me easily report on the full deferred value the ads are driving makes it easier for me to build the case for more spend. I can do that in other analytics tools, but I feel like this is data FB would want to have in a structured format. Maybe that's just me though.


I totally agree with your sentiment. What you are talking about I have "solved" by baking the dimensions into Google Analytics. However this is not really accurate. (I am trying to build a solution to this very problem in my spare time, actually).

About LTV: Yes, I totally agree. Another thing I don't like is the Facebook docs: I had a hard time implementing their custom events (trackCustom) because sometimes their resources link to older API versions and they are in dissonance of each other.


FYI as a word of caution with FB numbers in GA...FB gives 100% credit to view-through conversions with a 1-day lookback window by default in addition to click conversions on a 28 day window. GA only has last click attribution by default in most reports (attribution/multi-channel aside) and only tracks post-impression performance from channels Google owns (GDN, data piped in via DCM, etc.). So you'll likely have large discrepancies.

That is actually one of the biggest headaches with getting reporting automated at scale that I've had to solve for many times in my career. Bid management platforms don't hold all the data, your ad server can hold most of it but you need to pipe stuff in and still have real limitations on the levels of data you have in there, etc. Even extremely expensive enterprise solutions don't fully solve for all of this.


The problems you are experiencing should be what ta digital marketing consultant should be able to solve (i.e. naming conventions, automated reports) however anything above rudimentary analysis seems to be outside most analyst's skill sets form my experience - the tools don't help with this as you've discovered. You could even think that the platform providers (Google, Facebook) make it unnecessarily hard on purpose...


So...I actually am a senior digital marketer who has been doing this stuff for over a decade. The naming conventions aren't an issue, and automating through another analytics platform has its own issues (GA for example won't track FB's view throughs unless you manage it all via an ad server that can get the post-impression performance from FB).

My ask was around whether anyone had solved for this use case in FB since the documentation on Custom Events is limited in this regard. My broader point is that having seem MANY different ad platforms in my time, I'm disappointed that FB's is so limited compared to something like AdWords which, despite its issues, I still consider the gold standard in terms of UI/UX.

Your last note about making it unnecessarily hard on purpose is an interesting one that I've heard floated on more than one occasion. I think there is probably some gain for them in not giving super granular data on this as it leads to inefficiency in ad spend which in turn means higher CPMs for them. The counter-argument I've always made is that if you provide an amazing ad platform with great tools to drive performance, advertisers will shift more budget to you away from competitors in such a manner that should offset losses from people cutting out more of the crap inventory.

There's also the possibility they don't prioritize giving their ad platform love because it nudges people to PMDs and they have a lot to gain by growing that ecosystem. If your partners are doing all the development work for you to build their own interfaces AND they are driving more media sales, that might be enough to drive a strategic shift away from their own platform. I'd be very shocked if this were the case though.


There's a package in R that connects to the API. Native dataframes, dplyr, the best visualizations out there and rmarkdown notebooks and flexdashboard make it great for things like that.


Facebook, Google - people treat their numbers as holy because they have so many smart people working for them (and because they have very good PR departments).

But I beg to differ. I think it is about time we have a community investigating these metrics: https://segahm.github.io/adwords_investigators.html


I'm interested in how this works with your business model.

Do you charge job posters extra to get wider distribution (or more budget) on the ad you are running for them?

Or is this more of a growth hack to simulate having more organic traffic flow on your site?


There is no business model. I'm a yacht chef who decided to learn to code JavaScript. This site is just something to put in my portfolio.


I appreciate your post. Good insight on the "how to" and it surely got me motivated to have a look into this.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: