В арбитраже любят сохранять победы, с минусовыми тестами отношения обычно сложнее: залили гипотезу, потратили бюджет, не увидели нужных цифр, стопнули и пошли дальше. Через неделю про запуск помнит байер, через месяц – в лучшем случае тимлид, полгода спустя кто-нибудь в команде снова приходит примерно с той же идеей и вся тима еще раз платит за вывод, который уже когда-то получила.
Внутри команды остается история того, что сработало, но постепенно исчезает все, что проверили и отбросили по дороге, а без второй половины данных первая довольно легко начинает вводить в заблуждение.
Один плюс в базе может спрятать девять минусов
Представим, что за несколько месяцев команда протестировала десять подходов на одном GEO. Один дал хороший плюс, еще два потенциально были хороши, но не дожили до нормального скейла, а остальные семь залили в минус.
Если через полгода в базе остался только «победитель», картина выглядит очень красиво: вот GEO, вот подход, вот крео и результат. Только опыт команды состоял не из одного успешного решения, он был построен из десяти проверенных гипотез и девяти выводов о том, куда дальше копать не стоит или что нужно изменить перед следующим запуском.
В итоге новый байер может снова принести старую гипотезу, и если тимлид не вспомнит детали прошлого теста, то ребята заново соберут сетап и через пару дней придут ровно к тому же выводу. Отсюда мы берем стоимость плохой памяти команды и чем больше тестов проходит через тиму, тем дороже она обходится.
Худший вывод, который можно оставить после теста
Легко уйти в другую крайность и начать собирать кладбище связок.
«GEO X + оффер Y = не работает».
Такой вывод почти бесполезен: две связки с одинаковым итоговым ROI могут умереть вообще на разных этапах воронки. Допустим, в первом тесте получаем дорогой трафик и слабую реакцию еще на уровне просмотров. Во втором отличный CTR, удовлетворительный CPC, люди доходят до продукта, но дальше почти никто не регистрируется или не депает.
Финально оба теста можно записать в минус, но выводы из них совершенно разные.
— В первом случае есть вопросы к крео, подходу или самому попаданию в аудиторию.
— Во втором трафик уже проявил интерес, поэтому хоронить всю гипотезу только из-за отрицательного ROI рано, нужно смотреть дальше по воронке.
Поэтому нормальная отчетность отвечает не только на вопрос «сколько мы заработали или потеряли?», но и на более полезный: «Где эта гипотеза перестала конвертить?»
Какие данные сейвить?
Базовая часть довольно очевидна: GEO, оффер, источник, креатив, подход, лендинг, спенд и основные показатели вроде CPM, CTR, CPC, CR, депозитов и ROI. Без этого потом невозможно нормально восстановить сам запуск, но одна таблица с цифрами не превращается в базу знаний.
Представим, что спустя три месяца другой байер открывает строку:
Spend: $800
ROI: −37%
Что он должен из этого понять? Что оффер плохой? Что GEO не конвертит? Что больше не стоит юзать этот подход? Что нужно взять другое крео?
Поэтому рядом с цифрами должен оставаться контекст запуска и вывод самого байера, ниже дадим таблицу, по которой сможешь ориентироваться. По сути, цифры сохраняют результат теста, а комментарий байера сохраняет знание, которое команда за этот тест купила.
Минусовая связка = рабочий ретест
Представим тот же сценарий: связка ушла в минус, но CTR отличный, дешевый трафик и крео явно цепляет аудиторию. Основной отвал начинается уже на реге или депозите.
Если смотреть только на финальный ROI, логичный вывод — стопнуть и забыть, но если разложить тест по воронке, становится видно, что верх уже работает. Значит, в следующем запуске необязательно заново перебирать весь сетап. Можно сохранить рабочий заход и проверить то место, где связка начала сыпаться: подачу в преленде, оффер или следующий этап воронки.
И иногда после такой корректировки в плюс начинает выходить связка даже с менее вкусным CTR. То есть нормально разобранный провал подсказывает, что именно стоит проверить следующим.
У нормального ретеста должна появиться причина:
— Изменилось крео.
— Поменяли оффер.
— Пересобрали часть воронки, на которой был основной отвал.
— Прошла сезонность.
— Произошли заметные изменения в работе источника.
— Появились новые данные, из-за которых старую гипотезу теперь имеет смысл проверить иначе.
То есть между первым тестом и ретестом должна появиться новая переменная. Если ничего не изменилось и мы просто второй раз запускаем ту же мертвую связку в надежде увидеть другие цифры, то это уже сложно назвать тестированием, определение для такого вида мазохизма придумай сам.
Кто будет смотрящим?
Первично — байер, потому что он находится в контексте запуска. При этом оставить всю систему исключительно на совести вебов тоже не получится. Задача тимлида — сделать фиксацию тестов частью процесса и здесь будет работать простое правило: тест закончен тогда, когда по нему зафиксирован вывод.
Аналитик уже поможет правильно прочитать цифры и найти закономерности на большем массиве данных, ответственность в итоге действительно командная, но контекст запуска начинается с байера.
Главное, чтобы твоя тима не попала в другую ловушку: можно настолько увлечься, что после каждого теста вебу придется заполнять форму размером с налоговую декларацию. Уже сейчас несложно прикинуть, во что это превратится через неделю или месяц: если отчет неудобно заполнять, его либо начнут делать на отвали, либо перестанут делать вообще. Поэтому хороший шаблон должен быть достаточно подробным, чтобы сохранить смысл теста, но достаточно коротким, чтобы им реально пользовались.
Базово мы бы оставили:
Если тима хочет накапливать экспертизу, в ее истории должны оставаться все нормальные тесты, а не только те, которыми потом приятно поделиться в чате.
Потому что задача отчетности – сделать так, чтобы следующий веб принимал решение уже с учетом денег, которые команда потратила до него и тогда минусовой тест перестает быть просто убытком, он становится купленной информацией. Главное – не заплатить за нее второй раз.
Сильный баинг строится на тестах и решениях, за которыми стоят реальные цифры.
Если хочешь получать этот опыт внутри команды и расти вместе с FTD.team, чекай наш HR-бот — там собрали все актуальные вакансии: @ftdhrbot
