Last updated: 6 August 2026
UsageStory is used by two groups, and the rules differ for each.
Customers are the people who sign up for UsageStory and install it on their own websites and apps ("host apps"). For their account data, UsageStory is the data controller.
Visitors are the people who browse those host apps. For visitor data, the customer is the controller and UsageStory is the processor: we handle it on the customer's instructions and do not decide what it is used for. If you are a visitor asking about your data, contact the site you visited; they control it. Section 8 covers how we support them in answering you.
Installed on a host app, UsageStory records:
UsageStory does not collect precise location, does not buy or enrich data from third parties, does not build cross-site profiles, and never sells data.
UsageStory sets no cookies on host apps. The visitor and session identifiers live in the browser's local and session storage, they are random values with no meaning outside the host app, and they are scoped to that site alone, so they cannot be used to follow anyone across the web. Session storage is discarded when the tab closes.
The UsageStory dashboard itself does use a cookie, for keeping customers signed in. That is a strictly necessary cookie and is not used for tracking.
Host apps can call identify() to attach their own account identifier to a visitor, so their analytics can distinguish signed-in users. The value is chosen by the host app. UsageStory recommends an opaque internal id rather than an email address or name, but the host app decides what it sends and is responsible for having a lawful basis to send it.
A recording captures the structure of the page and interactions such as clicks, scrolls, and navigation. It is a reconstruction, not a video of the screen or the camera.
Text entered into form fields is masked by default, so passwords, card numbers, and messages are not captured. Host apps can mark any element with data-replay="false" to exclude it entirely, and can turn recording off per project. A host app that disables masking takes on responsibility for what it then captures.
IP addresses are used to derive a country and to enforce abuse limits. Each project has an IP anonymisation setting: with it on, addresses are truncated before they are stored, so 41.81.240.73 is written as 41.81.240.0 and no full address is ever kept. Country resolution is unaffected. Customers who do not need addresses should turn this on, and it is the recommended setting.
Deleting a project removes its pageviews, events, and recordings. Deleted data can persist in backups until those backups age out.
Depending on where a visitor lives, they may have rights to access, correct, delete, or object to the processing of their data, and to complain to a supervisory authority. Because the host app is the controller, requests should go to that site. UsageStory assists its customers in responding, including locating and deleting a specific visitor's data on request.
Data is stored on servers in London, United Kingdom, operated by DigitalOcean. UsageStory uses a small number of sub-processors, each limited to what its function requires:
Transfers from the EEA to the United Kingdom rely on the European Commission's adequacy decision for the UK. Transfers to sub-processors outside the UK or EEA rely on Standard Contractual Clauses. The current sub-processor list is maintained in the Data Processing Agreement.
Traffic is encrypted in transit with TLS. Access to production systems is restricted to named administrators using key-based authentication. Backups are encrypted and stored separately from the primary database. Passwords are stored hashed, never in readable form.
UsageStory is in beta and does not yet hold an independent security certification. Customers with formal certification requirements should take that into account.
UsageStory is a tool for businesses and is not directed at children. Accounts may not be created by anyone under 18.
Material changes to this policy will be announced to customers by email before they take effect. The date at the top always reflects the current version.
Privacy questions, data requests, and complaints go through the contact form, choosing the "Data & privacy" topic. We reply to the address you provide.