Guest blog by Joe Purnell, web designer & WordPress consultant
This has been big news recently – I’m not talking “news at ten” or anything like that, but if you work in the social media or paid ads world, it’s likely you have heard about increased privacy options as a result of iOS 14. On the surface, this seems like a good move for consumers; after all, you should be able to control how your data is used and transparency is a step in the right direction. But, this will have an impact on small businesses running ads, and there are some things you need to do.
This increased control over how websites and apps track your activity, introduced by iOS 14, will affect the performance of Facebook Ads, because tracking online conversions relies on the Pixel, and the Pixel relies on your device to send data to Facebook. We’re being given greater control over how our devices share data so we’re being given greater control over just what actions we take that ad networks can track.
These upcoming changes to Apple's operating system have highlighted the limitations of a cookie and script based conversion attribution approach. Keep reading to find out what’s happening as far as iOS 14 is concerned, and how else Facebook is making conversion tracking possible.
Disclaimer: the information provided is based on my own conclusions from sources currently available to us. I cannot guarantee 100% accuracy due to regularly changing information and accept no liability for any damages incurred as a result of acting solely using this advice.
What exactly is happening with iOS 14?
At this moment in time, we don’t have all the answers. We know that iOS 14 will cause users to start being explicitly asked for their consent as far as cross-site tracking is concerned and that there have been reports of these prompts already starting to appear.
Users will start to be asked whether or not they are happy for specific allow apps to track their activity across third-party apps and websites. This isn’t just tapping “Okay” with a vague notion that you can change your settings in-app, this is a standardised framework that app developers must adopt and comply with. And this includes Facebook.
This is a big change for ad providers because cross-site and cross-app tracking is how events can not only be recorded but assigned to a user and made available for retargeting too.
A sample prompt reported by 9to5mac.com
When is this all happening?
A screenshot posted on the MacRumours forum in December 2020 shows a prompt appearing in the beta of iOS 14.4, due for release in the first quarter of 2021. This prompt is part of Apple’s new AppTrackingTransparency framework.
However, while this leads to speculation that the release of this update may be the “deadline” for app developers to ensure they are compliant with the new explicit “opt-in” system, apps have been able to offer this greater control of privacy since the release of iOS 14 in September. It just hasn’t been a requirement yet.
Facebook will have to become compliant with these “opt-in” prompts, meaning that it is highly likely the Facebook Pixel will not be able to execute on devices running iOS 14 if users do not consent.
To understand the limitations of the Pixel, let’s take a look at how it works
The Facebook Pixel is a browser-side tracking tag that allows your device to send data to Facebook.
Techy bit – in depth: The Pixel is run in one of two ways: either a Javascript file is included in the website’s code to allow actions to be taken, or a 1×1 pixel invisible image from Facebook’s servers is included on a website to allow for tracking.
When the Pixel executes on a web page, Facebook is able to create and access cookies stored on your device. These cookies are used as an identifier so that Facebook knows it is *you* that is triggering events on a website. When it was first introduced, the Pixel worked using just third-party cookies but now uses a combination of both third-party and first-party cookies to attribute conversion events a Facebook user.
Safari on iOS has actually been blocking third-party cookies (a traditional way of tracking users across the internet) for a couple of years now. Facebook was forced to adapt to more and more browsers blocking this method of tracking, and they rolled out an update to the Pixel adding first-party cookies too. Instead of third-party cookies which are set by a site different to the one you are browsing, first-party cookies in this case are set by the website you are on – as long as the Pixel is installed, and if the Pixel is allowed to run.
How do these first-party cookies work?
When you first visit a website that uses the Pixel, the website sets a first-party cookie on your device containing a unique identifier used to identify you as a user. This is the “fbp” cookie.
When you click on a Facebook Ad and the website you are sent to uses the Pixel, the website also sets another first-party cookie on your device containing a click ID. This cookie, the “fbc” cookie, is used to attribute conversion events to a specific ad.
Are there any limitations with using this approach, even if the cookies used are set by the website you are browsing?
Even though most browsers do not block first-party cookies by default (because they can power essential elements of a website), the setting of these cookies depends entirely on your browser allowing the Pixel code to run – and this can be an issue.
It is estimated that, in the US, currently 27% of internet users have an AdBlocker installed in their browser. Many popular ad blockers will stop the Pixel code from executing, meaning that events and conversion data cannot be sent back to Facebook.
Looking at how exactly iOS 14, in particular, will make an impact, it isn’t completely clear how the use of the explicit “opt-in” prompt, and AppTrackingTransparency, will prevent browser-side tracking. It may be that Facebook simply prevents the Pixel from executing for those that opt-out or Apple may implement a block at device level if consent is not given.
Without the Pixel being able to execute, it cannot create cookies or send event data back to Facebook. This means that users that opt-out will not be available for use in a Custom Audience (because the events they trigger can not be shared), but also that events triggered by these users cannot be attributed as they are never recorded by Facebook.
Is there a workaround to the Pixel being blocked? Introducing the Conversions API…
Yes, there is another way to send events. But there is a potential limitation too that you need to be aware of.
In 2020, Facebook relaunched their Server-To-Server API as the new Conversions API. Put simply, the Conversions API allows your web server to send data from your website about conversions directly to Facebook, without involving the user’s browser.
Conversions API (CAPI for short) is described by Facebook as allowing you to:
- Measure customer actions in more ways. For example, you can share delayed values, user scores or lead scores and use them for optimisation in our other business tools. This gives you visibility into your customer's full journey.
- Improve accuracy of events sent for measurement and optimisation when used along with the pixel. When you use Conversions API, you don't have to worry about events getting lost because of problems such as a browser crash or an ad blocker.
- Control the data you share. Conversions API gives you control over what to share and when to share it.
Source: facebook.com
One of the key messages from that is “you don't have to worry about events getting lost because of problems such as a browser crash or an ad blocker”. Because CAPI sends events server-side, and not from a user’s web browser, conversion data sent to Facebook is not affected by ad blockers and cookie blockers.
CAPI allows for the full suite of conversion events to be sent, and Facebook is able to detect duplicate events (those sent via both the traditional Pixel and the Conversions API) and “de-duplicate” them to stop overreporting.
CAPI can be integrated easily with e-commerce platforms such as WooCommerce and Shopify to act as a fallback for when browser events do not fire. Additional parameters (such a purchase values and items purchased) can also be sent via CAPI.
There is definitely potential with the Conversions API, but the main issue lies with attribution because it is harder to match an event to a Facebook user without cookies having a part to play. And Apple do have the power to request Facebook disable support for the Conversions API for those that have opted out via AppTrackingTransparency, but it is not clear yet whether or not this is something that Facebook will be forced to do. Either way, setting up CAPI can be beneficial to your business because it allows you to capture some of the missing event data that is lost by browser-based cookie and ad blockers, which can be used for better ad targeting – and it’s not just iOS14 that has an effect on the Pixel as I’ve said, it’s up to 27% of people whose browsers block cookies and tracking tags.
So how else can CAPI attribute events if cookies can’t be used?
The Facebook Conversions API can match events to users by sending the below User Data Keys. These Keys are likely to be stored against a user’s profile by Facebook to allow them to be matched.
- Email – hashed,
- Phone – hashed,
- Last Name – hashed,
- First Name – hashed,
- Town/City – hashed,
- County/Region – hashed,
- Postcode – hashed,
- Country – hashed,
- Browser ID – this is the “fbp” cookie mentioned above – harder for CAPI to send this data as it would likely have needed to have been created by a Pixel in the first place,
- Click ID – this is the “fbc” cookie mentioned above – harder for CAPI to send this data as it would likely have needed to have been created by a Pixel in the first place,
- IP Address,
- User Agent – a piece of data about the browser you are using, the technologies used to power it and the version number of these included software libraries
What does “hashing” mean?
A hashed User Data Key means that this piece of data has been encrypted (using SHA-256) before being sent. This effectively scrambles the data into something that cannot be decoded, instead it can only be used to match against an identical value already held by Facebook, if one exists.
Once sent via CAPI, this hashed value is then received by Facebook, and they attempt to match it with an existing hashed value in their database which would be linked to a user.
This way, Facebook can identify users that triggered certain events and can attribute these to them without “seeing” raw pieces of personal information. Facebook says: “After matching, we promptly discard the hashed information.”
However, while these values can only be used for matching, and cannot decoded by anyone, the process of “Advanced Matching” does allow Facebook themselves to identify a user, so you need to ensure your privacy policy makes this fact clear.
Is this data always available for CAPI to use?
Not all conversion events will be able to send Facebook these User Data keys for matching because the website simply doesn’t have the data available. Some of these Keys are also more powerful than others because they are more likely to return a unique user match.
For example, while your IP address could be used to match your events on a website and your use of Facebook, you may have many different people in your household using the internet who would all report the same IP address.
CAPI is definitely part of the future of conversion tracking, but it is only as good as the data you have available.
If you have CAPI enabled, you can see the “Event Match Quality” in Events Manager. This gives you a score out of 10 highlighting how effectively events sent by CAPI can be matchd to Facebook users, based on the User Event Keys your website is sending.
Some Pixel events will be limited in terms of the data that is available to be sent, due to the nature of that specific action (e.g. PageView for a first-time visitor), and some will have a large amount of data available for matching for the same reason (e.g. Purchase as the user has just submitted a checkout form).
Here’s a breakdown of how the Facebook standard events can potentially be matched via CAPI, and how effective this can be:
It’s important to note that, while the example User Event Keys below will likely be received by the website at the point of triggering an event, it may not always be possible for your website to send this data via CAPI, due to how the data is captured and stored. Every website is configured differently, so I would recommend speaking to your developer to see what could be available for your specific scenario.
Scroll side-to-side to see the full table!
| Website action / Pixel event | User Event Keys potentially available for CAPI to send | How easily can this event be matched to a Facebook user? |
| Add payment info | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) · Postcode – a credit card entry form would likely collect this, but it would be unlikely that this could be shared outside of this function A logged in user would also make some of the following Keys potentially available: · First Name · Last Name · Phone |
With only the basic Keys available, event matching is very limited.
If a user is logged in, and other more effective hashed Keys could be sent, the potential for event matching would increase. |
| Add to cart | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) A logged in/registered user would also make the following Keys potentially available: · First Name · Last Name · Phone · All Keys related to their address |
Many users adding products to their cart are first-time customers without an account, so the data that can be sent via CAPI for matching is very limited. Here is where the traditional Pixel is currently more effective.
If a user is logged in, their name and email would likely become available to increase the event match quality. If they have made a purchase and your e-commerce platform has linked their address to their account, the event match quality would also be increased as these additional User Event Keys can potentially be sent. |
| Add to wishlist | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) A logged in/registered user would also make the following Keys potentially available: · First Name · Last Name · Phone · All Keys related to their address |
If your website allows you to create wishlists without being logged in, the data that can be sent via CAPI is very limited.
If a user is logged in, their name and email would likely become available to increase the event match quality. If they have made a purchase and your e-commerce platform has linked their address to their account, this would also potentially be available for sending, meaning the event match quality would also be increased. |
| Complete registration | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to register, the user will have had to provide some of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone · All Keys related to their address |
Due to the nature of a registration form, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking. |
| Contact | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to submit an enquiry, the user will have had to provide some of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone |
Due to the nature of a contact form, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking. |
| Customise product | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) A logged in/registered user would also make the following Keys potentially available: · First Name · Last Name · Phone · All Keys related to their address |
Many users customising/configuring products are first-time customers without an account, so the data that can be sent via CAPI is limited. Here is where the traditional Pixel is more effective.
If a user is logged in, their name and email would likely become available to increase the event match quality. If they have made a purchase and your e-commerce platform has linked their address to their account, the event match quality would also be increased as these additional User Event Keys can potentially be sent. |
| Donate | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) Making a donation would usually require most of the following information from the user, which could potentially be sent via CAPI: · First Name · Last Name · Phone · Postcode · All other Keys related to their address – not always as common |
As your website collects data that is more likely to be unique when someone makes a donation, the event match quality is likely to be higher. |
| Find location | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) If a user is logged in, the website would likely have the following data about them, which could potentially be sent via CAPI: · First Name · Last Name |
Most people will not be logged in when this action is taken, meaning that the event match quality is likely to be low. |
| Initiate checkout | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) A logged in/registered user would also make the following Keys potentially available: · First Name · Last Name · Phone · All Keys related to their address |
Many users checking out are first-time customers without an account or those checking out as a guest, so the data that can be sent via CAPI for matching is limited. Here is where the traditional Pixel is currently more effective.
However, it would technically be possible for a website to pass the data back to the server if someone fills out checkout fields, which could then be sent via CAPI. If a user visits the checkout page and does not enter any information before leaving, then the event match quality would be low due to the lack of unique data available for CAPI to send. If a user is logged in, their name and email would likely become available to increase the event match quality. If they have made a purchase and your e-commerce platform has linked their address to their account, the event match quality would also be increased as these additional User Event Keys can be sent. |
| Lead | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to submit a “lead”, the user will likely have had to provide some of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone · All Keys related to their address – dependant on the form |
Due to the nature of someone “sending a lead”, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking. |
| Purchase | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to make a purchase, the user will likely have had to provide most if not all of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone · All Keys related to their address – unless it’s a digital download |
Due to the nature of someone making a purchase, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking.
A checkout form collects the most data out of the standard Pixel e-commerce events (with the possible exception of CompleteRegistration), meaning that this event is likely to give you the highest event match quality. |
| Schedule | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to schedule a booking, the user will likely have had to provide most if not all of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone |
Due to the nature of someone scheduling a booking, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking. |
| Search | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) If a user is logged in, the website would likely have the following data about them, which could potentially be sent via CAPI: · First Name · Last Name |
Most people will not be logged in when this action is taken, meaning that the event match quality is likely to be low. |
| Start trial | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to start a free trial, the user will have had to provide some of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone |
Due to the nature of someone starting a trial (and likely creating an account in the process), the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking.
If the user is already logged in to an account prior to starting the trial, this data will already be held by the website and therefore potentially available to be sent via CAPI. This would also likely mean a higher event match quality. |
| Submit application | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to submit an application, the user will have had to provide some of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone · All Keys related to their address |
Due to the nature of an application form, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking.
If the user is already logged in to an account prior to submitting the application, this data will already be held by the website and therefore potentially available to be sent via CAPI. This would also likely mean a higher event match quality. |
| Subscribe | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) In order to start a subscription, the user will likely have had to provide most if not all of the following info which CAPI can potentially send for event matching: · First Name · Last Name · Phone · All Keys related to their address – unless it’s a purely digital subscription |
Due to the nature of someone subscribing, the event match quality would likely be higher as the user is submitting data that is likely to be unique at the point of tracking. |
| View content / Page View | · IP Address
· User Agent · Browser ID (if cookie not blocked) · Click ID (if cookie not blocked) A logged in/registered user would also make some of the following Keys potentially available: · First Name · Last Name · Phone · All Keys related to their address |
Many users viewing a page are first-time browsers without an account, so the data that can be sent via CAPI for matching is very limited. Here is where the traditional Pixel is currently more effective.
If a user is logged in, their name and email would likely become available to increase the event match quality. If they have made a purchase and your e-commerce platform has linked their address to their account, the event match quality would also be increased as these additional User Event Keys can potentially be sent. |
So where does that leave us?
Well, as you can see, CAPI and Facebook’s “advanced matching” technology can certainly be powerful *if* the right data is available. Attributing Purchase, Lead, CompleteRegistration, Contact and other similar events will be much easier as data that is more likely to be unique is collected at the point of the event being triggered (providing your website can be configured to send this data via CAPI).
However, the events that will not perform as well as far as matching and attribution is concerned are: PageView, ViewContent, AddToCart, AddToWishlist and InitiateCheckout – unless the user is logged in to an account at the point of triggering these events.
Retargeting things such as abandoned baskets are going to be harder if users opt-out of tracking and only the Conversions API is available to send data. However, looking at the example of iOS 14, it is not clear yet how the Pixel will be affected when events are triggered on a page this has been loaded in Facebook’s “in-app” browser – these events could potentially be affected less (as Facebook is not tracking them “outside of the app”), but it has not be confirmed that this will be the case either.
Apart from the issues surrounding the Pixel, what else do I need to know about the iOS14 changes?
Facebook are altering things such as the ad attribution window (decreasing to 7 days), the number of events you can track (to be limited to 8) and when events are actually being attributed (the day the event is triggered, not the day you click on an ad).
What should I do then as far as iOS 14 is concerned?
- If you haven’t already, enable the Conversions API and turn on Advanced Matching in your Facebook Ad account. Ensure your privacy policy highlights the use of sending hashed data to Facebook for the purposes of matching, in order to support your advertising campaigns.
- Verify your domain with Facebook – as far as we are aware, verifying your domain will be crucial when it comes to allowing you to perform certain operations in the future such as choosing the 8 priority events you want to track.
- …sit back and wait! It’s not ideal but, while there are certain actions you can take that are likely to help reduce the effect of the iOS 14 changes, it is a matter of waiting to see just how much (or little) of an effect this has on Facebook.
If you’ve got this far, congratulations! There is a lot to understand about how the Conversions API works, but it is important to recognise its advantages while also being aware of its limitations.
Looking for help with your Facebook Pixel, Catalogue or setting up the Conversions API?
Hi, I’m Joe – a WordPress consultant and web designer. If you are looking for someone to handle the finer techy details, click below to drop me a line and see how we can work together.
