Privacy
Last updated 2 October 2026.
The short version
We store your email so you can sign in, whatever you build so you can come back to it, and a small amount of usage data so we know which parts of the product are worth improving. We do not sell anything to anyone, and we do not use your uploads to train a model.
Who we are
DnD Soundboard (dndsoundboard.com) is the controller of the personal data on this page: the party that decides why and how it is used.
- Name
- DnD Soundboard
- Chamber of Commerce (KvK) number
- 84956526
- VAT number
- NL863439391B01
What is public, and when
Nothing you make is public until you publish it. When you publish a board, these become visible to anyone: the board’s title, description and audio layers, your creator handle and display name, and the number of people who have adopted it. Your email address is never shown.
A board you keep as a draft or share by unlisted link is not listed in the gallery and is not submitted to search engines. An unlisted link is a secret, not a permission: anyone you give it to can pass it on.
Your account
Your email address, and the one-time codes we send to it. We use a passwordless sign-in, so we never store a password. If you subscribe, Stripe holds your payment details — we never see a card number and only store which plan you are on and when it renews. When a new subscription did not come through a member’s invite, we also check whether a member’s code was used on the payment page (see referral links below). While you are waiting for a sign-in code, your browser keeps your email address (and an invite code, if you typed one) for up to an hour, never the code itself, so a reload or a new tab does not lose your place; it stays on your device and is removed once you sign in.
You can also choose Continue with Google. Google then shares your name, email address and profile picture with us, with Google’s identifier for your account. We keep your email address to sign you in; our sign-in system (Supabase) stores the rest of what Google sent alongside it, and we do not use it for anything. Google never gives us your password or anything else from your Google account. If an account with the same email address already exists here, you are signed in to it. Google says that data from Sign in with Google is not used for ads.
Which Google button you see depends on the cookie question below. Where we do not have to ask you, or once you have said yes, the button comes from Google: on the sign-in and sign-up pages your browser loads it from Google, which tells Google your IP address and that one of those pages was opened, and it may show your name if you are signed in to Google — before you click it, nothing about you reaches us. As soon as the button loads, Google’s script stores one cookie on our site, g_state, for up to six months. In it Google keeps the state of its sign-in prompts in this browser and a random identifier for this browsing session (a new one after half an hour away), and its script may send it to Google when it draws the button. When you click, it may add a short-lived g_csrf_token cookie, which checks that Google’s answer comes back to the page that asked.
In the European Economic Area, the United Kingdom, Switzerland and the places that follow their cookie rules, until you say yes, and anywhere after a no, the button is our own and Google’s sign-in script is not loaded; if we cannot tell where you are, we treat it as one of those places. Nothing about the button reaches Google before you click it, and g_state is not set, not even when you click: the click takes you to Google’s own sign-in page, where Google’s own terms apply, and Google sends you back to us with its answer.
Whenever Google sends you back to us from its own page (always on an iPhone or iPad, and always after our own button), we hand Google’s answer to the next page in a cookie of our own, sb_g_cred, for at most two minutes, deleted as soon as it is read. Saying no below also deletes g_state. The button is not loaded on any other page.
Analytics cookies
Our own cookie, dnd_anon, holds a random identifier so we can tell a returning visitor from a new one. While you are signed in, the events we record also carry your account’s internal id, so a sign-up can be tied to the visits before it. It is not shared with anyone. We do use it to count which of our own ads led to a sign-up or a trial; that count stays in our own database and nothing about you goes to the advertiser. Events we record are things like “a scene was played” or “a search returned nothing” — that last one is how we decide what to record next. Each event also notes the kind of device (phone, tablet or computer), its operating system and the app it was opened in, such as Instagram, but never the device itself: no model, no screen size. It also notes which ad platform’s click identifier was on the link that brought you, if there was one (Google’s or Meta’s, say): the platform only, never the identifier itself.
We also use Google Analytics to see which pages people arrive on and where they give up. It sets its own cookies (_ga and_ga_*) holding a random identifier. Advertising storage is switched off for it, for everyone. When a first payment goes through (about a month after a trial starts), our server reports that payment to Google Analytics with your account’s internal id (never your email address), but only if analytics was on for you when you started the checkout and you have not turned it off since, in that browser or while signed in.
We advertise on Reddit, and their pixel tells us which of those ads led to a sign-up or a trial. It sets its own cookie (_rdt_uuid) holding a random identifier. We send Reddit the fact that a sign-up or a trial happened and nothing that identifies you — no email address, no name, no account id.
We also advertise in ChatGPT, and OpenAI’s pixel does the same job for those ads. It sets two cookies: __oppref, which remembers the ad click that brought you (30 days), and __obref, a random identifier (one year), and it remembers your yes or no for itself in __oaiq_consent. We send OpenAI the same two facts, that a sign-up or a trial happened, and nothing that identifies you: its option to pick email addresses out of the forms on a page is blocked by our site, whatever the setting says.
In the EU, the UK and Switzerland none of them runs unless you say yes. Google Analytics loads without storing anything until then, so as long as you have not said yes it receives requests with no identifier in them; the ad pixels are not loaded at all. Everywhere else they are on by default and you can turn them off below. That deletes the cookies they set, stops the ad pixels and leaves Google Analytics with requests that carry no identifier, though a measurement already sent cannot be recalled. Either way the site behaves identically, apart from how the Google sign-in button works (see your account above). The invite cookie of the referral program is separate and has its own question: see referral links below.
Reports and moderation
If you report a board we store what you reported, why, and whether you were signed in — visible only to us, and never to the person you reported. You can report without an account.
When we act on a board we keep a record of the decision. That record identifies the affected creator by a one-way hash rather than by their account, so it still works for counting repeat problems after an account is deleted, and it stops being linkable to a person at that point. We delete these records after 24 months.
When you publish with your own audio
We record which version of the rights confirmation you agreed to and when. If you are asked about a track later, that record is what lets us answer accurately rather than guess.
Referral links
If you open someone’s referral link (dndsoundboard.com/r/…) while signed out, we count the visit for the member whose link it was: one row per visitor per day, with your country and whether it led to a sign-up. To count you only once that day we use a keyed one-way hash of your IP address and browser that changes every day. It is a pseudonym, not an anonymous value: we hold the key, so we could match it to an address we already had. We delete it once its day is over (UTC). Your IP address itself is not stored.
The invite cookie, dnd_ref, remembers the invite so the member can be credited if you sign up later. It holds the member’s code and the time you first opened the link, signed so it cannot be altered. It lasts 60 days, cannot be read by the page’s scripts (httpOnly), is never replaced by a later link, and is not used for analytics or advertising. In the European Economic Area, the United Kingdom, Switzerland and the places that follow their cookie rules, and whenever we cannot tell where you are, we set it only if you choose “Remember invite” on the page; until then the code stays in the open page only, and is gone when you reload or close it. Elsewhere we set it when you open the link. You can remove it at any time with “Forget invite”: on the invite card, on the sign-up form, or in the cookie settings above. (An earlier version of the site also set dnd_ref_p, a flag with no data in it; “Forget invite” removes that too.) Instead of the cookie, you can also type the member’s code when you sign up, or enter it on the payment page when you subscribe (“Add promotion code”).
If you then create an account through a member’s invite, the sign-up form tells you so and lets you choose “Don’t credit anyone”. If you go ahead, we record which member your account came through, when, whether through a link, a code typed at sign-up or a code entered on the payment page, which of the member’s codes it was, the extra month you were offered, and how far it has got since: a trial, what you have paid for Adventurer, refunds and payment disputes. To stop people referring themselves we also keep a keyed one-way hash (a pseudonym) of your normalised email address and of the IP address you signed up from, and the fingerprint Stripe gives your card — an identifier of the card, never its number — with its type (credit, debit or prepaid). The address hash is compared with the member’s own; your email hash and your card with the member’s own and with every other referral, through anyone’s link. A match does not refuse anything: it holds the referral for a person to review.
If you enter a member’s code on the payment page, Stripe tells us which code your subscription used. To find these, we look at every DnD Soundboard subscription started or changed in the last 35 days on an account that is not already a member’s referral: once, or — while the answer is not yet clear, for example because your email address is not confirmed yet or the program is paused — again every hour for up to 2 days. Stripe sends us the subscriptions on your Stripe customer record, including any for our other products, with their discounts. We use only the DnD Soundboard ones, and read whether one used a member’s code, what that code took off, and when each started, which tells us whether this is your first DnD Soundboard subscription. We keep a note that we looked — the subscription, what we found and when — for 75 days. If it used a member’s code, and this is your first DnD Soundboard subscription, your account becomes that member’s referral, recorded as above, and the member is not told who you are.
What the member sees: counts — visitors, accounts, trials, paid, counted — and a list of their referrals as “Friend #4 · paid · counts on 12 November”. Never your name or your email address, and never why a referral stopped counting (a refund, a payment dispute or a review all read the same: “did not count”). If they invited only you, they can work out that the friend on their list is you. If you do not want that, choose “Don’t credit anyone” when you sign up (on the payment page: do not enter their code), or object later (below). Choosing “Don’t credit anyone”, or not entering their code, also gives up the invite’s extra month: it comes with the referral.
If you are the member, we store your code, the version of the program terms you accepted and when, that you confirmed you are 18 or over, a keyed hash of the IP address you last used the program from (for the same self-referral check), your credit, rewards and payouts, and which emails about them we have sent. For the same check we read from Stripe the cards you pay with, for any subscription on your account including our other products, and compare them with your friends’ cards.
Your codes. We store the codes you create next to the one we give you, with when each was created, approved or retired, by whom, and the reason when we turn one down; a code you choose can be your own name, so treat it as public once you share it. So that your codes work on the payment page, we register each one with Stripe as a promotion code: Stripe gets the code and our internal id for it, never your name, email address or account.
Payouts. To be paid out you open an account with Stripe Connect. We send Stripe your email address, the country you choose and our internal id for your account. Stripe checks your identity and holds your bank details as a controller in its own right, under its own terms. If you already have a Stripe payout account with us from another of our products that is ready to receive payouts, we use that one. We keep the Stripe account id and its country, and we re-read the account from Stripe at least once a day to keep what we need to pay you safely: whether it can receive payouts, whether Stripe needs something from you or has turned it down, the business description on it, and whether its balance is below zero. When you ask for a payout we record the country and whether you take part as a private individual or a business.
Free years and VAT. When you take a free year we record which country you live in and how we know it: your billing and card country from Stripe, or the country you choose plus the country of your connection. VAT on the year depends on it. We do not ask for your address, date of birth or citizen service number. If a law turns out to require us to report rewards to a tax authority, we will tell you, and ask only for what that report needs.
Why we may do this. Running your membership, your codes (registering them with Stripe included), your rewards and your payouts is our contract with you (GDPR art. 6(1)(b)). Counting link visits, recording which member a friend’s account came through, reading from Stripe which member’s code a new subscription used and showing the member each referral’s stage rest on our and the member’s legitimate interest in paying rewards to the right person for the right sign-ups (art. 6(1)(f)). The email and IP hashes, the card fingerprints, the card comparisons and the daily check of payout accounts rest on our legitimate interest in stopping people from referring themselves or inventing friends, and in not paying out on fraud (art. 6(1)(f)). Payout records and the VAT records of free years are kept because tax law requires it (art. 6(1)(c)). Where we ask before setting the invite cookie, it is set with your consent, which you can withdraw with “Forget invite”.
Your right to object. You can object at any time to what we do on the basis of legitimate interest — counting your visit, crediting a member for your sign-up, the fraud checks — by writing to contact@dndsoundboard.com. At sign-up you can simply choose “Don’t credit anyone” (the invite’s extra month goes with it). We then stop, unless we have compelling reasons to carry on that outweigh yours, such as a fraud check on a referral that has already earned a reward.
How long we keep things
Your account and your scenes: until you delete them. Share links: 30 days. Scene-builder descriptions: 180 days. Moderation records: 24 months. Analytics events: while they are useful to the product.
Referral links: the per-visitor hash is deleted at the end of its day (UTC), and visit rows after 13 months. A referral record lasts as long as the member’s account. If the referred friend deletes theirs, the record stays for the member’s count but is no longer linked to their account. Until that referral is over — voided, or past its chargeback watch — it keeps the friend’s Stripe customer id and sign-up IP hash, so a chargeback on what was paid is still seen; then those are erased. For 24 months after the deletion it keeps the email hash and the card fingerprint, so that a later sign-up through anyone’s link with the same email address, or paid for with the same card, is held for review; then those are erased too.
Referral codes: a member’s codes last as long as their account. Once the account is deleted, each code is deleted when it has been out of use for 13 months; until then nobody else can take over a code still printed in old posts and videos, except that we may move a code that uses another person’s or a brand’s name to the member it names (terms, “Names that are not yours”). The note that we looked at a new subscription for a member’s code: 75 days.
Payout records: 7 years, for bookkeeping, even after the account that asked for the payout is deleted. VAT records of free years (the country and how we established it): 10 years, as tax law requires, also after the account is deleted. Credit: if you ask us to delete your account while you hold credit, we first offer to pay it out or turn it into a free year; credit you decline is deleted with the account.
Deleting your account deletes your scenes, your uploads and the audio files behind them. Boards other people adopted became copies in their libraries at the moment they adopted them, and those copies stay with them — we cannot reach into someone else’s library, and we said so in the terms before you published.
Who else touches it
Supabase (database, files and sign-in), Vercel (hosting), Stripe (payments, the promotion codes that make members’ referral codes work on the payment page, and Stripe Connect for referral payouts), Resend (email), Google (Analytics, and sign-in if you choose Continue with Google), and Reddit and OpenAI (their ad pixels — all see above). For the identity checks and bank details of payout accounts, Stripe is a controller in its own right. The scene builder sends the sentence you type to a third-party AI provider to turn it into search terms — that is disclosed at the point you use it, and the manual builder never calls it.
These are US companies, so your data can reach the United States. Where it does, that happens under the EU–US Data Privacy Framework for companies certified under it, and otherwise under the European Commission’s standard contractual clauses. Our database and files are stored in the EU (Paris).
Scene pictures: a picture you upload is re-encoded (its camera and location metadata are removed) and stored with Supabase. It is shown only to you inside the app and never appears in rooms, boards or anyone else’s library, but the file itself sits at a long, unlisted web address, so anyone you give that address to can open it. Remove the picture and the file is deleted from storage.
Your rights, and how to use them
You can ask for a copy of what we hold, ask us to correct it or delete it, ask us to limit what we do with it, ask for it in a form you can take elsewhere, and object to what we do on the basis of legitimate interest (see referral links above). Email contact@dndsoundboard.com and a person will answer. Marketing email has a one-click unsubscribe in every message and you never have to ask us for that.
If you think we handle your data wrongly, you can complain to the Dutch data protection authority, the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl), or to the one in the country where you live.