Every Install, Scan, Notification, and Redemption Reported Inside Salesforce
Kemicard writes wallet activity back to the Contact and the Campaign, so pass programs are measured against the same objects and filters as the rest of your CRM. Installs, scans, notifications, and redemptions all land as Salesforce data — wallet pass analytics, natively in the reports and dashboards your team already uses.
Get It on AppExchangeWallet Pass Data Follows the Same Sharing Rules That Govern Every Other Object in Your Org
Visibility is controlled on the record itself. Change a permission set and report access changes with it, with no vendor seat to provision or take away.
Org-wide defaults apply as written
Pass event records inherit the sharing defaults set on the objects they are stored against. Nothing about wallet data creates an exception to your baseline.
Role hierarchy rolls up
A regional manager sees the pass activity for their branches and nothing above them, because the hierarchy that governs Contacts governs this too.
Report and dashboard folders
Wallet analytics live in your existing folder structure, so the conventions your team already follows for sharing reports cover them.
Sharing rules for chapters and departments
Multi-program orgs can give each team its own view of installs and scans using the criteria-based rules already in place.
Every Install, Scan and Removal Is a Record
Because the pass is issued from Salesforce, the events it generates land there too. The card below is the surface; the reporting is the same data seen from the other side.
Lakeside Market
The card. Each scan of this barcode is an event you can report on.
On the lock screen. Message sends and opens are measurable.
77 Foreshore Drive
Kelowna, BC V1Y 6G1
The back of the pass. Turning off updates is itself a signal.
Apple Wallet Install Analytics and Google Wallet Install Tracking in One Salesforce View
One template issues to both wallets, so both platforms report into the same place. The pass installation dashboard shows the Apple and Google split for a campaign without anyone merging two sources.
Install event per record
Each save writes a record carrying the timestamp, the platform, and the channel, attached to the Contact the pass was issued to.
Channel attribution built in
Email, SMS, QR, and landing page links each carry their own source, so install counts split by delivery channel without any tagging work.
Platform share per campaign
Apple and Google totals for the same audience, which tells you whether the next design decision should favor one wallet's layout behavior.
A working list of non-installers
Records that received a link and never saved the pass are a Salesforce report, so a follow-up Flow can act on them rather than a person exporting a spreadsheet.
Bring a campaign you have already run and see what it would have reported.
See the Analytics DemoA Pass Notification Delivery Report for Every Push, Broken Down by Campaign and Platform
Notifications are sent from Salesforce and reported in Salesforce. Each push writes what reached the device and what failed, against the records it targeted.
Per-push delivery counts
Sent and delivered against failed, for each individual push rather than a campaign average.
Scheduled push reporting
Delivery and outcome reports can run on a schedule through standard Salesforce automation, so the weekly number arrives without anyone building it.
Platform comparison on the same send
Apple and Google delivery for one notification side by side, which is where most delivery gaps actually show up.
Click-through and conversion per campaign
Notification click-through and the outcomes that followed, reported per campaign.
Google Wallet API Analytics and Apple Pass Events Landing in the Same Salesforce Objects
Apple and Google each expose pass activity in their own way. Kemicard receives both and writes them to the same objects, so a campaign report covers your whole audience with no platform caveat underneath it.
One event object for both wallets
Apple and Google activity write to the same records, with the platform stored as a field rather than as a separate table.
Standard report types
Wallet activity is reportable through normal report types, so anyone who can build a Salesforce report can build a wallet campaign report.
Joins to the revenue record
Because the event lives on the Contact, a scan can be reported alongside the renewal, the donation, or the opportunity that followed it.
Funnel stages as report groupings
Issued, installed, engaged, and converted are groupings on standard reports, which means the same funnel shape works for any program.
Install & Download Tracking by Template
Know how many passes are generated, downloaded, and installed, by template and by audience. Installation tracking lives on the pass records themselves, so segmentation is a standard report filter away — no exports and no external analytics tool.
- Installs and removals — see when a member added the pass and when they removed it.
- Template usage — compare adoption across tiers, campaigns, and event types.
- Channel attribution — measure QR, email, and SMS enrollment paths separately.
- Campaign integration — pass issuance and engagement report alongside your Salesforce Campaign activity.
Pass installs by month — built with the standard Salesforce dashboard builder.
From Wallet Event to CRM Insight
Engagement dashboards
Dashboards for downloads, template usage, and event attendance — feeding post-event campaigns and renewal outreach. Built from Kemicard objects during onboarding.
Notification performance
Delivery counts and response per campaign, so you can compare a renewal reminder against a flash offer and tune both.
Attendance & check-in
Every scan is a Salesforce record: who, when, where. Attendance and visit-frequency reports reuse across events.
Benefits & redemption reporting
Track member benefit usage and redemptions — how many times a privilege was used, by location and by date. Delivered as client-specific report packs by professional services.
Unified customer profiles
Wallet engagement writes back to the source Contact, enriching the same profile your service and marketing teams read.
Export & BI
Schedule report snapshots, export with standard tools, and feed downstream BI through Salesforce APIs.
Frequently Asked Questions
Wallet pass analytics in Salesforce use the standard report builder, so anything your admin can build for Contacts they can build for passes. Engagement dashboards are built from the Kemicard objects during onboarding, so you start from a working set rather than a blank page.
No. The Salesforce dashboard for wallet passes runs on records already in your org. If your team uses CRM Analytics or Tableau, those tools read the same objects, so nothing has to be duplicated to keep them fed.
Yes. Every event is a Salesforce record, so Flow can act on it. A scan can change a status, start a journey, or alert an owner, which means the same data drives both the report and the response.
Neither Apple nor Google exposes a per-push open rate for wallet passes, so no vendor can report one honestly. Wallet pass notification analytics here cover delivery per push plus what the holder did afterwards, which is the measurement that survives scrutiny.
Every install, scan, and notification is stored as a record, so volume grows with your program. For a large deployment, bring your expected pass and event volumes to a demo and we will walk through sizing and archiving options against your org's storage.
Events remain in your org as records, which means retention follows whatever data policy you already apply to Salesforce objects rather than a vendor's retention schedule.
The underlying mechanics differ, since Apple and Google publish pass activity through different interfaces. Kemicard normalizes both, so Google Wallet pass analytics and Apple install data read the same way in a single report.
Campaigns give you the cleanest funnel because membership ties issuance to outcomes automatically. Wallet campaign analytics in Salesforce still work without them, using any object you already group programs by.
Yes. Install and removal events are logged on the record, so you can see when a holder added the pass and when they removed it. Removal is a useful early churn signal, and teams who track it build re-engagement segments from it.
Pass events are standard Salesforce records, so they move through the same export tools and APIs as everything else in the org. No vendor-specific connector is involved.
Further reading
From the blog
Your Next Wallet Campaign Can Report Itself
We show Apple and Google pass events landing in the same records, then build the report on top of them.