A preference center for a small SaaS: three toggles, not one exit

Does a preference center replace one-click unsubscribe?#

No. Mailbox providers expect an unsubscribe mechanism that works in the mail client itself. Google's email sender guidelines require bulk senders of marketing and subscribed mail to support one-click unsubscribe through the List-Unsubscribe and List-Unsubscribe-Post headers and to honor requests within two days. The mechanism is defined in RFC 8058.

That one-click request is a POST to your server with no page, no login and no choices. So the design is:

1. The header one-click action means "unsubscribe from this kind of email, immediately." It never opens a form.
2. The footer link opens the preference center, where the person can go finer or leaner.
3. Both write to the same record, so a choice made in one place holds in the other.

The headers themselves are explained in one-click unsubscribe and RFC 8058. Decide up front what the header action means. Many small senders map it to the stream the email belonged to (a tips email unsubscribes the tips toggle) rather than to the whole list. Either choice is defensible if you state it on the page and apply it consistently.

How do you store preferences?#

Keep it boring. One table, one row per person, a few columns:

CREATE TABLE email_preferences (
  user_id        uuid PRIMARY KEY,
  product_news   boolean NOT NULL DEFAULT true,
  tips           boolean NOT NULL DEFAULT true,
  digest         boolean NOT NULL DEFAULT true,
  paused_until   timestamptz,
  all_marketing_off boolean NOT NULL DEFAULT false,
  updated_at     timestamptz NOT NULL DEFAULT now()
);

Then enforce it where mail is sent, not where mail is designed. Every marketing or lifecycle send goes through one function that checks all_marketing_off, paused_until and the toggle for that email's stream, and refuses to enqueue if any says no. If checks live in each campaign, one forgotten campaign will email someone who opted out.

Two details that bite later:

• Signed links, no login. The footer link should carry a signed, expiring token so the person can edit preferences without signing in. Someone who is leaving is the least likely to remember a password.
• Apply changes immediately. Check the stored value at send time, not when a campaign was scheduled. A person who opts out at noon should not receive the 3 p.m. email that was queued yesterday.

How do you know it is working?#

Watch three numbers for the first month, using your own sending data:

• The share of footer visits that end in a toggle change versus "unsubscribe from all."
• Spam complaint rate on each stream, which should not rise after you add the page. Google asks bulk senders to keep it low (it recommends staying below 0.10% in Postmaster Tools).
• Whether any stream is switched off by most people. That is a content problem, not a UI problem.

If nearly everyone switches off the digest, fix or drop the digest. The page is feedback, and ignoring it defeats the purpose.

Common mistakes#

• Sixteen checkboxes. Nobody reads them, and "select all" becomes "unsubscribe all."
• Making people log in. Every barrier pushes people toward the spam button.
• A "confirm your choice" email. It is one more message to someone who asked for fewer.
• Resubscribing silently. A product update or an import must never flip a toggle back on.
• Hiding unsubscribe-all. Put it on the same page, in plain words.

Bottom line#

Start with three toggles, a pause and an honest unsubscribe-all button. Keep account and security email out of the page entirely, keep the one-click header action separate from the page, and enforce preferences at send time in one place. If you send only one stream, skip the page and keep a clean unsubscribe link until a second stream exists.