amp-subscriptions

<script async custom-element="amp-subscriptions" src="https://cdn.ampproject.org/v0/amp-subscriptions-0.1.js"></script>

Usage

The amp-subscriptions component implements subscription-style access/paywall rules.

How it works

1. The AMP Page is loaded in the AMP viewer with some sections obscured using attributes.
2. The AMP Runtime calls the Authorization endpoint of all configured services.
   1. If all services fail to respond, the fallback entitlement will be used.
3. The AMP Runtime uses the response to either hide or show different sections as defined by the Attributes.
4. After the document has been shown to the Reader, AMP Runtime calls the Pingback endpoint that can be used by the Publisher to update the countdown meter (number of free views used).
5. The Publisher can place specific Actions in the AMP document in order to:
   1. Launch their own Login page to authenticate the Reader and associate the Reader’s identity in their system with the AMP Reader ID
   2. Launch their own Subscribe page to allow the Reader to purchase a new subscription
   3. Launch login or subscribe actions from Vendor Services.

Relationship to amp-access

The amp-subscriptions component is similar to amp-access and in many features builds on top of amp-access. However, it's a much more specialized version of access/paywall protocol. Some of the key differences are:

1. The amp-subscriptions authorization endpoint is similar to the amp-access authorization endpoint but its response is strictly defined and standardized.
2. Instead of using amp-access-hide and amp-access attributes as described in amp-access Access Content Markup, you'll need to use:
   • subscription-section to define sections of content for subscribers and non-subscribers.
   • subscription-display to display elements based on factors that are not related to the subscription that the user has.
3. The amp-subscriptions component allows multiple vendor services to be configured for the page to participate in access/paywall decisions. Services are executed concurrently and prioritized based on which service returns the positive response.
4. AMP viewers are allowed to provide amp-subscriptions a signed authorization response based on an independent agreement with publishers as a proof of access.

Because of standardization of markup, support for multiple providers, and improved viewer support it is recommended that new publisher and paywall provider implementations use amp-subscriptions.

AMP Reader ID

To assist access services and use cases, AMP Access introduced the concept of Reader ID.

The Reader ID provides a solution for Publishers to identify Readers without revealing any personal information. This allows Publishers to track article views and implement metering, paywalls and other subscription services.

The Reader ID is an anonymous and unique ID created by the AMP ecosystem. It is unique for each Reader/Publisher pair - a Reader is identified differently to two different Publishers. It is a non-reversible ID. It is intended to be random in nature and uses a number of factors to achieve that unpredictability. The Reader ID is included in all AMP/Publisher communications and can be used by Publishers to identify the Reader and map it to their own identity systems.

The Reader ID is constructed on the user device and intended to be long-lived. However, it follows the normal browser storage rules, including those for incognito windows. The intended lifecycle of a Reader ID is 1 year between uses or until the user clears their cookies. The Reader IDs are not currently shared between devices.

The Reader ID is constructed similarly to the mechanism used to build ExternalCID described here. An example Reader ID is amp-OFsqR4pPKynymPyMmplPNMvxSTsNQob3TnK-oE3nwVT0clORaZ1rkeEz8xej-vV6.

We strongly recommend the usage of Reader ID over cookies to identify Readers, as publisher cookies are considered third party cookies when AMP is loaded from CDN and might be blocked by browsers. If you however want to rely on the cookie in cases where it is available, make sure to mark the cookies correctly as cross-origin cookies.

Configuration

The amp-subscriptions component must be configured using JSON configuration:

Below is an example of a configuration:

<script type="application/json" id="amp-subscriptions">
  {
    "services": [
      {
        // Local service (required)
        "authorizationUrl": "https://pub.com/amp-authorisation?rid=READER_ID&url=SOURCE_URL",
        "pingbackUrl": "https://pub.com/amp-pingback?rid=READER_ID&url=SOURCE_URL",
        "actions": {
          "login": "https://pub.com/amp-login?rid=READER_ID&url=SOURCE_URL",
          "subscribe": "https://pub.com/amp-subscribe?rid=READER_ID&url=SOURCE_URL"
        }
      },
      {
        // Vendor services (optional)
        "serviceId": "service.vendor.com"
      }
    ],
    "score": {
      "supportsViewer": 10,
      "isReadyToPay": 9
    },
    "fallbackEntitlement": {
      "source": "fallback",
      "granted": true,
      "grantReason": "SUBSCRIBER",
      "data": {
        "isLoggedIn": false
      }
    }
  }
</script>

Local service

The local service is provided by the Publisher to control and monitor access to documents.

It is configured using the following properties:

<URL> values specify HTTPS URLs with substitution variables. The substitution variables are covered in more detail in the URL Variables section below.

Below is an example of a "local" service configuration:

<script type="application/json"