can<\/em> mean that ITP clamps down on the cookie duration and says it can only exist for 24 hrs.<\/p>\nThat result here is that if a website visitor does buy a tennis racket within 24 hrs of them clicking the ad), Facebook will be able to attribute the sale correctly. Fine.<\/p>\n
However, if they buy the tennis rackets 25 hrs after the click (i.e. outside of that window), the cookie will have automatically been deleted by the web browser (because of the integrated ITP policy). Which means Facebook are no longer able to attribute – the advert\/click\/sale knowledge story has been broken.<\/p>\n
And that is really bad news for advertisers, as they are then not sure which of their ads work. And that is then really bad news for Facebook, as advertisers are less likely to spend money on ads.<\/p>\n
Let\u2019s next take a look at another feature coming in iOS14<\/p>\n
iOS14<\/h2>\n A big change in iOS14 will be the \u201cDo you want to be tracked<\/em>?\u201d dialog that should pop-up for all apps. It will look something like this:<\/p>\nFig. 2 – iOS 14 app privacy<\/em><\/p><\/div>\nThis will appear when you launch most apps on your iOS14 iPhone.<\/p>\n
I don\u2019t think I\u2019m going out on a limb here if I say that that dialog is not very enticing: most people, when confronted with that choice, will err on the side of caution by click \u2018Ask App Not to Track<\/em>\u2019 as who wants to be tracked?<\/p>\n\u2026.but what impact does this actually have?<\/p>\n
Remember we said that iOS passes a unique ID* to any app it launches? If you click \u2018Ask App Not to Track<\/em>\u2019, when that app launches it will NOT get given the actual unique ID from your device. Instead, it will get something else – perhaps a random one.<\/p>\n*Well, there are really two tracking IDs (IDFA & IDFV), for the sake of this article, we\u2019ll condense them to one.<\/em><\/p>\nLet\u2019s now look at the app scenario we mentioned early in this scenario\u2026.<\/p>\n
Joel\u2019s Banana Challenge app (on iOS14)<\/h3>\n We\u2019ve previously talked about my hypothetical app which runs on iOS14. It\u2019s a game and it shows ads from Facebook. The ads are highly targeted because of the iOS ID that gets passed to the app – Facebook are then able to tie this ID to a Facebook user\/profile and show very specific ads.<\/p>\n
Great (or not, depending on your point of view).<\/p>\n
Let\u2019s now imagine a user is opening the \u201cJoel\u2019s Banana Challenge<\/em>\u201d app for the first time on iOS14, and they get hit by that tracking dialog above.<\/p>\nThey don\u2019t want to be tracked, so they click NO accordingly.<\/p>\n
Now, the app has an issue – as the ID it passes to Facebook is random (well, it\u2019s certainly not<\/em> linked to a Facebook profile). Which means that Facebook no longer has an inside line on the owner of the smartphone. It can still serve ads, but they\u2019ll be much<\/em> less targeted as Facebook will not be able to reference the encyclopaedic trove of rich profile data it has on the phone\u2019s owner\/a Facebook account.<\/p>\nLess targeted ads typically means less relevancy, fewer clicks, fewer conversions; which all together makes such ads less appealing to advertisers. Which then hits Facebook in the pocket.<\/p>\n
The Facebook App<\/h2>\n We should also consider that the Facebook app itself will also be hit by this privacy dialog. And what does that mean to Facebook?<\/p>\n
As you know, the Facebook website (and app) shows ads itself. Irrespective of what the user has selected regarding tracking, the iOS14 Facebook App can still show very targeted ads as it does not need your unique iOS ID to do that – you are already logged in.<\/p>\n
However, that is not to say that accepting \u2018Ask App Not to Track\u2019 doesn’t have consequences for the Facebook App.<\/strong><\/p>\nWe know that iOS, if instructed, will not<\/em> pass in the actual iOS ID, so that will cause Facebook issues in terms of knowing about people\u2019s usage of apps (even outside of Facebook\u2019s community – such as whether a user plays on “Joel’s Banana Challenge<\/em>“).<\/p>\nWe should also bear in mind this: when someone asks not to be tracked, this choice is passed into the app, and the app is expected to take appropriate action to ensure that they comply with the user’s choice and the terms & conditions of the Apple\u2019s app store. Because compliance is not an option here, if you don\u2019t follow Apple\u2019s rules, you are off the app store – whether you are a company the size of Facebook or not.<\/p>\n
Double Whammy<\/h3>\n We also have to bear in mind the double whammy of Safari\/Webkit privacy changes here.<\/p>\n
This following screenshot is taken from my macbook computer but the situation is largely the same with Safari on iOS 14:<\/p>\n
Fig. 3 – Privacy Report<\/em><\/p><\/div>\nIn the above screenshot, Safari 14 has raised a flag on all the above services that it thinks are invisibly running in the background of The New York times website. Safari call this their ‘Privacy Report<\/em>‘.<\/p>\nAs you see above, the pop-up says \u201c7 trackers prevented from profiling you<\/em>.”. But what does this actually mean?<\/p>\nWell, you\u2019ll start to get the idea if I tell you that this Privacy Report is implementing and reporting on the ITP measures we talked about earlier in this article.<\/p>\n
The Privacy Reports lists out services which it is concerned about under \u2018Trackers on This Page<\/em>\u2019; you see common services like Google Analytics (Facebook\u2019s Pixel would be there as well, if the NYT site used it).<\/p>\nHowever, we should be clear on what is happening here: these services ARE still running, they have not been blocked. Though they are running in a more limited fashion. Limits are as per ITP including:<\/p>\n
– Limited access to cookies \n– Limited ability to set a more lengthy cookie duration (in many cases, only 24hrs).<\/p>\n
For Facebook Pixel etc, this can end up contributing to a narrow attribution window for any purchase which takes longer than a single visit. Which, as we know, causes a loss of confidence with advertisers, who may spend less money on ads.<\/p>\n
FBCLID revisited<\/h3>\n Let\u2019s revisit the FBCLID – the unique identifier which Facebook App (etc) appends to outbound links for attribution purposes.<\/p>\n
If an iOS14 user has clicked \u2018Ask Not to Track<\/em>\u2019 on (say) the Facebook App, then question marks must be raised about whether the Facebook App can tag outbound links like this.<\/p>\nIntelligent Tracking Prevention 2.3 is very aware of services trying tag links in this manner, and it calls such activities \u201cLink Decoration<\/em>\u201d. Safari\u2019s clever ITP privacy report engine spots this happening, and it will take firmer action with such services abilities to store data\/pass information.<\/p>\nNote: (and I\u2019m guessing here). If I were Facebook, and I were allowed, I would look to STILL pass some form of FBCLID to outbound ad links (in a \u2018Ask Not to Track\u2019 scenario), but not have the ID linked to an individual Facebook user (to preserve privacy); perhaps instead linked to an aggregated\/anonymised bucket of similar, generic users – this can then potentially help give businesses some idea of attribution etc; whilst maintaining the privacy concerns of users.<\/em><\/p>\nServer Side Tracking<\/h2>\n This leads us neatly on to the next topic of server side tracking.<\/p>\n
As we know, The Facebook Pixel (and similar services e.g. Google Analytics) are bits of code (written in Javascript) where are embedded in the web browser served code of your website; this is typically called \u2018client side<\/em>\u2019.<\/p>\nThis code then runs in your web browser and does whatever it needs to do.<\/p>\n
And by now we should have got the message that life is getting considerably tougher for these client-side trackers.<\/p>\n
A big issue of such services is this:<\/p>\n
– They add to the bulk of website, and can be a major performance headache. \n– They can be restricted by third party cookies. \n– They are very much in the firing line of Intelligent Tracking Prevention etc<\/p>\n
So, what\u2019s the alternative?<\/p>\n
The Opposite of \u2018Client Side\u2019?<\/strong><\/p>\nServer-side tracking (whilst not new), turns this on its head.<\/p>\n
In server-side tracking a website actually owns it\u2019s own analytics\/distribution engine. This engine can then process whatever data it needs, and (if needed) pass that data onto other third party services e.g. if The New York times had such a tracking engine, the situation would now look like as follows:<\/p>\n
The New York Times website would load, and there would be a (hopefully) minimal amount of third party, client side tracking there. This code, instead of trying to make connections directly to Facebook, Google etc, would instead send data back to The New York Times\u2019 own data engine.<\/em><\/p>\nThis data engine could then perform whatever pre-processing on that data it was asked to (e.g. stripping out personally identifiable information), and I it could send the data onwards to Facebook, Google etc.<\/em><\/p>\nI appreciate this point is subtle but the key here is that the web browser is no longer doing the heavy lifting here in terms of tracking & passing information to other domains (cross-site scripting). We have offloaded that responsibility to a server. And there are big benefits here:<\/p>\n
1. No need for so much bulky code execution in the browser (big performance win). \n2. Any cookies issued here will be first-party (no third party cookies) \n3. As cookies etc here will be from The New York Times main domain (or a valid subdomain), they will be less likely to fall foul of Safari\u2019s Privacy Report etc.<\/p>\n
Note on point 3: just because this presents a potential, short term way around ITP flagged issues, that does not mean that companies should take advantage of that loophole. The direction of travel of the privacy is clear – businesses need to take steps to get in line with that.<\/em><\/p>\nWe should also talk about \u2018consent<\/em>\u2019 again; server-side does not bypass any obligations here. If you need consent on the client side, you will on the server side – where the code runs is not the issue.<\/p>\nFrom my perspective, server side tracking offers a big win because it makes a website\u2019s code cleaner, and can perhaps help improve the performance profile of a website.<\/p>\n
Let\u2019s now deal with the final topic\u2026.<\/p>\n
Facebook Pixel and their Conversions API<\/h3>\n Facebook\u2019s Conversion API is the method you would use to talk to Facebook by the Server Side Tracking approach we discussed above.<\/p>\n
Facebook are putting more and more development into this as they know that days of the traditional, client-side Facebook Pixel are numbered (esp re cookies).<\/p>\n
The advice Facebook is offering is that businesses began to embrace using their Conversion API, let\u2019s dig into that a bit more\u2026.<\/p>\n
Conversions API, how can it help?<\/strong><\/p>\nTraditionally, Facebook\u2019s Pixel plugin for WordPress did not mention much about the Conversions API as it didn\u2019t need to. However, now that they are embracing the changing landscape, you\u2019ll notice that there is a setting for it in the 2.3 version of the plugin***.<\/p>\n
This allows you to get serverside Conversions API from your WordPress Facebook Pixel plugin (yes the Facebook Pixel runs on the client side, but the plugin also contains serverside code).<\/p>\n
But what does using Conversions API in the Pixel Plugin achieve?<\/strong><\/p>\nAs of now, unless you are using WooCommerce or any of the Form plugins listed here<\/a>, it won\u2019t do much for you:<\/p>\nWill Facebook add more integrations in the future? Probably. This is a hugely important area, and the situation changes all the time.<\/p>\n
If the Facebook Pixel\/WordPress plugin can\u2019t help you, your options for integrating with the Conversions API are:<\/p>\n
– Write bespoke API programming code (highly useful, but costly) \n– Using the server-side version of Google Tag Manager \n– Use Zapier with their Facebook Conversions integrations<\/p>\n
As should be clear, this whole landscape is under massive development whilst Facebook comes to terms with how things are going to be. So I would be mindful of not doing too much costly bespoke API development until you are sure you really need to,<\/p>\n
\u2026.where this leaves Facebook Pixel users who don\u2019t use those plugins, is anyone\u2019s guess. However, the plugin is under active development, who knows what is coming down the road.<\/p>\n
The javascript version of the Facebook Pixel will still work for now, and will still easily catch single visit\/24hr conversions. However, it loses its strength quickly (due to ITP etc).<\/p>\n
The End<\/h2>\n Apologies for that massive brain dump, I was going to split this into separate articles but in the end, I decided to drop in on you em masse.<\/p>\n
Joel<\/p>\n
Note re v2.3 of the Facebook Pixel for WordPress plugin:<\/strong><\/p>\n\u00a0v2.3 is what currently installs from Facebook\u2019s site when you specify WordPress as an integration partner. If you install that plugin, it will immediately offer you upgrade to v 3.0; which (oddly enough) changes the name of the plugin (no Pixel in title), and completely changes the settings page (i.e. no settings at all, no mention of Conversions API). However, from a test that we did, on an ecommerce site, using only v3.0 (on a WooCommerce site), it DID send Server FB events (even without us creating Conversion API settings, it must have done this automagically).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"In this article we\u2019re going to talk about the privacy impacting changes in iOS14, how this affects apps like Facebook, what implications this has for website tracking, and how it all fits together in the overall […] Read more <\/i><\/a><\/p>\n","protected":false},"author":2,"featured_media":44942,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[165],"tags":[],"acf":[],"yoast_head":"\niOS 14, privacy, Facebook, Pixel, ITP\u2026.and more • Glass Mountains<\/title>\n \n \n \n \n \n \n \n \n \n \n \n \n\t \n\t \n\t \n \n \n \n \n \n\t \n\t \n\t \n