How PUBMAXX handles your data

The short version

• No account needed to look. We don’t ask who you are to show you the price of a pint.
• Analytics are off until you switch them on. On your first visit we ask you to tap Allow or No thanks. We remember that choice, and you can change it later in your account settings.
• PUBMAXX never stores raw IP addresses in its own database. Where an unauthenticated action needs abuse controls or deduplication, we store a salted hash of it, never the address itself.
• We don’t sell anything to anyone. No ads, no data sales, no ad networks, no advertising trackers on the site.
• Your nights are yours. Your memories and private plans aren’t public unless you choose to share them.

Who’s responsible

PUBMAXX is run by Karan Manoharan, an individual based in London, UK. There is no company behind it yet, so for UK GDPR purposes the data controller is that individual, reachable at karan@pubmaxxing.com. We don’t have a Data Protection Officer, because at this size the law doesn’t call for one.

What we collect

If you browse

Nothing you type, and no account. Our hosting provider records the ordinary technical detail every web server sees when it serves a page: the request, the time, the browser type and the IP address it came from. That is how the site gets served and how abuse gets stopped. Your browser fetches map tiles directly from the tile hosts named below, so those hosts see your IP address the same way any website you visit does.

If you ask for a new area

We store the area name you send. You can add an email address if you want one message when PUBMAXX reaches that area. Most area requests have no email address. We don’t add it to a marketing list or a digest.

If you make an account

Supabase handles sign-in, using an emailed magic link, a code sent by text message to a UK mobile number, or Microsoft, Google or Apple sign-in. That means we hold your email address, or your phone number if you sign in with a text code. We use the phone number only to send sign-in codes. It is never shown to anybody. You must choose one public handle, which is linked to your authenticated account and is the only identity shown with contributions. You need a handle to finish signup. Date of birth is optional. Full name, gender and sex are optional. We collect and store date of birth, full name, gender and sex as private details for existing account tools. Social adult access does not use full name, gender or sex. They are never shown on prices, reports, signals, Recommendations, leaderboards or the public contributor record.

We keep date of birth until you delete your profile. Full name, gender and sex stay until you edit or clear them, or delete your profile. Deleting your profile removes these private identity fields and clears its editable public details. That action keeps your authentication account, public handle and handle-keyed contribution history. You can ask us to delete other account data. We don’t use date of birth to block an account or contribution.

Social uses a private product account tied to your Supabase sign-in session and stable profile. We don’t match accounts by email, public handle or anything typed into a form.

Full Social access is for signed-in accounts with a claimed handle and an 18+ answer. The date of birth you gave at onboarding decides when it is present. A date of birth is optional at onboarding. Where an account recorded none, one self-assertion can answer the access question. Social is live by default and may return to preview during an emergency rollback. We do not run a separate hosted age check. None of that private data appears on your profile as an age or verification badge.

Your public profile may also contain a display name, home city and short bio. A profile picture is an optional upload you choose: we store the normalised JPEG under our own private storage (not a hotlinked URL), strip embedded metadata before it is saved, and send a short-lived signed copy to OpenAI for an advisory omni moderation check before the picture is publicly addressable. If the check refuses the picture, we refuse the upload and keep your previous picture (or none). If the check cannot run or gives no usable decision, the upload can proceed without scan approval. Readers may report a profile picture; a report joins a private review queue and does not hide the picture on its own. A named staff member must hide or restore it, and that decision keeps a private audit record. Hiding stops public delivery and never deletes the stored file or the report record. Removing the picture yourself, or deleting your account, removes the stored file from our storage. If you connect an external social profile (X, Instagram, TikTok) we store the account details you connected and any provider tokens encrypted at rest.

If you use an invite link

Making an invite gives you an opaque link tied to your account. When someone follows it, the opaque code stays in the page address. We set no referral cookie and store no attribution record while they browse. If that person starts and completes account creation in the same sign-in journey, the completed callback submits the code and we record one private referral edge between the two account IDs. It is recorded once and is never shown on a public profile, contributor record, venue page or anywhere else public.

Attribution works only during that sign-up. A delayed return, a different browser or device, an invalid link, or signing into an existing account isn’t attributed. We don’t guess when the same-journey proof is absent.

A referral isn’t qualified by signup alone. It needs the new account to make its first accepted contribution. We keep append-only milestone records so later decisions can be explained. Those milestone records don’t grant paid features today, because sign-in doesn’t prove that one person has only one account.

A Plan can also publish a separate public invite link. Anyone with that link can RSVP with a display name (Going or Maybe) and leave a closed set of emoji reactions, without creating an account. We store the display name you type, your RSVP choice, your reaction choices, and a salted hash of a browser device id so the same device can update its own RSVP instead of stacking duplicates. We do not store the raw device id. Anyone who has the link can see the guest list and reaction counts on that invite page. The Plan host can remove an RSVP from the list. Closing or deleting the Plan removes those invite RSVPs and reactions with it.

What you post

Pint Drops (a price, a note, sometimes a photo), plans and crawl routes, presence taps (“I’m here tonight”), ratings, messages to other people, Visit Reports, Recommendations, and your memories. We keep these because they are the product. A price with no date and no source is worth nothing. Presence is always a deliberate tap; the app never tracks your location in the background.

We store Social post text in a private moderation queue, then send it to OpenAI for omni moderation. A post stays held from every Social feed and direct read until OpenAI returns a decision. If OpenAI is unavailable or returns no usable decision, the post stays held. No account ID, public handle, area or exact venue is included in that moderation request. Social photos are normalised to JPEG, resized and stripped of embedded metadata before private storage. OpenAI receives a short-lived signed copy with the post text for moderation. Photo tags appear only after the tagged person approves them and can be withdrawn later. The browser keeps unfinished text and selected photo data on this device until you post or clear the draft.

You can hide your name on a public Social post. Other people then see “a PUBMAXXER” instead of your handle, with no picture and no link to your profile. We still store your account and handle with the post. Moderators can see them, and a report on the post reaches your account. A post with your name hidden cannot name a pub or tag anybody.

Failed or interrupted Social photo uploads can stay temporarily in private server storage so an exact retry cannot damage another upload. They become eligible for deletion after 24 hours. A daily scheduled cleanup removes them. Storage or database outages can delay that cleanup.

Cheers, comments, private saves, reposts and quote posts are tied to your stable Social profile. Saves are private and have no public count. Comments and quote-post text enter the same kind of private queue, go to OpenAI for omni moderation, and stay held until a usable decision returns. In-app notifications store the people and source records involved, not a copy of protected post or comment text.

Blocks remove interactions from both people’s Social reads. Feature requests keep an append-only staff status and response history. Reports from readers join a private review queue and do not hide content. A named staff member must hide or restore a comment or quote, and that decision keeps a private audit record.

Social edits keep revision numbers, changed-field names and content digests for conflict handling and abuse review. A private removal audit keeps the media ID, post, actor, detachment action and retention deadline. A removed photo stops being delivered. Detached photo files enter a 30-day deletion queue. A scheduled server cleanup removes the private file and its media row after that date. Signed photo links expire after three minutes.

A Recommendation is your short opinion that one pub suits one kind of weather. Writing one needs a signed-in account, a claimed public handle and a completed private profile. We store your public PUBMAXX handle, the pub, the single condition you picked from warm, clear skies, raining, cold and windy, the reason you wrote, the time our server took it, and your account’s stable private profile key. The server derives the handle and private key from your authenticated account and ignores any handle sent by the browser. We use the private key for rate limits and audit records and never show it. A visible Recommendation counts on the public contributor record under its public handle. Historic Recommendations written under an unlinked, self-asserted handle can remain visible. They are excluded only while their stored handle does not resolve to a public profile. They stay unlinked and excluded from identity-backed counts. Writing another under the same handle for the same pub and condition replaces the one you already had. The weather never writes a Recommendation. It only decides which of the ones people wrote match right now.

Visit Reports

A Visit Report records what you noticed on one dated pub visit. Writing one needs a signed-in account, a claimed public handle and a completed private profile. We store your public handle, the pub, the visit date, the observations and note you chose, and the time our server took it. The server derives your handle from your authenticated account and ignores any handle sent by the browser. To limit abuse, we use your account’s stable private profile key together with a salted hash of your IP address. We never store the raw address. Historic Visit Reports written under an unlinked, self-asserted handle keep that attribution and can remain visible.

Crowd occupancy reports

A crowd occupancy report is linked to your signed-in account. We store the pub, the level you tapped, the time, and your account id. It is deleted with the account.

Any reader can flag a crowd occupancy report. We store the report the flag is about, a salted hash of the reader’s IP address and, when one is sent, a short written reason. We never store the raw address. Flags join a private review queue and never hide a reading on their own. A named staff member must hide or restore it. Hiding stops the reading being shown and never deletes the row. Flags leave with the report they are about.

Price trust milestones

When two independent logs first make a drink price trusted at a pub, we store an account-linked milestone and credit the accounts in that first cluster. A later agreeing log does not earn a second credit. A moderator hide writes an append-only audit reversal and removes the visible credit. If the remaining logs still qualify, we write one replacement milestone. Your personal credit is deleted with the account.

Community price submissions

Logging tonight’s price needs a signed-in account, a claimed handle and completed private profile. We store the venue, drink category, price and time, plus the account’s stable private profile key and current public handle. The server derives both contribution identifiers from the authenticated account and ignores any handle sent by the browser. A newly accepted price therefore counts under that account’s handle on the public contributor record.

The private profile key exists so one account can replace its own earlier entry instead of stacking duplicates, and can’t confirm itself by changing devices or handles. Legacy contributions made under a self-declared handle stay historic and cannot be claimed by first touch. Older rows that had no handle remain anonymous. Reader reports about a price still use a salted hash for abuse controls; we never store the raw IP address.

Public contributor record

The public contributor record ranks existing public profiles by contributions tied to that identity: visible prices posted, Visit Reports written and Recommendations made, added together across all time. Named Visit Reports and Recommendations that don’t resolve to an existing public profile can remain visible on their posts but are excluded from this identity-backed ranking. It shows the combined total and each of those three counts. Hidden or taken-down contributions don’t count. Older price logs with no handle never appear under a name.

We also keep whether a price was corroborated, whether a contribution survived moderation and whether a price was later contradicted. We keep those signals so we can make the record more useful later without losing its history. They don’t change today’s ranking, which is based only on how many identity-backed, visible contributions a profile has made.

Community venue reports

A signed-in account with a claimed handle can also report what they saw about a pub: rough or posh character, entrance and toilet access separately, door policy, and whether people were eating. We store the venue, answer and time, plus the same stable private profile key used for community prices. It lets your newer answer replace your older one and keeps one account from confirming itself. Venue reports don’t enter the public contributor record, and the private key is never shown.

Location

“Find my pint” asks your browser for your location and ranks nearby pubs there, so those coordinates never leave your device. Viewer coordinates never leave your device at full precision. Other location features work like this:

• What’s on: sharing location on the map or Tonight rounds your point to three decimal places, roughly 70 to 110 metres in London, before sending it to our /api/whats-on route so it can rank listings near you.
• Conditions and getting home: Tonight rounds your point to three decimal places, roughly 70 to 110 metres in London, before sending it to our /api/tonight-conditions,/api/last-train and /api/tfl-disruptionroutes. Today uses the same rounding for last-train and disruption requests. These answer nearby conditions, your nearest station and relevant transport disruption. The last-train route passes the rounded point to Transport for London’s public StopPoint API.
• Getting to a pub: sharing location for travel times in a map venue sheet rounds your point to three decimal places before posting it to our /api/citymcp/journey route. Our server forwards that approximate origin to CityMCP for journey options. If you then tap Maps, your browser sends the same rounded origin to Google Maps for directions.
• Buses near a pub: opening nearby bus departures sends the pub’s public map coordinates to our /api/nearby-bus-departures route. Our server passes that pub location, not your location, to Transport for London’s public StopPoint API to find nearby stops and live departures.
• Remembered areas: Tonight can turn an area choice saved in your browser into that public area’s coarse centre and send the centre to /api/whats-on. Today rounds the same kind of centre before sending it to /api/tfl-disruption. The saved choice itself isn’t uploaded.

Say no and the app falls back to picking an area or lets you open a venue without your location.

Analytics, only with consent

Usage analytics are off by default. A small prompt asks on your first visit, with Allow and No thanks both one tap. The browser remembers that choice so the prompt doesn’t return on every visit. If you allow analytics, you can turn them back off later under Optional usage analytics in your PUBMAXX account settings. While they’re on:

• We create a persistent device identifier in your browser so page loads and later visits from that browser count as the same device. PostHog uses it for unique-user and retention analysis and keeps pseudonymous person and device records. We don’t identify that record with your PUBMAXX account, handle or email.
• Page visits and events include browser and version, operating system, device type, screen and viewport size, the referring page, recognised campaign parameters and coarse app paths. The browser records page exits, time on each page and the furthest proportion scrolled, so we can measure visits and reading depth. We exclude message, account and admin pages from these measurements. The browser SDK also sends Web Vitals, and how long the map took to show its pubs, so we can measure loading and interaction performance. No account, handle, email, message content, free text or precise location is attached.
• Product actions still come from a closed, named list, such as a plan being accepted, with allow-listed simple values. Our server re-checks every product event and its browser context against the same rules and drops anything it doesn’t recognise.
• For crash reporting, the browser analytics SDK sends the crash type with the same standard device context and the same coarse app path as a page visit, so we can tell two different faults apart. Error messages and stack traces are redacted before they leave your browser. Session recording, autocapture, heatmaps, click tracking and surveys are all disabled.
• Analytics requests go through pubmaxxing.com rather than straight to the provider. The first-party browser proxy doesn’t forward cookies or sign-in headers. For named product events, the server passes the request user agent and raw IP address to PostHog along with the validated referrer, screen context and the analytics session the event happened in. PUBMAXX doesn’t put that raw IP address in its own logs or database; its own rate limit keeps only a salted hash.
• If your browser sends a Do Not Track signal we skip analytics regardless, and the server honours the same signal.
• Turning consent off deletes the browser analytics identifier and stops PostHog page visits and exits, product events, the hosting provider’s pageview counter and its Speed Insights Web Vitals. If you allow analytics again, page measurements start fresh. They exclude time and scrolling while analytics were off.

Things that aren’t about you

Pub locations, opening hours, heritage facts, scraped and sourced prices, and the weather all come from public data. None of it’s personal data, and our server makes the requests for it, not your browser.

Social Crews

A Social Crew uses its linked Planned Night title as its name. We store its visibility, owner, and roster. Visibility is private, friends-only, or open. Roster data includes each member’s account, role, join time and current state. The owner, and active members who remain Mutual with the owner, can read the full roster and Crew-bound Plan, including its stops, night details, actions and ending.

A private Crew is readable only by the owner and active members who remain Mutual with the owner. Friends visibility lets current Mutuals of the owner read a limited preview with the Planned Night title, phase, area, start time and their own Join Request state. That preview does not show the roster or Crew-bound Plan details. A block in either direction closes the read. While a plan is open, anyone can see its title, the pub or place it starts at, its start time, how many people are in it, and your handle as host. Close the plan and it drops out of the public list.

Each invitation records its sender member, recipient account, expiry and state. A Join Request records the requester account. The owner and cohosts can see who asked while it is pending. A pending request expires at its deadline, and its final state, decision time and deciding member remain as decision history.

Private Crew write receipts record the actor account, action, idempotency key, content digest and returned result. They exist for safe retries and audit only. These write receipts are never public.

Crew and roster records stay with the Crew-bound Plan. A left or removed member keeps a terminal membership row as history rather than disappearing. Invitations and Join Requests keep their final states until the Crew-bound Plan is deleted. Pending rows become expired rather than being rewritten as accepted or declined. Private write receipts stay until an account deletion request is carried out, unless a legal or security hold needs a narrower record for longer.

Why we’re allowed to

In UK GDPR terms, in plain language:

• Because you asked us to (contract). Holding your account, your plans, your messages and your saved nights is the service you signed up for.
• Because it’s a fair thing to do (legitimate interests). Keeping community prices and venue reports with their dates, private profile keys or legacy device tokens, rate-limiting writes, and keeping server logs is how the map stays honest and the site stays up. We’ve kept it to the minimum that works.
• Because you said yes (consent). Usage analytics and push notifications are consent-only, and you can withdraw consent at any time without losing the rest of the app.

Cookies and what sits on your device

We don’t use advertising or cross-site tracking cookies, and there’s no ad network on the site. What we do keep in your own browser storage:

• A sign-in session, if you signed in, so you stay signed in. It lives in your browser and refreshes in the background. A first-party sign-in cookie also keeps a session renewal token and your sign-in email address on this device for up to 30 days, renewed while you use the site, so clearing browser storage does not sign you out. Signing out removes it.
• Your analytics choice, either allowed or denied, so we don’t ask on every visit. Until you tap Allow, no analytics identifier exists. After you allow it, we keep the persistent device identifier in browser storage and a first-party cookie so later visits remain one device. Withdrawing consent removes that local analytics identity and stops new collection.
• Preferences and app state: theme, your device night profile, your remembered area, what you’ve already been shown once. We don’t upload those stored values as a bundle. An area choice can be turned in your browser into a coarse centre used for the requests described under Location. Your device night profile stays on your device unless you sign in and choose to bring it to your account.

Pub Pal keeps up to 24 conversation entries in this tab, including your questions, answers, sourced cards and pending proposals. It uses your browser’s sessionStorage when available, so you can return to the chat after browsing a pub.

We do not restore a saved conversation after more than two idle minutes. We remove an older copy when the chat reads it. Until then, the copy can remain in tab storage.

Changing accounts, signing out or choosing New conversation clears the current thread. Confirmed Pal memories stay separate. A pending proposal becomes a memory only after you confirm it.

Because nothing non-essential is set before you agree to it, the first visit choice is a small prompt rather than a wall in front of the map. Your account keeps the later control.

Who else touches it

We keep the list short on purpose. Each of these acts as a processor for us, is only reached when you actively use the feature, or is named as a planned processor that receives nothing today.

Supabase

Database, sign-in and file storage, on their EU region. Holds your account, your posts and your community price and venue report rows.

Twilio

Sends the sign-in code by text message, and only when you choose to sign in with a phone number. It receives your phone number and the code. Phone sign-in stays off until it is switched on in our Supabase settings.

Clerk

Optional sign-in for Clerk controls. Clerk keeps its own session and user ID. PUBMAXX joins that ID to a private product account on our server. It does not provide Social access, and it does not turn a Clerk session into a Supabase account.

Yoti

No current PUBMAXX access flow. A future stronger assurance tier would need a separate provider review. PUBMAXX does not currently send data to Yoti or receive a result from it.

OpenAI

Social post text goes to OpenAI for omni moderation after the post enters our moderation queue. It stays held until OpenAI returns a decision. We don’t send the Social account ID, handle, area or venue with that text. Normalised Social photos and profile pictures go to OpenAI through short-lived signed links for the same moderation decision. A profile picture is scanned before it is publicly addressable; a Social post stays held until a usable decision returns.

Vercel

Hosting and CDN. Serves every page, and keeps short-lived request logs that include IP addresses. With analytics consent, also receives pageviews and Speed Insights Web Vitals from your browser; Do Not Track blocks both. Without consent, neither is sent.

PostHog (EU)

Product analytics, EU project, consent-gated, with pseudonymous person and device records for unique-user and retention analysis. It receives the analytics categories listed above, including the raw IP on named product events. There are no session recordings and no identify calls tying events to your account.

Map tile hosts

OpenFreeMap and CARTO serve the base map straight to your browser, so they see your IP address while you pan the map. Map data is © OpenStreetMap contributors.

Transport for London

When you ask for last-train help, our server sends your coordinates rounded to three decimal places to TfL’s public StopPoint API at api.tfl.gov.uk to find your nearest station. It also fetches live arrivals, timetables and line-status information. Opening nearby buses on a pub sheet sends that pub’s public map coordinates, not your location, to find nearby stops and live departures.

CityMCP

When you share location for travel times to a pub, our server sends your origin rounded to three decimal places, with the selected venue, to CityMCP London at citymcp.com for journey options.

Google Maps

If you tap Maps after sharing location in a venue sheet, the directions link gives google.com your origin rounded to three decimal places and the selected venue. Other Google map links include the venue or search only, not your shared location.

Imported pub lists

We match the pub names in a caption, note or message you paste. Short prose may go to OpenRouter, using providers that do not retain it. We discard the pasted text after matching and exclude it from logs and analytics. If you save the list, we keep its matched pub IDs, your optional source link, its creator handle when the link names one, and the save date in a private night draft. Only your account can read that draft. Your account export includes it. Deleting your account removes it. We never fetch the source link.

Board photos

If you photograph a pub’s price board, we strip the photo’s metadata and send it to OpenRouter, using providers that do not retain it, so the Pal can read the prices. We do not keep the photo from that read. Each price you then confirm is logged like any other price you log, with the photo as its bill.

AI features

If you ask The Landlord about a pub, or talk to Pub Pal by typing or by voice, the text or audio of that request goes to the model provider that answers it (OpenRouter; Anthropic at api.anthropic.com when Pub Pal typed chat runs on Claude; and ElevenLabs at api.elevenlabs.io for Pub Pal voice, and for typed chat when Claude is not configured). With Pub Pal, the memories you confirmed for your Pal go with each chat or voice call too, so it can use them: every one of those short preferences, such as a drink you like or an access need, up to forty, with the ones about what you just asked first. Past forty, the ones about what you asked go and the oldest of the rest wait for a question about them. So does a short read of your taste that we work out from your profile’s favourite drink and what you logged yourself: your usual patches, the pubs you go back to or rated, what you drink, what you usually pay for a pint, the vibes you tag and the pubs you saved. Our server keeps that read in memory for two minutes at most and never writes it to a database. Turn the taste read off on your Pal’s page and neither your favourite drink nor your logs are read for it. Nothing else about you goes with it. We do not keep the audio. Recent lines are stored against your account for two minutes after your last line, then deleted by a clean-up that runs every minute.

TypeSafe

Pub Pal asks TypeSafe two yes-or-no safety questions about your message before it answers. Are you asking if you are fit to travel after drinking? Are you asking how to get home? Your message and up to six recent turns of that conversation go to api.typesafe.ai for those judgments. When Pub Pal offers to remember something in a typed or voice chat, the new fact and up to five of the memories you confirmed that are about the same thing also go to TypeSafe, which says whether the fact is new, repeats one of them or replaces one. Nothing else about you goes with them. It is off and sends nothing unless a TypeSafe key is set on the deployment; without one Pub Pal falls back to a fixed word list on our own server, and every memory offer is an ordinary card.

Arize AX (United States)

Server-side tracing for the model calls above, so we can see what they cost and where they fail. While it is switched on for a deployment, every model call our server makes sends Arize the model name, the token counts, how long the call took, and a fixed tag naming the feature, together with the text of the request and the model’s reply. That includes what you type into The Landlord, Pub Pal, a question about a pub’s history, and the free text a planning ask carries. Traces go to otlp.arize.com in the United States. Email addresses and @handles are replaced before a trace leaves our server; nothing else in the text is. The moderation calls named above send Arize no text and no picture. A trace carries no IP address, no account ID and no handle of its own, and nothing is sent at all unless both Arize keys are set on the deployment.

Email and push

Supabase sends account magic links and stores an optional contact address when you ask PUBMAXX to cover an area. There is no marketing list or email digest. If you turn notifications on, PUBMAXX stores your browser’s push subscription, the endpoint plus its keys, so it can send you the notification; the subscription itself belongs to your own browser’s push service. We keep that stored row until the push service reports it dead or you ask us to remove it. The separate weekly nudge is off by default. If you turn it on, we store that preference against your account, bind it to the same web push subscription, and may send at most one push a week about a pub on your list to try near your night patch, an open plan for tonight, or a sourced deal. Turning it off withdraws the preference and removes the bound subscription.

Apple and Google push

If you allow notifications in the iPhone or Android app, your phone gives the app a device token, and we store that token with the platform name. The token carries no account, handle or email. To deliver a notification, our server sends the token with the notification title and text to the Apple Push Notification service at api.push.apple.com (or api.sandbox.push.apple.com for development builds), or to Firebase Cloud Messaging at fcm.googleapis.com. We keep the token until Apple or Google reports it invalid, for example after you delete the app. Because the token carries no account, we cannot find it from an account or email request.

Sign-in and connected profiles

If you choose Microsoft, Google or Apple sign-in, that provider confirms who you are to our Supabase sign-in service and shares your email address and the basic profile details it releases. If you connect an X, Instagram or TikTok profile, our server exchanges the sign-in code with that platform at api.x.com, api.instagram.com and graph.instagram.com, or open.tiktokapis.com, and reads your username, profile link and, where the platform gives it, display name and picture. Disconnecting the profile, or deleting your account, removes the stored details and tokens.

We don’t sell personal data, and we don’t share it with advertisers or data brokers. We’ll only hand something over to authorities if the law tells us to.

How long we keep it

• Your account and what you posted: until you delete it, or ask us to. Ask, and we’ll delete the account and the personal content attached to it within 30 days.
• Pub Pal lines: recent lines from typed chat and voice are stored against your account for two minutes after your last line, then deleted by a clean-up that runs every minute. We do not keep the audio.
• After you delete your account: the prices and reports you logged stay up with your handle taken off them, and we keep a private record, readable only by us, of which deleted account logged which of them.
• Backups: data you delete, including a deleted account, can remain in our backups for up to 8 weeks before it is removed. We never delete our only complete backup, so if newer backups fail, that one is kept past 8 weeks until a newer backup completes. A failed backup sends us an alert so we can fix it. If the backup Mac is asleep, powered off, or unavailable, deletion is delayed until the next run.
• Social account records: the private product account link stays with the Social account until deletion. The date of birth used for the 18+ gate stays in your private identity record until you delete your profile.
• Social Crews: the Crew, membership history, invitations and Join Requests stay with the Crew-bound Plan until that Plan is deleted. Private write receipts stay for safe retries and audit until the actor’s account deletion request is carried out, unless a legal or security hold applies.
• Crowd occupancy reports: linked to your account and deleted with it.
• Price trust milestones: your personal credit is linked to your account and deleted with it. Append-only audit reversals stay with the pub’s milestone record and do not name you.
• Community prices and venue reports: the report itself stays, so later readers can see what people said and when. Each row records the venue, either a drink and its price or one venue answer from a fixed list, the date and the private profile key. Price attribution stays with the row while it is up and counts on the public contributor record until you delete your account. Legacy rows may instead contain an unreversible device token or no public handle.
• Recommendations: a Recommendation keeps your handle and private profile key for as long as it is up, or until you delete your account. The handle attributes the opinion publicly; the private key stays hidden and supports rate limits and audit records. Writing another under the same handle for the same pub and condition replaces the one you already had. There is no one-tap delete for a single Recommendation yet, so ask us and we’ll take it down, the same as anything else you posted.
• Hidden or reported content: a detached Social photo stops being delivered immediately and enters the 30-day deletion queue.
• Analytics events: PostHog deletes analytics events 12 months after collection. It deletes pseudonymous person and device records 12 months after their last activity. These records carry no account identity, so they can’t be traced back to you after the fact, which also means we can’t pick your events out to delete them individually.
• Rate-limit records: durable limiter rows are keyed to salted hashes, never raw IP addresses. Each row expires at the end of its limiter window and is deleted the next time the durable limiter runs. The longest current window is seven days.
• Area requests: the area demand signal stays so we can plan coverage. An optional contact address stays until you ask us to delete it at karan@pubmaxxing.com.
• Legacy pending digest addresses: addresses in legacy public.email_subscribers rows remain stored. We do not confirm or mail them. Ask us to delete yours at karan@pubmaxxing.com.
• Push subscriptions: if you turned notifications on, the stored subscription row stays until your browser’s push service reports it dead or you ask us to remove it. A weekly nudge opt-in preference and its last-sent stamp stay until you turn the nudge off or delete your account.
• Referral records: the private invite code, account-to-account edge, first accepted contribution marker and milestone records stay until either account is deleted. Ordinary product writes can only append that history. A confirmed account deletion removes the private referral data tied to that account. We retain only a one-way hash of the deleted account ID in the referral system so an existing session can’t recreate those records.

Your rights

Under UK GDPR you can ask us to show you what we hold about you, correct it, delete it, hand it over in a portable form, restrict what we do with it, or object to it. You can also withdraw analytics consent whenever you like, in the app, without asking us.

A portable copy you can take yourself, without asking us: open the You tab, go to Account settings and choose Download your data. It is one JSON file of your memories and Moments, the prices and Pint Drops you logged, and the messages you sent.

Deletion you can do yourself, without asking us: open the You tab, go to Account settings and choose Delete account. It happens immediately. What deletion removes and what it keeps is written out in full.

For anything else, email karan@pubmaxxing.com and say what you want. We’ll reply within 30 days, and it doesn’t cost anything. If we can’t confirm that the account is yours we’ll say so rather than hand your data to someone else.

If you think we’ve got it wrong, you can complain to the Information Commissioner’s Office at ico.org.uk. We’d rather you told us first so we can fix it.

Age and access

The map and existing contribution tools don’t use age to block an account. Social is live by default and may return to preview during an emergency rollback. Full access needs a signed-in account, a claimed handle and an 18+ answer. The date of birth you gave at onboarding decides when it is present. A date of birth is optional at onboarding. Where an account recorded none, one self-assertion can answer the access question. We do not run a separate hosted age check. Pubs remain responsible for deciding who they serve.

If this changes

When what the app does changes, this page changes with it and the date at the top moves. If a change is significant, like a new processor or a new category of data, we’ll say so in the app rather than quietly editing the text.