Sign in to StumbldaySave events, keep your own calendar in sync, and follow organizers.
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 October 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: select Turn optional analytics off (the same as adding ?analytics=off to a Stumblday 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. Turn optional analytics back on reverses the choice.
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.
“I’m going” marks and the plan bar live in your browser’s local storage. Saved events and follows also live there, and are kept for this browser on our server too (see Your events). 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 and how you answered them, the days this browser visited (the last 30) and whether you have seen, dismissed or answered the survey, 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 at most four cookies: the analytics opt-out cookie if you opt out, the account cookie once you confirm an email or sign in, the device cookie described under Your events once you save or follow something, and an experiment cookie (sd_fv, about a year) that holds only a random id so a design test shows you the same version on every visit (it is never set for automated crawlers, holds no personal data, and goes away with your site data); 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.
Your events collects the events you save and the calendars, venues, artists and lists you follow (by following, turning on email alerts or adding one to your phone calendar). If you are not signed in, we keep these for your browser on our server: each saved event or followed calendar, how you added it and the page you were on, keyed to a random id in a first-party cookie (sd_dev, HttpOnly, about 13 months). The cookie holds only that id and a signature, never an email address. It is set only when you save or follow something, not when you merely visit, and requests from automated crawlers never create these records. When you sign in or confirm an email on that browser, its saved events and follows move into your account and the browser’s records are deleted. “Forget this device” on Your events deletes them and the cookie without signing in.
Signed in, the same things are kept on your account instead. “Delete my data” in Your events removes them, along with the records kept for the browser you use it from.
If you tap “Turn on notifications” (offered only after you save, follow or mark “I’m going”) and your browser asks and you allow it, we store what the browser gives us to reach that device: an unguessable push-service address and two encryption keys. Alongside them we store the ids of the events saved in that browser and the calendars it follows (so the morning-of reminder and the new-events digest know what to say), the city of the page you turned it on from, the kind of push service (Apple, Google, Mozilla or Microsoft) and which of the three kinds you want: reminders for your events, at most one daily digest of new events from calendars you follow, and updates from hosts of events you RSVP’d to. If this device is signed in, the row is linked to your account. Each notification we send is logged (its kind, when, and a short title) so nothing is sent twice. Notification text is encrypted end to end to your browser; the push service (Apple, Google, Mozilla or Microsoft) delivers it without being able to read it. Turn it off in Your events → Settings, with “Turn off on this device”, or in your browser’s site settings; turning it off deletes the row. Installing Stumblday to your Home Screen stores nothing on our side.
Forms are rate-limited by network address held briefly in memory; it is never stored.
Weekend Digest. Signing up stores your address, the page you signed up from, and which city’s digest you get. The city is the city of the page you signed up from — sign up on a Chicago page and you get Chicago’s weekend, not New York’s — and signing up again from a different city’s page moves you to that city. Each city’s digest goes out once a week, on Friday afternoon in that city’s own time, 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. As the line above the email box says, leaving an address there also adds it to the Weekend Digest list (one email a week, Friday afternoon in that city’s own time, unsubscribe link in every issue) — for the city the event you marked is in. The two are separate: cancelling a reminder does not unsubscribe you from the digest, and unsubscribing from the digest does not cancel a reminder. An address that has already unsubscribed from the digest is not re-added by an RSVP; RSVPs made through the AI connector before it became read-only (October 2026) never added an address to the digest.
Day-before reminders and “Your week”. When you save an event while signed in, you can tick “Remind me the day before”; we record that choice on the saved event and send one email the day before it starts. “Your week” is an email on Monday mornings that you turn on in Your events: it lists your saved and going events for the week, new events from calendars you follow and three picks, and is skipped on a week with nothing new. Both keep a record of when they were sent, and every one carries a one-click unsubscribe link.
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 for the city whose board you used it on.
Plans with friends. Creating an itinerary stores its title, date and selected public events on our server. Before you sign in, a separate editing key stays in your browser and only its hash is stored on our server. When you save the plan to your account, ownership is tied to that account. We store join requests, participation, votes and plan-change records. Participant names are visible to the organizer and confirmed participants; email addresses are not shared with the group. Unlisted plans can be read by anyone with their link. A separate invitation link lets its recipients join while joining is open. Publishing is optional: public plans and the organizer’s name appear in our plans directory and may be indexed by search engines. You can make your plan unlisted again, close joining, manage participants, or delete it; search engines may take time to remove previously indexed content. Plan updates appear on the plan page, not by email. Joining or creating a plan does not subscribe you to the newsletter.
Saturday plans. Creating a Chelsea afternoon stores its date, hours, neighborhood, admission preference and selected stops on our server. Each version has an unguessable read link: anyone you give that link can view that version. Swapping creates a new version, leaving earlier shared versions intact. We store a hash of a separate editing key; the key itself stays in the creating browser’s local storage, along with kept plan links. Keeping this plan also saves its events on this device. No email address, account or subscription is required. Clearing browser storage removes your editing key, but does not delete the server copy. To request deletion, contact us with the plan link.
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.
Survey. Visitors who have come back on another day, or through one of our own links, may see a short optional survey; it stores your answers, the page and city it was opened from, how many days this browser has visited and roughly where the visit came from, and, only if you type it into the optional box, an email we use solely to contact you about early access to Friday picks by text — the answers are never sent to analytics, only that the survey was shown, opened, dismissed or sent.
Organizers can make an event page on Stumblday (stumblday.com/e/…) that takes RSVPs. When you RSVP on one, we collect your name, your email address, how many people you are bringing and your answers to any questions the host added, and we share them with that event’s host, who can see and export the guest list. Across their own events, a host also sees how many of their events you RSVP’d to and attended (checked in), when you first and last RSVP’d, which of their invite links you came through, and any tags they add to you; this is never shared with other hosts. A host sees that you follow them only if you ticked the box to follow them on their RSVP form, or turned on “Let hosts of events I attend see my email” in Your events settings (off unless you turn it on), which also shows hosts whose calendars you follow your email before you RSVP. A host who runs a calendar can email its followers updates, which we review before they go out, either to every follower or, for an update aimed at part of their audience, only to followers who shared that they follow them; each has a one-click unsubscribe. Unless you have already confirmed your address on this device, we first email you once to confirm the RSVP; nothing else is sent until you do. We use your details to send your RSVP confirmation, waitlist and cancellation notices, a reminder on the day, and messages from the host about the event; we send follow emails about that host only if you tick the box to follow them and confirm. Every one of those emails has a link to change or cancel your RSVP and to stop emails about that event. We keep your RSVP until you ask us to delete it at bryan@stumblday.com.
Guest list, guest wall and photos. Your name appears on an event page only if you tick “Show me on the guest list”, and then only as your first name and last initial; your email is never shown. Confirmed guests and the hosts can post comments and photos on that event’s guest wall and, after the event, its photo album; only the event’s confirmed guests and hosts can see them, they are not indexed by search engines, and photo location data is removed. Before a post appears, its text and a smaller copy of any photo are checked automatically for spam and unsafe content, including by an AI model from Google (Gemini); the host can approve, hide or delete posts. You can delete your own posts. Wall and photo emails are sent only if you ask for them. If you share your personal invite link, we store a hashed browser id for each visit and each RSVP or save that comes through it, used only to count them, and show you and the host how many friends came.
Sharing “I’m going” with friends, or “Plan this 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. Answering an invite — I’m in, Maybe or Can’t — stores the answering browser’s device id, the answer and, if given, a first name; the older 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, how many people gave each answer, and the first name of each person who added one to their answer, as the box you type it in says. A name given with the older “I’m in”, which only promised to tell the inviter, is counted but never listed. 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.
If you sign up for Stumblday Text on stumblday.com/text, in the sign-up form on an event page, or on a picks page someone shared, you give us a US mobile number, your city (on an event page, the event’s city) and, on stumblday.com/text, up to three interests if you pick them. We text that number asking you to reply YES; only after YES do we send the texts: about one a week, on Thursday evening, with weekend picks, plus an answer to each text you send. We store the number, your city, your interests and what you tell us by text about what you like (for example “no comedy”, or rating a pick), the picks we sent you, when you signed up, which version of the sign-up wording you agreed to and where, when you replied YES, and, if you signed up through a friend’s link, their referral code. We keep the texts you send us and the texts we send you for 30 days, then delete them; the lists of picks we sent you are deleted after 120 days. We keep a record of your YES (when, and the message it answered) for as long as you are subscribed. A sign-up made before the texts start is kept until they do and then gets the one “reply YES” text; one still waiting after 30 days is never texted. To limit abuse of the sign-up form we keep, for 30 days, a salted one-way hash of the network address each sign-up came from, never the address itself. The “try it” chat on stumblday.com/text sends what you type there, your city and any interests you mention to Google’s Gemini AI service to answer from Stumblday’s listings; the conversation stays in your browser and we do not store it. To limit its use we keep, for 30 days, a salted one-way hash of your network address with each question, never the question itself. The number is used only to send Stumblday Text messages. It is never sold, rented or shared for marketing, never shown to anyone, never returned by any page or API, never written to our logs and never sent to analytics. Msg & data rates may apply. Reply STOP to cancel, HELP for help. The program’s terms are on the Stumblday Text terms page.
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.
Stumblday Text is deleted on a schedule: its messages (and the sign-up network hashes) 30 days after they were sent or received, its picks lists after 120 days. Nothing else is purged automatically. 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. A Stumblday Text number, its interests and its consent record are kept the same way; replying STOP marks the number unsubscribed rather than deleting it, so it is not texted again. 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.
Stumblday runs a connector (an MCP server at /mcp) that ChatGPT, Claude and similar assistants can call. Every tool only reads public listings and public calendars; none accepts an email address, phone number, name or account. A call carries only the tool’s arguments — a city, a date, an area, a category, a search phrase, a result count, an event or calendar slug or URL — plus the connector’s user-agent, used to label the client as ChatGPT, Claude or another, and its network address, which is used only to rate-limit calls 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 rate limiter that holds the network address for one minute and never writes it anywhere. Our server log keeps a search phrase with email addresses and phone numbers removed; phrases that arrive through the connector are not sent to PostHog. We record one anonymous count per tool and client in PostHog, tied to the client name, not to a person. Going to an event, following a calendar or adding an event to your calendar happens on stumblday.com or in your calendar app, when you open a link the assistant shows you; nothing you enter there passes through the connector. 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 event details you enter, your organizer name, contact email, optional photos and credits, and the page you submitted from — no IP address and no user-agent — and sends us a submission notification. Photos are resized and re-encoded without embedded metadata. A person reviews the submission before publication. When you sign in with a verified email, matching unclaimed submissions are connected to your account so you can review and update them. Your contact email stays private.
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 with their own effective date.
Stumblday is published by Creamsicle, LLC, a Delaware limited liability company based in New York. Privacy questions and deletion requests: bryan@stumblday.com.