What we store.

If you have an account

• Your account: handle, display name, timezone, avatar, and the moment you accepted these terms.
• Your settings, including the language you chose.
• One row per signed-in device, so you can see and revoke them: device, browser, operating system, IP address, city, country, and when it was last seen.

accounts · account_settings · login_sessions (device, browser, os, ip, city, country)

The IP address on a login session is the one place we keep one. It is what lets you recognise a session that is not yours.

If you bought something from a creator here

You do not have an account: the link you were emailed is your identity. What is stored is what an order needs to exist and to be honoured.

• Your email and name on the order, with its receipt number.
• Your email in the creator’s contacts, with the country, when you were last seen, and whether you confirmed or unsubscribed.
• Your access rights to what you bought, keyed by your email.
• For a booking: your name, email, timezone, and any answer you gave to the creator’s intake question.

orders · contacts · entitlements · bookings · holds

The creator you bought from can see this. It is their shop, their customer, and their record of the sale.

What we count when someone visits a page

Opening a creator’s page here records one event, and so does tapping a link or a block on it. These events do not go to the database above: they are sent to Tinybird, an analytics service, and they live on its European workspace — Google Cloud, Frankfurt (gcp/europe-west3).

An event is stored without an IP address — there is no column for one. What it carries is the event name and when it happened, whose page it was, a country, a device category, a browser, an operating system, a language, and the domain of the site you came from. Never your name, your email, or the page’s address bar.

It also carries a daily visitor fingerprint: a one-way hash of the day, the creator’s account, your IP address and your browser’s user agent. The IP address and the user agent are used to compute it and are not kept. The hash is different for every creator and changes every day, so it cannot follow you from one day, or one creator, to the next. It is what makes ten refreshes count as one visit.

Submitting a creator’s signup form records one too, with the same country, device category, browser, operating system and language — read from your own request, as above.

A sale, a refund and a lost dispute also record an event there. Those carry the order and the product you bought, so the creator can see which product sold and when. They do not carry a country or a device: they are written by our payment provider’s server call, not by your browser, so we would have nothing true to put there. And they never carry your name or your email — the creator reads those from their own order records, not from here.

We keep these events for 13 months. After that the analytics database deletes them itself — it is the one thing here that expires on its own.

tinybird/datasources/evenements.datasource (ENGINE_TTL) · apps/web/lib/analytique/producteur.ts (evenementVueDePage, evenementClic, evenementLead, evenementPaiementGagne, evenementRemboursement, evenementLitigePerdu, hachageVisiteur) · apps/web/lib/analytique/profil.ts · apps/web/lib/analytique/retention.ts

The one cookie we set

dsid, and it is the only one the product sets of its own accord. It holds a single opaque identifier — no name, no email, nothing readable. It exists so a creator can see which link produced a sale.

• It lives for 7 days, and the row it points to stops attributing after the same 7 days.
• It is HttpOnly (no script on the page can read it), Secure (it never travels in clear), and SameSite=Lax.
• The row it points at holds the creator’s account, the click, the link and a referrer label. No personal data.

apps/web/proxy.ts · apps/web/lib/attribution/pose.ts (FENETRE_JOURS = 7, httpOnly, secure, sameSite lax) · attribution_sessions

If you sign in, your browser also holds a session cookie from our authentication provider. That one is what keeps you signed in; it is not analytics.

Google user data

This section is about the data we receive from Google when you sign in with Google or connect your Google Calendar. It is only collected if you choose to do either.

• Continue with Google — your Google account’s email address, to sign you in.
• Google Calendar, only if you connect it in Settings › Calendar:
  • the start and end times of busy periods on the calendars you choose to check — never the titles, descriptions, places or guests of your events — so that hours you are already busy are not offered on your booking page;
  • the list of your calendars (their names), so you can pick which ones are checked and where bookings are written;
  • the events of the bookings made with you on dropp.ing: we add, move and remove those events in your calendar, with a Google Meet link when you chose Meet. We do not read your other events.

What we keep: the email of the Google account you connected, the names of your calendars and which ones you checked, your calendar settings, an encrypted refresh token, and, for each booking, the identifier of the event we created. Busy times are read when they are needed and are not stored. Access tokens are never stored: they exist in memory for the duration of one request.

How it is protected.

• Everything travels encrypted (HTTPS / TLS) between your browser, our servers and Google.
• The refresh token is encrypted with AES-256-GCM before it is written, with a key that is kept outside the database.
• The Google connection is not readable from a browser, nor by any other account: no database access rule grants it, and only our server code reads it, with a key that never leaves our servers.
• The database itself is encrypted at rest by our database provider, Supabase.
• Only the access needed for the features above is requested from Google.

Removing access. Disconnecting in Settings › Calendar revokes our access at Google and deletes the connection, its encrypted token and your calendar list. You can also remove dropp.ing at any time from your Google Account’s permissions.

What we never do with it. Google user data is not sold, not used for advertising, and not shared with anyone, except what is needed to run the features above (the booking events go to your own Google Calendar) or what the law requires.

No AI or machine learning. dropp.ing does not use Google user data — raw, aggregated, anonymised or derived — to develop, improve or train generalised artificial intelligence or machine learning models, and does not transfer it to any third-party AI service. dropp.ing does not integrate any AI or machine learning service.

dropp.ing’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.

apps/web/lib/google/cles.ts (PORTEES: openid, email, calendar.freebusy, calendar.calendarlist.readonly, calendar.events) · apps/web/lib/google/secret.ts (AES-256-GCM) · apps/web/lib/google/connexion.ts (debrancher) · google_connections · watched_calendars

Instagram data (AutoDM)

This section is about the data we receive from Instagram when you connect an Instagram professional account to AutoDM. It is only collected if you choose to connect one.

• Your Instagram account: its ID, username, account type and profile picture link, and an encrypted access token with its expiry date and the permissions you granted.
• Comments and messages that match one of your automations: the comment or message ID, the post it was left on, the person’s Instagram-scoped ID and username, its text (the first 500 characters), what AutoDM did with it (sent, skipped or waiting), the IDs of the DM and public reply it sent, and when the link in the DM was opened. Comments and messages that match none of your automations are read and not kept.
• The posts you choose for an automation: their ID, caption, thumbnail link and date.

What it is used for. Only to run your automations: send the DM you wrote to the person who commented or messaged your keyword, post the public reply you wrote under their comment, and show you how many DMs were sent and opened. We never read your other messages, never write to anyone who did not comment or write to you first, and never post anything you did not write.

How it is protected. Everything travels encrypted (HTTPS / TLS). The access token is encrypted with AES-256-GCM before it is written, with a key kept outside the database. The Instagram tables are readable only by our server code: no database access rule grants them to a browser or to another account. The database itself is encrypted at rest by Supabase.

Removing access and deleting your data. Disconnecting the account in AutoDM deletes the connection and its token: no DM goes out in your name from then on. Removing dropp.ing in Instagram (Settings › Apps and websites) does the same. Asking for your data to be deleted from there deletes the connection, every comment and message recorded for that account, and the posts its automations kept; Instagram gives you a confirmation code. Your automations themselves are your settings and stay in your dropp.ing account until you delete them in AutoDM.

What we never do with it. Instagram data is not sold, not used for advertising, not shared with anyone except Meta (which delivers the DMs and replies), and not used to train any artificial intelligence or machine learning model.

apps/web/lib/instagram/cles.ts (PORTEES: instagram_business_basic, instagram_business_manage_comments, instagram_business_manage_messages) · apps/web/lib/instagram/secret.ts (AES-256-GCM) · instagram_connections · autodm_deliveries · social_posts

Who else receives data

• Supabase — the database, the sign-in, and the files creators upload. Everything above lives there.
• Stripe — payments. A buyer’s payment details go to Stripe and never to us: the payment is created on the creator’s own Stripe account.
• Vercel — hosting. It serves every request to dropp.ing.
• Tinybird — the audience counts described above. Every view of, and every tap on, a public page is sent there, and stays on its European workspace (Google Cloud, Frankfurt — gcp/europe-west3) for 13 months. No name, no email and no IP address travels with it.
• Resend — the transactional email we send: receipts, access links, password resets. It is the only mail sender in the code.
• Google — only if you choose “Continue with Google” to sign in, or connect your Google Calendar. See “Google user data” above.
• Meta (Instagram) — only if you connect Instagram to AutoDM: the DMs and replies your automations send go through Instagram’s API. See “Instagram data” above.

apps/web/lib/supabase · apps/web/lib/stripe · apps/web/lib/analytique/envoi.ts (api.tinybird.co) · apps/web/lib/emails/envoi.ts (api.resend.com) · apps/web/lib/supabase/google-signin.tsx · .github/workflows/dns.yml

How long we keep it

The audience events above expire on their own, 13 months after they were received. That number is written once in our code, and both this sentence and the analytics database read it from there, so the page and the database cannot end up saying two different things.

For everything else we would rather answer exactly than reassuringly: there is no automatic deletion today. No scheduled purge runs over the database. The 7-day window on attribution bounds how long a click can be credited with a sale; it does not delete the row.

Closing your account does not erase your data either, and the terms say exactly what it does instead. Orders, receipts and bookings are kept because they are your buyers’ records as much as yours.

Asking us about your data

There is no dedicated privacy address yet, and we will not print one that does not receive mail. Today the working channel is the report form — no account, no name required. Why this page says so.