Working with paywall optimisation is, in theory, an easy exercise. You need an offer and a design that is appealing to your readers and enables you to sell subscriptions.

In reality, when it comes to working with paywalls, understanding what works isn’t always as easy as it seems, and the devil is in the details.

Finding a starting point

At the beginning of 2024, we decided that we wanted to give working with our paywall another go. It had looked the same for quite some time, and we suspected there was untapped potential.

We formed a cross-functional team that included data science, UX design, tech, product, and business strategists.

To understand what gives impact, the process has to be methodical, so we all agreed we would only test one thing at a time. Together we stated everything we could think of to test and prioritised where to start.

In our first iterations, we improved our design and simplified our offer, which immediately gave results; our conversion increased by 24%.

This gave us a new baseline to work with. Encouraged by these initial wins, we began introducing greater complexity. We tested different price points, experimented with subscription durations, varied content packages, and implemented different design versions.

Eventually, our iterative testing led us to three highly effective paywall versions. But we quickly realised we had more winning variations than could practically be shown to a single user at once.

To tackle this complexity, we decided to build a dynamic paywall model.

How the dynamic paywall works

Our model serves the paywall variant most likely to convert an individual user, based on real-time behavioural data. The model could be described as a multi-armed bandit-based decision system selecting the best-performing paywall in different user contexts. A user context is a mix of features for users, such as referrer, login status and device type.

In our first iteration, the optimisation target for the dynamic model (a first-place winner at the INMA Global Media Awards in May) has simply been conversions. However, we see a broader potential moving forward: steering the model towards optimising for overall revenue. In the first step, this would only affect which paywall is shown, but as a second step, this should also include open or closed content.

To achieve this, the model will need to account for several factors:

• The specific revenue generated by each paywall variant, taking into account the expected customer lifetime value.
• The value derived from a reader who logs in.
• The monetary value of an article viewed without a login wall or paywall.

Today, SvD already employs a mix of premium and meter logic to determine open versus closed content. By integrating the meter with a dynamic paywall logic, it would allow us to optimise revenue along the entire user journey, meaning we can strategically balance openness and monetisation across all touchpoints.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .