1. What is push notification automation?
Push notification automation is a saved rule that sends a message when a defined condition becomes true — no one presses send. Instead of a marketer deciding on Tuesday to write a message and choose an audience, the system watches customer events continuously and delivers the right message to each customer at the moment their own behavior makes it relevant.
Almost every business that sends notifications starts the same way: someone opens a dashboard, writes a message, picks a list, and sends. That works, and it does not scale — not because of the volume of messages, but because of the volume of moments. A customer earning their fifth stamp, another whose reward expires on Thursday, a third who has not been in for six weeks, a fourth whose membership renews next month: these are four different messages that need to go to four different people on four different days, and they happen again tomorrow with four different people. No human sends that reliably. A rule does.
That is the entire premise. Push notification automation converts a marketing decision you would otherwise make repeatedly into a rule you make once. The building blocks are consistent across every platform and every channel:
| Component | What it decides | Example |
|---|---|---|
| Automation | The saved rule itself, running continuously | "Expiring reward reminder" |
| Trigger | The event or condition that starts it | Reward expiry date is 3 days away |
| Condition | Whether this particular customer qualifies | Reward is unredeemed and customer is active |
| Audience | The segment the rule is allowed to touch | Loyalty members with a reward balance > 0 |
| Message | What is said, personalized from their data | "Your free coffee expires Friday" |
| Timing | When it lands, relative to the trigger | 3 days before expiry, inside 9am–8pm local |
| Action | The behavior the message is asking for | Visit and redeem |
| Follow-up | What happens next — escalate or exit | Exit on redemption; one final nudge at 24 hours |
Why automation is different from sending campaigns manually
The obvious difference is labour. The important difference is relevance decay. A manual campaign is written for the average member of a list on the day the sender happened to be at their desk. It is maximally relevant to almost nobody. An automation is written for a moment — and every customer who reaches that moment receives it while it is still true. A "your reward expires soon" message sent on a Tuesday to everyone is wrong for most recipients; the same message sent to each customer three days before their expiry is right for all of them.
The second difference is compounding. A manual campaign produces one burst of results and then stops existing. An automation you build in March is still producing results in December, for customers who had not enrolled when you wrote it. This is why the return on an automation should never be judged by its first week.
Every automation in this guide, and every automation you build, resolves to this chain. Write it out in one line before you open any tool. If you cannot fill in all five, the automation is not ready to build.
Trigger: what happened · Rule: who it applies to and whether to send · Message: what we say and with what data · Action: what we want them to do · Next step: what happens whether or not they do it.
- Automation converts a repeated marketing decision into a rule you make once.
- Its advantage is relevance per customer, not message volume.
- Every automation specifies eight components; the chain is trigger → rule → message → action → next step.
2. Manual vs scheduled vs automated push notifications
Manual push is written and sent by a person. Scheduled push is written by a person and sent by the clock. Triggered push is sent by a customer event. Behavioral automation is triggered push with segment and history logic attached. Drip sequences are multi-step flows spaced by fixed delays. Lifecycle automation is the whole set, organized by customer stage. They are not competing options — they are increasing degrees of independence from your calendar.
Most confusion in this category comes from treating "scheduled" and "automated" as synonyms. They are not. A scheduled send is still a campaign; you have simply decided in advance when to press the button. The moment is chosen by you. In a triggered send, the moment is chosen by the customer, and that single difference is what makes triggered messaging stay relevant without supervision.
| Mode | Timing decided by | Best use case | Personalization | Scalability | Example |
|---|---|---|---|---|---|
| Manual campaign | A person, now | Genuine news: a closure, a launch, an emergency | Low — one message, one audience | Poor — scales with staff time | "We're closed today for repairs" |
| Scheduled campaign | A person, in advance | Calendar-bound moments known ahead of time | Low–medium — segment-level | Moderate — still one-to-many | Black Friday offer at 8am Friday |
| Triggered campaign | A single customer event | Confirming or reacting to something that just happened | High — the event is the personalization | High — runs indefinitely | "Reward unlocked" on the 8th stamp |
| Behavioral automation | Event plus segment and history rules | Acting on patterns, not just single events | High — event plus profile plus history | High | Lapsed VIP who has not visited in 45 days |
| Drip sequence | Fixed delays after one entry event | Onboarding, education, staged nurture | Medium — same steps for everyone | High | Day 0, 2, 5, 10, 20 after enrollment |
| Lifecycle automation | Customer stage transitions | Covering the whole relationship, not one campaign | Highest — stage-aware | Highest | Onboarding → engagement → win-back → renewal |
The most common mistake is building a drip when the situation calls for behavioral automation. A drip does not check what the customer did between steps unless you explicitly tell it to, so a five-step onboarding drip will happily send "here's how to earn your first reward" on day 5 to someone who earned three rewards on day 1. Drips are for information that is true regardless of behavior. Anything that depends on what happened since should be behavioral.
- Scheduled is not automated — the timing is still yours, not the customer's.
- Triggered messaging is customer-relative; that is why it stays relevant unattended.
- Use drips for information that is true regardless of behavior, behavioral flows for everything else.
3. The highest-value push notification triggers
A push notification trigger is the event or condition that starts an automation. The twenty triggers below are ranked into three tiers by how much value they typically return for the effort of building them. Tier 1 — new member, reward earned, reward expiring, inactivity and milestone — covers most of the return available to a small business, because those events already happen daily in a business you are already running.
Triggers fall into four families, and recognizing the family tells you how to configure the automation. State changes (enrollment, tier upgrade, renewal) fire once when something becomes true. Thresholds (points balance, visit count, reward earned) fire when a number crosses a line. Time conditions (expiry approaching, birthday, days since last visit) fire on a clock relative to a customer-specific date. Context (entering a geofence, an event starting) fires on where or when the customer is. Most weak automations are weak because they used a time condition where a threshold was available.
Twenty triggers, each with the customer state that produces it, what the message should communicate, when it should send and the behavior it is trying to create. Cite, adapt or reproduce this table with attribution — it is built to be referenced.
| # | Trigger | Customer state | Message should communicate | Timing | Goal |
|---|---|---|---|---|---|
| 1 | New customer / member | Just joined, no history | What they now have and the single next step | Immediately on save | First redemption |
| 2 | Loyalty enrollment | Enrolled but not yet earning | How the program works and what the first reward is | Within minutes; follow-up at day 2 | First qualifying visit |
| 3 | Reward earned | Just crossed the earn threshold | Confirmation, value and how to claim | Immediately, at the moment of earning | Redemption while motivated |
| 4 | Reward about to expire | Unredeemed reward, deadline near | What they will lose and when | 3 days before; optional 24-hour final | Prevent silent loss |
| 5 | Inactive customer | Slower than their own norm | A reason to return, not an apology | At 1.5× their typical gap | Interrupt drift before it becomes churn |
| 6 | Lapsed customer | Beyond any plausible cycle | A genuine, time-bound reason | Once at the lapse threshold; once more later | Win back or let go cleanly |
| 7 | Purchase / visit milestone | Reached a countable achievement | Recognition first, offer second or not at all | Same day as the milestone | Reinforce identity and habit |
| 8 | Birthday | Known birth date approaching | A gift with a usable window | 2–5 days before, not on the day | An extra visit in a quiet week |
| 9 | Membership renewal | Term ending | Value received and what happens next | Two touches: ~14 days and ~2 days before | Renewal without a service gap |
| 10 | Tier upgrade | Qualified for a higher tier | Status earned and what unlocks | Immediately on qualification | Lock in the higher spend pattern |
| 11 | Tier downgrade pending | About to fall below threshold | What is needed to hold status, factually | Well before the drop — enough time to act | Retain the tier without resentment |
| 12 | New offer published | Segment matches the offer | The offer and who it is for | On publish, within send window | Redemption |
| 13 | Location / geofence event | Near a location, right now | One immediately actionable thing | On dwell in radius, in opening hours | Convert proximity into a visit |
| 14 | Event / appointment reminder | Booked commitment approaching | Time, place and what to bring | 24 hours before, plus a short-range nudge | Reduce no-shows |
| 15 | Seasonal campaign | Anyone eligible in a period | Timeliness and scarcity, honestly | Scheduled, capped, segment-filtered | Concentrated demand |
| 16 | Customer action taken | Did something meaningful | Acknowledgement and the natural next step | Immediately | Close the loop; build trust |
| 17 | Incomplete action | Started, did not finish | The one thing left to do | After a delay long enough to be helpful | Recover an in-progress conversion |
| 18 | Re-engagement | Holds a pass but never engages | A different value proposition than before | After a long, clearly defined quiet period | Re-activate or retire cleanly |
| 19 | VIP / member-only event | Top segment by value or tenure | Exclusivity that is actually exclusive | Ahead of any public announcement | Deepen the most valuable relationships |
| 20 | Referral event | Referred or was referred | Confirmation and the reward on both sides | Immediately on qualifying event | Turn advocacy into a repeatable loop |
Realistic examples for each trigger
1 · New member: "Your card's in your wallet. Stamp one is on us — show it on your next visit."
2 · Enrollment: "Six stamps, one free lunch. Show your card at the till each time you order."
3 · Reward earned: "That's stamp eight — your free coffee is ready. Show your card next visit."
4 · Expiring reward: "Your free dessert expires Sunday. It takes one visit to use it."
5 · Inactive: "It's been a few weeks. Your 4 stamps are still waiting — two more for a free bowl."
6 · Lapsed: "We've changed the menu since you were last in. Here's 20% off this week if you'd like to see it."
7 · Milestone: "That's your 25th visit. Genuinely — thank you. Coffee's on us today."
8 · Birthday: "Happy birthday week. A free slice is on your card until Sunday."
9 · Renewal: "Your membership renews on the 14th. You trained 31 times this year."
10 · Tier upgrade: "You're Gold from today: early access to drops and a free guest pass each month."
11 · Tier downgrade pending: "You're two visits from keeping Gold this quarter. You have until the 30th."
12 · New offer: "New this week for members only: half-price pastries after 4pm."
13 · Geofence: "You're nearby — your free coffee is still on your card."
14 · Appointment: "See you tomorrow at 2pm with Nadia. Reply to the shop if you need to move it."
15 · Seasonal: "Holiday hours are up, and members get first pick of the gift sets."
16 · Action taken: "Redeemed — enjoy. You're back to zero stamps and one closer to the next reward."
17 · Incomplete action: "You started setting up your card but didn't finish. It takes about 20 seconds."
18 · Re-engagement: "You've had our card a while and never used it. Would a free drink help?"
19 · VIP event: "Members only: Thursday 7pm tasting, 20 places, before we post it publicly."
20 · Referral: "Priya joined using your link — you both have a free coffee on your cards."
This guide publishes no open-rate, click-rate or conversion benchmarks for any of these triggers, and you should be sceptical of articles that do. Published push benchmarks rarely disclose sample size, period and message mix together, and almost never separate triggered from broadcast sends — which makes them useless for predicting what a specific automation will do in a specific business. The timings above are calibration starting points drawn from how these triggers behave structurally, not measured results.
- Triggers come in four families: state change, threshold, time condition and context.
- Tier 1 triggers — new member, reward earned, expiring reward, inactivity, milestone — carry most of the available return.
- Prefer a threshold trigger over a time trigger whenever the data supports one.
4. The 10 push notification automations to build first
Build in this order: welcome, reward-earned, expiring-reward, win-back, birthday, renewal, loyalty milestone, VIP, location-based offer, re-engagement. The first three are ranked highest because they fire on events your business already produces every day and confirm value the customer has already earned — which means they need no discounting to work. Win-back is fourth because it addresses revenue you have otherwise already lost.
Ten is not a target. Most businesses should launch three, run them for a full purchase cycle, and only then add more — because every flow you add competes for the same finite attention, and you cannot tell which flow is doing the work if you launch six at once. The ranking below is by return per unit of build effort, not by importance.
Ten flows fully specified: goal, trigger, delay, message, call to action and success metric. This is the build sheet — everything needed to construct each flow in any tool that supports triggers.
| # | Flow | Goal | Trigger | Delay | Message | CTA | Success metric |
|---|---|---|---|---|---|---|---|
| 1 | Welcome | Turn a signup into a first use | Pass saved / member enrolled | Immediate, then day 2 | What they have, how it works, first step | Show your card on your next visit | % reaching first qualifying visit within one cycle |
| 2 | Reward earned | Convert earned value into a visit | Balance crosses the earn threshold | Immediate | Confirmation, what it is worth, how to claim | Claim it on your next visit | Redemption rate within the reward's window |
| 3 | Expiring reward | Prevent silent value loss | Unredeemed reward within 3 days of expiry | 3 days before; optional 24-hour final | What expires, when, and that it is theirs | Use it before Sunday | Share of expiring rewards redeemed vs holdout |
| 4 | Win-back | Recover a customer who has stopped | No visit for your defined lapse period | At threshold, then once ~2 weeks later | A concrete reason to return, time-bound | Come back this week | Reactivation rate vs an untouched holdout |
| 5 | Birthday | Add a visit in a low-intent week | Birth date is 2–5 days away | 2–5 days before the date | A specific gift and its usable window | Claim it this week | Redemption rate; incremental visits |
| 6 | Renewal | Renew without a service gap | Membership term ending | ~14 days before, then ~2 days before | Value received this term; what happens next | Renew now / manage membership | On-time renewal rate; involuntary lapse rate |
| 7 | Loyalty milestone | Reinforce habit and identity | Nth visit, spend or stamp reached | Same day | Recognition first; a small thank-you second | None required — recognition can stand alone | Visit frequency change in the following cycle |
| 8 | VIP | Deepen the highest-value relationships | Enters top segment by value or tenure | Immediate on entry; then event-driven | Genuine early or exclusive access | Reserve your place | Retention and spend of the VIP cohort |
| 9 | Location-based offer | Turn proximity into a visit | Enters and dwells in a store radius | Real-time, opening hours only | One immediately actionable thing | Pop in — it's ready | Visits attributable to proximity triggers |
| 10 | Re-engagement | Revive or retire a dormant contact | Holds a pass, no engagement in a long window | Once, after a clearly defined quiet period | A different proposition than last time | Try this instead / no longer interested | Re-activation rate; clean list decay |
Launch welcome, reward-earned and expiring-reward together, because they form a closed loop: the welcome creates the first earn, the earn creates a reward, the expiry protects it. Run that loop for one full purchase cycle with a holdout group before adding win-back. You will learn more from three measured flows than from ten unmeasured ones.
- The first three flows form a self-reinforcing loop and need no discount to work.
- Every flow needs a delay, a CTA and a success metric before it is built.
- Launch three, measure a full cycle, then expand.
5. Push notification drip sequences
A push notification drip sequence is a series of messages sent at fixed intervals after a single entry event. The customer enters once — by enrolling, saving a pass or signing up — and then receives step 2 two days later, step 3 five days later, and so on. The spacing is decided in advance rather than by what the customer does next, which makes drips excellent for onboarding and education and unsuitable for anything that depends on live behavior.
A drip is the simplest multi-step automation and the easiest to get wrong, because its greatest weakness is invisible: it keeps sending. Without exit conditions, a five-step onboarding drip will tell a customer how to earn their first reward on day 5 even though they earned three on day 1. Every drip needs at least one exit — usually "customer has completed the action this sequence exists to cause."
An example five-step drip
| Step | Day | Purpose | Message shape | Exit condition |
|---|---|---|---|---|
| 1 | Day 0 — Welcome | Confirm what they now have | What the card is, where it lives, the one next step | — |
| 2 | Day 2 — Value | Explain the benefit, not the mechanic | What they get and roughly how soon | Exit if first earn already happened |
| 3 | Day 5 — First incentive | Lower the barrier to the first use | A small, time-bound reason to come in | Exit on first qualifying visit |
| 4 | Day 10 — Reminder | Catch the ones who meant to and didn't | Restate the value in one sentence | Exit on first qualifying visit |
| 5 | Day 20 — Re-engagement | Last attempt, then stop | Different angle; explicit final message | Exit unconditionally after this step |
Day 0/2/5/10/20 is a shape, not a recommendation. A coffee shop where customers visit four times a week and a furniture retailer where they visit twice a decade cannot share a cadence. Calibrate against: purchase frequency (a drip should not outlast one typical cycle), lifecycle stage (onboarding tolerates more contact than dormancy), offer urgency (a real deadline compresses the sequence), business model (subscription renewal cadence differs from transactional repeat), and observed behavior (if most first visits happen on day 3, your day-5 incentive is late).
- A drip is time-spaced from one entry event, not behavior-driven.
- Every step that behavior can make redundant needs an exit condition.
- Cadence follows purchase frequency — copied intervals are the most common drip failure.
6. Behavioral push notification automation
Behavioral push notifications are triggered by what a customer does — or conspicuously fails to do — rather than by the calendar. The reusable pattern is event → segment → rule → message → timing → action: an event arrives, you narrow it to the segment it applies to, a rule decides whether to send at all, the message is composed from the customer's own data, timing decides when it lands, and the action you want defines the exit condition.
Behavioral automation is where most of the value in this category lives, because the behavior is the personalization. A message that arrives because someone is two stamps from a reward does not need clever copy to be relevant; it is relevant by construction. This is also why behavioral flows tolerate plain language better than broadcast campaigns do — the recipient already knows why they are hearing from you.
The behavioral events worth automating
- Customer joins the loyalty program — the only moment you are guaranteed their attention.
- Customer earns points or a stamp — confirms progress and makes the program feel real.
- Customer reaches a milestone — a countable achievement worth naming.
- Customer becomes eligible for a reward — the highest-intent moment in most loyalty programs.
- Customer approaches reward expiry — a deadline you did not have to invent.
- Customer hasn't returned — measured against their own pattern, not a global average.
- Customer opens or engages with an offer — interest without conversion, which is a distinct state.
- Customer enters a location — context that expires in minutes.
- Customer renews a membership — the moment to reset expectations for the next term.
EVENT — what happened, as your system recorded it.
SEGMENT — which customers this event matters for.
RULE — the conditions under which we actually send (including suppressions).
MESSAGE — composed from the customer's own data, not a template variable.
TIMING — relative to the event, constrained by a send window.
ACTION — the behavior we want, which is also the exit condition.
Event: stamp balance reached 6 of 8. Segment: active members, opted in, no reward currently unredeemed. Rule: send only if they have not received an automated message in the last 72 hours and have visited at least twice in the last 60 days. Message: "Two more and lunch is on us — you're at 6 of 8." Timing: next day, 11:00 local, before the lunch decision. Action: a qualifying visit within 14 days; exit on the 7th stamp.
- In behavioral automation the trigger carries the personalization — the copy does not have to.
- The suppress branch is the difference between behavioral automation and a broadcast.
- The action you want is also your exit condition; define them together.
7. Lifecycle push notification automation
Lifecycle push automation organizes flows by where a customer is in their relationship with you — acquisition, onboarding, activation, engagement, retention, win-back, renewal and advocacy — rather than by campaign. Each stage has a customer state, a trigger that detects it, a message appropriate to it and a business objective. Mapping them makes coverage gaps visible, and most programs have the same gap: everything sits in engagement and nothing in win-back.
Campaign-level thinking asks "what should we send this month?" Lifecycle thinking asks "which stage is under-served?" The second question is more useful, because a customer in onboarding and a customer in win-back need opposite things — one needs orientation, the other needs a reason — and a program organized by campaign will send both of them the same October offer.
Eight stages, each with the customer state that defines it, the trigger that detects it, the message it calls for and the objective it serves. Use it as an audit: mark which stages you currently automate and which you do not.
| Stage | Customer state | Trigger | Recommended message | Business objective |
|---|---|---|---|---|
| Acquisition | Aware but not enrolled | Offer viewed, QR scanned, save page opened not completed | What they get for the thirty seconds it takes to join | Enrollment rate |
| Onboarding | Enrolled, no history yet | Pass saved / member created | What they now hold and the single next step | Time to first use |
| Activation | Enrolled, one interaction | First qualifying visit or first earn | Confirmation of progress and what is next | Second visit rate |
| Engagement | Using the program normally | Earning events, milestones, relevant offers | Progress, recognition and occasional relevant offers | Visit frequency and basket size |
| Retention | Slowing against their own pattern | Gap exceeds ~1.5× their typical interval | A reason to return that is not automatically a discount | Reduce drift into lapse |
| Win-back | Lapsed beyond any plausible cycle | Gap exceeds your defined lapse threshold | Something genuinely new or genuinely valuable | Reactivation rate |
| Renewal | Term-based relationship ending | Renewal date approaching | Value received, and exactly what happens next | On-time renewal; fewer involuntary lapses |
| Advocacy | Loyal, high tenure or high value | Milestone reached, referral made, tier held | Recognition and an easy way to bring someone in | Referrals and word of mouth |
Retention and win-back get skipped for the same reason: they are the only two stages where the trigger is an absence. Every other stage fires on something a customer did, which arrives in your data as an event. Nothing arrives when a customer quietly stops coming, so you have to go looking — which means defining what lapsing means for your business before you can automate anything about it. That definitional work, not the tooling, is why these stages stay empty.
- Lifecycle automation is organized by customer state, not by campaign calendar.
- Retention and win-back trigger on absence, which is why they are usually missing.
- Use the map as an audit before adding another engagement-stage flow.
8. Location and geofence push notifications
A geofence trigger fires when a customer enters, dwells in or leaves a defined radius — but the two wallet platforms document meaningfully different behavior, and conflating them is the most common factual error in this topic. Google's Wallet API documentation says a location object "is used for geofenced notifications" and that Google "will trigger a notification" when a user is within a set radius and dwells there. Apple's Wallet Passes documentation describes relevant locations as causing the system to display the pass on the Lock Screen, and states a pass "can have only 10 relevant locations."
Location is the most contextually powerful trigger available and the one most often described inaccurately by marketing material. The distinction that matters: a notification is pushed to the customer; a lock-screen pass suggestion is surfaced where the customer will see it if they look at their phone. Both are valuable. They are not the same mechanism, and a business planning a location program should know which one it is buying.
What each platform actually documents
| Aspect | Apple Wallet (Wallet Passes) | Google Wallet API |
|---|---|---|
| What location does | "the system can show it on the lock screen when it's relevant" — a display behavior | "Currently, this location is used for geofenced notifications" |
| Trigger condition | "passes with no relevant date display when one of the locations matches" | "When a user is within a set radius of this lat/long, and dwells there, Google will trigger a notification" |
| On leaving | Not described as a notification event | "When a user exits this radius, the notification will be hidden" |
| Location limit | "A pass can have only 10 relevant locations" | Not stated in the MerchantLocation reference |
| Beacons | "Add up to ten different UUIDs for iBeacons"; group beacons by UUID with different major/minor identifiers for more | Not applicable |
| Combining with time | "The system displays the pass on the lock screen if both the date and any location matches" | Not stated in the same reference |
Apple Developer — Showing a Pass on the Lock Screen (Wallet Passes) for relevance, the ten-location limit and the ten-UUID beacon limit. Google for Developers — MerchantLocation REST reference for the geofenced-notification behavior and the dwell/exit description. Both consulted 26 August 2026. Quotations are verbatim; the interpretation around them is ours.
Designing a location automation that is worth receiving
Proximity is a claim on someone's attention at a moment when they are physically doing something else. That raises the bar for the message, not lowers it. Four rules hold up in practice:
- One actionable thing. A proximity message that requires reading is a proximity message that gets dismissed. "Your free coffee is still on your card" works; a three-line description of a seasonal range does not.
- Opening hours only. A geofence that fires at 11pm outside a closed shop is worse than no geofence, because it trains people to ignore you.
- Radius follows the trip, not the map. A drive-to destination needs a wider radius than a high-street shop where a 100-metre radius is the difference between "you are outside" and "you are two streets away and not coming."
- Cap hard, per person. Someone who works next door will cross your fence ten times a week. Without a per-customer cap, your best local customer receives your most annoying automation.
Event proximity — surfacing a ticket or membership as someone arrives at a venue — is generally the strongest location use case, because the pass is the thing they need in that moment. Store proximity is weaker and more easily overused. In either case, do not assume a platform capability from a vendor's marketing page: check the current developer documentation for the wallet you are targeting, because Apple's and Google's behaviors differ and both change over time.
- Google documents geofenced notifications on dwell; Apple documents lock-screen pass display on relevance.
- Apple limits a pass to ten relevant locations and ten beacon UUIDs.
- Location messages need one actionable line, opening-hours gating and a hard per-customer cap.
9. How to build a push notification automation
Work through eleven steps: choose the business objective, define the customer event, define the audience, set the trigger, write the message, set the timing, set frequency limits, define the call to action, define the next action or exit, decide the success metric, then test and optimize. None of this requires code. The two steps people skip — the exit condition and the success metric — are the two that decide whether the automation becomes an asset or a nuisance.
Step 1 — Choose the business objective
Not "send a welcome message." Something you would report to an owner: more second visits, fewer expired rewards, higher on-time renewals. If the objective cannot be stated as a number moving, the automation has no way to be judged and will survive on vibes.
Step 2 — Define the customer event
Name the exact event in your data that represents the moment: pass_saved, stamp_added, reward_issued, days_since_last_visit = 30. If you cannot name it, you cannot trigger on it — and this is where most automation projects actually stall, in the data rather than the tool.
Step 3 — Define the audience
The event tells you when; the audience tells you who. Write both the inclusion rule (active loyalty members) and the suppressions (already redeemed, already in another flow, opted out, joined in the last 48 hours).
Step 4 — Set the trigger
Choose the family — state change, threshold, time condition or context — and prefer a threshold over a time condition wherever the data allows, because thresholds fire on evidence and time conditions fire on assumption.
Step 5 — Create the message
Lead with the customer's own fact, not your brand: "You're two stamps from a free lunch" beats "Don't miss out at Café Rossi." Keep it to one idea. Assume it is read on a lock screen in under two seconds, because it is.
Step 6 — Set timing
Define the delay relative to the trigger and the send window in the customer's local time. Immediate is right for confirmations. A short delay is right for anything that could feel like surveillance. A long delay is right for anything that needs the customer to have had a chance to act on their own.
Step 7 — Set frequency limits
Set a cap per customer across all automations, not per flow. Fatigue is cumulative and your customer does not know which flow a message came from. Also record the platform's own limits: Google's Wallet API documents a maximum of three notification-triggering messages and three notification-triggering updates in a 24 hour period.
Step 8 — Define the CTA
One action, expressed in the customer's terms. "Show your card on your next visit" is a CTA. "Learn more" is a shrug. Recognition messages are the one legitimate exception — a milestone message with no ask is often stronger than one with a discount attached.
Step 9 — Create the next action
Decide, before launch, what happens both ways. If they act: exit, and suppress from related flows for a period. If they do not: one escalation at most, then exit. An automation with no exit is a subscription to being ignored.
Step 10 — Measure the result
Pick one primary metric tied to the Step 1 objective, and hold out a random slice of the eligible audience from the start. A holdout is the only way to distinguish "this automation caused visits" from "these people were coming anyway."
Step 11 — Test and optimize
Change one variable at a time, in this order of expected impact: trigger (is it firing at the right moment?), then timing, then offer or value, then copy. Copy is the variable teams test first and the one that matters least.
Automation name: ______________________
Business objective: ______________________
Trigger event: ______________________
Entry conditions: ______________________
Suppressions: ______________________
Delay: ____________ · Send window (local): ____________
Message: ______________________
Personalization fields: ______________________
CTA: ______________________
Frequency cap (all flows): ______________________
Exit condition: ______________________
Escalation (if no action): ______________________
Primary success metric: ______________________
Holdout %: ____________ · Review date: ____________
- Automation projects stall in the data layer, not the tool — name the event first.
- Frequency caps belong at the customer level, across every flow.
- Test triggers and timing before copy; copy is the least impactful variable.
10. Push notification automation examples by business type
The triggers that matter differ by business because the events differ. A coffee shop automates around visit frequency, a gym around attendance and renewal, a salon around rebooking intervals, a Shopify store around restocks and VIP access, and an agency around running all of the above for many clients at once. The table below gives each a distinct starting automation rather than the same welcome flow ten times.
For each business type: the customer event worth building on, the automation it supports, an example message, the business goal and the KPI that would prove it worked.
| Business | Customer event | Automation | Example message | Business goal | Primary KPI |
|---|---|---|---|---|---|
| Restaurants | Booking confirmed for tomorrow | Pre-visit reminder with a pre-order or specials prompt | "See you tomorrow at 7:30. Tonight's specials are on your card." | Fewer no-shows, higher spend per cover | No-show rate |
| Coffee shops | Stamp count reaches N−2 | Near-reward nudge timed to the morning window | "Two more and your next flat white is free." | Compress the gap between visits | Average days between visits |
| Retail | Enters store radius during opening hours | Proximity reminder of unredeemed value only | "You're nearby — your £10 reward is unused." | Convert footfall passing by | Redemptions attributed to proximity |
| Salons & spas | Days since last appointment hits the rebooking interval | Rebooking prompt keyed to their own service cycle | "It's about six weeks since your last cut — Nadia has Thursday free." | Keep the chair full without discounting | Rebooking rate within the interval |
| Gyms | Attendance drops below their own baseline | Attendance-dip intervention before cancellation | "You trained twice this month, and eight the month before. Everything OK?" | Catch churn before the cancellation form | Cancellation rate in the following month |
| Fitness studios | Class credits nearing expiry | Credit-expiry flow with a bookable slot | "Three credits expire on the 30th. Saturday 9am has space." | Use up credits — used credits get repurchased | Credit utilisation rate |
| DTC brands | Consumable reaching typical replenishment point | Replenishment reminder based on their own cycle | "You're about due for a refill — same one, one tap." | Predictable repeat revenue | Repeat purchase rate |
| Shopify stores | Sold-out item back in stock, VIP tier held | Restock and early-access flow, VIPs first | "Back in stock. Members get four hours before it goes public." | Sell through drops without paid reach | Sell-through in the first 24 hours |
| Membership businesses | Renewal date approaching | Two-touch renewal flow with a value recap | "Your membership renews on the 14th. You came 31 times this year." | Renewals without involuntary lapses | On-time renewal rate |
| Agencies | A client's flow underperforms its holdout | Template a proven flow set and deploy per client, then monitor | Internal: "Client 7's win-back is below holdout — review offer." | Repeatable retention service across accounts | Flows live per client; client retention |
Notice that only two rows involve a discount. The strongest automations in most of these businesses are built on information the customer wants anyway — a booking they made, a credit expiring, a restock they asked about, value they already earned. Discount-led automation is easy to build, easy to copy, and trains customers to wait for the next one. Information-led automation compounds instead.
- Start from the events your business actually generates, not from a list of flows.
- Service businesses key on intervals; retail keys on inventory and proximity; memberships key on renewal dates.
- Information-led automations outlast discount-led ones.
11. Best time to send automated push notifications
There is no universally best hour, and any article that gives you one is generalizing across businesses whose customers behave nothing alike. For automated messaging the right time is defined relative to the trigger — minutes after a reward is earned, three days before an expiry, a set number of quiet days after a last visit — constrained by a send window in the customer's own time zone. Fixed-clock sending only makes sense for genuinely calendar-bound moments.
"Send at 10am" is advice for broadcast campaigns, and even there it is weak. In automation the question is not what hour but what offset. A reward confirmation at the moment of earning outperforms the same message at 10am tomorrow, not because 10am is bad but because the moment has passed. Once you think in offsets, "best time" resolves into eight variables you can actually control.
| Factor | What it changes | Practical rule |
|---|---|---|
| Customer behavior | When this person actually transacts | Time to their observed pattern, not the segment average |
| Time zone | Whether "10am" is 10am for them | Always send in local time; never in yours |
| Business type | When the decision is even possible | Send before the decision window, not during service |
| Purchase cycle | How long a nudge stays relevant | Short cycles tolerate shorter offsets and vice versa |
| Event urgency | How much delay is acceptable at all | Real deadlines compress everything; invented ones should not |
| Lifecycle stage | How much contact is welcome | Onboarding tolerates more frequency than dormancy |
| Previous engagement | How much benefit of the doubt you have | Reduce frequency for the persistently unengaged, don't escalate |
| Frequency | What else they've already received | Enforce the gap before the send, not after the complaint |
Three timing models, and when each applies
| Model | Timing is set by | Use it when | Failure mode |
|---|---|---|---|
| Fixed-time automation | The clock or calendar | The moment is genuinely shared — an opening, a holiday, an event date | Arrives while irrelevant to most recipients |
| Event-triggered automation | An offset from a customer event | Something happened that the message is about | Offset too long; the moment has cooled |
| Behavior-triggered automation | A pattern in behavior over time | The signal is a change in rhythm, including absence | Threshold set from an average rather than their own baseline |
Whatever your offsets, wrap every automation in a local-time send window, and hold any message that would land outside it until the window opens. A reward confirmation that arrives at 2am reads as a system error; the same message at 8am reads as a service. This single guardrail prevents more opt-outs than any amount of copy tuning.
- In automation, timing is an offset from an event — not an hour on a clock.
- Eight factors determine the offset; time zone and lifecycle stage are the most commonly ignored.
- A local-time send window is the highest-value guardrail you can add.
12. How to prevent push notification automation from becoming spam
Automation becomes spam when it keeps sending after it has stopped being useful — which is a design failure, not a volume problem. The fixes are structural: a customer-level frequency cap shared across every flow, suppression of anyone who already converted, exit conditions on every sequence, no offer that has already expired, and a rule that long-dormant contacts get fewer messages rather than more.
The instinct when an automation underperforms is to send more of it. That instinct is why most programs deteriorate. Every additional message spends the same finite permission, and permission is the only asset in this channel that cannot be bought back. The ten controls below are ordered by how much damage their absence causes.
| Control | What goes wrong without it | The fix |
|---|---|---|
| 1 · Frequency caps | Flows individually reasonable, collectively unbearable | One cap per customer across all automations, plus a minimum gap |
| 2 · Exit conditions | People keep hearing about something they already did | Exit on the target action; suppress from related flows after |
| 3 · Message relevance | Automation becomes a scheduled advert | Every message must be useful even if the offer is ignored |
| 4 · Segmentation | Right message, wrong person, repeatedly | Narrow entry conditions; explicit exclusions |
| 5 · Expired offers | A dead offer destroys trust in every future one | Validate expiry at send time, not at build time |
| 6 · Redundant notifications | Two flows describe the same event differently | Deduplicate by event; give one flow ownership of each event |
| 7 · Timing | Right message at a moment that reads as intrusive | Local-time send windows and sensible offsets |
| 8 · User preferences | Customers with no valve simply remove the pass | Offer a real choice of frequency or category |
| 9 · Inactive users | Escalating to people who have already left | Fewer messages over time, then a clean stop |
| 10 · Testing | Errors ship to the whole base at once | Test on a seed segment; check every dynamic field renders |
Run this before any automation goes live. An automation that fails any line is not ready — and in our experience the two most commonly missing are the last two.
- Clear trigger — one named event or condition, not a vague intent
- Relevant audience — entry conditions plus explicit suppressions
- Useful message — valuable even if the recipient ignores the offer
- Appropriate timing — offset defined, local send window applied
- Clear CTA — one action, in the customer's words
- Frequency limit — customer-level cap shared across all flows
- Exit condition — the automation knows when to stop
- Success metric — one primary metric, with a holdout group
Treating opt-out rate as the only spam signal. In wallet-based programs the loudest signal is quieter than an unsubscribe: the customer deletes the pass. That looks like list decay rather than a complaint, so it gets attributed to churn instead of to the automation that caused it. Track pass removals per flow, not just in aggregate.
- Spam is a design failure — the absence of caps, exits and suppressions.
- Message relevance means useful even when the offer is ignored.
- Track removals per flow; in wallet programs that is the real complaint rate.
13. How to measure push notification automation
Measure two layers and never confuse them. Operational metrics — delivery rate, open rate, click-through rate, opt-out or pass-removal rate — tell you whether the mechanics work. Business outcomes — conversion rate, revenue per automation, repeat purchase rate, retention, win-back rate, incremental revenue against a holdout, and customer lifetime value — tell you whether it was worth running. A flow can have an excellent open rate and negative value; only the second layer settles it.
Layer 1 diagnoses the machine. Layer 2 justifies its existence. Report Layer 2 to the business and use Layer 1 only to explain why Layer 2 moved.
Layer 1 — Operational metrics
| Metric | Definition | What a bad number means |
|---|---|---|
| Delivery rate | Messages that reached the device, of those sent | A technical or platform-limit problem, not a marketing one |
| Open rate | Delivered messages opened or interacted with | The message did not earn attention on the lock screen |
| Click-through rate | Opens that produced the intended tap | The CTA is unclear or the promise did not match the content |
| Opt-out / removal rate | Recipients who unsubscribed or deleted the pass | Frequency or relevance failure — check per flow, not in aggregate |
Layer 2 — Business outcomes
| Metric | Definition | Only trustworthy if… |
|---|---|---|
| Conversion rate | Recipients who took the target action in a defined window | The window is fixed in advance |
| Revenue per automation | Revenue from converting recipients, per flow | Attribution window is stated and consistent |
| Repeat purchase rate | Share purchasing again within a period | Compared against a matched holdout, not last year |
| Retention | Share of a cohort still active after N periods | "Active" is defined by your purchase cycle, not a default |
| Win-back rate | Lapsed customers who returned after the flow | Measured against untouched lapsed customers |
| Incremental revenue | Revenue above what the holdout produced | The holdout was randomly assigned before launch |
| Customer lifetime value | Expected value of a customer over the relationship | Cohort-based; applied to programs, not to single sends |
We deliberately quote no industry averages for any of these metrics. Published push benchmarks almost never disclose sample size, period and message mix together, and virtually none separate triggered messages from broadcasts — which makes them incapable of predicting what your welcome flow will do. The number that matters is your own flow measured against your own holdout. If you see a vendor chart claiming a specific lift for "automated push," ask for the sample, the period and the control group before you plan around it.
Withhold a random slice of every eligible audience — commonly 5–10% — from launch, and leave it untouched for a full purchase cycle. Retro-fitting a control group is impossible, and without one you cannot separate the automation's effect from the behavior of customers who were already engaged enough to trigger it. This is the single highest-value measurement decision available.
- Operational metrics diagnose; business outcomes justify. Report the second.
- Every outcome metric needs a stated window and a control group.
- Assign the holdout before launch — it cannot be added later.
14. Push notification automation for wallet marketing
Wallet-based engagement automates the same triggers as app or web push, but through a different object: a pass saved in Apple Wallet or Google Wallet. Updating or messaging that pass can produce a lock-screen notification, and because the pass itself carries state — a stamp count, a reward, a tier, an expiry date — the pass is simultaneously the message surface and the trigger source. That is the structural difference, and it changes how you design flows.
In app push, the notification and the customer's state live in separate places: the app holds the state, the notification is a pointer to it. In wallet, they are the same object. When a customer's stamp count changes from 6 to 7, the pass in their wallet changes, and that change is what generates the notification. This has two practical consequences: your triggers are naturally about progress and status rather than content, and the message and the record the customer checks later stay in sync automatically.
The wallet objects you can automate against
| Object | What it holds | Natural automation triggers |
|---|---|---|
| Wallet pass | The container: branding, fields, barcode, relevance data | Save, update, removal |
| Digital loyalty card | Stamp or point balance | Earn, near-reward threshold, reward issued |
| Membership card | Tier, member since, renewal date | Tier change, renewal approaching, lapse |
| Reward card | Unredeemed reward and its expiry | Reward earned, expiry approaching, redeemed |
| Coupon | Offer, code, validity window | Issued, expiring, redeemed |
| Wallet update | A change to any field on the pass | The update itself is the notification event |
App push, web push and wallet engagement are not the same thing
This distinction matters enough to state precisely, using each platform's own documentation rather than marketing language.
| Dimension | App push | Web push | Wallet-based engagement |
|---|---|---|---|
| Requires | App install + OS permission | Site visit + browser subscription | Saving a pass |
| Opt-in mechanic | Permission prompt | Browser prompt | The save is the opt-in |
| How a message is produced | You send a payload to a device token | You send to a browser subscription | You update or message the pass; Apple's flow pushes "an empty JSON dictionary for the payload" so the device fetches the updated pass |
| Platform frequency limits | Set by you and by user tolerance | Set by you and by browser policy | Google documents "a maximum of 3 messages that trigger a push notification in a 24 hour period" and the same cap on updates |
| Which changes notify | Any payload you choose to send | Any payload you choose to send | Google's update notifications are limited to specific allow-listed fields, and notifyPreference is "a transient field that only lives on this request" |
| Environment constraints | Sandbox and production | — | Apple: "A push notification for a pass update works only in the production environment" |
| Best content | Real-time, transactional, in-app | Content and site re-engagement | Loyalty, rewards, memberships, coupons, reminders |
It is a tempting line and it is inaccurate. Apple's pass-update push carries an empty payload whose purpose is to tell the device to fetch a new version of the pass, and it works only in production. Google's message and update notifications are capped at three per 24 hours each and only certain field changes are treated as notification-worthy. Wallet is a structured pass channel with platform-defined rules — which is a strength for loyalty automation and a genuine constraint for anything high-frequency.
- In wallet, the pass is both the message surface and the source of trigger state.
- Platform rules differ materially from app push and are documented — read them before designing cadence.
- Wallet suits loyalty, rewards, memberships, coupons and reminders; not high-frequency messaging.
15. Push notification automation without a mobile app
Yes — for a defined set of use cases, and it is worth being precise about which. A pass saved in Apple Wallet or Google Wallet gives a business a persistent mobile touchpoint that can be updated after the fact, producing lock-screen notifications without the customer installing a business app. That covers loyalty, rewards, memberships, coupons, renewals, appointments and reminders. It does not replace app push for high-frequency, in-product or transactional messaging.
The problem this solves is specific. Most small and mid-sized businesses want automated customer messaging and cannot justify a mobile app — not the build, and especially not the maintenance across two operating systems for years. The usual fallbacks each have a structural weakness: email competes with everything else in an inbox, SMS carries per-message cost and consent obligations, and social reach is rented. The wallet is unusual because the customer already has it, already trusts it, and does not have to install anything.
| Use case | Wallet fit | Why |
|---|---|---|
| Loyalty and stamp programs | Strong | The pass holds the balance; progress is the trigger |
| Rewards and expiry reminders | Strong | Real deadlines, already in the pass data |
| Memberships and renewals | Strong | Term dates are natural triggers; the card is used in person |
| Coupons and member offers | Strong | Redemption happens where the pass is presented |
| Appointments and reminders | Good | Date relevance and a card the customer keeps |
| Event and venue access | Good | The pass is the thing needed on arrival |
| Order and delivery status | Situational | Frequency and immediacy may exceed platform limits |
| High-frequency product messaging | Poor | Platform caps and pass semantics are not designed for it |
| In-product onboarding and support | Poor | There is no product surface to message inside |
| Rich interactive or media-led campaigns | Poor | Pass fields are structured, not a canvas |
The claim worth making is narrow and defensible: for certain customer-engagement use cases, a wallet-based pass can provide a persistent mobile touchpoint without requiring the customer to install a dedicated business app. The claim not worth making is that wallet replaces app push. It does not, and four of the ten rows above say so. If your automation needs are in the bottom four rows, build or buy for app push — our push notification tools buying guide covers those platforms, several of which are better at it than any wallet tool.
- A saved pass is a persistent mobile touchpoint that needs no app install.
- It fits loyalty, rewards, memberships, coupons and reminders — six of ten common use cases.
- It is a poor fit for high-frequency, in-product and media-rich messaging.
16. Push notification automation software: what to look for
Evaluate automation software on nineteen criteria, weighted by which triggers your business actually produces. A tool that cannot see your events cannot automate them, so trigger coverage and integrations matter more than workflow-builder aesthetics. If your program is loyalty-led and app-less, wallet support for both Apple Wallet and Google Wallet moves from a nice-to-have to a gating requirement.
| # | Criterion | What to ask |
|---|---|---|
| 1 | Trigger support | Which of your twenty triggers can it actually fire on, natively? |
| 2 | Segmentation | Attribute, behavioral and history-based — or just tags? |
| 3 | Automation workflows | Multi-step with branching, or single triggered messages only? |
| 4 | Scheduling | Local-time send windows and quiet hours, or server time only? |
| 5 | Behavioral rules | Can a rule reference past behavior, not just the current event? |
| 6 | Lifecycle automation | Can flows be organized and audited by customer stage? |
| 7 | Analytics | Per-flow reporting, and does it support holdout groups? |
| 8 | Frequency controls | Caps at the customer level across all flows, or per campaign? |
| 9 | Personalization | Which customer fields can appear in a message, and from where? |
| 10 | Wallet support | Native passes, or a bolt-on? |
| 11 | Apple Wallet support | Pass creation, updates and relevance handled for you? |
| 12 | Google Wallet support | Issued alongside Apple, with the platform's own limits respected? |
| 13 | Integrations | Does it connect to where your events are born — POS, booking, store? |
| 14 | Ease of use | Can the person who will actually run it build a flow unaided? |
| 15 | Testing | Seed sends, preview with real data, dry runs before go-live? |
| 16 | Templates | Starting points for the ten core flows, or a blank canvas? |
| 17 | Deliverability | What is reported, and is per-flow delivery visible? |
| 18 | Compliance | Consent capture, preference management, data handling and export |
| 19 | Pricing model | Does cost scale with audience, messages or features — and at your projected size? |
Ask a vendor to build your single most valuable automation in the demo, using your trigger, in front of you. Not a welcome flow — the one that depends on your own data. Whether that is possible in ten minutes, or requires a project, tells you more than any feature matrix. And ask specifically whether the tool can run a holdout group; many cannot, and without one you will never be able to prove what the automation did.
- Trigger coverage and integrations outrank workflow-builder polish.
- Frequency caps must work at the customer level, not per campaign.
- Holdout support is rarer than it should be — ask explicitly.
17. How PushNotice fits into push notification automation
PushNotice is a wallet-native customer engagement platform: it creates Apple Wallet and Google Wallet passes and sends wallet notifications without requiring customers to install an app. Within the automation landscape described above, it occupies the wallet lane — the loyalty, reward, membership, coupon and reminder triggers — rather than the app-push lane. If your program is loyalty-led and your customers will never download an app, that is the lane you need. If you need high-frequency in-app messaging, it is not.
PushNotice publishes this guide and PushNotice is our product. Everything above this section is written to be useful whether or not you ever use it. The capabilities described below come from PushNotice's own published product pages as of 26 August 2026; specifics that depend on current plans or on how a particular trigger is configured are marked to confirm against the live product rather than asserted here. We do not describe capabilities we have not published.
The reason wallet fits automation well is the one made in Section 14: the pass carries the customer's state. A stamp count, a reward, a tier and an expiry date all live on the object in the customer's pocket, which means the events that make good triggers are generated by the program itself rather than by an analytics integration you have to build first. For a business without an app and without an engineering team, that removes the step where most automation projects die.
| Area | What is published |
|---|---|
| Pass types | Loyalty cards with stamp tracking, membership cards with expiry and renewal, coupons and offers, reward and VIP cards, gift cards, event tickets |
| Platforms | Apple Wallet and Google Wallet, issued together; no app required for the customer |
| Distribution | QR codes and shareable save links; no customer account required to save a pass |
| Notifications | Lock-screen wallet notifications at pass level; manual campaign sends |
| Automation | Behavioral trigger automation, milestone-triggered messaging, expiry-based notifications, win-back automation for lapsed customers, behavioral drip sequences [confirm current trigger set] |
| Location | Location-based surfacing and per-location push for multi-location businesses [confirm per-platform behaviour] |
| Segmentation | Tagging and segmentation by tag and loyalty tier; RFM segmentation [confirm plan availability] |
| Analytics | Save rate, scan rate, redemption rate, repeat-visit rate; offer A/B testing [confirm holdout support] |
| Plans | Free plan at $0, Starter and Pro tiers, and an agency option with white-label capability [verify current plans] |
If you run a mobile app and need high-frequency, in-product, transactional messaging, a classic push suite is the right core system and we would tell you to start there. If your automation depends on events that live only in a system PushNotice does not connect to, solve the data question first — no automation tool can trigger on an event it cannot see. Wallet is a complementary channel that happens to be unusually well-suited to loyalty automation, not a universal replacement.
- PushNotice occupies the wallet lane: loyalty, reward, membership, coupon and reminder automation.
- The pass carrying customer state is what makes the triggers available without an integration project.
- It is not a substitute for app push in high-frequency or in-product messaging.
Frequently asked questions
Twenty questions people actually ask about push notification automation, answered in the shortest accurate form.
Fundamentals
What is push notification automation?
Push notification automation is the practice of using predefined triggers, customer behavior, timing rules and lifecycle conditions to send notifications automatically, instead of creating and sending every campaign by hand. You build the rule once — when this happens, to these people, send this, after this delay — and the system runs it for every customer who qualifies, indefinitely.
How do automated push notifications work?
An event happens in your data — a customer enrolls, earns a reward, crosses a milestone, or goes quiet. The automation checks its entry condition to see whether that customer qualifies, selects the message and any personalization, waits for the configured delay or send window, and delivers the notification. It then watches for the action it wanted and either exits the customer or moves them to the next step.
What is a push notification trigger?
A trigger is the event or condition that starts an automation. Triggers fall into four families: state changes (enrollment, tier upgrade, renewal), thresholds (points balance, visit count, reward earned), time conditions (expiry approaching, birthday, days since last visit) and context (entering a geofence, an event starting). The trigger answers when; the rule answers to whom.
What is the difference between scheduled and triggered push notifications?
A scheduled notification fires at a time you choose — the same moment for everyone in the audience. A triggered notification fires at a time the customer chooses through their behavior, so each person receives it at a different moment. Scheduled is calendar-relative; triggered is customer-relative. Most programs need both, but triggered messages are the ones that stay relevant without supervision.
Sequences & behavior
What is a push notification drip campaign?
A drip campaign is a sequence of messages sent at fixed intervals after a single entry event — for example day 0, day 2, day 5, day 10 and day 20 after a customer joins. The spacing is decided in advance rather than by what the customer does next, which makes drips ideal for onboarding and education and poor for anything that depends on live behavior.
How do behavioral push notifications work?
Behavioral push notifications are triggered by what a customer does or fails to do rather than by the calendar. The reusable pattern is event, segment, rule, message, timing, action: an event arrives, you narrow it to the segment it applies to, a rule decides whether to send, the message is composed with the customer's own data, timing decides when it lands, and the action you want defines the exit condition.
What is lifecycle push notification automation?
Lifecycle push automation organizes flows by where a customer is in their relationship with you — acquisition, onboarding, activation, engagement, retention, win-back, renewal and advocacy — rather than by campaign. Each stage has a customer state, a trigger that detects it, a message appropriate to it, and a business objective, so coverage gaps become visible.
What are the best push notification automations to build first?
Build in this order: welcome, reward-earned, expiring-reward, win-back, birthday, renewal, loyalty milestone, VIP, location-based offer, and re-engagement. The first three are the highest-return because they fire on events that already happen every day and confirm value the customer has already earned. Win-back is fourth because it reaches revenue you have otherwise lost.
How do you build a push notification automation?
Work through eleven steps: choose the business objective, define the customer event, define the audience, set the trigger, write the message, set the timing, set frequency limits, define the call to action, define the next action or exit, decide the success metric, then test and optimize. Skipping the exit condition and the success metric is what turns automations into noise nobody can evaluate.
Wallet, apps & platforms
Can push notifications be automated without a mobile app?
Yes, for a defined set of use cases. A pass saved in Apple Wallet or Google Wallet is a persistent mobile touchpoint that can be updated or messaged after the fact, producing a lock-screen notification without the customer installing a business app. It suits loyalty, rewards, memberships, coupons, renewals and reminders. It is not a general-purpose replacement for high-frequency in-app messaging.
What is wallet push?
Wallet push is a lock-screen notification produced by updating or messaging a pass the customer has saved in Apple Wallet or Google Wallet — a loyalty card, membership, reward card or coupon. Because the pass is a first-party wallet object, the save is the opt-in and no app install or classic push permission prompt is required.
Are Apple Wallet and Google Wallet the same as app push?
No, and the differences are documented by each platform. Apple's pass update flow sends a push carrying an empty JSON payload that tells the device to fetch an updated pass, and Apple states it works only in the production environment. Google's Wallet API caps notification-triggering messages and updates at three per 24 hours each and only treats certain field changes as notification-worthy. Both are structured pass channels with platform rules, not general-purpose app push.
How do location and geofence push triggers work?
A geofence trigger fires when a customer enters, dwells in or leaves a defined radius. The platforms behave differently. Google's documentation says a MerchantLocation is used for geofenced notifications and that Google triggers a notification when a user is within a set radius and dwells there, hiding it when they exit. Apple's documentation describes relevant locations as making the system display the pass on the Lock Screen, and limits a pass to ten relevant locations.
Timing, frequency & quality
What is the best time to send automated push notifications?
There is no single best hour. For triggered automations the right time is usually defined relative to the event — minutes after a reward is earned, days before an expiry, a set number of quiet days after a last visit — constrained by a quiet-hours window in the customer's own time zone. Fixed-time sending only makes sense for genuinely calendar-bound moments.
How often should automated push notifications be sent?
Set a per-customer cap across all automations rather than per campaign, because the fatigue a customer feels is cumulative. A common starting point for loyalty and offer messaging is a small number of messages per week with a minimum gap between any two. Note that platforms impose their own limits — Google's Wallet API documents a maximum of three notification-triggering messages in a 24 hour period.
How do you stop push automation from becoming spam?
Give every automation a clear trigger, a narrow audience, a message that is useful independent of the offer, a frequency cap shared across all flows, an exit condition so people stop receiving messages once they act, and a success metric. Suppress customers who already converted, never send an offer that has already expired, and stop messaging long-inactive contacts rather than escalating.
Measurement & tooling
What metrics should you track for push notification automation?
Track two layers. Operational metrics — delivery rate, open rate, click-through rate, opt-out or pass-removal rate — tell you whether the mechanics work. Business outcomes — conversion rate, revenue per automation, repeat purchase rate, retention, win-back rate, incremental revenue against a holdout, and customer lifetime value — tell you whether it was worth running. Only the second layer justifies the program.
Can automated push notifications be personalized?
Yes, and in automation the strongest personalization is structural rather than cosmetic. Using someone's first name is cosmetic; sending them a message because they are two stamps from a reward, or because their membership renews in seven days, is structural — the trigger itself carries the personalization, which is why behavioral automation outperforms broadcast without needing clever copy.
How do businesses automate customer retention notifications?
They define what lapsing looks like for their own purchase cycle, then automate a small set of flows around it: a welcome flow that establishes the habit, reward and milestone flows that confirm progress, an expiry flow that creates a deadline, and a win-back flow that fires after a defined quiet period. Each has an exit condition and is measured against a holdout group.
What should you look for in push notification automation software?
Check trigger coverage, segmentation, workflow building, scheduling, behavioral rules, lifecycle support, analytics with holdout testing, frequency controls, personalization, wallet support for Apple and Google Wallet, integrations, testing tools, templates, deliverability, compliance and pricing model. Weight them by which triggers your business actually generates — a tool that cannot see your events cannot automate them.
Glossary
| Term | Definition |
|---|---|
| Automation | A saved rule that sends a message when a defined condition becomes true, without a person pressing send. |
| Trigger | The event or condition that starts an automation — an enrollment, a reward earned, a period of inactivity. |
| Entry condition | The rule that decides which customers a trigger actually applies to. |
| Exit condition | The rule that removes a customer from a running automation, usually because they took the desired action. |
| Drip sequence | A time-based series of messages spaced by fixed delays after a single entry event. |
| Behavioral automation | Messaging triggered by what a customer does or fails to do, rather than by the calendar. |
| Lifecycle automation | Automation organized by customer stage — acquisition through advocacy. |
| Frequency cap | A limit on how many automated messages one customer can receive in a period. |
| Geofence trigger | An automation that fires when a customer enters, dwells in or leaves a defined geographic radius. |
| Wallet push | A lock-screen notification produced by updating or messaging a pass in Apple Wallet or Google Wallet. |
| Holdout group | A randomly withheld set of eligible customers used to measure the incremental effect of an automation. |
| Incremental revenue | Revenue attributable to an automation above what the holdout group produced without it. |
Methodology, sources & disclosure
This guide is published by PushNotice, reviewed by its editorial team, and written to be useful whether or not you use our product. Platform behaviors are quoted verbatim from Apple's and Google's official developer documentation with the date they were checked. No engagement benchmarks, conversion rates or customer results are quoted anywhere, because none we could find disclose sample, period and message mix together. Frameworks are labelled as our own analysis.
How this guide was researched
Every platform-specific claim in Sections 8 and 14 comes from Apple's Wallet Passes documentation or Google's Wallet API documentation, consulted on 26 August 2026, and is quoted verbatim where quoted at all. Where a behavior is not stated in the official documentation, we say so rather than inferring it. PushNotice capabilities in Section 17 come from PushNotice's own published product pages on the same date, with plan-dependent and configuration-dependent specifics explicitly marked to confirm.
Why there are no statistics in this article
This is deliberate, and it is the choice most likely to distinguish this page from others on the same topic. Push notification benchmarks are widely republished and rarely usable: they seldom disclose sample size, measurement period and message mix together, and almost never separate triggered messages from broadcast sends. Since the entire subject of this guide is triggered messaging, quoting a blended benchmark would be worse than quoting nothing. The timings and thresholds given throughout are calibration starting points derived from how each trigger behaves structurally, and every one of them is presented as something to test against your own holdout rather than a result to expect.
Editorial policy and conflict of interest
PushNotice sells wallet-native customer engagement, so we have a commercial interest in one of the seventeen sections above. We manage that the same way across this library: the product appears last, after the reader has everything they need to act without it; Section 15 lists four use cases where a wallet approach is a poor fit; Section 17 states plainly where a classic push suite is the better core system and links to competitors' category; and no PushNotice capability is described here that is not published by PushNotice. Nothing in this guide is paid placement.
Review and updates
Published 26 August 2026 and last reviewed 26 August 2026 by the PushNotice Editorial Team. Platform documentation changes; the quoted Apple and Google behaviors should be re-verified before being relied on for implementation. Corrections are welcome via the PushNotice contact page.
About the author
Sajid Ali — Founder & CEO, PushNotice. Sajid works directly on wallet pass design, pass-update and notification logic, and the retention automations built around them, and reads the Apple Wallet Passes and Google Wallet documentation as a working requirement rather than as research. That is the perspective behind this guide's insistence on separating what the platforms document from what marketing material claims. Connect on LinkedIn.
Reviewed by the PushNotice Editorial Team. The team verified every quotation in Sections 8 and 14 against the primary documentation, confirmed that no unsourced statistic appears anywhere in the article, and checked that every PushNotice capability claim in Section 17 corresponds to something PushNotice publishes.
Sources
- Apple Developer — Adding a Web Service to Update Passes (Wallet Passes). Source of the empty-payload push mechanism and the production-environment requirement. Consulted 26 August 2026. developer.apple.com
- Apple Developer — Showing a Pass on the Lock Screen (Wallet Passes). Source of relevance behavior, the ten-relevant-location limit and the ten-beacon-UUID limit. Consulted 26 August 2026. developer.apple.com
- Google for Developers — Trigger Push Notifications (Google Wallet API, loyalty cards). Source of the three-messages and three-updates per 24 hour limits, the
notifyPreferencebehavior, the allow-listed notifying fields, and theTEXT_AND_NOTIFYandTEXTmessage types. Consulted 26 August 2026. developers.google.com - Google for Developers — MerchantLocation (Google Wallet API REST reference). Source of the geofenced-notification behavior, including the dwell and exit description. Consulted 26 August 2026. developers.google.com
- PushNotice — published product and pricing pages, consulted 26 August 2026, for the capabilities listed in Section 17. pushnotice.io/wallet-marketing
Frameworks, matrices, checklists and timing recommendations in this guide are original PushNotice analysis and are labelled as such. They are offered as structures to test, not as findings.
Related guides
This page owns automation — triggers, sequences, workflows and measurement. For strategy, content and channel thinking, read push notification marketing. For choosing software, read the tools buying guide. For the wallet category as a whole, read what is wallet marketing. For retention beyond messaging, read customer retention strategies. Each covers a distinct question; none repeats this one.
Cite this guide
- APA: Ali, S. (2026). Push Notification Automation: Triggers, Drip & Behavioral Sequences. PushNotice. https://pushnotice.io/blog/push-notification-automation
- MLA: Ali, Sajid. "Push Notification Automation: Triggers, Drip & Behavioral Sequences." PushNotice, 26 Aug. 2026, pushnotice.io/blog/push-notification-automation.