Loading...
Loading...
Bi-weekly engineering deep dives on auth, notifications, and developer infrastructure. No spam.
Sign Up for UpdatesPublished by Zyphr
A user receives a marketing SMS at 2:00 PM while they’re deep in a focused coding session. It’s a discount code they don't want for a feature they don't use. Annoyed, they reply "STOP" or click the "Unsubscribe" link in the footer. If your system relies on a binary "Global Unsubscribe" flag, you’ve just lost the ability to send them critical security alerts, billing failures, or password resets via that channel. You didn't just lose a lead; you broke a vital lifecycle touchpoint. This friction often starts because you lack a dedicated subscriber preference center.
When that user’s credit card expires next month, your automated recovery emails will bounce against an "Unsubscribed" status. The user will churn without ever knowing why. This is the "Unsubscribe All" death spiral. It happens because developers often treat notification preferences as an afterthought—a single boolean column in a users table called is_unsubscribed. We do this because building a granular system is a chore. It involves writing hundreds of lines of boilerplate CRUD code to manage the intersections of channels (Email, SMS, Push) and topics (Billing, Security, Updates). You’re faced with a dilemma: ship a blunt instrument that drives churn, or spend a week of engineering sprints building a custom preference engine.
Most notification systems fail because they ignore the nuance of human communication. Users don't hate notifications; they hate irrelevant noise. The "Binary Trap" treats all communication as equal. In reality, a user might want "Security Alerts" via SMS for high urgency, but prefer "Product Updates" via a weekly Email, and "Social Interactions" only via an in-app notification strategy where they can engage on their own terms.
Fragmentation makes this worse. If your Auth provider handles email verification, your marketing tool handles newsletters, and your backend handles transactional SMS, your user’s preferences are likely scattered across three different databases. There is no single source of truth.
The Zyphr Subscriber Profile solves this by unifying identity and messaging. Instead of managing preferences across disparate vendors, you map a single subscriberId to a unified profile that tracks every channel and topic preference in one place. When you send a message, the system checks this profile automatically. If the user opted out of "Marketing" but kept "Security" on, the system enforces that logic without you writing a single if/else statement in your business logic. This shifts the burden of compliance and logic from your application to your infrastructure.
To build a system that lasts, you have to separate how you send (Channels) from what you send (Topics). A modern subscriber API reference should operate on a matrix rather than a list.
security, billing, marketing, and social.marketing topic, the system must check if both the Email channel and the Marketing topic are enabled for that specific subscriber.If you were to model this in a relational database yourself, you’d likely end up with a join table that grows exponentially: user_topic_channel_preferences. For 10,000 users, 5 topics, and 4 channels, that’s 200,000 rows to index and query every time you send a notification. Zyphr handles this state as a first-class citizen, allowing you to query the "effective" state of a user's preferences in a single millisecond-range API call.
For the frontend, Mantine is an excellent choice for internal tools and user settings dashboards. It provides accessible, unstyled components that handle the heavy lifting of state and keyboard navigation. We want a "Matrix" view where topics go on the Y-axis and channels go on the X-axis.
import { Table, Switch, Text, Stack, Group } from '@mantine/core';
interface Topic {
id: string;
label: string;
description: string;
channels: {
email: boolean;
sms: boolean;
push: boolean;
};
}
const PreferenceMatrix = ({ topics, onToggle }: { topics: Topic[], onToggle: any }) => {
return (
<Table verticalSpacing="md" withColumnBorders>
<thead>
<tr>
<th>Notification Type</th>
<th>Email</th>
<th>SMS</th>
<th>Push</th>
</tr>
</thead>
<tbody>
{topics.map((topic) => (
<tr key={topic.id}>
<td>
<Stack gap={0}>
<Text fw={500} size="sm">{topic.label}</Text>
<Text size="xs" c="dimmed">{topic.description}</Text>
</Stack>
</td>
<td>
<Switch
checked={topic.channels.email}
onChange={(e) => onToggle(topic.id, 'email', e.currentTarget.checked)}
/>
</td>
<td>
<Switch
checked={topic.channels.sms}
onChange={(e) => onToggle(topic.id, 'sms', e.currentTarget.checked)}
/>
</td>
<td>
<Switch
checked={topic.channels.push}
onChange={(e) => onToggle(topic.id, 'push', e.currentTarget.checked)}
/>
</td>
</tr>
))}
</tbody>
</Table>
);
};
This layout provides a clear visual map. By grouping these controls, you move away from the "Unsubscribe All" button as the primary interaction. You are offering the user a way to "Manage the Noise" rather than just muting your brand entirely.
The connection between your UI and the backend relies on the Zyphr SDK. Your subscriberId should match your internal userId to maintain consistency across your stack. When the component mounts, you fetch the current state from the API.
const fetchPreferences = async (subscriberId: string) => {
const { data, error } = await zyphr.subscribers.getPreferences(subscriberId);
if (error) throw new Error(error.message);
return data;
};
When a user toggles a switch, don't make them wait for a loading spinner. Use an "Optimistic UI" pattern: update the local state immediately and fire the API request in the background. If the request fails, roll back the UI and show a notification. This makes the interface feel responsive, which is critical when a user is already frustrated enough to be digging through their settings.
const togglePreference = async (topicId: string, channel: string, enabled: boolean) => {
// Update local state first
const originalState = [...localPrefs];
setLocalPrefs(current =>
current.map(t => t.id === topicId
? { ...t, channels: { ...t.channels, [channel]: enabled } }
: t
)
);
try {
await zyphr.subscribers.updatePreferences(subscriberId, {
topicId,
channel,
enabled
});
} catch (err) {
// Revert on server error
setLocalPrefs(originalState);
console.error("Sync failed", err);
}
};
A subscriber preference center is also a security layer. You shouldn't expose these settings via a public, unauthenticated URL. If an attacker knows a subscriberId, they could theoretically mute security alerts for a victim, making an account takeover harder to detect.
Always protect this route with your application's existing authentication or use Zyphr’s signed magic links for "one-click" preference management from emails. If you use the latter, ensure the token is short-lived and tied to a specific action.
Beyond security, you must account for "Transactional Fallback." Certain messages, like password reset requests or MFA codes, must bypass user preferences. In Zyphr, you can flag a template or a specific send request as transactional: true. This ensures that even if a user has opted out of every single topic, the message required to access their account still delivers. Use this flag carefully. If you use it for marketing content, you will destroy your deliverability and likely get your keys revoked by providers like SendGrid or Twilio.
The most difficult technical part of a subscriber preference center is handling the "Unsubscribe All" request while still allowing the user to opt back into specific things later.
When a user clicks a global unsubscribe link in an email, the law requires you to honor that opt-out quickly. However, the data model needs to reflect why they opted out. Did they opt out of the "Product Newsletter" topic, or did they opt out of the "Email" channel entirely?
If a user hits a global opt-out, Zyphr sets a global_unsubscribe flag on the subscriber profile. This acts as a circuit breaker. Even if the individual topic flags are set to true, the circuit breaker prevents any non-transactional message from going out. To re-engage, the user must explicitly flip that global switch back to on before their granular preferences become active again. This architecture prevents "accidental" resubscriptions where a user changes one small setting and suddenly gets hit with a backlog of marketing emails they thought they muted.
For applications sending millions of notifications, querying a preference API for every single message can introduce latency. You can optimize this by using a caching layer or edge functions.
If you use a system like Vercel or Cloudflare Workers, you can cache the subscriber’s preference object at the edge. When a user updates their preferences in your Mantine-based UI, you trigger a webhook that invalidates that specific edge cache. This ensures that your notification engine always has the latest data without doing a heavy database hit for every "Like" or "Comment" notification.
Zyphr provides outbound webhooks for this exact purpose. When subscribers.preferences.updated fires, you can update your own internal cache or sync the data to your marketing platform (like HubSpot or Braze). This keeps your entire ecosystem in sync.
Building the UI is only half the task. The real value comes from your communication strategy. If you currently have 30 different triggers firing at random intervals, your users are going to mute you.
Take an hour to audit your current triggers. Group them into four core topics:
Once these are defined, map your existing backend calls to include the topic parameter. By providing this level of control, you're not just checking a compliance box; you're building a relationship based on respect for the user's time and attention.
Ready to implement a better experience for your users? Create a free Zyphr account and start configuring your first topic categories today.