> 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/fr/marketing-automation/bloomreach/recipes.md).

# Recettes

Modèles de scénarios pratiques pour tirer parti de Bloomreach Engagement avec les cartes Apple Wallet et Google Wallet gérées dans The Wallet Crew.

Cette page rassemble des recettes pratiques pour exploiter l’intégration entre **Bloomreach Engagement** et **The Wallet Crew**.

Ces recettes complètent la documentation de référence :

* [Configuration](/connectors/fr/marketing-automation/bloomreach/setup.md)
* [Activités Bloomreach](/connectors/fr/marketing-automation/bloomreach/bloomreach-activities.md)
* [Événements](/connectors/fr/marketing-automation/bloomreach/events.md)
* [Les composants The Wallet Crew](/connectors/fr/marketing-automation/bloomreach/the-wallet-crew-components.md)

### Comment utiliser ces recettes

Les scénarios Bloomreach définissent le ciblage, le moment et la personnalisation. The Wallet Crew exécute des actions Wallet telles que l’actualisation de la carte, l’attribution d’avantages et les notifications Wallet.

L’intégrateur Bloomreach (équipe informatique ou partenaire d’implémentation) décide généralement quelles activités inclure et comment mapper les données. [Configuration](/connectors/fr/marketing-automation/bloomreach/setup.md) couvre les concepts de configuration et de mappage des données requis.

La plupart des équipes valident d’abord une recette de bout en bout dans l’environnement de préproduction. Les recettes sont ensuite combinées en scénarios à plusieurs étapes.

## Recettes

### Envoyer une notification push Wallet (activité Notify)

Notify envoie un message Wallet à une carte. Apple Wallet peut envoyer une notification sur l’écran verrouillé. Google Wallet affiche le message sur la carte.

{% hint style="info" %}
**Exemple :**

Lorsqu’une commande est livrée, une notification confirme que l’expédition est en cours.
{% endhint %}

**Mise en œuvre habituelle**

* Utilisez l’activité **Notify** dans le scénario. Référencez les attributs du scénario pour créer un message personnalisé.
* Si le message fait référence à un contenu de carte mis à jour, exécutez d’abord **Update carte** puis **Notify**.
* Utilisez la segmentation et des plafonds de fréquence. Les messages Wallet ont une apparence de niveau système et peuvent être perçus comme intrusifs s’ils sont trop fréquents.

{% stepper %}
{% step %}

#### Définir le déclencheur et la carte cible

Commencez par sélectionner la condition d’entrée du scénario. La plupart des configurations s’appuient sur un événement de commande, une entrée dans un segment ou une règle temporelle, selon le moment où la mise à jour de la carte doit avoir lieu.

Vérifiez ensuite que le contexte du scénario inclut un identifiant de carte stable. Cela garantit un ciblage cohérent entre les mises à jour et les appareils. Dans la plupart des implémentations Bloomreach, cet identifiant est stocké comme propriété client, telle que `passId`.
{% endstep %}

{% step %}

#### Ajouter l’activité Notify

Dans Bloomreach, ajoutez l’activité **Notify** du catalogue d’activités The Wallet Crew. Définissez le contenu de la notification, puis personnalisez-le avec les attributs du scénario (par exemple, le nom du client ou le numéro de commande). Lorsque le message fait référence au contenu de la carte, assurez-vous que les valeurs sont déjà à jour.
{% endstep %}

{% step %}

#### Se prémunir contre les cartes non installées

Les messages Wallet nécessitent au moins une installation active. Ajoutez une condition afin que Notify ne s’exécute que lorsque l’installation est confirmée.

Modèles de conditions courants :

* Déclenchez Notify uniquement après `wallet_installed`.
* Ajoutez une branche qui vérifie les indicateurs d’installation stockés dans Bloomreach.

S’il n’existe aucune installation active, utilisez un canal de secours (e-mail/SMS) pour distribuer un lien « Ajouter à Wallet ».
{% endstep %}

{% step %}

#### Valider la livraison sur de vrais appareils

La validation doit couvrir iOS et Android. Elle doit également couvrir à la fois la journalisation et le comportement sur l’appareil.

Vérifiez les deux :

* Journaux d’activité Bloomreach.
* Comportement sur l’appareil (visibilité des notifications et rendu des messages).

Lorsque le message fait référence à des champs mis à jour, validez d’abord la mise à jour.
{% endstep %}
{% endstepper %}

Référence associée : [Activités Bloomreach](/connectors/fr/marketing-automation/bloomreach/bloomreach-activities.md).

### Accorder un avantage et le refléter sur la carte (activité Apply privilege)

Apply privilege associe un avantage à une carte. Un privilège peut être un coupon, un droit d’accès ou un avantage avec un cycle de vie d’expiration et d’utilisation.

{% hint style="info" %}
**Exemple :**

Un privilège « Week-end VIP » est accordé à un segment. La carte affiche l’avantage et peut passer à un style « VIP » tant que le privilège est actif.
{% endhint %}

**Mise en œuvre habituelle**

* Utilisez **Apply privilege** pour associer l’avantage à la carte.
* Configurez le modèle de carte pour afficher les privilèges et, le cas échéant, modifier le style selon les privilèges actifs.
* Vous pouvez éventuellement poursuivre avec **Notify** pour annoncer l’avantage.

{% stepper %}
{% step %}

#### Créer le modèle de privilège dans The Wallet Crew

Commencez par définir le type de privilège et son cycle de vie. Vérifiez ensuite que le modèle de carte peut afficher les privilèges, soit sous forme de liste, soit dans des champs dédiés.
{% endstep %}

{% step %}

#### Créer le scénario Bloomreach

Sélectionnez un déclencheur qui représente l’éligibilité. Les options courantes comprennent l’entrée dans un segment, le changement de niveau ou une étape d’achat.
{% endstep %}

{% step %}

#### Appliquer le privilège

Ajoutez **Apply privilege**, puis définissez à la fois le contenu et les règles de cycle de vie.

* titre et description
* validité et expiration (le cas échéant)
* priorité (lorsque plusieurs avantages peuvent se chevaucher)

Chaque exécution de **Apply privilege** crée un nouveau privilège. `processId` prend en charge la traçabilité et la corrélation des campagnes. Il ne déduplique pas les privilèges.

Pour mettre à jour ou supprimer un privilège, utilisez son `privilegeId`. Bloomreach ne conserve pas `privilegeId` par défaut.

Utilisez une activité **Apply privilege** par carte et par campagne. Définissez systématiquement une `deletionDate` afin que les privilèges de campagne expirés soient nettoyés automatiquement.
{% endstep %}

{% step %}

#### Actualiser et annoncer (facultatif)

Si le modèle de carte affiche les données de privilège à partir de la charge utile de la carte, ajoutez **Update carte** ensuite. Si l’avantage doit être mis en avant, poursuivez avec **Notify**. L’ordre est généralement d’abord la mise à jour, puis la notification.
{% endstep %}

{% step %}

#### Valider en préproduction

La validation doit couvrir la création, le rendu et le comportement du cycle de vie.

* Le privilège existe dans The Wallet Crew.
* La carte le reflète (champs et éléments visuels).
* Le cycle de vie d’utilisation se comporte comme prévu.
  {% endstep %}
  {% endstepper %}

Référence associée : [Privilège](/guides-animation/fr/engager-and-animer/privilege-and-activation/privilege.md).

### Brancher les scénarios selon le cycle de vie de la carte (événements The Wallet Crew → Bloomreach)

The Wallet Crew transmet les événements Wallet à Bloomreach. Ces événements rendent le Wallet mesurable et déclenchable comme point de contact CRM.

{% hint style="info" %}
**Exemple :**

Après la création de la carte, un scénario attend `wallet_installed`. Si l’installation n’a pas lieu dans un délai défini, un e-mail de rappel est déclenché à la place.
{% endhint %}

**Modèles de scénarios courants**

* **Bienvenue uniquement après l’installation**: démarrez une série d’onboarding uniquement après `wallet_installed`.
* **Supprimer les notifications Wallet**: n’exécutez pas Notify lorsqu’il n’existe aucune installation active.
* **Signaux d’attrition**: déclenchez un flux de réactivation après `wallet_uninstalled`.
* **Déclencheurs après visite**: déclenchez un suivi après `wallet_scanned` (lorsque l’API Scan est connectée).

{% stepper %}
{% step %}

#### Confirmer la transmission des événements

`wallet_created`, `wallet_installed`, `wallet_uninstalled`, et `wallet_scanned` doivent être visibles dans Bloomreach. Cela dépend de la configuration du connecteur.

Les étapes de validation se trouvent dans [Configuration](/connectors/fr/marketing-automation/bloomreach/setup.md).
{% endstep %}

{% step %}

#### Démarrer un scénario sur un événement Wallet

Créez un scénario déclenché par un événement Wallet. Utilisez `wallet_installed` pour les flux où l’installation est confirmée. Utilisez `wallet_uninstalled` pour les flux de suppression et de reconquête.
{% endstep %}

{% step %}

#### Ajouter la déduplication et des fenêtres temporelles

Traitez les événements comme se produisant « au moins une fois » et prévoyez les doublons.

Protections courantes :

* Stockez un attribut `firstWalletInstalledAt` .
* Utilisez des fenêtres temporelles (exemple : ignorez les installations répétées dans les 24 h).
  {% endstep %}

{% step %}

#### Utiliser les propriétés d’événement pour la segmentation

Utilisez `device`, `registrationSource_medium`, et `registrationSource_tags` pour segmenter l’adoption et mesurer les performances des canaux.

Gardez la gouvernance à l’esprit lorsque vous transmettez des identifiants via des événements.
{% endstep %}
{% endstepper %}

Référence associée : [Événements](/connectors/fr/marketing-automation/bloomreach/events.md).

### Créer ou mettre à jour un contact Bloomreach depuis le formulaire d’inscription The Wallet Crew (CustomerFlowElement)

CustomerFlowElement connecte les soumissions de formulaires The Wallet Crew à Bloomreach. Il crée ou met à jour un contact Bloomreach lorsqu’un client termine un flux d’inscription.

{% hint style="info" %}
**Exemple :**

Après l’installation d’une carte, un formulaire d’inscription recueille le consentement et les données de profil. La soumission crée ou met à jour le contact Bloomreach, puis un scénario d’onboarding Bloomreach démarre.
{% endhint %}

**Mise en œuvre habituelle**

* Activez **CustomerFlowElement** dans le flux Wallet utilisé pour l’inscription.
* Mappez les champs du formulaire aux attributs de contact Bloomreach.
* Définissez les règles de correspondance (e-mail, téléphone, ID de membre, etc.) afin que les contacts soient résolus de manière déterministe.

{% stepper %}
{% step %}

#### Décider de la stratégie de résolution des contacts

Commencez par choisir quel identifiant Bloomreach est utilisé pour la correspondance des contacts. L’e-mail est courant, car il est largement disponible dans les modèles de données CRM. Lorsqu’un programme possède un identifiant de membre stable, cet identifiant constitue souvent une meilleure clé de correspondance, car il évite les problèmes liés aux changements d’e-mail.
{% endstep %}

{% step %}

#### Configurer le flux du formulaire d’inscription

Ajoutez **CustomerFlowElement** au flux d’inscription, puis mappez les champs du formulaire aux propriétés de contact Bloomreach. Lorsque le consentement est requis par la gouvernance, assurez-vous que les champs de consentement sont également collectés et mappés.
{% endstep %}

{% step %}

#### Tester une soumission réelle

Effectuez une soumission réelle avec une carte de préproduction. Vérifiez ensuite que le contact est créé ou mis à jour dans Bloomreach, et que les identifiants utilisés pour la correspondance restent cohérents entre les soumissions ultérieures.
{% endstep %}

{% step %}

#### Démarrer les scénarios en aval

Déclenchez les scénarios en aval après l’upsert du contact. Un modèle courant ne démarre qu’après `wallet_installed`, puis utilise la soumission du formulaire comme étape de complétion du profil.
{% endstep %}
{% endstepper %}

Référence associée : [Les composants The Wallet Crew](/connectors/fr/marketing-automation/bloomreach/the-wallet-crew-components.md).

### Afficher les données Bloomreach sur la carte (PassDataProvider + Update carte)

PassDataProvider récupère les attributs client depuis Bloomreach et les expose au rendu de la carte. Cela fait de Bloomreach une source de données pour les valeurs affichées sur les cartes Apple Wallet et Google Wallet.

{% hint style="info" %}
**Exemple :**

Lorsqu’un attribut de niveau change dans Bloomreach, un scénario exécute **Update carte** afin que la carte affiche immédiatement le nouveau niveau.
{% endhint %}

**Note opérationnelle essentielle**

Les données Bloomreach apparaissent sur la carte après une actualisation. Une actualisation peut être déclenchée par **Update carte** dans un scénario.

**Tutoriel (Bloomreach comme source de données pour les cartes)**

{% stepper %}
{% step %}

#### Identifier les champs gérés par Bloomreach

Commencez par les champs de profil stables gérés par Bloomreach, tels que le libellé de niveau, les points, le magasin préféré ou les attributs de personnalisation. Conservez les valeurs transactionnelles dans leur système de référence lorsque des contraintes d’exactitude ou d’audit s’appliquent.
{% endstep %}

{% step %}

#### Configurer PassDataProvider

Activez PassDataProvider pour le projet, puis vérifiez quelles propriétés Bloomreach sont récupérées. Les conventions de nommage et les règles de mappage doivent être validées tôt afin d’éviter la dérive des champs entre les environnements.
{% endstep %}

{% step %}

#### Afficher les attributs dans le modèle de carte

Référencez les valeurs exposées par PassDataProvider dans les champs du modèle. Validez ensuite les valeurs rendues sur une carte de préproduction, y compris les valeurs vides et les cas limites.
{% endstep %}

{% step %}

#### Déclencher les actualisations depuis Bloomreach

Créez un scénario déclenché par des changements de profil et ajoutez **Update carte**. Lorsque le changement est sensible au temps, poursuivez avec **Notify** afin qu’il soit visible sans ouvrir la carte.
{% endstep %}
{% endstepper %}

Référence associée : [Les composants The Wallet Crew](/connectors/fr/marketing-automation/bloomreach/the-wallet-crew-components.md).

### Combiner les recettes en campagnes à plusieurs étapes

Ces recettes sont conçues comme des blocs de construction. En pratique, les scénarios enchaînent souvent la création de cartes, l’actualisation des cartes, l’attribution d’avantages et la messagerie.

Enchaînements courants :

* Update carte → Notify
* `wallet_installed` → série d’onboarding
* Soumission du formulaire d’inscription → upsert du contact → avantages basés sur le niveau

## FAQ

<details>

<summary><strong>Quelle est la différence entre Update carte et Notify ?</strong></summary>

Update carte modifie ce qui est affiché sur la carte. Notify attire l’attention au moyen d’un message Wallet.

Lorsque le message fait référence à un contenu mis à jour, le modèle courant exécute d’abord Update carte, puis Notify.

</details>

<details>

<summary><strong>Que se passe-t-il si Notify ou Update carte s’exécute sur une carte qui n’est pas installée ?</strong></summary>

L’activité cible toujours un enregistrement de carte, mais il n’existe aucune installation active sur un appareil vers laquelle envoyer une notification. Notify ne peut pas être livré sans installation active.

Une solution de secours courante utilise l’e-mail pour distribuer un lien « Ajouter à Wallet », puis reprend les actions Wallet après `wallet_installed`.

</details>

<details>

<summary><strong>Comment tester Notify sans déranger les vrais utilisateurs ?</strong></summary>

La plupart des équipes isolent la préproduction aux deux niveaux.

Un jeton de projet Bloomreach de préproduction est utilisé avec un tenant The Wallet Crew de préproduction.

Les tests sont exécutés avec un petit ensemble de cartes de test installées sur des appareils internes.

</details>

<details>

<summary><strong>Comment empêcher Notify si la carte n’est pas installée ?</strong></summary>

Utilisez le statut d’installation comme condition.

Les modèles courants consistent à déclencher Notify uniquement après `wallet_installed`, ou à maintenir un attribut « isInstalled » dans Bloomreach.

Lorsque la condition échoue, utilisez une solution de secours par e-mail/SMS pour distribuer un lien « Ajouter à Wallet ».

</details>

<details>

<summary><strong>Le même événement d’installation ou de scan peut-il se produire plusieurs fois ?</strong></summary>

Oui. Les installations peuvent se répéter (réinstallation, plusieurs appareils). Les scans peuvent se répéter (plusieurs visites).

La logique de scénario utilise souvent des règles de déduplication basées sur `passId` et des fenêtres temporelles.

</details>

<details>

<summary><strong>Bloomreach peut-il être la source de référence pour les champs de carte ?</strong></summary>

Oui, lorsque PassDataProvider est utilisé pour récupérer les attributs de profil. Les valeurs transactionnelles (commandes, utilisations, soldes) restent souvent gérées par d’autres systèmes.

</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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.