> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/connectors/marketing-automation/bloomreach/events.md).

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

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

</details>

### Event list

Events are tracked in Bloomreach with the following event names:

* `wallet_created`
* `wallet_installed`
* `wallet_uninstalled`
* `wallet_scanned`
* `wallet_linkOpened` **(new)**

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

<details>

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

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

**Bloomreach event name:** `wallet_created`

</details>

<details>

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

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.

</details>

<details>

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

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.

</details>

<details>

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

Sent when a pass is scanned.

{% hint style="info" %}
For this event to be triggered, the [Scan API](/developers-guides/integration-guides/scan-api.md) must be invoked by the scanning system.
{% endhint %}

**Bloomreach event name:** `wallet_scanned`

**Additional properties:**

* `scannedData` (string): scanned value.
* `scannedType` (string): scanned type.

</details>

<details>

<summary><strong>Pass:LinkOpened</strong></summary>

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 pass location, such as `Homepage`, `HelpUrl`, or `AppDeepLink`.
* `link_sourceId` (string): included when set.
* `link_userAgent` (string): included when known.

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

#### Link engagement

`wallet_linkOpened` can trigger follow-ups after customers open tracked pass links. The `link_origin` property supports location-specific scenarios.

### 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](/connectors/marketing-automation/bloomreach/extensibility.md).

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.thewalletcrew.io/connectors/marketing-automation/bloomreach/events.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.