Events

Events sent from The Wallet Crew to Bloomreach for segmentation, automation, and measurement.

The Wallet Crew emits events to Bloomreach so scenarios can react to wallet behavior. This makes the wallet pass a measurable CRM touchpoint.

Real-world examples

• Onboarding: when a pass is installed, trigger a welcome series.
• Win-back: when a pass is uninstalled, trigger a light reactivation flow.
• In-store: when a pass is scanned, trigger a post-visit survey or a reward.

Event list

Events are tracked in Bloomreach with the following event names:

• wallet_created
• wallet_installed
• wallet_uninstalled
• wallet_scanned

Event data model

Events are sent as flat key/value properties. Two property name prefixes are patterns:

• identifier_xxx: one property per pass identifier (email, memberId, etc.).
• metadata_xxx: one property per metadata key stored on the pass.

When a source key contains ., it is normalized to _. Example: identifier key y2.customerId becomes identifier_y2_customerId.

Event definitions

Pass:Created

Fires when The Wallet Crew generates a new pass. This is mainly useful for auditing and “created but not installed” flows.

Bloomreach event name: wallet_created

Properties:

• passId: The Wallet Crew pass identifier.
• passKind: High-level pass category (customerCard, eventTicket, giftCard, offer, generic).
• passType: Template identifier used to create the pass.
• identifier_xxx: All identifiers present on the pass.
• metadata_xxx: All metadata keys present on the pass.

Pass:Installed

Fires when a customer adds a pass to Apple Wallet or Google Wallet. It can fire multiple times for the same pass (re-install, multiple devices).

Bloomreach event name: wallet_installed

Properties:

• passId
• passKind
• passType
• identifier_xxx
• metadata_xxx
• device: apple or google.
• registrationInformation_totalRegistrationCount: Lifetime install count, after this install.
• registrationInformation_activeRegistrationCount: Active installs, after this install.
• registrationSource_medium: Tracking medium (email, sms, qr, in_app, ...).
• registrationSource_tags: Tracking tags captured during installation.
• registrationSource_userAgent: Browser/device user agent.
• registrationSource_origin: Origin URL where the installation started.

Pass:Uninstalled

Fires when a customer removes the pass from their wallet. This is a churn signal and a suppression signal.

Bloomreach event name: wallet_uninstalled

Properties:

• passId
• passKind
• passType
• identifier_xxx
• metadata_xxx
• device: apple or google.
• registrationInformation_totalRegistrationCount: Lifetime install count, after this uninstall.
• registrationInformation_activeRegistrationCount: Active installs, after this uninstall.

Pass:Scanned

Fires when the pass barcode or QR code is scanned. This is the strongest “in-store / at-venue” behavioral signal.

For this event to be triggered, the Scan API must be invoked by the scanning system.

Bloomreach event name: wallet_scanned

Properties:

• passId
• passKind
• passType
• identifier_xxx
• metadata_xxx
• scannedData: Raw decoded value captured at scan time.
• scannedType: Barcode/QR symbology.

Scenario patterns

Engagement and re-engagement

A common pattern uses wallet_installed for welcome flows. wallet_uninstalled can drive win-back flows and suppression rules.

Behavioral triggers

wallet_scanned can trigger post-visit messaging. It can also be used to build segments based on recent store or venue visits.

FAQ

Can the same event fire multiple times for the same pass?

Yes. This is expected for installs (multiple devices, re-installs) and scans (multiple visits).

How fast do events appear in Bloomreach?

This depends on network conditions and Bloomreach ingestion. In typical setups, events are delivered in seconds.

How to avoid triggering scenarios twice on multiple installs?

Scenarios can use deduplication rules based on passId and time windows. Another common approach stores “installed once” flags as customer attributes.

Can events be used for segmentation and for scenario triggers?

Yes. Once ingested, events can be used in Bloomreach the same way as other tracked events.

Events can be used to build segments based on recency and frequency. They can also be used as triggers to start or branch scenarios.

Can events be renamed / filtered before ingestion?

Yes. The connector can intercept events before sending them to Bloomreach.

This is used to rename event names, add or remove properties, or drop events entirely. Details: Extensibility.