Countly Documentation

Countly Resources

Here you'll find comprehensive guides to help you start working with Countly as quickly as possible.

Security & privacy FAQ

We take security very seriously here at Countly, since our main focus is privacy of your data, and we know and understand how important the responsibility of safeguarding this data is to our customers. There are several measures we have undertaken for Countly, and you'll find a list of questions here to make your instance more secure.

We have worked with many companies to date and we have an extensive knowledge in this domain, especially when it comes to General Data Protection Regulation (GDPR), HIPAA and COPPA, collaborating with several parties and conforming to their standards and regulatory laws. This has enabled us to make Countly the platform of choice when it comes to data privacy and security. Below you can read some of the unique features of Countly and how it helps secure sensitive information.

  • Self-hosting options: Countly can be installed on-premise (i.e. either in your own data center or with a trusted hosting partner), allowing for a greater depth and breadth of security and control. Self-hosting means that no third party (not even Countly) ever has access to your data unless you permit it.
  • Secure transmission: Data collected from devices are sent over a secure channel, and cannot be tampered — this eliminates intruders and potential man-in-the-middle attacks.
  • Right to be forgotten rule: If a EU citizen asks for his data to be removed, it can be done in Countly so his data is completely wiped out. Countly also has a “Filtering Rules” plugin which blocks data from reaching Countly database using several criteria like username, email, IP address, deviceID etc.
  • Do not track: GDPR also stipulates that individuals have a right to ‘block’ or suppress processing of personal data. If an individual decides not to be tracked, Countly has a function to support this. If it is invoked, then we do not track that user at all.
  • Data-at-rest encryption: When data is stored, we can use data-at-rest encryption, further enhancing the security of personal data, making it impossible for a rogue employee to reach this data.
  • Extensive system audit logs: There are more than 30 different system logs collected, and this helps system administrator know what is happening inside the server. In case of an emergency or an audit, logs can be viewed, allowing organization insight into what has happened and the cause of issue.
  • Login security: We have several methods to keep logins secure — Countly can require strong passwords, only permit logins via HTTPS, and ban users when there is a brute force attack.
  • Access levels: Countly dashboard users can only view what what has been enabled for them. Administrators have the ability to disable a menu item or a view (e.g User Profiles) for specific users. This way, only necessary and required data is shown.
  • No IP address storage: Countly doesn’t store any IP address, but rather converts IP to user’s city and then discarding the IP. For customers where this is an issue, Countly has the ability to completely remove city and country information.
  • Data portability: Our database schema is completely open, allowing any Countly client to transfer data from Countly to another service easily.

How do I enable password expiration?

You may enable password expiration under Management → Configuration → Security → Password expiration. You can set it to 0 (no password expiration), or to a number like 20, where password expires after 20 days and must be changed.

Is it possible to block logins after failed logins?

Yes, this is configurable under Management → Configuration → Security → Allowed Login attempts and default value is 3, after which account will be locked for amount of time configurable under Management → Configurations → Security → Incorrect Login block time increment. On consecutive failed logins account will be blocked with increased time, so if configured value is 5 minutes, then after 5 minutes expire, if a user fails to login 3 more times, it will be locked for 10 minutes, then 15 minutes, etc.

How do I enable password rotation?

Countly can be configured so that a user may not be able to use his one of previous passwords. In order to enable this, go to Management → Configurations → Security → Password rotation and define number of previous passwords user should not be able to reuse.

How to add authentication to MongoDB?

See this documentation for adding a username and password to MongoDB.

How do I configure Countly to accept HTTPS connections?

This documentation can be used to configure Countly to accept HTTPS connections.

How do I use Let's Encrypt certifications for HTTPS?

In order to use Let's Encrypt certificates, please follow this guideline.

How can I enable pinning public key of SSL certificate for extra security?

Pinning can be used to provide extra security for Android and iOS. Use this documentation for Android certificate pinning and this one for iOS certificate pinning.

How do I use parameter tampering protection?

Countly can be configured to use a salt (from Management → Applications and inside the SDK) to add checksum to SDK requests in order to prevent parameter tampering. For more information about parameter tampering, see this documentation.

For iOS, configuration can be done using guidelines here, and for Android, see this link (under Parameter Tampering).

How do I allow an IP to access to dashboard and disallow others?

This can be done by modifying nginx configuration file (/etc/nginx/conf.d/sites-enabled/default.conf or /etc/nginx/conf.d/default.conf depending on your operating system). Below you can see which parts to add for a server without HTTPS connectivity:

Note that for servers where HTTPS is configured, there are two server { blocks instead of one, hence this configuration should be applied on both blocks.

Since allow parameter accepts IP masking, you may use allow to let all IPs inside IP block to access dashboard and disallow other IPs.

What data does Countly collect by default?

Default hardware, software and telemetry data collected

  • Application Key (App_Key of the application)
  • Generated device ID
  • Session duration (Gives duration of a session)
  • Country code & city (Gives country and city, from IP address. IP address is discarded)
  • Operating system (Platform of the device, e.g Android)
  • Operating system version (Platform version, e.g 7.0)
  • Device resolution (e.g 1344x768)
  • Carrier (e.g Verizon)
  • Application version (Version of the application)
  • Density (e.g XXHDPI or @2X)
  • Locale (device language, e.g Polish)
  • Store (Store that this app is downloaded from, e.g Google Play)

Crash data

  • Crash dump (Whole crash dump of the error)
  • Current and total RAM (RAM sizes at the time crash occurred)
  • Current and total disk space (Disk sizes at the time crash occurred)
  • Online or not (Whether device had an active connection when crash happened)
  • Muted or not (Sound - Whether the device was muted or not when crash happened)
  • App is in background or not (Whether app was in background or not when crash happened)
  • Name of crash (Name of crash)
  • Fatal or non-fatal (Whether crash caused app to exit or not)
  • Running time of app (how long the app was running at the time of crash, in seconds)
  • Any custom key/value provided by developer (Any value that can help identify cause of crash)


  • Which screens user has visited

Install attribution

  • Campaign name (Name of the campaign this user has been attributed / converged)
  • Campaign ID (ID of the campaign)

Security & privacy FAQ