Mugo Web main content.

Subscription-based sites: softer / combination paywall solution

By: Betsy Gamrat | November 13, 2014 | Business solutions and Case study

On subscription-based websites, digital publishers often restrict the majority of content to registered users and/or paid subscribers. However, publishers still need a way to enable non-registered users to sample the website in order for the visitors to more fully understand the benefits to subscribing. This is sometimes called a "softer" or "combination" paywall as opposed to a fully hard paywall (everything protected) or a "porous" paywall (everything available given the right conditions).

One solution for a softer / combination paywall that Mugo recently implemented uses special "hash" URLs to provide time-limited, full access to select articles.

There are many ways for non-registered users to discover articles on a website. For example, they could click a link from:

  • The homepage and/or other marketing pages
  • E-mail newsletters
  • Social media or other directly shared links

For the purposes of this blog post, we will presume that we want visitors to be able to read the entire article if they've clicked any of the above links.

For example, in this list of featured articles on a homepage, the first 2 articles might be publicly available, while the remaining 3 are behind the paywall.

Paywall: Featured article list

Whenever new articles are added to the list, they will push the top articles down -- once an article is no longer in one of the top 2 positions, it is no longer publicly available.

In order to allow access to the otherwise protected pages, we will append a time-sensitive hash to the linked URLs.  Without the hash, the user should be prompted to login or register.  The time-sensitive element makes it so that the hash URLs are only valid for a certain number of days -- configurable via a setting.

What is a hash?

hash is a string of characters that is created from information.  It is a simple encryption that allows the site to verify that the URL is valid.

The hash URLs are generated by the website templates, the e-mail newsletter script(s), or manually for sharing on social media and other direct channels so that they can be valid for specific time periods.

While a normal article URL might look like this...

http://example.com/News/2014/09/Featured-Article

... a hash URL would look like this:

http://example.com/News/2014/09/Featured-Article/(hash)/9ac8af9aa_1415304004

If the hash is valid, the visitor is shown the full article. The hash values are only required and checked for anonymous users; authenticated users have unrestricted access. Because a timestamp is included as part of the hash, the decoding logic not only checks for the general validity of the hash, but it also checks for whether the hash has expired.

What are some alternatives?

There are several alternatives to hash URLs in order to show full article content.  Two that were considered carefully were "metered access" and "always free articles".

Metered access

Cookie name and value

This is often called the porous paywall solution. A cookie or session storage can be used to count the number of pages viewed; after a certain number of views, the user is prompted to register for an account. Many sites use this approach. However, there are a few drawbacks with this method.  Access is controlled based on the number of requests from the user, regardless of the specific pages requested, which means additional logic would be required to grant access to specific content.  As well, technically-savvy surfers can easily defeat this approach.

Always free articles aka "checkbox"

Available to All

Another method is to mark content available for public access with a flag or checkbox. Anonymous users would be able to read specific content only if it had been explicitly marked as available. The advantages of this approach are that it is simple to manage and easy to implement.  However, it may become cumbersome to administer as the list of publicly available articles must be manually managed and tracked.

How do the alternatives compare?

Two key requirements for this task were ease of administration and a variable, sliding timespan.  Ease of administration meant little to no overhead for the content editors.  The timespan requirements were that when access is granted using the hash URL, the content is accessible for a timespan starting at time the link was issued.

Additional considerations included the complexity of implementation, impact on content architecture, and the level of protection.

The following table compares the alternatives:

Editorial control

Timespan control

Full access to content

Modifications to content architecture

Level of Protection

Hash

No*

Yes

Yes

None

High

Metered

No*

No

Yes

None

Low

Checkbox

Yes

Yes

Yes

Content class updates

High

* can be combined with a checkbox-like approach to provide editorial control

Are there other alternatives?

You can also allow non-registered users to read an introduction or summary, but not the entire article.

Masking Content

Masking content

Subscription access would be required to read the entire article. This is a very common approach if you do not need non-registered users to be able to read the entirety of articles.

This can be combined with a "trial" level of access so that visitors can register for an account that gives full access to articles for a short period of time.

Technical challenges

The technical challenges in the hash approach included creating and recreating the hashes, checking the timespan, and ensuring the hashes were properly handled by the reverse proxy in front (Varnish in this case) and respected by the eZ Publish view cache.

To create a hash that includes a timestamp, the original timestamp must be passed in such a manner that it can be decoded and easily compared to the current timestamp. We used eZ Publish's view parameters to pass the hash.

If you would like more information, whether you are a digital publisher or a developer, contact Mugo Web and we'll be glad to help!

Comments

blog comments powered by Disqus