FAQ по атрибуции

При использовании Tenjin вы заметите, что есть два типа установок: Установки, о которых сообщается, и отслеживаемые установки.

Заявленные установки — это установки, которые, по утверждению рекламной сети, были привлечены в рамках каждой из ваших кампаний. Отслеживаемые установки — это установки, которые независимая третья сторона относит к кампании рекламной сети с учетом других кампаний, которые вы запускаете в других рекламных сетях. Когда вы анализируете отслеживаемые установки, вы рассматриваете комплексный показатель установок — он основан на данных всех кампаний, даже тех, которые вы запускаете в других рекламных сетях. «Заявленные установки», с другой стороны, рассчитываются в изоляции рекламной сетью, в которой вы размещаетесь — они основаны исключительно на данных, доступных этой рекламной сети.

Значит ли это, что «зарегистрированные установки» должны совпадать с «отслеженными установками»? Не всегда. Цель атрибуции НЕ заключается в том, чтобы «отслеженные установки» равнялись «зарегистрированным установкам». Более того, иногда атрибуция должна делать как раз обратное. Цель атрибуции — получить целостную картину ВСЕЙ активности кампаний в различных рекламных сетях, которые вы используете одновременно, и отнести пользователей к наиболее подходящей кампании. Сделать это может только беспристрастная третья сторона.

Например: Вы запускаете рекламные кампании одновременно в двух рекламных сетях — Applovin и TikTok. Вы установили показатель CPI равным $1.00 для каждой кампании в каждой рекламной сети. Уникальный пользователь кликает по вашей кампании в Applovin, затем позже этот же пользователь кликает по вашей кампании в Tiktok и устанавливает приложение. Что происходит? Как отслеживаются все действия этого пользователя?

Поскольку Applovin и Tiktok не общаются друг с другом, у них нет возможности согласовать уникального пользователя, взаимодействующего с обеими рекламными кампаниями в разных сетях одновременно. В результате счетчик Reported Install для Applovin будет равен “1”, а Reported Install для Tiktok также будет равен “1”. Вот что мы имеем на данный момент:

Но это бессмысленно! Мы приобрели только одного уникального пользователя! Уникальный пользователь должен быть связан только с одной из кампаний!

Именно эту проблему решает система атрибуции. При использовании стороннего поставщика услуг атрибуции, такого как Tenjin, Tenjin отнесёт пользователя к кампании в TikTok как “отслеженную установку” (в данном случае на основе последнего клика). Таким образом, уникальный пользователь, который сначала перешёл по ссылке Applovin, а затем — по ссылке TikTok, будет отнесён к кампании TikTok, а НЕ к кампании Applovin. В данном примере показатели «Отслеживаемых установок» и «Зарегистрированных установок» будут выглядеть следующим образом:

Теперь уникальный пользователь отнесен к соответствующей кампании рекламной сети, что позволяет проводить последующий анализ эффективности ваших кампаний. Если пользователь начинает приносить LTV, вы сможете оценить эффективность своих расходов. Только так можно измерить рентабельность инвестиций (ROI), сравнивая сопоставимые показатели.

Допустим, приобретенный пользователь генерирует 90-дневный LTV в размере $2.5 Ваш анализ покажет следующее:

В этом случае ROI = (LTV/Spend -1).

Это позволит вам узнать, что ваша кампания в Google более эффективна, чем кампания в Facebook, для данного уникального пользователя.

Обычно ожидается расхождение до 30% для SAN и 10% для не-SAN по указанным ниже причинам:

• Рекламные сети игнорируют технологии атрибуции сторонних разработчиков — Meta, Twitter, Google и некоторые другие полагаются на собственные внутренние технологии, чтобы сообщать партнерам по атрибуции, когда установка должна быть зачислена их сетям. Когда аудитории этих сетей пересекаются, сторонние технологии не могут контролировать, не зачтет ли рекламная сеть заявленную установку, даже если технология атрибуции выбирает только одну рекламную сеть для привязки загрузки.
• Неправильная настройка обратных вызовов установки и URL-адресов перехода — Самая легко устранимая из проблем возникает в том случае, когда рекламодатель неправильно настроил URL-адреса перехода и обратные вызовы установки. Обычно эту проблему можно решить сразу, дважды проверив, что используются правильные URL-адреса перехода и что обратный вызов установки в системе атрибуции работает должным образом.
• В SDK рекламных сетей используются неточные методы отслеживания кликов и установок — если рекламная сеть не поддерживает сбор рекламного идентификатора (IDFA или GAID), то сторонние технологии атрибуции, как правило, опираются на вероятностную атрибуцию.
• Дублирование SDK рекламных сетей и систем атрибуции — системы атрибуции отправляют обратные вызовы об установке в рекламные сети, чтобы уведомить их об установке. Если в приложении установлен дублирующийся SDK, который также отправляет обратные вызовы об установке в рекламную сеть, это может привести к двойному учету зарегистрированных установок.
• Рекламные сети используют иное окно атрибуции, чем мы (обычно для SAN).

“Идея ”удержания“ проста, но при ее реализации необходимо учитывать несколько деталей. По умолчанию в Tenjin мы рассчитываем ”классическое" удержание: пользователь, удерживаемый в течение N дней, - это тот, кто возвращается на N-й день после приобретения. День возвращения пользователя может показаться понятным и простым, но на самом деле существует два способа интерпретации этого понятия: (1) с использованием абсолютного времени или (2) с использованием относительного времени. В качестве примера абсолютного времени можно привести пользователя, приобретенного 1 мая и вернувшегося 2 мая, который называется пользователем 1 дня. Однако если этот пользователь был получен в 23:59 1 мая и вернулся в 00:01 2 мая, то на самом деле он ждал возвращения всего 2 минуты.

• В Tenjin по умолчанию используется относительное время. У каждого пользователя есть свой “срок жизни”, исчисляемый в днях после приобретения. Их “рождение” происходит в момент приобретения в день 0, а день 1 начинается 24 часа спустя. Пользователь с N-дневным сроком пребывания - это тот, кто возвращается между 24N часами и 24(N+1) часами после приобретения.

Коэффициент удержания за N дней = количество уникальных пользователей, удержанных в течение N дней / количество уникальных пользователей на 0-й день

• Мы считаем, что использование относительного времени ставит всех пользователей в равные условия, независимо от того, в каком часовом поясе они находятся и каков их циркадный ритм. Кроме того, это позволяет нам “нормализовать” другие показатели, характеризующие весь жизненный цикл пользователя, такие как совокупная выручка, совокупная рентабельность инвестиций (ROI) и стоимость удержания одного пользователя. (ПРИМЕЧАНИЕ) Tenjin теперь поддерживает расчет коэффициента удержания с использованием стратегии когорты на основе UTC. При таком подходе «День 1» начинается в полночь по UTC, следующую за моментом установки приложения каждым пользователем. Этот метод помогает согласовать расчеты коэффициента удержания с другими платформами, использующими временные метки на основе UTC, что снижает расхождения в показателях.

Чтобы включить эту функцию для вашей учетной записи, перейдите в раздел «Моя учетная запись» → «Управление пользователем» → «Стратегия когорты» и выберите нужный вариант.

Как мы видели выше, при варианте относительного удержания пользователь, удерживаемый в течение N дней, - это тот, кто возвращается в период от 24N часов до 24(N+1) часов после приобретения.

Возможно, лучше всего понять это на примере.

• Пользователи, принадлежащие к когорте “Sept 1”, были получены в период с 2015-09-01 00:00 по 2015-09-01 23:59.
• Последний пользователь “Sept 1” (назовем его Джо) мог быть приобретен в 2015-09-01 23:59.
• 0-й день Джо длится 24 часа и заканчивается в 2015-09-02 23:59.
• Если Джо вернется в любое время между 2015-09-02 23:59 и 2015-09-03 23:59, то он будет считаться пользователем, сохранившимся на 1 день.
• Таким образом, показатель удержания за 1 день для когорты “1 сентября” будет окончательно рассчитан только 4 сентября 2015 года в 00:00.

Как правило, коэффициент удержания на x-й день для данной когорты определяется окончательно только ПОСЛЕ истечения (x+2) ПОЛНЫХ дней с момента привлечения. Иными словами, на (x+3)-й день он останется неизменным.

Может показаться странным ждать целых 3 дня, пока этот показатель стабилизируется. Откуда берутся эти дни и как их объяснить? В худшем случае пользователь может быть приобретен в конце дня (“День #1”). Его 0-й день (начальный 24-часовой период) не учитывается при удержании (“День #2”). А в худшем случае он может вернуться в конце 24-часового периода x-го дня (“День #3”).

• Tenjin собирает доход от IAP непосредственно с вашего SDK, в то время как iTunes connect или Google play console показывают их количество непосредственно через покупку в магазине. По нашему опыту, эти доходы могут отличаться на 20%.
• Это возможные варианты, если вы видите большое расхождение.
• Доход Tenjin чистый (после 30% Apple/Google play store cut)
• (Только для iOS) Если вы не подтверждаете квитанции, Tenjin подсчитывает все доходы, которые проходят через наш SDK. Но некоторые доходы могут быть отклонены Apple. Чтобы избежать этого, пожалуйста, убедитесь, что вы используете нашу функцию проверки квитанций (SDK для iOS)
• Если вы недавно интегрировали наш SDK и обновление приложения будет добровольным, у некоторых пользователей еще не будет Tenjin SDK. В этом случае вы не сможете увидеть все доходы в Tenjin. Со временем это должно исчезнуть.

Когда вы говорите “доход”, в общем случае есть два типа дохода - когорта и некогорта. В Tenjin мы проводим четкое различие между этими двумя типами. “Выручка” - это всегда некорпоративное значение, а “LTV” - это всегда когортное значение по определению. Давайте рассмотрим пример. Предположим, сегодня 10/20:

В данном примере,

• Всего оборотов = $94.27
• 90-дневный общий LTV = $91.70

Это означает, что приложение сгенерировало $94,27 от всех пользователей (независимо от того, когда они были приобретены) в сентябре (не когорта), а приложение сгенерировало $91,70 за все время существования от пользователей, которые были приобретены в сентябре (когорта). Доход обычно полезен при управлении ежедневным денежным потоком, а LTV - для измерения рентабельности инвестиций в кампанию.

Пожалуйста, учитывайте эту разницу, когда будете сравнивать показатели Tenjin с показателями, которые вы видите в других инструментах. Мы также разделяем доходы от IAP (или LTV) и доходы от рекламы (или LTV), чтобы вы могли видеть, из чего складывается ваш доход.

Выручка - это ежедневный денежный поток за выбранный диапазон дат.

• Заданный диапазон дат с 1 по 30 сентября, все пользователи получили $94,27 дохода за активность в приложении (IAP или рекламный доход), которая произошла в этот диапазон дат

x-day LTV - это доход, полученный от пользователей, приобретенных (установивших приложение) в течение выбранного диапазона дат, как совокупный итог за X дней после установки приложения.

• Важно понимать, что означает “сегодня” в контексте выбранного диапазона дат, поскольку необходимо знать, насколько “старые” пользователи входят в этот диапазон. Если сегодня 20 октября, а заданный диапазон дат — 1–30 сентября, то ваши “самые старые” пользователи “старые” на 50 дней (20 октября минус 1 сентября), а «самые молодые» — на 20 дней. Общая 90-дневная LTV, равная $91,70, представляет собой всю выручку, сгенерированную пользователями в 30 когортах (каждый день сентября). Следовательно, учитывая этот диапазон дат в примере, показатели LTV за 50 дней, 51 день…, 89 дней и 90 дней будут иметь одинаковое значение, поскольку ваши самые старые пользователи способны генерировать доход только в течение 50 дней после установки.

Будет ли доход когда-нибудь равен x-day LTV?

Скорее всего, нет. Для этого необходимо, чтобы у ВСЕХ пользователей дата установки пришлась ИМЕННО на один и тот же день по UTC (с 00:00 до 23:59). Такое крайне маловероятно.

Расхождения между показателями DAU в Tenjin и Firebase вполне ожидаемы, поскольку на этих платформах используется разная логика подсчёта и отслеживания установок и DAU. В Tenjin мы используем первое событие app_open в качестве события установки, а все последующие события app_open регистрируются как сеансы. Также рекомендуется всегда использовать последнюю версию SDK Tenjin и инициализировать его при каждом вызове OnResume. Если вы по-прежнему наблюдаете значительные расхождения в данных, напишите нам по адресу support@tenjin.com с подробной информацией для дальнейшего расследования.

UUID (идентификатор установки Analytics), генерируемый Tenjin во время установки, не сохраняется на уровне устройства. Следовательно, когда пользователь переустанавливает приложение, идентификатор установки Analytics сбрасывается, что приводит к подсчету новых установок. Это может привести к небольшому увеличению количества отслеживаемых установок в зависимости от частоты повторных установок.

Если вы хотите, чтобы для вашего приложения отображался показатель ‘Отслеживаемые повторные установки’, пожалуйста, напишите на адрес support@tenjin.com. В настоящее время такие повторные установки будут относиться исключительно к органическому трафику.

Что касается событий установки: Meta обычно автоматически устраняет дубликаты данных об установках. Поэтому, если об установке сообщают и Meta SDK, и Tenjin, она, как правило, учитывается только один раз.

Для событий In-App (например, покупок, доходов или показов рекламы): Они не дедуплицируются автоматически. Отправляйте события только из одного источника: Выберите Tenjin или Meta SDK для отправки событий в приложении, не выбирайте оба источника.

Отключите автоматическую регистрацию событий в Meta SDK: Если вы используете SDK Meta, отключите autoLogAppEventsEnabled, чтобы он не отправлял события о доходах/покупках по умолчанию.

Да! Tenjin поддерживает функцию атрибуции для Meta Instant Games. Чтобы узнать подробные инструкции по настройке этой функции, обратитесь в службу поддержки Tenjin по адресу support@tenjin.com