I hope this question is on-topic here, as it’s about the tech side of the Facebook tracking.
Some months ago, Facebook released their Conversions API (CAPI) to make it possible to send them user activity events directly from your servers, instead of sending the events from the client using the classic Facebook pixel.
Supposedly, they released CAPI because the Facebook pixel uses third-party cookies to identify the user, and at some point in 2023 Google Chrome will start blocking third-party cookies. This change should render the client-side Facebook pixel useless, supposedly, or at least that’s what every marketing blog out there says.
The thing is, from what I can see in my browser devtools, the Facebook pixel inserts a cookie named _fbp on a first-party context (and also another one named _fbc if the visitor landed on the website from a Facebook ad). These two cookies are unique to the user and the website. Then, the Facebook pixel attaches the cookie values as query params to the GET request that does to the Facebook servers on every event.
So, if the Facebook pixel is generating and reading these first-party cookies & attaching them as query params on every event, what’s the deal with Conversions API? Supposedly it should solve the problem of third-party cookies blocking, but we’re not using third-party cookies here, and anyway we are attaching the value to the cookie in the URL instead of sending the values in the cookie headers.
I guess I’m misunderstanding something. Any help is much appreciated! Thanks!
2
Answers
It’s not just about first vs third party. Even first-party cookies, if set by JavaScript instead of a secure server, are impacted by Apple’s ITP, which will expire any such cookies after 7 days.
The logic in the question is entirely correct; I think the confusion mostly stems from terminology.
Facebook posts like this one don’t compare third-party cookies with first-party cookies; instead, they compare them to first-party data. This term typically refers to the data customers provide voluntarily, such as emails and phone numbers entered in forms, as well as persistent user identifiers that may be used by the app or a store.
When a pixel tracks an event with JavaScript code, it indeed has access to the current
_fbpcookie, which may be relatable to a paid ad click or it might be from a different device, for example. For instance, if the event tracked is on the thank you page after a purchase, there would often be no personally identifiable information available there.Contrastingly, it’s all available server-side. If a customer has signed up on the website previously, the server would have the original click ID, name, email, and so forth. So in many cases, server-side integration would have a lot more data to attribute the conversion, compared to Pixel tracking.
In other words, it isn’t the type of cookies; it’s the presence of additional data on the server that may be useful to attribute the conversion if the
_fbpcookie is unhelpful.First-party cookies become a limitation in a sense that in the ideal (for ad platforms) world, where cross-domain third-party cookies would’ve always been available and there would be no need for
_fbpfirst-party cookie because the tracking pixel has access to the facebook.com cookies on any website. Third-party cookies like this are still partially available in Chrome (until 2024), but hasn’t been available in Safari for years.Thus, first-party cookies plus a server-side integration is where the industry moved. First-party cookies may be entirely sufficient for a website where customers buy immediately and never return, but for anything else, they’re a serious limitation.
A Conversions API integration that ensures it has access to the original click ID, cookies, personal data, etc. (instead of attempting to proxy the Pixel requests via the first-party domain in the hope that tracking blockers won’t notice, as many do) can make a huge difference in the Ads Manager data.