Collecting data with Trackers and Webhooks

  1. Home
  2. Docs
  3. Collecting data with Trackers and Webhooks
  4. Trackers – collecting data from your own applications
  5. React Native Tracker
  6. Advanced usage

Advanced usage

Tracker Maintenance Classification
Latest tracker version
Supported React Native versions



Getting session data from the tracker

The React Native tracker has implemented callbacks that enable you to get session data back from the tracker at runtime. The way to do so is by using a tracker’s get.. methods. As with all tracker methods, these callbacks are also asynchronous, and they return a Promise that resolves to the respective value (or undefined) when fulfilled.

The available methods, are:

getSessionUserId

This method returns a promise that resolves to the identifier (string UUIDv4) for the user of the session.

const sessionUserId = await tracker.getSessionUserId();
Code language: JavaScript (javascript)

getSessionId

This method returns a promise that resolves to the identifier (string UUIDv4) for the session.

const sessionId = await tracker.getSessionId();
Code language: JavaScript (javascript)

getSessionIndex

This method returns a promise to resolve to the index (number) of the current session for this user.

const sessionIdx = await tracker.getSessionIndex();
Code language: JavaScript (javascript)

getIsInBackground

This method returns a promise to resolve to whether (boolean) the app is currently in background.

const isInBackground = await tracker.getIsInBackground();
Code language: JavaScript (javascript)

getBackgroundIndex

This method returns a promise to resolve to the number of background transitions in the current session.

const bgIndex = await tracker.getBackgroundIndex();
Code language: JavaScript (javascript)

getForegroundIndex

This method returns a promise to resolve to the number of foreground transitions in the current session.

const fgIndex = await tracker.getForegroundIndex();
Code language: JavaScript (javascript)

Removing a tracker at runtime

As also mentioned in Introduction, besides the createTracker function, the React Native Tracker also provides two functions that allow you to remove a tracker (or all of them) at runtime.

removeTracker

As each tracker is identified by its namespace, in order to remove a tracker at runtime, you need to pass its namespace to the removeTracker function.

For example, assuming an existing tracker with namespace sp1 :

import { createTracker, removeTracker } from '@snowplow/react-native-tracker'; // ... removeTracker('sp1');
Code language: JavaScript (javascript)

removeAllTrackers

The function removeAllTrackers, which accepts no arguments, will remove all trackers created in your app.

import { removeAllTrackers } from '@snowplow/react-native-tracker'; removeAllTrackers();
Code language: JavaScript (javascript)

Tracking user identifiers

The React Native Tracker inherits from the Mobile Native Trackers the policy for tracking user identifiers. Generally the user identifiers, when tracked, are being sent as part of the mobile_context.

This section describes the default behavior of the native trackers concerning tracking of user identifiers (namely: AAID for Android, and IDFA, IDFV for iOS) and the ways to change it.

iOS

Concerning the IDFA and IDFV user identifiers, the default behavior of the Snowplow iOS Tracker, and thus, the default behavior of the React Native Tracker is:

  • The IDFA is not being tracked
  • The IDFV is being tracked

One of the things to do in order for this behavior to change, is to pass Preprocessor flags to the underlying Snowplow iOS Tracker, especially since Apple requires the relevant code to be removed. The way to do so from the React Native side is therefore through post_install script in the app’s Podfile, that will take care of passing the corresponding Preprocessor definitions to the build settings of the Snowplow iOS Tracker.

IDFV tracking

Returns the generated identifier for vendors. More info can be found in UIDevice’s identifierForVendor documentation.

As mentioned above, by default, the IDFV is being tracked.

If you do not want to track the IDFV, you’ll need to pass the SNOWPLOW_NO_IDFV preprocessor definition to the iOS Tracker build settings:

# ios/Podfile # ... post_install do |installer| installer.pods_project.targets.each do |target| if target.name == 'SnowplowTracker' target.build_configurations.each do |config| config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)'] config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] << 'SNOWPLOW_NO_IDFV=1' end end end end
Code language: Ruby (ruby)

IDFA tracking

IDFA allows advertisers to track a user’s device among reinstalls and apps. Obviously Apple has introduced way to limit the trackability in order to keep high level of privacy for the user. Your app’s users can choose to limit ad-tracking by preventing the IDFA being passed to advertisers.

If you want to track the IDFA you need to follow the guidelines of AppTrackingTransparency and enable IDFA tracking on Snowplow iOS tracker:

  • Add and follow the guidelines of AppTrackingTransparency framework in your app.
  • Add AdSupport framework to your app. If it’s not added the tracker will not send the IDFA with the events.
  • Again, use a post_install script in your app’s Podfile to pass the SNOWPLOW_IDFA_ENABLED=1 preprocessor definition to the underlying iOS Tracker
# ios/Podfile # ... post_install do |installer| installer.pods_project.targets.each do |target| if target.name == 'SnowplowTracker' target.build_configurations.each do |config| config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)'] config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] << 'SNOWPLOW_IDFA_ENABLED=1' end end end end
Code language: Ruby (ruby)

Note: The simulators can’t generate a proper IDFA, instead they generate a sequence of zeros. If you want to test IDFA with a real code, please, use the physical device.

Note: The user has the ability to limit ad-tracking from the device’s Settings. If the user enable the limitations the tracker will not be able to track the IDFA.

Android

Similarly, the React Native Tracker, inherits the AAID-tracking behavior from the Snowplow Android Tracker. This section below, from the Android Tracker documentation, applies equally to the React Native Tracker, where you will need to make the respective changes to the android part of your React Native app.

AAID tracking

The AAID (Android Advertising ID) is a unique user-resettable identifier, which uniquely identifies a particular user for advertising use cases, such as ad personalization. The tracker allows retrieval of the AAID, sending it as property androidIdfa as part of the mobile_context JSON which is attached to each mobile event.

For privacy purposes the user can reset the identifier at any moment. In that case the tracker will report a new AAID, despite the device and user being the same as before. Also, the user can “Opt out of Ads Personalisation” from the Android settings menu. In that case the tracker will report an empty string in place of the AAID.

If you want to track the AAID, you need to add the Google Mobile Ads library to your app. If it isn’t included, the tracker will not send the AAID with the events.

The Google Mobile Ads can be imported in the dependencies section of the build.gradle adding:

dependencies { ... implementation 'com.google.android.gms:play-services-ads:19.0.0' ... }
Code language: JavaScript (javascript)

The Google Mobile Ads SDK v.17.0.0 introduced some changes requiring a tag in the androidManifest.xml explained below.

Manifest tag for AdMob publishers

AdMob publishers have to add the AdMob app ID in the AndroidManifest.xml file:

<manifest> <application> <!-- TODO: Replace with your real AdMob app ID --> <meta-data android:name="com.google.android.gms.ads.APPLICATION_ID" android:value="ca-app-pub-################~##########"/> </application> </manifest>
Code language: HTML, XML (xml)

Failure to add this tag will result in the app crashing at app launch with a message starting with “The Google Mobile Ads SDK was initialized incorrectly”.

Manifest tag for Google Ad Manager publishers

Publishers using Google Ad Manager have to declare the app an “Ad Manager app” in the AndroidManifest.xml file:

<manifest> <application> <meta-data android:name="com.google.android.gms.ads.AD_MANAGER_APP" android:value="true"/> </application> </manifest>
Code language: HTML, XML (xml)

Failure to add this tag will result in the app crashing at app launch with a message starting with “The Google Mobile Ads SDK was initialized incorrectly”.

If you’d like to learn more about Snowplow Insights you can book a demo with our team, or if you’d prefer, you can try Snowplow technology for yourself quickly and easily.