Topics and Preferences
Every campaign carries a topic. Recipients opt out of topics rather than of everything, and the platform checks their preference before each individual send.
Where to find it
Architect Panel → Commercial:
- Campaign Manager — where a campaign’s topic is set
Architect Panel → Activity:
- E-mail Log — what was sent
- SMS Log — text sends
Why topics rather than one switch
An all-or-nothing opt-out forces a choice between everything and nothing, and people choose nothing. Somebody who wants their order confirmations but not the newsletter has one option, and you lose the ability to reach them at all.
Topics let them keep what they want. That is better for them and better for you.
Choose a small set of topics
Meaningful to the recipient, not to your internal structure. "Product updates", "Events", "Service notices" are topics somebody can make a decision about. "Campaign type 4" and "Marketing team B" are not.
Keep it short — a preference centre with fifteen checkboxes gets abandoned or unticked entirely.
Set a topic on every campaign
A campaign without one gives the recipient nothing meaningful to opt out of, and undermines the whole mechanism. Make it part of building a campaign, not an optional extra.
Preferences hold across every channel
This is the important behaviour, and it was a real bug once. A preference recorded through the preference centre is written to both the e-mail and the messaging preference stores.
Before that dual-write existed, somebody who opted out of a topic by e-mail was correctly refused by e-mail — and kept receiving the same topic by SMS, because the messaging side read a different store and never saw the opt-out.
As the code comment on the fix puts it: an opt-out that holds in one subsystem and not the other is worse than no preference centre, because the person has evidence they asked. That is exactly right, and it is why the two are kept in step.
Recording a preference is idempotent
Preferences are keyed on the tenant, channel, address and topic, so recording the same answer twice changes nothing and changing it back works through the same path. Somebody can opt out and opt back in without producing conflicting records.
Unsubscribe links are signed
The link in a message carries a signature, so it cannot be altered to unsubscribe somebody else. Recipients do not need to sign in to use it — which matters, because an unsubscribe requiring a login is one people will not complete, and they will report the message as spam instead.
Make unsubscribing easy
It is a legal requirement in most jurisdictions and, more practically, the alternative is worse. Somebody who cannot find the unsubscribe link marks the message as spam, and complaints damage deliverability for everybody on your list.
A prominent, working unsubscribe link protects your ability to reach everybody else.
Honour preferences everywhere
If somebody opts out of a topic, that must hold for any route that sends that topic — including anything you build yourself. The platform handles this for campaigns; custom code should check the same preference rather than sending directly.
Worked example
An organisation runs four topics. A customer opts out of "Events" through the preference centre and keeps the other three. A later events campaign — sent by SMS rather than e-mail — excludes them, because the preference was recorded against both channels when they set it.
Recommendations
- Set a topic on every campaign.
- Keep topics few and meaningful to the recipient.
- Make the unsubscribe link prominent.
- Check preferences in any custom sending code.