How Cronitor RUM handles personal data

4 min read

Cronitor RUM helps website owners measure and understand the performance of their websites. It does so by automatically de-personalising session data and presenting it in an aggregated format. We only collect the necessary data and we do not sell data under any circumstances.

In this document, we’ll explain how Cronitor RUM handles the personal data of your end users, where the data is stored, and how you have control over it - all in simple terms.

Automatic Depersonalization

Cronitor RUM automatically depersonalizes personal data we detect when collecting it from your website. That means any information we find that can identify a specific individual, such as an IP address, name, email address, or phone number, is automatically removed or replaced with generic information.

Data Storage Location

Our main data center is securely managed by Amazon Web Services (AWS). This data center is located in Oregon, USA. You can view the full list of sub-processors in our privacy policy, including their country and purpose.

For customers with specific data processing and storage requirements, we offer a relay server which you can deploy in a data center under your control. This server becomes the first point of contact for your visitor’s data and strips out IP addresses before they even reach our servers.

No Selling of Personal Data

We have a strict policy of no selling of personal data to third parties under any circumstances. Our business is funded by charging for the product, not by hoarding vast amounts of personal data for selling or advertising purposes. That means our business model is aligned for user privacy, and we have no incentive to collect more data than necessary.

Data Ownership

You’re in complete control of your site data. You can access it anytime, configure inbound filters to block specific countries, paths, restrict data collection to specific networks, and even delete all data if you no longer wish to use the service.

Collected Data

Our analytics script is open source and collects the information listed below:

  • Timestamp
  • Event name (eg. Pageview, Error, CoreWebVital)
  • Client site key
  • Environment name (eg. production or staging)
  • Country code and city name if available
  • Effective connection speed (eg. slow-2g, 4g)
  • Page URL
  • User Agent
  • Referrer
  • UTM Parameters
  • Browser language and timezone
  • Screen width
  • Page load timings
  • Core web vital metrics
  • Error type, message, originating filename
  • User provided metrics (eg. a general purpose “value” field, commonly used to represent a cart value or item count).

Does Cronitor RUM track IP addresses or use cookies?

We do not store IP addresses as part of the visitor session data, and do not make use of tracking cookies.

However, something important to note is that every HTTP request automatically includes an Internet Protocol (IP) address in the request headers, this is how the internet works, and it’s not particular to us.

Just like any other service that takes security seriously, we do use IP addresses to prevent abuse using rate-limiting and to power many security features that protect our customer’s data. This includes temporary access logs, and active logged-in session verification. Additionally, IP addresses are used to derive anonymized data such as the visitor’s country and as part of our anonymous session tracking mechanism.

To be clear, we do not store raw IP addresses for purposes other than security or to prevent abuse, and they are not stored any longer than necessary. This data is typically deleted within minutes except for our audit logs which are automatically deleted within 14 days. We do not sell personal data to any third-party.

How does Cronitor RUM count unique sessions?

We developed a two-layer session tracking mechanism that automatically forgets about individual visitor devices, while still giving website owners useful data.

It’s different from plain browser fingerprints, because the resulting session IDs have zero personal data encoded in them. They are completely random 128-bit UUIDs, without a cookie linked to them, and they are not browser fingerprints or user hashes.

This is in part possible because the algorithm automatically destroys any link between the visitor that generated the data and the session IDs.

The reason we created this method, is because it gives everyone complete peace of mind. Even in case of an absolute disaster and we leaked the session data, you couldn’t brute any IP address, User Agent, or sensitive data out of the Session IDs. There’s no personal data encoded, or hashed into them.

Session tracking algorithm:

For transparency, below you’ll find a simplified view of our session tracking algorithm:

  1. When a new event arrives at our servers, lookup the current 256-bit cryptographically secure random salt, which rotates at least every 24 hours, and is neither logged nor persisted.
  2. Take two dimensions from the incoming event related to the visitor’s device (IP address, user agent), and one dimension related to the website (Site ID).
  3. Compute an ephemeral bridge key by generating a SHA-256 of the selected dimensions and daily salt. Keep it in-memory, and set it to expire in 30 minutes.
  4. Lookup the session ID with the bridge key in an in-memory cache. If found, extend the TTL by another 30 minutes (the session is active). Otherwise, set the session ID to a completely random 128-bit UUID.
  5. The resulting session ID now contains zero personal data, and within 30 minutes of inactivity or 24 hours, the device bridge key will be destroyed. This leaves no link between the visitor device, and the session ID.

You can find more details about our privacy and data protection practices in our privacy policy.