Countly Enterprise Edition has the ability to track every device or user. This feature offers several approaches spanning different use-cases. In this blog post, we depict those approaches, providing the pros and cons of each in detail.

Before diving into different methods, we need to understand how Countly tracks users. This process is realized through the notion of “device_id”. This ID is normally (by default) generated on the environment the Countly SDK runs on (e.g. a smartphone, a web browser, or a desktop application), and it is used to identify the user who directly interacts with the device.

But what happens if there are several users and several devices that are used interchangeably? What happens if a user can log in and log out, hence transitioning between a known and an anonymous user? In such cases, you should experiment and decide on the correct user tracking strategy before going into production so as to minimize negative effects.

Depending on the selected strategy, you can change what a user means in the Countly dashboard.

Default user tracking

By default, when implementing 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.

Generally speaking, this way assigns a unique ID to a particular user who is the owner of that device.

Pros

• This is the easiest and fastest implementation, with no additional steps, apart from undertaking the default SDK implementation, being needed.

Cons

• If multiple different users use the same device, they will be identified as a single user in the Countly dashboard and would have a single profile under User Profiles.
• If the same user uses multiple devices, each device will be identified as a separate user in the Countly dashboard; hence the same user will have separate user profiles, which is, by nature, not the case.
• Depending on the platform, if app storage is reset or the app is uninstalled and re-installed again, this user may be identified as a new user and a new user profile is created. This highly depends on how the platform behaves, and we suggest that you check this document to understand what happens in such cases.

Tracking known users

This method, as opposed to the first one, helps Countly identify and track users if they are “known” to you. It is used in cases when the default Countly generated device_id to track the same user across multiple devices or different users on the same device is not appropriate. In this case, you need to provide your own “user identifier”. This unique identifier can be a user email address or an internal customer id — or simply anything unique to that user. Countly SDK can then use this string as the device_id. From this point on, Countly will know exactly what user it is and the same device_id would be used even on different devices.

In order to accomplish that, you need to provide device_id upon SDK initialization and not afterward. This might fit applications which can identify their users right away, or have little or no actions before authenticating users.

This would be the case when the user inside the Countly dashboard directly corresponds to your customer (e.g. 1 Countly user = 1 company customer, regardless of the device/platform they use).

Pros

• Each of your customers will be exactly 1 single user inside Countly and have 1 user profile

Cons

• If you don’t know your user ID right away and would know it only after the user authenticates, you would miss all the actions that were made before authentication.

Known user with pre-tracking

To tackle the problem of missing out on data before user authentication, it is possible to launch the Countly SDK in an “offline mode”. In this case, it will track data, but will not send it, until you provide your user ID and enable “online mode”.

This way, you can initialize SDK in offline mode right when the app starts, and track everything needed; when the user finally authenticates, and you get your user’s ID, you can set it as device_id and enable online mode, so Countly SDK would start sending data. All previously collected data in offline mode will also be assigned to that user.

For the definition of the user, nothing changes - it still directly corresponds to your customer.

Pros

• Each of your customers will be exactly 1 single user inside Countly and have 1 User profile
• You will have the opportunity to be able to collect and visualize data before the user authenticates, but only after authentication.

Cons

• If your user doesn’t authenticate, you will never receive any data from this user.

Managing anonymous and known users together

It is also possible to collect data of both user states (before login and after login) and SDK provides two ways to manage that by allowing to change device_id after SDK initialization.

First, you can change device_id without merging. That will simply end session of old device_id and sync all the left data, and start a new session for new device_id. This is handy, for example, when multiple users use the same device and you want to switch them.

The second way is that you change device_id, without starting a new session, but merging both users on the server-side. So this will basically create a new user for new device_id, if it was not already created. Then merge data of the user with old device_id into this new one. And afterward, delete the user with old device_id from Countly.

This is handy when, for example, you are firstly tracking an anonymous user with Countly generated device_id, but then the user authenticates and you retrieve id for this user and change it in SDK, allowing to merge both users on the server. This means that everything that the anonymous user had, all events and properties, will now be assigned to an identified user and the old user will be deleted.

You can implement different strategies that utilize these two options.

For example, you can start tracking a user as anonymous with a Countly generated id. Then, upon authentication, change device_id to your own id by merging on server. And then when the user logs out, you can change it back to anonymous generated id without user merge.

The problem is that when the user logs out, it will create a new user inside the Countly dashboard again, and there will be 2 different user profiles: one with your provided id and the other with random id.

So the user on the Countly dashboard represents both your customer and anonymous user before authentication. And in some cases, it could be the same user, but with 2 different user profiles inside Countly.

For applications like banking, where the user must log in and log out every day, that can basically double the user count, thus skewing the data.

You can try to tweak this strategy to minimize double user creation. For example, on logout, let’s not change device_id at all and keep using your provided one. Instead, upon authentication, we check if the type of device_id is your provided, then we switch device_id without merging. But if the type of device_id is Countly generated, then we change device_id with user merging.

In such a case, the scenario would look like this:

• App starts for the first time and Countly generated id is used
• Upon authentication, you confirm that current device_id is Countly generated; it means we need to do merging when switching to your provided device_id 
• When the user logs out, we don’t do anything
• When the user logs in, we check current device_id and it is your provided one. So we switch to authenticated user’s device_id without merging. If it is the same user and the same id SDK currently has, nothing will happen. But if it is different id, then it is probable that another user logged in and SDK will stop the current session and start a new one for new user

These are just a couple of examples of how you could manage tracking data for both known users and anonymous ones. The actual implementations may differ based on your application specifics.

Pros

• You get to track data for users both before and after authentication

Cons

• In some cases, aggregated data may be skewed and may over report users and new users due to creating many anonymous users
• Merging can be quite a performance intensive process, especially if the user that is merged has a lot of data, or there are lots of users to merge
• In some cases, the same user may have a user profile for both states: known user and anonymous one
• It requires SDK integration and customization that is slightly more difficult

Other interesting strategies

We have seen our customers using their own different implementations, and one of them was quite effective, which is why we have included it here. The strategy involved dividing the onboarding (pre-authenticated users) and authenticated users into separate Countly apps.

The customer had quite a long and complicated onboarding process with the registration form. But once that was done, there was nothing else to do before the login screen. So they wanted to utilize 1 user profile per 1 customer inside the Countly dashboard. But they also wanted to track how a user onboards, how long it takes, and where they would drop off if registration was not finished.

That is why sending onboarding data to one app and then sending data of known users to the other app made perfect sense for them.

You could also leave a custom property with your user id once registration is complete, on the onboarding app, just to be able to tie the both users together. However, overall, this shows that many different interesting approaches could be taken to find what you need.

Just to note, this approach would require changing app_key in the running SDK, and currently, not all SDKs support that. You would need to consult Countly or make modifications yourself on certain SDKs.

Conclusion

There are different user tracking strategies available. Each one has its own pros and cons. You need to understand what kind of data you want to collect and what you want the word “user” to mean exactly for you in the Countly dashboard. Make sure you know the options and then you would be able to find the best way that fits you with all its trade-offs.