Loop

Utilisez Loop pour répéter les mêmes étapes pour un utilisateur plusieurs fois sans les dupliquer sur le canevas. Il convient aux rappels, relances et vérifications qui doivent s’exécuter encore et encore, jusqu’à une limite que vous définissez. Après la dernière répétition, l’utilisateur passe à la partie suivante du journey.

Cas d’usage

• Rappels de paiement : envoyez un rappel et attendez le paiement. Les utilisateurs qui paient continuent et ne reçoivent plus de rappels. Les utilisateurs qui ne paient pas reçoivent un autre rappel après une pause, jusqu’à la limite que vous définissez.
• Récupérer les utilisateurs inactifs : envoyez un nombre limité de relances avec un délai entre elles. Après la dernière, dirigez les utilisateurs vers une offre différente ou arrêtez de leur envoyer des messages.
• Continuer à vérifier un événement : attendez le même événement encore et encore sans dupliquer l’étape d’attente sur le canevas.

Prérequis

Loop est désactivé par défaut. Pour l’utiliser, demandez au support Pushwoosh de l’activer pour votre compte.

Ajouter et configurer Loop

Construisez d’abord les étapes que vous voulez répéter, puis placez le Loop juste après elles. Le Loop a deux sorties :

• Repeat : une connexion de retour vers la première étape répétée. Les utilisateurs y retournent et repassent par les étapes.
• Exit : une connexion vers l’avant, vers ce qui vient après la boucle. Les utilisateurs y arrivent après leur dernière répétition.

Exemple : rappels de paiement

Sur le canevas, une boucle de rappel de paiement ressemble à ceci :

• Push : envoie le rappel.
• Wait for Trigger : attend le paiement. Les utilisateurs qui paient suivent leur branche de paiement et ne reçoivent plus de rappels. Les utilisateurs qui ne paient pas suivent Not triggered vers le Loop.
• Loop : Repeat renvoie les utilisateurs vers Push pour le rappel suivant.

1. Ajoutez l’élément Loop juste après les étapes que vous voulez répéter, et double-cliquez dessus.

2. Dans Maximum repeats, définissez combien de fois un utilisateur peut passer par les étapes répétées, de 1 à 100. La valeur par défaut est 10. Un nombre en dehors de cette plage revient à la limite la plus proche dès que vous enregistrez.

3. Dans Not more often than every, s, définissez la pause minimale entre deux répétitions pour un utilisateur, en secondes :

   • 0 : utilisez cette valeur lorsque les étapes répétées attendent déjà par elles-mêmes, avec une étape Wait for Trigger, une étape Time delay, ou un autre Loop ayant sa propre pause.
   • 60 ou plus : utilisez cette valeur lorsque rien dans les étapes répétées n’attend. Le Loop retient chaque utilisateur jusqu’à ce que ce délai se soit écoulé depuis sa dernière répétition. Si vous saisissez une valeur de 1 à 59, elle passe immédiatement à 60.

   Si vous laissez 0 mais qu’aucune des étapes répétées n’attend, le journey ne s’enregistrera pas et affichera The loop body has no waiting element, set a minimum interval. Sans aucune pause, la boucle se répéterait aussi vite que le système peut la traiter. Définissez 60 ou plus, ou ajoutez une étape Wait for Trigger ou Time delay aux étapes répétées.

   

4. Faites glisser une connexion depuis la sortie Repeat jusqu’à la première étape que vous voulez répéter. Dans l’exemple ci-dessus, il s’agit du rappel Push.

   Si Repeat n’est pas connecté, le journey ne s’enregistrera pas et affichera Connect the repeat output of the Loop. S’il mène au Loop lui-même, vous verrez The repeat output of the Loop cannot lead to the Loop itself.

5. Faites glisser une connexion depuis la sortie Exit vers l’étape qui doit venir après la boucle, par exemple un message final ou une offre différente. Les utilisateurs y arrivent une fois qu’ils ont parcouru la boucle Maximum repeats fois.

   

6. Cliquez sur Save.

Seul Repeat peut pointer vers une étape antérieure. Si vous connectez toute autre sortie à une étape antérieure du journey, le journey ne s’enregistrera pas.

Ce qui se passe à chaque répétition

Chaque étape de la partie répétée s’exécute à nouveau à chaque fois. Gardez ces règles à l’esprit lors de sa construction.

Les modifications de Tag s’accumulent

Une étape Update user profile à l’intérieur de la boucle s’exécute à chaque répétition. Ce que cela signifie dépend de l’action :

• Augmenter, diminuer, ajouter un élément de liste, supprimer un élément de liste : la modification s’accumule. Par exemple, avec Maximum repeats réglé sur 100, un Tag augmenté de 1 augmente de 100, pas de 1.
• Remplacer la valeur : sûr à répéter, car cela ne s’accumule pas.

Lorsque l’étape a une modification qui s’accumule, elle affiche un avertissement expliquant que la modification s’accumule à chaque répétition.

Les attentes recommencent à chaque répétition

Une étape Wait for Trigger ou Time delay compte son temps à partir de la répétition en cours, pas à partir du moment où l’utilisateur est entré dans la boucle. Une attente de 24 heures signifie 24 heures à chaque répétition, donc un utilisateur qui passe 3 fois par la boucle peut y passer jusqu’à 72 heures.

Les utilisateurs restent dans la même branche de test

Un A/B/n Split envoie chaque utilisateur vers la même branche à chaque fois qu’il l’atteint : à chaque répétition, et lorsqu’il rentre dans le journey plus tard. Un Holdout Split fonctionne de la même manière. Cela garantit l’exactitude des résultats des tests, car aucun utilisateur ne peut passer à une autre branche et être compté deux fois.

Wait for Trigger utilise l’événement le plus récent

Une étape Wait for Trigger dans la boucle conserve uniquement l’événement de la répétition en cours. Chaque nouvel événement remplace celui de la répétition précédente. Les étapes suivantes qui utilisent les données de l’événement obtiennent toujours l’événement le plus récent, y compris les espaces réservés de message, un Time delay dynamique, une valeur de Tag dynamique et un Condition split.

Les objectifs comptent une fois, les messages comptent à chaque fois

Un Objectif de conversion atteint à l’intérieur de la boucle compte une fois pour le journey, pas une fois par répétition.

Les messages fonctionnent différemment. Chaque répétition d’une étape de canal est un envoi distinct et compte dans la limite de plafonnement de la fréquence de l’utilisateur. Une étape Push qui se répète 10 fois peut utiliser jusqu’à 10 envois de cette limite, pas un seul.

Conseil

Pour vous assurer qu’un utilisateur ne reçoit pas plus de messages d’une étape que ce que permet la limite du canal, activez le plafonnement de la fréquence sur chaque étape de canal à l’intérieur de la boucle. Définissez la limite de l’une de ces manières, sinon l’étape restera illimitée :

• Dans les paramètres de plafonnement global de la fréquence.
• Avec un plafond personnalisé par étape.

Boucles imbriquées

Vous pouvez placer un Loop à l’intérieur de la partie répétée d’un autre. Chaque Loop compte ses propres répétitions. Le Loop interne recommence à compter à zéro chaque fois que les utilisateurs le quittent, il exécute donc à nouveau toutes ses répétitions à chaque répétition du Loop externe.

Par exemple, si le Maximum repeats du Loop externe est 3 et celui du Loop interne est 2, les étapes du Loop interne peuvent s’exécuter jusqu’à 2 × 3 = 6 fois. La limite combinée de 1000 répétitions s’applique toujours.

Limite de sécurité sur toutes les boucles

Un utilisateur peut passer par au maximum 1000 répétitions au total sur tous les Loop d’un journey, même si le propre Maximum repeats de chaque Loop en permet davantage.

• Un utilisateur qui atteint 1000 sort par le Exit du dernier Loop, même si la propre limite de ce Loop n’a pas encore été atteinte.
• Cette limite protège contre les boucles imbriquées dans des boucles qui se multiplient en bien plus de répétitions que prévu, par exemple deux boucles de 100 répétitions imbriquées l’une dans l’autre.