Pushlane: Push Segmentation for Subscription Apps

"All users" is rarely a useful subscription-app audience. A trial user, an active annual subscriber, a person in a billing issue and a former subscriber may all have the same app installed, but the same notification can be irrelevant or false for three of them.

Good segmentation begins with current state and a specific message job. Pushlane audiences can combine user attributes, event properties and event predicates. RevenueCat supplies verified lifecycle events. The hard part is deciding which data represents durable current state and which only describes something that happened in the past.

This guide builds a practical segmentation model without assuming that one webhook field automatically becomes a permanent user trait.

Separate state, behavior and delivery

Use three layers when defining eligibility.

Subscription state answers what access and billing condition applies now: free, trialing, paid, billing issue, auto-renew off or expired.

Product behavior answers what the person has done: activated, completed a key action, used a premium feature or become dormant.

Delivery state answers whether the person can and should receive this push: active iOS device, relevant consent, locale and recent contact frequency.

A lifecycle audience normally needs one condition from each layer. For example:

trialing
AND has not completed first premium action
AND has a reachable, consent-eligible iOS device

Do not replace this with "received trial_started sometime". An old event in history does not prove the user remains in trial.

Know what Pushlane audiences evaluate

Pushlane audiences are named, reusable filters. The current audience documentation supports:

• user attributes such as plan, locale or onboarding goal;
• event-property clauses scoped to a named event;
• event predicates such as performed or did not perform, optionally within a recent window;
• all and any match modes;
• dynamic evaluation when the engine checks membership.

Audience counts can be inexact when a property is new or not fully evaluable. The count response exposes that state. Do not interpret an inexact zero as proof that nobody qualifies.

An audience can start a flow when a user enters membership, can be re-evaluated on a schedule or can be checked inside a branch. Choose the placement based on timing, not convenience.

Do not confuse an event with current entitlement state

RevenueCat webhooks describe state transitions. INITIAL_PURCHASE, RENEWAL, BILLING_ISSUE, CANCELLATION and EXPIRATION are events. RevenueCat's official event reference documents their meanings and properties.

Pushlane bridges supported webhooks as revenuecat.* flow events and stores their properties for event-based conditions. It does not automatically mirror a single subscription_state user attribute for every project.

If you need a durable current-state audience, choose one of two honest patterns:

1. Event-driven flow state: enter on the RevenueCat event, branch on its properties and exit on every superseding event. This is best when the message is tightly timed to the transition.
2. Server-maintained user attribute: have your trusted backend or controlled flow update a normalized attribute such as subscription_state after validating the RevenueCat transition. Define precedence and reconciliation so out-of-order events cannot leave the attribute stale.

Do not let the mobile client declare itself paid. Billing state comes from the server source of truth.

Build six useful lifecycle audiences

These audience definitions are starting models. Use only attributes and events your project actually records.

1. Trialing but not activated

subscription_state is trialing
AND did not perform first_premium_value
AND trial expiration is still in the future

Use this audience inside a trial-start flow rather than as an indefinite recurring blast. The message job is product activation. Exit on activation, paid conversion, cancellation or expiration.

2. Paid but missing first premium value

subscription_state is active_paid
AND did not perform first_premium_value
AND performed verified paid purchase recently

Use for a post-purchase activation flow. Do not include long-term subscribers who already use another valuable workflow simply because one event is missing.

3. Billing recovery in progress

subscription_state is billing_issue
AND did not perform verified renewal after the issue

Event-driven state is usually safer here because renewal or expiration must cancel delayed reminders. Use the billing issue flow instead of a daily audience blast.

4. Auto-renew off with access remaining

subscription_state is cancelled_active
AND expiration timestamp is in the future

This is not the win-back audience. Use cause-neutral copy because Pushlane does not currently expose RevenueCat cancel_reason as a flow branch property. Exit on uncancellation or expiration.

5. Expired former subscriber with prior value

subscription_state is expired
AND performed meaningful premium action before expiry
AND did not perform verified resubscription after expiry

This narrows win-back to people who know what they would regain. Add contact-frequency and support exclusions. The win-back guide covers copy and stop events.

6. Healthy active subscriber near a product moment

subscription_state is active_paid
AND performed a recurring value action in its normal window
AND has not completed the next expected action

Use this only when the product has a real recurring rhythm. Avoid inventing a daily habit for an app normally used once a month.

Use event entry for timing and audience for eligibility

An event says "now." An audience says "who."

Suppose a user tries a premium feature. Enter on premium_feature_attempted, then branch on an audience of activated free users. That preserves the exact moment while excluding people who are not ready for the message.

Suppose a billing issue arrives. Enter on revenuecat.billing_issue, then branch on store, production environment, reachability and contact rules. Do not wait for a nightly segment job to discover an urgent transition.

Scheduled audience entry is appropriate for genuinely calendar-based work, such as a weekly summary for users who opted into that cadence. It is weaker for state transitions where a server event already exists.

Pushlane audience membership can be edge-triggered when a user transitions into the segment. A recurring schedule can re-enter current members, so apply explicit limits and exits to avoid sending the same campaign forever.

Define state precedence

Subscription events can arrive close together, and networks can change delivery order. RevenueCat's common webhook flows warns that billing events can be observed out of order.

If you maintain a normalized attribute, define precedence and timestamps. For example:

1. A newer verified paid renewal moves state to active.
2. Expiration moves state to expired only when it is not superseded by a later renewal.
3. Billing issue moves state to recovery only while access and retry context remain applicable.
4. Cancellation does not imply expiration.
5. Sandbox events never update production customer state.

Compare lifecycle timestamps or an authoritative current entitlement lookup, not webhook arrival time alone. Make updates idempotent using RevenueCat's event ID.

Keep plan and entitlement labels customer-safe

RevenueCat webhook properties can include product_id and entitlement_ids. These values are useful for branching, but internal identifiers rarely belong in notification copy.

Map products to stable, user-facing names in trusted code or attributes. Use a fallback that reads naturally:

Your {{ plan_name | premium access }} is ready

Do not expose com.example.pro.monthly or assume every product ID has the same benefits across stores. If a product change event is deferred, RevenueCat notes that the new product may not take effect immediately. Segment on current access, not only the requested change.

Add delivery and consent guards last, but always

A business audience can contain people who cannot receive the push. Before sending, check:

• supported iOS delivery path;
• active APNs registration for the current user;
• current system permission and recorded consent rules;
• locale coverage or a safe default locale;
• recent message frequency;
• account identity after logout or transfer.

Pushlane can register Android FCM tokens, but Android delivery is not currently live. Do not count an FCM-only user as deliverable for an iOS campaign. A suppressed send is an honest outcome and belongs in reporting.

System permission and marketing preference are separate. An iOS-authorized device can still be excluded from promotional lifecycle messages when the person opted out.

Avoid segments that encode assumptions

These definitions look convenient but are unreliable:

• "high value" based only on purchase price;
• "churn risk" because someone missed one arbitrary day;
• "discount seeker" because a paywall was viewed;
• "loyal" because the user has not cancelled;
• "trial failed" before expiration;
• "Android reachable" because an FCM token exists in Pushlane.

Name audiences after observable criteria, such as "Active paid, no premium export in 30 days," not psychological labels. That makes review, debugging and deletion easier.

Avoid tiny sensitive segments that reveal health, financial or personal conditions in notification copy. Store only the data needed for the message job, and prefer broad product behavior over private content.

Verify audience logic before activating a flow

For each audience:

1. List every source field and who writes it.
2. Confirm the property exists in the Pushlane catalogue and has real data.
3. Inspect whether the live count is exact.
4. Create test users for every inclusion and exclusion edge.
5. Advance subscription state and verify membership changes.
6. Deliver RevenueCat events out of the expected order in sandbox.
7. Confirm sandbox never changes production eligibility.
8. Verify logout and identity transfer behavior.
9. Test the audience inside the flow branch, not only in the builder count.
10. Confirm an unsupported or opted-out device is suppressed at send time.

Write the expected membership as examples before implementation. "User A is included because..., user B is excluded because..." catches ambiguity faster than a large boolean expression.

Measure segment quality and campaign outcome separately

Segment quality asks whether the right people were selected. Campaign outcome asks whether the message helped.

For segment quality, track:

• eligible count and whether it is exact;
• unexpected inclusions and exclusions found in QA;
• stale state transitions;
• proportion without a supported device;
• overlap with other lifecycle audiences.

For campaign outcome, use the event tied to the message job: activation, payment recovery, uncancellation or verified resubscription. Opens and taps are diagnostics.

Do not conclude that a smaller segment is better merely because its conversion rate is higher. It may select people who would have acted anyway. Use stable holdouts within the eligible audience when volume supports an incrementality test.

Segment around truth, then around relevance

The first segmentation win is preventing a false message: no upgrade push after purchase, no win-back before expiration, no billing reminder after renewal. Relevance comes next through product behavior, goal and timing.

Use RevenueCat events for verified transitions, a reconciled attribute only when you truly maintain current state, and Pushlane audiences for reusable eligibility. Then let the event that created the moment start the flow. That model stays understandable as the subscription lifecycle becomes more complex.