Country & IP address

Country data

Country tracking is enabled by default for all customers. Either via Server-Timing information (Shopify is amongst the platforms that will expose such information via country in their Server-Timing response header) or otherwise AWS services.

Country via AWS services

RUMvision uses CloudFront Geolocation Headers. As beacons are coming in, the IP address is seen at the network edge only long enough for AWS to determine the Country ISO code. The IP address is then discarded at the edge. The only geographical data that enters RUMvision's Elastic database is the anonymized ISO Country Code (e.g., "DE" or "FR").

No other (sub)processors then the one already used are involved.

IP-address

Although IP addresses don't end up in RUMvision's Elastic database, IP addresses are temporarily processed. The chapters below elaborate on this.

Logging of end-user IP addresses

End-user IP addresses are not logged, stored, or processed within the RUMvision application or its database. RUMvision operates on a "Zero-Log" infrastructure for standard traffic.
The only technical exception is within our AWS WAF (Web Application Firewall), which will temporarily "sample" web requests (accompanied with their source IP addresses) [1] to JavaScript files under strictly defined security conditions.

However, this happens only for traffic that:

  • triggers global threat protection rules (e.g., bot detection or DDoS mitigation)
  • or during diagnostic sessions specifically requested by a client to investigate data anomalies. In these cases, logging is narrowly scoped to that specific domain and is used only to identify and filter suspected automated (bot/malicious) traffic.

Purpose, Retention, and Access

  • Purpose:
    The sole purpose of the above is Network and Information Security (ensuring the system can resist malicious or accidental events, as recognized by GDPR Recital 49).
  • Retention:
    These records are highly ephemeral. AWS WAF provides a rolling window of sampled data for the last 3 hours only [1]. After this period, the samples are automatically purged by AWS and are not recoverable.
  • Access:
    This temporary security metadata is only accessible to RUMvision’s senior infrastructure engineers for immediate troubleshooting. It is never shared with the CDN provider beyond the standard automated processing required to deliver the script, nor is it ever integrated into the RUMvision analytics interface.

[1] Continue reading on AWS data sampling and data retention period at this specific AWS docs article.

The above (1 & 2) is easily mitigated by self-hosting the JavaScript file. Please read security trade-offs carefully.

IP handling during data transmission

When the browser sends the performance data (the "beacon"), it initiates a standard HTTPS request to your AWS endpoint. At this exact moment, the IP address is technically visible to the entry point (CloudFront) to facilitate the encrypted connection. This is a fundamental requirement of the TCP/IP protocol.

The IP address is only visible at the network layer during the HTTPS handshake. It is never persisted to any log file or database. Our application consumes only the anonymized geolocation headers provided by AWS at the edge. See "Country via AWS services" chapter above.

Immediate anonymization or truncation

This means that RUMvision architecture is designed to avoid IP persistence entirely.

Deployment without prior consent

The above means that RUMvision tracking script can be deployed without prior user consent under the following legal reasoning, but only when site owners configure their tracking snippet to not use localStorage nor sessionStorage:

  • ePrivacy Directive Exemption:
    Since RUMvision optionally does not use cookies, localStorage, or any other method of "storing or accessing information" on the user's terminal device, it does not trigger the consent requirements of the ePrivacy Directive (the "Cookie Law").
  • GDPR Legitimate Interest:
    The limited processing of technical signals (performance metrics) is performed under Article 6(1)(f) (Legitimate Interest). Because the data is immediately anonymized (IP discarded) and used strictly for technical audience measurement and performance optimization, it meets the "balancing test" — the privacy impact on the user is negligible, while the publisher has a legitimate interest in ensuring their website functions correctly.
  • CNIL/EU & German (TDDDG) Precedent:
    Our configuration aligns with the 'strictly necessary' exemptions and legitimate interest frameworks recognized across the EU:
    • France (CNIL): We comply with the criteria for audience measurement exemptions by avoiding cross-site tracking and persistent identifiers.
    • Germany (TDDDG/GDPR): Our approach respects the German 'Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz' (TDDDG). Since we do not store or access any information on the end-user’s device (no cookies/local storage), we do not trigger the consent requirement under Section 25(1) TDDDG. Furthermore, our immediate anonymization of IP addresses ensures that the processing of performance data remains within the 'Legitimate Interest' (Art. 6(1)(f) GDPR) of the website operator to ensure a functional and performant user experience.

Self-hosting

Infrastructure logging can be mitigated by self-hosting the RUMvision JavaScript file. By serving the script from your own first-party domain, RUMvision’s infrastructure never sees the initial request for the script, ensuring zero IP exposure during script fetch.

Security trade-offs

Please be aware of security trade-offs when self-hosting the JavaScript file. If you choose to self-host, RUMvision will be unable to apply global threat protection or diagnostic WAF rules to that traffic. Consequently, RUMvision engineers would be unable to identify, filter, or prevent automated (bot/malicious) traffic from appearing in your performance data, as that security perimeter would now be under your internal management.

Table of Contents