Жёлтый Веб Оптимизация кампании по товарке на выкуп с помощью Conversion API (CAPI)

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

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

Материал с сайта: Жёлтый Веб

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

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

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

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

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

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

Server Side API — лучшая версия пикселя фб!, изображение №1


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

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

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

Server Side API — лучшая версия пикселя фб!, изображение №2


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

Server Side API — лучшая версия пикселя фб!, изображение №3


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

И, дополнительно, увеличиваем ROI с помощью этой статьи: Как увеличить ROI с помощью Facebook Conversion API

На этом всё, надеюсь, описание схемы было достаточно полным, чтобы вы могли всё это настроить и запрограммировать! А будут вопросы — велкам на консультацию.

Лейте в плюс, господа!
 
Назад
Верх
Главная Поиск Блог Обучение Партнёрки Инструменты