Facebook Conversions API (CAPI): A Better Version of the Pixel

What if I told you that you can optimize your Facebook Shopping campaigns not for leads, but for redemptions? Run campaigns on gambling without adj, and still optimize for deposits? Or, let’s say, optimize for regs in crypto, even in those affiliate network for which you cannot install a pixel on the broker’s website? Interesting? Read on.

All the situations described above are possible to implement today thanks to one single thing on Facebook —Conversions API!

And today we will look in detail at what kind of beast this is, and how to configure all the necessary technical components to make the above a reality.

First, a little about the pixel. So, with a normal pixel setup, we must push a piece of javascript code onto landing page, where the user performs the target action. This method has a couple of fatal flaws:

1. First, we must have access to the landing page. That is: either we download it from affiliate network and host it somewhere at home, or we transfer the pixel id to affiliate network and affiliate network “shows” it on the landing page. Not in all verticals, they will let us do it. In the same crypt or binary, it may often turn out that it is simply impossible to send a pixel to the broker’s website (not to mention downloading this site for yourself, because card processing takes place there).
2. The pixel does not fire at the level of the funnel that we would like. Sometimes this happens because of the first point, and we have to put a pixel on ourselves in order to optimize at least for those users who went from it to the broker’s website, and only if they register and deposit — God only knows! In the product, we put a pixel on the Lead event and wait for approval, without being able to optimize for those who confirm the order.

Now let’s look at what the Conversions API is and how we can use it to solve these problems. Essentially, this is an API that allows us to send from our serveranyevents to the selected Facebook pixel. Here is the main method:

https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events?access_token={TOKEN}

The idea is this: having receivedpostbackfrom affiliate network that the user performed the target action (rega, deposit, approved lead), send a notification about this event to Facebook! In this case, we don’t need a pixel on our proclamation landing pages at all!

“But wait, Yellow, how will Facebook understand which user performed the target action?” — you ask. To answer this question we need to look intoparameters that are passed to the main api methodand also to the link we are using.

If we take a closer look at the link of our advertisement published on Facebook, we will see that at the end of almost any (but not every!) such link Facebook adds its own additional parameterfbclid.

The pixel code on landing pagee stores the value of this parameter in a cookie, and then sends it along with pixel events like Lead and Purchase. This is how Facebook determines what kind of user clicked on the landing page. We will save the value of this parameter in thetracker, so that you can then send it via the Conversions API.

Remark:Yes, Facebook can identify a user by other parameters such as soap, phone and name, and if you don’t get fbclid or you can’t get the fbc cookie value, then you can try them, but the description of working with these parameters is beyond the scope of this manual, read the docs, everything is described there!

So, the following general scheme of work emerges:

1. Special software saves all access_tokens and pixel ids somewhere in its database in order to be able to call Conversions API methods. This could be software for uploading, which saves this information automatically when uploading, or simply a separate application with a web interface, into which you manually add a bunch of id pixels — a Facebook token (and probably cookies, if the token is from Ads Manager).
2. When a user follows a link from an ad to us intracker, Thattrackerassigns a unique subid to the click. After which it extracts the pixel id from the link (we, of course, need it for thisadd to the link when setting up an ad) and the Facebook parameter fbclid and stores in its database the correspondence: subid — pixelid — fbclid.
3. The user performs the target action, after which affiliate network is sent to ustrackera postback in which the lead’s subid and its status are written, let’s say this will be the sale status in the product.
4. Trackersame inin turn sends an S2S postbackback to us in the software from point 1. In this postback the following information is sent: fbclid — pixelid — lead status
5. The software receives this postback, looks in its database which token is needed for the received pixel and sends all the necessary information to the Conversions API: pixelid — token — fbclid — the required pixel event.

After the CAPI call occurs, you can track whether it went through or not on Facebook in Events Manager:

I foresee a question: how to save fbclid intracker? Let’s look at Keitaro as an example. We go to Sources, there we either create or edit a Facebook source. And we add this notorious fbclid to the parameters. In the screenshot below, I added it to the sub-tag number 13 — sub_id_13.

All! Now, when we send an S2S postback, we can write the macro {sub_id_13} in it and it will be replaced with the value of the saved fbclid.

That’s all, I hope the description of the circuit was complete enough for you to set it all up and program it!

I would also like to draw your attention to the fact that if you use Keitaro trackers orBinom, Youyou can use a ready-made solutionfrom your humble servant. More than four dozen teams are already working with it and have no problems with tracking on Facebook at all!

And there will be questions —welcome for a consultation. Pour into the plus, gentlemen!