Server Side API — лучшая версия пикселя Facebook

А что если бы я сказал вам, что вы можете оптимизировать свои кампании по товарке в Facebook не на лидов, а на выкуп? Лить кампании на гемблу без прил, и при этом всё равно оптимизироваться на депы? Или, допустим, оптимизироваться на реги в крипте даже в тех ПП, у которых нельзя ставить пиксель на сайте брокера? Интересно? Читаем далее.

Все вышеописанные ситуации возможны в реализации уже сегодня благодаря одной единственной штуке в Facebook — Server Side API!

И сегодня мы подробно разберёмся, что это за зверь, и как настроить все необходимые компоненты тех.части, чтобы воплотить вышесказанное в реальность.

Для начала, немного про пиксель. Итак, при обычной настройке пикселя мы должны запихнуть кусок javascript-кода на лендинг, где пользователь совершает целевое действие. У данного метода есть пара фатальных недостатков:

1. Мы должны иметь доступ к ленду. То есть либо мы выкачиваем его из ПП и хостим где-то у себя, либо мы передаём id-пикселя в ПП и уже ПП его «показывает» на ленде. Не во всех вертикалях нам дадут это сделать. В той же крипте или бинарке зачастую может оказаться так, что прокинуть пиксель на сайт брокера тупо нельзя (не говоря уже о том, чтобы скачать этот сайт себе, ибо там происходит процессинг карт).
2. Пиксель срабатывает не на том уровне воронки, как нам того хотелось бы. Иногда это происходит из-за первого пункта, и нам приходится ставить пиксель себе на проклу, чтобы оптимизироваться хотя бы на тех пользователей, что перешли с неё на сайт брокера, а уж зарегаются они и депнут ли — одному б-гу известно! В товарке же мы ставим пиксель на событие Lead и ждём аппрува, не имея возможности оптимизироваться на тех, кто подтвердит заказ.

Теперь рассмотрим, что же такое Server Side API, и как с его помощью мы сможем решить эти проблемы. По сути, это апи, которое позволяет нам со своего сервера слать любые события в выбранный пиксель Facebook. Вот основной метод:

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

Идея такова: получив постбэк из ПП о том, что пользователь совершил целевое действие (рега, деп, аппрувнутый лид), послать уведомление об этом событии в Facebook! В таком случае нам вообще не нужен пиксель на наших проклах-лендах!

«Но погоди, Жёлтый, а как же Facebook поймёт, какой именно пользователь совершил целевое действие?» — спросите вы. Для ответа на этот вопрос нам нужно заглянуть в параметры, которые передаются основному методу апи, а также к ссылке, на которую мы льём.

Если мы присмотримся к ссылке нашего рекламного объявления, опубликованного в Facebook, то мы увидим, что в конце практически любой такой ссылки Фб дописывает свой дополнительный параметр fbclid.

Код пикселя на лендинге сохраняет значение этого параметра в куки, и шлёт потом его вместе с событиями пикселя типа Lead и Purchase. Именно по нему Facebook определяет, что за пользователь переходил на ленд. Мы будем сохранять значение этого параметра в самом трекере, чтобы потом иметь возможность послать его через Server Side API.

Ремарка: да, Фб может определять пользователя и по другим параметрам типа мыла, телефона и имени, но описание работы с данными параметрами выходит за рамки этого мануала, читайте доки, там всё описано!

Итак, вырисовывается следующая общая схема работы:

1. Специальный софт сохраняет где-то у себя в БД всё access_token-ы и id пикселей для того чтобы иметь возможность вызывать Server Side API. Это может быть софт для залива, который сохраняет эту инфу автоматом при заливе или просто отдельное приложение с веб-интерфейсом, в которое вы сами руками добавляете связку id-пикселя — токен Facebook.
2. Когда пользователь переходит по ссылке с объявления к нам в трекер, то трекер присваивает клику уникальный subid. После чего вычленяет из ссылки id пикселя (нам его, ясное дело, надо для этого добавить в ссылку при настройке объявы) и фбшный параметр fbclid и хранит у себя в базе соответствие: subid — pixelid — fbclid.
3. Пользователь совершает целевое действие, после чего ПП шлёт нам в трекер постбэк, в котором написан subid лида и его статус, допустим это будет статус sale (продажа) в товарке.
4. Трекер же в свою очередь шлёт S2S-постбэк обратно нам в софт из пункта 1. В этом постбэке шлётся следующая инфа: fbclid — pixelid — статус лида
5. Софт принимает этот постбэк, смотрит у себя в базе, какой для полученного пикселя нужен токен и шлёт в Server Side API всю нужную инфу: pixelid — token — fbclid — нужное событие пикселя.

После того, как произойдёт вызов Server Side API вы сможете отследить, прошёл он или нет в фб в Events Manager:

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

Всё! Теперь, когда мы будем слать S2S-постбэк мы сможем прописать в нём макрос {subid13} и он будет заменён на значение сохранённого fbclid.