A guide to using the Facebook Pixel
github.com
github.com
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).
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.
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
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
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.
If you want to ensure you don't get fined, I'd rather let the user opt-in than risk a legal confrontation.
Add the following to your HOSTS file:
https://github.com/panicsteve/facebook-hosts-file-additions/...
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.
Tracking cookies and code can only be set and loaded after the user has accepted them.
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.
> 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.
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.
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.
Sources please.
I think it was mistaken for Google paying Mozilla to keep it as default search engine.
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.
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.
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.
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.
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.
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?
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