Preference center: letting users manage consent after the fact

What it's for

The cookie banner covers necessary/preferences/statistics/marketing — but most sites also track standing marketing preferences that live outside the banner's lifecycle entirely: newsletter subscriptions, SMS opt-ins, profiling consent, and similar. Dashboard → Privacy → Preferences is where you look up and edit a specific subject's standing preferences on their behalf — typically when they've emailed or called asking to be unsubscribed from something the banner itself doesn't govern.

This is the operator-facing side of the tool. It's for your team to act on a request; it isn't a public-facing self-service page a visitor lands on directly.

Step-by-step: looking up a subject

1. Go to Dashboard → Privacy, then switch to the Preferences tab.

2. In the Subject ID / email field, enter any identifier the subject is known by — email address, account ID, or any other reference your systems use internally. This is a free-text lookup key, not validated as an email format, so it works for whatever identifier scheme you actually use.

3. Click Look up (or press Enter in the field).

What happens next depends on whether a record already exists:

• Record found — the subject's current purposes load with their granted/denied state shown as toggles.

• No record found — a fresh set of purposes is prepared with every known purpose defaulted to denied, and a No record on file badge appears next to the subject's identifier, so you know you're creating a new record rather than editing an existing one. This isn't an error state — it's expected the first time you look up a subject who's never had preferences recorded.

The purpose set

Four purpose keys are recognized out of the box, with friendly labels shown in the UI:

If a subject's record contains any other purpose key (saved previously via the API, for instance), it still displays — just as the raw key rather than a friendly label, since the dashboard only ships translations for the four above.

Step-by-step: editing and saving

1. Once a subject's purposes are loaded, each renders as a row with a toggle switch — the purpose's friendly label (or raw key) on the left, the key itself shown in small monospace underneath for clarity, and the switch on the right.

2. Toggle any combination of purposes on or off.

3. Click Save preferences.

On save, the updated record replaces what was loaded, the No record on file badge clears (the subject now has a record), and a confirmation toast appears. There's no separate "cancel" — toggling and not saving simply discards your changes if you navigate away or look up a different subject.

What the data means

A preference record here is independent from consent-log entries. It doesn't carry a stamp, a region, or a hash-chain position — it's a simple current state per purpose per subject, meant to answer "is this person currently opted in to X," not "what did they decide and when, provably." If you need that stronger, timestamped, tamper-evident guarantee, that's what the consent log and signed receipts are for.

When to use this vs. the DSAR flow

• Preference center — routine, non-statutory "please update my marketing preferences" requests. It's a direct edit with no due-date tracking, no status workflow, and no regulatory paper trail — appropriate for the kind of request that doesn't rise to a formal legal ask.

• DSAR requests — a formal, regulation-backed access/deletion/rectification/portability request that needs an auditable due date, a status trail, and (for deletion) crypto-erasure of consent-log records rather than a preference toggle.

If you're ever unsure which applies: if the requester cited a law (GDPR, CCPA) or explicitly asked for deletion/export of "everything you have on me," treat it as a DSAR, not a preference update.

An important limitation

Saving a preference here changes the record of preference inside Cookie Munch — it does not, by itself, reach into your ESP, SMS provider, ad platform, or any other delivery system. If a subject asks to stop receiving marketing email and you flip email_marketing to denied here, that's the system of record updated; actually suppressing the next send is still your own automation's job (typically driven by syncing this record, or your own webhook-based integration, against those delivery systems).

Compliance value

Keeping standing preferences current — and centralized in one lookup tool rather than scattered across support tickets — is what lets you answer "did we honor this person's opt-out" with a record instead of a guess. It's a lighter-weight complement to DSAR, not a replacement for it, and pairing the two means every kind of consent-adjacent request a visitor might send you has a clear, appropriate home in the dashboard.

See also: DSAR requests · Consent log