Countly is an innovative, real-time, open source product analytics application, built with features for every team. It collects data from mobile phones, desktop apps (Mac OS X & Windows), web apps, and websites, and visualizes this information to analyze application usage and end-user behavior. Countly is product analytics for companies that care about user data privacy.
Events
An event in Countly represents one of the following:
- An action of the user, such as an interaction with a single UI element or set of elements
- A significant milestone the user reaches after completing other actions, such as completing an application or onboarding process
- A transaction that takes place after one or more actions of the user, such as a backend API returning a result
It is a basic building block and used as the base for other features that build on top of it.
User Identification
Due to the data security, privacy and ownership focus of Countly, the detail and identification possibility level of data collected with Countly is incomparable to traditional analytics platforms. This applies to all data points but most importantly, identification of the entity the analytics data is originating from changes the nature of your entire analytics strategy.
By default, Countly embraces anonymous tracking using an identifier that is unique per device or browser. This results in User Profiles, and the metric of “users” across all reporting to be device or browser-based rather than representing your actual customers.
However, Countly has an elaborate user identification implementation that lets you track your actual customers even across platforms.
User Properties
User properties in Countly define and enhance the entity the data is originating from, the “user”. There are three types of user properties:
- Device metrics: These are sent together with the session request automatically which is triggered when the app is launched and include metadata such as app version, device, platform and platform version.
- Named properties: These properties have a reserved place in the User Profiles detail screen such as name, organization, gender, age. You can optionally set them using the API calls and/or SDKs.
- Custom properties: These properties are optional key-value pairs, where value can be a string, number, boolean, or an array. There are various modifiers available in the API/SDKs such as set, set once, push unique, increment, multiply to update these as you need.
All the data (sessions, events, views, crashes etc.) originating from a user will be stored together with a historical snapshot of user properties in the granular data storage and will be available to be used in reporting and filtering in features such as Cohorts, Funnels, Drill, Retention, Formulas, and User Profiles.
Compliance Hub
Countly puts customer data privacy at the forefront of its platform. Your journey with Countly starts with assessing whether you need to get consent from your customers for data collection. There are legal considerations and platform-specific considerations that you will need to delve into together with your legal/compliance team. Countly provides you with an essential built-in mechanism called Compliance Hub to help with these efforts.
Compliance Hub enables:
- Storing the timeline/history of opt-ins and opt-outs for features or feature groups together with device ID, timestamp and country-level location information
- Purging individual user/device data
- Exporting individual user/device data
Compliance Hub does not:
- Store customer opt-in/opt-out states for features or feature groups. It is expected that your app stores this information in its persistent storage of choice.
- Provide opt-in/opt-out forms or visual UI elements. You should have your own consent forms, with your own legal language based on your business’ legal basis of data collection.
- Provide a mechanism to collect data subject requests such as purge/export. These requests should be handled in a more general context outside of Countly.
If you already have a consent mechanism, and you get consent from your customers for the level of data you will be collecting via Countly, then you will not necessarily need Countly Compliance Hub. It is still a good practice to assess whether you should pass your existing consents to the Countly side, especially to be able to serve data subject requests.
App Separation
Data inside Countly is stored inside containers called applications. Applications provide the first level of control while accessing the dashboard, raw data and APIs since dashboard users and user groups are assigned to applications they have access to. Furthermore, reporting and data storage are based on this concept of an application. Countly initialization requires an app_key variable on the SDK level, which determines the individual app on Countly Server the data will be sent to.
Applications in Countly do not necessarily have to one-to-one match your offerings in different platforms. Furthermore, a single application can be represented as two applications on the Countly side, for example, pre-login and post-login areas can be two separate apps on Countly.
Voice of the Customer
Countly has three different ways to help you make the voice of your customers be part of your analytics strategy: Surveys, NPS and Ratings.
Surveys let you create in-app survey widgets with up to five questions each. You can target the surveys to be visible only to a matching subset of your customers based on their user properties or actions within your application.
Using NPS surveys, you can collect 0-10 scores from your customers about a specific question such as “How likely would you recommend us to a friend or colleague?” as well as having one follow up question based on the score bracket. Just like surveys, NPS surveys can be targeted based on customer metadata and activity.
Ratings, on the other hand, is a simple widget that gives you the ability to collect a 1 to 5 rating (via a face-based choice) together with a comment if you choose to.