Как масштабировать и оптимизировать расходы на маркетинг с помощью SKAdNetwork?

В этом переводе статьи, описано как, по мнению Eric Seufert, маркетологи могут адаптироваться к изменениям iOS14, чтобы достичь оптимальной эффективности мобильной рекламы.

Общая стратегия, представленная в этой статье, основана на трех основных компонентах:

• Выбор наивысшего значения ценности конверсии (HVCV);
• Расчет LTV и оценка ROAS;
• Оптимизация кампаний и бюджета.

Под HVCV имеются в виду самые важные конверсии с наибольшей ценностью.

Параметр ценности конверсии (conversion value) был добавлен во вторую версию постбэка SKAdNetwork, объявленную на WWDC 2020. Он позволяет разработчикам приложений отправлять 6-битное значение с указанием атрибуции установки обратно в рекламные сети. Ценность конверсии соответствует любому размеченному разработчиком параметру, но постбэк может включать только одно 6-битное значение — наиболее важное, доступное в течение 24 часов и записанное приложением согласно логике окна атрибуции (timer logic). Сама логика окна запутанная: перед дальнейшим чтением статьи рекомендую ознакомиться с этой веткой QuantMar.

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

Это масштабная тема, но в целом, я полагаю, что стратегия использования ценности конверсии позволяет найти компромисс между двумя конкурирующими ограничениями:

• Когда срабатывает ценность конверсии;
• Что представляет собой ценность конверсии.

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

На практике это означает, что в приложении нужно создать корреляцию с высоким LTV пользователя, и использовать метод updateConversionValue() так, чтобы следующие конверсии по ценности были меньше, чем предыдущие, чтобы избежать сброса 24-часового окна ценности конверсии. Это также может объяснить, для чего updateConversionValue() определяет первую сессию пользователя: с помощью нее отмечается время, в течение которого можно отправить постбэк о событии после установки.

Поэтому важно, чтобы рекламодатель спроектировал триггер для ценности конверсии так, чтобы он срабатывал, как только будет собрана достоверная информация о пользователе. Это означает, что для большинства рекламодателей простое сопоставление 6-битных значений ценности конверсии с существующими событиями в приложении не имеет смысла. Сейчас эти события приспособлены для их совокупного сбора и отправки в рекламные сети (то есть, в Facebook и Google), чтобы использовать их при построении профилей монетизации пользователей, индексированных по IDFA. Поскольку с постбэком может быть отправлено только одно значение ценности конверсии, рекламодателям потребуется создавать новые искусственные (синтетические) события, которые предназначены только для фиксации условно рассчитанного LTV или просто для агрегирования по мере того, как пользователи выполняют действия, которые отражают более высокий уровень вовлечения в приложение.

Обратите внимание, что все вышеперечисленное — это работа, которая относится к проектированию и анализу продукта (какие события имеют самый высокий расчетный LTV): SKAdNetwork приближает тренды, о которых я много писал — рекламная стратегия глубоко проникает в продукт, а автоматическая оптимизация кампаний на основе событий преобладает в мобильной рекламе. Ирония в случае со SKAdNetwork заключается в том, что, хотя точность таргетинга этих кампаний без IDFA значительно снижается, вся информация, которые рекламная сеть когда-либо получит от данного пользователя, теперь сосредоточена только в одном значении ценности конверсии (по сравнению с текущей парадигмой, когда источник трафика получает множество событий и может составить более полное представление о пользователе).

Таким образом, проектирование событий для обеспечения максимальной предсказуемости становится еще более важным в SKAdNetwork, потому что у приложения есть только одна возможность передать ценность пользователя рекламной сети. Аналитическая оценка этих событий с очень жестким ограничением сегментации теперь ложится на разработчиков приложений. В отличие от того, что сейчас происходит с MMP-постбэками, приложение не будет получать исходную информацию о пользователе в течение нескольких секунд или минут после установки. Поэтому аналитическая оценка становится основным механизмом оптимизации рекламных кампаний.

Есть несколько способов, которыми разработчик может присвоить LTV какому-либо моменту или состоянию пользователя в приложении. Первый объединяет средние значения на основе условных вероятностей относительно «событий», выполненных пользователем в приложении (как показано на рисунке выше). Примером может быть средний уровень дохода с пользователя приложения при покупке обуви в момент добавления пары обуви в корзину, если до этого они посмотрели 10 пар обуви.

Обратите внимание, что это отличается от парадигмы «событий», которую в настоящее время использует большинство разработчиков для отправки в рекламные сети конкретных действий из приложения (например, «уровень пройден). В новой реальности разработчики приложений сами должны рассчитывать какой LTV присвоить событию; они не могут рассчитывать на то, что рекламные сети сделают это за них. Таким образом, «событие» в данном случае — это не уведомление о том, что пользователь выполнил какое-либо действие, например, добавил товар в корзину, а скорее состояние пользователя, основанное на истории поведения, за счет которого можно спрогнозировать доход. Разработчикам не следует просто оборачивать свою существующую систему передачи событий в метод updateConversionValue() и надеяться на лучшее; скорее, они должны определять, где находятся пользователи, на основе потенциальной монетизации и сопоставлять их положение в приложении с прогнозируемыми LTV.

Как и в приведенном выше примере, можно достичь этого результата путем сопоставления уровней LTV с конкретными 6-битными значениями конверсий и использования онлайн-сервиса для оценки LTV в режиме реального времени по мере продвижения пользователя внутри приложения. Но это непросто. Очень немногие разработчики обладают необходимыми знаниями в предметной области, чтобы построить сервис, дающий надежные прогнозы — эта экспертиза выходит далеко за стандартные границы разработки продукта. Но есть возможность в реальном времени объединять пользователей в диапазоны LTV и обновлять эти оценки в пределах некоторого окна conversion value, чтобы отправлять наиболее надежные и самые свежие value диапазона LTV в течение определенного времени после установки.

Другой подход, представленный выше, состоит в том, чтобы просто сопоставить 6-битные значения конверсии с различными действиями, которые могут быть предприняты пользователями в приложении, и делать оценку LTV на этих действиях постфактум (например, при просмотре агрегированного количества conversion value по данным рекламных сетей). Этот подход проще в реализации, но ему не хватает данных в реальном времени, что важно, поскольку постбэки не могут быть объединены в когорты, а оценка LTV, основанная на конкретных действиях, может значительно измениться со временем.

Чтобы понять, как можно оптимизировать кампании в среде SKAdNetwork, полезно перечислить данные, которые будут доступны рекламным сетям через постбэки SKAdNetwork и их собственные аукционы:

• Стоимость: рекламные сети знают, сколько израсходовано на рекламную кампанию на основе цены за тысячу показов (СРМ) и общее количество выполненных показов;
• Количество показов и кликов: рекламные сети знают, когда были выполнены показы и когда пользователь нажал на объявление;
• Установки: рекламные сети будут получать постбэк установки через SKAdNetwork и могут агрегировать количество установок по идентификатору кампании;

• Ценность конверсии (Conversion value): рекламные сети будут получать значения конверсии для каждой установки через постбэки SKAdNetwork и могут агрегировать количество и ценность конверсий по идентификатору кампании.

Благодаря доступу к этим данным источники трафика смогут нативно оптимизировать кампании по затратам на клики и установки, а также на основе показателей CTR и IR (конверсии в установку). Источники также смогут оптимизировать кампании с учетом возникновения различных значений conversion value, но без какого-либо дополнительной информации (например, нельзя будет сопоставить значение ценности конверсии с вовлечением и событиями с определенной ценностью), поэтому они не смогут оптимизировать ROAS (рентабельность инвестиций в рекламу) или LTV.

Но, у рекламодателей будет: конкретный LTV с привзякой к тому, где и что делает пользователь в приложении, или прогнозируемый диапазон LTV в реальном времени, за счет которого рекламодатели смогут анализировать ценность конверсий на уровне кампании. Это позволит оценить общий доход и, соответственно, измерить ROAS относительно общих расходов на рекламную кампанию.

Однако, у этого подхода к аналитике есть два ограничения:

1. Поскольку данные кампании не объединяются в когорты (как обсуждалось ранее), «новые» данные, которые агрегируются каждый день по инсталлам, не отражают окупаемость по дням и требуется смотреть на совокупные данные по кампании. Первоначальное 24-часовое окно conversion value теоретически можно сбросить 64 раза; если значения conversion value не были тщательно спроектированы для быстрой отправки после первого открытия приложения, то постбэки будут приниматься таким образом, чтобы эффективность не измерялась в реальном времени по дням (например, сегодня я получу 10 постбэков, и каждый из них принадлежит пользователю, установившему приложение в различную дату);
   
2. SKAdNetwork предоставляет только 100 идентификаторов кампании для каждой сети для каждого рекламируемого приложения. Это означает, что кампании должны быть старгетированы достаточно широко, поскольку возможность настроить таргетинг на очень многие комбинации, например, географию, цели по интересам, целевые устройства и рекламные объявления будет ограничена 100 доступными идентификаторами кампании.

В результате большая часть работы по таргетингу и оптимизации, которая в настоящее время «передана на аутсорсинг» крупным рекламным платформам, таким как Google UAC и Facebook, будет возвращена обратно: с помощью автоматического динамического тестирования эффективности кампаний и персонализации приложений.

Один из подходов к измерению, который я наблюдал за несколько недель, прошедших после WWDC, — это вероятностная атрибуция: использование поведенческих профилей с целью связать пользователей с каналом трафика или кампанией, из которой они вероятнее всего получены.

Полагаю, сделать это грамотно будет сложно. Во-первых, любая обучаемая сейчас модель, пока рекламные платформы имеют неограниченный доступ к IDFA и могут таргетироваться на этой основе, мгновенно станет неактуальной при выходе iOS14. Результаты любых проводимых сейчас тестов вероятностной атрибуции, сильно отличается от той, которая образуется после прекращения поддержки IDFA, поэтому не отражают достоверную эффективность. Кроме того, я полагаю, что при включении opt-in трафика будет присутствовать значительный перевес в сторону opt-in, поэтому я не думаю, что обучающие модели по opt-in трафику будут иметь реальные возможности для прогнозирования opt-out трафика. А без возможности обогащать данные для обучения модели успешными результатами прогнозирования, они просто будут отдавать предпочтение каналам, через которые привлекается наиболее ценный трафик для рекламодателя.

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

Вышеописанные стратегии, разумеется, ограничены нехваткой информации о многих аспектах SKAdNetwork: как она развивается с течением времени, что Apple будет делать в отношении fingerprints (отпечатков пальца) и других персональных данных для идентификации (я отношусь к этому с пессимизмом), и какие новые рекламные технологии появятся, чтобы помочь рекламодателям эффективно использовать маркетинговый бюджет.

Использование инфраструктуры SKAdNetwork является относительно низким риском: Apple, похоже, утвердит SKAdNetwork как основной инструмент оценки эффективности рекламы для iOS, и рекламодатели должны понимать, как построить инфраструктуру и стратегию на его основе.

Если вам интересно узнавать больше про аналитику от человека, который сам работает в индустрии рекламы и делится личным опытом – приглашаю вас знакомиться лично в Facebook https://www.facebook.com/gr.kapnin

И вступайте в сообщество по мобильной аналитике https://t.me/mobile_analytics Сообщество направлено на то, чтобы делиться контентом, новыми переводами, обсуждать работу с мобильными трекерами, интеграций, расхождений и трендов вроде iOS14.