When using Tenjin, you’ll notice that there are two types of installs: 1. Reported Installs and 2. Tracked Installs. Reported Installs are installs that the ad network claims to drive for each of your campaigns. 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 ad networks. When looking at Tracked Installs, you are looking at an install metric that is holistic - it’s based on all campaigns, even ones that you’re running on other ad networks. 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 attribution ISN’T to make Tracked Installs = Reported Installs. In fact, sometimes attribution is supposed to do the exact opposite. The point of attribution is to take a holistic view of ALL the campaign activity on the various ad networks you’re using at the same time, and attribute users to the most appropriate campaign. Only an unbiased 3rd party can do this.
- Ad networks ignore 3rd party attribution technology. Facebook, Twitter, Google and a few others rely on their own internal technology to let attribution partners know when an install 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 Install even when the attribution technology only picks one ad network to associate the download with.
- Install callbacks and click URLs are not set up properly. The most fixable of the problems is when click URLs and install callbacks 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 install callback in the attribution technology is functioning properly.
- Inaccurate methods for tracking clicks and installs are used with ad network SDKs.
- Doubling up on ad network and attribution SDKs. Attribution systems send install callbacks to ad networks to notify an ad network of an install. If the app has a duplicate SDK that sends an ad network install callbacks, there can be double counting of Reported Installs.
“Retention” is a simple idea, but there are several details to consider when implementing it. At Tenjin, we calculate “classic” retention: an N-day retained user is one who returns on the Nth day after acquisition. The day a user returns may seem clear and simple, but there are actually 2 ways to interpret this: (1) using absolute time or (2) using relative time. As an example of absolute time, a user acquired on May 1st and returning on May 2nd is called a 1-day user. However, if that user was acquired at 23:59 May 1 and returned at 00:01 May 2, they really only waited 2 minutes to return.
At Tenjin, we use relative time. Each user has their own “lifetime”, as counted in days after acquisition time. Their “birth” is at acquisition on day 0, and day 1 begins 24 hours later. an N-day retained user is one who returns between 24N hours and 24(N+1) hours after acquisition the N-day retention rate = 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.
- Tenjin collects IAP revenue directly from your SDK, whereas iTunes connect or Google play console shows their number directly through the store purchase. Based on our experience, those revenue could be different by up to 20%.
These are the possibilities if you see a large discrepancy.
- Tenjin’s revenue is net(after 30% Apple/Google play store cut)
- (Only for iOS) If you don’t validate receipts, Tenjin counts all revenue that gets passed through our SDK. But some revenue may be rejected by Apple. To avoid this, please make sure to use our receipt validation (iOS SDK)
- If you newly integrate our SDK and the app update is voluntary, some users won’t have Tenjin SDK yet. In that case you won’t see all revenue in Tenjin. This should go away as time goes by.
- All the reporting data is shown in UTC.
- The User Acquisition and Ad Monetization tabs show a timestamp that show when the report was updated last time at the top. This time is shown in your local timezone.
- The most common reason your User Acquisition dashboard may have an Unavailable Channel or Unavailable Campaign is because there is ad revenue that can’t be attributed to users of a specific channel or campaign. This happens when an ad network reports ad revenue for a specific country, but we don’t see any events from users in that country.
- If you set up Facebook or Google channel properly but don't see the spend on the dashboard yet, please make sure you add the ad account id you are trying to pull spend for. The instruction is here.
Under the main menu, select My Account-> GDPR Requests. You can either enter data manually or upload a CSV if there are multiple requests.
- This is because we fail to pull spend or ad revenue data from ad-network API in the last attempt. The most common reasons are:
- Credentials used to pull the data are no longer valid. This could happen when the password on ad network dashboard is updated, or the user who authenticated accounts before is no longer in the company.
- One-time server error in Ad network side. In this case, we will be able to pull the data in the next attempt.
- If ad account has not been working for 1 month, we will automatically suspend the ad account. Since then, we won't try to pull the data anymore. In order to fix it,