EdgeKit Newsletters
Every sign-up is a reader, not just an address
The reader who signs up for your newsletter is the reader who registers and pays: one record, across every title. Your email platform keeps sending.
Why it matters
Your list knows an address. Your paywall knows a reader.
The newsletter is often how a reader first arrives, and the list rarely knows who later pays.
Two versions of one person
The list holds an address. The paywall and the billing system hold an account. Joining them is an export, a spreadsheet and a guess.
Unsubscribes that drift
A change made in one system is undone by the next import from the other, and someone keeps getting a newsletter they left.
A status, not a history
When a reader says they never signed up, the list can say they are subscribed. It cannot say when, or how.
What it does
One list of readers, kept in step with your email platform
Sign-up
A sign-up is a reader from the first address
Someone types an email into your newsletter box and EdgeKit creates their reader record, or finds the one they already have. When they register or buy a subscription with that address, it is the same record. Nothing to match, nothing to merge.
- One reader record per person, across every title you publish
- Readers signed in with EdgeKit ID subscribe without a confirmation email
- An address alone can add a newsletter, never remove one
Preferences
Every newsletter on one page, in your own design
Readers see every newsletter a title runs and choose in one place, on your own domain and in your own design. Every confirmed choice reaches your marketing stack, so the page and the list never disagree.
- A sign-up waiting for confirmation shows as pending, not ticked
- Readers only ever see newsletters you have published
- Names and descriptions change in the console, with no release
Sync
Your email platform sends. The list stays in step.
Every confirmed change reaches the matching subscription group in your marketing stack, and a late or repeated update never leaves it out of step. Unsubscribes made there come back. The Lists screen counts every change it has not received yet and puts those lists first.
- Unsubscribes from your marketing stack come back. A stale re-subscribe never does.
- A temporary failure is retried; one your marketing stack refuses is shown on screen, never dropped quietly
- Welcome series and win-backs stay in your marketing stack, where your CRM team builds them
Proof
Answer “I never signed up” with the record
Every change to a reader’s newsletters is kept and never overwritten: which list, what it became, when, and how — a browser form or preference page, your own server, an unsubscribe link or your marketing stack. When someone disputes a sign-up, the answer is a row in your own database, not a guess.
- Append-only: a correction is a new row, never an edit
- With Publications, every edition carries a one-click unsubscribe for its list
- Your marketing stack’s own reason is kept on every unsubscribe it reports
With EdgeKit Paywall
Send readers who registered but never paid to your newsletter
Add EdgeKit Paywall and a rule can send a registered reader who has bought nothing to your newsletter sign-up step, so the newsletter becomes the step between registering and paying.
- Your commercial team writes and changes the rule, with no release
- A published change is live in 60 seconds
Also in Newsletters
What a list owner asks about next
Double opt-in, per title
Switch it on and every address EdgeKit has not already proven gets a confirmation email naming the newsletter. Until confirmed it is pending and your marketing stack sends it nothing; signing up again sends a fresh link.
Consent kept apart
A newsletter sign-up never stands in for tracking consent, and tracking consent never puts anyone on a list. Each is recorded on its own.
Sign-ups from your own systems
Your own servers can sign readers up too. The record says the sign-up came from your server, and double opt-in still asks the reader to confirm.
Lists are never deleted
Disabling a list stops sign-ups and syncing; who joined, who left and when stays on record. A change your marketing stack has not yet received when you disable a list stays flagged on screen.
How it works
Four steps, and a working demo on your own site in a day
White-glove onboarding: we set it up with you, start to finish.
- 01
Create the list
In the console: the title it belongs to, a name and one sentence readers see, and the subscription group it mirrors in your marketing stack.
- 02
Publish it
A list goes live with your next publish. Until then it takes no sign-ups, so a half-made list never collects an address.
- 03
Add the form and the preference page
Your team builds both in your own design with EdgeKit’s browser SDK.
- 04
Keep sending as you do
Each change reaches your marketing stack and unsubscribes made there come back. Your campaigns and journeys do not move.
Fit
Beside the email platform and login you already run
Your email platform stays
It works with your marketing stack, and EdgeKit builds the connector at no charge if there is none yet. Your platform keeps every send; EdgeKit tells it who is on each list.
Your login can stay
A title that keeps its own sign-in still takes sign-ups and preferences. EdgeKit reads that login’s token and finds the reader behind it.
Add Publications when you want it
Newsletters decides who is on each list. EdgeKit Publications builds the edition from your CMS and sends it to that list.
Questions
What media groups ask about Newsletters
Do we have to change email platform?
No. Your platform keeps every send, segment and journey. EdgeKit tells your marketing stack who is on each list and hears back when someone unsubscribes there. If there is no connector for it yet, EdgeKit builds one at no charge.
Can we take Newsletters without the paywall?
Yes. It is adopted on its own and billed on its own meter: each person on a list counted once, however many newsletters and titles they are on. Sign-in, the paywall and subscriptions can follow later, on the same record.
We keep our own login. Does that matter?
No. A title that signs readers in through its own identity provider still takes sign-ups and preferences: EdgeKit reads that login’s token and finds the reader behind it. Anyone not signed in can still sign up with an address.
What happens when someone unsubscribes inside your marketing stack?
It comes back to the reader record, with your marketing stack’s own reason kept. Only unsubscribes travel that way, so an old update from it cannot put back someone who left. A global unsubscribe there takes the reader off every list.
Can one reader be on newsletters from several titles?
Yes. Each title’s newsletters are its own, and the reader is one record across all of them. Being known on one title never puts anyone on another title’s list.
What does our team build?
The sign-up form and the preference page, in your own design, with EdgeKit’s browser SDK: three calls cover listing, reading and saving a reader’s choices. No developers free? We are happy to build them with you.
How is Newsletters different from Publications?
Newsletters is who is on each list: sign-ups, preferences, unsubscribes and the sync with your email platform. Publications is what they receive: editions built from your CMS, scheduled and sent. Newsletters runs alone beside the campaigns you already send; Publications sends to Newsletters’ lists.