Privacy Policy

Authentication cookies

If you sign in, Supabase sets session cookies to keep you logged in. These are essential for authentication.

Preferences cookie

We save your name and preferred payment method in a cookie (180 days) so you don’t have to re-enter them each time.

Region cookie

Outside the EU, UK, and Switzerland we set a tidytab_region cookie (24 hours) so the site knows standard analytics may run. It holds no identifier - just that classification - and in consent-required regions it is never set at all.

Local storage

Your browser stores contribution history and payment preferences locally on your device to improve the experience. The same store holds a few small notes about what you’ve already been shown, so we don’t ask twice - among them tidytab_celebrated_payments, a count of the payments you’ve completed on this device. This count holds no identifier, never leaves your device, and is never sent to analytics. tidytab_paid_bills lists the short link codes of the bills you have paid on this device, and tidytab_repeat_host_invite_seen lists the bills where we have already invited you to host one of your own. tidytab_repeat_host_invite_dismissed remembers that you chose Not now on that invitation, and does not expire. These lists stay on your device. When we show the invitation, analytics receives the number of different bills you have paid on this device only where analytics storage is allowed (by default everywhere outside the EU, UK, and Switzerland; there, or when we cannot tell where you are, only after you opt in). Analytics receives the link code of the bill you are on in every region, as described under Analytics below, but never the lists themselves.

After you publish, tidytab.hostProfile.v1 remembers your name, email and payment details on this device to fill in your next bill, even when you are signed out; this convenience record is separate from analytics, and Clear on the bill form, signing out or deleting your account erases it.

Analytics

We use Vercel Analytics and PostHog to collect usage data, including page views, feature usage events (e.g., bill creation, payment method chosen), and AI model performance metrics. Where analytics storage is allowed, authenticated hosts are identified by their account user ID alone - never their email address - so their activity joins up across devices. While analytics are cookieless, your browser and the app send nothing that links your activity to your account; a few things you do while signed in - signing in, creating a bill, creating a group - are still recorded against your account ID by our server. Anonymous contributor activity is tracked at the bill or group level, not the individual level. No names, emails, or payment account details are sent to analytics services for anonymous users.

What happens by default depends on where you are. In the US - and everywhere else outside the EU, UK, and Switzerland - standard analytics are on from your first visit, and you can opt out any time with the control below. If you’re in the EU, UK, or Switzerland, or if we can’t tell where you are, analytics start cookieless instead: everything stays in memory, nothing is written to your device, and session replay is off unless you opt in via the consent banner. When analytics are on, PostHog may store an identifier in cookies/local storage and record sessions so we can watch back anonymized usage. Whichever way you decide, your choice is saved on your device - the tidytab_consent key in local storage plus a matching cookie our server refreshes, so a browser storage cleanup can’t silently flip your decision - and strictly functional storage (like the sign-in nudge dismissal) never leaves your device.

Everything sent to PostHog is masked in your browser first, recordings and ordinary events alike. Every word the page displays is replaced with asterisks, and so is everything you type. Accessible labels, tooltips and the page title are masked or dropped. Images, including receipt photos and avatars, are recorded as an empty box of the right size, with no link to the file. A link to another site keeps only the site, so a payment link reads https://venmo.com, without the handle or the amount. A web address keeps the page path and loses everything after the question mark, wherever it appears: in the page, in a link, in a recorded request, and in the address of the page itself.

What is left is the shape and position of what was on screen, which page you were on, and where you tapped, scrolled and typed. Events carry the page path, your browser and device type, and what you did in product terms: a bill created, a payment method chosen, the size of a share. A group is recorded by its ID. If you are signed in, both carry your account ID; your email address is not sent.

One more analytics key, and only when analytics are on: the first time you open a bill, or create one, we write tidytab_first_touch to local storage - the bill’s short link code, the date, and whether you were a guest or its host. It records only that first time: later bills never replace it, and the one thing that can change it is finding out that the bill it names was yours all along, which corrects “guest” to “host” and keeps the original date. It exists so that if you later create a bill of your own we can count how often someone who arrived as a guest went on to host. The link code never leaves your browser - the event carries only “arrived as a guest” and the number of days since. We neither write nor read it while analytics are off, so in a consent-required region nothing is stored before you opt in and nothing is sent afterwards if you opt out; opting out below deletes it outright.

The same key also holds a referral code, when a link or a printed card you arrived on carried one (for example tidytab.app/new?ref=haas-f26). It tells us which campus programme or group a new host came from, it is the first one only, and it is never anything but the short code itself. If analytics storage is off for you, the code is kept in memory for that browsing session alone and nothing is written to your device.

Links from this site to the App Store and Google Play name the part of the site they sit in, such as the footer, so we can see which ones lead to installs. The first time the Android app opens, and only where analytics storage is allowed, it asks Google Play for that same label and sends it with the install; nothing else Google Play returns leaves your phone. The iPhone app reads nothing like it.