Case Study : MAT

Introduction
The MobileAppTracking (MAT) SDK for Google Android provides basic application install and
event tracking functionality. The Android SDK is provided in the for of a single !ava "A# file that
you siply include in your Android pro!ect. This SDK is copatible $ith all devices running
Android %.& and above . To track installs' ust first integrate the Android SDK $ith your Android
app. (e ay also add and track additional events beyond an app install (such as purchases' gae
levels' and any other user engageent).
)nce you*ve do$nloaded the Android SDK' decopress the +ip file and e,tract the files to your
developent coputer. The Android SDK is provided as a single !ava "A# file.
Unique Identifiers for Attribution
-y default the Android SDK collects Device .D' Android .D' )din and Mac Address. These
/ni0ue.dentifiers for Attribution are collected to a,ii+e your ability to $ork $ith inergrated
adnet$orks and publisher partners.
Methodologies for Attributing Installs
When the platform receives a request to trac an app install! it uses three methodologies for
attributing installs! conducted in the follo"ing order:
#$Android Install %eferrer
&$Unique Identifier Matching
'$(evice )ingerprintin
(hen the platfor receives a re0uest to track an app install' it uses three ethodologies for
attributing installs' conducted in this order1
&. Android .nstall #eferrer
%. /ni0ue .dentifier Matching
2. Device 3ingerprint Matching
#$ Android Install %eferrer
Google allo$s an install referrer string to be passed through the Google 4lay store. The platfor
utili+es this capability to pass Google a uni0ue tracking id generated on click of the tracking link.
/pon install of the obile app' Google allo$s this value to be collected fro $ithin the obile
app. The install is then attributed to the click based on the tracking id passed back by Google.
Android app installs use the sae look back period as the Device Attribution 5ength $hich is a
default of 6 days. Since the install referrer is set on the last click' no other clicks are considered
fro additional publishers.
Attribution based on the Android .nstall #eferrer is copatible $ith Google 4lay only. The Android
.nstall #eferrer is not available $ith the Aa+on App Store or any other app store. There is also an
issue $ith the Android .nstall #eferrer not $orking properly $hen the $eb version of Google 4lay
is used. Android 4roble collecting .nstall #eferrer on Do$nload. 3or this reason' using Direct
Tracking links for Android is not a fool proof ethod of tracking Android app installs on Google
4lay' and thus #edirect 5inks are recoended in order to allo$ the platfor7s other t$o
attribution ethods to take place.
&$ Unique Identifier Matching
Attribution using uni0ue identifiers is done by atching the uni0ue identifiers fro the install to a
click. )n install' ultiple /ni0ue .dentifiers for Attribution are included $ith the install re0uest. All
of this installs are then used to search for clicks $ith atching uni0ue identifiers. The atching
clicks are then sorted by recency and the last click (ost recent click) receives credit and is
attributed $ith the install.
3or e,aple' a publisher includes ios8ifa9&&&&&&&&&&&&&&&& in their tracking link. )n install' the
SDK collects the .D3A of &&&&&&&&&&&&&&&& and sends this to the platfor. The platfor receives
the track install re0uest and searches for all clicks $here .D3A e0uals &&&&&&&&&&&&&&&&. The
results $ould include the click by the publisher that specified the .D3A of &&&&&&&&&&&&&&&& in the
tracking link. The install is then attributed to this publisher based on the uni0ue identifier that
atched fro install to click.
/ni0ue .dentifier Matching is an autoated and real:tie $ay of coparing clicks to installs
instead of anually conducting the atching at the end of a $eek or onth using ;,cel
spreadsheets. /ni0ue .dentifier Matching enables &1& atching of click to install $here identifiers
can be passed app to app.
Ad net$orks and publishing platfors support various uni0ue identifiers for attribution.Since these
advertising partners support the sae and different uni0ue identifiers' it is recoended to collect
ultiple uni0ue identifiers on install in order to $ork sealessly $ith each ad net$ork and
publishing platfor you choose.
The look back $indo$ for uni0ue identifier atching : Device Attribution 5ength : is set to 6 days
by default. The Device Attribution 5ength can be custoi+ed on an account level as $ell as for a
specific publisher $ithin the platfor.
(hen a publisher specifies /ni0ue .dentifiers for Attribution in a tracking link' the publisher can
5oad the Tracking 5ink Server:Side because a device fingerprint is not re0uired' allo$ing the user
to be iediately directed to the app store.
'$ (evice )ingerprint Matching
Device fingerprinting is used as a third ethodology for attribution if the previous ethods do not
provide results. This ethod pulls basic and not &<<= uni0ue inforation fro a user7s device
headers' including .4 address' to connect a user fro click to app install. Device fingerprinting
happens asynchronously in the background of the obile app' $hich does not interfere $ith the user
e,perience by forcing a bro$ser to open
Device fingerprinting $orks by redirecting a user through a tracking link and collects the publicly
available >TT4 headers about the device. This inforation is used to create a fingerprint about the
click of the tracking link. (hen a user installs the obile app' the SDK collects the sae data
points fro $ithin the obile app and sends it to the platfor. The platfor generates the
fingerprint of the install and then searches for clicks $ith the atching fingerprint. The last click
$ith a atching fingerprint is then used to attributed the install.
(hile MobileAppTracking does not support cookie tracking by default' it can be ade available for
$eb apps. ?ookie tracking redirects a user through a tracking link and sets a cookie that stores
inforation about the click. (hen a user installs the obile app' cookie tracking ust redirect the
user out of the native obile app e,perience and into a $eb bro$ser. This allo$s cookies to be
collected fro the user7s device that gives inforation about a previous ad click. The user is then
directed back to the obile app fro the $eb bro$ser. This process can take a fe$ seconds to
coplete and breaks the users7 first e,perience of the app' ipacting conversions rates.
.t is encouraged for publishing partners $ith /ni0ue .dentifiers for Attribution to include the in
their tracking links so their installs $ill be attributed using uni0ue identifier atching. )ther$ise
publishers using uni0ue identifiers $ill trup publishing partners $ithout uni0ue identifiers for
attribution.
The look back $indo$ for atching using device fingerprint : 3ingerprint Attribution 5ength : is
set to %@ hours. #ecency of a users interaction is a priary factor in the statistical significance and
accuracy of device.
Installs and Updates
As the success of attributing app events after the initial install is dependent upon first tracking
that install' $e re0uire that the install is the first event tracked. To track the install of your
Android obile app' use the Atrack.nstallB ethod. .f users have already installed your app
prior to SDK ipleentation' then these users should be tracked as updates.
Trac Install
The Atrack.nstallB ethod is used to track $hen users install your obile app on their device
and $ill only record one conversion per install in reports. Cou should call track.nstall() in the
ain activity*s on?reate ethod after instantiating a MobileAppTracker class.
obileAppTracker.track.nstall()D
The Atrack.nstallB ethod autoatically tracks updates of your app if the app version differs
fro the last app version it sa$.
*andling Installs +rior to S(, Implementation
(hat if the app already has thousands or illions of users prior to ipleenting the SDKE
After integrating $ith the MAT SDK' the platfor $ould record each user as a ne$ app
install $hen those users updated their app. The MAT SDK provides you t$o ethods to force
an update event to be tracked instead of an install event1
&.Atrack/pdateB instead of Atrack.nstallB
%..port prior installs to the platfor
These ethods are useful if you already have an app in the Android Market and plan to add
the MAT SDK in a ne$ version.
.f the code used to differentiate installs versus app updates is not properly ipleented' then
you $ill notice a spike of total installs on the first day of the SDK ipleentation
All of the follo$ing events can be called after instantiating the MobileAppTracker1
obileAppTracker9ne$
MobileAppTracker(this'Fyour8advertiser8idF'Fyour8advertiser8keyF)DobileAppTracker.set;v
ent#eferrer(get?alling4ackage())D
%egistration
.f you have a registration process' its recoended to track it by calling trackAction set to
AregistrationB.
obileAppTracker.trackAction(FregistrationF)D
Cou can find these events in the platfor by vie$ing #eports G ;vent 5ogs. Then filter
thereport by the AregistrationB event.(hile our platfor al$ays blocks the tracking of duplicate
installs' by deafult it does not blockduplicate event re0uests. >o$ever' a registration event
ay be an event that you only $anttracked once per deviceHuser. 4lease seeblock duplicate
re0uests setting for eventsfor further inforation.
+urchases
The best $ay to analy+e the value of your publishers and arketing capaigns is to track
revenue fro in:app purchases. -y tracking in:app purchases for a user' the data can
becorrelated back to the install and analy+ed on a cohort basis to deterine revenue per
installand lifetie value.
Trac In-App +urchases
The basic $ay to track purchases is to track an event $ith a nae of purchase and then
definethe revenue (sale aount) and currency code.
trackAction(!ava.lang.Stringeventnae' !ava.lang.Doublerevenue' !ava.lang.Stringcurrency)
e,aple of tracking an event for purchase $ith revenue and currency code.
obileAppTracker.trackAction(FpurchaseF'&.II'7/SDF)D
4ass the revenue in as a Double and the currency of the aount if necessary. ?urrency is setto
F/SDF by default. See Setting ?urrency ?ode
for currencies $e support.Cou can find these events in the platfor by vie$ing #eports G
;vent 5ogs. Then filter thereport by the ApurchaseB event.
+urchases "ith .oogle/s 0illing system
The SDK also allo$s you to track purchase events that occur inside your app by tieing in
yourevents to Google 4lay*s .n:App -illing syste. To do so' ipleent a Service that is
bound toGoogle*s billing syste via their instructions.
)pens
The SDK allo$s you to analy+e user engageent by tracking uni0ue opens. The SDK has
built infunctionality to only track one AopenB event per user on any given day to inii+e
footprint. Allsubse0uent AopenB events fired on the sae day are ignored and $ill not sho$
up on theplatfor.To track an AopenB event you need to override the AonStart()B inside your ain activity.
Cou ustpass in AopenB as the paraeter in the AtrackActionB call
Soe app ads $ill open your app if already installed on the device. (e recoend
sendingthe app package nae that caused the open as the field for the Aset;vent#eferrerB
ethod. .f your app $as called fro an .ntent $ith AstartActivity3or#esultB fro another
app' callingAget?alling4ackage()B fro your conte,t $ill return the package nae of the app
that started it.Cou can find counts of )pens by vie$ing #eports G Mobile Apps. .nclude the
paraeter of )pens to see the aggregated count. The platfor does not provide logs of
)pens. .f you track)pens using a nae other than FopenF then these tracked events $ill cost
the sae price as allother events to track.
)ther ;vents
Cou can track other events in your app dynaically by calling AtrackActionB. The
AtrackActionBethod is intended for tracking any user actions. This ethod allo$s you to
define the eventnae.To dynaically track an event' replace A;vent JaeB $ith the nae of
the event you $ant totrack. The tracking engine $ill then look up the event by the nae. .f an
event $ith the definednae doesn*t e,ist' the tracking engine $ill autoatically create an
event for you $ith thatnae. An ;vent Jae has to be alphanueric.
obileAppTracker.trackAction(F;vent JaeF)D
Cou can find these events in platfor by vie$ing #eports G ;vent 5ogs.The a, event liit
per site is &<<. 5earn ore about thea, liit of events
.
While our platform al"ays blocs the tracing of duplicate installs! by deafult it does
not blocduplicate event requests$ *o"ever! there may be other types of events that you
only "anttraced once per device1user$ +lease see bloc duplicate requests setting for
eventsfor further information$

2vent Items
An event is like your receipt for a purchase' the event ites are the individual ites you
purchased. ;vent ites allo$ you to define ultiple ites per a single event. The
AtrackActionBethod can include this event ite data. 5earn ho$ to track event ites.
App to App Tracing
App to App tracking provides the ability for one app (the referring app) to do$nload another
app (the target app). The target app $ill then record an install event that contains data fro the
referring app. Also' you can specify that your app (AppA : referring app) redirect to the
link$here App- (target app) can be do$nloaded (typically this is Google 4lay).
Trac %eferrer Application 3%e-2ngagement4
Soe app ads $ill open your app if already installed on the device. (hen your app is
launchedfro soe other app : e.g. Safari : you receive a callback in the A/.ApplicationDelegateB. To track
A#e:engageentB' you can track the referrer app package nae and /#5.
Configure as Shared Instance
Soeties' it becoes necessary to aintain a shared instance of the
MobileAppTrackerob!ect throughout ultiple activities. The recoended $ay of doing this
is by creating a ne$shared instance that e,tends Application.
Trac 2vents in Web5ie"
.f your app contains >TM5 content and you $ould like to track events in the (ebKie$' you
cando this by overriding your (ebKie$?lient. Then handle the /#5 loading to find the /#5
re0uestthat corresponds $ith your event and call a trackAction before it loads.
Implementation
&. ?onfigure the Android Manifest.,l. The Android SDK re0uires setting up a Mobile App
Tracker receiver in your Android anifest. )nce you have set up the MAT receiver' you $ill need to
place it inside your application tags
%. .nstall #eferral (re0uired) in your anifest file. Doing so gives the SDK access to the
install referrer value fro Google 4lay and can be used for attribution.
6receiver android:name78com$mobileapptracer$Tracer8android:e9ported78true8:
6intent-filter:
6action android:name78com$android$vending$I;STA<<=%2)2%%2%81: 61intent-
filter:
61receiver:
.f the app has ultiple receivers for .JSTA558#;3;##;#' you $ill need to $rite a
custo receiver that $ill call these receivers instead.
2. -efore closing the anifest tag' add the follo$ing perissions in as the SDK uses the.
a. Internet +ermission3%equired4:
.nternet perission is re0uired to connect to tracking servers.
Luses:perission android1nae9Fandroid.perission..JT;#J;TFHG
b. >ffline Tracing +ermission3%equired4:
These perissions enable the SDK to 0ueue tracking events $hile the user is not connected
to the .nternet. )nce the user is online' the SDK $ill process all 0ueued events.

Luses:perission android1nae9Fandroid.perission.A??;SS8J;T()#K8STAT;FHG
c. Wifi State +ermission3>ptional4:
These perissions enable the SDK to access inforation about $hether you are connected to
a (i: 3i net$ork and obtain the device7s MA? address. .f not use initiali+e Mobile App
Tracker $ith AcollectMacAddressB set to flase.

Luses:perission android1nae9Fandroid.perission.A??;SS8(.3.8STAT;FHG
d. +hone State +ermission:
Allo$s the user7s device .D to be recorded. .f not used' initiali+e MobleAppTracker
$ithFcollectDevice.dF set to false.
Luses:perission android1nae9Fandroid.perission.#;AD84>)J;8STAT;F HG
@. Add MobileAppTracker.!ar
to your Android pro!ect7s build path..f you are using ;clipse' right click on your pro!ect
folder1
M
4roperties
M
"ava -uild 4ath
M
5ibraries
M
Add "A#s
.As of ADT &6.<' you can siply place MobileAppTracker.!ar in a folder called FlibsF in
yourpro!ect directory and ;clipse $ill autoatically include the !ar as part of the build under
theclasspath container FAndroid DependenciesF for e,port.N. .port the package into your
"ava class.
N. Cou7ll then need to instantiate the FMobileAppTrackerF class to allo$ you to call the
functions fro the Android SDK. ?hoosing $here to instantiate a ne$ class is a decision that
is uni0ue to your applicationHcode design. Generally' the code is placed inside your ain
activity7sFon?reate(-undle)F ethod.
4ublic class My?lass e,tends ActivityO

MobileAppTracker obileAppTracker9nullD
P)verride
public void on?reate(-undle saved.nstanceState)O
obileAppTracker9ne$ MobileAppTracker(this'Fyour8advertiser8idF'Fyour8keyF)DQ
Q
The ?your=advertiser=id@ and the ?your=ey@ values correlate to the Advertiser Id and
Conversion ,ey
Testing S(,
The SDK is designed to track conversions through the Google 4lay Store as $ell as fro
outsidearketplaces like the Aa+on App Store or third parties. This allo$s you to test it
$ithoutupdating your production app listing. Subse0uently' you $ill be able to update your
obile appfor Google 4lay after testing that tracking is fully operational : saving you tie and
resources.
(ebug Mode and (uplicates
(ebugging
(hen the Debug ode is enabled in the SDK' the server responds $ith debug
inforationabout the success or failure of the tracking re0uests. Debug ode log output can
be found in5og?at under the tag FMobileAppTrackerF. To debug log essages that sho$ the
event status and server response' call the FsetDebugModeF ethod $ith -oolean true1
obileAppTracker.setDebugMode(
true
)D
Allo" (uplicates
The platfor re!ects installs fro devices it has seen before. 3or testing purposes' you
ay$ant to bypass this behavior and fire ultiple installs fro the sae testing device.There
are t$o ethods you can eploy to do so1 (&) calling the FsetAllo$DuplicatesF ethod'and
(%) set up a test profile.
(&) ?all the AsetAllo$DuplicatesB after initiali+ing MobileAppTracker' $ith -oolean true1
obileAppTracker.setAllo$Duplicates(
true
)D
(%) Set up a test profile. A Test 4rofile should be used $hen you $ant to allo$ duplicate installsandHor
events fro a device you are using fro testing and don7t $ant to ipleentsetAllo$Duplicate#e0uests
in the code and instead allo$ duplicate re0uests fro the platfor.
The setDebugMode and setAllo$Duplicates calls are eant for use only during debugging
and testing. .ts re0uired to disable these for production builds.