Tracking Mobile App Installs for Android

Part of this article relates to our Attribution Analytics product, formerly branded as Mobile App Tracking, which was acquired by Branch in September 2018 and is being integrated into Branch Universal Ads. To learn more about Branch Universal Ads, please visit branch.io/universal-ads/.

2019 Update: HasOffers has rebranded to TUNE! The TUNE Partner Marketing Platform is the same great technology behind HasOffers, now enhanced with new tools and features for networks and advertisers. Read the rebrand announcement here or head to our homepage to learn more.

---

Many of you have seen or heard about our new platform for tracking mobile app installs called — you guessed it — Mobile App Tracking. It just so happens our actual “Hello, world!” is today.  You can check out a new website and video explanation at MobileAppTracking.com.

So, I figured today’s press launch would be an excellent occasion to talk about the strategies behind tracking mobile app installs.  Though I’m only going to focus on tracking Android apps today (saving iPhone for later), if you’re half the nerd we are about tracking, you should find this pretty interesting.  So put on your really thick glasses because this post is about to get a little bit technical.

What’s So Special About Tracking App Installs?

Believe it or not, cookie tracking doesn’t work on mobile.  So what are people using to track app installs to figure out which advertising and marketing channels are sending the best traffic?  Anybody?  I know!  We couldn’t believe it either.  On Android devices, where the user came from is obscured as soon as they enter the Android Market.  On iPhones and iPads, they’re obscured by the iTunes AppStore.  Then, there are several third-party marketplaces for mobile apps.  Once a user clicks into any app store environment, their actions enter a black hole and we can no longer determine who was responsible for generating an install of a free app or a purchase of a paid app.  This is exactly why for the last eight months we’ve been working on solving this problem with Mobile App Tracking.

Tracking Android App Installs With Referral Data

Recently, Google made it a little easier by making some updates to the Android platform, allowing a small amount of data to be passed into the Android Market and accessed after an app is installed.  The Android Market actually passes the URL of the referral to the mobile app on download, and once the user installs the app, you can access the referral URL.  The cool part about this is that HasOffers can then include custom variables in the install URL and access them from within the application on install.  Allowing advertisers and app developers to pass in referral data seems like a no-brainer for Google.  Too bad Apple doesn’t provide similar functionality.

By using the referral data, you can then allocate credit to the mobile traffic source (affiliate or ad network) that was responsible for the install.  However, tracking using referral data still requires the use of server-side tracking, and this causes a disconnect between the mobile web and mobile app environments.  We already know that mobile apps cannot access traditional client-side cookies placed on a user’s web browser, but even with traditional server-side tracking you need a browser to store unique values in the URL string that the advertiser can store and pass back to record a conversion (which is the difference between client-side versus server-side tracking).  So if a user is not using a mobile browser and is clicking an ad within another mobile app, server-side tracking won’t work.

That is why HasOffers uses a server tracking method called Server Postback with Transaction ID.  On install, the Android app posts back the transaction ID value, which is just the name of a variable that we associate with a “click.”  Some refer to this value as a click ID.

How a Server Postback with a Transaction ID Tracks Mobile App Installs

1.  Include the Transaction ID as a Parameter

In the offer you’ve created for your app, you must include the Transaction ID parameter as part of the “referrer” in your install URL.  Referrer is the name of the parameter that Google has defined that is then passed into the app on install.  This URL would then be set as the default offer URL for your offer.

Here is an example of a basic install URL with the Transaction ID:

market://details?id=com.zeptolab.ctr.paid&referrer=transaction_id%253D{transaction_id}

Or if you use Google Analytics for your app, you could include Transaction ID as a value in one of their parameters.  This advanced install URL includes Transaction ID as a value of Google’s utm_medium parameter.

The example URL below includes tracking parameters for Google Analytics.

market://details?id=com.zeptolab.ctr.paid&referrer=utm_source%253D{source}%2526utm_content%253D{aff_sub3}%2526siteid%253D{aff_sub}%2526utm_campaign%253D{aff_sub2}%2526utm_medium%253D{transaction_id}

You can read more about the HasOffers and Google Analytics integration in last Tuesday’s post.

2.  Request the Value of the Referral

Once you have this in place, your offer in HasOffers uses the tracking protocol of Server Postback with Transaction ID.  After a successful install of your app, you will then need to request the value of the referral.  The referral is only available immediately after installation as its not a persistent value stored by the app. Once you have the value of the referral, you will need to parse out the transaction ID value.  If you used the basic install URL then it will be set to the Transaction ID parameter.  If you used the advanced install URL with Google Analytics, then the Transaction ID will be the value of the utm_medium parameter.

3.  Post the Transaction ID to HasOffers

Once your app has the Transaction ID value, you will then need to post it to HasOffers using the Server Postback URL for the offer.  You would include the Transaction ID value in the URL.

This is an example postback URL that your app would load to notify HasOffers of the install:

http://demo.go2cloud.org/aff_lsr?offer_id=1&transaction_id=123TransactionIdValueHere

HasOffers’ servers then take the Transaction ID value and search our databases for the associated tracking information, including information about the affiliate or ad network, time of click, et cetera. The affiliate or ad network responsible for the install is then credited in reporting and, depending on your offer settings, in their payouts.  With this tracking setup in place, only the ad networks or affiliates who have a recent user session will get credit for generating an install.

Tracking Android Apps Installs With Device Fingerprint

So, there is another really cool way to track app installs and other “in app” conversions on Android apps.  This method involves using a device fingerprint.  The device fingerprint is generated using several header data points sent by the device.  By combining several of these data points together, we’re able to create a unique fingerprint for a specific device.  The device fingerprint generated by our servers is not the UID or device ID provided by the phone, but a unique number we’ve applied to track the device.  This fingerprint can then be used to track a user’s interactions with advertisements and connect them to any installs or other “in app” conversions generated.

After a user clicks on an advertisement, a request is sent to our ad servers.  We collect the header data points and generate a unique ID for that user’s device, or what we call a device fingerprint.  Our ad servers then store the device fingerprint in our database with information about the advertisement and the traffic source (affiliate or ad network).  We are also able to store information about user headers as well as time and location parameters.  After we’ve collected this information, the ad servers direct the user to the install URL so they are able to continue downloading the Android app.  This all happens in a span of 300 milliseconds.

When users block third-party app markets in the Android Market, typical conversion rates from advertising campaigns to app installs are around 2-5%. Conversion rates outside of the Android Market range from 1 to 2%.  The difference in conversion rates between in-market and out-of-market app installs is largely due to some users’ phones blocking apps from third parties, causing a decrease in conversion rates.  If these users still want to download the app from a third party, they have to go into their device settings and enable downloads from third parties.

Once the download is complete and the user installs the app, the app needs to notify HasOffers of the conversion.  This is done by loading the postback URL; similar to Server Postback with Transaction ID, but instead of needing to include the Transaction ID, the postback URL is called without it.  When the app loads and sends the request to the ad servers notifying HasOffers of the conversion, the ad servers collect the same header information that was collected from the click event.  The ad servers generate the device fingerprint based on the header information, and then look at the device fingerprint (generated on the conversion) and search the databases to see if any tracking sessions were generated from clicks with the same device fingerprint.  If there is a match, the ad servers load the information saved from the click event and use it to record the conversion.

Device fingerprinting tracking technology is actually already available for mobile app tracking within HasOffers, and is included in the Pro edition.  To set up an offer in your HasOffers account with this tracking, you’ll select Mobile App Postback for the conversion tracking method on the offer (instead of using iFrame or Server Postback).  This conversion tracking method of Mobile App Postback will use the device fingerprinting technology to track clicks and link them with specific conversion data.

With the Mobile App Postback conversion tracking method, you won’t need to pass special values in the install URL.  The only part that will change with the postback URL being loaded on the conversion, is that instead of the server response conversion handler, the postback URL will use the mobile tracking handler.

This is an example of a postback URL using the Mobile App Postback conversion tracking method:

http://demo.go2cloud.org/aff_lm?offer_id=1&device_id=DeviceIdHere

When using this conversion tracking method, it’s recommended to include the user’s device ID / UID to associate the user with the device fingerprint and prevent duplicate conversions from being recorded due to two users having the same device fingerprint.  Our research indicates that our device fingerprints are currently 97% unique, and we’re working on improving this method.

The cool thing about the conversion tracking method of Mobile App Postback is that it will actually work for Apple iOS tracking installs of iPhone and iPad apps as well.  Since Apple doesn’t allow referral data to be accessed on install like Google does, only this device fingerprinting method can be used to link conversions to specific advertising campaigns.  While this post focuses on tracking Android app installs, I can’t wait to share the post on iPhone and iPad app tracking we’ll be following up with soon.

HasOffers Mobile App Tracking

If all of that seemed a bit complicated, we’ve actually simplified the entire process of tracking Android applications into a single SDK (software development kit).  This Android SDK combines both referral data and device fingerprinting technology to accurately track and allocate credit for installs to the traffic sources (applicable publishers) responsible.  By installing this Android SDK, you can get the insight you need to determine the value of mobile advertising and know your CPI (cost per install).

Our Android SDK is also integrated with the top nine mobile ad networks to make it easier for you to work with more than one.  Our engineers have worked closely with these ad networks to integrate our Android SDK in collaboration with their tracking systems.  Instead of having to implement the tracking SDK for every ad network you work with (if you’re working with three or more, this gets very time consuming and complicated), you just have to install the HasOffers Android SDK.  Then our Android SDK communicates the appropriate tracking information to the ad network responsible for generating the install.

Reducing Latency

Most people don’t realize that by integrating more than one tracking SDK from multiple ad networks, they are severely harming the accuracy of their tracking.  For example, you have advertising campaigns with Google Admob and have their tracking SDK integrated into your app.  You also work with Millennial Media and have their tracking SDK integrated into your app as well.  Let’s say a user saw and clicked on a Google Admob ad, but abandoned before actually installing the app.  Then two months later, that same user sees an advertisement for the same app via campaigns on Millennial Media.  The user decides to click again, and this time they install the application.  On install, both Admob and Millennial report back to their systems that an advertisement on their network generated an install.  Wait … two networks recorded the install for one user?  Yes.  Houston, we have a problem.

Mobile App Tracking is the solution that controls who’s responsible for generating installs and credits them appropriately.  In the example above, only Millennial would get credit for the install since they were responsible for the recent and relevant interaction with the user.  Our SDK loads Millennial’s SDK and their system tracks the install accordingly.  Since Admob wasn’t responsible for the last interaction with the user, they wouldn’t be credited, and their SDK would not be loaded.  This enforces that one install is credited to only one source, eliminating duplicate conversions in reporting and ensuring your conversion data is accurate.  Inaccurate CPA / CPI metrics can kill great advertising campaigns.

Check out the official Press Release of HasOffers’ Mobile App Tracking from today.