Paywall

EdgeKit Paywall answers one question for each feature your site asks about: what does this user, or this anonymous device, get on this page? Your page or your server names the features. EdgeKit returns one outcome for each, and your site switches on the outcome’s id.

The parts

• Feature: one named decision. Your site asks for it by name, and it runs on the sites it names, or on every site when it names none. The paywall on an article is one feature. A subscribe banner or a newsletter prompt is another. You author features in Revenue › Decision Engine › Features. See Create and edit a feature.
• Outcome: what a feature returns. It has an id your page switches on, an optional access type (allow or deny), a reason, and optional typed fields your page renders. You author named outcomes in Revenue › Decision Engine › Outcomes. See Create an outcome.
• Meter: a count of reads a rule can test and add to, such as free articles in the last 30 days. You declare meters in Revenue › Decision Engine › Meters. See Set up a meter.
• Segment and experiment arm: named tests a rule can reuse. See Segments and Experiments.
• Fact: a value a rule tests, such as whether the user is signed in or which products their grants cover. Every fact a rule may test is listed in Revenue › Decision Engine › Facts.

A feature is made of canvases. A canvas has an entry, which says who it is for, an ordered list of rules, an outcome for everyone else who entered, and an error outcome. A rule is a set of conditions and the outcome it returns when they all hold.

How a decision is made

1. The request names a site and up to 32 features. The site must be active and in your newest deployment. See Select a site on a request.
2. EdgeKit works out who is asking. From a browser, that is the user the sign-in cookie names. From your server, it is the user your server names with its API key. At a site where users sign in only through your own identity provider, it is the user that identity provider’s credential names. With none of these, the request is from an anonymous device. Anonymous browsing never creates a user.
3. It reads the facts once for the whole request. Every feature in the request reads the same facts, so the order you name them in never changes an answer.
4. Each feature walks its canvases in order. The first canvas whose entry holds is entered, and entering commits: no later canvas runs for this request. Inside it:
   • the rules run in order, and the first rule whose conditions all hold returns its outcome;
   • if no rule holds, the canvas returns its outcome for everyone else;
   • if no rule holds and one of them could not be read, the canvas returns its error outcome instead.
5. If no canvas is entered, the feature returns its fallback. Every feature has one, so a feature always answers.
6. Meters are counted after every feature has its outcome. A meter moves only when the rule that won says so. Each meter moves at most once per request, however many features read it.
7. The response has one decision per feature. A name that is not deployed, is left out of the deployment or does not run on the site comes back in unknown instead.

See Ask for a decision for the request and the response.

Rules about entries and errors

• An entry says who the canvas is for. It may not read a meter or an experiment arm, directly or through a segment. Stage refuses a draft where one does.
• An entry that cannot be read does not hold. The canvas is not entered, and the next canvas is tried.
• A rule tests every condition. Its conditions are one AND. A group inside a rule combines its own tests with all of, any of or none of.
• The error outcome may not allow. When any outcome a feature can return is allow or deny, stage refuses a draft whose error outcome is allow. A fact that could not be read must never open the page.
• A winning rule’s outcome can also fail. If it carries a field filled from a fact that could not be read, the canvas returns its error outcome.

What a rule can read

Facts	What they say	When there is no value
user.state	anonymous, registered (signed in, no live grant) or paid (holds at least one live grant, however it was paid for)	anonymous
user.membership_level, user.membership_type	The slug of the highest-ranked product the user’s grants cover, and how that grant was sold	Empty
grants.product_ids, grants.site_ids, grants.expires_in_days	The products and sites the user’s live grants cover, and days until the longest one ends (0 for none, 36500 for no end date)	Empty, and 0
user_site.status, user_site.source	The user’s standing on this site	active and organic
device.token, request.new_device	The device cookie, and whether the request had none	Empty, and true
db_user_traits.complete	Whether the user has answered every required trait	Cannot be read when nobody is signed in, and on every request to /edgekit/v1/decide
gift_link.*	Whether the page URL carried a valid gift link for this page	false and empty. See Gift links
external.*	Claims from your own identity provider, at a site where users sign in only through it	Empty
profile.*, streaming.*	Values your organization’s profile and streaming inputs hold for the user on this site	The condition that tests it does not hold, and it never returns the error outcome
bot.*	The crawler verdict for the request	Cannot be read. On a site with no crawler verdict, which is every site unless EdgeKit sets one up, stage refuses a feature that reads one
item.*	Facts about one content item	Cannot be read: a decide request carries no content item

A rule cannot test a content fact your site signs for the page (signed.*, content.*): stage refuses a rule that names one.

A rule that tests a fact that cannot be read neither holds nor fails: the rule is unreadable, and if no rule wins, the canvas returns its error outcome.

Your page and your server can also send facts about the page in context. They arrive exactly as sent, anyone can set them, and the console’s rule builder does not offer them. See Ask for a decision.

Draft and deployed

What you save in the console is the draft. Requests are decided against your newest deployment, so a change to a feature, an outcome or a meter reaches your sites after the next deploy. See Stage and deploy a change.

Meter counts are not configuration. They are written as users read, and a deploy never resets them.

Who can change it

Owner, Admin and Developer can create, edit and delete features, outcomes and meters. Editor and Member can read them. See Who can change it.

Questions are answered in the Paywall FAQ, and refusals in Troubleshooting.