На планёрке сервиса доставки продуктов маркетолог предлагает перевести бюджет в TikTok: установка там стоит 300 ₸, а в среднем по сетям 500 ₸. Продакт отвечает цифрой из того же AppsFlyer: из 3 000 человек, которые поставили приложение из TikTok в сентябре, первый заказ за неделю сделали 150, каждый двадцатый. Спорят на самом деле об остальных 2 850, и рассудить спор могут только события между установкой и заказом. Приложение и цифры те же, что в уроке про MMP на практике, и они условные.
CPI - цена установки, а не покупателя
CPI говорит, сколько стоила установка, и больше ничего. Человек мог открыть приложение и сразу закрыть, узнать, что в его город не доставляют, или дойти до корзины и передумать. Поэтому установку связывают с тем, что человек сделал потом: закончил ли регистрацию, заказал ли, вернулся ли за вторым заказом. Эти шаги и есть in-app события. AppsFlyer записывает каждое из них на сеть, которая привела установку, и держит эту связь, пока человек пользуется приложением, у пользователей из Meta до 180 дней (обзор in-app событий AppsFlyer, расхождения с Meta).
AppsFlyer советует начинать с трёх-пяти таких событий, по которым судят о качестве пользователей, и доставке продуктов хватит четырёх.
План событий: от регистрации до второго заказа
Первый заказ first_purchase и повторный purchase настроены по уроку про MMP. В том же августовском релизе SDK план добавил к ним то, что происходит до первого заказа, и способ считать возвраты.
Активация. Регистрация в приложении - это номер телефона, код из SMS и адрес доставки. Сервис возит продукты только по Алматы и Астане, и с адресом вне зоны регистрация не заканчивается: приложение так и пишет и отправляет другое событие, address_out_of_zone. Значит, законченная регистрация sign_up и есть активация, после неё человек может заказать.
Повторный заказ. purchase уходит только на второй и следующие заказы, поэтому каждый уникальный пользователь с purchase - покупатель, который вернулся. Удержание (retention) в отчётах AppsFlyer считается по сессиям, то есть по доле тех, кто открыл приложение в нужный день (метрики My Dashboards). Но открыть приложение доставки и посмотреть цены ещё не значит заказать, поэтому удержание здесь меряют повторным заказом.
| Событие | Когда отправляется | Параметры | Куда |
|---|---|---|---|
view_item, add_to_cart, begin_checkout | Шаги к заказу, как в воронке из урока про аналитику приложения | Товар и сумма | Firebase |
sign_up | Сервер создал аккаунт: номер подтверждён, адрес в зоне доставки | method = phone | Firebase и AppsFlyer |
address_out_of_zone | Сервер ответил, что по этому адресу не доставляют | city | Firebase и AppsFlyer |
first_purchase | Первый оплаченный заказ клиента | Сумма, валюта, номер заказа | Firebase и AppsFlyer |
purchase | Второй и каждый следующий оплаченный заказ | Сумма, валюта, номер заказа | Firebase и AppsFlyer |
В Firebase уходит всё, в AppsFlyer только то, что нужно сетям и отчёту по источникам. Параметры событий AppsFlyer показывает только в сырых данных, а это платная функция, поэтому город из city смотрят в Firebase. А вот число людей с адресом вне зоны по каждой сети видно в обычном дашборде, потому что address_out_of_zone - отдельное событие. Отсюда правило: что нужно видеть по сетям, делают событием, а подробности кладут в параметры.
Событие - это факт, а не нажатие
sign_up отправляют по ответу сервера, что аккаунт создан, а не по нажатию «Продолжить» на экране адреса. Нажать его можно и с адресом в Шымкенте, и тогда в активированных окажутся люди, которым сервис ничего не привезёт. С покупками так же: first_purchase и purchase уходят, когда оплата картой подтверждена или курьер закрыл заказ, а не по нажатию «Оформить». Оплату курьеру приложение не видит, поэтому такие заказы отправляет сервер, как в интеграции SDK.
На схеме та же граница между намерением и фактом, только на подписке: продление выключено 9 сентября, а доступ действует до 30-го.
Продление выключено, доступ ещё есть
9 сентября
Продление выключено
Оплаченный период
Доступ ещё открыт
30 сентября
Оплаченный период заканчивается
Как назвать события
Имя события живёт в коде двух приложений, в Firebase, в AppsFlyer и в настройках каждой сети, и переименовать его дорого: старые версии приложения ещё месяцами шлют старое имя.
- Рекомендованное имя, если смысл совпадает. Под рекомендованные события GA4 строит отчёты и аудитории (рекомендованные события), так что
sign_up,view_item,add_to_cartиbegin_checkoutберут оттуда. - Своё имя, когда рекомендованного нет.
first_purchaseиaddress_out_of_zoneсвои. AppsFlyer советует по возможности брать его встроенные имена вродеaf_purchase: их проще сопоставлять с событиями сетей. Сервис взял имена как в Firebase, поэтому сопоставляет их вручную. - Формат. GA4 разрешает буквы, цифры и подчёркивание, первой идёт буква, без пробелов (правила имён в GA4). Сверх этого договоритесь писать строчной латиницей: регистр различают и GA4, и AppsFlyer, и
Sign_upсsign_upдля них два разных события. Длина до 40 символов: это предел GA4 (лимиты сбора), и столько же Meta принимает в событиях от AppsFlyer (интеграция с Meta). - Одно имя на iOS и Android. AppsFlyer советует держать одинаковые имена и структуру событий на всех платформах.
- Без персональных данных. Телефона, имени и адреса в параметрах нет, хватит
city. AppsFlyer прямо просит не класть в события данные, по которым можно узнать человека.
У своего имени first_purchase есть цена: отчёты электронной торговли GA4 считают покупками только purchase (метрики электронной торговли), и первые заказы в них не попадут. Их выручку берут из AppsFlyer и системы заказов.
Где теряются люди из TikTok
Вот сентябрьская когорта через неделю после установки. Установки, расход и первые заказы взяты из урока про MMP, регистрации - это уникальные пользователи sign_up за D7 в том же отчёте My Dashboards.
| Сеть | Установки | CPI | Регистрации | Расход на регистрацию | Первые заказы, D7 | Расход на первый заказ |
|---|---|---|---|---|---|---|
| Meta | 4 000 | 500 ₸ | 1 600 | 1 250 ₸ | 400 | 5 000 ₸ |
| TikTok | 3 000 | 300 ₸ | 600 | 1 500 ₸ | 150 | 6 000 ₸ |
| Google App campaigns | 2 000 | 600 ₸ | 1 000 | 1 200 ₸ | 300 | 4 000 ₸ |
| Apple Ads | 1 000 | 900 ₸ | 500 | 1 800 ₸ | 150 | 6 000 ₸ |
| Всего | 10 000 | 500 ₸ | 3 700 | 1 351 ₸ | 1 000 | 5 000 ₸ |
В TikTok регистрацию закончил каждый пятый установивший, в Meta 40%, в Google и Apple Ads каждый второй. Дальше разрыв намного меньше: из зарегистрированных первый заказ сделали 25% в TikTok и Meta и по 30% в Google и Apple Ads. Выходит, TikTok теряет людей в основном до регистрации. И по расходу на регистрацию он уже не самый дешёвый: 1 500 ₸ против 1 200-1 250 ₸ у Google и Meta.
Часть причины показывает address_out_of_zone. Адрес, куда сервис не возит, ввели 1 200 человек из TikTok, 300 из Meta, 60 из Google и 40 из Apple Ads. Получается, 40% установивших из TikTok указали адрес там, куда доставки нет, и заказать эти люди не могли в любом случае. Почему из остальных 1 800 зарегистрировались только 600, четыре события в MMP не скажут. Ответ даст воронка по экранам с источником установки, а два способа передать источник в продуктовую аналитику описывает урок про аналитику мобильного приложения.
Отсюда два шага для TikTok: сузить географию кампании до Алматы и Астаны, если там весь Казахстан, и сменить событие, на котором кампания учится.
Какое событие отдать каждой сети
В сентябре кампания TikTok оптимизировалась на установки. Алгоритм искал людей, которые поставят приложение, и ему было всё равно, есть ли у них доставка: сеть учится на том событии, которое вы ей передали.
Событие выбирают по близости к деньгам и по тому, наберёт ли сеть столько таких событий, чтобы обучиться:
- Meta ставит группе объявлений статус «Недостаточно результатов» (Learning limited), если та вряд ли получит около 50 событий оптимизации за неделю после последнего существенного изменения, и советует объединять группы или брать событие почаще (Learning limited).
- TikTok пишет, что колебания обычно затихают примерно после 25 результатов или 7 дней обучения (обучение в TikTok).
Для сентябрьских цифр это значит:
| Сеть | Событие для оптимизации | Почему |
|---|---|---|
| Meta | first_purchase, сопоставлен с Purchase | 400 первых заказов в месяц, около 90 в неделю. Одной группе объявлений хватает, а у трёх групп будет примерно по 30, меньше порога |
| TikTok | sign_up, сопоставлен с Registration | Первых заказов около 35 в неделю, а если поделить бюджет пополам между старой и новой группой, у новой будет около 17, меньше 25. Регистраций около 140 в неделю, у новой группы около 70, и все с адресом в зоне доставки |
| Google App campaigns | first_purchase | Со стратегией «Целевая цена за конверсию» Google советует бюджет хотя бы в 10 раз больше целевой цены. При цене 4 000 ₸ это от 40 000 ₸ в день, ровно сентябрьские 1 200 000 ₸ в месяц |
| Apple Ads | Ничего | Интеграция Apple Ads в AppsFlyer постбэков не поддерживает (настройка Apple Ads) |
На своих (custom) событиях TikTok не оптимизирует, а только показывает их в отчётах (интеграция TikTok в AppsFlyer), поэтому sign_up сопоставляют со стандартным Registration, которое оптимизацию поддерживает (события приложений в TikTok). first_purchase TikTok тоже получает, как Purchase, и когда заказов хватит для обучения, кампанию переведут на них. Старую группу оставляют на установках, но тоже только на Алматы и Астану, а рядом запускают новую на sign_up: через месяц будет с чем сравнить.
В Google в кампании остаётся одно действие, first_purchase, и до первых 100 конверсий кампанию не правят (рекомендации Google). Действие приходит из одного источника, Firebase или AppsFlyer, иначе один заказ попадёт в два действия. Для ставок по сумме заказа источник важен: стратегия «Целевая рентабельность инвестиций в рекламу» требует SDK Google Аналитики для Firebase (ставки в кампаниях для приложений), а события с выручкой из AppsFlyer для неё не подходят (интеграция с Google Ads).
Повторные заказы purchase с суммой отправляют Meta и TikTok своим событием, не сопоставляя с Purchase: иначе сеть сложит их с первыми заказами и начнёт учиться на постоянных покупателях. AppsFlyer умеет отправлять события в обе сети и под своим именем, без сопоставления (Meta, TikTok). На iPhone без согласия на отслеживание часть заказов сеть видит только через SKAN.
Повторный заказ по источникам
К концу октября сентябрьской когорте исполнилось 30 дней. В том же отчёте My Dashboards поменяйте период на D30 и добавьте уникальных пользователей purchase.
| Сеть | Первые заказы, D30 | Расход на первый заказ | Повторили заказ, D30 | Доля повторивших |
|---|---|---|---|---|
| Meta | 460 | 4 348 ₸ | 170 | 37% |
| TikTok | 190 | 4 737 ₸ | 60 | 32% |
| Google App campaigns | 350 | 3 429 ₸ | 140 | 40% |
| Apple Ads | 170 | 5 294 ₸ | 70 | 41% |
| Всего | 1 170 | 4 274 ₸ | 440 | 38% |
На вопрос из урока про MMP ответ получился двойной. Люди из TikTok действительно заказывают позже: после первой недели пришла пятая часть его первых заказов, у других сетей 12-14%, и первый заказ подешевел с 6 000 до 4 737 ₸. Но и на D30 он дороже, чем из Google и Meta. Повторный заказ сделали 32% покупателей из TikTok против 37-41% у остальных. На 190 покупателях такой разрыв на грани случайного (p около 0,06 против остальных сетей вместе), и вывод «возвращаются реже» пока не сделать.
Для решения по бюджету картина такая: TikTok теряет людей до регистрации, а по дошедшим до заказа разницы с другими сетями пока не видно. Урезать TikTok из-за слабой первой недели было бы ошибкой, перевести в него бюджет из-за дешёвых установок - тоже. Чинят географию и событие оптимизации и смотрят следующую когорту. Повторные заказы здесь главное: по расчёту из урока про mobile-first привлечение окупается только на пятом заказе покупателя, LTV по таким когортам считают как в когортном анализе, а как вернуть тех, кто второй раз не заказал, - в уроке про пуши и retention.
Задание: план событий для своего приложения
Возьмите приложение, с которым работаете, или сервис доставки из урока.
Выполнено 0 из 4
Теперь ситуация. Команда не стала держать две группы и в октябре перевела весь бюджет TikTok на новую: география Алматы и Астана, оптимизация на sign_up. Через месяц у неё 2 000 установок на те же 900 000 ₸, 800 регистраций и 200 первых заказов за первую неделю после установки (D7). Маркетолог пишет: «CPI вырос с 300 до 450 ₸, новая настройка хуже старой». Что вы ответите?
Установки подорожали, а всё, что после них, подешевело. Регистрация стоит 1 125 ₸ вместо 1 500 ₸, первый заказ за неделю 4 500 ₸ вместо 6 000 ₸. Судить о группе по CPI - та же ошибка, с которой начался урок, только наоборот: дешёвые установки не дали хороших покупателей, и дорогие не обязательно дадут плохих. Стало ли лучше, покажут расход на первый заказ к D30, а за ним доля повторных заказов.
Записывать улучшение на смену события тоже рано. В октябре поменяли сразу географию и событие оптимизации, а спрос в октябре мог быть другим, так что по одному месяцу не понять, что сработало. Для этого и нужны были две группы на одной географии: их сравнивают на одних и тех же неделях.
Видео: сбор данных приложения в Google Analytics
Урок Analytics Academy на английском: как подключить сбор данных приложения в Google Analytics.