I’ve always wanted to create a proper preference center for my newsletter subscribers. A preference center isn’t just a nice-to-have; it’s how you show subscribers you respect their choices and time. Whether it’s letting them unsubscribe easily or tailor how often they hear from you, it’s key to building trust. My first attempt was what I’d call “hacky”—using Tally with a custom domain. It worked, but just barely. I found myself doing manual CSV updates more often than I’d like to admit because the automations I built kept tripping up. It wasn’t exactly the seamless experience I wanted to provide my subscribers!
⚡️ Why Build
When you’re running multiple newsletters, giving subscribers control over what they receive is crucial. The tipping point? Spending hours wrestling with manual updates for something that should have been automated. I realized I wasn’t just wasting time—I was delivering a clunky experience to my subscribers. That wasn’t fair to them or me.
As someone who loves automation and respecting user choices, I knew I needed something better. I wanted to build a system that felt effortless for subscribers while saving me from the frustration of constant fixes and manual tweaks. That’s when I decided to create a proper, user-friendly preference center that puts subscribers in control.
🛠️ The Current System
The solution I build this morning is much more sophisticated (though still not perfect - more on that later!). When someone subscribes to my newsletter, they get two forms of identification:
- Their MailerLite ID handles email delivery and subscription status
- A Supabase User ID lives in my custom database
These IDs work as tokens when subscribers want to update their preferences. When someone subscribes through a form, they're automatically added to both MailerLite and my Supabase database then a group and newsletter based on the form. Every newsletter includes a unique URL at the bottom that's specific to each subscriber. When they click it, they land on their personal preference center where they can subscribe to additional newsletters or unsubscribe from all.
💡 Airtable vs Supabase
Here's something interesting - I actually built two versions of this system. One uses Supabase and the other uses Airtable. I love the Supabase version, but if you are on the free plan, you have a max of 3 projects, and you can surely use the free tier for a more robust or larger project/application.
Airtable works well because each subscriber automatically gets a unique record ID just like Supabase, which works perfectly as their token. While I could have used only MailerLite IDs, I ran into some API challenges that made Airtable and Supabase's solution easier to implement.
🔒 Security Considerations
Is this the Fort Knox of preference centers? Not quite, but it’s secure enough for its purpose. The unique URLs tied to specific IDs mean only the intended user can access their settings—unless the link is forwarded or intercepted. That’s a known limitation, and it’s why version 2.0 is going to include token-based authentication with time-sensitive, single-use tokens, similar to magic links.
Here’s the thing: magic links and token-based URLs are pretty much the same at their core. Both embed a token in the URL that acts as a temporary credential. The problem? If someone shares or intercepts the link, it’s game over. What makes magic links stand out is the added security they usually pack, like time-limited expiry, single-use validation, and contextual checks (e.g., IP or device verification). Without those extra layers, token-based URLs rely entirely on secrecy—which is a risk I’m determined to fix.
Version 2.0 is going to take this system up a notch. I’m working on adding:
- Short-lived tokens to limit the window of opportunity for misuse.
- Single-use links so a token is immediately invalidated after it’s used.
- Contextual verification, like checking the user’s IP or device, to make sure the link is being used by the right person.
- For highly sensitive actions, I’m exploring multi-factor authentication to add an extra layer of protection.
Oh, and everything is sent over HTTPS, so those tokens are safe during transmission. I’m also considering encrypting tokens directly in the URL to make them harder to exploit if exposed. The goal? To strike the perfect balance between strong security and a smooth user experience—because nobody likes systems that make them jump through hoops just to update their preferences.
🎯 Why This Matters
Here's what really drives me: respect for subscribers. Sometimes people hit 'unsubscribe' not because they don't want to hear from you at all, but because they're getting too many emails or content that's not quite right for them. By giving them control over frequency and content preferences, I'm hoping to build better relationships with my readers.
🚀 Newsletter Preference Center v2.0 Plans
I'm excited about some major improvements coming up:
- Time-based authentication (implemented carefully with user experience in mind)
- Options for subscribers to adjust email frequency
- Better ways to update interests and preferences
- Enhanced security without adding friction
I've already built and tested the time-based system but held back on implementing it until I can make the user experience smoother. The goal is to let subscribers have more control while maintaining security.
The next version will also give users more granular control over their subscriptions. Instead of a simple subscribe/unsubscribe option, they'll be able to:
- Choose how often they receive emails
- Select which topics interest them most
- Manage multiple newsletter subscriptions easily
- Pause subscriptions temporarily
🎓 Key Learnings in Building a Newsletter Preference Center
Building this system taught me some valuable lessons:
1. Sometimes the simpler solution (Airtable) beats the more sophisticated one (Supabase)
2. Security and user experience don't have to be at odds
3. Giving users more control often prevents total unsubscribes
💫 What's Next?
While I'm proud of how far this system has come from my initial Tally hack, there's always room for improvement. I'm constantly gathering feedback and making tweaks to make it even better.
Want to see how I implemented this? Have thoughts on newsletter preference centers? I'd love to hear your experiences or help you avoid some of the pitfalls I encountered along the way!
P.S. I’ve stopped collecting first and last names entirely, so this might feel like overkill. Now, the only data I retain is the user’s email address and their preferences. While personalizing newsletters with names can be a nice touch, I realized it’s unnecessary for most cases. If I ever want to personalize an email, I prefer sending a direct, one-on-one message instead of including it in a mass newsletter.
I’ve always wanted to create a proper preference center for my newsletter subscribers. A preference center isn’t just a nice-to-have; it’s how you show subscribers you respect their choices and time. Whether it’s letting them unsubscribe easily or tailor how often they hear from you, it’s key to building trust. My first attempt was what I’d call “hacky”—using Tally with a custom domain. It worked, but just barely. I found myself doing manual CSV updates more often than I’d like to admit because the automations I built kept tripping up. It wasn’t exactly the seamless experience I wanted to provide my subscribers!
⚡️ Why Build
When you’re running multiple newsletters, giving subscribers control over what they receive is crucial. The tipping point? Spending hours wrestling with manual updates for something that should have been automated. I realized I wasn’t just wasting time—I was delivering a clunky experience to my subscribers. That wasn’t fair to them or me.
As someone who loves automation and respecting user choices, I knew I needed something better. I wanted to build a system that felt effortless for subscribers while saving me from the frustration of constant fixes and manual tweaks. That’s when I decided to create a proper, user-friendly preference center that puts subscribers in control.
🛠️ The Current System
The solution I build this morning is much more sophisticated (though still not perfect - more on that later!). When someone subscribes to my newsletter, they get two forms of identification:
- Their MailerLite ID handles email delivery and subscription status
- A Supabase User ID lives in my custom database
These IDs work as tokens when subscribers want to update their preferences. When someone subscribes through a form, they're automatically added to both MailerLite and my Supabase database then a group and newsletter based on the form. Every newsletter includes a unique URL at the bottom that's specific to each subscriber. When they click it, they land on their personal preference center where they can subscribe to additional newsletters or unsubscribe from all.
💡 Airtable vs Supabase
Here's something interesting - I actually built two versions of this system. One uses Supabase and the other uses Airtable. I love the Supabase version, but if you are on the free plan, you have a max of 3 projects, and you can surely use the free tier for a more robust or larger project/application.
Airtable works well because each subscriber automatically gets a unique record ID just like Supabase, which works perfectly as their token. While I could have used only MailerLite IDs, I ran into some API challenges that made Airtable and Supabase's solution easier to implement.
🔒 Security Considerations
Is this the Fort Knox of preference centers? Not quite, but it’s secure enough for its purpose. The unique URLs tied to specific IDs mean only the intended user can access their settings—unless the link is forwarded or intercepted. That’s a known limitation, and it’s why version 2.0 is going to include token-based authentication with time-sensitive, single-use tokens, similar to magic links.
Here’s the thing: magic links and token-based URLs are pretty much the same at their core. Both embed a token in the URL that acts as a temporary credential. The problem? If someone shares or intercepts the link, it’s game over. What makes magic links stand out is the added security they usually pack, like time-limited expiry, single-use validation, and contextual checks (e.g., IP or device verification). Without those extra layers, token-based URLs rely entirely on secrecy—which is a risk I’m determined to fix.
Version 2.0 is going to take this system up a notch. I’m working on adding:
- Short-lived tokens to limit the window of opportunity for misuse.
- Single-use links so a token is immediately invalidated after it’s used.
- Contextual verification, like checking the user’s IP or device, to make sure the link is being used by the right person.
- For highly sensitive actions, I’m exploring multi-factor authentication to add an extra layer of protection.
Oh, and everything is sent over HTTPS, so those tokens are safe during transmission. I’m also considering encrypting tokens directly in the URL to make them harder to exploit if exposed. The goal? To strike the perfect balance between strong security and a smooth user experience—because nobody likes systems that make them jump through hoops just to update their preferences.
🎯 Why This Matters
Here's what really drives me: respect for subscribers. Sometimes people hit 'unsubscribe' not because they don't want to hear from you at all, but because they're getting too many emails or content that's not quite right for them. By giving them control over frequency and content preferences, I'm hoping to build better relationships with my readers.
🚀 Newsletter Preference Center v2.0 Plans
I'm excited about some major improvements coming up:
- Time-based authentication (implemented carefully with user experience in mind)
- Options for subscribers to adjust email frequency
- Better ways to update interests and preferences
- Enhanced security without adding friction
I've already built and tested the time-based system but held back on implementing it until I can make the user experience smoother. The goal is to let subscribers have more control while maintaining security.
The next version will also give users more granular control over their subscriptions. Instead of a simple subscribe/unsubscribe option, they'll be able to:
- Choose how often they receive emails
- Select which topics interest them most
- Manage multiple newsletter subscriptions easily
- Pause subscriptions temporarily
🎓 Key Learnings in Building a Newsletter Preference Center
Building this system taught me some valuable lessons:
1. Sometimes the simpler solution (Airtable) beats the more sophisticated one (Supabase)
2. Security and user experience don't have to be at odds
3. Giving users more control often prevents total unsubscribes
💫 What's Next?
While I'm proud of how far this system has come from my initial Tally hack, there's always room for improvement. I'm constantly gathering feedback and making tweaks to make it even better.
Want to see how I implemented this? Have thoughts on newsletter preference centers? I'd love to hear your experiences or help you avoid some of the pitfalls I encountered along the way!
P.S. I’ve stopped collecting first and last names entirely, so this might feel like overkill. Now, the only data I retain is the user’s email address and their preferences. While personalizing newsletters with names can be a nice touch, I realized it’s unnecessary for most cases. If I ever want to personalize an email, I prefer sending a direct, one-on-one message instead of including it in a mass newsletter.
