Nexly is designed to provide useful product analytics while limiting unnecessary data collection. It does not use customer analytics data for advertising or sell it to third parties.
The current SDK uses pseudonymous identifiers. It should not be described as fully anonymous analytics.
Visitor and session identifiers
- Web SDK: a random visitor UUID is stored in localStorage for the property origin.
- React Native SDK: the same type of identifier is stored in AsyncStorage when available.
- A session UUID groups activity and is renewed after 30 minutes of inactivity.
- The visitor identifier can recognize a returning browser across sessions. It does not directly contain a name or email, but it is pseudonymous data.
- The Node SDK does not create visitor or session identifiers unless a customer supplies them.
Privacy mode
Customers can initialize the SDK with privacy mode enabled. In this mode the SDK does not read or write localStorage, AsyncStorage, or any other device storage for its identifiers, and events are sent without a client-side visitor or session identifier.
For privacy-mode events the ingest service derives a short-lived pseudonymous visit fingerprint from the request IP address and User-Agent using a keyed hash. The fingerprint changes every 24 hours, the inputs are not stored, and yesterday's fingerprints cannot be recomputed. As a result the same device cannot be recognized across days.
Privacy mode still processes IP addresses and User-Agent values transiently, so it is pseudonymous — not fully anonymous — analytics. Whether it removes notice or consent obligations depends on the laws applicable to the customer's visitors.
Customers can also supply their own visitor or session identifiers in privacy mode; those identifiers are then governed by the customer's own lawful basis and notices.
Data sent by the SDK
| Category | Examples |
|---|---|
| Navigation | URL, sanitized path, referrer, landing page, outbound and download destinations |
| Device and software | Browser, operating system, device type, screen size, language, timezone |
| Engagement | Pageviews, active time, scroll depth, clicks, input focus, session lifecycle |
| Attribution | UTM parameters and common campaign identifiers |
| Custom data | Customer-defined event names and approved scalar string, number, or boolean properties |
| React Native | Platform, OS version, screen metrics, locale, timezone, and device category |
IP address, location, and User-Agent
The ingest service receives an IP address as part of the network request. It uses the address transiently for country, region, and city lookup, network and bot classification, rate limiting, and customer-configured IP filters.
Raw IP addresses are not written to the Nexly analytics database. Infrastructure providers may still process network addresses in operational or security logs under their own policies.
The HTTP User-Agent is processed for browser, operating system, device, and bot detection. A User-Agent value is stored with session records. Nexly does not collect precise latitude or longitude.
Automatic and custom events
Customers can enable automatic pageview and engagement collection. Click events may include an element tag and up to 80 characters of visible link text. Outbound, mail, telephone, and download interactions may contain their destination.
Customers control custom event names and properties through a per-property registry. Nexly accepts scalar custom values, but a customer could still submit personal data. Customers must avoid sensitive information and ensure their collection is lawful.
Nexly redacts common sensitive query parameters such as password, token, email, code, and JWT before storing supported URLs, but customers should not rely on redaction as a substitute for safe URL design.
Storage and retention
| Data | Current retention behavior |
|---|---|
| Raw events | Automatic database TTL of 24 months |
| Hourly and daily analytics rollups | Automatic database TTL of 60 months |
| Session records | No automatic TTL is currently configured |
| Event queue and operational logs | Operational retention is not represented as a customer-facing guarantee |
Property deletion and privacy requests
Deleting a property in the dashboard is currently a soft deletion. It stops ingestion and removes access through the product, but does not immediately purge the underlying analytics storage.
Customers can request a manual account or analytics deletion by emailing mail@nexly.to. Requests may require verification and coordination to identify the relevant property and pseudonymous identifiers.
Verified deletion requests are completed within 30 days: the relevant data is deleted or de-identified in active systems. Residual copies may persist in backups for a limited period before being cycled out.
Customer responsibilities
- Tell visitors about Nexly and the categories of data collected.
- Choose and document an appropriate lawful basis.
- Obtain consent before using device storage where applicable law requires it.
- Do not place personal or sensitive data in URLs, link text, event names, or custom properties without a valid reason.
- Respond to visitor requests and provide Nexly with the information needed to assist.
Questions
Questions about analytics collection or deletion can be sent to mail@nexly.to.
Last updated: July 10, 2026