Wallet notifications: copy, audience and timing

Start with one useful fact and one action the customer can take. A reward that is ready to redeem is a clearer reason to check a loyalty card than a generic reminder that the business exists. Set the offer, eligibility and end date before writing the message.

Keep three events separate: the loyalty system records a change, the saved card receives an update, and the device shows an alert. A successful step does not prove that the next one happened. This guide covers how to plan and check that sequence, with illustrative messages and a measurement example you can adapt to your own rules.

For an updatable Apple pass, the issuer signals that a new version is available. The registered device can then request the updated pass. The push signal is not a general promotional message sent straight to the lock screen. Record acceptance of that signal separately from whether the new pass and an alert appeared. [1]

Apple can describe a changed pass field using a change message. That mechanism is tied to the changed value, and Apple says this field-change message is not used on Apple Watch. Verify the behavior on the devices your customers actually use. [2]

The customer controls Wallet notification and location settings. In a test, check those settings before treating a missing alert as a failed campaign. A device setting is one possible explanation, not evidence that every problem is on the customer's phone. [4]

Google supports a message added to a loyalty pass with a notification request. It limits notification-triggering messages to three per pass within 24 hours and can throttle misuse. Treat that as a technical ceiling, not a recommended campaign schedule. [5]

An ordinary object change is not automatically a notification request. Google supports notifications for specified updates; the notification preference applies to that request rather than permanently enabling future alerts. Check that your provider supports the intended event. [6]

Users manage Wallet notification preferences themselves. Confirm them on a test device using Wallet settings. The sender cannot turn a provider-accepted request into proof that the recipient enabled, saw or read an alert. [7]

Write the selection rule before choosing the audience size. For a reward reminder, establish that the reward is still available at the time of preparation. For a birthday message, use a birthday the customer actually provided. Keep the rule small enough that a staff member can explain why a card was included.

BlackCards provides campaign audiences such as all customers, birthdays, Apple or Google cards, recent loyalty activity, available rewards and saved segments, with a card-program filter. Review the program and audience-selection rule before scheduling; the recipient-card list appears when the campaign runs. A label such as today's visitors is based on recorded loyalty activity; it is not proof of a physical visit or live location.

Put the useful fact first, then give the next step and the essential condition. Staff should be able to apply the offer as written. Avoid putting private customer information in text that could appear on a visible lock screen.

The following examples are fictional copy, not offers issued by BlackCards. Adapt the reward, expiry, eligible branch and language to the actual program. Do not promise a free item to a card that has not earned it.

Maintain a clear distinction between a balance or redemption update and an optional marketing campaign. BlackCards campaign preparation checks the recorded wallet-marketing choice for the eligible audience. That is different from the operational path used to keep an installed card current.

Review consent status and queued campaigns when a customer asks to stop marketing. Do not assume that changing a preference instantly recalls every delivery already prepared or accepted. Confirm the state of the campaign and the available cancellation action before reporting that it has stopped.

Document the customer's request, apply it through the appropriate process, and keep operational updates focused on the loyalty service. For a launch in a new market, check the applicable consent and messaging requirements for that operation; a saved pass by itself is not your complete marketing permission record.

BlackCards schedules campaigns in the store's time zone. Check the date and time shown before confirming: a due time is a scheduling instruction, not a guarantee of an alert at an exact second. Processing cycles, connectivity and the wallet provider affect what happens next.

For GCC planning, Saudi Arabia, Kuwait, Qatar and Bahrain use UTC+3; the UAE and Oman use UTC+4 in the current time-zone data. Thus 18:00 in Riyadh corresponds to 19:00 in Dubai. Keep the location and date in the planning sheet instead of sharing an unlabeled clock time. [8]

Choose a period when the business can fulfil the offer and the customer has time to use it. Set a practical pause between related messages, and check for overlap with automated reminders. The best interval depends on the purchase cycle and customer feedback; no single hour or frequency is proven best for all six markets.

Location relevance is a separate mechanism from a scheduled marketing message. Apple lets an issuer supply relevant locations and distance information, while the system controls how relevance is evaluated. It does not establish a guaranteed alert radius or prove that a person entered a store. [3]

Google's nearby experience depends on eligible merchant locations and the user's notification and precise, always-on location settings. Google controls the resulting notification's timing, distance and text. Keep this separate from a campaign whose copy the merchant writes. [5]

A card surfacing near a shop is not a visit, purchase or redemption. Use verified visit or purchase records for those outcomes, and completed redemption records for redemptions. Test location behavior separately from ordinary message delivery.

Use test cards controlled by your team and a real rule sheet. Test the supported Apple and Android paths separately; observing one device does not validate every device or every customer's settings. Record the time and the state before and after the action.

A useful test ends with evidence about each step, including a missing result. If the card updated but no alert appeared, record exactly that. Repeatedly sending the same message while diagnosing can create duplicates later and consume the provider's limits.

BlackCards campaign follow-up records delivery at card level, including provider acceptance, pending or unsuccessful outcomes, attempts and their times. A card-level row is not necessarily one unique person. Keep that distinction when comparing the report with a customer list.

Provider acceptance is not a read receipt. A tracked action-link click shows that the tracking link was opened; it does not establish that a wallet alert caused the click or that a purchase followed. Likewise, a scan and a completed reward redemption are different events.

Choose the question before choosing the metric. Use delivery states to diagnose processing, tracked clicks to examine the action link, and verified loyalty actions for redemption analysis. If an open or display measure is unavailable, label it unavailable rather than assigning a zero or inferring it from acceptance.

Define the unit, eligible group, outcome and follow-up period before sending. For a card-level reward reminder, an outcome might be at least one recorded redemption within 14 complete days. Count each eligible card once for that outcome, and treat any comparison of unique people as a separate analysis. The 14-day window in this example is a separate manual analysis, not a configurable attribution window in the BlackCards campaign dashboard. The current scheduled-campaign flow uses a 30-day attribution window; keep those reports separate.

For example, suppose 100 eligible cards each have a full 14-day observation window and 18 record at least one qualifying redemption. The observed card-level redemption rate is 18 ÷ 100 × 100 = 18%. These are fictional numbers, not BlackCards results, and the denominator is eligible cards rather than assumed readers.

That rate does not show how many redemptions the notification added. Purchase habits, other promotions and selection into the audience can affect it. For a more informative comparison, plan an appropriate randomized holdout for an optional promotion while preserving benefits already owed to customers. Record allocation and eligibility in advance; do not call a small difference a proven uplift. The stamp-program guide linked below explains cohorts and attribution in more detail.

Does “unlimited notifications” in a plan override wallet rules? Plan allowances and provider controls are separate. Device preferences, Google limits and the supported behavior of each wallet still apply. Confirm the intended workflow for your plan rather than promising unlimited visible alerts.

Can the same message be assumed to appear identically on every phone? Check the actual devices, card layout and language. A successful test on one combination is a useful observation, not a universal display guarantee.

Can a loyalty-activity segment tell you who walked into a branch? It can identify recorded activity under its selection rule. For an actual store-visit claim, you need a suitable independent source.

Before expanding, keep a short campaign record: purpose, eligible cards, consent check, message version, local schedule, device-test result, delivery states and the observation window. Use those findings to improve the next campaign, and confirm any unsupported step with the team setting up your BlackCards program.