Pushlane: Push Metrics for Subscription Apps

Push notification metrics for subscription apps should connect delivery to customer value and verified subscription state. Open rate alone cannot tell you whether the right person received the message, completed the promised action, renewed, opted out or would have converted anyway.

A useful measurement model has four layers: eligibility, delivery, product response and lifecycle outcome. Each layer answers a different question. Collapsing them into one rate hides where the system or strategy failed.

This guide defines the metrics and denominators without supplying a universal benchmark. Your own event quality, product rhythm, platform mix and campaign purpose determine what a healthy result means.

Start with an explicit funnel

Write the funnel before launching the flow:

eligible user
  -> send decision
  -> provider accepted
  -> device received
  -> notification opened
  -> destination action completed
  -> subscription outcome verified

Not every app can observe every step. Pushlane can record a provider send decision. On iOS, the Notification Service Extension can emit a received event when it processes a mutable notification before display. Current native SDKs and generated drop-ins emit the reserved opened interaction when the person taps, with the original message_id. Your product events and RevenueCat webhook complete the rest of the path.

Document missing instrumentation instead of changing the denominator. If the Notification Service Extension is not installed, do not label provider acceptance as confirmed device delivery.

Measure eligibility and reachability first

The top of the funnel determines how much of the intended audience can actually receive a Pushlane notification.

Eligible audience

Count users who match the business rule at evaluation time.

eligible audience = users matching current state, behavior and policy conditions

State matters. A user who received a trial-start event months ago is not necessarily still trialing. Use a reconciled current-state attribute or an event-driven flow with explicit exits.

Reachable eligible rate

reachable eligible rate = eligible users with an active supported device / eligible users

For Pushlane today, supported end-to-end delivery means an active APNs device. An FCM token registered by an Android or Flutter drop-in is not currently deliverable. Count that user separately rather than inflating reach.

Allowed send rate

allowed send rate = send decisions / evaluated eligible users

Review the reasons for suppressed decisions: missing active device, explicit marketing opt-out, frequency cap, missing variable, unsupported platform or a lifecycle guard. A lower send rate can be healthy when it reflects correct protection. The important question is whether the reason matches reality.

The segmentation guide explains how to separate current state, product behavior and delivery eligibility.

Keep provider acceptance, receipt and open distinct

These events are related but not interchangeable.

Provider acceptance rate

provider acceptance rate = provider-accepted sends / attempted sends

This shows whether Pushlane and APNs accepted the request path. It does not prove the person saw the notification. Device state, Focus, summary behavior and other OS decisions still matter.

Confirmed receipt rate

confirmed receipt rate = received events / provider-accepted sends with receipt instrumentation

Use only the population that has the required iOS extension and payload behavior. The Pushlane iOS SDK documentation describes how received is emitted and why the shared App Group is required for its telemetry.

Open rate

Choose and name the denominator:

open per accepted send = unique opened messages / provider-accepted sends
open per confirmed receipt = unique opened messages / confirmed received messages

The second rate isolates response among confirmed receipts, but only when receipt instrumentation coverage is reliable. Neither rate is a business outcome.

Deduplicate by message ID and user. One person reopening the same deep link should not become several converted recipients.

Treat open instrumentation coverage as a separate quality measure. A client version without the notification-response handler cannot report taps. The same is true when an app emits a custom event name or omits message_id: those taps are unattributable, not evidence that nobody opened the message. Test foreground, background and cold-start taps on each supported client path before comparing open rates, and annotate any cohort whose telemetry contract is incomplete.

Measure the action promised by the copy

Every push should lead to one observable destination action.

Examples include:

• first workout completed after an activation reminder;
• lesson resumed after a streak reminder;
• billing settings opened after a payment notice;
• premium feature used after a post-purchase message;
• plan restored after an expired-subscriber invitation.

Define an attribution window that matches the task. A billing update may happen quickly. A weekly planning prompt may need longer. Keep the window fixed during a comparison.

destination action rate = recipients completing the target action in window / eligible recipients

Using eligible recipients preserves suppressions and failed delivery in the operational result. You can also report action per confirmed receipt as a diagnostic slice, but do not quietly replace the primary denominator after launch.

Avoid using app_open as the target unless opening the app is genuinely the entire job. For most subscription products, the useful outcome happens after the session begins.

Join the journey to verified subscription outcomes

RevenueCat is the source for purchase, renewal, billing issue, cancellation and expiration transitions in a connected subscription flow. Its official Charts overview documents subscription metrics available in its dashboard, while its webhook event reference defines the events used for flow outcomes.

Match the outcome to the campaign:

Do not treat revenue attached to a notification tap as automatically caused by the push. Store billing can resolve independently, and users who engage with messages may already be more likely to renew.

Add safety and quality guardrails

Growth metrics need customer-experience counterweights.

Track:

• explicit marketing opt-outs after exposure;
• invalid or stale deep links;
• messages sent after a stop event;
• incorrect lifecycle claims found in QA or support;
• frequency-cap suppressions;
• missing localization or fallback use;
• unreachable users by platform and device state;
• duplicate message incidents.

An outcome lift does not justify a false payment notice or a push after opt-out. Treat those as defects, not acceptable conversion costs.

For copy and timing tests, follow the guardrails in the Pushlane A/B testing guide. Change one meaningful variable and preselect the primary outcome.

Estimate incrementality with an eligible holdout

When audience size supports it, assign a stable random holdout before sending. Both groups should satisfy the same eligibility rule at the same moment.

incremental outcome rate = treatment outcome rate - holdout outcome rate

Report the absolute difference and the group sizes. Do not call noise a lift because the relative percentage looks large. Predefine the observation window and include people who were assigned but later suppressed in the operational analysis.

For very small cohorts, use the flow to establish correctness first. Report counts, confidence limits when appropriate and the absence of a reliable conclusion. "Not enough evidence yet" is more useful than a benchmark copied from another vendor's network.

Build one scorecard per message job

A compact scorecard keeps the layers visible:

Choose the subscription or product outcome first, then instrument backward to eligibility. That keeps push notification metrics connected to the customer's job and makes technical delivery problems visible before they are mistaken for weak copy.