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 192.168.1.0/24 to let all IPs inside 192.168.1.0 IP block to access dashboard and disallow other IPs.

What does Countly collect from SDKs?

Countly has different properties available, and collected from end users via SDK:

  • Default metrics, or properties: This is explained below in its own topic.
  • Custom user properties: This is much like default metrics, but they are custom metrics and they can hold not only key:value pairs but also array like more complex objects more modifier examples. Custom users properties are also saved into app_usersAPPID collection (for Enterprise Edition), also all drill documents have a field as "custom" which contains values of custom user properties at the time of session, custom event, crash or view occurrence.
  • Event level metrics (called segmentations): Event segments work in a one-time logic, meaning there is no history or automatic association that exists in default metrics and custom user properties.

Default metrics (properties) collected

Those are the metrics collected by default on each session start of the user. These properties reside in app_usersAPPID collection for each individual user (for Enterprise Edition) and also these metrics are saved into aggregated data format to report users, new users, sessions per metric, like device (for Community Edition). Apart from that, in each granular record of a session, view, event or crash has these metrics.

Default hardware, software and telemetry data collected

  • Application Key
  • Generated device ID or custom ID
  • Session duration extension (Helps calculate 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 or browser language, e.g German)
  • Store (Store that this app is downloaded from, e.g Google Play)
  • Traffic sources and search terms (for web SDK)
  • Browser information (e.g Chrome, Firefox)

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 (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)

If symbolication service is used

  • Phone architecture, saved crash stack trace, load addresses of apps binary images, crash mapping file (iOS devices)
  • Saved crash stack trace and crash mapping file (Android devices)

Views

  • 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)