Measuring and shipping paywall changes

The edit loop

Server-driven config lets you change a live screen in minutes, which is exactly why it needs guard rails. The shipped workflow has three of them.

1. Preview and confirm. Write tools such as create_paywall, update_paywall, and create_winback_offer first return a preview and a confirmToken. A human approves the preview, then the same tool is called again with the token. The token is bound to the exact content previewed, so changing the input invalidates it.
2. Draft. An update_paywall patch changes only the fields you pass and saves the result as a draft. It does not change what users see.
3. Publish. publish_paywall promotes the saved draft to the served version. It needs no second confirm token because it only promotes content that was already saved and approved.

Creating a brand-new paywall is the exception: confirming create_paywall saves and publishes it in one step, so it goes live once your agent completes setup. Later edits stay drafts until you publish. Because the client route serves only the published snapshot, an unpublished draft is invisible to end users, and a paywall that was never published answers not found.

Shipping a change safely

• Change one thing at a time. A patch touches only the fields you send, so a copy tweak, a recommended-package change, and a new locale can each be their own draft and publish.
• Check both themes. The builder previews light and dark when the theme is auto, and updates on every keypress.
• Remember price is not yours to change here. A synced package's price is Play-owned; a price change is a Play Console change, not a paywall publish. See chapter 2.
• Remember the SDK version. Config changes what the installed SDK renders, not what it is able to render.

What you can measure today

Tierux's measurement surface is built around entitlements and lifecycle events, not around paywall impressions. The dashboard analytics service reports, per app: how many entitlements are currently active (grace period included), purchase verifications in the last 24 hours and per day over the last seven, and a count of entitlements by status — active, grace period, account hold, cancelled, and expired.

For individual subscribers, an append-only billing timeline records renewals, billing retry, grace period, cancellation pending, expiry, refunds, and admin notes, derived from purchase verifications and lifecycle notifications. It powers the support timeline and the get_user_timeline tool.

Sources: src/services/entitlementAnalyticsService.ts and the billing timeline types in src/types.ts. Verification required if a funnel or experiment feature has shipped since this page was last updated.

That last row is deliberate. The paywall spec does not include variant testing or impression-to-purchase funnels, so this guide does not describe them and neither should you assume them. If you need conversion analysis, pair a change with your own product analytics and compare against the entitlement and timeline signals above. This guide also quotes no benchmark numbers, because none are grounded in Tierux data.

Getting lifecycle events out

If you want these signals in your own systems, Tierux can forward lifecycle events to your backend as signed HTTP POSTs; see the webhooks docs. That is the practical route for joining paywall publishes to subscription outcomes in a warehouse or dashboard you already run.

A checklist to close on

• Design the paywall around a package's Play-owned price (chapter 2).
• Opt packages into a win-back offer and let RTDN arm it (chapter 3).
• Edit as drafts, preview, publish (this chapter).
• Watch verification counts, status breakdown, and the timeline afterwards.
• Check the platform support matrix before promising any of this to iOS users.

← Back to the paywalls and win-back guide