Skip to content
Product Documentation

Server-side Paywall Best Practices

This document aims to provide our customers with a list of proposed do’s and don’t for enabling Server-Side Paywall (SSP).

For more information about the working of Server-Side Paywall, please read the How to Build a Server-side Paywall with Arc Subscriptions or an External System article.

How do I enable Server-Side Paywall?

Currently, SSP is a standardized offering, you will need to coordinate with your Technical Account Manager to get it added to your CDN/Delivery configuration.

Am I allowed to whitelist any user-agent or IP addresses ?

No, we don’t allow any whitelisting of user-agents or IP addresses to bypass the paywall. Please read below how you can effectively use the entitlements in order to address specific use-cases.

What are Entitlements/Variants?

Entitlements are a differentiated rendering of a customer’s site, driven by resolver query parameter matches. They do not map directly to a specific group of users on the internet, or a specific user state, but instead is the experience that a user is assigned to see when browsing the public site. Clients can describe their own qualifications or requirements for users to be assigned a specific experience as part of their identity system.

Variants is another term used to describe the entitlement set within a server-side paywall cookie, it describes the QSP(query string parameter) that entitlements are mapped to within PageBuilder Engine resolvers.

How many variants am I allowed?

Each client is allowed only two entitlements per site delivery configuration. Entitlements are limited in order to preserve cache performance at the edge. User segmentation and other QSP’s also impact cache and the combinations of these and entitlements can negatively impact performance.

What information do I need to provide to get SSP?

We need the following information from you:

For more information please contact your Technical Account Manager.

How do I use entitlements effectively?

Since an entitlement is an experience, look at how you are classifying users and determine where user experiences should be the same between user segments. For instance, do monthly subscribers see the same articles as a “gift” user? Do allow-listed organizations see the same articles as monthly subscribers? The client middleware/identity solution can then route these groupings of users into the same entitlement option.

Entitlements can also be changed on the fly in order to offer time-limited, or usage-limited experiences. Client-side tracking beacons or other methods to track user consumption can trigger changes to the entitlement value in their cookie. Guest users who sign up can get their entitlement set to a value that allows premium content, or full article loads. Then, after 10 article reads the cookie can be removed, or changed to a different entitlement number which provides a different experience.

Finally, using an entitlement as the default value for any visitor is not an effective implementation since in this configuration the resolver matching requests without the variant QSP will not be used. Entitlements should only be used to separate users who require an alternate experience out from the “standard” experience of a new or anonymous user.

The following diagram gives an example for using the SSP entitlements:

Using SSP Entitlements

What content is SSP applied to?

SSP can be applied per path to any content served by your PageBuilder Engine bundle.

What about search engine access?

When leveraging the server-side paywall outlined in this document, we recommend that the paywalled version of the article includes enough content to enable search engine crawlers to establish a decent understanding of the content. When using a hard paywall, the search engine read version should be the same as the non-logged-in (paywall version) the user sees.

Alternative approaches to allowing full article access to search engines, like requesting user agent whitelists or reverse DNS verification, open an easy-to-bypass backdoor or are technically not available within Arc’s CDN vendor.

What about Composer Preview?

Composer preview should be configured to use your Trident domain as the preview URL. Since these requests are processed directly by a resolver, a “variant= QSP” can be added to the URL format to allow the preview to show the desired entitlement.

How do I allow 3rd party access or crawlers?

Any partners or providers that need access to a specific experience will need to support using an SSP cookie to reach that experience.

Tips for managing expiration

The expiration value within the SSP cookie can be set to a different expiration value than the cookie itself. Since the redirect to a login portal only occurs when the entitlement expires, that value can be tweaked to provide the maximum time between login intervals. However, if modal login windows or other methods are used to authenticate users, the client should ensure that those silently re-set the SSP cookie to ensure the correct experience. Cookie expiration should be set to the longest time a user can be inactive and still be redirected to login.