Stumblday is a directory of what is on in New York City this weekend. Most of it works without telling us who you are. This page says what we collect, why, who processes it, how long it is kept and how to have it deleted. It sits alongside the Terms of Use.
Effective September 6, 2026. Published by Creamsicle, LLC. Questions and deletion requests: bryan@stumblday.com.
Stumblday uses PostHog for product analytics. On every page it records a page view and a page leave, and the actions the site itself offers — saving an event, marking “I’m going”, clicking through to an event’s source, adding an event to your calendar, sharing, signing up, sending feedback — together with the page, the event and whether you are on a phone or a desktop. It does not record your clicks in general (autocapture is off) and it never records your screen (session replay is off).
PostHog gives your browser a random device id and keeps it in your browser’s storage. It receives your IP address with each event and, under its default settings, derives an approximate location from it. Anonymous visitors are not given a person profile. When you give us an email address — subscribing, RSVPing, keeping a plan, submitting an event, or sending feedback with an address — the matching event we send PostHog is keyed to that address, and a signed-in account is identified to PostHog by its id, email, name, handle, borough and which sign-in system created it.
Google Analytics 4 is loaded alongside PostHog and receives page views; it is never handed the return token described below.
We read aggregate counts back out of PostHog — views, clicks, saves, shares, calendar adds and going marks per event — to show “Popular this weekend” and to inform ranking. A count below five is never shown.
Opt out: open any Stumblday page with ?analytics=off added to the address. That sets a cookie and a browser flag for one year; after that neither PostHog nor Google Analytics is loaded, and the server records no analytics for your requests either. ?analytics=on turns it back on.
Links we own carry a short token in the address (d=) so that a visit that comes back through one of them — a calendar alarm, the Weekend Digest, an RSVP reminder, your emailed plans — is counted as a return by the same person rather than as a stranger. In the calendar (.ics) files it is the PostHog device id your browser already has. In email it is a one-way hash of your address (SHA-256 with a secret salt, first 24 characters), from which the address cannot be recovered. The server checks the token’s shape and copies it into the links; our code does not log it, store it or return it from any API, though a request that carries it appears, like any other URL, in Google Cloud’s standard request log. Share and invite links never carry it.
Saved events, “I’m going” marks and the plan bar live in your browser’s local storage, not on our servers, unless you email them to yourself or sign in. The site also remembers there: the email you typed into the RSVP box, which events you asked a reminder for, that you subscribed to or dismissed the newsletter prompt, which sign-up bars you closed, your recently viewed pages, this browser’s device id, the invite links it has minted and the name you gave with them, which invite links you have opened, a first-save nudge flag, a per-tab flag that your plans were just emailed, a local copy of your account profile while you are signed in, and the analytics opt-out flag. Stumblday itself sets one cookie, and only if you opt out of analytics; PostHog, Google Analytics and Firebase keep their own browser storage when they run. Clearing site data for stumblday.com in your browser removes all of it.
Forms are rate-limited by network address held briefly in memory; it is never stored.
Weekend Digest. Signing up stores your address and the page you signed up from. The digest goes out once a week, on Friday afternoon, and each send is recorded against your row. Every issue carries an unsubscribe link and a List-Unsubscribe header; the link works with no login and no JavaScript. Unsubscribing marks your row rather than deleting it, so a later send cannot reach you by mistake; signing up again clears the mark.
“I’m going” reminders. Marking “I’m going” on its own stores nothing in our database (the tap is one of the analytics actions above). If you also leave an email, we store the address, the event’s slug, title, dates and venue as they were at that moment, where on the site you did it, and a private token for the cancel link. You get one reminder the morning of the event (sent around 8:03 a.m. New York time) with a few other picks from that weekend’s board, and one “how was it?” the day after with a thumbs-up/thumbs-down; your answer is stored as a rating on the same row. Each of these emails carries a cancel link and a List-Unsubscribe header.
Email me my plans. The button on the Saved page sends one email listing your saved and going events and stores nothing — not the address, not the list. The per-address daily limit is keyed by the one-way token, so not even the limiter holds an address.
Keep my plan. The older “Keep my plan” box on the board’s plan bar is different: it emails you the plan, stores the plan with your address, and adds your address to the Weekend Digest list.
Feedback. The feedback form stores your message, the address if you gave one, the page you were on and your browser’s user-agent string, and emails the same to us.
Sharing “I’m going” with friends mints an invite link. Minting stores the event, the first name you typed (optional) and this browser’s device id, which is used for rate limits and for your own “friends are in” count and is never shown to anyone. Accepting stores the accepting browser’s device id and, if given, a name; the accept endpoint would also store an optional contact, but the invite page never asks for one, so accepting on the site leaves it empty. Anyone holding the link can see the inviter’s first name and how many people accepted, nothing else. The invite page never asks for a phone number or an email address.
Accounts are optional; nothing on the site needs one. The sign-up form sends your email and password to Firebase Authentication, a Google service; Stumblday’s own database never stores a password, and the API has no route that accepts one. It stores the Firebase user id, your email, the display name you gave, a handle made from it, your initials, your borough, a role title, the events you save, vote on, share, comment on, ask a question about or submit while signed in and, if you fill them in on the settings page, a short bio and a one-line “taste signal”. Two accounts created before Firebase sign-in existed (as of the effective date) still hold a SHA-256 hash of the password set then; that sign-in path has been removed and we clear those hashes on request. Your avatar is a generated pattern your browser fetches from DiceBear (api.dicebear.com) using your Firebase user id as the seed.
When you click through to an event’s own page or its ticket page, the click passes through a /go/ link and we count it: the event, the destination, which kind of link, and the Stumblday page you came from. No device id, no address, no name.
Nothing is deleted on a schedule; there is no automatic purge in the code. Subscriber rows, RSVPs (with their reminder, follow-up and rating marks), invites and accepts, organizer submissions, feedback, kept plans, outbound-click counts and account rows are kept until you ask us to delete them. Unsubscribing and cancelling a reminder mark the row rather than delete it, so the opt-out cannot be forgotten. The plans email and the calendar files store nothing. PostHog and Google Analytics keep event data under their own retention settings, and Google Cloud keeps its request logs under its defaults.
?analytics=off to any Stumblday address.Stumblday runs a connector (an MCP server at /mcp) that ChatGPT, Claude and similar assistants can call. A call carries only the tool’s arguments — a weekend date, a borough or neighborhood, a category, a result count, an event slug or URL and, for an RSVP, the email address you gave the assistant — plus the connector’s user-agent, used to label the client as ChatGPT, Claude or another, and its network address, which is used to rate-limit RSVPs and is never written to the database. We do not receive your conversation, your name, your account with the assistant or any identifier for you. Each call is stateless; nothing is kept between calls except an in-memory RSVP rate limiter that holds the network address for ten minutes and never writes it anywhere. We record one anonymous count per tool and client in PostHog, tied to the client name, not to a person. An RSVP made through an assistant is stored like one made on the site, marked as coming from an assistant, and gets the same emails. Links returned to assistants carry utm_source=mcp, so a visit that starts in an assistant is counted as such.
Listings come from organizers’ and venues’ public pages, city calendars, operator schedules and the submit form, as the About page describes. The submit form stores the title, date, venue, source link and summary you enter, your email and the page you submitted from — no IP address and no user-agent — and emails the same to us. A person reads it; it goes nowhere until a curator moves it by hand.
Organizer outreach — an email offering the “Featured on Stumblday” badge to organizers whose events rank near the top of a board — goes only to an address already written in the listing’s own text or given in that organizer’s own submission; we never fetch a page to find one, never write twice about the same event, never more than once in 14 days to the same address, and every message says how to be removed.
The board data — each pick’s title, dates, venue, price, link and summary — is published under the Creative Commons Attribution 4.0 International (CC BY 4.0); the terms are on the open-data page. Images are organizer-supplied or licensed stock, openly licensed photographs credited on the event page, ticketing-API artwork shown beside its ticket link, or illustrative art generated by Stumblday; none of them is made from anything about you.
Stumblday is not directed to children under 13 and we do not knowingly collect personal information from them. If you believe a child has given us an address, email bryan@stumblday.com and we will delete it.
When this policy changes, the new version is posted here with a new effective date. The Terms of Use are a separate page and carry the same effective date.
Stumblday is published by Creamsicle, LLC, a New York company. Privacy questions and deletion requests: bryan@stumblday.com.