Reduce Churn at the Paywall

A user opens your paywall, hesitates, and leaves without subscribing. Instead of losing them, present a premium brand offer, a real perk a brand funds to acquire customers, that unlocks a better-than-standard deal on your product. Because the brand pays for the perk rather than you, staying subscribed suddenly costs the user less than leaving. This is the Reduce Churn use case, and it is the Web SDK’s default: a placement that names no use case resolves to 'reduceChurn'.

The complete pattern

An example fitness app, FitTracker, whose exclusive offer is an extended 1-month free trial (vs the standard 7 days), unlocked by claiming the brand offer:

import Encore from '@encorekit/web-sdk';

Encore.configure({ apiKey: 'pk_live_yourpublishablekey' });
Encore.identify(userId); // bind the claim to an id that survives reloads

// 1. The user dismisses your paywall without subscribing
async function onPaywallAbandoned() {
  const result = await Encore.placement('paywall_decline', {
    appearance: { accentColor: '#2E6BFF' },
  }).show();

  if (result.status !== 'claimed') {
    return; // 'dismissed' | 'unavailable': continue your normal exit path
  }

  // 2. The user claimed, and the brand's tab is already open in the background.
  //    Keep the transaction id: it is how a completion landing days later is
  //    traced back to this user.
  await persistClaim(result.transactionId);

  // 3. Your page still has focus. Sell YOUR OWN exclusive offer now.
  openTrialCheckout(); // "1 month free (usually 7 days), then $9.99/mo"
}

Full contracts: show() · placement().

Requires the current @encorekit/web-sdk 2.x release. Upgrading an existing integration: Updating to 2.x.

Sequencing your own offer

The brand tab opens in the background the moment the user claims, and your page keeps focus, so your checkout is what the user sees next. Open it as soon as the result resolves claimed, while the reason they claimed is still fresh. Your checkout and the brand handoff are independent from here. The user might complete yours, theirs, both, or neither, and none of those outcomes changes what show() already resolved: the claim is a fact the moment it happens.

Wire up analytics

The flow above drives trials, but Encore can only credit them to the offer if your subscription events join back to the exposures it recorded. Identify the user with your stable customer id (as in the setup above) and forward your subscription events to Encore with that same id. Configure Analytics is the quickstart step that wires it up.

Gotchas

Identify before show(). Call Encore.identify() with your stable customer id before presenting the offer; that id is what links later subscription events to the offer cohort. Exposures recorded before identify() are not retro-linked. See Configure Analytics.
Never block the cancel flow. When the user dismisses the offer, your own fallback path must let them proceed. Branch on the result, and treat dismissed and unavailable identically here.
Persist transactionId. It carries the attribution for a completion that lands days later. It is optional on the result, because the transaction write can fail while the claim genuinely happened, so handle its absence without treating the claim as failed.
unavailable is not an error. It means no eligible offers, or a measurement control cohort. Show your normal exit path.
A claim is not a conversion. Brand completion is asynchronous and server-authoritative; never gate access on the client result.

The Claim Flow: what a claim does, and what its payload carries.
Reduce Churn: the canonical description of this use case.
show() · placement()
Updating to 2.x: moving off the two-phase flow.

iOS

Android

Web

Bridges

Reduce Churn at the Paywall

The complete pattern

Sequencing your own offer

Wire up analytics

Gotchas

​The complete pattern

​Sequencing your own offer

​Wire up analytics

​Gotchas

​Related

The complete pattern

Sequencing your own offer

Wire up analytics

Gotchas

Related