Pushlane Mid-Trial Reminder Push Notifications

A mid-trial reminder push notification should help a trial user reach the value they expected when they started. It should not manufacture urgency, repeat the paywall or assume that day three and day five are correct for every product.

The useful inputs are verified trial state, the product milestone that matters and the time remaining before the real expiration. RevenueCat can supply the subscription transition. Your app supplies evidence of progress. Pushlane connects those signals to a message with clear stop conditions.

This guide uses day three and day five only as planning examples. The right checkpoints depend on trial length, how quickly a customer can experience value and whether the trial renews automatically.

Start from verified trial state

In a connected Pushlane workspace, RevenueCat sends the raw INITIAL_PURCHASE webhook first. When its period_type is TRIAL, Pushlane also derives revenuecat.trial_started. That derived event is the clean entry for a trial-specific flow.

RevenueCat documents this sequence in its official trial event flow. Its event field reference defines fields such as expiration time and environment.

Do not add a client-side trial_started event to imitate the webhook. A local purchase callback may fire twice, arrive before store state settles or use an identity that does not match the webhook. Keep billing truth on the server path.

Before activating the flow, verify:

• the RevenueCat App User ID matches the external ID passed to Pushlane;
• a sandbox trial reaches the correct workspace;
• revenuecat.trial_started includes the expected environment and expiration data;
• the app has an active supported push device and marketing consent;
• production flows exclude sandbox events.

The RevenueCat automation blueprints show how this entry relates to the rest of the subscription lifecycle.

Define the value checkpoint before the delay

Ask one question: what observable action makes this trial useful?

For a fitness app, it may be a completed session. For a language app, it may be a first lesson and a chosen practice time. For a finance app, it may be the first connected account or completed budget. Choose the smallest action that demonstrates the product's core job without pretending it guarantees conversion.

Then separate trial users into states:

1. Not activated. The person has not completed the first value event.
2. Activated but stalled. The first milestone happened, but the next meaningful action did not.
3. On track. The person is already using the product as intended.
4. No longer eligible. The trial converted, ended, was cancelled, the user opted out or another stop condition occurred.

These states need different treatment. The unactivated user needs a short route to the first result. The stalled user may need help with the next obstacle. The on-track user may need no reminder at all.

Use time as a checkpoint, not the message reason

Pushlane supports fixed flow delays. Place a delay after revenuecat.trial_started, then branch on current product evidence before sending. Choose that delay from trial lengths you have actually observed in your own RevenueCat events.

For a seven-day trial, a team might review day three and day five as candidate checkpoints. That does not make them universal best times. A three-day trial, a fourteen-day trial and a usage-based introductory offer require different plans.

If the message makes an expiration claim, calculate it from the verified expiration timestamp in your application or flow design. Do not write "two days left" merely because a fixed delay usually lands there. Store changes, retries and different products can make that copy false.

A safer mid-trial flow is:

revenuecat.trial_started
  -> wait for the tested checkpoint
  -> exit if trial converted, cancelled, expired or user opted out
  -> branch on activation milestone
     -> missing: send one useful setup action
     -> complete: suppress or send a distinct next-step message
  -> wait for the next tested checkpoint
  -> recheck every exit and current product state

Write for progress, not pressure

Mid-trial copy should identify one available benefit and one action. It should not imply that the customer has already succeeded or failed.

Examples to adapt:

Activation incomplete

Your first plan is ready to build

Choose one goal and we will turn it into a simple next step.

Activated but stalled

Pick up where you stopped

Your saved lesson is ready when you are.

Help path

Want help setting things up?

Open the two-minute setup guide for your first result.

These are original starting points, not winning templates or measured benchmarks. Replace the nouns with actions the destination can actually complete. If the user cancelled auto-renew but retains trial access, use cause-neutral language. Do not say the trial has ended before RevenueCat reports expiration.

Build strict exits

Every delayed trial message can become stale while it waits. Stop or suppress the flow when any of these conditions applies:

• revenuecat.trial_converted arrives;
• RevenueCat reports cancellation or expiration relevant to the flow;
• the activation or next-step event is completed;
• the user disables marketing notifications;
• the device is no longer reachable;
• the message's deep link or benefit is no longer available.

Cancellation during a trial may mean auto-renew is off while access continues. It is not the same as expiration. Decide whether a support message remains useful, but never describe the customer as expired while entitlement is active.

Measure the promised action

Use the product milestone as the primary response metric. Opens help diagnose the message path, but an open without the promised action is not activation.

Track:

• eligible trial users at each checkpoint;
• suppressions and their reasons;
• provider-accepted sends and attributable opens;
• completion of the target product action;
• verified trial conversion as a later lifecycle outcome;
• opt-outs and stale-message defects.

If the audience is large enough, hold out an eligible group and compare the same observation window. If it is small, report counts and uncertainty. The Pushlane metrics guide explains why conversion among openers is not proof that the reminder caused the conversion.

The goal of a mid-trial reminder is not to fill silence on a calendar. It is to notice a real, recoverable gap while the customer still has time to experience value, then get out of the way when the evidence says the job is done.