Data Collected by RumDash

This page documents exactly what data the RumDash client library collects from your website's visitors, what our servers add to it, and the controls you have over collection. It is intended for security and privacy reviewers evaluating RumDash. For API-level details of the client library, see the client JavaScript documentation.

Data sent by the client library

The RumDash script collects performance telemetry, not user behavior profiles. Each page navigation produces a JSON payload containing the fields below, sent to RumDash's ingestion API over HTTPS. A single navigation may produce more than one beacon (for example, when a metric finalizes after the initial send), and later beacons carry the same per-navigation identifier so the server can reconcile them.

Category	Fields
Page & navigation	Page URL (including query string and fragment), referrer URL, navigation timestamp, navigation type, a per-navigation `id` (a randomly generated UUID that correlates beacons from the same navigation and identifies nothing else), and the optional `pageType` label you configure. Email addresses appearing in query parameter values of the page URL, the referrer URL, or the URL of a client-side navigation in a single-page application, whether plain or percent-encoded, are redacted by the client at capture time, before the payload leaves the browser.
Session	A `rum_session_id`: a randomly generated UUID stored in your site's `localStorage` under the key `__rdSessId`, paired with a `__rdSessTimestamp` key holding the time of last activity, which expires the session after 30 minutes of inactivity. Both keys are written only once an `init()` call resolves to enabled, so a page that loads the script without initializing it, or that initializes with reporting off, stores nothing. The UUID is scoped to your site, is not a cross-site identifier, and contains no user information. A boolean marks whether a navigation is the first of its session.
Device & environment	Viewport width and height, device pixel ratio, effective connection type (e.g. `4g`), and logical CPU core count. The viewport is recorded once per navigation: when the RumDash script runs for the page load (at consent time if the script is deferred until then), when the page is restored from the back/forward cache, and when the app routes for a soft navigation. If the window reports no size at that moment, as an embedded WebView can before its first layout, the size at send is used instead. Each metric's attribution records the viewport again at the moment that metric fires, so a rotation or resize between the two shows up as different values. The browser's User-Agent string is not part of the JSON payload; the server reads it from the ingestion request's headers and parses it into browser, OS, and device family.
Performance metrics	Core Web Vitals (TTFB, FCP, LCP, CLS, INP). LCP, CLS, and INP additionally carry attribution data for debugging: CSS selectors and tag names of the elements involved, the visible text content of attributed elements (with email addresses and digits redacted, as described below), URLs of contributing resources (images, videos, scripts, stylesheets; only the first 100 characters of an inlined `data:` URI) with their load timings (start, request start, service worker start, duration), transfer and body sizes, script function names and timings from Long Animation Frames, element geometry (bounding rectangles, scroll positions), and for LCP the timestamp, tag name, and resource URL of each candidate element the browser considered before settling on the final one.
Configuration	Your website API key (transmitted in the request URL's query string rather than the JSON body), optional environment label (e.g. `prod`), optional revision identifier, and the RumDash library version.
Error telemetry	If the RumDash library itself throws an error, the error message and stack trace are reported so we can fix the library. These reports stop with everything else once reporting is off: a page that initializes with `enabled: false` or that calls `disable()` sends none. That opt-out is applied before any other configuration is read, so a failure while the library is starting up cannot outrun it. The report reaches our internal error tracker alongside standard HTTP request metadata (such as the Referer and User-Agent headers); it never includes page content, form data, or user identifiers.

What RumDash does not collect

No cookies. RumDash sets no cookies of any kind. Session continuity uses localStorage only.
No session replay. RumDash does not record screens, DOM mutations, or mouse movement.
No form input or keystrokes. The script never reads form field values, keystrokes, or clipboard contents, including on checkout and payment pages.
No cross-site tracking or advertising identifiers. The session UUID is random, site-scoped, and short-lived.
No user accounts or identity. RumDash has no concept of your end users' identities and provides no API for attaching them.

One nuance worth flagging for reviewers: Core Web Vitals attribution includes the visible text of the specific element that produced a metric (for example, the headline that was the Largest Contentful Paint). On pages that render user-specific text, that text can appear in attribution data. Two redactions narrow that exposure: email addresses in the text are replaced with [REDACTED_EMAIL], and every digit character is replaced with #, so numeric identifiers such as phone numbers, order numbers, and account numbers never leave the visitor's browser verbatim.

Both redactions happen in the client, at capture time, before the payload leaves the browser. Email redaction's scope is deliberately narrow: the visible text of attributed elements, and query parameter values in the page URL, the referrer URL, and the URLs of client-side navigations in single-page applications. Digit redaction applies to the visible text of attributed elements only; digits in URLs are not redacted.

Server-side geolocation enrichment

RumDash's ingestion API sits behind Cloudflare. At the edge, Cloudflare derives coarse geolocation from the request's IP address and forwards it as HTTP headers. From those headers RumDash stores: country, city, region code, continent, latitude, and longitude. This enrichment happens entirely server-side; the client library does not access or transmit location data itself.

IP addresses

Like any HTTP service, RumDash's servers necessarily receive the visitor's IP address in transit. We treat IP addresses as personal information under CCPA, GDPR, and similar state privacy laws, and we handle them accordingly:

IP addresses are not stored in analytics records. Only the coarse geolocation fields listed above are persisted.
IP-bearing HTTP headers (CF-Connecting-IP, True-Client-IP, X-Forwarded-For) are filtered out of our internal error reports before they leave our infrastructure.

Because the IP is momentarily processed at the edge for geolocation, we recommend customers disclose RumDash as a performance-analytics processor in their privacy policies rather than asserting that no personal information is ever processed.

Payment pages & PCI scope

RumDash never reads form input, keystrokes, or payment data, so it does not handle cardholder data on any page. If your PCI assessment calls for excluding third-party scripts from payment pages entirely, you have three options:

Omit the RumDash snippet from payment-page templates, so the script never loads there.
On a traditional multi-page site, where each route is its own page load, initialize with RumDash.init({ key, enabled: false }) on payment routes: the script loads but registers no observers, touches no browser storage, and sends no telemetry whatsoever, error reports included.
In a single-page application, where a payment route is reached by client-side navigation rather than a page load, call RumDash.disable() when you navigate onto it. init() takes effect once per page load, so a later init() call is ignored and cannot be used to turn reporting off.

Note on the third option. disable() stops reporting for the remainder of the page's lifetime and cannot be resumed later in that same page's lifetime, so a single-page application that disables on a payment route also stops reporting on whatever the visitor navigates to next, until the next full page load. Where that is too broad, omit the snippet from the payment-page template instead.

See the client JavaScript documentation for details on init() and disable().

Cookie-consent & consent-management platforms

To gate RumDash behind a consent-management platform (DataGrail, OneTrust, and similar), defer loading the RumDash <script> tag until the visitor grants consent. While the script is not loaded, nothing is collected and no browser storage is touched. Keep the __rdOnLoad definition from your installation snippet in place, and inject the script tag from your consent platform's grant callback:

<script>
  function __rdOnLoad() {
    RumDash.init({ key: "your-api-key" })
  }

  // In your consent platform's "consent granted" callback:
  function loadRumDash() {
    var script = document.createElement("script")
    script.defer = true
    script.src = "https://your-rumdash-script-url" // same src as your installation snippet
    document.head.appendChild(script)
  }
</script>

If consent is later withdrawn, call RumDash.disable() to stop reporting for the remainder of the page's lifetime.

Data retention

Raw navigation records (the per-pageview payloads described above) are deleted after 100 days.
Aggregated analytics (statistical rollups with no per-visit or per-session records) are retained for up to 3 years.
Client error reports are not stored by RumDash; they are forwarded to our error-tracking provider and are subject to that provider's retention policy.

These windows are upper bounds on how long data exists in our systems, not a guarantee of dashboard history. We periodically restructure our aggregations, and a restructured aggregate is rebuilt from the raw-data window, so the history available in a given dashboard view may be shorter than 3 years.

The windows above cover data collected from your website's visitors. Data about your RumDash account itself (operator logins, team membership, billing) is covered by our privacy policy.

Data protection

Encryption in transit

Telemetry is encrypted with TLS on every network hop, from the visitor's browser to the database:

Browser to edge. All telemetry is transmitted over HTTPS (TLS) to RumDash's ingestion API, which sits behind Cloudflare. Plain-HTTP requests to our application are redirected to HTTPS, and HTTPS is enforced via HSTS.
Edge to application. Cloudflare connects to our origin servers in Full (strict) mode: the edge-to-origin leg is itself TLS-encrypted, with the origin certificate validated on every connection.
Application to database. Connections from our application servers to the analytics database require TLS, and our database provider does not accept unencrypted connections at all. In addition, the database is locked down to an allowlist of client IPs, covering only our origin servers.

Encryption at rest

Analytics data is stored in a managed TimescaleDB service (Tiger Cloud, running on AWS), which encrypts data at rest using AES-256, covering both active databases and backups, with cryptographic keys managed by AWS Key Management Service.

Access controls

Ingestion is authenticated per-website via API key, and every request's payload is validated before it is stored.
Dashboard access is scoped by team membership with role-based permissions.
Direct network access to the analytics database is restricted to an IP allow list covering only the address ranges our application servers connect from; connections originating anywhere else are refused at the network layer, before authentication is attempted.

Questions this page doesn't answer (subprocessor agreements or a security questionnaire) can be directed to support.