В новом интервью поговорили с Anita Ferrum, директором по работе с партнерами KissMyAds.pro. Обсудили, почему оптимизация только на событие Lead может приводить не ту аудиторию, как передавать в Meta* данные о качестве заявок и что можно отсеять еще до отправки лида в партнерскую программу.
В CPA Анита, по ее собственным словам, уже больше 100 лет. Она стояла у истоков рынка, когда первый postback еще передавали голубями. А если серьезно, за ее плечами участие в запуске более десяти проектов: рекламных сетей, CPA-партнерок и других performance-проектов.
Почему оптимизации только на Lead недостаточно
Для Facebook* любой отправленный Lead — положительный сигнал. Но для рекламодателя два лида могут иметь совершенно разную ценность.
Один клиент оставил корректный телефон, взял трубку и подтвердил заказ. Второй указал несуществующий номер или при звонке сказал, что ничего не заказывал.
Если оба раза отправить одинаковое событие Lead, Facebook* не знает, какой пользователь нам действительно нужен. Мы фактически учим алгоритм искать людей, которые хорошо заполняют форму, а не тех, кто впоследствии покупает.
Как передавать в Meta* данные о качестве заявок
Самый простой следующий уровень — разделить Lead и Valid Lead. В KissMyAds.pro есть возможность настраивать пиксель по событию валидного лида. То есть рекламная система получает дополнительный сигнал после того, как мы понимаем, что заявка прошла первичную валидацию. Получается воронка: Lead → Valid Lead → Approve.
Valid Lead интересен еще и объемом: апрувов всегда меньше, а валидных лидов достаточно много, чтобы алгоритм быстрее получал данные для обучения.
— А можно передавать обратно уже сам апрув?
Да. Несколько наших партнеров уже работают по такой схеме через Conversions API. Механика выглядит так: Facebook* → Landing → Lead → KissMyAds → Call Center → Approve → Postback → CAPI → Facebook*.
Вебмастер отправляет лид в партнерскую программу по API. После обработки мы возвращаем статус постбэком. Если лид получил Approve, скрипт партнера отправляет соответствующее серверное событие обратно в Meta*.
В итоге Facebook* видит не только тех, кто оставляет заявки, но и тех, чьи заявки впоследствии подтверждаются.
Когда стоит оптимизироваться по Approve
Для глубокого события нужен объем данных. Если у тебя три апрува в неделю, алгоритму просто не на чем нормально обучаться. Поэтому сначала нужно накопить достаточную статистику и тестировать.
По этой же причине я бы не дробила данные без необходимости. Базовый вариант, который стоит протестировать: 1 Pixel = 1 Offer × 1 GEO.
Если между созданием лида и апрувом проходит время, также имеет смысл протестировать более широкое окно атрибуции, например 7 дней, если оно соответствует реальному циклу обработки заявки.
— Как понять, что такая оптимизация действительно дала результат?
Не смотреть только на CPL. Допустим, кампания А дает CPL $3 и Approval 15%, а кампания B — CPL $4 и Approval 25%. На первый взгляд А лучше. Но стоимость подтвержденного заказа получается $20 против $16.
CPL вырос на 33%, а стоимость апрува снизилась на 20%.
Поэтому нужно смотреть всю цепочку: CPL → Valid Rate → Contact Rate → Approval Rate → CPA Approved → итоговая экономика. Дешевый лид сам по себе еще ничего не говорит о качестве закупки.
Как отсекать невалидные лиды и дубли
Начать стоит с валидации контактных данных на лендинге. Если мы льем конкретное GEO, мы знаем, какой формат телефона там возможен. Значит, форма должна проверять код страны, допустимую длину и формат номера.
Причем просто показать пользователю маску +351 ___ ___ ___ недостаточно. Нужна именно проверка данных перед отправкой формы. Зачем платить за обработку лида, которому call-центр физически не сможет позвонить?
— А что делать с повторными заявками?
Проверять их еще на лендинге. Например, если этот клиент уже оставлял заявку в течение последних 24 часов, новую заявку можно определить как дубль еще до того, как она попадет в основную воронку.
Это важно и для оптимизации. Если один человек пять раз заполнил форму и каждый раз отправить в Facebook* событие Lead, алгоритм получит пять положительных сигналов, хотя нового клиента у нас фактически нет.
Если отсекать такие заявки заранее, мы уменьшаем количество дублей и не обучаем Facebook* на конверсиях, которые не имеют для бизнеса дополнительной ценности.
— Можно ли использовать данные рекламодателя еще до того, как человек повторно оставит заявку?
Да, мы также выгружаем партнерам черные списки клиентов, которые можно использовать для формирования аудиторий исключения в рекламных кампаниях — с учетом доступных инструментов платформы и требований к работе с пользовательскими данными.
Получается двусторонняя работа: через Valid Lead и Approve мы даем алгоритму информацию о том, какую аудиторию хотим получать, а через аудитории исключения стараемся не покупать повторно пользователей, которые уже показали отсутствие ценности для конкретной воронки.
— Если собрать все инструменты вместе, как должна выглядеть такая система?
Я бы строила ее поэтапно: Трафик → проверка телефона → проверка дубля за 24 часа → Lead → Valid Lead → Call Center → Approve → обратный сигнал в Meta.
Плюс отдельно — работа с накопленными данными и аудиториями исключения.
Смысл простой: не давать рекламному алгоритму одинаковый положительный сигнал за хороший и плохой лид. Сначала мы отсекаем очевидный мусор на форме, затем определяем валидность, после обработки возвращаем информацию об апруве, а исторические данные используем, чтобы не покупать заведомо ненужную аудиторию повторно.
Как оценивать качество трафика и апрув
Сначала я бы проверила три базовые вещи на лендинге: маску телефона, реальную валидацию номера и отсечение дублей за 24 часа. Следующий шаг — передача Valid Lead. Если объем позволяет — подключение Approve через CAPI и тест оптимизации на более глубоком событии. И обязательно оценивать результат не по тому, насколько снизился CPL, а по тому, сколько в итоге стоит валидный и подтвержденный лид.
В конечном счете задача вебмастера и рекламодателя одна: не получить максимальное количество заявок, а найти такой трафик, на котором обе стороны зарабатывают.
* — запрещенная соцсеть на территории РФ.
