Events

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

The Wallet Crew sends wallet pass events through the brand's Bloomreach event API. Each event is associated with the customer through the pass's registered identifier or identifiers.

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.
• Link engagement: when a tracked pass link is opened, trigger a targeted follow-up.

Event list

Events are tracked in Bloomreach with the following event names:

• wallet_created
• wallet_installed
• wallet_uninstalled
• wallet_scanned
• wallet_linkOpened

Event data model

Events are sent as flat key/value properties. Every event includes these base properties:

• passType (string): pass type identifier.
• passId (string): pass identifier.
• passKind (string): pass kind, such as CustomerCard or EventTicket.
• identifier_<name> (string): one property for each pass identifier.
• metadata_<name> (string): one property for each non-null pass metadata entry.

Dots in an identifier name become underscores. For example, y2.customerId becomes identifier_y2_customerId.

Metadata properties with a null value are omitted.

Event definitions

Pass:Created

Sent when The Wallet Crew creates a wallet pass. This event has no properties beyond the base set.

Bloomreach event name: wallet_created

Pass:Installed

Sent when a pass is installed on a device. It can fire multiple times for the same pass.

Bloomreach event name: wallet_installed

Additional properties:

• device (string): Apple or Google.
• registrationInformation_totalRegistrationCount (string): total registrations.
• registrationInformation_activeRegistrationCount (string): active registrations.
• registrationSource_medium (string): included when set.
• registrationSource_origin (string): included when set.
• registrationSource_userAgent (string): included when set.
• registrationSource_tags (string): comma-separated tags, included when set.

All registrationSource_* properties are absent when the registration has no source information.

Pass:Uninstalled

Sent when a pass is uninstalled from a device.

Bloomreach event name: wallet_uninstalled

Additional properties:

• device (string): Apple or Google.
• registrationInformation_totalRegistrationCount (string): total registrations.
• registrationInformation_activeRegistrationCount (string): active registrations.

Pass:Scanned

Sent when a pass is scanned.

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

Bloomreach event name: wallet_scanned

Additional properties:

• scannedData (string): scanned value.
• scannedType (string): scanned type.

Pass:LinkOpened

Sent when a cardholder taps a tracked link embedded in a wallet pass.

Bloomreach event name: wallet_linkOpened

Additional properties:

• link_targetUrl (string): always included.
• link_device (string): Apple or Google, included when known.
• link_origin (string): included when known. This identifies the location in the pass the link was tapped from, such as BackField, FeaturedAction or LinksModule. The origin reference lists every value and what it means on each wallet.
• link_sourceId (string): included when set. This identifies the individual link within that location, such as a field key or a message identifier.
• link_language (string): included when the link was tapped in localized text. This is the language the cardholder saw.
• link_userAgent (string): included when known.

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.

Link engagement

wallet_linkOpened can trigger follow-ups after customers open tracked pass links. The link_origin property supports location-specific scenarios: Link tracking lists the values it can take and the source identifier that goes with each, and Measure link clicks in passes explains what tracking does to the destination URL before the customer reaches it.

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.