# Recettes

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

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

* [Configuration](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/setup)
* [Activités Bloomreach](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/bloomreach-activities)
* [Événements](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/events)
* [Les composants de The Wallet Crew](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/the-wallet-crew-components)

### 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 le rafraîchissement de la Carte, l’attachement d’avantages 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 cartographier les données. [Configuration](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/setup) couvre les concepts requis de configuration et de correspondance des données.

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

## Recettes

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

Notify envoie un message Wallet à une Carte. Apple Wallet peut afficher une notification sur l’écran de verrouillage. 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 typiquement implémenté**

* Utilisez la **Notify** activité dans le scénario. Référencez des attributs du scénario pour construire un message personnalisé.
* Si le message fait référence à un contenu de Carte mis à jour, exécutez **Update pass** d’abord, puis **Notify**.
* Utilisez la segmentation et des limites de fréquence. Les messages Wallet donnent l’impression d’un niveau système et peuvent être perçus comme intrusifs s’ils sont surutilisés.

{% stepper %}
{% step %}

#### Définir le déclencheur et la cible de la Carte

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 de segment ou une règle temporelle, selon le moment où la mise à jour de la Carte doit se produire.

Puis confirmez que le contexte du scénario inclut un identifiant de Carte stable. 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 telle que `passId`.
{% endstep %}

{% step %}

#### Ajouter l’activité Notify

Dans Bloomreach, ajoutez l’ **Notify** activité depuis le catalogue d’activités The Wallet Crew. Définissez le contenu de la notification, puis personnalisez-le avec des attributs du scénario (par exemple nom du client ou 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 protéger contre les Cartes non installées

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

Schémas de garde courants :

* Déclencher 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 repli (email/SMS) pour distribuer un lien « Ajouter à Wallet ».
{% endstep %}

{% step %}

#### Valider la livraison sur des appareils réels

La validation doit couvrir iOS et Android. Elle doit aussi couvrir la journalisation et le comportement sur l’appareil.

Vérifier 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 connexe : [Activités Bloomreach](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/bloomreach-activities).

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

Apply privilege attache 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 de rédemption.

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

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

**Comment c’est typiquement implémenté**

* Utilisez **Apply privilege** pour attacher l’avantage à la Carte.
* Configurez le modèle de Carte pour afficher les privilèges et, le cas échéant, changer le style en fonction des privilèges actifs.
* Suivre éventuellement par **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. Puis confirmez que le modèle de Carte peut afficher les privilèges, soit sous forme de liste, soit sous forme de champs dédiés.
{% endstep %}

{% step %}

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

Sélectionnez un déclencheur qui représente l’éligibilité. Les options typiques incluent l’entrée de segment, le changement de niveau ou un jalon 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)

Pour l’audit et l’idempotence, utilisez un `processId` (ou un autre identifiant de corrélation) qui reste stable lors des nouvelles tentatives.
{% endstep %}

{% step %}

#### Rafraîchir et annoncer (optionnel)

Si le modèle de Carte rend les données de privilège depuis la charge utile de la Carte, ajoutez **Update pass** ensuite. Si l’avantage nécessite une attention, suivez par **Notify** . L’ordre est généralement update d’abord, puis notify.
{% endstep %}

{% step %}

#### Valider en staging

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 de vie de la rédemption se comporte comme attendu.
  {% endstep %}
  {% endstepper %}

Référence connexe : [Privilège](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/engage-and-animate/privilege-and-activation/privilege).

### Brancher les scénarios en fonction du 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 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 une fenêtre temporelle, un e-mail de rappel est déclenché à la place.
{% endhint %}

**Schémas de scénario courants**

* **Bienvenue seulement après installation**: lancer une série d’onboarding uniquement après `wallet_installed`.
* **Supprimer les notifications Wallet**: ne pas exécuter Notify lorsqu’aucune installation active n’existe.
* **Signaux de churn**: déclencher un flux de réactivation après `wallet_uninstalled`.
* **Déclencheurs post-visite**: déclencher un suivi après `wallet_scanned` (lorsque l’API Scan est connectée).

{% stepper %}
{% step %}

#### Confirmer le transfert d’é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 sont dans [Configuration](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/setup).
{% 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 confirmés par l’installation. Utilisez `wallet_uninstalled` pour les flux de suppression et de reconquête.
{% endstep %}

{% step %}

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

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

Mesures de protection courantes :

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

{% step %}

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

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

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

Référence connexe : [Événements](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/events).

### Créer ou mettre à jour un contact Bloomreach depuis le formulaire d’enrôlement 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 complète un flux d’enrôlement.

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

Après l’installation d’une Carte, un formulaire d’enrôlement 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 typiquement implémenté**

* Activer **CustomerFlowElement** dans le flux Wallet utilisé pour l’enrôlement.
* Mapper les champs du formulaire aux attributs de contact Bloomreach.
* Définir les règles de correspondance (email, téléphone, identifiant 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’email 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 est souvent une meilleure clé de correspondance car il évite les problèmes liés aux changements d’email.
{% endstep %}

{% step %}

#### Configurer le flux du formulaire d’enrôlement

Ajoutez **CustomerFlowElement** au flux d’enrôlement, 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 staging. 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 ultérieures.
{% endstep %}

{% step %}

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

Déclenchez des scénarios en aval après l’upsert du contact. Un schéma 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 connexe : [Les composants de The Wallet Crew](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/the-wallet-crew-components).

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

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 pass** 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 un rafraîchissement. Un rafraîchissement peut être déclenché par **Update pass** dans un scénario.

**Tutoriel (Bloomreach comme source de données de la Carte)**

{% stepper %}
{% step %}

#### Identifier les champs détenus par Bloomreach

Commencez par les champs de profil stables détenus par Bloomreach, tels que l’étiquette de niveau, les points, le magasin préféré ou les attributs de personnalisation. Gardez 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 confirmez quelles propriétés Bloomreach sont récupérées. Les conventions de nommage et les règles de correspondance doivent être validées tôt pour éviter la dérive des champs entre les environnements.
{% endstep %}

{% step %}

#### Rendre 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 staging, y compris les valeurs vides et les cas limites.
{% endstep %}

{% step %}

#### Déclencher des rafraîchissements depuis Bloomreach

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

Référence connexe : [Les composants de The Wallet Crew](https://app.gitbook.com/s/WLc8AHXW4tdrAXUBfrYF/connect/marketing-automation/bloomreach/the-wallet-crew-components).

### Combiner les recettes en campagnes multi-étapes

Ces recettes sont conçues comme des blocs de construction. En pratique, les scénarios enchaînent souvent la création de Carte, le rafraîchissement de Carte, l’attachement d’avantages et la communication.

Chaînes courantes :

* Update pass → Notify
* `wallet_installed` → série d’onboarding
* Soumission de formulaire d’enrôlement → upsert de contact → avantages basés sur le niveau

## FAQ

<details>

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

Update pass modifie ce qui est affiché sur la Carte. Notify attire l’attention via un message Wallet.

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

</details>

<details>

<summary><strong>Que se passe-t-il si Notify ou Update pass 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’y a pas d’installation d’appareil active vers laquelle pousser. Notify ne peut pas être livré sans une installation active.

Un repli courant utilise l’email 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 de vrais utilisateurs ?</strong></summary>

La plupart des équipes isolent le staging à deux niveaux.

Un token de projet Bloomreach de staging est utilisé avec un tenant The Wallet Crew de staging.

Les tests sont effectué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 garde.

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

Lorsque la garde échoue, utilisez un repli email/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, multi-appareils). Les scans peuvent se répéter (visites multiples).

La logique du 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 la Carte ?</strong></summary>

Oui, lorsque PassDataProvider est utilisé pour récupérer des attributs de profil. Les valeurs transactionnelles (commandes, rédemptions, soldes) restent souvent la propriété d’autres systèmes.

</details>