After you add the library to your project, you can make any of the Analytics method calls anywhere in your App (make sure you import ADBMobile.h to your class).

Enable Mobile Application Reports in Analytics

Before you add code, have your Analytics Administrator complete the following to enable Mobile App Lifecycle tracking. This ensures that your report suite is ready to capture metrics as you begin development.

  1. Open Admin Tools > Report Suites and select your mobile report suite(s).

  2. Click Edit Settings > Mobile Management > Mobile Application Reporting.

  1. Click Enable Mobile App Livecycle Tracking, and optionally, Enable Mobile Location Tracking and Enable Google Play Campaign Tracking.

Lifecycle metrics are now ready to be captured, and Mobile Application Reports appear in the Reports menu in the marketing reports interface.

Lifecycle Metrics

To collect lifecycle metrics in your app, call collectLifecycleData() in the ApplicationUI constructor. For example:

ApplicationUI::ApplicationUI(bb::cascades::Application *app): QObject(app) {

If collectLifecycleData() is called twice in the same session, then your application will report a crash on every call after the first. The SDK sets a flag when the application is shutdown that indicates a successful exit. If this flag is not set, collectLifecyleData() reports a crash.

Events, Props, and eVars

If you've looked at the Adobe Mobile Class and Method Reference, you are probably wondering where to set events, eVars, props, heirs, and lists. In version 4, you can no longer assign those types of variables directly in your app. Instead, the SDK uses context data and processing rules to map your app data to Analytics variables for reporting.

Processing rules provide you several advantages:

  • You can change your data mapping without submitting an update to the App Store.
  • You can use meaningful names for data instead of setting variables that are specific to a report suite.
  • There is little impact to sending in extra data. These values won’t appear in reports until they are mapped using processing rules.

Any values that you were assigning directly to variables should be added to the data HashMap instead.

Processing Rules

Processing rules are used to copy the data you send in context data variables to evars, props, and other variables for reporting.

Processing Rules Training @ Summit 2013

Processing Rules Help

Become authorized to use Processing Rules

We recommend grouping your context data variables using "namespaces", as it helps you keep logical ordering. For example, if you want to collect info about a product, you might define the following variables:


Context data variables are sorted alphabetically in the processing rules interface, so namespaces let you quickly see variables that are in the same namespace.

Also, we have heard that some of you are naming context data keys using the evar or prop number:


This might make it slightly easier when you perform the one time mapping in processing rules, but you lose readability during debugging and future code updates can be more difficult. Instead, we strongly recommend using descriptive names for keys and values:


Context variables that define counter events can have the same key and value:


Context data variables that define incrementor events can have the event as the key and the amount to increment as the value:

"levels completed":"6"

Note: Adobe reserves the namespace "a.". Aside from that small restriction, context data variables just need to be unique in your login company to avoid collisions.

(Optional) Enable Offline Tracking

To store hits when the device is offline, you can enable offline tracking in the ADBMobileConfig.json Config File Reference. Pay very close attention to the timestamp requirements described in the config file reference before you enable offline tracking.

Analytics Methods

Each of these methods is used to send data into your Adobe Analytics report suite.




Tracks an app state with optional context data. States are the views that are available in your app, such as "home dashboard", "app settings", "cart", and so on. These states are similar to pages on a website, and trackState calls increment page views.

Note: This is the only tracking call that increments page views.


static void trackState(QString state, QHash contextData = QHash());


ADBMobile::trackState("loginScreen", null);

Tracks an action in your app. Actions are the things that happen in your app that you want to measure, such as "logons", "banner taps", "feed subscriptions", and other metrics.


static void trackAction(QString action, QHash contextData = QHash());


ADBMobile::trackAction("heroBannerTouched", null);

Sends the current x y coordinates. Replace event with the event that is received from the subscriber to BPS.


static void trackLocation(bps_event_t *geoEvent, QHash contextData = QHash());


ADBMobile::trackLocation(event, null);