what we collect
- your email + a hashed password (or google oauth identity).
- the workspaces, links, destinations, and redirects you make.
- people who share their email and/or phone: email, phone (only if they gave one + ticked “ok to text or WhatsApp me”, used for SMS / WhatsApp), first name, a coarse country (country only, from the edge), how they opted in, + a raw IP/UA + timestamp at consent time. the raw IP is the GDPR proof-of-consent record: the one un-hashed IP we keep; it’s in every DSAR export and erased on request.
- analytics events: hashed IP, user-agent, geo, referrer. the original IP never leaves the cloudflare worker.
what we don't collect
- credit cards. stripe handles billing; we never see it.
- the contents of your DMs, emails, messages anywhere.
- your audience’s IPs in analytics: those are hashed at the edge; the raw IP never leaves the worker. (the one raw IP we keep is the consent record above.)
- data from third-party analytics tools you didn’t configure yourself.
who else processes it
cloudflare (edge + KV + custom-domain SSL), vercel (app + landing + marketing hosting), supabase (postgres + auth + storage), fly.io (background worker), upstash QStash (event ingest queue), postmark (email), anthropic (link scan + safety check), brave (scan web-search fallback), stripe (billing). retargeting pixels (meta / tiktok) only when a workspace enables them and the visitor consents. each is a standard, GDPR-aware provider.
on yala.la itself: our own meta pixel and google ads tag load only while we’re running paid campaigns (they’re off unless explicitly configured). when they’re on, the signup conversion we report carries at most a hashed email — never your links, catalog, or audience.
GDPR
Article 15 export and Article 17 erasure are real features, exposed both in the workspace admin and on the public API. see the help doc for the workflow.
contact
privacy questions: hi@yala.la. security disclosures: security@yala.la. we read every email.