How to Track Wallet Pass Analytics: Open Rates, Scans and Push Performance

Apple Wallet and Google Wallet do not expose an analytics dashboard. There is no built-in report showing you how many customers opened their pass today, how your latest push notification performed or what percentage of issued passes have been scanned. This is not an oversight — Apple and Google deliberately limit the data they surface to protect user privacy. But it creates a real problem for businesses that need to understand whether their wallet pass programme is working. Here is everything you can track, how to track it and which metrics actually matter.

What Apple and Google do not expose

Let us be direct about the gaps before covering what is possible. Apple Wallet does not provide a view count for passes. You cannot tell how many times a customer has opened a pass, how long they spent looking at it or whether they tapped the back fields. Apple provides no consumer-facing analytics data to pass issuers.

Google Wallet is slightly more informative through the REST API — the pass object has a state field (ACTIVE, COMPLETED, EXPIRED, INACTIVE) — but it does not report a view count or engagement time either. Neither platform provides click-through data on back-field links.

What this means is that your analytics layer must be built on the server-side events your infrastructure can observe, not on platform-side engagement data you cannot access.

What you can track

1. Pass add events

Every time a customer adds your pass to their wallet, your server has a record of it. For Apple Wallet, the device calls your webServiceURL registration endpoint immediately after the pass is added. This registration payload includes the device library identifier, the pass serial number and a push token. Log this event with a timestamp and you have a complete record of every pass add, by pass and by time.

For Google Wallet, the pass object state transitions from a pre-issued state to ACTIVE when the user saves it. You can poll the Google Wallet REST API to check object states, or — better — log the pass creation event and treat first-use confirmation (a scan or state poll showing ACTIVE) as the add confirmation.

The key metric here is your pass add rate: the percentage of customers who received a pass distribution link and actually added the pass to their wallet. Industry benchmarks vary by sector and distribution method. Email-distributed passes to warm audiences (existing customers) typically see 30–60% add rates. Cold audiences or poorly designed landing pages can drop to under 10%.

2. Push notification delivery receipts

When you send a push notification to Apple Wallet passes, APNS returns a response for each push token. A successful delivery returns HTTP 200. Errors indicate whether the token is invalid (device unregistered, pass removed), whether the rate limit was exceeded or whether there was a temporary failure. Log every APNS response against the pass record.

Google Wallet push does not use APNS. A PATCH to the Google Wallet object API with anaddMessageRequest body returns a success or failure response synchronously. Log these responses.

From these logs, you can calculate your push delivery rate: the percentage of pushes that returned a successful delivery response. A declining delivery rate typically indicates pass removals — customers who deleted the pass from their wallet, causing their push token to become invalid.

3. Scan events

When your scanner reads a barcode from a wallet pass, you control the validation system. Log every scan event with a timestamp, the barcode value, the pass serial number (resolved from the barcode), the scanner location and the validation outcome (valid, already used, expired). This gives you a complete redemption history per pass.

Key metrics from scan data: scan rate (percentage of active passes that have been scanned at least once), redemption velocity (how quickly passes are redeemed after issue) and repeat scan rate (for loyalty cards where multiple scans per pass are expected).

4. Pass update fetches (Apple Wallet)

Apple Wallet calls your webServiceURL endpoint to fetch an updated pass bundle whenever it receives an APNS push signal. This call is not precisely a “pass open” event — it happens when the device processes a push, not necessarily when the user views the pass. But it does confirm that the device received and acted on the push. Log these fetch requests: they are your closest proxy to push open rate on Apple Wallet.

5. Google Wallet object state

The Google Wallet REST API allows you to GET any pass object and read its current state. ACTIVE means the pass is in the customer's wallet. COMPLETED means the pass has been used and marked complete (for single-use passes). EXPIRED means the expiry date has passed. INACTIVE means the pass was deleted or deactivated.

Polling object states periodically (nightly is sufficient for most use cases) gives you a current picture of your pass population: how many are active, how many have expired, how many were deleted. The deletion rate — INACTIVE objects — is a signal worth monitoring; a spike suggests a poor experience or irrelevant notifications.

6. Pass removal events (Apple Wallet)

Apple Wallet sends a deregistration call to your webServiceURL when a customer removes a pass from their wallet. Log these events. The pass removal rate— the percentage of added passes that are subsequently removed — is one of the most important health indicators for a wallet pass programme. A high removal rate signals that passes are not delivering enough value, or that push notifications are being sent too frequently.

Building a simple analytics layer

You do not need a complex data warehouse to track wallet pass analytics. The minimum viable analytics stack has four components:

1. An events table in your database. Log every observable event — pass issued, pass added (registration), push sent, push delivered, push failed, pass fetched, pass scanned, pass removed (deregistration) — as a row with a timestamp, pass ID and event type.
2. A pass state table. Track the current state of every pass: issued, active (added to wallet), removed, expired. Derive this from your events log.
3. Aggregate queries. Weekly queries against your events table produce the metrics you need: pass add rate for the past 30 days, push delivery rate, scan rate, removal rate.
4. Alerting on anomalies. A sudden spike in deregistrations or a push delivery rate drop below a threshold warrants investigation. Simple threshold alerts on your aggregate metrics catch problems early.

Metrics that actually matter

Not all metrics are equally actionable. Focus on these:

• Pass add rate — are your distribution efforts converting? If this is below 25%, your distribution email, landing page or pass design needs work.
• 30-day active rate — what percentage of added passes are still in customer wallets 30 days after issue? Declining retention is an early warning sign.
• Push delivery rate — what percentage of sent pushes were successfully delivered? A falling rate indicates pass removals.
• Scan rate — for redemption passes (coupons, event tickets), what percentage of issued passes were scanned? Low scan rates suggest barriers at the point of redemption.

How Issuepass surfaces these metrics

Issuepass logs every pass lifecycle event — add, removal, push delivery, scan — and surfaces them in the dashboard as real-time metrics. You can see your pass add rate by distribution campaign, your push delivery rate per send and your overall active pass count without building any custom analytics infrastructure.

For teams who need deeper analysis, every event is available through our API so you can pipe it into your own data warehouse or BI tool.

Start free and start tracking your wallet pass programme performance from day one.