Differences between Apsalar & GA decoded

There’s a good chance that anyone who works on mobile apps works with both Apsalar (or any other attribution tool) and Google Analytics. If you fall in that segment, I’m sure you’ve wondered why the two tools show different statistics for new users or retention.

In this post I aim to give you an in-depth explanation on how the two tools work. To anyone who is new to the world of mobile apps — Apsalar is a mobile ROI & attribution tool used by companies to track the number of installs by source and also for in-app analytics to a certain extent. So without further ado, let’s get into the specifics.

New users

Google Analytics

Identifies a new user by a client id (cid) which is a random string generated every-time the user installs the app (similar to a cookie implementation for the web). However this id is reset every-time the user uninstalls the app/clears the app data. Hence the count of new users/total users for Google Analytics is/can be higher than the actual number of unique devices. There is also an alternative user id implementation which can give different results.


Apsalar remembers the unique identifiers of the users’ devices that ever installed your mobile app — namely the ANDI(Android device id) and the AIFA(android advertising id) . As per Google Advertiser policy, Apsalar can now only use the AIFA (since AIFA can be reset by the user.) Hence if a user uninstalls and then later re-installs your app, as long as the AIFA is unchanged the user is not treated as a new user.

Please note that the ‘user’ is counted only on an ‘app open’ in both the tools. If the user never opens your app, the SDK isn’t initialized and neither of the two tools can count the user.


Google Analytics

Google analytics for android(which is similar to the web implementation) groups hits received in a time-period of 30 mins as one session. One can also configure the session using the API. For example one can start a new session everytime the app is placed in the background for a period of time.


Since the count of unique sessions is based on the definition of unique users the overall session count can be different from the actual figure for apsalar. Also the duration of the session is dependant on the implementation of a session.

A session starts when one calls the Apsalar.startSession method. Also the session is kept alive as long as the events are being sent from the SDK. Apsalar also has a ‘heart beat’ mechanism which it uses to check if the session is alive.

Along with this Apsalar also provides a ‘endSession’ & ‘restartSession’ method to further control the length of your session. You can find more information on this here.

Session control in Apsalar


Google Analytics

Using Cohort Analysis in the Audience explorer you can check the retention rate for your new users. Currently the ‘acquisition date’ is the ‘the first time a user is recognised as interacting with your content’. This is similar to the way Apsalar counts it’s new users.

However, there is one key difference. The default retention in google analytics is determined for all your users. Since this retention would depend on the quality of users acquired during a particular channel(if you have paid acquisition campaigns running), one can create a segment and check the retention for this channel over a particular duration.

Cohort Report — Apsalar

Sample Google Analytics — App retention — last 7 days.

Image source: Google Analytics documentation.


To check the retention rate in Apsalar, one should refer to the cohort report.

Cohort Report — Apsalar

Cohort Report — Apsalar

Cohort report in Apsalar — select ‘unique users’ & ‘% of total’ to get a report similar to Google Analytics. Also select ‘Retention’ as the measure on top.

Which retention rate is more accurate?

Typically we see lower retention rates in Apsalar than Google Analytics. Based on your GA configuration, one can determine the retention for a unique user id too. We see a difference in 3–5% in the weekly retention rates for the two platforms. GA retention rates are bit inflated but over a period of time, one can use it to track app performance.


One can configure events in both Google Analytics & Apsalar. In my opinion, the event functionality of GA is perhaps the most robust option.

An event in Google analytics is defined by an

  1. Event category
  2. Event action
  3. Event label

(I also wrote about how we use events to track our search performance. Read the article here.)

Events in Apsalar are limited in functionality. One should typically pass only the required goals like a purchase for an e-commerce app. Additional event data can be passed using a JSON feed however it isn’t readily available and hence not of much use.That’s it for now. Below are some links for your reference.

I’ll wrap up this post with the few resources on this topic that I’ve found very useful.

  1. http://support.apsalar.com/customer/portal/articles/772135-managing-session-lengths-and-counts-with-the-android-sdk
  2. https://developers.google.com/analytics/devguides/collection/android/v4/sessions
  3. http://support.apsalar.com/customer/portal/articles/1816516-comparing-apsalar-traffic-report-to-google-adwords
  4. http://support.apsalar.com/customer/portal/articles/717491-events

If you found the article useful, do recommend :)

A big thank you to Aamna Khan for reading the draft and making the article more readable.

Leave feedback!

Currently building & growing Gaana — India’s Favorite Music app.

I would love it if you give it a try. You can follow me on Twitter or Linkedin