React Native (Bridge)


Documentation Version

This documentation applies to version 20.11.0.

To access the documentation for versions 20.04 and older, click here.

React Native Bridge is a successor to the React Native SDK

The React Native SDK, which was developed earlier, will soon be end-of-life and will no longer be maintained. Please use this bridge SDK for a more complete and tested version.

This is the Countly SDK for React Native applications. It features bridging, meaning it includes all the functionalities that Android and iOS SDKs provide rather than having those functionalities as React Native code.

Creating a new application

In order to use the React Native SDK, please use the following commands to create a new React Native application.

npm install -g react-native-cli     # Install React Native
react-native init AwesomeProject    # Create a new project

cd AwesomeProject                   # Go to that directory
react-native run-android # OR       # Run the android project
react-native run-ios                # Run the iOS project

# New terminal
adb reverse tcp:8081 tcp:8081       # Link Android port
npm start                           # Run the build server

Installing the Countly SDK

Run the following snippet in the root directory of your React Native project to install the npm dependencies and link native libraries.

# Include the Countly Class in the file that you want to use.
npm install --save
# OR
npm install --save countly-sdk-react-native-bridge@20.11.0

# Linking the library to your app

# react-native < 0.60. For both Android and iOS
react-native link countly-sdk-react-native-bridge
cd node_modules/countly-sdk-react-native-bridge/ios/
pod install
cd ../../../

# react-native >= 0.60 for iOS (Android will autolink)
cd ios
pod install
cd ..


We will need to call two methods (init and start) in order to set up our SDK. You may also like to specify other parameters at this step (i.e. whether logging will be used). These methods should only be called once during the app's lifecycle and should be done as early as possible. Your main app component's componentDidMountmethod may be a good place. 

See the serverURL value in the code snippet below.

If you are using the Countly Enterprise Edition trial servers, use the domain from which you are accessing your trial dashboard, such as,, or

If you use both Community Edition and Enterprise Edition, use your own domain name or IP address, such as or https://IP (if SSL is setup).

import Countly from 'countly-sdk-react-native-bridge';

if(!await Countly.isInitialized()) {
Countly.setLoggingEnabled(true); // Enable countly internal debugging logs
Countly.enableCrashReporting(); // Enable crash reporting to report unhandled crashes to Countly
Countly.setRequiresConsent(true); // Set that consent should be required for features to work.
Countly.giveConsentInit(["location", "sessions", "attribution", "push", "events", "views", "crashes", "users", "push", "star-rating", "apm", "feedback", "remote-config"]); // give conset for specific features before init.
Countly.setLocationInit("TR", "Istanbul", "41.0082,28.9784", ""); // Set user initial location.

await Countly.init("", "YOUR_APP_KEY"); // Initialize the countly SDK.
Countly.start(); // start session tracking

After init and start have been called once, you may use the commands in the rest of this document to send additional data and metrics to your server. 

User Location

Countly allows you to send geolocation-based push notifications to your users. By default, the Countly Server uses the GeoIP database to deduce a user's location. However, if your app has a different way of detecting location, you may send this information to the Countly Server by using the setLocationInit orsetLocation methods.

We recommend using the setLocationInit method before initialization to sent location. This includes:

  • countryCode a string in ISO 3166-1 alpha-2 format country code
  • city a string specifying city name
  • location a string comma-separated latitude and longitude
  • IP a string specifying an IP address in IPv4 or IPv6 formats
// Example for setLocationInit
var countryCode = "us";
var city = "Houston";
var latitude = "29.634933";
var longitude = "-95.220255";
var ipAddress = "";

Countly.setLocationInit(countryCode, city, latitude + "," + longitude, ipAddress);

Geolocation recording methods may also be called at any time after the Countly SDK has started.
To do so, use the setLocation method as shown below.

// Example for setLocation
var countryCode = "us";
var city = "Houston";
var latitude = "29.634933";
var longitude = "-95.220255";
var ipAddress = "";

Countly.setLocation(countryCode, city, latitude + "," + longitude, ipAddress);

To erase any cached location data from the device and stop further location tracking, use the following method. Note that if after disabling location, the setLocationis called with any non-null value, tracking will resume.

//disable location tracking

Custom events

This is a quick summary on how to use custom events recording methods and what information they provide. For more information about how custom events and segmentations work, please review the Custom Events documentation.

Note that all data passed to the Countly instance via the SDK or API should be in UTF-8.

// Example for sending basic custom event
var event = {"eventName":"basic_event","eventCount":1};

// Example for event with sum
var event = {"eventName":"Event With Sum","eventCount":1,"eventSum":"0.99"};

// Example for event with segment
var event = {"eventName":"Event With Segment","eventCount":1};
event.segments = {"Country" : "Germany", "Age" : "28"};

// Example for event with segment and sum
var event = {"eventName":"Event With Sum And Segment","eventCount":1,"eventSum":"0.99"};
event.segments = {"Country" : "Germany", "Age" : "28"};

// Timed events
// Basic timed event

// Timed event with a sum
var event = {
  "eventName": "timedEvent",
  "eventSum": "0.99"

// Timed event with segment
var event = {
  "eventName": "timedEvent"
event.segments = {
  "Country": "Germany",
  "Age": "28"

// Timed event with segment, sum and count
var event = {
  "eventName": "timedEvent",
  "eventCount": 1,
  "eventSum": "0.99"
event.segments = {
  "Country": "Germany",
  "Age": "28"

User Profiles

You can provide Countly any details you may have about your user or visitor. This will allow you to track each specific user on the "User Profiles" tab, which is available in Countly Enterprise Edition. For more details, please review the User Profiles documentation.

In order to set a user profile, use the code snippet below. After you send a user’s data, it can be found in your Dashboard under Users > User Profiles.

// Example for setting user data
var options = {}; = "Nicola Tesla";
options.username = "nicola"; = "info@nicola.tesla";
options.organization = "Trust Electric Ltd"; = "+90 822 140 2546";
options.picture = "";
options.picturePath = "";
options.gender = "M";
options.byear = 1919;

Countly also supports custom user properties that you can attach for each user. In order to set or modify a user's data (e.g. increment, multiply, etc.), use the code snippet below.

// examples for custom user properties
Countly.userData.setProperty("keyName", "keyValue"); //set custom property
Countly.userData.setOnce("keyName", 200); //set custom property only if property does not exist
Countly.userData.increment("keyName"); //increment value in key by one
Countly.userData.incrementBy("keyName", 10); //increment value in key by provided value
Countly.userData.multiply("keyName", 20); //multiply value in key by provided value
Countly.userData.saveMax("keyName", 100); //save max value between current and provided
Countly.userData.saveMin("keyName", 50); //save min value between current and provided
Countly.userData.setOnce("setOnce", 200);//insert value to array of unique values
Countly.userData.pushUniqueValue("type", "morning");//insert value to array of unique values
Countly.userData.pushValue("type", "morning");//insert value to array which can have duplicates
Countly.userData.pullValue("type", "morning");//remove value from array

Crash reporting

With this feature, the Countly SDK will generate a crash report if your application crashes due to an exception and send it to the Countly server for further inspection.

If a crash report cannot be delivered to the server (e.g. no internet connection, unavailable server, etc.), then the SDK stores the crash report locally in order to try again at a later time.

You will need to call the following method before calling init in order to activate automatic crash reporting.

// Using Countly crash reports

You may also add breadcrumb crash logs to your crash report using addCrashLog and catch and send exceptions manually using logException. Please review the example code below.

Countly.addCrashLog("User Performed Step A");
setTimeout(() => { Countly.addCrashLog("User Performed Step B");}, 1000);
setTimeout(() => { Countly.addCrashLog("User Performed Step C");}, 1500);
setTimeout(() => {
   try {
     var a = {};
     var x = a.b.c; // this will throw an error.
   } catch (exc) {   
     var stack = exc.stack.toString();
     const customSegments = {"external_lib_version": "4.2.7", "theme": "dark"};
     const nonfatal = true;
     Countly.logException(stack, nonfatal, customSegments);

The method logExceptiontakes a string for the stack trace, a boolean flag indicating if the crash is considered fatal or not, and a segments dictionary to add additional data to your crash report.

View tracking

You may manually add your own views in your application, and each view will be visible under Analytics > Views. Below you may see two examples of sending a view using the Countly.recordview function.

// record a view on your application
Countly.recordView("My Home Page");
Countly.recordView("Profile Page");

While tracking views, you may want to add custom segmentation to them.

// record view with segments
Countly.recordView("View with Segment", {"version": "1.0", "_facebook_version": "0.0.1"})

Application Performance Monitoring

The Performance Monitoring feature allows you to analyze your application's performance on various aspects. For more details, please review the Performance Monitoring documentation.

Here is how you can utilize the Performance Monitoring feature in your apps:

First, you need to enable the Performance Monitoring feature:

// Enable APM features.

With this, the Countly SDK will start measuring some performance traces automatically, including app foreground time, app background time. Additionally, custom traces and network traces can be manually recorded.

App Start Time

For the app start time to be recorded, you need to call the appLoadingFinished method. Make sure this method is called after init.

// Example of appLoadingFinished
await Countly.init("", "YOUR_APP_KEY");

This calculates and records the app launch time for performance monitoring.
It should be called when the app is loaded and it successfully displayed its first user-facing view. E.g. componentDidMount: method or wherever is suitable for the app's flow. The time passed since the app has started to launch will be automatically calculated and recorded for performance monitoring. Note that the app launch time can be recorded only once per app launch. So, the second and following calls to this method will be ignored.

Custom trace

You may also measure any operation you want and record it using custom traces. First, you need to start a trace by using the startTrace(traceKey) method:


Then you may end it using the endTrace(traceKey, customMetric)method, optionally passing any metrics as key-value pairs:

String traceKey = "Trace Key";
Map<String, int> customMetric = {
"ABC": 1233,
"C44C": 1337
Countly.endTrace(traceKey, customMetric);

The duration of the custom trace will be automatically calculated upon ending.

Trace names should be non-zero length valid strings. Trying to start a custom trace with the already started name will have no effect. Trying to end a custom trace with already ended (or not yet started) name will have no effect.

You may also cancel any custom trace you started using the cancelTrace(traceKey)method:


Additionally, if you need you may cancel all custom traces you started, using the clearAllTraces()method:


Network trace

You may record manual network traces using the recordNetworkTrace(networkTraceKey, responseCode, requestPayloadSize, responsePayloadSize, startTime, endTime) method.

A network trace is a collection of measured information about a network request.
When a network request is completed, a network trace can be recorded manually to be analyzed via Performance Monitoring later using the following parameters: 

- networkTraceKey: A non-zero length valid string
- responseCode: HTTP status code of the received response
- requestPayloadSize: Size of the request's payload in bytes
- responsePayloadSize: Size of the received response's payload in bytes
- startTime: UNIX timestamp in milliseconds for the starting time of the request
- endTime: UNIX timestamp in milliseconds for the ending time of the request

Countly.recordNetworkTrace(networkTraceKey, responseCode, requestPayloadSize, responsePayloadSize, startTime, endTime);

Remote Config

Remote Config allows you to modify how your app functions or looks by requesting key-value pairs from your Countly server. The returned values may be modified based on the user profile. For more details, please review the Remote Config documentation.

// remoteConfigUpdate will update all remote config values

// updateRemoteConfigForKeysOnly will update only those values which keyname are pass in array

// updateRemoteConfigExceptKeys will update only values except which keyname are pass in array
// getRemoteConfigValueForKey will fetch remote config values for keyname sent

To erase all the values downloaded from the server call the function below.


User Consent Management

Being compliant with GDPR and other data privacy regulations, Countly provides ways to toggle different Countly tracking features on or off depending on a user's given consent. For more details, please review the Compliance Hub plugin documentation.

Currently, available features with consent control are as follows:

  • sessions - tracking when, how often, and how long users use your app
  • events - allows sending custom events to the server
  • views - allows tracking which views user visits
  • location - allows sending location information
  • crashes - allows tracking crashes, exceptions, and errors
  • attribution - allows tracking from which campaign did the user come
  • users - allows collecting and providing user information, including custom properties
  • push - allows push notifications
  • star-rating - allows sending the results from Rating Feedback widgets
  • feedback - allows showing the results from Survey and NPS® Feedback widgets
  • apm - allows application performance monitoring
  • remoteConfig - allows downloading remote config values from your server

Since the React Native Bridge SDK employs our iOS and Android SDKs, you may also be interested in reviewing their relevant documentation on this topic (iOS Consents and Android Consents).

Next we will go over the methods that are available in this SDK.

Method Parameters / Examples Description
setRequiresConsent boolean

The requirement for checking consent is disabled by default. To enable it, you will have to call setRequiresConsentwith truebefore initializing Countly. You may also pass a consent flag as true or false when you call init.

giveConsentInit string array of strings

To add consent for a single feature (string parameter) or a subset of features (array of strings parameter). Use this method for giving consent before initializing.

giveConsent string array of strings

To add consent for a single feature (string parameter) or a subset of features (array of strings parameter). Use this method for giving consent after initializing. 

removeConsent string array of strings

To remove consent for a single feature (string parameter) or a subset of features (array of strings parameter).

giveAllConsent none To give consent for all available features.
removeAllConsent none To remove consent for all available features.
// Usage examples


// for a single feature

// for a subset of features
Countly.giveConsentInit(["events", "views", "star-rating", "crashes"]);
Countly.giveConsent(["events", "views", "star-rating", "crashes"]);
Countly.removeConsent(["events", "views", "star-rating", "crashes"]);

// for all available features

The string values corresponding to the features that will be used in the giveConsent or removeConsent methods may be found here. In addition, please review our platform SDK documents if the feature is applicable or not for that platform.

Device ID

When the SDK is initialized for the first time and no device ID is provided, a device ID will be generated by the SDK.

For iOS: the device ID generated by the SDK is the Identifier For Vendor (IDFV).
For Android:  the device ID generated by the SDK is the OpenUDID or Google Advertising ID.

You may provide your own custom device ID when initializing the SDK using the method below.


Changing the Device ID

You may configure or change the device ID anytime using the method below.

Countly.changeDeviceId(DEVICE_ID, ON_SERVER);

You may either allow the device to be counted as a new device or merge existing data on the server. If onServer is set to true, the old device ID on the server will be replaced with the new one, and data associated with the old device ID will be merged automatically.
Otherwise, if onServer is set to false, the device will be counted as a new device on the server.

Temporary Device ID

You may use a temporary device ID mode for keeping all requests on hold until the real device ID is set later. 

To enable this when initializing the SDK, use the method below.

Countly.init(SERVER_URL, APP_KEY, "TemporaryDeviceID")

To enable a temporary device ID after initialization, use the method below.

Countly.changeDeviceId(Countly."TemporaryDeviceID", ON_SERVER);

Note: When passing the TemporaryDeviceID for the deviceID parameter, the argument for the onServerparameter does not matter.

As long as the device ID value is TemporaryDeviceID, the SDK will be in temporary device ID mode and all requests will be on hold, but they will be persistently stored.

When in temporary device ID mode, method calls for presenting feedback widgets and updating remote config will be ignored.

Later, when the real device ID is set using the Countly.changeDeviceId(DEVICE_ID, ON_SERVER); method, all requests which have been kept on hold until that point will start with the real device ID.

Enabling and disabling logging

If logging is enabled, our SDK will then print out debug messages regarding its internal state and problems encountered. Logging is disabled by default, but:

  • Enabling it during development is advised.
  • Enabling it before initialization is recommended so you may see the initialization process logs.
Countly.init(...); ...
// to disable it again later Countly.disableLogging();


If the data sent to the server is short enough, the SDK will use HTTP GET requests. In the event you would like an override so that HTTP POST may be used in all cases, call the setHttpPostForced function after you have called init. You may use the same function later in the app’s life cycle to disable the override. This function has to be called every time the app starts, using the method below.

// enabling the override
// disabling the override

Checking if init has been called

In the event you would like to check if init has been called, use the function below.

Countly.isInitialized().then(result => console.log(result)); // true or false

Checking if onStart has been called

For some Android applications, there might be a use case where the developer would like to check if the Countly SDK onStart function has been called. To do so, use the call below.

Countly.hasBeenCalledOnStart().then(result => console.log(result)); // true or false 

Push Notifications

Please first check our Push Notifications documentation to see how you can use this feature. Since Android and iOS handles notifications differently (from how you can send them externally to how they are handled in native code), we need to provide different instructions for these two platforms.

General Setup

First, when setting up Push for the React Native (Bridge) SDK, select the push token mode. This allows you to choose either test or production modes. Note that the push token mode should be set before initialization. Use the method below.

// Important: call this method before init method
Countly.pushTokenType(Countly.messagingMode.DEVELOPMENT, "Channel Name", "Channel Description");
// Countly.messagingMode.DEVELOPMENT
// Countly.messagingMode.PRODUCTION
// Countly.messagingMode.ADHOC

When you are ready to initialize Countly Push, call Countly.askForNotificationPermission() after init, using the method below.

// Call this method any time.
// This method will ask for permission,
// and send push token to countly server.

To register a Push Notification callback after initialising the SDK, use the method below.


Android Setup

Step 1: For FCM credentials setup please follow the instruction from this URL

Step 2: Make sure you have google-services.json from

Step 3: Make sure the app package name and the google-services.json package_name matches.

Step 4: Place the google-services.json file inside android/app

Step 5: Use google services latest version from this link

Step 6: Add the following line in the file android/build.gradle

buildscript {
    dependencies {
        classpath ''

Step 7: Add the following line in file android/app/build.gradle

// Add this at the bottom of the file
apply plugin: ''

iOS Setup

For iOS push notification please follow the instruction from this URL

For React Native you can find CountlyNotificationService.h/m file under Pods/Pods/CountlyPod/Core/CountlyNotificationService.h/m

You can drag and drop both .h and .m files from Pod to Compile Sources.


Attribution analytics & install campaigns 

Countly Attribution Analytics allows you to measure the performance of your marketing campaign by attributing installs from specific campaigns. This feature is available for the Enterprise Edition.

Call the method below before initialization.

// Enable to measure your marketing campaign performance by attributing installs from specific campaigns.

For iOS 13.7 and below, use the Countly.recordAttributionID("IDFA") function instead of Countly.enableAttribution()

You can use Countly.recordAttributionID the function to specify IDFA for campaign attribution


For iOS 14+ due to Apple changes regarding Application Tracking, you need to ask the user for permission to track the Application.

For IDFA you can use this Plugin, which also supports iOS 14+ changes for Application tracking permission:

Here is how to use this plugin with the Countly attribution feature:

npm install --save

cd ./ios
pod install

Add "Privacy - Tracking Usage Description" in your ios info.plist file.

#Example Code for Countly attribution feature to support iOS 14+.

import RNAdvertisingId from 'react-native-advertising-id';

if (Platform.OS.match("ios")) {
.then(response => {
.catch(error => console.error(error));
else {
Countly.enableAttribution(); // Enable to measure your marketing campaign performance by attributing installs from specific campaigns.

Receiving user feedback

There are a different ways of receiving feedback from your users: the Star-rating dialog, the Ratings widget, and the Surveys widgets (Surveys and NPS®).

The Star-rating dialog allows users to give feedback as a rating from 1 to 5. The Ratings widget allows users to rate using the same 1 to 5 emoji-based rating system as well as leave a text comment. The Surveys widgets (Surveys and NPS®) allow for even more targeted feedback from users.

Ratings widget

The rating widget displays a server-configured widget to your user devices.

All the text fields in the example above can be configured and replaced with a custom string of your choice.

In addition to a 1 through 5 rating, it is possible for users to leave a text comment and an email, should the user like to be contacted by the app developer.

Showing the rating widget in a single call involves a two-set process: before it is shown, the SDK tries to contact the server to get more information about the dialog. Therefore, a network connection to it is needed.

To display the widget after initializing the SDK, you will first need to get the widget ID from your server, as shown below.

Then, call the function to show the widget popup using the widget ID below.

Countly.showFeedbackPopup("WidgetId", "Button Text");

Star-rating dialog

The Star-rating integration provides a dialog for getting user feedback about an application. It contains a title, a simple message explaining its purpose, a 1 through 5-star meter for getting users rating, and a dismiss button in case the user does not want to give a rating.

This star rating has nothing to do with Google Play Store ratings and reviews. It is simply for getting brief feedback from your users to be displayed on the Countly dashboard. If the user dismisses the star-rating dialog without giving a rating, the event will not be recorded.


The star-rating dialog's title, message, and dismiss button text may be customized either through the init function or the SetStarRatingDialogTexts function. 

Countly.SetStarRatingDialogTexts("Custom title", "Custom message", "Custom dismiss button text");

Surveys widget

It is possible to display 2 kinds of Surveys widgets: NPS and Surveys. Both widgets are shown as webviews and they both use the same code methods. 

Before any Surveys widget can be shown, you need to create them in your Countly Dashboard.

When the widgets are created, you need to use 2 calls in your SDK: one to get all available widgets for a user and another to display a chosen widget.

To get your available widget list, use the call below.

Countly.getAvailableFeedbackWidgets().then((retrivedWidgets) => {
},(err) => {

From the callback, get the list of all available widgets that apply to the current device ID.

The objects in the returned list look like this:


To determine what kind of widget that is, check the "type" value. The potential values are survey and nps.

Then use the widget type and description (which is the same as provided in the Dashboard) to decide which widget to show.

After you have decided which widget you want to display, call the function below.

Countly.presentFeedbackWidget("WIDGET_TYPE", "WIDGET_ID", "CLOSE_BUTTON_TEXT");

Native C++ Crash Reporting

If you have C++ libraries in your Android app, the React Native Bridge SDK allows you to record possible crashes in your Countly server by integrating the sdk-nativedeveloped within our Android SDK. Find more information here.

As this feature is optional, you will need to uncomment some parts in our SDK files in order to make it available.

1. Go to android/build.gradleand add the package dependency (all file paths in this section are given relative to the countly-sdk-react-native-bridgewhich was npminstalled above):

dependencies {
    implementation ''    

2. Uncomment the following in the android/src/main/java/ly/count/android/sdk/react/CountlyReactNative.javafile:

  public void initNative(){
  public void testCrash(){

3. Modify Countly.jsto connect from JavaScript to these new methods:

Countly.initNative = function(){

Countly.testCrash = function(){

If you are using our sample app in example/App.js, also uncomment the following parts in it for easy testing:



// ...

            < Button onPress = { this.initNative } title = "Init Native" color = "#00b5ad"> 
            < Button onPress = { this.testCrash } title = "Test Native Crash" color = "crimson"> 

We suggest calling Countly.initNative() as soon as your app is initialized to be able to catch setup time crashes. Sending crash dump files to the server will be taken care of by the Android SDK during the next app initialization. We also provide a Gradle plugin that automatically uploads symbol files to your server (these are needed for the symbolication of crash dumps). Integrate it into your React Native project as explained in the relevant Android documentation page.

This is what the debug logs will look like if you use this feature:

$ adb logcat -s Countly:V countly_breakpad_cpp:V

# when Countly.initNative() is called 

D/countly_breakpad_cpp(123): breakpad initialize succeeded. dump files will be saved at /Countly/CrashDumps

# when a crash occurs (you may trigger one by Countly.testCrash())

D/countly_breakpad_cpp(123): DumpCallback started
D/countly_breakpad_cpp(123): DumpCallback ==> succeeded path=/Countly/CrashDumps/30f6d9b8-b3b2-1553-2efe0ba2-36588990.dmp

# when app is run again after the crash 

D/Countly (124): Initializing...
D/Countly (124): Checking for native crash dumps
D/Countly (124): Native crash folder exists, checking for dumps
D/Countly (124): Crash dump folder contains [1] files
D/Countly (124): Recording native crash dump: [30f6d9b8-b3b2-1553-2efe0ba2-36588990.dmp]

Pinned Certificate (Call this method before initialization)


openssl s_client -connect -showcerts

Run the above command and copy the content inside the begin certificate and the end certificate.

Example files: Android and iOS. Note that Android needs the certificate string, while iOS needs the entire .cer file.


cd AwesomeProject
mkdir -p ./android/app/src/main/assets/
cp ./ ./android/app/src/main/assets/


open ./ios/AwesomeProject.xcworkspace
Right click on AwesomeProject and select `New Group` (ScreenShot 1)
Name it `Resources`
Drag and Drop file under that folder (ScreenShot 2)
Make sure copy bundle resources has your certificate (Screenshot 4).






Note that is the name of the file. Replace this file with the one you have.

Interacting with the internal request queue

When recording events or activities, the requests don't always get sent immediately. Events get grouped together. All the requests contain the same app key which is provided in the init function.

There are two ways to interact with the app key in the request queue at the moment. 

1. You can replace all requests with a different app key with the current app key: 

//Replaces all requests with a different app key with the current app key.

In the request queue, if there are any requests whose app key is different than the current app key, these requests app key will be replaced with the current app key.

2. You can remove all requests with a different app key in the request queue:

//Removes all requests with a different app key in request queue.

In the request queue, if there are any requests whose app key is different than the current app key, these requests will be removed from the request queue.

Setting an event queue threshold

Events get grouped together and are sent either every minute or after the unsent event count reaches a threshold. By default it is 10. If you would like to change this, call:



Was this article helpful?
0 out of 0 found this helpful

Looking for help?