Measuring and Merging External (Non-App) Events

Mobile is an exciting time for retailers as mobile devices afford brands additional channels through which they can engage their users. Without a user having to take a single step into a retail store, brands can engage their users not only through tailored mobile apps, but the mobile web experience as well.

With so many diverse avenues for user engagement, the challenge becomes how to gain insights on the complete value of your users as they generate value across all of your channels. You may first acquire a user via your mobile app, but they may continue to engage with your brand via your website as well as visit your actual retail store. The Measuring and Merging External (Non-App) Events API can help you understand the true value of each user although they may be generating value in entirely different spaces.


Based on your goals and resources, you have two options to combine these data sources as a MobileAppTracking client.

  1. Send non-mobile app data from external BI system to MAT and MAT will use the data to provide insights on value of mobile app installs.
  2. Send mobile app data from MAT to external BI system and external BI system will fuse the data to provide insights on value of mobile app installs.

This document addresses #1. If you’d like to ingest MAT data into your own BI system and fuse it there with #2 then please refer to Exporting Reporting Logs and Fusing Data.

Measuring Internal App Events via the MAT SDK

As a MobileAppTracking client you’ll have our SDKs implemented in your mobile apps to measure end-user sessions in your app. We measure the first app-open event as an Install, while subsequent session calls are measured as opens. Opens that include a change in app version are recorded as Updates.


When measure session is called with the SDK, depending on the platform, the following mobile identifiers will be associated with the install and/or open request.

Android apps on Google Play

  • Google Ad ID – google_aid

Android Apps on Kindle or other stores

  • Android ID – android_id

iOS apps

  • Apple Identifier for Advertising  – ios_ifa
  • Apple Identifier for Vendor – ios_ifv

Windows 8.1 apps

  • Windows Ad ID – windows_aid

Windows 8.0 Apps

  • Windows Hardware ID

While the mobile device identifiers above are used for attribution, the SDK must also be implemented to collect a User ID value (your internal identifier for the end user) because this is the only value that MAT uses to link data generated by a user in-app with data generated by a user outside of an app. The device identifiers listed above refer to the device, while the User ID refers to the actual user (and a single user may have multiple devices).

It is required for you to implement the SDK to collect:

  • User ID – user_id

The following code can be used to set the User ID value when measuring an event with our SDK.


MobileAppTracker setUserId:@"custom_user_id"];



For many apps, your internal User ID value is not available on first app open. For example, it may be created and available after a user registration or login event. When MAT measures one of these events and it includes a new user identifier, it uses the device identifiers to associate the event to the install, at which point the install can then be referenced by the user identifiers going forward.


The benefit of MAT updating the install record with a user identifier is that this enables events to be measured from outside the app experience only using the user identifier – without any device-specific identifiers – and then matched to app events made by that same user. However we can only do so when we have access to that User ID, so out-of-app events can only be measured after the USER ID has been passed into MAT.

For more information about user ID configuration, please visit SDK Settings for User IDs.

Measuring External Events via the MAT Measurement API

After the SDK has been implemented to measure sessions that collect mobile device identifiers (and possibly other in-app events with user identifiers), you can then implement a process to send events to our Measurement API, which empowers clients to measure additional events that are generated or processed by a third-party system.


Once an in-app event is measured with the User ID, you can measure events directly with the Measurement API (which uses the User ID to search for the install and link the event to the install).The most common events that retailers measure directly with our Measurement API outside the SDK implementation are:

The Measurement API requires that a user_id is always specified to measure events. Thus, the user_id needs to be included in the request so MAT can link the user data generated outside the app with the data inside the mobile app.

Consider the following GET request example to measure a purchase event with the Measurement API:

The Measurement API takes the user_id value, finds the install with the matching user_id, and then links the event to the install. This linking enables MAT to provide you with insights on the value of the user, including lifetime value (LTV) analysis.

Have a Question? Please contact for technical support.