Server Side API - the best version of pixel fb!

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 - Server Side 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:

1. 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).
2. 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.

Now let's see what the Server Side API is, and how we can use it to solve these problems. Basically, it's an API that allows us to send from our server 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.

If we look closely at the link of our ad published in FB, we see that at the end of almost any (but far from every!) such link FB adds its own additional parameter 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 trackerto then be able to send it via the Server Side API.

Remark: yes, fb can identify the user and other parameters such as soap, phone and name, and if you do not catch fbclid or you can not take out the value of fbc-cookie, you can try them, but the description of working with these parameters is beyond the scope of this manual, read the docks, there all described!

So, the following general scheme of work emerges:

1. Special software saves all access_token and pixel id somewhere in the database in order to be able to call Server Side API. This can be a software for uploading, which saves this information automatically when uploading or just a separate application with web interface, in which you manually add a bunch of pixel id - fb token.
2. 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.
3. 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.
4. Tracker on top of 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
5. The software receives this postback, looks in its database, which token is needed for the received pixel and sends to the Server Side API all the necessary information: pixelid - token - fbclid - the desired pixel event.

Once the Server Side API call happens, you can track whether or not it made it to the fb in Events Manager:

Anticipate a question: how to save fbclid in tracker? Let's look at an example Keitaro. Go to Sources, either create or edit the Facebook source. And in the parameters add this notorious fbclid. In the screenshot below, I added it to the sub-label number 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.

Go on the plus side, gentlemen and send donations, I'll drink puerh for your health!