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

When using Tenjin, you’ll notice that there are two types of installs: Зарегистрированные установки and Tracked Installs.

Зарегистрированные установки это установки, которые рекламная сеть заявляет для каждой из ваших кампаний. Отслеживаемые установки are installs that an unbiased 3rd party attributes to an ad network’s campaign, taking into account the other campaigns you’re running on other Рекламные сети. When looking at Tracked Installs, you are looking at an Установите metric that is holistic – it’s based on all campaigns, even ones that you’re running on other Рекламные сети. Зарегистрированные установки, on the other hand, is calculated in a vacuum by the ad network you’re running on – it’s only based on what that ad network sees.

So are Зарегистрированные установки supposed to be the same as Tracked Installs? Not always. The point of Атрибуция ISN’T to make Tracked Installs = Зарегистрированные установки. In fact, sometimes Атрибуция is supposed to do the exact opposite. The point of Атрибуция is to take a holistic view of ALL the campaign activity on the various Рекламные сети you’re using at the same time, and attribute users to the most appropriate campaign. Only an unbiased 3rd party can do this.

Например: You’re running campaigns on two Рекламные сети at the same time, Applovin and Tiktok. You set the CPIs to $1.00 for each campaign on each ad network. A unique user clicks on your Applovin campaign, then later that same user clicks on your Tiktok campaign, then installs the app. What happens? How is everything tracked for that user?

Since Applovin and Tiktok don’t talk to each other, there is no way for them to reconcile the unique user interacting with both ad campaigns on separate networks at the same time. As a result, the Reported Установите count for Applovin would be “1” and the Reported Установите count for Tiktok would be “1” also. Here’s what we have so far:

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

That’s what Атрибуция solves. By using a 3rd party Атрибуция provider like Tenjin, Tenjin will place the user into the Tiktok campaign as a “Установка с гусеницами” (based on the last click in this case). This way, the unique user who clicked on Applovin and then Tiktok will be associated with Tiktok’s campaign and NOT Applovin’s. In this example the count for Tracked Installs and Зарегистрированные установки would look like this:

Now the unique user is in the appropriate ad network campaign for downstream analysis of your campaigns. If the user starts generating LTV, then you know what the effectiveness of your Провести is. This is the only way you can measure your ROI on an apples-to-apples basis.

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

In this case ROI = (LTV/Провести -1).

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

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

• Рекламные сети ignore 3rd party Атрибуция technology – Meta, Twitter, Google and a few others rely on their own internal technology to let Атрибуция partners know when an Установите should be awarded to their networks. When users for these networks overlap, the 3rd party technology can’t control if the ad network claims a Reported Установите even when the Атрибуция technology only picks one ad network to associate the download with.
• Установите Обратные вызовы and click URLs are not set up properly – The most fixable of the problems is when click URLs and Установите Обратные вызовы are set up improperly by the advertiser. This can usually get fixed right away by double checking that the proper click URLs are getting used and the Установите callback in the Атрибуция technology is functioning properly.
• Inaccurate methods for tracking clicks and installs are used with ad network SDKs – When an ad network does not support collection of an advertising ID (IDFA or GAID), then the 3rd party Атрибуция technology will generally rely on probablistic Атрибуция.
• Doubling up on ad network and Атрибуция SDKs – Атрибуция systems send Установите Обратные вызовы to Рекламные сети to notify an ad network of an Установите. If the app has a duplicate SDK that sends an ad network Установите Обратные вызовы, there can be double counting of Зарегистрированные установки.
• Рекламные сети use a different Окно атрибуции from ours (usually for SANs).

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

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

the N-day Коэффициент удержания = unique N-day retained users / unique 0-day users

• We believe using relative time puts all users on equal footing, no matter what time zone they may be in, or what their circadian rhythm might be. It also enables us to “normalize” our other lifetime metrics, such as cumulative revenue, cumulative ROI, and cost-per-retained user. (NOTE) Tenjin now supports Коэффициент удержания calculation using the UTC-based cohort strategy. With this approach, Day 1 begins at the first UTC midnight following each user’s Установите timestamp. This method helps align Коэффициент удержания calculations with other platforms that use UTC-based timestamps, reducing discrepancies in metrics.

To enable this feature for your account, navigate to My Account → Manage User → Cohort Strategy and select the desired option.

Как мы видели выше, при варианте относительного удержания пользователь, удерживаемый в течение 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 день.
• Therefore, the 1-day Коэффициент удержания for the “Sept 1” cohort is not finalized until 2015-09-04 00:00.

In general, the x-day Коэффициент удержания for a given cohort is not finalized until AFTER (x+2) FULL days after acquisition. Or in other words, on the (x+3)th day it will remain constant.

Может показаться странным ждать целых 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

This means the app generated $94.27 from all users (regardless of when those users were acquired) in September (non-cohort), and the app generated $91.70 in the lifetime from the users that were acquired in September (cohort). Revenue is usually useful when you manage daily cashflow and LTV is to measure your campaign ROI.

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

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

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

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

• It is important to know what “today” is, in relation to the selected date range because you need to know how “old” the included users are. If today is Oct 20 and the given date range is Sept 1-30, your “oldest” users are 50 days old (Oct 20 minus Sept 1), and your “youngest” users are 20 days old. The 90-day LTV total of $91.70 is all the revenue generated by users in 30 cohorts (each day of September). Consequently, given this date range in the example, 50-day LTV, 51-day LTV …, 89-day LTV, and 90-day LTV would all be the same value, since your oldest users are only able to generate 50 days of revenue after the Установите.

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

Probably not. You would need ALL users in a single UTC day (00:00 to 23:59) to have EXACTLY the same Установите date. This is extremely unlikely.

The assumption here is that your app is based on in-app ads.

• Currently, one of the main ways Tenjin allocates ad revenue is by using the sesion counts from SDK to calculate LTV or ROAS. This total must be somehow distributed and assigned to each user’s source channel. We use the proportion of app sessions generated by the user (on that day, in that app) to estimate how much ad revenue to assign to each source channel.
• Например,
• Data from publisher API:
• 4/20/2016
• Классная игра
• Доходы от рекламы $20
• Данные из Tenjin SDK:
• 4/20/2016
• Классная игра
• 30 мета-сессий
• 40 сеансов Google
• 30 сессий в Twitter
• Предполагаемый доход от рекламы для каждого канала-источника:
• 4/20/2016
• Классная игра
• $6 Доход от метарекламы
• $8 Доходы от рекламы Google
• $6 Доходы от рекламы в Twitter
• Когортный доход от рекламы немного сложнее, но использует тот же метод оценки. При определении доли сессий приложений также учитывается день приобретения и n-й день жизни пользователя.
• However, AppLovin uses impression-level ad revenue(ILRD) to calculate LTV or ROAS. In general, their ROAS is higher than Tenjin ROAS based on the allocation logic.

We now support Ad Mediation LTV and ROAS. You can use the Ad Mediation ROAS metric from the Tenjin dashboard which will be closer to your Applovin MAX ROAS. Details здесь.

• TikTok сообщает об установках SKAN, а не об установках MMP для кампаний SKAN для iOS 14, как описано выше здесь поэтому наш отслеживаемые_установки не будет точно совпадать с сообщенные_установки.

Please find the detailed differences between Tenjin and TikTok Attribution here

Discrepancy between Tenjin DAU and Firebase DAU numbers are expected as the logic used for counting and tracking installs and DAU is different in both platforms. In Tenjin, we use the first app_open event as the Установите event and all subsequent app_open events are recorded for sessions. It is also recommended to always use the latest Tenjin SDK and initialize it on every OnResume. If you continue to see large data discrepancies, email us at support@tenjin.com with details to investigate further.

A discrepancy between Tenjin 0D ROAS and Mintegral 0D ROAS is expected due to the different methodologies utilized for ROAS calculations between the two platforms.

• IAA ROAS:

Tenjin employs a Сессия-based aggregation method to compute Ad revenue LTV and ROAS. Conversely, Mintegral used the ILRD-based revenue approach for its ROAS calculations. This distinction leads to an expected discrepancy of approximately 30%.

• IAP ROAS:

Tenjin calculates the LTV and ROAS based on the net IAP amount (after 30% or 15% app-store commission, contingent upon the store-cut you’ve configured in Tenjin). In contrast, Mintegral adopts the gross IAP amount for its ROAS calculations, resulting in a discrepancy of upto 30%.

Upon successful configuration and setup, you should be able to start ROAS campaigns with Mintegral, despite the expected discrepancies.

За дополнительными разъяснениями или информацией обращайтесь к нам по адресу support@tenjin.com.

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

For Установите Events: Meta usually handles Установите deduplication automatically. So if both Meta SDK and Tenjin report an Установите, it typically only counts once.

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

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