Руслан Назаренко, ментор в Google Launchpad и куратор нескольких курсов в школе Projector, подготовил материал на тему Marketing Automation.
Несколько лет назад, когда я завязал работать фулл-тайм и стал контрактором, я занимался в основном тем, что можно называть Initial Traction. Идея была достаточно простая, после всех своих проектов, фейлов и побед, у меня скопился какой-то багаж знаний о том, как правильно запускать продукты и где брать тот самый traction, с которым можно идти дальше. Мне это нравилось.
Но реальность такова, что какие-то из клиентов хотели двигаться дальше и спрашивали меня: а что теперь? Сложный вопрос, на самом деле. Мы сделали входящий поток пользователей, но они отваливались. Что вроде и логично, а с другой стороны — катастрофа. Знаете, когда ваш продукт — это кусок огромной компании и ваши ресурсы, де-факто, безграничны — это не очень страшно. Вы меняете продукт, допиливаете его, улучшаете UX, фиксите баги. Все как обычно.
Но когда все, что у вас есть, это $100 на следующий месяц, а их хватит разве что на выпить кофе, появляется острый вопрос: Как быть?
Ответ, как оказалось, достаточно простой. Закрывать дыры в UX за счет маркетинга. В одном из таких продуктов мы насетапили 300 триггеров. И около 600 экшенов по ним. Это вот приблизительно та причина, по которой стоит перестать пафосно называть емейлы marketing automation. Это как называть колесо от автомобиля самим автомобилем.
Все наши конверсии вдоль фанела значительно выросли. Ребята решили взять себе фултайм маркетолога и попросили рассказать ему, что тут происходит. Я себе крайне слабо представляю, как можно на пальцах рассказать, что же за 300 триггеров у нас. Почему они такие, как они менялись и что с ними происходит. И я начал строить визуальные карты о том, как работает наш маркетинг.
Но давайте обо всем шаг за шагом:
Первый вопрос с которым вы столкнетесь — фреймворк для фанела. Есть классика в виде AARRR. О нем все знают, все привыкли. Мне его катастрофически не хватает. Основная идея любого фреймворка — дать какой-то чеклист, по которому можно следовать и быть уверенным, что все важное вы не забыли. Так что для себя я его немного модифицировал.
Встречайте версию 2.0 — ACD AE RRR. В чем идея? Сам по себе первый этап A (A stands for Acquisition) — достаточно туманное понятие. Надо привлекать людей и что дальше? За основу я взял User Journey by Hubspot и первый этап разделился на три: Awareness, Consideration, Decision.
Теперь понятно, что у нас есть три фокуса: помочь человеку описать свою проблему, показать, как ее решают другие и дать выбор подходов/инструментов, как ее решить может он лично. В последнее время я иду еще дальше и делаю 5 этапов: Unaware, Pain aware, Solution aware, Product aware, Most aware. Детальнее можно почитать в книжке прекрасного копирайтера Joanna Wiebe The conversion marketer’s guide to landing page copywriting by Unbounce. На удивление, ее подход отлично ложится на весь маркетинг.
Дальше идет AE. Если в классике у нас есть только один этап — Activation, то я для себя отдельно вывел другую категорию — Engagement. Зачем? Мне проще разделить first user experience и получение AHA момента пользователям в первых сессиях от общего engagement`а. То есть от того, как мы потом этого пользователя вовлекаем. Тут книжка Hooked будет полезной.
После этого стоит «замапить фанел». С помощью draw.io или любого похожего инструмента (знаю ребят, которые делают это в Figma или Sketch) вы шаг за шагом переносите свои маркетинг процессы. По центру, к примеру, идет Landing page -> Sign up page 1 -> Sign up page 2 — Onboarding -> Action X — AHA moment, etc.
Важно (!). Идите строго сверху вниз. Да, на том же лендинге может быть блог и что-то еще. Это все вспомогательные штуки. Я для себя важные этапы (как вот регистрация — действие Х) отмечаю просто квадратами, а все промежуточные — квадратами со штрихпунктирами.
Почему? Иначе спустя несколько итераций ваша карта станет нечитабельной.
После этого вы можете выделить все области и соотнести их с general framework ACE AE RRR. Это поможет понять, какие цели/задачи/проблемы у пользователя на каждом этапе. Это кажется несущественным, но поверьте моему опыту — впоследствии сыграет ключевую роль. Если вы все таки не верите — сходите на блог Chris Von Wilpert и почитайте, каких результатов он добивается, остановившись только здесь.
С левой стороны я выписываю гипотезы, почему пользователь, находясь на нашем сайте/апке, тупит на этом этапе. В целом, это обычная работа по исправлению дроп-оффов.
К примеру, есть у нас пользователь Meizu. Он на этапе «пригласи друга», но почему-то висит на экране 2 минуты вместо средних 47 секунд. Что с ним не так? Как оказывается, из-за кастовой версии ОС, лаунчер контактов у него не срабатывает и просто идет бесконечная загрузка экрана. Это технический баг, о котором вы узнаете постфактум. Лучше сыграть на опережение и спросить, все ли у него ок.
Есть миллион таких кейсов и иногда, когда пользователь не знает, что дальше делать — вы можете предложить ему 1-3 варианта решения. Подробнее читайте в Intercom on Onboarding и в Intercom on User Engagement. Идея в том, что тут каждую гипотезу вы превращаете в триггер и пытаетесь решить проблему с помощью in-app messages, попапов, онбординга, гайдов, туториалов и т.д. прямо внутри сайта.
С правой стороны я выношу гипотезы, которые касаются пользователей, ушедших с какого-то этапа. Вот пользователь дошел до конца момента ввода данных карты. Допустим, ваш продукт сделан таким образом, что ввод карты происходит еще до взаимодействия и получения велью от вашего решения. Пользователь ушел.
Тут несколько вариантов, если до этого форма регистрации была простая — скорее всего, он просто не уверен в нужности продукта. Если сложная и он потратил 1 час, чтоб ее заполнить и внес даже данные своей бабушки, но ушел — скорее всего, ему не хватает social proof. Идеальный пример можно посмотреть на регистрации Invision. Исходя из этого мы думаем, как его вернуть. Почта, ретаргетинг — это, скорее всего, будет 80% ваших инструментов.
Я советую набрасывать по 2-3 гипотезы на каждый этап для начала и быстро их тестировать. Таким образом с помощью маркетинга вы можете решить проблемы UX в том числе. Возврат не должен строиться в одно касание. Самое паршивое, что можно сделать, если пользователь ушел — догонять его скидкой. В этот момент на 99% вы ловите халявщиков. Вместо этого попробуйте с помощью маркетинга решить его проблему. Если вы угадали с гипотезой, правильно стригерили пользователя и показали ему статью: «Как Uber вырос в 7 раз за счет смены механики реферальной программы», — ваши шансы на успех достаточно высоки. Но если он не кликнул на эту рекламу, а перед этим вы попробовали поменять каналы от дешевых к дорогим, то это фейл и надо думать дальше. В сухом остатке, на старте должно быть 2-3 гипотезы и 3 касания по цепочке: не кликнул на X — показали Y — не кликнул на Y — показали Z.
Вот, кстати, пример который сделали студенты моего курса как кейс для клиента:
Как итог, marketing automation здорового человека состоит не только из емейлов (они даже 50% не занимают), а из всего спектра инструментов, которые есть в продакт маркетинге. На подход выше, который я описал, так же чудесно ложится lead nurturing, lead scoring, саппорт сейлзов маркетингом, MQL/SQL и многое другое. Если вы, банально, раз в неделю-две будете выносить основные цифры по каждому экшену — вы получите горизонтальный фанел коммуникации и сможете увидеть, где и какие user journey работают хорошо (и сможете пофиксить это в дизе и перестать вливать денег в маркетинг), а какие работают плохо. Как следствие, вам будет понятно где и над каким этапом сейчас надо работать особенно активно.
Из инструментов, которые вам пригодятся: GTM, Segment, IFTTT, Zapier, Phantombuster, automate.io, Autopilot/Pipz/Userengage, Intercom, Amplitude, Hubspot/Pipedrive.
Вот вам и marketing automation.
Outro:
Нельзя автоматизировать то, чего вы не понимаете. Маркетинг в этом плане намного проще, чем автоматизация бизнеса. Но оба начинаются с прорисовывая процессов, которые у вас есть, выбора инструментов и потом попыток связать эти инструменты в одно целое. Надеяться на то, что это получится сделать без JS/Python/SQL — пустая трата времени. Но уровень знаний, который вам нужен для этих задач — достаточно базовый и его можно получить за 3-4 месяца интенсивной учебы.
Для отправки комментария необходимо войти на сайт.