# Recettes

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

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 de 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 timing et la personnalisation. The Wallet Crew exécute des actions Wallet telles que l’actualisation de carte, l’attribution d’avantage et les notifications Wallet.

L’intégrateur Bloomreach (équipe IT 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 mapping de données requis.

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

## Recettes

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

Notify envoie un message Wallet à une carte. Apple Wallet peut diffuser 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 %}

**Comment c’est généralement mis en œuvre**

* Utilisez l’ **Notifier** activité dans le scénario. Référez-vous aux attributs du scénario pour construire un message personnalisé.
* Si le message fait référence à du contenu de carte mis à jour, exécutez **Mettre à jour la Carte** d’abord, puis **Notifier**.
* Utilisez la segmentation et les plafonds de fréquence. Les messages Wallet ont un caractère système et peuvent être perçus comme intrusifs lorsqu’ils sont trop utilisés.

{% stepper %}
{% step %}

#### Définissez 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 basée sur le temps, selon le moment où la mise à jour de la carte doit se produire.

Confirmez ensuite que le contexte du scénario inclut un identifiant stable de carte. Cela maintient 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, par exemple `passId`.
{% endstep %}

{% step %}

#### Ajoutez l’activité Notify

Dans Bloomreach, ajoutez l’ **Notifier** activité 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 %}

#### Protégez-vous contre les cartes non installées

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

Schémas de protection 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 diffuser un lien « Add to Wallet ».
{% endstep %}

{% step %}

#### Validez la livraison sur de vrais appareils

La validation doit couvrir iOS et Android. Elle doit aussi couvrir à la fois les journaux et le comportement sur l’appareil.

Vérifiez les deux :

* les journaux d’activité Bloomreach.
* le comportement sur l’appareil (visibilité de la notification et rendu du message).

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é Appliquer un privilège)

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

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

Un privilège « VIP Weekend » est accordé à un segment. La carte affiche l’avantage et peut adopter un style « VIP » pendant que le privilège est actif.
{% endhint %}

**Comment c’est généralement mis en œuvre**

* Utilisez **Appliquer le privilège** pour attacher l’avantage à la carte.
* Configurez le modèle de carte pour afficher les privilèges et, le cas échéant, modifier le style en fonction des privilèges actifs.
* Vous pouvez éventuellement enchaîner avec **Notifier** pour annoncer l’avantage.

{% stepper %}
{% step %}

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

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

{% step %}

#### Créez le scénario Bloomreach

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

{% step %}

#### Appliquez le privilège

Ajoutez **Appliquer le privilège**, puis définissez à la fois le contenu et les règles du cycle de vie.

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

Pour l’audit et l’idempotence, utilisez un `processId` (ou un autre identifiant de corrélation) qui reste stable d’un essai à l’autre.
{% 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 **Mettre à jour la Carte** ensuite. Si l’avantage doit être mis en avant, enchaînez avec **Notifier**. L’ordre est généralement : mise à jour d’abord, puis notification.
{% endstep %}

{% step %}

#### Validez 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 visuels).
* Le cycle d’utilisation se comporte comme prévu.
  {% endstep %}
  {% endstepper %}

Référence associée : [Privilège](https://github.com/TheWalletCrew/docs/blob/main/documentation/privilege-and-activation/privilege.md).

### Scénarios de branchement selon le cycle de vie de la carte (The Wallet Crew → événements Bloomreach)

The Wallet Crew transmet les événements Wallet à Bloomreach. Ces événements rendent Wallet mesurable et déclenchable en tant que 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 donné, un e-mail de rappel est déclenché à la place.
{% endhint %}

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

* **Accueil uniquement après installation**: démarrez une série d’onboarding uniquement après `Wallet_installed`.
* **Supprimer les notifications Wallet**: n’exécutez pas Notify lorsqu’aucune installation active n’existe.
* **Signaux de churn**: 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 Scan API est connecté).

{% stepper %}
{% step %}

#### Confirmez le transfert des événements

`Wallet_created`, `Wallet_installed`, `Wallet_uninstalled`, et `Wallet_scanned` doit être visible dans Bloomreach. Cela dépend de la configuration du connecteur.

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

{% step %}

#### Démarrez 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 avec installation confirmée. Utilisez `Wallet_uninstalled` pour les flux de suppression et de reconquête.
{% endstep %}

{% step %}

#### Ajoutez de la déduplication et des fenêtres temporelles

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

Mesures de protection courantes :

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

{% step %}

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

Utilisez `appareil`, `registrationSource_medium`, et `registrationSource_tags` pour segmenter l’adoption et mesurer les performances du canal.

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

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

### Créez ou mettez à jour un contact Bloomreach à partir du formulaire d’inscription The Wallet Crew (CustomerFlowElement)

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

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

Après l’installation d’une carte, un formulaire d’inscription collecte 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 %}

**Comment c’est généralement mis en œuvre**

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

{% stepper %}
{% step %}

#### Définissez 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 dispose d’un identifiant 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 %}

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

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

{% step %}

#### Testez une soumission réelle

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

{% step %}

#### Démarrez 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 finalisation du profil.
{% endstep %}
{% endstepper %}

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

### Afficher les données Bloomreach sur la carte (CarteDataProvider + Mettre à jour la carte)

CarteDataProvider 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 s’exécute **Mettre à jour la Carte** afin que la carte affiche immédiatement le nouveau niveau.
{% endhint %}

**Note opérationnelle clé**

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

**Tutoriel (Bloomreach comme source de données de carte)**

{% stepper %}
{% step %}

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

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

{% step %}

#### Configurez CarteDataProvider

Activez CarteDataProvider pour le projet, puis confirmez quelles propriétés Bloomreach sont récupérées. Les conventions de nommage et les règles de mapping doivent être validées tôt afin d’éviter les écarts de champs entre les environnements.
{% endstep %}

{% step %}

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

Faites référence aux valeurs exposées par CarteDataProvider 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éclenchez des actualisations depuis Bloomreach

Créez un scénario déclenché par des changements de profil et ajoutez **Mettre à jour la Carte**. Lorsque le changement est sensible au temps, enchaînez avec **Notifier** afin qu’il soit visible sans ouvrir la carte.
{% endstep %}
{% endstepper %}

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

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

Ces recettes sont conçues comme des briques de base. En pratique, les scénarios enchaînent souvent la création de carte, l’actualisation de carte, l’attribution d’avantage et la messagerie.

Enchaînements courants :

* Mettre à jour la 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 Mettre à jour la carte et Notify ?</strong></summary>

Mettre à jour la carte modifie ce qui est affiché sur la carte. Notify attire l’attention via un message Wallet.

Lorsque le message fait référence à du contenu mis à jour, le schéma courant exécute d’abord Mettre à jour la carte, puis Notify.

</details>

<details>

<summary><strong>Que se passe-t-il si Notify ou Mettre à jour la 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 l’appareil vers laquelle l’envoyer. Notify ne peut pas être livré sans installation active.

Un repli courant utilise l’e-mail pour distribuer un lien « Add to Wallet », puis reprend les actions Wallet après `Wallet_installed`.

</details>

<details>

<summary><strong>Comment tester Notify sans perturber 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 l’état 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 un repli e-mail/SMS pour distribuer un lien « Add to 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 (visites multiples).

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 vérité pour les champs de carte ?</strong></summary>

Oui, lorsque CarteDataProvider 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: 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:

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

The question should be specific, self-contained, and written in natural language.
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.