Всем привет! Меня зовут Подольский Александр, и последние 8 лет я занимаюсь аналитикой. В этой заметке я хочу рассказать про такой старый инструмент, как опросы (а именно, опросы после покупки), который может оказаться очень полезным для атрибуции, когда между пользователем и вашем продуктом появился SKAN.
Перенесемся во времена до введения SKAN.
Для отдела маркетинга при решении задачи атрибуции было 2 вызова:
- Атрибуция оффлайн каналов – сложно / дорого / спорно.
- Выбор last / first /… touch метода атрибуции для онлайна, при том, что все данные были "на руках".
После введения SKAN стало еще хуже. Раньше можно было считать, что со 2-м пунктом всё более менее понятно, а после выхода обновления iOS 14.5 сложность онлайн атрибуции максимально приблизилась к оффлайн (компании-гиганты, кажется, не так пострадали, т.к. имеют возможность использовать IDFV и прочие преимущества объема данных, которым они располагают). После такого по-настоящему тектонического сдвига в маркетинге, который произошел уже год как, никто все еще не предложил единого решения, как делать атрибуцию (конечно, существует Appsflyer / Adjust / …, но все равно это требует от маркетинга некоторого "прыжка веры"). Ровно поэтому любые "сигналы" / данные и инструменты, полезные для атрибуции, ценны как никогда. Один из таких инструментов – PPS.
PPS (post purchase survey) – это опрос пользователя после покупки (совершения важного целевого действия) в котором пользователя спрашивают "откуда вы о нас узнали?".
До боли знакомая оффлайн механика, которую очень легко реализовать силами своей разработки или интегрировать готовые решения (Iterate, Survey Sparrow,… ). Iterate – однозначно не тот проект, который "на слуху", но по воле случая именно с ним я работаю уже лет 5 и могу рекомендовать (в первую очередь со стороны маркетолога / менеджера / аналитика).
Предположим, что введение убедило вас внедрить (или хотя бы попробовать) PPS к себе в продукт, ниже я приведу несколько важных пунктов, на которые надо обратить внимание.
Итак, PPS 101:
- Опрос должен отрисовываться быстро – у вас есть буквально несколько секунд (а то и десятых секунд) внимания пользователя после заказа (важного события) , в которые еще хочется впихнуть вопрос, время на подумать и ответ. Если экран с опросом будет грузиться долго, то пользователь без какого-либо зазрения совести просто закроет/свернет приложение, ведь заказ-то уже оформлен. Аналогично стоит учитывать то, как выглядит экран с опросами, и не допускать скролла. Опять же, вы просите пользователя помочь вам, он за это не получает никакой выгоды (хороший вопрос, стоит ли мотивировать пользователя, кажется, что нет, но тут, наверное, лучше обратиться к социологии), ровно поэтому никто не захочет скроллить или иметь дело с неудобной версткой.
- "Простые вопросы – простые ответы" – как уже было отмечено выше, ресурс внимания пользователя крайне ограничен, поэтому вопрос должен быть сформулирован максимально коротко и понятно, аналогично и ответы. Иначе пользователь либо пропустит опрос, либо будет делать все, чтобы от него "отстали" (что напрямую отразится на качестве ваших данных).
- Настройте отправку идентификатора пользователя / заказа /…, чтобы в дальнейшем иметь возможность связать ответ с конкретным пользователем / заказом /… .
- Перемешивайте ответы – пользователи не помнят / кликают на первый попавшийся вариант / врут, поэтому для того, чтобы хоть как-то минимизировать влияние на конечные данные, надо постоянно перемешивать ответы.
- Добавьте поле "Другое" – текстовое поле со свободным вводом, такие ответы бывает крайне полезно читать, потому что иногда там можно найти то, о чем вы не догадывались. К примеру, когда я работал во Fridge No More (q-grocery стартап), мы заметили, что пользователи начали отвечать "Storefront", то есть они узнавали о нашем продукте по витринам наших магазинов. Это может показаться очевидным, но когда вы погружены в свою performance marketing рутину, то можно легко упустить из виду такую опцию. В итоге это привело к тому, что мы начали инвестировать во внешний вид наших магазинов, и это дало свои результаты.
Отдельно хочется выделить часть пункта 2. "Простые ответы". На самом деле, выбрать правильное название маркетингового канала (понятное для пользователя) не так уж и просто, и это тоже отдельный процесс, в котором нужно итеративно экспериментировать с разными названиями и искать оптимальное. Основная сложность заключается в том, что пользователь может не отличать рекламные каналы между собой, не знать "общепринятого названия среди маркетологов" или же просто не понимать, что за реклама его привела.
К примеру:
- Google поиск и brand search – вряд ли обычный человек запомнит, по какому размещению он кликнул в поиске
- Рекламные сетки – когда во время игры вы видите баннер и кликаете, вряд ли вы знаете, что за рекламная сеть показала вам этот баннер.
- YouTube блоггеры и YouTube пре-роллы – аналогично, скорее всего вы как пользователя запомните, что пришли из YouTube (или RuTube;)) , но вряд ли запомните, какой именно был формат рекламы. Со стороны аналитики при просмотре статистики ответов вида "YouTube" вам будет очень сложно отделять ответы, которые относились к pre-roll-ам, а какие к блоггерам.
- Instagram блоггеры и instagram реклама – аналогично
Итак, с основными трудностями на пути внедрения мы разобрались, дальше я хочу рассказать о нескольких кейсах использования и работы с PPS.
Как можно найти “правильные названия” и отделить похожие друг на друга каналы?
Разберем на примере Direct Mail и Street Teams (это скорее специфика американского рынка), начнем с определения того, что это за каналы такие.
Direct mail – листовки, которые кидают пользователям в физические почтовые ящики (да-да, на одном из главных рынков мира все еще безумно популярен и эффективен такой метод рекламы) .
Street Teams – это тоже листовки (флаеры) , но которые раздаются на улице, чаще всего помимо листовки пользователю еще дают какой-нибудь бесплатный напиток (снек или что-то аналогичное) и, допустим, просят установить приложение (да, удивление x2, но это тоже работает и популярно на рынке US) .
Так вот, по сути в обоих этих каналах речь идет о листовках, и пользователю трудно их отличать.
В итоге мы провели несколько тестов:
- Street teams можно называть brand ambassadors / flyer on the street…
- Direct mail – flyer / flyer in my mailbox /…
и остановились на формулировках "Street Teams" и "Flyer in my mail". Для принятия решения мы смотрели на ответ пользователя и купон, который он использовал. Нам повезло, так как все рекламные материалы содержали индивидуальный купон со скидкой на первый(-ые) заказ(-ы) (для каждого "материала" / "канала" / "активности" /… свои купоны), а значит помимо ответа пользователя мы могли узнать, какой купон использовался для первого заказа. В итоге, мы оценивали % пользователей, у которых атрибуция купона совпадает с выбранным ответом в опросе.
Как измерить инкрементальность и уменьшить% “лжи”?
Предположим, что мы хотим запустить крупную ТВ кампанию, соответсвенно, мы ожидаем увидеть рост доли пользователей, которые будут отвечать, что они узнали о нашем продукте из ТВ рекламы. Вроде все звучит логично, с другой стороны, как я уже говорил ранее, люди могут "лгать" (намеренно / ненамеренно), а значит, после добавления нового варианта ответа мы увидим, как часть "лживых" ответов перераспределится и на этот канал тоже.
Для частичного решения такой проблемы можно добавлять новый ответ в опрос до фактического запуска рекламной кампании, в итоге, вы замерите "false awareness", и потом можно будет просто вычесть из % доли тех, кто отвечает ТВ, константу, которую вы получите. Способ выглядит очень элегантно, правда, сразу же появляется новая трудность – атрибуция перестает быть юзер-центричной.
Получается, что вы можете посчитать сколько было пользователей, которые пришли по выбранному рекламному каналу (простым умножением (% ответивших – false awareness) x кол-во новых пользователей) , но не можете выделить конкретных (а точнее, можете выделить тех, кто выбрал в опросе нужный ответ, но при этом не можете отфильтровать тех, кто попал в группу false awareness) . Описанный недостаток далеко не всегда является критичным, поэтому такой способ улучшения качества данных достаточно часто применяется.
Для каких еще задач можно использовать PPS?
Когда я работал в Scentbird, мы активно закупали рекламу в Facebook, и я застал момент внедрения SKAN (вне зависимости от того, гнали вы трафик на app или нет, это изменение почувствовали все участники аукциона) .
Благодаря тому, что мы использовали отдельные лендинги / купоны для Facebook, а также PPS, у нас была возможность строить атрибуцию и считать эффективность рекламы несколькими способами (по версии Facebook и по PPS) , если представить, что мы считаем CAC (деньги / новые пользователи) , то визуально это можно было представить, как 2 кривых, между которыми была почти константная разница (для простоты представим, что там действительно была константа) .
В итоге, после раскатки SKAD мы увидели, что по версии Facebook–a CAC отправился в космос, при этом "по версии" PPS CAC остался примерно на том же уровне, а значит и соотношение между CAC, посчитанном 2-мя разными способами изменилось (впервые за крайне долгий период наблюдений) . Соответственно, путем несложных вычислений мы смогли скорректировать наши расчеты. Тут, конечно, важно проверить, а действительно ли мы верим PPS, и готовы ли мы ему верить после таких изменений.
PPS можно использовать для отслеживания утечки купонов.
Для этого достаточно следить за тем, как соотносятся ответы пользователей с теми купонами (лендингами / utm метками… ), которые они используют. К примеру, вы видите, что среди тех, кто отвечает, что увидел вашу рекламу в метро, растет процент тех, кто использует инфлюенсерские промокоды.
Это не тот инструмент, который на 100% закроет проблему с утечкой купонов, а скорее дополнительный сигнал, который можно использовать.
Работы с данными PPS.
У большинства сервисов есть свои API с документацией и примерами. Поэтому после внедрения PPS в ваш продукт (скорее всего, силами разработки), вы сможете собрать нужные графики / дашборды и настроить импорт данных из PPS платформы к себе силами одного аналитика, причем достаточно быстро. По сути вам потребуется база данных, один python скрипт и cron для того, чтобы скрипт запускался и загружал новые данные к вам в базу данных, а дальше уже дело техники связать пользователя / заказ /… с ответом из опроса и рассчитать необходимые метрики.
Надеюсь, что вы найдете эту заметку полезной для себя, и с помощью внедрения PPS (если дойдет до такого) сможете улучшить метрики своего продукта.
P.S. Эта заметка является дополненной версией моего выступления на вебинаре EpicGrowth.