Frequently Asked Questions

Last Updated: Feb 29, 2016 04:14PM PST

Applications and SDK

Do I need different SDKs for iOS and Android? Answer

Yes, there is a different SDK for iOS and Android applications, however, these are bundled together in the Apsalar SDK download file, so you only need to do a single download. To download the SDKs log in and go to Developer Tools.


How do I download the SDK? Answer

If you are a registered user, the SDK will be sent in your registration confirmation email. You can also log in to Apsalar, select "Get the SDK" from Developer Tools, and then follow the instructions for downloading the SDK.


Do you provide SDK source code? Answer

You can request the shared source code for our SDKs by emailing The use of the shared source code is subject to our Terms of Use.


I have downloaded the SDK, what’s next? Answer

Time to integrate the SDK into your applications and use the Apsalar platform.

Integration is as easy as adding the SDK libraries to your iOS or Android project and then placing the appropriate API calls into your apps for managing sessions and tracking events. For instructions on installing and integrating the SDK review our integration guides.

Once you have integrated the SDK, you can then use the Apsalar website for defining conversion funnels and cohort analysis.

How big is the Apsalar SDK footprint in my application? Answer

Please read this article for more information.


How much data does Apsalar's SDK use? Answer

While data usage will vary based on each user's unique configuration of start sessions and events, here are some generalized numbers to help calculate data usage in your own application:

  • First Launch: The first time a user launches your application on their device, the Apsalar call will use approximately 500 bytes. 
  • Start Session: After the first launch, subsequent start sessions will use approximately 200 bytes
  • Events: Events will use between 100 and 500 bytes, depending upon the number of attributes configured for the event.
  • Optional Heartbeat: The optional heartbeat feature, enabled by default, which supports tracking session lengths in both our iOS and Android SDKs use approximately 100 bytes per call. The calls start at 5 minutes, doubling in duration for each subsequent call (5 minutes, 10 minutes, 20 minutes, 40 minutes, etc) until reaching 6 hours. If the user triggers any events during those durations, the heartbeat call is delayed until the reaching the next duration. 
If you have any remaining questions or concerns regarding Apsalar's data usage within your application, please contact our Product Support Team.



How does Apsalar identify my application, since I am using the same API Key and Secret? Answer


Apsalar maintains two ‘names’ for your application.

  • Long Name: For iOS, we use the Bundle identifier (CFBundleID in Xcode 3.x and earlier) as the long name. For Android, we use the package name defined in the manifest.xml file. The long name is the unique identifier for your application. The long name is used to identify your app when a session is started and for all subsequent interaction through the SDK. If you change the Bundle identifier/CFBundledID or package name and rebuild your app, it will be seen as a different app.
  • Display Name: This is what we get from the Bundle name (CFBundleName in Xcode 3.x and earlier) for iOS or the application label (e.g., <application android:label=”@string/app_name” > ) from the manifest.xml file for Android. We use the display name to reference your app in the reports and other places on our site. If you have more than one app with the same display name, the long name will also be displayed to differentiate between them. You might have this condition if you have one app with a long name reflecting a test version but uses the same display name as the production version. These would be two different apps with the same display name.



What performance impact will Apsalar have on my application? Answer

Apsalar should not impact the performance of your app. Even though we record session and event information in real-time, this is completely handled in a separate thread.


How can I test my integration? Answer

To test your integration with Apsalar and to verify session and event data is being recorded, we recommend that you:

  1. Create a separate account for testing purposes
  2. Use the test account API key and secret in your integration
  3. Verify data is being recorded by looking at dashboard reports. Please wait a few hours for our batch reports to run and for data to populate
  4. When building the production version of your application, replace only the API key and secret in your integration (for startSession and reStartSession calls) with that of the production account




Events and Sessions

How is event and session data sent to Apsalar? Answer

All event and session data is sent to Apsalar in real-time using a background thread. Events and session data is sent one event at a time using a single HTTP request for each occurrence.


What is the bandwidth consumed for sending event and session data? Answer

Each HTTP request consumes about 0.2KB of bandwidth. So 1,000 events consume 200KB.


Is there a limit to the number of events you may track? Answer

There are no limits on the number of events you may track, but there are limits on the number of event names, per app version.

You are limited to 400 event names per app version. If you exceed the 400 event name limit in your application, new event names for that particular app version will not register. 
Your events should be hard-coded within your application, never created dynamically when a user action is triggered. To keep event names to a minimum, Apsalar recommends implementing attributes for your event (e.g. purchase_one_tree, purchase_two_trees; product_id; etc.).

  • If you have dynamically generated event names, you should remove them and use attributes instead. 
  • If you are over this limit, all new event names will be rejected.
  • Release a new application version with less than 400 (usable) event names if you have more than 400 event names. 



Is there a limit on the volume of events that you may track? Answer

We do reserve the right to limit the event traffic rate/volume for our free accounts. Please contact us if you are expecting high volumes so we can accommodate them.




Is there a cost to using Apsalar’s analytics package? Answer

Basic event tracking is available with our free analytics package. To take advantage of our full analytics suite, please contact for pricing details.


Are there any functional limits with the free analytics package? Answer


Your plan will allow you to track data points, subject to the following restrictions.

  • There is a limit of 10 event names for each application version. For your reference, we have compiled a set of best practices for setting up event names.
  • There is a limit of 15 for all active funnel analyses. Deactivated or deleted funnels do not count towards this limit.
You can track your usage and limits on your Apsalar account page.

For more information and to upgrade, please review Apsalar's platform plans or email us at



What if I want more functionality than what I get with the free analytics? Answer

We will be happy to discuss your needs! You can contact us here.


What are your terms of service? Answer

You can read our terms of service and our privacy policies here.


Can I use one account for multiple apps? Answer

Yes, all of your applications can be managed under one account. Apsalar also provides cross-app analytics and reporting within one account.


Do I need to have a separate API Key and Secret for all of my apps? Answer

No. Apsalar provides cross-app analytics, and all of your apps and their related analytics are part of a single account. All of your apps will use the same API Key and Secret for communicating with the Apsalar platform.


Where do I find my API key and secret? Answer

The API key and secret for the account can be found on the Get the SDK page. Click on Developer Tools on the top right navigation bar and select Get the SDK.




What platforms does Apsalar support? Answer


Our SDK runs on Android and iOS.

For iOS device architectures, Apsalar supports:

  • iPod touch 3 and above

  • ​iPhone 3GS and above

  • All iPads

The Apsalar iOS SDK supports iOS 4.3 and above.

The Apsalar Android SDK supports Android 2.1 and above.



How much extra coding is needed to use Apsalar’s tools? Answer

Very little.

Basically, whether you have an iOS or an Android application, you need to add a singe line of code in order to start, end, or restart an Apsalar session. You will also need to add a single line of code whenever you want to track an event.


How do I opt out from behavioral advertising? Answer


Apsalar honors opt-out flags as set by the device operating system.  This capability is only available to mobile devices using iOS 6 and greater.  The functionality is not supported by Android.

Complete the following steps:

1. Select "settings"

2. Select “General”

3. Select “About”

4. Select “Advertising”

5. Turn Limit Ad Tracking “On”

Once complete, this flag will be passed by our advertising partners and users will not be considered for behavioral advertising.



Where can I find Apsalar's Feature History? Answer

You can find it here




(Install Referrer) Why are there campaigns I don't recognize in the Traffic Report for my Android app? Answer

One of the attribution methodologies used by Apsalar for Android installs is Google's Install Referrer method. Here is Google's documentation regarding the Install Referrer:

When a user clicks on an Apsalar Attribution Tag for Android and are redirected to the Google Play Store app, Apsalar appends a click ID to the Google Play Store URL in the referrer parameter. When that user downloads and launches the app, the Apsalar receiver captures the data from the referrer parameter. If the Apsalar click ID that is captured matches the click ID we appended to the referrer parameter upon redirecting the user to the Google Play Store, we record an attribution.

Campaign data such as campaign source, campaign name, and campaign group can also be passed in the referrer parameter, using what are called UTM parameters. If the Apsalar receiver captures referrer data that includes UTM parameters when a user installs an app, and there is no corresponding click from an Apsalar Attribution Tag, we will attribute the install to the campaign source, campaign name, and campaign group that is specified by the UTM parameters. 

Here is an example of a Google Play Store app link with a referrer parameter that contains UTM parameters:

When we receive UTM parameters, we map them in our Traffic Report as follows:
  • utm_source = Campaign Source
  • utm_campaign = Campaign
  • utm_term = Campaign Group

There are some instances where users can be redirected to the Google Play Store by a 3rd party that is not using an Apsalar Attribution Tag. This 3rd-party source will append the Google Play Store link with a referrer parameter and UTM parameters, leading to these campaigns populating in the Traffic Report. 

The most common occurrences of this behavior come from users finding your app in a 3rd-party app store (i.e., not Google Play Store). Some 3rd-party apps may have a listing for your app, which will redirect users to the Google Play Store page if a user clicks "download". Example of these 3rd-party apps stores are (this list is not exhaustive):
  • 1MobileMarket
  • 79 or 79Market
  • appbrain

The other common source is Facebook, via the "Find Apps" section of the Android Facebook app. If a user clicks "Install" from within the Facebook app, they will be redirected to the Google Play Store app, and their install will be attributed to as the Campaign Source.

While Apsalar cannot prevent campaign data from entering our system in this manner, this data can be a valuable insight into how users are organically finding your app. In all of these instances, this type of install can essentially be considered an organic install that came from a specific source, as opposed to the user searching for your app manually in the Google Play Store.






In DataSync Integrations, default integration rules are created automatically as you activate an integration. They are set up to cover the most common integration use cases. Note that you can edit and change every rule at any time by clicking on the 'configure' link of an activated integration.

seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found