⚡️ Карты тестов для Facebook: определяем, что не так с вашими кампаниями

Мы поговорили с Вячеславом Чемодановым, сооснователем партнерки AlfaLeads и руководителем медиабаингового отдела AlfaMedia об их внутренней разработке. Медиабайеры под руководством Славы используют карты тестов, чтобы понять, за что Facebook банит аккаунты, как те или иные шаги при фарме акков влияют на результат, что работает, а что — точно нет. 

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

Что такое карта тестов и как она выглядит? 

Карта тестов — это некая сводная таблица, которая содержит в себе все переменные, которые участвуют в тесте, а также результаты всех проведенных тестов. Карта позволяет “подсветить” зависимости между переменными.

Зачем нужна карта тестов, какие проблемы она помогает решить? 

Она нужна для нахождения корреляции между определенными переменными и результатами теста. Делая репрезентативное количество итераций в тестах, мы можем делать выводы о том, что работает, а что нет. Где есть зависимости (например, баны FB), а от чего баны не зависят.

Карта тестов – ваша личная разработка, или ее применяют и в других медиабаингах/арбитражных командах?

Я думаю, что аналитику собирает большинство байеров и команд, вопрос в том, как именно это делать, и как находить корреляции между различными типами переменных. Уверен, что кто-то создает для себя нечто похожее, но разбирать чужие подобные инструменты не приходилось.

Как составляют карты тестов у вас в Alfamedia? 

Мы выделяем несколько переменных, корреляцию между которыми мы хотим проследить, и выясняем количество возможных значений этих переменных.

Для простоты примера: мы хотим протестировать, как будут запускаться и жить аккаунты FB при разном сетапе типа аккаунтов и платежек. Опять же, для простоты тестируем 3 вида аккаунтов и 3 вида платежных инструментов. Минимальный тест, который мы можем здесь провести — 9 мультипликаций. Для достоверности результатов стоит брать не менее 3-4 итераций каждой мультипликации. Суммарно получаем 36 итераций.

Как впоследствии собрать и воспользоваться этой информацией? 

Составляется единая таблица, куда расписываются все 36 возможных варианта теста. Каждой строчке соответствует одна итерация. Итерация всегда присваивается определенному байеру. Также в таблице мы всегда фиксируем остальные важные элементы нашего теста: приложение, платформа, типы креативов, типы подходов, гео, оффер, тип клоакинга/тип прилы и т.д. Эти параметры являются у нас константными, то есть мы не ищем прямой корреляции между ними и основными переменными теста.

Но эти константы могут быть нам полезны для дополнительной информации. Например, после всех тестов мы можем сортировать всю таблицу по байерам и понять, что при разных сетапах у “buyer 1” результаты теста (запуск и живучесть аккаунтов) лучше, чем у “buyer 2”, а также другие возможные корреляции. Часто бывает, что косвенный анализ, который мы можем провести, дает больше пищи для размышлений, чем главный результат теста, ради которого все затевалось.

Есть ли переменные, которые вы точно не включаете в карту тестов?

Нельзя ответить универсально. Все зависит от конкретной задачи, что именно мы хотим протестировать, какие корреляции найти и какой репрезентативности нам “достаточно”.

Может ли такая карта привести к ошибке? Если да, как этого избежать? 

Конечно. Много упирается в репрезентативность данных и минимально необходимый тест. Мы не можем проводить аналогии, не сделав нескольких итераций для определенного сетапа переменная 1 и переменная 2. Мы никогда не можем доверять нашим итоговым данным на 100%, так как возможности теста всегда ограничены.

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

1. Экономическая целесообразность. Само тестирование и подготовка к нему может съесть больше ресурсов, чем принесет пользы.
2. Фактор времени. Если ваш тест слишком продолжительный, вы рискуете, что внешняя ситуация, с которой вы боретесь (например, баны FB) может меняться быстрее, чем проходит ваше тестирование. И в результате вы не сможете понять вообще никакой корреляции между итерациями и результатом.
3. Простота итераций. Сам проект тестов может быть объемным, сложным. Но все итерации в этом тесте должны быть простыми и понятными байеру/дизайнеру и любому другому члену команды, кто будет выполнять эту задачу. Если ваша итерация сложная, и вы не все описали, вы не можете быть уверены, что она выполнена правильно. А значит, не можете полагаться на достоверность конечного результата всего теста.

Бывало ли так, что карта тестов не помогла пофиксить проблему? Что вы делаете в таких случаях? 

Конечно бывает! Не все можно исследовать и понять через тест. Всегда есть и будут ограничивающие факторы, которые занижают целесообразность самого теста. Всегда будут ошибки, человеческий фактор. Мы никогда не можем быть уверены, что наш тест приведет к положительному результату.

Но при этом, во времена особенно частых или массовых банов, штормов в источниках трафика, мы всегда стараемся найти решение, а не переждать бурю. Не всегда, но в подавляющем количестве кейсов усилия окупаются с лихвой, и нам удается понять рабочий сетап раньше рынка и, соответственно, успеть заработать на трафике больше.

Если наш тест не удается, но проблема все еще не решена, мы садимся и планируем новый тест с учетом новых внешний реалий, которые, вероятно, изменились. Возможно, этот тест будет более простым, быстрым, рисковым, так как во втором этапе потенциальное количество всех значений для переменных сокращается.