661 А что если бы я сказал вам, что вы можете оптимизировать свои кампании по товарке в Facebook не на лидов, а на выкуп? Лить кампании на гемблу без прил, и при этом всё равно оптимизироваться на депы? Или, допустим, оптимизироваться на реги в крипте даже в тех ПП, у которых нельзя ставить пиксель на сайте брокера? Интересно? Читаем далее.
Все вышеописанные ситуации возможны в реализации уже сегодня благодаря одной единственной штуке в Facebook — Server Side API!
И сегодня мы подробно разберёмся, что это за зверь, и как настроить все необходимые компоненты тех.части, чтобы воплотить вышесказанное в реальность.
Для начала, немного про пиксель. Итак, при обычной настройке пикселя мы должны запихнуть кусок javascript-кода на лендинг, где пользователь совершает целевое действие. У данного метода есть пара фатальных недостатков:
- Мы должны иметь доступ к ленду. То есть либо мы выкачиваем его из ПП и хостим где-то у себя, либо мы передаём id-пикселя в ПП и уже ПП его «показывает» на ленде. Не во всех вертикалях нам дадут это сделать. В той же крипте или бинарке зачастую может оказаться так, что прокинуть пиксель на сайт брокера тупо нельзя (не говоря уже о том, чтобы скачать этот сайт себе, ибо там происходит процессинг карт).
- Пиксель срабатывает не на том уровне воронки, как нам того хотелось бы. Иногда это происходит из-за первого пункта, и нам приходится ставить пиксель себе на проклу, чтобы оптимизироваться хотя бы на тех пользователей, что перешли с неё на сайт брокера, а уж зарегаются они и депнут ли — одному б-гу известно! В товарке же мы ставим пиксель на событие 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.
Ремарка: да, Фб может определять пользователя и по другим параметрам типа мыла, телефона и имени, но описание работы с данными параметрами выходит за рамки этого мануала, читайте доки, там всё описано!
Итак, вырисовывается следующая общая схема работы:
- Специальный софт сохраняет где-то у себя в БД всё access_token-ы и id пикселей для того чтобы иметь возможность вызывать Server Side API. Это может быть софт для залива, который сохраняет эту инфу автоматом при заливе или просто отдельное приложение с веб-интерфейсом, в которое вы сами руками добавляете связку id-пикселя — токен Facebook.
- Когда пользователь переходит по ссылке с объявления к нам в трекер, то трекер присваивает клику уникальный subid. После чего вычленяет из ссылки id пикселя (нам его, ясное дело, надо для этого добавить в ссылку при настройке объявы) и фбшный параметр fbclid и хранит у себя в базе соответствие: subid — pixelid — fbclid.
- Пользователь совершает целевое действие, после чего ПП шлёт нам в трекер постбэк, в котором написан subid лида и его статус, допустим это будет статус sale (продажа) в товарке.
- Трекер же в свою очередь шлёт S2S-постбэк обратно нам в софт из пункта 1. В этом постбэке шлётся следующая инфа: fbclid — pixelid — статус лида
- Софт принимает этот постбэк, смотрит у себя в базе, какой для полученного пикселя нужен токен и шлёт в Server Side API всю нужную инфу: pixelid — token — fbclid — нужное событие пикселя.
После того, как произойдёт вызов Server Side API вы сможете отследить, прошёл он или нет в фб в Events Manager:
Предвижу вопрос: как сохранять fbclid в трекере? Разберём на примере Кейтаро. Заходим в Источники, там либо создаём либо редактируем источник Facebook. И в параметры добавляем этот пресловутый fbclid. На скрине ниже я его добавил в суб-метку под номером 13 — sub_id_13.
Всё! Теперь, когда мы будем слать S2S-постбэк мы сможем прописать в нём макрос {sub_id_13} и он будет заменён на значение сохранённого fbclid.
На этом всё, надеюсь, описание схемы было достаточно полным, чтобы вы могли всё это настроить и запрограммировать! А будут вопросы — велкам на консультацию.
Лейте в плюс, господа и шлите донатики, выпью пуэра за ваше здоровье!
