よくある質問

When using Tenjin, you’ll notice that there are two types of installs: Reported installsインストール指標 and Tracked Installs.

Reported 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 アドネットワーク. Reported installsインストール指標, 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 Reported installsインストール指標 supposed to be the same as Tracked Installs? Not always. The point of アトリビューション ISN’T to make Tracked Installs = Reported 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:

しかし、これでは意味がありません。獲得したユニークユーザーは 1 人だけでした。ユニークユーザーはいずれかのキャンペーンにのみ関連付けられる必要があります。

That’s what アトリビューション solves. By using a 3rd party アトリビューション provider like Tenjin, Tenjin will place the user into the Tiktok campaign as a “追跡インストール（Tracked Install）” (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 Reported installsインストール指標 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 Spend is. This is the only way you can measure your ROI on an apples-to-apples basis.

したがって、獲得したユーザーが 90日間のLTV2.5ドルを生み出したとします。分析すると次のことがわかります。

In this case ROI = (LTV/Spend -1).

これにより、そのユニークユーザーにとってTiktokキャンペーンがApplovinキャンペーンよりも効果的であることがわかります。

通常、以下の理由により、SANでは最大30%程度の不一致、非SANでは最大10%程度の不一致が予想されます。

• アドネットワーク 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 Reported installsインストール指標.
• アドネットワーク use a different アトリビューションウィンドウ from ours (usually for SANs).

継続率はシンプルなメトリックですが、実際の計算ではいくつかの方法があります。デフォルトの設定だと、Tenjinでは、「クラシック」計算での継続率を採用しています。N日の継続ユーザは、獲得後N日にアプリに戻ってきたユーザです。この解釈には、(1) 絶対時間 (2) 相対時間の二通りがあります。例えば、ユーザが5/1の23:59に獲得され、5/2の00:01にアプリに戻ってきた場合、２分しか経過していません。

• デフォルトの設定だとTenjinでは、相対時間での計算を採用しています。それぞれのユーザには「生涯時間」が存在して、獲得日からの日数で計算されます。獲得日時が0日の起点となり、その24時間後が1日の始まりとなります。 同様に、N日の継続ユーザは獲得日時から24 x N時間から 24 x (N+1)時間内にアプリに戻ってきたユーザとなり、N日継続率はユニークなN日ユーザ / ユニークな0日ユーザとなります。

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日継続ユーザーとは、獲得後24 x N時間から 24 x (N+1)時間の間にアプリに戻ってきたユーザーのことです。

おそらくこれを理解する最良の方法は、下記の例に従うことです。

• ※「9月1日」コホートに属するユーザーは、2015年9月1日 00:00から2015年9月1日 23:59までの間に獲得されたユーザ。
• 最新の「9月1日」ユーザー (ジョーと呼びます) は、2015年9月1日 23:59にアプrをインストールしました。
• ジョーの0 日目は24時間続き、2015年9月2日 23:59 に終了します。
• ジョーが 2015年9月2日 23:59 から 2015年9月3日 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日の終わり (「1 日目」) に取得される可能性があります。彼の0日目 (最初の24 時間) はリテンション (「2 日目」) にはカウントされません。そして最悪の場合、x日目 (「3 日目」) の24 時間の終わりにアプリに戻ってくる可能性があります。

• Tenjinのアプリ内課金がiTunesコネクトやGoogleプレイコンソールの値と違うのはなぜですか?
• それ以上の差異がある場合、下記の可能性が考えられます。
• Tenjinの売上はネット表示となります(アップル/グーグルの30%ストアカット後)
• レシート検証機能を実装していない場合、TenjinがSDKから取得した全てのアプリ内課金を表示するのに対し、一部の売上がアップル/グーグルではリジェクトされている可能性があります。これを解消するには、レシート検証機能を必ず実装してください(iOS SDK)
• 直近でTenjin SDKを実装していて、アプリのアップデートがボランタリーアップデートの場合、一部のユーザはTenjin SDK実装済みのアプリをダウンロードしていないため、全ての売上情報がTenjin上に表示されません。これは時間とともに解消されます。

一般に「Revenue」という場合、コホートと非コホートの2種類のメトリクスがあります。Tenjinではこの二つを明確に区別しています。 「Revenue」は常に非コホート値であり、「LTV」は定義上常にコホート値です。例を見てみましょう。今日が10/20であると仮定します。

この例では、

• トータルRev = $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) も区分されているため、収益がどこから来ているかを確認できます。

Revenueは、選択した日付範囲における毎日のキャッシュフローです。

• 9月1日から9月30日までの日付範囲で、すべてのユーザーがその日付範囲内に発生したアプリアクティビティ (IAPまたは広告収益) に対して94.27ドルの収益を生み出しました。

x日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 インストール.

Revenueがx日の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
• Cool Game
• $20広告収益
• Tenjin SDKからのデータ:
• 4/20/2016
• Cool Game
• 30 Metaセッション
• 40 Googleセッション
• 30 Twitterセッション
• 各ソースチャネルでの収益:
• 4/20/2016
• Cool Game
• $6 Meta広告収益
• $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は、 こちら で説明されているように、iOS 14キャンペーンではMMPインストールではなくSKAN インストールをレポートするため、 tracked_installs と reported_installs.

TenjinとTikTokのアトリビューションの詳細な違いは こちら をご覧ください。

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までお問い合わせください。

インストール時にTenjinによって生成されるUUID（Analytics Installation ID）は、デバイスレベルでは永続的ではありません。したがって、ユーザーがアプリを再インストールすると、Analytics Installation IDがリセットされ、新規インストールの数がカウントされます。これにより、再インストールの頻度によっては、Tracked Installsがわずかに増加する可能性があります。

For インストール Events: Meta usually handles インストール deduplication automatically. So if both Meta SDK and Tenjin report an インストール, it typically only counts once.

アプリ内イベント(購入、収益、広告インプレッションなど)の場合: これらは自動的に重複が除去されません。片方のソースからのみイベントを送信する：アプリ内イベントを送信するには、TenjinまたはMeta SDK のいずれか一方のみを選択してください。両方を選択しないでください。

Meta SDKで自動イベントログを無効にする： MetaのSDKを使用している場合は、autoLogAppEventsEnabledをオフにして、デフォルトで収益/購入イベントが送信されないようにして ください。