{"id":13595,"url":"\/distributions\/13595\/click?bit=1&hash=0578f662a4e99e0a477083ff538dcc87ef422d22dc979e88ddacc35e13f6995c","title":"\u041b\u044e\u0431\u0438\u0442\u0435 \u0441\u0430\u043b\u0430\u0442\u0438\u043a? \u0415\u0433\u043e \u0434\u043b\u044f \u0432\u0430\u0441 \u0441\u043e\u0431\u0440\u0430\u043b \u0432\u043e\u0442 \u044d\u0442\u043e\u0442 \u043c\u0438\u043b\u044b\u0439 \u0440\u043e\u0431\u043e\u0442","buttonText":"\u041f\u043e\u043a\u0430\u0436\u0438\u0442\u0435","imageUuid":"f0cac355-ac0f-5d0f-a8ce-eb75ae2b39ea","isPaidAndBannersEnabled":false}

Атрибуция с помощью PPS в эру SKAN

Всем привет! Меня зовут Подольский Александр, и последние 8 лет я занимаюсь аналитикой. В этой заметке я хочу рассказать про такой старый инструмент, как опросы (а именно, опросы после покупки), который может оказаться очень полезным для атрибуции, когда между пользователем и вашем продуктом появился SKAN.

Перенесемся во времена до введения SKAN.

Для отдела маркетинга при решении задачи атрибуции было 2 вызова:

  1. Атрибуция оффлайн каналов – сложно / дорого / спорно.
  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:

  1. Опрос должен отрисовываться быстро – у вас есть буквально несколько секунд (а то и десятых секунд) внимания пользователя после заказа (важного события) , в которые еще хочется впихнуть вопрос, время на подумать и ответ. Если экран с опросом будет грузиться долго, то пользователь без какого-либо зазрения совести просто закроет/свернет приложение, ведь заказ-то уже оформлен. Аналогично стоит учитывать то, как выглядит экран с опросами, и не допускать скролла. Опять же, вы просите пользователя помочь вам, он за это не получает никакой выгоды (хороший вопрос, стоит ли мотивировать пользователя, кажется, что нет, но тут, наверное, лучше обратиться к социологии), ровно поэтому никто не захочет скроллить или иметь дело с неудобной версткой.
  2. "Простые вопросы – простые ответы" – как уже было отмечено выше, ресурс внимания пользователя крайне ограничен, поэтому вопрос должен быть сформулирован максимально коротко и понятно, аналогично и ответы. Иначе пользователь либо пропустит опрос, либо будет делать все, чтобы от него "отстали" (что напрямую отразится на качестве ваших данных).
  3. Настройте отправку идентификатора пользователя / заказа /…, чтобы в дальнейшем иметь возможность связать ответ с конкретным пользователем / заказом /… .
  4. Перемешивайте ответы – пользователи не помнят / кликают на первый попавшийся вариант / врут, поэтому для того, чтобы хоть как-то минимизировать влияние на конечные данные, надо постоянно перемешивать ответы.
  5. Добавьте поле "Другое" – текстовое поле со свободным вводом, такие ответы бывает крайне полезно читать, потому что иногда там можно найти то, о чем вы не догадывались. К примеру, когда я работал во 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.

0
Комментарии
Читать все 0 комментариев
null