Visitor data

Use Topics → Visitor data to control optional visitor/browser telemetry used for Chatbot analytics. Collection is off until fields are selected.

​

Available fields

The current policy can collect selected fields including:

• IP address;
• country;
• region;
• city;
• GeoIP timezone;
• GeoIP accuracy radius;
• device class;
• browser family and major version;
• OS family and major version;
• browser language;
• browser timezone;
• viewport size class;
• landing path;
• referrer origin;
• UTM source;
• UTM medium; and
• UTM campaign.

​

Data minimization rules

The visitor-data system deliberately excludes more invasive identifiers and precision than the analytics need. The current implementation does not collect exact coordinates, browser fingerprints, ISP, street address, hardware identifiers, or raw user-agent strings as public reporting dimensions. Landing path is stored without its query string. Referrer is restricted to the HTTPS origin form.

​

IP address

Raw visitor IP, when enabled, is encrypted. It is used for controlled functions such as approximate server-side GeoIP and authorized exact lookup/export paths. It is not a public identity credential. Approximate country/region/city data must not be treated as proof of identity, authorization, fraud, or household location.

​

UTM values are allowlisted

Even when UTM fields are enabled, only exact source/medium/campaign values in the configured allowlist may be stored. Leaving a UTM allowlist empty means collect none.

​

Public disclosure

If a widget collects visitor telemetry, configure the required public disclosure text. English is the organization fallback. Add the published widget’s default locale and any additional visitor-language variants you need. Widget-specific Topics policies can have their own disclosure set.

​

Disabling a field

Disabling a telemetry field stops new collection under the applicable policy. It does not instantly erase values already retained in historical records.

​

Purge historical telemetry

Use Purge historical telemetry when you need to permanently remove retained visitor telemetry for the organization while keeping conversation transcripts and Topics insights themselves. This is a privileged destructive action. The current flow requires:

1. an audit reason of at least 10 characters; and
2. current authentication proof using the user’s password or 6-digit authenticator code.

RAUM first issues a short-lived confirmation grant, then consumes it for the purge. The confirmation is bound to the sensitive operation rather than treating an old login as indefinite permission to delete telemetry.

​

Retention

Visitor telemetry is still subject to the product’s retention/deletion lifecycle. The explicit purge exists for cases where you need to remove the telemetry independently of the rest of the conversation record. Retention & deletion → Visitor identity →