User Profiles helps you collect and analyze customer information, and get insights about each and every specific user, including identifying users, their devices, the event timeline, and application crash information. As Countly ensures that 100% data ownership remains with the application that the users subscribe to and asks users for permission to track, this data collection remains within the purview of GDPR and other privacy laws.

If your Countly dashboard app will be "Web", you will see the section name as "Visitor Profiles", otherwise you will see it as "User Profiles".

Benefits of User Profiles

This data helps product managers and marketers understand the application usage information and corresponding sessions. This can then be used to analyze the demographic view of your customers and understand their behaviors.

With User Profiles, among other things, it is possible to understand:

• When and where a user has logged in
• Which Events a user has generated during a specific Session
• User timeline (total Sessions and total Events per day)
• What the user did during each Session

User Profiles also gives you a location to centralize data reported from several other Countly features, allowing you to deep-dive into the customer journey of a particular user.

Information Collected from Users

This is a list of data that you can collect from users:

• User name and surname
• City and country
• First and last seen time
• Device information
• App information
• Browser information
• Source channel
• Engagement level
• E-mail
• Organization name
• Gender
• Age
• Total Sessions
• Total time spent
• Last purchase date/time
• Last purchase amount
• Total purchase count and amount
• Any custom key values

Getting Started

To start using the User Profiles feature, you need to undertake the below steps:

1. Set up the SDK that sends user data to Countly. You can find the information on how to deploy User Profiles in each SDK here.
2. In most cases, the User Profiles feature is enabled by default in Countly Enterprise. If not, enable it through the following steps: in the Sidebar, go to Management > Feature Management, and enable the User Profiles feature toggle. Note that User Profiles can be enriched by enabling other features, such as Feedback features, A/B Testing, Funnels, Cohorts, Compliance Hub (Consent), and Crashes.
3. In addition, upon enabling the feature, you will be able to manage its settings, including the addition of Notes, by going to the Sidebar > Management > Settings > User Profiles.

User Profiles Overview

This view is divided into two tabs: User Profiles and Profile Groups. To know more about profile groups, you can visit the user guide of Profile Groups.

Understanding User Profiles

User Profiles contains information that is either collected by you, or that is collected automatically by the Countly SDK.

A server with this feature always shows all the basic user information, regardless of whether the SDK sends extra custom data or not. Therefore, if you have User Profiles, you can easily send custom attributes related to that user, whenever that may be needed or required.

This is the general lifecycle of collecting and analyzing user data:

1. First, you collect user information and send it to Countly servers.
2. This information is sent via the Countly SDK or the User Profiles API.
3. Data is collected and visualized on the User Profiles View.

User properties can be anything you would like to collect, such as user photo, name, surname, phone numbers, gender, age, campaigns, or information which may be tied to the user or device, as well as custom data like address or hobbies. This page also has an event timeline showing what a user has done historically in each session. Additionally, funnels inside User Profiles show whether a specific funnel is passed by this user or not.

As a result, it's possible to understand user sessions, in-app purchase information, last purchase amount/time, as well as user-specific information. Moreover, once defined, it's possible to understand whether a user passed a specific funnel or not.

Types of Users

Users are grouped into two categories:

• Identified user: By default, when implementing the Countly SDK, Countly will generate a random value (called device_id) to identify the user, or use some platform-specific value, for example, IDFV for iOS and Advertising ID for Android.
• Anonymous user: By default, Countly generates an anonymous identifier to uniquely identify a device or browser. For example, the Total Users metric for a given period is based on the unique number of device IDs from which the Countly Server receives requests. Similarly, the User Profiles View contains a list of unique and anonymous devices from which the Countly Server is receiving data. All data originating from a single device, including sessions, events, views, crashes, is grouped under these individual profiles since all the data is tagged with the originating device ID.

Types of IDs

A User ID, also often referenced to as “Device ID” or “ID”, is used to identify a user on that particular device that is sent from the SDK.

A UID is the internal ID Countly uses to match a user to their actions, and it is also a shorter ID, which is a better method for several query types.

Both (device/user) ID, UID are visible on each user profile. For example, an ID appears as: c8711040-7402-4739-bebc-21se13421e0d; whereas a UID appears as: #78e62.

Additionally, MongoDB assigns each user a unique Visitor ID, which in Countly is reflected as the username. Whenever there is no username available for display, as provided directly by the user, this Visitor ID will also be visible on the respective User Profiles.

Modifying and Setting User Values

Apart from simply setting key/value pairs, Countly also utilizes MongoDB operations to provide a way to modify values on the server.

Here are some of the actions you may perform with custom user data:

Increase/decrease a value:

"key2":{"$inc":2}

Assign multiple values:

"key3":{"$mul":2}

Store minimal value between current and provided:

"key4":{"$max":10}

Store maximal value between current and provided:

"key5":{"$min":10}

Set initial value when it does not exist (do not confuse with $setOnInsert which works only on document creation):

"key6":{"$setOnce":"initial value"}

Push one or more values into the array:

//add one value to array
"key7":{"$push":"value"},

//add multiple values to array
"key8":{"$push":["value1","value2"]},

Push one or more unique values into the array:

//add value to array, if it is already in array, it won't add it
"key9":{"$addToSet":"value"},

//add values to array, if values is already in array, it won't add them
"key10":{"$addToSet":["value1","value2"]},

Remove one or more values from the array:

//remove one value from array
"key11":{"$pull":"value"},
//remove multiple values from array
"key12":{"$pull":["value1","value2"]},

Delete property:

//delete property
"key13":""

You can find more information about modifying custom user data in our SDK endpoint specification.

Note that the maximum number of custom properties is 20 by default. This may be changed in Management > Settings > Drill:

Sending User Profiles Data

User properties data are not bound by a session or specific event, so they can be sent whenever the developer of an application wants to send them via SDK. The Countly Server will receive user profile information and store them as app_user properties, with all other information we know about the user.

What changes is that all events and sessions that come after you set those properties, on a granular level, will contain those properties too, such as historical data, like a snapshot of user information.

Let's take a simple example - location: One of the possible user properties could be location. You set a user property to location = France, then the user has eventA and eventB, and then you change location to Germany and the user again has eventA and eventB. Afterward, inside the data collected, you will be able to distinguish between eventA and eventB made in France and eventA and eventB made in Germany, as this property - location - would be stored with each separate occurrence of all events.

Note that user properties do not increase data point count.

Each official SDK includes information on how to send user profile-related data to the Countly server. Click on this link for the iOS example, and this link for the Android example.

Updating the SDK to Send Profile Information

You need to use Enterprise Edition on the server-side and the latest SDK version. The User Profiles feature is not available in the Community Edition server. Any user profile-related information from the SDK sent to a Community Edition will be ignored.

Using User Profiles

Default View

Upon accessing User Profiles, the first View contains a table listing all users, which can be filtered further using customized queries. When clicking on each line of the table, you can access the individualized user profiles.

This initial View contains:

1. This view represents the number of total users and identified users.
2. Filtering options. Allows to either create new queries to filter the applicable User Profiles or to load a filter previously saved.
3. This stores the filtering option you selected, so that you can run it when you want to fetch the same data.
4. User type drop-down selector. 
5. User table.
6. Table controls. Allow customizing the table, adding up to 8 columns (note that Name is enabled by default as it is a mandatory field); exporting it; and searching within the content of the table. Below the table, you can select and navigate through the number of results.
7. Button to Send message to users (requires enabling Push Notifications).
8. This keeps track of all the filters that you have run in the user profiles enlisted.
9. You can select all the profiles you want to add to your desired profile group by selecting the checkbox and clicking on Add to Profile Group.
10. You can delete the user profiles selected in bulk, by clicking on Purge User Data. This operation is available only for the users who have the respective permissions. 

By default, this table shows information regarding the user’s names and surnames, devices, total sessions, last seen, and total time spent. Click on a specific column title to sort the table by that feature.

If you would like to see specific information about a user, click on that user's name. This will open another View where you will find detailed information about that user.

Searchable Fields

You can search on this page by clicking using the search bar. You may only search by using the user's information contained in the Name/Device ID and Email columns.

Filtering rules - User Profile Segmentation

In the following page, you will find:

1. Query Name - Set by default to when this new query is being done. It can be edited when you save it.
2. Load - It shows the saved queries.
3. Segmentation builder- Property - Select a filter that will segment your data based on User Properties (e.g., First Seen, City, Device, Platform, or Name), Custom Properties (e.g., Facebook Login, Twitter name, Has Apple Watch OS, etc.), or Campaign Properties (e.g., Campaign Name), as well as any other custom properties you might have set. Segmentation is selected by default, but you may use the toggle button to disable it. 
4. Breakdown selector - Depending on the selected data type, different filter categories are listed: event properties, crash segments, view segments, feedback segments, etc. The breakdown is selected by default, but you may use the toggle button to disable it. 
5. Send push notification - Opens a drawer to send a One-time Push Notification to all users segmented by the query. The button is only available in applications for mobile devices - i.e., if your application is not mobile, the button will not be clickable.

Creating a Query

When you create a query, the possible segmentations for the incoming data will depend on the properties being sent along with the event or session. Depending on the breakdown applied, you will also have different graphic outputs, such as time series, pie charts, bar charts, or stacked bar charts.

As you construct a query by adding more properties using the corresponding operators and filtering them with AND or OR filters, you can get deeper into your data. Sometimes, simple queries are enough to answer particular product questions. But if you need to add more layers of complexity or clearly understand how your application gets used under particular scenarios, or identify highly-segmented user groups, you can keep adding properties.

A Simple Query

This is a great way to see a high-level overview of how things are going and performing single-level segmentations on our data. 

Say that in your gaming app, you would like to identify users still using older versions of your application.

Basing your query on Sessions, simply set the segmentation to filter out your latest version.

The resulting output will include the primary metrics for the total occurrences and provide the tabular results, as shown below.

Now, if you want to break down these total numbers by a particular property, such as the country where these older versions of your app are used, just add the Breakdown by Platform in which the application is used, and re-execute the query, as shown below. You can save and load the saved queries using the SAVE and LOAD buttons.

Adding Multiple Segmentations

Now, let's extend our query and add conditions to understand more about these users accessing the older versions.

For instance, if you want to determine how valuable these users are, you can factor into the query if the users are highly experienced in the game or if retained within the last 6 months, and that they have had at least 3 sessions in your chosen time range.

And, then you can select to visualize the results as a stacked bar chart.

Adding Multiple Breakdowns

Using multiple breakdowns for segmenting allows you to generate a Cartesian projection for the values of mainly defined properties. This is typically helpful when you need to analyze the correlation between the values of specific properties. For instance, you can easily detect frequently co-occurring values (e.g., event count, user count) of two properties (e.g., Device, App version).

Let's say we want to know the number of session occurrences grouped by Device and App Version pairs:

According to the table, our event has occurred significantly more for (Device A, Version 3.2) pair. We can thus infer that there is something special about the pair, which is possibly an essential insight for our app. 

When you run multiple segmentations, you can select up to 3 properties for your queries to be used as breakdowns. Visualizing this multiple-segmented data is similar to individual segmentation, as you can still use 3 basic chart types (line, pie, and bar chart) to graph the query results. There is only a nuance for segment names: 

• 1 Breakdown (Platform): Android, iOS, Mac, Windows
• 2 Breakdowns (Platform, App Version): (Android | 2.3), (Android | 2.0), (iOS | 2.3), (iOS | 2.0), etc.
• 3 Breakdowns (Platform, App Version, Platform Version): (Android | 2.3 | 1.0), (Android | 2.0 | 1.0), (Android | 2.3 | 2.0), (Android | 2.0 | 2.0), etc.

So, let's see this in action. Show Sessions which App Version is not the latest, broken down by App Version and Platform.

The result can be seen as follows:

 

It is important to note that the number of segment pairs (or triples) can be large, mainly when many different values exist for each field. In those cases, the results table could be a faster way of seeing all data.

You can list the users in each segment by Clicking the View Users: 

 

 Once you view the users in a segment, you can view the other users, simply by selecting the target segment on the drop-down list: 

 

Request Queries

In some cases, queries become so big that it would not be possible to query them easily and encode queries in the URL hash. In such cases, we involve the Countly server-side to generate queries for us and use its results. This is mostly used in Drill and Funnels, where the user list can generate large lists of User IDs (UIDs) to query.

For this purpose, we use the namespace /users/request and provide request parameters as JSON-encoded strings.

Obviously, a request is only made to the same current Countly server’s /o endpoint. However, it gives full control of passed parameters, meaning a request may theoretically be made to other applications as well. For example, in the case where a client has multiple apps used by the same identifiable users through their internal company ID or something similar. This way you could create a plugin that allows querying users in other apps and matches them to users in the existing app by their very same ID.

Example:

// this 1-liner has been wrapped for better a better view

/users/request/{"api_key":"388531348bdc55c08263296509e5223b"
,"app_id":"591d50302a0a890d59fe8599","method":"funnel"
,"funnel":"47533d96a55b5132b156a915b77afafe","filter":"{}","period":"30days","users_for_step":1}

Individual User Profiles

When you access profiles from the table in the User Profiles default View, you get to see all the information aggregated for an individual user.

This View is divided into two main parts:

• The left panel covers the user property-based data, including the User summary (1), properties and notes (2) that apply to this individual user.

• The right panel covers session- and event-based data, grouped into tabs (3). Note that the tab list can be expanded, as User Profiles display data obtained through other Countly features, such as Feedback features, A/B Testing, Funnels, Cohorts, Compliance Hub (Consent), and Crashes.

User Summary

The User Summary box covers the following information known about the user:

User Full Name or Username

If the name and surname are unknown - most likely because the user is anonymous - Countly will display the User ID or Device ID. However, note that this depends on your implementation.

User Picture

If a picture has not been provided, Countly attempts to load one from the Gravatar service, assuming an email address has been provided, or generate an avatar for the user’s initials, assuming a name has been provided.

Geolocations: Location and Country

By default, Countly automatically determines user location from IP addresses using the free Maxmind GeoIP database. In the event that your application has permission to use location services, you may also set the user coordinates to the SDK that would substantially increase accuracy. Alternatively, you may supply your own city and country in the SDK, assuming you know them.

Countly’s Enterprise Edition also allows sending push notifications to groups of users located in a specific region. You will have to set coordinates in the SDK in order to do so.

The algorithm may seem complicated, so we created a few tables to help you, depending of the version of Countly.

Fallback priority is as shown in the table: SDK data first, then geocoder, then GeoIP. The SDK can disable location services and override any part of location-related data.

When a user explicitly disables location services for your app, you should call the corresponding SDK method as well to respect that user's privacy. Otherwise, Countly will continue to collect and store the location data of this user during each session based on GeoIP services.

Engagement Score

The engagement gauge shows how loyal the user is by computing how much they have returned to the application. It is color-coded on a scale from Very Low (in red) to Very High (in green).

The engagement score calculated as follows:

• Score1: Average session duration in minutes; 1 point per minute, up to 2 points as a maximum.
• Score2: Amount of sessions in last week; 1 point per session, up to 20 points as a maximum.
• Score3: How many days did the user use the app in the last 7 days; 1 point for each day, up to 7 points as a maximum.

The multiplication of these 3 scores shows your user engagement score result. The maximum result is 280 points or 100% engagement.

Last Seen

The last time the user has used your app. This is also displayed as one of the metrics in the Activity tab.

On expanding the three-dot ellipsis button, you will get the following screen:

Downloading debug Information

You can download debug data, related to a specific user profile for troubleshooting any issue related to the user profile. To download the debug data, click on the three dot ellipsis menu, and select download debug information. Once the download debug information is clicked a JSON file containing the debug information will be generated.

Export user’s data

Using this option, you can export a particular user’s data which is comprised of data related to all the user properties and analytics tabs related to each user for further analysis.

Purge user’s data completely

You can delete the data you have recently exported or completely remove any user’s data.

Enable Incoming data logs

Enabling the incoming data logs toggle lets you record incoming SDK requests for that user, even in cases where request logging is deactivated due to a high volume of requests.

User Properties and Notes

Tabs

Tabs group event- and session-based user data linked to the individual user. By default, all profiles have an Activity tab. However, more tabs will be enabled as more Countly features get deployed.

All in all, the possible tabs are the following:

• Activty
• Performance
• Feedback
• A/B Testing
• Consents
• Cohorts
• Funnels
• Crashes

Note that the order of the tabs will vary depending on when each feature was enabled in Countly, except for Activity, which is the default tab for any user profile.

Let's see more about each tab:

Activity Tab

Data in this tab are grouped into the following panels:

User Stats

This collapsible section displays a summary of the user's activity in your application, and contains:

• First session: time of the user's first session ever.
• First seen: time of the user's first-ever session or event. If this data is either missing, different than the first session data, or empty in an exported User Profile file, it means that you may be sending event data to this user's profile via the API, but the user does not have any proper session.
• Last session: time of the user's last ever started session.
• Last seen: time of the last ever known action (both event or session) inside the application. 
• Last data sync: time of the last API request received by the server.
• Total sessions: total count of unique sessions by this user.
• Total time spent: aggregated data for the time the user has spent inside the application, shown in days, hours, minutes, and seconds.
• Last purchase amount: amount of the purchase when the last Purchase Event was completed.
• Last purchase time: time when the last ever Purchase Event was completed.
• Total purchase amount: total amount for all purchase events completed.

Timeline

This graph displays the number of the user's sessions and events in the selected time period. You can enable/disable either of the metrics using the boxes below the graph.

Session History

This session history keeps a record of all the sessions of that user, giving information about the session date, time, and duration.

When you select a session entry in the Session History table, the corresponding session events will be shown in this Event Timeline table below. If a crash occurs, this crash information is also shown here, in addition to events.

Cohorts Tab

User Profiles shows you the list of cohorts to which this particular user belongs too. In the list, you can click on the name of each cohort, which hyperlinks directly to the details as set in the Cohorts feature.

You can find more information about the Cohorts feature here.

Funnels Tab

User Profiles gives you detailed information regarding whether a user has passed a specific funnel or not. Previously, you should have defined this funnel in order to see it appear here. Each funnel has a percentage that tracks the overall progress, but you can additionally inspect the details of this user's step progression using the arrow on the left of each entry. You can also review the entire funnel by clicking on the funnel's name.

You can find more information about the Funnels feature here.

A/B Testing Tab

User Profiles shows if the user has been part of a test via the A/B Testing feature. Note that in the Variant column you will see in which group was this user, including the control group or any of the variants you created for the experiment.

You can find more information about the A/B Testing feature here.

Crashes Tab

This tab shows whenever a user suffers fatal and non-fatal crashes or errors that are still unresolved. Clicking on the error/crash name will lead you to its specific details within the Crashes/Errors feature.

You can find more information about the Crashes and Errors feature here.

Consent Tab

User Profiles show you the activity this user had in relation to their consents while in your application. Remember that a user can either opt-in or opt-out of one, several, or all features of your app and that each of those changes must be recorded.

You can find more information about user consents and the Compliance Hub feature here.

Performance Tab

You can find more information about the Application Performance Management feature here.

Feedback Tab

You can find more information about the Feedback feature set in the Surveys, NPS, and Ratings User Guides. Please note, these user guides are for Countly 20.11, and most functionalities are the same. We will upload the User Guide for the new Feedback feature set UI in the coming days.

FAQ

What is the difference between a User ID and a UID? 

In Countly, you will see both User ID (sometimes found as "Device ID") and UID. User ID / Device ID refer to the particular device or user as identified by the SDK, while a UID is an internal way in Countly for the User Profiles feature to identify the user.

From a visual perspective, you will note that a User ID / Device ID is long, while a UID is much shorter. For more information, click here.