What we collect, what we don't, and why.

We collect what we need to introduce a vetted companion to your family member: your contact info, your family member’s details, your visit history. We send transactional emails such as confirmations. When you join the waitlist, we also send waitlist availability and launch updates. Senior-living representatives can request a facility pilot; we collect business-contact and facility details, not resident information, at that stage. We don’t sell your data, ever. We use a small set of third-party services (auth, database, email, analytics) and we’re explicit about which below. You can delete your account by emailing us at hello@mypopover.com.

Popovers is a service operated by [Company entity name — to be confirmed]. Contact: hello@mypopover.com. This policy covers everything on mypopover.com and any future subdomains.

We collect different things depending on what you do on the site:

• Visitors: a session-stable visitor ID cookie (so our A/B tests stay consistent between page loads), first- and last-touch campaign details from known parameters such as UTMs and ad click IDs, plus aggregate analytics through Vercel Analytics. PostHog and Meta run only after you allow optional analytics and advertising.
• Waitlist signups:the email address you provide, the ZIP code of the person you’re booking for, the urgency answer (within a month / 1–3 months / just curious), the campaign source that brought you to us, and your email consent choice. Optionally a phone number, only if you’ve checked the SMS-consent box. We require you to confirm ownership through an emailed link; confirmation and unsubscribe tokens are stored only as one-way hashes.
• Abuse prevention: short-lived submission counters keyed by one-way, secret-keyed hashes of the email address and network address. We do not store the raw values in the rate-limit table.
• Facility pilot requests: organization name and type, your name, job title, work email, optional phone, facility city and state, approximate bed and resident counts, desired timeline, and campaign attribution. The form does not ask for resident names, diagnoses, or health information.
• Institutional prospects: facility name, address or market, public facility-directory details, and professional contact details for a relevant employee. Facility records come from government directories; professional contact information may be matched and verified through our configured sales-engagement provider. If a representative expresses interest, a private qualification form may collect the expected resident-group size, launch window, funding path, decision role, and operational business contact. It does not request resident identities or health information.
• Account holders (bookers):your name, email, password (stored as a one-way hash — we never see the plaintext), session cookie. Optionally phone number.
• Care recipient profiles:the older adult’s name, address, date of birth (optional), interests, mobility notes, and anything else you choose to share with companions.
• Companion applicants:name, email, phone, age, location, work-history references, why you’re applying, your availability summary. Once approved, additional info needed to deliver visits (background-check status, agreement signature, Stripe Connect account details for payouts).
• Bookings:who, where, when, optional notes, status history (pending, confirmed, cancelled, completed). Future: payment authorization details from Stripe (we don’t store card numbers ourselves).
• Booking notes: information a Booker adds to help a Companion prepare for a requested visit. If we add direct messaging later, this policy will be updated before that feature launches.

We don’t store payment card details on our servers (those go directly to Stripe). We don’t collect any health information beyond what you choose to put in optional “mobility notes.” Analytics and advertising measurement tools run only when their corresponding integrations are configured; they are described below.

• To match families with companions— searching, ranking, and connecting based on availability, location, and the activities the family chose.
• To run the visit— sharing the care recipient’s address and visit notes with the companion only after the booking is confirmed.
• To send transactional email— booking confirmations, applicant status updates, and password resets. Waitlist availability and launch updates are sent only after you check the email-consent box, and you can unsubscribe anytime.
• To discuss facility partnerships— responding to pilot requests and, where lawful, sending a limited business outreach sequence to relevant senior-living decision-makers with a working opt-out. We use delivery and response metadata to stop sequences, honor suppression, and route interested replies; we do not copy reply bodies into the Popovers database. A clearly interested reply may receive one automated transactional next-step email with a time-limited, signed qualification link.
• To pay companions— through Stripe Connect (Phase 5/7).
• To improve the site— reviewing aggregate analytics, running A/B tests on the waitlist landing variants via Statsig.
• To prevent abuse— identifying fake signups, repeat applications, or other patterns that suggest something other than honest use.

We use a small set of vendors to operate the service. Each receives only the data they need:

• Vercel— hosting + edge network + aggregate visitor analytics. Privacy: vercel.com/legal/privacy-policy.
• Neon (Postgres)— database for accounts, profiles, bookings. Privacy: neon.tech/privacy-policy.
• Better Auth— authentication library running on our own servers; sessions live in our Neon database. No data leaves to a Better Auth vendor.
• Resend— transactional email delivery. Privacy: resend.com/legal/privacy-policy.
• Cloudflare Turnstile— bot detection on public forms when configured. The browser receives a short-lived challenge token that our server validates with Cloudflare; the token is not used for advertising.
• Hunter— when configured, matching and verifying professional facility contacts and delivering the institutional outreach sequence from a connected business mailbox. Hunter also provides message status and reply classification metadata so we can process bounces, unsubscribes, and interested replies without storing reply content locally. Hunter is not used for family waitlist email or other transactional product mail. Privacy: hunter.io/privacy-policy.
• Sentry— error monitoring. It is inactive unless a Sentry project is configured and may receive technical request context when an application error occurs.
• Statsig— A/B test variant assignment after you allow analytics. We send an anonymous visitor ID; no PII. Privacy: statsig.com/privacy-policy.
• PostHog— optional product analytics such as page views, CTA interactions, form progress, and scroll depth. It runs only after you choose “Allow analytics & ads” and only when configured.
• Meta Pixel and Conversions API— optional advertising measurement and attribution. They run only after you choose “Allow analytics & ads” and only when configured. Conversion identifiers sent from our server are hashed where required by Meta.
• Stripe (Phase 5/7)— payments + companion payouts. Stripe holds card data directly; we never see it. Privacy: stripe.com/privacy.
• Checkr (Phase 3 follow-up)— background checks for companion applicants. Only used once an applicant has been approved at the interview stage and has consented. Privacy: checkr.com/privacy-policy.

We use a small number of necessary first-party cookies. PostHog and Meta storage is optional and remains off unless you select “Allow analytics & ads.” You can change that choice at any time using “Privacy choices” in the footer. We also honor a browser Global Privacy Control signal as a request to keep optional tracking off. Specifically:

• mp_visitor — a random ID set on first visit to keep A/B test variants consistent across page loads. HttpOnly, lasts a year.
• mp_attr_first and mp_attr_last — allow-listed campaign fields such as UTM source, campaign, ad content, click ID, landing path, and external referrer. HttpOnly, first-party, lasts up to 90 days. We do not store arbitrary URL parameters.
• mp_tracking_consent — remembers whether you allowed or declined optional analytics and advertising. First-party, lasts one year.
• Better Auth session— identifies you when you’re signed in. HttpOnly + secure, lasts until sign-out or the configured session expiry (30 days).
• Vercel analytics— aggregate page views and performance information.
• PostHog— after permission, stores a visitor identifier in browser storage so consented visits can be measured over time. Choosing necessary only opts out and disables that persistence.
• Meta Pixel— after permission, Meta may set browser identifiers used for advertising measurement. Choosing necessary only revokes Meta consent and removes the first-party Meta browser identifiers available to us.

We keep active waitlist signups until you unsubscribe, ask us to delete them, or the waitlist is no longer needed. After an unsubscribe, we keep a suppression record so we do not email you again unless you explicitly rejoin. Campaign attribution is retained with the signup for that same period. Hashed abuse counters are automatically deleted after seven days without a new attempt. Facility pilot requests are kept while we evaluate or operate the partnership and then for the period needed for business, legal, and dispute records. Professional outreach records are retained while the campaign is active, including delivery status and reply classification metadata but not reply bodies; opt-outs and suppression status are retained so we do not contact that address again. Account data persists until account deletion. Booking records persist for tax, dispute, and audit purposes (typically 7 years after the visit). Server logs that include IP addresses are kept up to 90 days.

You can ask us to do any of the following by emailing hello@mypopover.com:

• Get a copy of the data we have about you.
• Correct anything that’s wrong.
• Delete your account and associated data (booking history stays in our records for the retention period above, but we’ll redact it from any active views).
• Unsubscribe from any non-transactional email.
• Turn optional analytics and advertising on or off immediately through “Privacy choices” in the site footer.

Popovers isn’t designed for use by people under 18. We don’t knowingly collect data about minors. Care-recipient profiles describe an adult and are maintained by an adult booker.

When we materially change this policy, we’ll update the “last updated” date at the top and, for substantive changes, email account holders so you have a chance to read it.

Questions, requests, complaints: hello@mypopover.com.