EdgeKit Paywall
Paywall rules your revenue team writes, tests and ships
Meters, registration walls, offers and the tests between them, in one console instead of a developer's backlog. Write a rule, try it on any reader, publish it: live across your titles in 60 seconds.
Reader groups
- 1Everyone herereason: subscriptionOpen
- 1Free articles under 10 in the last 30 daysOpen· counts 1
- 2Everyone elseoffer: Digital AnnualSubscribe offer
- 1Gift link covers this articlereason: giftOpen
- 2Free articles under 3 this monthOpen· counts 1
- 3Everyone elseRegistration ask
The problem
A meter change should not wait for a sprint
Where the paywall is a vendor dashboard on top and a developer ticket underneath, raising the free count on one section, opening a story for a weekend or testing a softer registration ask each waits in someone else's queue. EdgeKit Paywall hands the whole decision to the people who own the number.
One decision, every title
Titles share one set of rules or run their own. Where they differ, it is a line in the rule, not a second copy to keep in step.
Every answer says why
Subscription, meter, registration, gift or upgrade: each decision names its reason, so your own analytics count registration asks and meter limits apart.
60 seconds
From publish to live, on every title the change covers.
How it works
Write it, try it, test it, ship it
Meters
Count reading the way your business counts it
A meter counts reading the way you do: every read or each article once, per device or per signed-in reader, across one title or all of them. Each rule sets its own limit and window.
- Rolling windows of 1 to 365 days, or a calendar day, week or month in your timezone
- When an anonymous reader signs in, their count carries over or starts again: your choice
- Three free for anonymous readers, ten once registered: two rules on one meter
- Counts
- Every readEach article once
- Per
- DeviceSigned-in readerGift link
- On sign-in
- Carry the count to their accountStart again
- Titles
- All titlesChoose titles
Read by
- Everyone else
- Signed in
Before you publish
See the answer before a reader does
Build any reader: signed in or not, subscribed or not, free articles used, title and section. The console shows which rule wins and what comes back, worked out by the same evaluator your pages call.
- Every fact a rule can read is a field you can set
- Unsaved edits preview straight away
- A rule hidden behind an earlier catch-all is flagged before you publish
The reader
- TitleMarkets Weekly
- Signed inYes
- SubscriptionNone
- Free articles used9 of 10 · last 30 days
- SectionMarkets
- Gift linkNo
The answer
Open the article
- Matched
- 2 · Signed in, rule 1
- Meter
- 9 → 10 of 10
- Reason
- meter
Next article from this reader: Subscribe offer
Tests
Test the meter, the ask or the offer
Split readers between versions of any rule: three free articles or five, a registration ask or an offer. A reader counts as seen only when a rule reading the test gives their answer, so readers it never touched stay out.
- Split per device, or per signed-in reader so the version follows them across devices
- Splits set to a tenth of a percent, and the same reader stays on the same side
- Who saw which version comes back with every decision, ready for your own event stream
- Split by
- DevicePer signed-in reader follows them across devices
- Who’s in
- Everyone else, on Markets Weekly
- Read by
- Article paywall · Everyone else · rule 2
- Counted as seen
- When that rule gives the answer
Each decision names the versionyour event stream
Publishing
Publish, and know exactly what shipped
Edits collect in a draft. Staging freezes it and runs the checks: a rule pointing at nothing, a loop, or an error path that would open the article stops the deploy. What passes is listed change by change before anyone presses Deploy.
- Publishing is its own permission: an editor can write rules without the right to ship them
- Every deploy is numbered, kept and names who shipped it
- One person edits a rule at a time, and a colleague can take over
Preview
staged by A. Novak 1 hour ago · 3 changesChecks passed · 0 blocking, 0 warnings
- Article paywallv4 → v5Behavioural
- Free articles meterv2 → v3Behavioural
- Offer “Digital Annual”renamedPresentational only
- #47ConfigurationJ. OkaforLive
- #46EdgeKit releaseConfig carried forward
- #45ConfigurationA. Novak
Capabilities
Everything a paywall decision needs
Rules read the reader
Sign-in state, subscription, membership level, days until access ends and how they joined, plus any score your own model writes back to the reader record.
Rules read the article
Section, story type or the access level set in your CMS, read from the page, decide alongside who is reading.
Every ask, not just the meter
A registration ask, an offer, an upgrade or a win-back is a rule like any other, written, tried and tested the same way.
Gift links
Subscribers share a story. Who may gift and how many a month is a rule. Each link opens on a set number of devices, then expires.
More than the paywall
The same engine answers any decision a page asks: hide ads for subscribers, show the newsletter prompt, pick the offer. One request, several answers.
A broken rule never opens the article
If something a rule needs cannot be read, the decision falls to an answer that gives no access, and the checks refuse to publish one that would.
Adoption
Live on one title first
Take Paywall on its own. It reads the sign-in you already run and leaves billing where it is.
White-glove onboarding: we set it up with you, start to finish.
- 01
Map your rules
Rules do not move between engines, so EdgeKit re-authors yours with your team, the exceptions nobody wrote down included.
- 02
Start with a script
The decision runs from a script on the pages you already render, so nothing sits in front of your pages and no traffic moves.
- 03
Withhold at the edge
When the article text should never reach the browser, your team deploys EdgeKit's site proxy, a Cloudflare Worker in front of the title, and one CSS selector names the text it holds back.
- 04
Hand over the console
From then on your team writes, tries and publishes, adding titles one at a time.
Fit
Beside your CMS, your login and your biller
Paywall answers a question your pages ask. What renders, signs in and bills stays yours.
Your design system
The decision is data. The panel is yours.
EdgeKit returns named fields (which outcome, why, the meter count, the copy key, the offer) and your own components draw the panel in your design system. No vendor iframe, no template language, no second design system to keep in step.
- Fields are generated as types per deployment, so a renamed field breaks your build, not your paywall
- A panel on any page shows developers what was asked and what came back
"article-paywall": { "outcome": "subscribe-offer", "type": "deny", "reason": "meter", "meters": { "free-articles": { "count": 10 } }, "value": { "copy": "markets-limit", "offer": "digital-annual" } }
Your CMS
Keeps rendering every page. The paywall only answers what the page asks.
Your login
Stays. A rule reads its membership claim on every decision, or a title moves to EdgeKit ID when you choose.
Your biller
Recurly stays. An outcome can name an offer, and checkout charges the Recurly account you already hold. Checkout on Stripe is not built yet.
Your test tool
EdgeKit runs the split itself today. Deciding the paywall on Statsig's own assignment is designed and not built yet.
Coming from another paywall? See the side-by-side with Piano, Zephr or Poool.
Questions
What revenue teams ask first
Does changing a rule need a developer?
No. Writing a rule, changing a meter, starting a test and publishing all happen in the console. A developer is needed to install the script and draw the panels your rules return, and again only when you want a new kind of panel.
Does the article text ever reach the browser?
Not once a title names its article body: the edge withholds the gated text before the page is sent. If the decision cannot be reached in time, the page is sent whole rather than taken down. Until a selector is set, or if you start with the script alone, the panel is drawn in the browser and the text is in the page source. We check the selector title by title before you rely on it.
Our readers sign in with our own login. Will the paywall know who subscribes?
Yes. EdgeKit verifies a token your login signs for it, or checks the session with your identity provider, and a rule reads its membership claim on every decision, so nobody signs in again. A title can move to EdgeKit ID later, or never.