iOS 14, privacy, Facebook, Pixel, ITP….and more

In this article we’re 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 jigsaw puzzle of online privacy.

I focus a bit on Facebook (and their Conversions API) as that is on my mind at the moment, but the issues Facebook faces are common across many service providers.

There are some aspects we still don’t know much about, I’ll try to make that clear where that is the case, and I may well come back and update this article as time reveals further nuggets.

Before I begin, I’d like to Craig Francis, who’s technical input here has been invaluable.


A few notes before we start….

This article (as most are on this blog) is aimed at people and businesses who have an active interest in their company’s WordPress website – you are not anticipated to be developers or technicians; so the tone of this article is pitched accordingly.

The article is not meant to be a definitive guide to all technologies mentioned here; it’s more about providing an introduction and overview.

I play fast and loose a little with how Facebook works – this isn’t a manual for advertising on Facebook (for that, go to Jon Loomer); I’m just trying to get across the general concepts; especially as they apply to WordPress websites (in light of iOS* 14 etc).

(*iOS is the name of the operating system on Apple’s iPhone range).

Some aspects of this article are more technical than others (especially towards the end). You may want to read those bits more than once, or you may choose to gloss over them – either way, that’s completely fine.

Ok, now we’ve got that out of the way, let’s get started….

Privacy? Tracking? What’s the problem?

The web has been a bit of a West West for years. With websites being able to plug in all manner of things that go on to perform all manner of invisible tracking.

You might wonder what I mean by ‘invisible tracking’?

Well, have you ever wondering how adverts just seem to ‘follow’ you around the Internet? You view tennis rackets on Amazon or Facebook, and you just seem to see adverts for more tennis rackets everywhere? Funnily enough, that is not by accident; that is by design.

Me and my shadow

You could argue that adverts that follow you around is quite a helpful concept: you’ve expressed an interest in tennis rackets, people don’t always purchase on their first visit, so by reminding them that they were interested in buying them, the advertiser increases the likelihood that they’ll be able to convert someone who has viewed tennis rackets, into buyers.

However, the issue here is how such companies are able to show these ads, and how they are able to track you around the web. And whether that is transparency & ethical.

Evolving Landscape

The online privacy landscape has been slowly evolving over the last couple of years. You may well have heard of cookies (more on those later), you may have heard of ad blockers, and, unless you’ve been living under a rock, you will have more than probably heard of GDPR (or even perhaps California’s CCPA).

Without going into too much detail on all those individual topics, I would say that the general direction of travel for online privacy can be broadly summarised as this – Websites & businesses need to:

  • Be much clearer as to what data they are collecting & storing on us (and why)
  • Be aware that just because they want to store certain data, doesn’t mean they have the right to.
  • Explicitly ask for us consent when looking to track, or store our data (rather than just assuming it is ok)

The consent aspect from the last point is critical.

The web & privacy laws are evolving to where our rights are more protected. And where we must give consent (in many cases) before businesses use our data.

Put another way: instead of businesses considering personal information as a precious metal like gold or platinum, they are better off thinking of it as a radioactive isotope; potentially very useful, but also highly dangerous and only to be used when strictly necessary (and then disposed of responsibly).

Consent Exhibit A

Here is an example of a cookie banner:

Fig 1 - a simple cookie banner

Fig 1 – a simple cookie banner

In truth, I don’t think many cookie banners mean much to your average website visitor, and I think we are going to see a lot more clarity about how they are implemented, worded, and handled going forward.

However, the key point here is that we are already seeing, on our journeys around the Internet, how websites are trying to surface ‘consent’; trying to actively engage with their audience instead of simply assuming they can do whatever they want with website visitors data.


Apple has taken privacy to heart and has decided to tackle this issue head-on. Irrespective of their potential motivations for doing this, Apple is a huge player, and what they do needs to be paid attention to.

It is also many people’s opinion that Apple is leading the way here – indicating the general direction of travel that industry is heading.

……but what are Apple actually concerned about?

Pretty much what we’ve talked about above: the ability of websites/apps to track you, and to store information about you. They are looking to shine light on those invisible tracking areas, and to give you more control over consent.

Let’s try and make this a little more concrete; consider this scenario.

  1. You have an iPhone
  2. You have the Facebook App on your phone
  3. You have another app on your phone. A game called “Joel’s Banana Challenge

(Yes I just made up that game, it doesn’t exist*. No, I have no idea what you might do in that game – eat lots of bananas?).

(*Actually there is a game called ‘Banana Challenge’, what a world!)

Let’s imagine that “Joel’s Banana Challenge” game is free, but it also shows adverts in the app. The app tries to show targeted ads, which are much more likely to convert than random ones.

And by ‘convert’ we mean:

  1. Someone clicks on an ad in the “Joel’s Banana Challenge” app (let’s say for Tennis Rackets)
  2. They are taken to a website that sells tennis rackets
  3. ….hopefully they then buy a tennis racket (i.e. the click has converted into a sale!)

Let’s explore this scenario a bit more so we can understand what is coming down the line, and why that is important.


Let’s say that the ads displayed in my “Joel’s Banana Challenge” iOS app are handled by Facebook. That way, we (as the game app developer) don’t need to worry anything about serving or targeting ads etc, we can embed some Facebook code and let them deal with the whole shooting match: we worry about the game, they worry about the ads.

Why Facebook? Well, a good reason is that they have over 2.7 billion users.

How does the game show these targeted ads?

When someone launches “Joel’s Banana Challenge”, iOS passes the app an ID which is unique to the smartphone: there is no-one else with that ID.

The app then passes that same ID to Facebook who more than likely is able to tie that to an individual Facebook account. Or if they can’t tie it to a specific Facebook user, perhaps they can tie it to a profile based on what apps that ID uses (or what websites that profile visits). In short: Facebook have rich data here.

From that point on, any app (such as ours) that shows Facebook ads, can show highly targeted ads – based on the huge amount of data that the California based social media giant knows about you. And they know a lot!

Note: I’m talking about Facebook a lot here but I’m not picking on them specifically. They are just a high profile company that does this tracking – there are many others of course. Including Google with their Adsense model.


Let’s expand on the above scenario a little….

We mentioned that someone could click on an ad in our app, and be taken off to a website ( selling tennis rackets).

And if the person bought a tennis racket, we can say that the click has converted.

This is good news as the company selling tennis rackets (who I’m guessing paid to run the ad in the first place), is making money, and better still, they know which of their ads are working.

If they know their ads are working, they’ll be more likely to spend money on future Facebook ads; that makes Facebook happy.

Safari…so goody

When that person clicked on the tennis racket advert in the “Joel’s Banana Challenge” app, it opened up Safari and loaded up the tennis racket website; let’s invent a website and call it

The ad link from my app would open up in Safari looking something like this:

Notice that fbclid={+ crazy long number} bit on the end? We need to talk about that….

The full name for FBCLID is the “Facebook Click ID”. This is basically extra information that Facebook is passing along with the link just for the ride.

Facebook knows a lot about who clicked the ad in the “Joel’s Banana Challenge” game – and they want to know as well. Why? Because if Honest Fred’s website knows who clicked the ad link, then the website can attribute the sale correctly.

Attribution is a key concept.

Attribution joins the dots between someone clicking an ad, and someone buying something because of that ad. Attribution allows Facebook’s ad reporting to tell advertisers what ads are working, and which ones are not. As you may guess, that is worth a lot of money.

The Facebook Pixel?

Let’s delve a little deeper into how the Honest Fred’s website is able to tell Facebook that I bought the tennis racket.

There is a thing called The Facebook Pixel, which is a little bit of code (from & written by Facebook) that sits invisibly on your website. It sends information back to Facebook about how website visitors are using your website (pages visited, time on site etc) – whether they are Facebook users or not.

So, in our scenario, someone clicked on the ad in Joel’s Banana Challenge, and was taken to And let’s say the Facebook Pixel is installed on that website.

Remember the FBCLID we said was passed in via the click link? The Facebook Pixel uses this to tell Facebook who actually visited the site, and whether they bought.

Furthermore, because Facebook can use a concept they call ‘Advanced Matching’ did you know that the Facebook Pixel could use any form data on your website which it thinks is relevant? E.g. got a contact form on your website? Facebook may try and listen to the email and name information on that form – why? Because such information can help them with attribution.

If that is starting to concern you, then you are understanding why the web is becoming much more privacy focussed.


Before we delve too much into what is changing, we’re going to need to recap what cookies are (and why they are important in this context).

Cookies are little pieces of information which your web browser can store on your computer. In many cases cookies are essential to how websites operate (e.g. on an ecommerce website, cookies are used to remember that you have certain items in your shopping basket). However, Cookies have also been used for slightly less honourable activities….

Cookies also have a duration – this is the maximum lifetime a cookie can be stored on your computer. When that duration lapses, the web browser will automatically sweep the cookie into the dustbin.

Note: there are other methods of local storage aside from Cookies; I won’t go into them in this article for the sake of brevity; I’ll just deal with them all under the general heading of ‘Cookies’.

I’m mindful of not melting your mind with too much tech but we’ll need to learn a few more concepts….

Cookies can be first party or third party.

First party cookies are issued by the domain itself. E.g. If I add a tennis racket to my shopping basket on, the website issues a cookie to remember what is in my shopping basket. The cookie is issued by the domain, and this is a first party cookie.

Third party cookies are different….

Remember we said that we can have third party code embedded into our website? Things like the Facebook Pixel?

When the Facebook Pixel invisibly runs on your website, it will pass some details back to (i.e. that I’ve added a product to my shopping basket, or I bought something).

The Facebook Pixel may then add a cookie, and because the Facebook Pixel is owned by/talking to domain (rather than, the cookie is called a third party cookie.

If I go away for a few days, and then come back and visit again, Facebook’s third party cookie will help remember who I am. Again, this is critical for attribution.

Third Party Cookies

Because third party cookies are so synonymous with this invisible tracking, and linked to issues with privacy, they will fall by the wayside as the web carries on down a more privacy-aware road.

Indeed, Apple’s Safari web browser already blocks third party cookies. Firefox takes a firm stance. And Google’s Chrome will soon as well.

So does that mean that Facebook Pixel does not work in Safari and Firefox?

Not quite. The Facebook Pixel code (and many others similar, I’m not just picking on Facebook here), exploited a loophole and have managed to write first party cookies instead.

Oh, so they don’t use third party cookies? So no problem?

No. Problem!

Intelligent Tracking Prevention 2.3

Put simply, Intelligent Tracking Prevention (ITP) is an industry wide effort to help stop people being tracked without their consent when they go to a website. Now there is a lot to ITP, so I’m only going to dive into the bits which serve our story here.

ITP is also clamping down on loopholes like the one we mentioned in the previous section (where the Facebook Pixel was able to write a first party cookie when really they should only be able to write third party ones).

And ITP will clampdown on any further attempts at what it sees as abuses or attempts to circumvent measures put in place to protect user privacy.

What does ITP mean for the Facebook Pixel?

Well, it can mean that ITP clamps down on the cookie duration and says it can only exist for 24 hrs.

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

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.

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.

Let’s next take a look at another feature coming in iOS14


A big change in iOS14 will be the “Do you want to be tracked?” dialog that should pop-up for all apps. It will look something like this:

Fig. 2 - iOS 14 app privacy

Fig. 2 – iOS 14 app privacy

This will appear when you launch most apps on your iOS14 iPhone.

I don’t think I’m 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 ‘Ask App Not to Track’ as who wants to be tracked?

….but what impact does this actually have?

Remember we said that iOS passes a unique ID* to any app it launches? If you click ‘Ask App Not to Track’, 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.

*Well, there are really two tracking IDs (IDFA & IDFV), for the sake of this article, we’ll condense them to one.

Let’s now look at the app scenario we mentioned early in this scenario….

Joel’s Banana Challenge app (on iOS14)

We’ve previously talked about my hypothetical app which runs on iOS14. It’s 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.

Great (or not, depending on your point of view).

Let’s now imagine a user is opening the “Joel’s Banana Challenge” app for the first time on iOS14, and they get hit by that tracking dialog above.

They don’t want to be tracked, so they click NO accordingly.

Now, the app has an issue – as the ID it passes to Facebook is random (well, it’s certainly not 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’ll be much less targeted as Facebook will not be able to reference the encyclopaedic trove of rich profile data it has on the phone’s owner/a Facebook account.

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

The Facebook App

We should also consider that the Facebook app itself will also be hit by this privacy dialog. And what does that mean to Facebook?

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.

However, that is not to say that accepting ‘Ask App Not to Track’ doesn’t have consequences for the Facebook App.

We know that iOS, if instructed, will not pass in the actual iOS ID, so that will cause Facebook issues in terms of knowing about people’s usage of apps (even outside of Facebook’s community – such as whether a user plays on “Joel’s Banana Challenge“).

We 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’s app store. Because compliance is not an option here, if you don’t follow Apple’s rules, you are off the app store – whether you are a company the size of Facebook or not.

Double Whammy

We also have to bear in mind the double whammy of Safari/Webkit privacy changes here.

This following screenshot is taken from my macbook computer but the situation is largely the same with Safari on iOS 14:

Fig. 3 - Privacy Report

Fig. 3 – Privacy Report

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

As you see above, the pop-up says “7 trackers prevented from profiling you.”. But what does this actually mean?

Well, you’ll 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.

The Privacy Reports lists out services which it is concerned about under ‘Trackers on This Page’; you see common services like Google Analytics (Facebook’s Pixel would be there as well, if the NYT site used it).

However, 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:

– Limited access to cookies
– Limited ability to set a more lengthy cookie duration (in many cases, only 24hrs).

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.

FBCLID revisited

Let’s revisit the FBCLID – the unique identifier which Facebook App (etc) appends to outbound links for attribution purposes.

If an iOS14 user has clicked ‘Ask Not to Track’ on (say) the Facebook App, then question marks must be raised about whether the Facebook App can tag outbound links like this.

Intelligent Tracking Prevention 2.3 is very aware of services trying tag links in this manner, and it calls such activities “Link Decoration”. Safari’s clever ITP privacy report engine spots this happening, and it will take firmer action with such services abilities to store data/pass information.

Note: (and I’m 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 ‘Ask Not to Track’ 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.

Server Side Tracking

This leads us neatly on to the next topic of server side tracking.

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 ‘client side’.

This code then runs in your web browser and does whatever it needs to do.

And by now we should have got the message that life is getting considerably tougher for these client-side trackers.

A big issue of such services is this:

– They add to the bulk of website, and can be a major performance headache.
– They can be restricted by third party cookies.
– They are very much in the firing line of Intelligent Tracking Prevention etc

So, what’s the alternative?

The Opposite of ‘Client Side’?

Server-side tracking (whilst not new), turns this on its head.

In server-side tracking a website actually owns it’s 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:

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’ own data engine.

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

I 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:

1. No need for so much bulky code execution in the browser (big performance win).
2. Any cookies issued here will be first-party (no third party cookies)
3. 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’s Privacy Report etc.

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.

We should also talk about ‘consent’ 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.

From my perspective, server side tracking offers a big win because it makes a website’s code cleaner, and can perhaps help improve the performance profile of a website.

Let’s now deal with the final topic….

Facebook Pixel and their Conversions API

Facebook’s Conversion API is the method you would use to talk to Facebook by the Server Side Tracking approach we discussed above.

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

The advice Facebook is offering is that businesses began to embrace using their Conversion API, let’s dig into that a bit more….

Conversions API, how can it help?

Traditionally, Facebook’s Pixel plugin for WordPress did not mention much about the Conversions API as it didn’t need to. However, now that they are embracing the changing landscape, you’ll notice that there is a setting for it in the 2.3 version of the plugin***.

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

But what does using Conversions API in the Pixel Plugin achieve?

As of now, unless you are using WooCommerce or any of the Form plugins listed here, it won’t do much for you:

Will Facebook add more integrations in the future? Probably. This is a hugely important area, and the situation changes all the time.

If the Facebook Pixel/WordPress plugin can’t help you, your options for integrating with the Conversions API are:

– Write bespoke API programming code (highly useful, but costly)
– Using the server-side version of Google Tag Manager
– Use Zapier with their Facebook Conversions integrations

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,

….where this leaves Facebook Pixel users who don’t use those plugins, is anyone’s guess. However, the plugin is under active development, who knows what is coming down the road.

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

The End

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.


Note re v2.3 of the Facebook Pixel for WordPress plugin:

 v2.3 is what currently installs from Facebook’s 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).

No Comments

Leave a Reply