We Are Countly

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.

Foundations of Countly

Countly is designed to be helpful not only for teams who interact with data daily but also for everyone in an organization that touches the digital customer journey. Product, Engineering, Customer Success, Support, Design, Data and Marketing teams are typical audiences of Countly. 

With such a broad audience in our customer organizations, we have formed the below six principles over the years to help our team and our customers to develop the healthiest partnership towards creating better customer journeys on digital products.

1. More data is never more information and insight. Tracking everything you possibly can, or going further and doing this automatically, has never been our way. We are big fans of first defining the questions and then planning the data to answer these questions.
2. Analytics is a journey, not a one-off implementation. Your Countly implementation will change over the months you will be with us. Starting with a minimum viable implementation and scaling it as you go almost always works best.
3. You can’t do it all at once. Countly is a comprehensive platform, being actively developed since 2013. All capabilities Countly provide are there to help you understand and build better customer journeys but trying to tackle everything all at once is not the right approach. Just as you define the questions and then plan for data, you need to select the most important sets of questions and actions to decide which parts of Countly you will start with, and then we will scale from there together.
4. Assign Countly related responsibilities to one or a few team members. You get assigned an Account Manager as soon as you start your journey with us. The best way to utilize this relationship is to give the Countly relationship responsibility to one or a few people on your side. Your AM will proactively guide you, and provide you with best practices and access to resources and other Countly team members.
5. Keep us involved. Team Countly and your Account Manager are here to be a part of your growth. The more relevant information you provide us with, the better we can help you. A new product launch? A new feature? A pivot, or a test? We would like to be a part of it to help you better.
6. You will need to unlearn certain concepts of the past. Countly is a platform with your customers at the heart of it and a comprehensive suite of tools to turn data into information, insight and action. Pageviews, hits, and bounce rates are still there, but these metrics are just a tiny portion of the value we would like you to get with Countly.

This living document aims to provide in-depth information on three core concepts of Countly, Data Setup, Data Exploration and Acting on Data. We will take you through this journey, and this document will be the baseline for Team Countly and you for our mutual success.

Consents / 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 (such as Apple/iOS 14.5) 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:

• Instructing the SDKs to start only after the user gives consent by setting a built-in SDK level flag
• Defining granular & customizable feature level flags to get user consent in feature groups or for each individual feature
• Storing the timeline/history of opt-ins and opt-outs for these 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 / Segregation

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 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.

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 a platform-dependent 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 and merging implementation that lets you track your actual customers. In summary, below user identification implementations are possible with Countly:

1. Tracking only known users. Starting Countly not on app-launch but when you acquire a customer identifier such as an email address or account number after customer login.
2. Tracking only known users, with pre-tracking. Starting Countly in offline mode on app-launch but sending data only when you acquire a customer identifier.
3. Tracking anonymous and known users, with server merging. Starting Countly on app-launch with anonymous tracking, changing the user identifier after login and merging the two entities on the server-side.
4. Tracking anonymous and known users without server merging. Starting Countly on app-launch with anonymous tracking, changing the user identifier after login and keeping the two entities separate on the server-side.
5. Tracking pre-login and post-login states in 2 separate apps. Starting Countly on app-launch with anonymous tracking and changing the application, the data is being sent to the Countly side after acquiring a customer identifier.

For more information about the subject and pros/cons of each option, please refer to Tracking Users in Countly article and the documentation of your SDKs of choice for implementation details.

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:

1. Default. These properties 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.
   
   
2. Reserved. These properties are not set by default, but they have a reserved place in the User Profiles detail screen such as name, organization, gender, age. You can optionally set them using the API and/or SDKs.
    
3. Custom. 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 default, reserved and custom 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.

User properties play a crucial role in defining and detailing your user profiles, thus the foundation of the entire dataset you have in Countly. Apart from enhancing your segmentation abilities across various reports, user properties play an important role in various other cases such as personalizing push notifications and creating conditional remote configuration variables.

Events in Countly

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.

Voice of the Customer / Collecting feedback

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.

It is extremely important to be able to explore customer choices and feedback as part of their journey inside your application, putting the voice of the customer into context. 

• Which customer paths lead to low NPS and ratings? 
• What are the survey choices of a particular customer cohort? 

Are two example questions you can only answer when you have the power of analytics data by your side, and this is exactly why Countly has these VoC capabilities.

Countly treats VoC data as a first-class citizen, where we give you the ability to use it in Cohorts, Funnels, Drill and most importantly, as part of the event timeline in the User Profiles. Everything you can do with session or event data is possible with VoC data as well.  Furthermore, VoC data becomes usable in Remote Configuration, A/B Testing and Push Notifications which you can read more about in the Voice of the Right Customer section.