[amp-subscription] for ad-free site

[eNoodle4711]

We know that SWG was developed mainly for real paywalls and premium content. However, we want to use SwG for an ad-free site and not only in the WWW version, but also via AMP.

To make it even more complex, we don't use any accounts on our site and we don't store any data on our servers for privacy reasons. We only use the LocalStorage to store necessary data and to keep it for performance reasons.

In fact, this works perfectly in the WWW version. In combination with Google SignIn (via server-side oAuth) and SwG we get all the signals we need to make the site ad-free or not.

Under AMP it's a bit different - and here we need your help.

If we include amp-subscriptions and configure a local service (via amp-access-iframe - #21395) and additionally SwG, it works, but with limitations:

• isAccessibleForFree (see amp-subscriptions behavior is undefined if isAccesibleForFree is true. #27262).

In principle, every article is accessible and readable for everyone. A subscription with us would only hide the banners. However, "isAccessibleForFree: true" ensures that the Entitlements are not retrieved. The behavior here differs from the normal web implementation, where the property can remain set to "false" and the Entitlements will still be retrieved.

• amp-access-iframe (see amp-access-iframe for amp-subscriptions #21395)

Works fine, thanks for this solution. We can use it to switch to our TLD without any problems and fetch the data stored in LocalStorage.

However, this seems pointless - at least for our case - to create a local service at all:

• The Google News Viewer does not attract the local service.
• The data (e.g. username) can not be used any further

Another problem is the lack of mechanisms to show or hide ads. What works fine with amp-access, unfortunately did not work with subscription-display.

Maybe we abuse SwG too much, but we find the use of SwG for an ad-free version really exciting. Especially in combination without own login and without own paywall.

[jpettitt]

isAccessibleForFree should be set false for this use case. While it's perhaps not intuitive isAccessibleForFree really means "some content on this page will be rendered differently according to subscriber status" which is true if you are hiding ads.

We do not recommend the iframe approach because for a large number of browsers the data will not be stored in local storage when the frame is cross origin. Additionally it won't buy you much in terms of latency because the iframe won't load until the page is visible and will probably take longer to load than the SwG entitlements call.

You should be able to control ad display by putting the subscription-display on the parent element of the ad not the amp-ad tag itself. However you need to be very conscious of layout shift for ad element above the fold. You will also delay ad ad server call until after the subscription resolves which may have an effect on viewability depending on where the ads are.

[eNoodle4711]

@jpettitt, thanks for the clarification and the valuable insights.

We will set isAccessibleForFree to false. Some content (mainly ads) on this page will be rendered differently and if the set flag reflects that, we're absolutely fine with this. Otherwise I would have prefered the alwaysAuthFreeContent flag mentioned here #27754 in combination with isAccessibleForFree set to true, but it seems the mentioned flag is not available.

However, we'll go with "false" for now, but we need to make sure, that it won't affect indexing of the AMP pages. Do you have any shareable insights here?

I wasn't aware of the local storage problems within a cross origin frame, we definitely have to rethink our implementation here. While the local service is required, we have to provide a correctly configured "remote" service. It's not a problem to set it up, but for our setup - a pure Google SignIn and SwG solution - it's not really the best option. In my opinion we could skip it completely and avoid any call at all because SwG - for our AMP implementation - is the only source of thruth.

Showing/Hiding ads are non-critical for us, our AMP version avoids ads in the first viewport. Adding subscription-display to the wrapping container did the trick. While this works for simple sections within the content, we're still missing some flexibility here. For example, subscription-display within an amp-siderbar component will always remain hidden, regardless of the subscription state.

Again, thanks for your help, really appreciate it.

[jpettitt]

isAccessibleForFree will not change indexing either way. The product id metadata is used to match user subscriptions to show "from your subscriptions" search results, isAccessibleForFree doesn't change that either way.

Please file a separate issue for subscriptions-display failing within amp-sidebar - that's a bug.

We recommend using the AMP reader Id as a user lookup key. If you associate the reader Id with your google sign in token on your backend you can make the server to server api query for the subscription data. That said on google.com search results the google login cookies are present (google.com is the top level domain and so 1st party). This means that the SwG entitlements call will work.

There are three cases

1. Google.com search result. SwG entitlement call works, no publisher cookies and no iframe storage on some browsers.

2. AMP page from amp cache not on google.com. Publisher and SwG cookies are seen at 3rd party and may not work on some browsers, iframe storage also unusable. This is an unlikely scenario.

3. AMP page on publisher origin. SwG cookies may not be available, publisher 1st party cookies work, iframe storage (presuming iframe is also publisher origin) available.

The AMP reader ID is a consistent token for a specific device/surface/browser/publisher combination - you can associate it on a back end system with a subscription or a Google sign in token to retrieve a subscription. You would need to handle a user having multiple reader ID's as it will be different in different browsers (desktop / mobile or even 2 different mobile browsers on the same device).

Webviews in apps are an unknown as every app developer implements them differently and the storage is visible to the app and so untrusted.