# Events

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

<details>

<summary><strong>Real-world examples</strong></summary>

* **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.

</details>

### 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

<details>

<summary><strong>Pass:Created</strong></summary>

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.

</details>

<details>

<summary><strong>Pass:Installed</strong></summary>

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.

</details>

<details>

<summary><strong>Pass:Uninstalled</strong></summary>

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.

</details>

<details>

<summary><strong>Pass:Scanned</strong></summary>

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

{% hint style="info" %}
For this event to be triggered, the [Scan API](https://docs.thewalletcrew.io/develop/guides/scan-api) must be invoked by the scanning system.
{% endhint %}

**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.

</details>

### 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

<details>

<summary><strong>Can the same event fire multiple times for the same pass?</strong></summary>

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

</details>

<details>

<summary><strong>How fast do events appear in Bloomreach?</strong></summary>

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

</details>

<details>

<summary><strong>How to avoid triggering scenarios twice on multiple installs?</strong></summary>

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

</details>

<details>

<summary><strong>Can events be used for segmentation and for scenario triggers?</strong></summary>

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.

</details>

<details>

<summary><strong>Can events be renamed / filtered before ingestion?</strong></summary>

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](https://docs.thewalletcrew.io/connect/marketing-automation/bloomreach/extensibility).

</details>