It has been a while since Meta released the Conversions API (CAPI) and almost every blog post out there is going to tell you that, besides capturing conversions through CAPI (server side), you still have to implement the Meta Conversions pixel on the browser. Why?
“Why” is indeed the very first question we should ask ourselves - why two ways of tracking conversions? Does CAPI + Meta Pixel implementations workaround the Safari restrictions on cookies imposed by Apple? Why if my implementation is full server side? If you care about the quality of your data, I’d advise you to keep reading.
Why two ways of tracking conversions?
A very valid question. Official information states that “If you use the Conversions API to send website events, best practice is to also use the pixel to help maximize the effectiveness of your website events” and “the Conversions API are linked to your pixel”.
Behind those generic statements there is the real truth, and it’s no other than Meta is still using cookies to recognize unidentified users or assign them a unique Id. The main reason why Meta is asking to implement the Meta pixel on top of the CAPI it's because they need a unique Id generated in the browser to assign conversions to.
Does Meta CAPI in conjunction with Meta Pixel create a workaround for the Safari restrictions on cookies imposed by Apple?
No, it does not, and make no mistake, Safari still represents 18% of the internet browser market so it’s not something to be taken lightly.
The next logical question to ask would be - if it doesn’t, why is Meta asking to also implement CAPI in the first place? Simple, to record conversions that otherwise would be blocked by AdBlockers.
It’s clear that CAPI, being a server side technology, works around AdBlockers so it collects all the conversions but, to whom are those conversions attributed for users that browse through Safari browsers? Good question!
Here you can find a very detailed explanation but to summarize, cookies created by the Meta pixel in Safari will either expire in 24 hours or at best in 7 days. So what does that mean for us? It basically means that every 24h/7days the conversions are attributed to a new user.
The whole point of tracking is to attribute actions (purchase, page views, lead forms etc) to the same user regardless of time length between touch points. A user may land on your website through a Meta Ad and buy a product of yours in two days, shouldn’t Meta get credit for that (attribution models aside)?
Well, my guess is that it should. Can we overcome that? Give me 3 minutes more of your time 🙂
Why if my implementation is full server side?
Regardless of your tag implementation strategy, whether being fully or partially server side, you can completely avoid the Meta pixel implementation. Confused based on information you’ve read elsewhere?
Well, Meta pixel creates a couple of cookies, the combination of these cookies helps Meta to uniquely identify a user. But remember, Safari will normally delete these cookies in 24 hours (7 days at best). So then that asks the question, how do we overcome that?
Cookies created from the server are not binded to the aforementioned expiration times and actually, those Meta cookies can be transformed to server side, thus avoiding their expiration (or indeed set a more common lookback window such as 30 days). This in turn, enables us to properly attribute conversions to the same user regardless of time length during different touchpoints.
Remember, it is not just about collecting conversions, it is also about attributing these to the right users.
If you want to properly understand the returns of your investment efforts on Meta Ads, get accurate attribution and make smarter media buying decisions, get in touch with us, we will help you all the way.