Views and user properties are supplementary data types that complement events. Together, they show where your users are in your application and what state they are in.
Views
Views show the visual journey of your users, along with metrics such as the time spent on a view, landings, exits, and bounces. Most SDKs can track views automatically, but because of platform limitations and the wide variety of application interfaces, we recommend that you decide what a view means for your application and track views manually.
The main pages that users reach through navigation are good candidates for views. Starting a view as soon as the user opens a new page tells you where the user is. For single-page applications or long scrolling pages, you might start new views as the user scrolls to the parts you consider significant.
A "one view at a time" approach is easy to implement and saves you many headaches. If your application spreads across multiple screens, recording multiple views at the same time is also possible with the SDKs that support it.
To see how views appear in Countly and how to implement them, see:
User Properties
As people use your application, they gain new permissions, qualities, or properties. A free user can become a paying power user, a long-time user can collect a large number of bookmarks, or a user can add a new tool to their setup. To capture this kind of state, Countly offers user properties.
User properties describe who a user is and what properties they have right now. Open a profile to see them in its properties panel: the predefined properties under General, and the properties you send yourself under Custom properties.
Predefined user properties include name and email address, and you can send any custom user properties you need on top of them. Keep custom properties to a minimum: by default, each profile can hold up to 20 custom properties, and a new custom property beyond that limit is not stored. Your server administrator can raise the limit, but a higher limit can cost performance.
Choose custom properties that do not change often. A "wireless connection state" can change many times a day, so it is better tracked as segmentation on an event. A "membership tier", on the other hand, is a great candidate for a user property.
To learn what you can do with user properties in Countly and how to track them with the SDK, see: