Facebook is pushing its advertising customers more and more to use the in-house Facebook Conversion API (CAPI). But why? And what is the FB Conversion API anyway? And what options are there to use them? That's what this post is about.
What is the Facebook Conversion API?
Our Knowledge Base article clarifies this question:
https://tracking-garden.com/knowledge/facebook/conversion-api/
There you can also read what options there are to use FB CAPI.
Is there a time limit to start using the FB CAPI?
We heard statements that the Facebook Conversion API (CAPI) should be implemented by June 2021. However, we have not yet been able to find any verifiable information on this - verifiable information is very welcome.
Nevertheless, the FB CAPI should be implemented as quickly as possible, see the next section.
Why the FB CAPI should be implemented as soon as possible
Ad banner and tracking blockers as well as browser restrictions for tracking pixels are increasingly blocking client-side tracking solutions. This proportion is now 5-30% (depending on the website) and the trend is rising.
The Facebook Conversion API tracks (if implemented correctly) the required events and information on the server side. This means that if tracking is blocked in the client (the browser), this has no effect on server-side tracking - it is technically not possible to prevent server-side tracking using a browser. If at all, this (or the evaluation of the tracked data) can only be made more difficult, e.g. by making it more difficult to assign related page views to a session.
Since various measures on the part of browser providers make it increasingly difficult to collect reliable data, client-side Facebook tracking pixels should be supplemented (or replaced) by server-side solutions using FB CAPI as soon as possible.
Does FB CAPI solve the iOS 14.5 tracking restrictions?
No (or only theoretically).
Since iOS 14.5, iOS apps have to include a consent dialog if user data is to be tracked. All apps that are offered in Apple's app store have to ask the user for an allowance to track (theoretically also all browsers except Safari).
Now websites (and parts of apps) are loaded live from web servers. Apple cannot prevent this request to the web server and therefore cannot prevent all technically necessary information that is sent with this request. This means that on the web server side, events can be sent to Facebook that Apple cannot prevent.
However, we have to comply with the respective data privacy requirements. So if the user has refused (in Apple's consent dialog or somehow else) to transfer tracking data to Facebook, we are not allowed to do that either. At least no personal data may then be sent or data that allow information on the identity of the user (see next chapter).
Another limitation comes from Facebook itself:
The click conversion time window has been limited since the beginning of 2021 and only a maximum of 8 different events can be tracked. For more information see here:
https://tracking-garden.com/blog/2021/facebooks-tracking-limits/
Use without consent in the (cookie) consent banner
As already mentioned in the previous chapter, no personal data may be tracked without user consent and also no data that allow information about the identity of the visitor. Cookies (or similar technologies) that are not technically necessary and/or are not based on any other legal basis (than user consent) may then not be used - this also applies to the data to be “tracked”.
These legal bases (which also include user consent) are subject to the applicable data protection regulations. Here in Europe, it is important to distinguish whether you collect (e.g. statistical) data for yourself (i.e. no third parties have access to it) or whether this data is shared with third parties (e.g. Facebook). If the third party is a company outside the EU with which there is no “data protection agreement”, there is an increased risk (see Schrems II) - this is the case, for example, with all US companies (including Facebook).
The biggest problem with the client-side tracking pixels at the moment is that (for technical reasons) the IP address is transmitted to the respective server. The IP address is personal data because it allows conclusions to be drawn about the identity of the visitor. Therefore a transfer of the IP address (and all other personal data) to third parties without a “data protection agreement” should be avoided. This excludes a direct client-side tracking implementation like that of the Facebook Pixel. At least if there is no user consent. And even then this (see Schrems II) can be a data protection violation.
On the server side, care must therefore be taken that no personal data is transmitted - i.e. also no IP address. According to various statements, anonymizing the IP address is not sufficient either. There is also a need for clarification for IPv6 addresses. The transmission of the IP address (also anonymized) should therefore be avoided if possible.
In summary, without user consent, no user data should be transmitted to Facebook.
General recommendation for using the FB CAPI
A specific recommendation for action depends on the status (and budget) of the Facebook campaigns. If these play a subordinate role in the marketing mix, everything can (initially) remain unchanged. The statement that there is an obligation to use the Facebook Conversion API can be seriously questioned. After all, Facebook also sees the FB CAPI as a supplement to the Facebook Pixel, i.e. not as a complete replacement. You should plan for the use of the Conversion API in the medium term, at least if you want to continue to have a reasonably reliable evaluation of the campaigns.
If your own economic success (partly) also depends on the success of the Facebook campaigns, you should plan to use the Facebook Conversion API as soon as possible. Which variant can be found in our Knowledge Base Article.