Making your Ad Network Accountable - Mixpanel
Blog Post

Making your Ad Network Accountable

Last edited: Jul 12, 2022 Published: Apr 25, 2012
Mixpanel Team

How to Evaluate your Mobile User Acquisition Spend

Last week an experienced digital marketer visited our offices to learn about Mixpanel. His background was in web analytics, but he had recently been hired by a growing mobile company to professionalize their digital marketing.

When he arrived at his new company, he was shocked to learn they were paying thousands of dollars for users via a number of ad networks (iAd/MoPub/Admob/Tapjoy, etc) but didn’t have numbers showing how engaged the users acquired this way were. He had no way to know if a user acquired from one campaign brought in more revenue than one acquired a different way.

Source attribution on the web is relatively easy. If I want to bring users via AdWords to my site, I’ll make the landing page link from the ad something like this:

http://www.mysite.com/landingpage?utm_source=AdWords&utm;_medium=PPC&utm;_campaign=NameOfMyCampaign

Once I’ve done that, in Mixpanel the utm_source, utm_campaign, and utm_medium all become super properties I can use for segmentation. This is vital to determining how effective each campaign, medium, or source was in terms of conversions to actual users or revenue generated and retention. Without this information you cannot make an informed decision about how to allocate your marketing resources. This has become a standard practice for web-based marketing.

However, as I told the marketer I was speaking with, for mobile apps, tying a user’s behavior within the app with their acquisition source data is more complicated. This means very few mobile app marketers actually do it. However, it is possible! If you go through the trouble of linking up your ad network with Mixpanel you can hold your ad network accountable for the quality of the users they send you.

Android

Acquisition source attribution is much easier in the Android Marketplace than in the iOS App store. This is because if you provide a link to your application that looks like this:

http://market.android.com/details?id=your.package.name&referrer;=**your_referrer_parameter**

Android will make the your_referrer_parameter available to your app when it first launches., This parameter needs to be a series of specific key / value pairs and be URL encoded. The keys you can use are utm_source, utm_medium, utm_term, utm_content and utm_name. utm_source, utm_medium and utm_name are required. You can use these values to categorize the campaign in different ways. A completed Android Market URL would look something like this:

http://market.android.com/details?id=your.package.name&referrer;=utm_source%3Dtapjoy%26utm_medium%3Dbanner%26utm_campaign%3Dbrainy%2520images

To access the referrer information, create a Broadcast Receiver in your app registered to the com.android.vending.INSTALL_REFERRER intent filter. A good code example for doing this is available here.

Once you have access to your referrer parameter, you can register it as a Mixpanel super property, so all future events will be associated with it.

iOS

Acquisition source attribution is much more difficult on iOS. Apple does not provide any capability to pass a referrer string through to your app from a link to the app store. The result is that when someone installs an app for the first time, you are blind as to where they came from.

To solve this problem, traditionally the ad networks would record the UDID (a unique identifier assigned by apple to every iDevice) of anyone who tapped on one of their ads. They also provide you with a code snippet that you add to your application. This code snippet will ping the ad network’s server when your app first opens with the UDID of the device that opened the app. The ad network will take credit for all UDIDs that both tapped on their ad, and launched your app for the first time.

Much has been written about Apple’s recent rejection of some apps that access UDIDs, causing a minor panic. Though it is important not to panic (apps that disclose they collect the UDID are not being rejected) it is clear that the industry is moving away from UDID to an array of alternatives. In general these alternatives are drop- in replacements for UDID, and don’t change this general paradigm.

Whether an ad network is using UDID or some other identifying string, the app itself does not know when it first launches that it was discovered through a certain acquisition source. This means you can’t just register a super property the way you would in Android to perform easy segmentation of user behavior in Mixpanel. Instead, you have to add the data to Mixpanel after the fact.

Most ad providers will provide you with a flat file that indicates which UDIDs (or other identifier) installed after tapping their ad. This is usually generated daily, and is accessible in an automated way via FTP or S3. To get this data into Mixpanel, write a script that processes this data file and uses our HTTP API to insert a back dated event for each user called “Annotated Signup.” At a minimum this event needs to have the following properties:

  • The distinct_id of the user
  • The time the user’s account was created
  • The acquisition source of the user

The distinct_id is the identifier you are using to identify users within Mixpanel. Depending on your implementation this could be your own internal ID or the identifier Mixpanel uses (a one way hash of the MAC address).

The time should be a UTC unixtime stamp representing when the account was created. This is most likely recorded in your database.

The acquisition source is the name of the ad network or the campaign the user came from. This will be determined by which file you got the identifier from.

The trickiest part of this is mapping the identifier you get from your ad network to the distinct_id used within Mixpanel. You need to understand exactly which identifier system your ad network is using, and add logic to your application to send that identifier to your server, so you can store it in your database and associate it with each of your users. You can then use your database to lookup each identifier you get from the ad network, translate it to the distinct_id you are using for Mixpanel, and then send the event to Mixpanel.

This “Annotated Signup” event can be used as the first step for your funnel reports and retention reports, allowing you to understand how users from different sources convert to different actions and retain in your application.

Below are two examples of reports in Mixpanel you can create after sending an “Annotated Signup” event. Reports like these let you determine not only how many users you are buying, but how valuable the users you bought are actually are.

This funnel uses “Annotated Signup” to determine what percentage of users from different acquisition sources eventually complete level 5 of this game, a key metric of engagement for this publisher.This report looks at what percentage of users acquired via TapJoy return and continue to use the app 7 days later. You apply different filters for each of your acquisition sources to see which ones are retaining the best.

Once you’ve put the basic infrastructure in place, you can start being more granular. Different campaigns with different messages, creative and placements can be assigned different values for your acquisition source property, so you can optimize your spend to where it is most effective.

Get the latest from Mixpanel
This field is required.