Data management tools
Govern your data before it becomes a report. Every event, session and profile enters Countly through one control layer. You decide what is collected, how it is transformed and who can see it, before it reaches a single report. Clean, consistent data from the first day.
What you can capture
From actions and context to feedback and intent, Countly captures the signals your product gives off, so analytics, engagement and AI all work from the same complete picture.
Taps, scrolls, screen views, form submissions
Time spent, navigation flow, frequency
OS, app version, region, device model
Exceptions, performance regressions, loading issues
Your product’s logic, tracked exactly as you define it
Surveys, NPS, in-app ratings
Profiles enriched with traits, preferences, activity history
User behavior across test variants
Captured from web, mobile, desktop, connected products and server-side systems, through Countly SDKs for iOS, Android, Web, Node.js, Flutter, React Native, Unity, C++, Java and Windows, plus APIs for custom ingestion.
Capabilities
Data quality is not a cleanup job afterwards. Countly gives you the tools to shape, validate and govern data as it arrives from web, mobile, desktop, connected products and server-side systems.
A single schema for events and segmentations across all apps. Approve new events, rename, merge or block them, and keep tracking plans and reality in sync.
Rewrite, derive or drop properties as data comes in. Normalize values, split or combine events, and fix SDK mistakes without a release.
Sensitive properties are masked, hashed or removed before storage. Personal data never lands in raw form unless you explicitly allow it.
Collect and enforce consent per feature category. Users who opt out of a category simply generate no data for it, on every SDK.
Attach backend signals, transactions and internal attributes to user profiles. Analytics stops being anonymous the moment you need it to be.
Keep raw events as long as you need, purge on a schedule and export anything through the API, without reprocessing.
In depth
The parts that matter when you evaluate this area seriously: what it does, how it behaves at the edges, and what your team controls.
Schema
The Data Manager is where product, engineering and analysts agree on what is tracked. New events wait for approval, naming is enforced, and the documentation is generated from the schema itself.
Ingestion
Transformation rules run on the ingestion path. A misnamed event from an old app version is corrected on arrival, a currency is normalized, a free-text field is bucketed. Reports stay consistent across releases.
Profiles
A profile is created for every device and merged when the user identifies. Backend systems add attributes and events through the API: plan, revenue, support tickets, contract dates. Every report and every campaign can then segment by them, and the profile is subject to the same consent and masking rules as the SDK data.
How it works
Countly ships more than ten SDKs and a REST API for everything else. The control layer sits between them and your reports.
Add the SDK, define the first events. Consent categories are part of the SDK from day one.
Approve events in the Data Manager, set types and descriptions, block what you do not want.
Add masking, hashing and transformation rules. Test them against live traffic.
Analytics, engagement and AI all work on the same governed data, in one product intelligence environment.
FAQ
Straight answers on how this part of Countly works in practice. For anything else, talk to us.
Yes. Renaming, merging, blocking and transforming events happens in the Data Manager and applies at ingestion, so old app versions keep producing clean data.
Wherever you decide. On Flex you choose the Google Cloud region. On Enterprise the data never leaves your infrastructure. Masking rules ensure raw PII is not stored at all unless you allow it.
Yes. The API accepts profile properties and events from any server-side system, so CRM attributes, transactions or support tickets can enrich the same profile the SDK writes to.
Consent categories are enforced in the SDK: if a user has not consented to a category, no data for that category is created or sent. The server records the consent history for audits.
