Cookie Policy
How Roda uses essential technologies, PostHog analytics, and similar tools on roda.place and in the mobile app.
- last updated
- effective
Scope
This policy explains how Roda uses cookies, local storage, mobile identifiers, analytics events, and similar technologies on roda.place and in the Roda mobile app.
Technologies we use
- Essential technologies: required to load pages, secure sessions, remember privacy choices, process sign-in, support bookings, and prevent fraud.
- Preference storage: used to remember language, consent status, or app state where needed.
- Analytics: PostHog helps us understand waitlist conversion, page usage, app flows, feature adoption, and reliability. On roda.place it works as described in the sections below.
- Error reports: Sentry tells us when something breaks, on roda.place or in the app, as described in “Error reports” below.
- Payment and authentication technologies: Stripe, Clerk, Apple, Google, and related providers may set or use necessary technologies during payment or sign-in flows.
Analytics on roda.place
roda.place sends analytics events to PostHog's EU cloud through our own address (roda.place/ingest). We use them to count visits and see which pages and links work. Session recording, automatic click capture, heatmaps, and surveys are switched off.
Every event carries the following, whether or not you have said okay:
- What happened: a page view; on pass pages (roda.place/<handle>), the pass page being shown, with the pass handle (a public link), whether spots are open, and which version of the page it was; a tap on a link to the App Store, TestFlight, or Google Play, with where it was (the home page, roda.place/app, or a pass page), which store, the platform, and on pass pages the pass handle; on pass pages, a tap on a link that opens the Roda app, with the pass handle and whether it was the creator's own host link (never the link itself), and copying the pass name, with the pass handle; and your answer to the cookie banner when you give one (see “Your answer, and changing it”).
- Where: the page address and path, and the page that sent you here (the referrer) and its domain. Page titles are not sent: on pass pages they name the creator. A creator's private host link (?host=…) is removed from every address before it is sent, and ad click identifiers such as gclid or fbclid are masked. Campaign tags in the address, such as utm_source, are kept; the QR code on a pass page adds utm_source=qr, so a visit from scanning it shows as one.
- Your browser and device: browser and version, the full user-agent string, operating system and version, device type, screen and window size, browser language, and time zone.
- Identifiers: until you say okay, none from your browser; PostHog's servers give the event a visitor and session id worked out from a daily hash, as the next section describes. After an okay, a random visitor id and session id created by PostHog and kept in your browser (see “If you say okay”).
- Your IP address reaches PostHog with each request, as with any web request. PostHog may use it to estimate an approximate location and, until you say okay, to work out the daily hash described below.
Before you answer, and after “no thanks”
PostHog runs in cookieless mode. It sets no cookies, writes nothing to localStorage, sessionStorage, or any other browser storage, and creates no visitor id or session id in your browser. Instead, each event is marked as cookieless, and PostHog's servers combine your IP address and user-agent with a secret value that PostHog changes every day into a one-way hash, which stands in for the visitor and session ids. Visits from the same browser and network on the same day count as one visitor; a visit on another day, or from another network, can't be linked to an earlier one.
The only thing roda.place stores in this mode is your answer itself, once you give one (see below).
If you say okay
PostHog keeps its random visitor id between visits, so repeat visits count once. The events are the same as above, now linked by that id, starting with the visit where you said okay. To do that, it stores the following in your browser. All of it is first-party (set by roda.place, not by a third-party domain); <key> stands for our PostHog project key.
- Cookie ph_<key>_posthog: the visitor id, the current session id, and the address and referrer of the first page you visited (with host links masked). Expires after 365 days.
- localStorage ph_<key>_posthog: the same, plus the campaign tags and referrer of your visit and PostHog's own settings for the site. Stays until you clear site data or say no thanks.
- sessionStorage ph_<key>_posthog, ph_<key>_window_id, and ph_<key>_primary_window_exists: this visit's campaign tags and referrer, and which browser tab is which. Cleared when the tab closes.
Signing in on roda.place
roda.place/account/delete, where you can export your data or delete your account without the app, lets you sign in with Apple or Google through Clerk, our sign-in provider. It is the only roda.place page that loads Clerk, and only it sets the cookies below. They are strictly necessary for signing in, so the cookie banner doesn't cover them.
- Cookies __session and __client_uat (their names may carry a short suffix), set on roda.place: a short-lived sign-in token, and when you last signed in or out.
- Cookie __client, set on Roda's Clerk sign-in domain: your sign-in session, so the page knows it's you while you're there.
Your answer, and changing it
roda.place asks once, with the cookie banner. “no thanks” is one click, same as “okay”.
Your answer is kept in localStorage under roda-cookie-consent, as 1 (okay) or 0 (no thanks), so we don't ask again and can keep honoring a no. PostHog reads your answer from the same entry. It holds no identifier and stays until you clear site data.
If your browser blocks site storage, no answer can be remembered, so the banner doesn't open on its own and analytics stays in cookieless mode.
Each time you answer, one consent_updated event is sent to PostHog with your answer (granted or denied), along with the page and browser details listed above. After a no, it is sent in cookieless mode, with no stored identifier. Loading a page later does not send it again.
To change your answer, use “cookies” at the bottom of any roda.place page to bring the banner back. Saying no thanks after an okay deletes PostHog's cookie and browser storage straight away and switches back to cookieless mode, without the old visitor id; other open roda.place tabs follow your new answer.
You can also clear or block cookies and site data in your browser settings, or contact hello@roda.place. In the mobile app, use app privacy settings where available. Blocking essential technologies may prevent parts of Roda from working.
PostHog in the mobile app
In the Roda mobile app, we use PostHog in an EU-compliant configuration to understand how Roda is used and where the product needs improvement. Depending on configuration, PostHog may process page views, app events, clicked elements, URLs, device and browser information, approximate location, feature flags, and identifiers for signed-in users.
If session replay, autocapture, or similar features are enabled, they will be used only with appropriate consent and privacy protections, such as masking sensitive inputs and avoiding collection of payment details or questionnaire free text where possible.
Error reports
When something breaks, on roda.place or in the Roda app, an error report goes to Sentry's EU cloud (Frankfurt) so we can find and fix it. On roda.place it is sent through our own address (roda.place/monitoring), and nothing is sent while things work. In the app, each launch also sends a short session record (when it started and ended, and whether the app crashed, with your Roda account id if you are signed in), so we can see how often the app crashes. None of this is used for analytics.
Error reporting sets no cookies and writes nothing to localStorage, sessionStorage, or any other browser storage, so on roda.place it runs whether or not you have answered the cookie banner. A report carries:
- What went wrong: the error message, where in our code it happened, and what led up to it: the pages opened, the page elements clicked (described by their place in the page's code, never by anything you typed), and the requests the page made.
- Where: the page address and the page that sent you here (the referrer), with a creator's private host link (?host=…) removed from both. In the app, the screen instead.
- Your browser and device: the user-agent string (browser, operating system, and their versions). In the app: device model, operating system, app version, and similar technical details such as language, time zone, and free memory.
- Who: on roda.place, no identifier of any kind. In the app, when you are signed in, your Roda account id (a random string, not your name or email), so we can tell how many people a problem affects.
- Your IP address is not included in a report, and Sentry is not asked to work it out.
Advertising
Roda does not use advertising cookies, retargeting pixels, or third-party ad networks at launch. If that changes, we will update this policy and request consent where required.
Changes
We may update this policy if our analytics, consent, or provider setup changes. Material changes will be reflected on this page and, where appropriate, in the consent interface.