The purpose of this guide is to walk you through the basic steps of setting up mParticle in your app, unlocking core functionality, and troubleshooting common issues. Along the way, you’ll cover some important concepts you need to understand to be successful with mParticle.
This is not a complete guide to all of mParticle’s features and capabilities. If you already know your way around mParticle and you’re looking for in-depth docs, head to our Developers or Guides sections.
The tutorials in this guide follow the process of setting up mParticle in the mPTravel app: a mobile and web app that sells luxury travel packages to its users.
Later on in this guide, you’ll learn about sending data from mParticle to some of our many integration partners. As examples, the tutorials use services which are simple to set up and verify, and which offer a free account tier, so that you will be able follow the examples exactly if you wish. However, mParticle is agnostic about which integrations you choose and you can follow the same basic steps from this guide to implement any of our integrations.
One of the key functions of mParticle is to receive your data from wherever it originates, and send it wherever it needs to go. The sources of your data are inputs and the service or app where it is forwarded are outputs. A connection is a combination of an input and output.
Inputs include:
To get started with mParticle, you need some data, which means you need to create at least one input.
The first thing you need to do is to to create a set of access credentials that will allow a client-side SDK or a server-side application to forward data to this workspace.
mParticle labels the credentials you create for an integration the key and secret, but they are not exactly like an API key and secret, since you embed these credentials in the app. However, this is not the security risk that exposing API credentials would be:
Most anonymous client-server architectures, including Adobe, Braze, Firebase, Google Analytics, and Segment don’t have per-session or per-instance credentials, nor does mParticle.
You need a developer to help you install and initialize an SDK. See the Getting Started guides for the iOS, Android or Javascript SDKs to get set up before continuing.
For the iOS, Android, tvOS, and Web platforms, some advanced configuration settings are available. To change these settings, navigate to Setup > Inputs in the left column and select either iOS, Android, tvOS, or Web from the list of platforms.
Expand the Advanced Settings by clicking the + icon.
iOS, Android, and tvOS (Apple TV) devices allow users to limit the collection of advertising IDs. Advertising IDs are unique identifiers you may use to associate event and user data with a specific device. For both iOS and Android devices, if a user has not provided explicit consent to share their device’s advertising ID, then the value of that ID is set to an all-zero value.
By checking Restrict Device ID by Limit Ad Tracking, mParticle will not collect advertising IDs from users who have enabled the Limit Ad Tracking setting on their device.
Remember, mParticle will collect advertising IDs for both iOS and Android devices, regardless of whether or not a user has enabled the Limit Ad Tracking setting on their device. However, the IDs collected from users who have opted out will be all-zero values.
Following are descriptions of Apple and Google’s policies for device advertising IDs:
After the release of iOS 14.5, Apple introduced the App Tracking Transparency (ATT) framework, which requires app developers to request users’ explicit consent to share their advertising IDs. If a user of your app has not provided this consent, Apple’s advertising ID (IDFA) will be set to all an all-zero value: 00000000-0000-0000-0000-000000000000
. Read more about Apple advertising identifiers in their documentation.
For more information about the ATT framework, visit the iOS 14 Guide.
Google allows Android users to opt out from sharing their devices’ advertising IDs. Similar to Apple’s policy, Google will set a user’s advertising ID (GAID or AAID) to an all-zero value if that user has opted out from sharing their ID. Read more about Google’s advertising identifiers in their documentation.
The Web SDK can collect integration-specific identifiers to enrich the user data forwarded to your connected outputs.
When Collect Integration-Specific Identifiers is checked, these integration-specific identifiers are collected and used to enrich your user data to help optimize the match rate of your audiences in downstream tools. Currently, these identifiers include Facebook’s fbc
and fbp
fields.
If you don’t see data appearing in the Live Stream within the first few minutes after opening a development build:
Congratulations, you have created a working data input. Now it’s time to start capturing some data.
Was this page helpful?