What if I told you that you could optimize your product campaigns in fb not for leads, but for redemption? Cast campaigns on gembla without prl, and still be optimized for deps? Or, say, optimize for registrations in crypto even in those PPs that can't have a pixel on the broker's site? Interested? Read on.
All of the situations described above are already possible today thanks to a single thing in FB - Conversions API!
And today we'll take a detailed look at what this beast is, and how to set up all the necessary tech components to make the above come true.
First, a little bit about the pixel. So, in a normal pixel setup, we have to shove a piece of javascript code onto the landing page where the user takes the targeted action. This method has a couple of fatal flaws:
- First, we must have access to the feed. That is: either we download it from the PP and host it somewhere, or we pass the pixel id to the PP and the PP already "shows" it on the tape. Not all verticals will let us do this. In the same crypto or binary, it may often turn out that it is not possible to send the pixel to the broker's site (Not to mention downloading this site for yourself, because card processing takes place there).
- The pixel is not triggered at the level of the funnel as we would like it to be. Sometimes this happens because of the first point, and we have to put the pixel on our procles in order to optimize ourselves at least for those users who have moved from it to the broker's site, and God only knows whether they register and deposit! In the marketplace, we put the pixel on the Lead event and wait for the uplift, without being able to optimize ourselves for those who confirm the order.
Теперь рассмотрим, что же такое Conversions API, и как с его помощью мы сможем решить эти проблемы. По сути, это апи, которое позволяет нам со своего сервера слать any events in the selected fb pixel. Here is the basic method:
https://graph.facebook.com/{API_VERSION}/{PIXEL_ID}/events?access_token={TOKEN}
The idea is this: by getting postback from the PP that the user has taken a target action (rega, dept, uplifted lead), send a notification of this event to fb! In this case, we don't need a pixel on our proclamations at all!
"But wait, Yellow, how will fb know which user took the targeted action?" - you ask. To answer that question, we need to look at parameters that are passed to the main method of the api as well as to the link to which we are pouring.
Если мы присмотримся к ссылке нашего рекламного объявления, опубликованного в фб, то мы увидим, что в конце практически любой (но не каждой!) такой ссылки фб дописывает свой дополнительный параметр fbclid.

The pixel code on the landing page stores the value of this parameter in a cookieand then sends it together with the pixel events like Lead and Purchase. This is used by the fb to determine what kind of user went to the lead. We will save the value of this parameter in the tracker, чтобы потом иметь возможность послать его через Conversions API.
Ремарка: да, фб может определять пользователя и по другим параметрам типа мыла, телефона и имени, и если у вас не ловится fbclid или вы не можете вынуть значение fbc-куки, то можно попробовать их, но описание работы с данными параметрами выходит за рамки этого мануала, читайте доки, там всё описано!
So, the following general scheme of work emerges:
- Специальный софт сохраняет где-то у себя в БД всё access_token-ы и id пикселей для того чтобы иметь возможность вызывать методы Conversions API. Это может быть софт для залива, который сохраняет эту инфу автоматом при заливе или просто отдельное приложение с веб-интерфейсом, в которое вы сами руками добавляете связку id-пикселя — токен фб (и, вероятно, куки, если токен от Ads Manager).
- When a user clicks on a link from an ad to us at trackerthen tracker assigns a unique subid to the click. Then it extracts the pixel id from the link (we need it, of course, for this add to the link when setting up the ad) and fbclid parameter and stores the following correspondence in its database: subid - pixelid - fbclid.
- The user performs the target action, after which the PP sends us the tracker Postback, which writes the subid of the lead and its status, let's say it will be the status of sale (sale) in the product.
- Трекер же в in turn sends an S2S postback back to us in the software from point 1. This postback sends the following information: fbclid - pixelid - lead status
- Софт принимает этот постбэк, смотрит у себя в базе, какой для полученного пикселя нужен токен и шлёт в Conversions API всю нужную инфу: pixelid — token — fbclid — нужное событие пикселя.
После того, как произойдёт вызов CAPI вы сможете отследить, прошёл он или нет в фб в Events Manager:

Предвижу вопрос: как сохранять fbclid в tracker? Разберём на примере Кейтаро. Заходим в Источники, там либо создаём либо редактируем источник Facebook. И в параметры добавляем этот пресловутый fbclid. На скрине ниже я его добавил в суб-метку под номером 13 — sub_id_13.

That's it! Now, when we send the S2S postback, we can write the {sub_id_13} macro in it and it will be replaced by the value of the saved fbclid.
That's all, I hope the circuit description was complete enough for you to configure and program it all! And if you have any questions, welcome to a consultation.
Лейте в плюс, господа!