Guides

Privacy & consent

What is collected, what never is, and consent handling.

4 min readSDK 0.5.0

Riveora understands behavior from interactions, not recordings. This page lists exactly what is collected, what never is, and how to handle consent.

What is collected

Screens viewed and how long each was on display.
Taps: the element type, your component name, the position, and a label: the accessibility label, or a button’s short text like “Add to cart”.
Rage taps, taps on non-tappable elements, and JavaScript errors.
Failed and slow network requests: method, host, path (with IDs, emails, phone numbers and tokens replaced), status and duration. Never query strings, headers or bodies.
Device model and brand, OS and version, screen size, language and time zone.
Your app’s version, if you pass appVersion, and the SDK version.
A random anonymous ID per device, and your own user ID if you call identify.
Onboarding, paywall and custom events that your code sends.
In development builds only: the names of your app's screens, and a picture of each screen taken on your own test device.

What is never collected

Screenshots, screen recordings or video of your users’ screens. Screen pictures only come from development builds.
Anything typed into text fields, including passwords.
Text on screen that someone taps when it isn’t a short button label: a message, an address, or a row with a name, a status and a time.
Emails and phone numbers. Riveora.identify() refuses them, properties that look like one are dropped, and notes on saved people can’t contain them. Names only if your own code sends them; properties named like one (first_name, username) are dropped.
Passwords, PINs, API keys and other secrets in properties: keys named like one, and values holding a token or an API key, are dropped on the device and again by the server.
Stack traces. Crash messages are shortened, with emails, numbers, tokens and web address details masked.
Advertising IDs, device serial numbers, contacts, photos or GPS location.

How long data is kept

Events (every screen, tap and request) and the summaries made from them, such as visit summaries, paywall visits, onboarding results, the screen list and insights, are kept while the app exists in Riveora. Every page, and every visit in full, stays available for any period, including all time.
To delete one person’s data, for example when they ask you to, contact us with their user ID.
Deleting an app in the dashboard deletes all of its data straight away.

The SDK has a consent switch with three states. Events are only recorded and sent while it’s granted. Nothing is ever sent before that.

State	Behavior
`unknown`	The default. Nothing new is recorded and nothing is sent. Events saved while consent was granted earlier wait on the device, so an app that loads its saved consent a moment after launch doesn’t lose them. Development builds print a warning, so a forgotten consent setting doesn’t go unnoticed.
`granted`	Events are recorded and sent. Granting during a visit starts recording from that moment, including the visit’s start and the screen on display.
`denied`	Nothing is recorded or sent, and events waiting on the device are deleted.

tsx

// Start without consent...
<RiveoraProvider projectKey="pk_your_project_key" consent="unknown">

// ...then, when the user agrees:
Riveora.setConsent('granted');

// or if they decline:
Riveora.setConsent('denied');

In development builds, the screen list and screen pictures follow the same rule: they’re only sent while consent is granted. If your app asks for consent first, agree on your test device and the dashboard fills in from then on.

Reducing what’s captured

Wrap sensitive UI in RiveoraIgnore. See Automatic capture.
Pass beforeSend to the provider to change or drop any event before it’s queued. See the SDK reference.
Set autocapture={{ captureText: false }} to never use on-screen text as a label.
Set autocapture={false} to turn automatic taps, crashes and network requests off entirely.

Riveora gives you these controls, but you remain responsible for telling users about analytics in your privacy policy and for asking for consent where the law requires it.

Something unclear or missing? Email us and we’ll improve this page.