Countly SDKs do not track your users by default and should be set up to track automatically, manually or both. Selecting which data to track and how can influence the amount of detail and clarity you can get with Countly.
SDKs that are designed to work in specific platforms (like in browsers, Android or iOS applications) utilize tools offered by those platforms to collect data automatically. This type of tracking is useful in scenarios where you do not have man power to dedicate for a custom implementation or when depending on the feature its auto tracking logic already fits to your definition.
Common auto tracking options are:
Sessions
Recommended in most cases
Designed for short to medium app usage
Views
By default collects activity names or URLs
Needs customization to become human readable
Crashes / Errors
Collects uncaught exceptions
Might conflict with other error reporting tools
Does not indicate a crash directly
Clicks/Scrolls (web only)
Only used in Heatmaps
Form Submissions (web only)
Collects data under formSubmit event
Excludes passwords and hidden data
Link Clicks (web only)
Collects data under linkClick event
Reports text, ID and URL
Device Properties / Metrics
Works together with sessions
You would get the most out of Countly with custom events that you specifically record for your application manually. Automatic tracking can never replace manual design and integration of events specifically tailored for your project. If you are using an SDK designed for multiple platforms (like C++) or do not want to be swarmed by data gathered from automatic tracking manually deciding and implementing which events to record will benefit you the most.
With a manual tracking strategy you can achieve everything you can achieve from the automatic tracking and much more. Automatic tracking gathers rough data with a one-size-fits-all approach. For anything above that you will need to capture and report your data manually using the SDK or through direct API calls.