Les clients entreront dans une Series lorsqu'ils correspondent aux filtres de l'un des blocs de règles d'entrée. Tout bloc de règle placé au début d'un chemin est automatiquement défini comme règle d'entrée :

Vous pouvez avoir plusieurs blocs de règles, ce qui permettra aux clients d'entrer dans plus d'un chemin à la fois.

Oui, un User peut entrer plusieurs Series en même temps.

Il existe plusieurs façons pour un client de quitter une Series : il peut sortir conformément à vos règles de sortie, devenir désengagé ou terminer un chemin.

Dans les paramètres de votre Series, vous pouvez définir un ensemble de règles qui, si elles sont respectées, feront sortir un client de la Series. Les règles de sortie peuvent être basées sur n'importe quels attributs ou événements que vous suivez concernant vos clients ou leurs entreprises :

Si les données d'un client sont mises à jour pour correspondre à la règle, il sortira de la Series.

Pour un moyen simple de retirer des clients spécifiques d'une Series, ajoutez simplement une règle de sortie pour tous les clients avec un certain tag, puis vous pourrez l'appliquer au besoin à toute personne devant quitter la Series :

Lorsqu'un utilisateur final correspond à une règle de sortie dans une Series, il sortira immédiatement de cette Series et cessera de recevoir d'autres messages provenant de celle-ci. Cependant, l'utilisateur final peut réintégrer la Series si celle-ci autorise la réinscription, s'il ne correspond plus aux règles de sortie et qu'il correspond toujours aux règles d'entrée. Vous pouvez désormais ajouter plusieurs critères de sortie et ces users peuvent également suivre le flux et/ou.

Les événements de contenu comme Si l'utilisateur clique sur le message seront considérés comme remplis si le client a cliqué sur n'importe laquelle des versions de ce message qu'il a reçues précédemment, pas seulement lors de cette entrée et de ce parcours individuels dans la Series.

Par exemple, dans la Series ci‑dessous, si l'utilisateur entre le lundi et clique immédiatement sur un lien dans Email 1, il correspondra alors au deuxième bloc de règles et recevra Email 2.

Cependant, s'il réintègre la Series le mardi, il recevra de nouveau Email 1, et la règle Si cliqué sera automatiquement vraie car il avait précédemment cliqué sur un lien dans Email 1 lorsqu'il l'a reçu le lundi.

Après avoir effectué une modification pour empêcher les users de se désengager prématurément, les nouveaux users suivront le chemin original comme prévu ; cependant, un nouveau chemin devra être créé pour atteindre les users désengagés auparavant.

Il est important de noter que dans toute situation de désengagement, si le user se trouve dans d'autres chemins de la Series, il continuera sur ces chemins. Vous pouvez utiliser cela à votre avantage pour vous assurer que les users reçoivent les bons messages à l'avenir.

Si vous allez dans votre liste de users désengagés, vous pouvez appliquer un tag à tous ces users ⤵️

À partir de là, vous pouvez dupliquer le bloc de règles où les users se sont désengagés dans la Series. Une fois dupliqué, vous pouvez ajouter le nouveau tag créé pour vos users désengagés à ce bloc de règles.

Ensuite, nous connecterons ce bloc de règles dupliqué au bloc situé après le désengagement de l'utilisateur. Cela réintégrera l'utilisateur dans le chemin sur lequel il se trouvait déjà ⤵️

La seule réserve ici est que les messages ne seraient toujours pas délivrés aux personnes qui se sont désengagées en raison d'un échec d'email ou de notification push ; toutefois, cela garantit que ceux qui ont pu se désengager avant que vous ne le souhaitiez puissent recevoir les messages situés plus loin dans la Series.

Si un client atteint un bloc de règles qu'il ne correspond pas, ou un message qu'il ne peut pas recevoir, il attendra la période spécifiée dans le bloc :

Après cette période, s'il n'a toujours pas reçu le message ou ne correspond pas aux règles, il sera marqué comme désengagé et quittera ce chemin.

Cela peut arriver pour plusieurs raisons :

Dans n'importe laquelle de ces situations, si le user se trouve dans d'autres chemins de la Series, il continuera sur ceux-ci.

S'ils correspondent aux règles pour entrer dans un chemin différent à l'avenir, ils y entreront à ce moment-là.

S'il existe un chemin de repli pour les clients qui ne correspondent pas à un bloc de règles ou ne reçoivent pas un message, ils emprunteront ce chemin à la place et ne seront pas marqués comme désengagés :

Si un client atteint la fin d'un chemin dans la Series et n'a aucun autre contenu à recevoir (dans un autre chemin par exemple), il sera marqué comme « Terminé » et quittera la Series :

Les clients réintègrent une Series lorsque vous utilisez des règles d'entrée planifiées ou déclenchées par événement. Vous pouvez autoriser les clients à réintégrer la même Series plusieurs fois. C'est utile lorsque vous avez un ensemble de messages à envoyer aux clients lorsqu'un événement récurrent se produit, comme l'expiration d'un abonnement ou un achat.

Vous trouverez des options permettant aux users de Revenir plus d'une fois :

Ils peuvent toujours réintégrer si :

Chaque fois qu'un client se connecte à votre application ou visite votre site web et est suivi par Intercom, il entrera dans toute série où il correspond aux règles d'entrée d'un parcours.

S'ils ne se sont pas connectés ou n'ont pas visité votre site web, les règles d'entrée sont vérifiées une fois par heure pour toute personne devant entrer. Les blocs de règles au milieu d'un parcours (lorsque le client a déjà rejoint la série) sont vérifiés environ toutes les 30 minutes.

Le visiteur/lead est retiré de la série parce qu'il est supprimé lorsqu'il est fusionné dans le user.

Le user ne prend pas la place du visiteur/lead dans la série.

Pour cibler les clients en fonction de leur interaction avec une autre série, vous pouvez ajouter des règles d'engagement de série dans un bloc de règles.

Exemple : « Si un client a démarré series A, ne lui envoyez pas series B ».

Sélectionnez simplement l'événement sur lequel baser votre règle :

Ensuite, sélectionnez la condition (a ou n'a pas) et la série spécifique :

Si vous avez des blocs d'attente dans une série tels que Attendre d'être en ligne, le même user peut rester bloqué à ce bloc d'attente plusieurs fois pour plusieurs entrées/parcours. Puis, lorsqu'il finit par être en ligne, il recevra plusieurs fois le message qu'il attendait.

Dans l'exemple ci‑dessus, un user entre quotidiennement. Comme le user n'est pas encore en ligne, chaque entrée restera bloquée en attendant d'afficher le message postérieur. Ensuite, si le 8e jour le user se connecte enfin, on lui montrera la même publication 8 fois en une seule fois.

Pour résoudre cela et éviter une accumulation de nouveaux users à chaque bloc, mettez à jour les règles Attendre jusqu'à pour qu'elles correspondent à la même période que la période de réentrée multiple.

Atteindre un objectif de série n'exclura pas automatiquement un client de votre série ; si vous souhaitez qu'il sorte en atteignant l'objectif, vous devez également ajouter cela comme règle de sortie.

Pour les objectifs d'entreprise, la liste n'inclut pas un nom d'utilisateur, ni de boutons pour tagger ou envoyer des messages aux users.

Nous n'avons pas actuellement de façon de suivre plusieurs objectifs de Series.

Nous avons quelques solutions de contournement que vous pouvez essayer :

Ensuite, filtrez dans la liste Contacts pour obtenir les résultats (série rejointe + tags d'événements)

Si vous avez une série en cours, où des clients sont déjà entrés, il y a quelques points à considérer avant de la modifier.

Si vous supprimez une série en direct, tous les customers sortiront et ils ne recevront plus aucun contenu.

Oui, la suppression d’une Série supprime tous les messages sortants qu’elle contient. Envisagez de créer le message sortant de façon autonome et d’utiliser une copie dans la Série. Ainsi, si vous devez supprimer la Série, le message sortant autonome ne sera pas supprimé.

Oui, cela garantit que chaque série reste simple à gérer et fonctionne correctement. Limites actuelles en place :

Les limites strictes sont des limites importantes du produit pour protéger l’infrastructure et la capacité à traiter les Séries efficacement.

Les limites strictes sont décrites ci‑dessous :

Un edge connecte deux nœuds dans une Série.

Un nœud représente un bloc au sein d’une Série. Ils sont associés à un ensemble de règles (Ruleset), qui détermine ce qui se passe à ce nœud. Ils peuvent aussi contrôler le comportement, comme attendre avant de progresser le long de l’Edge approprié(s).

Il n’est pas possible de créer une série avec des boucles infinies où un customer revient à un point précédent de la série et reçoit à nouveau le même contenu. Vous verrez l’avertissement suivant si vous essayez :

Plusieurs options s’offrent à vous si vous souhaitez n’envoyer votre Série qu’aux personnes qui correspondent aux critères à l’avenir.

Vous pouvez fonder la règle d’entrée sur un attribut que les personnes ne correspondront qu’après aujourd’hui — par exemple, si c’est une Série d’intégration, vous pouvez utiliser "Signed up after [today's date]" :

Ou, si ce n’est pas un critère que vous pouvez facilement définir avec un attribut, vous pouvez plutôt *étiqueter* tous vos current users depuis la liste Contacts, puis exclure cette étiquette de la règle d’entrée de votre Série.

Si vous groupez vos users par entreprise dans Intercom, certaines choses sont à garder à l’esprit lors de la création de règles dans une série.

Si vous utilisez les données de l’entreprise dans un bloc de règles comme « Company size is greater than 50 », vos users seront évalués par rapport aux règles une fois par entreprise.

Par exemple, si vous avez un user qui est membre de deux entreprises de tailles différentes :

Cet user sera traité comme deux combinaisons distinctes d’utilisateur et d’entreprise :

Chacune de ces « versions » de l'utilisateur peut correspondre aux règles individuellement et suivre des chemins différents en conséquence. Ainsi, « User at company 1 » correspondrait à cette règle et suivrait le « Path 1 » :

Et « User at Company 2 » ne correspondrait pas, il suivrait donc le « Path 2 » :

Cela signifie qu'un seul user peut se trouver dans plus d'un chemin et recevoir des messages de chacun d'eux.

Si un user correspond à une règle avec plus d'une entreprise, plusieurs « versions » de cet user suivront le même chemin et recevront chaque message une fois par entreprise.

Donc si vous modifiez la règle dans cet exemple en « Companies with 20 people or more », « User at Company 1 » et « User at Company 2 » iraient tous les deux au message de « Path 1 », et l'utilisateur le recevrait pour chaque entreprise qui correspondait aux règles :

S'il n'y a pas de variable company ajoutée au corps (content) de votre message, il est normal que la Series envoie ce message plusieurs fois à un user s'il est associé à plusieurs entreprises. Cela se produit à cause du mécanisme de secours que nous utilisons lorsqu'aucune variable company n'est ajoutée.

Je recommande d'ajouter une variable company au corps de votre message pour éviter les doublons et résoudre ce problème. Avec une variable ajoutée, une copie du message sera envoyée uniquement pour chacune des companies de l'utilisateur qui correspond au bloc de règles.

Oui. La Series attendra le début des heures de bureau avant d'envoyer ce message à l'utilisateur, même s'il correspond plus tôt.

Il n'existe actuellement pas de moyen direct pour faire sortir les users d'une Series lorsqu'ils répondent à un message, mais vous pouvez y parvenir avec un bloc d'étiquetage.

Vous pouvez configurer un bloc de règle pour « Has replied to [message] » suivi d'un bloc qui tague l'utilisateur avec quelque chose comme « Exit ».

Et utilisez ensuite ce tag comme votre règle de sortie.

Vous pouvez même lister plusieurs messages dans le bloc de règle si vous souhaitez créer une règle qui vérifie si l'un quelconque des messages de la Series a reçu une réponse.

Pour ajouter une checklist que vous avez déjà créée à une Series, cliquez sur le bouton More en haut à droite de la Series et sélectionnez « Copy existing message into series » dans le menu déroulant. Ici vous pouvez sélectionner votre checklist. Pour automatiser les étapes de la checklist en fonction des attributs au niveau de l'entreprise, utilisez un attribut personnalisé company. Cela permet à l'étape de checklist d'être automatiquement résolue pour tous les users de cette entreprise une fois qu'un utilisateur a complété l'étape. Vous pouvez également cibler la checklist vers les owners au sein de l'entreprise en utilisant un attribut personnalisé, comme leur rôle d'owner.

Si vous souhaitez tester une Series avant de la mettre en ligne pour vos customers, ajoutez une règle d'entrée spécifique à votre adresse e-mail et seuls vous pourrez y entrer :

Par exemple, si vous testez une Series d'onboarding, vous devez vous inscrire comme nouveau user et effectuer les mêmes actions qu'ils effectueraient dans votre produit pour recevoir les messages de votre Series.

Ensuite, lorsque vous serez satisfait de ses performances, vous pourrez supprimer la règle d'adresse e-mail spécifique, et elle commencera à correspondre aux autres users.

Pour définir une date de début pour votre Series, vous pouvez ajouter un bloc d'attente après les règles d'entrée pour « Wait until [X date] », avant l'envoi de vos premiers messages.

Nous n'avons pas de fonctionnalité pour définir une date de fin pour une Series actuellement, mais une option serait de configurer un chemin séparé dans la Series avec les mêmes règles d'entrée et un bloc d'attente qui attend jusqu'à la date à laquelle vous souhaitez qu'elle s'arrête, ainsi qu'un tag block pour taguer les users à cette date, puis définir ce tag comme critère de sortie de la Series, afin que tous les users présents dans la Series après cette date soient tagués et immédiatement sortis.

​

Oui, vous pouvez consommer vos métriques Series en utilisant le content_stat.series Webhook. Souscrivez au topic content stat de la Series ainsi qu'à tout type de contenu pouvant être inclus dans une Series, et vous recevrez des notifications sur votre URL de point de terminaison lorsqu'un événement se produit.

Vous pouvez configurer tous vos messages dans un seul chemin à partir de leurs règles d'entrée, avec des flèches « If matched » menant au bloc suivant, faisant en sorte que vos messages soient toujours envoyés dans un ordre consécutif. Vous pouvez ajouter des flèches « If not matched » menant à des blocs ultérieurs si vous voulez qu'ils s'envoient dans l'ordre, mais avec la possibilité d'en sauter certains si l'utilisateur ne correspond pas. Ou, vous pouvez avoir plusieurs messages et chemins liés à votre règle d'entrée choisie pour permettre à tous les messages d'être envoyés à tout moment, dans n'importe quel ordre.

Non — il n'est pas possible de changer le type d'un e-mail Series en transactionnel après sa création.

Comme solution de contournement, recréez le message en tant que nouvel e-mail transactionnel sortant en utilisant un déclencheur d'événement en dehors de la Series.

Une fois qu'une personne correspond aux règles d'entrée et entre dans une Series, elle continuera dans la Series jusqu'à ce qu'elle la termine ou corresponde aux règles de sortie.

Si vous souhaitez que les Users qui ne correspondent plus aux règles d'entrée sortent, vous pouvez configurer des blocs de règle qui vérifieraient si le User/Lead correspond toujours avant d'envoyer le contenu suivant.

Autrement, vous pouvez mettre à jour les règles de sortie afin que dès qu'ils ne correspondent plus aux règles d'entrée, ils correspondent aux règles de sortie et quittent la Series.

« Try to match once » est utile pour les règles qui vérifient les attributs des users, mais ne dépendent pas de l'action de l'utilisateur. Pour les blocs de règle qui nécessitent que l'utilisateur effectue une action (par ex. se connecter pour recevoir un message in-app, ou ouvrir un e-mail), ils voudront utiliser « Try to match for X days/hours/minutes » pour donner du temps à l'utilisateur, sinon il vérifierait immédiatement cette action et passerait à la suite.

Il n'est pas possible d'accéder ou de restaurer une Series supprimée depuis votre espace de travail. Une fois qu'une Series a été supprimée, elle ne peut pas être récupérée ou consultée.

Si vous voyez un message d'erreur qui dit « A multi entry series must have a single starting point », cela indique que votre Series a plusieurs règles d'entrée et permet aux customers de rentrer plusieurs fois dans la Series, ce qui n'est pas pris en charge.

Customers peuvent rentrer plusieurs fois dans une Series mais en utilisant cette fonctionnalité, vous ne pouvez avoir qu'un Entry Rule Block pour la Series.

Pour résoudre l'erreur, retirez les blocs de règle d'entrée supplémentaires de la Series, ou mettez à jour les règles d'entrée afin qu'un customer ne puisse y entrer qu'une seule fois.

Pour comprendre pourquoi users qui n’auraient pas dû entrer dans la Série l’ont fait, vérifiez les horodatages du moment où les users sont entrés dans la Série et du moment où ils se sont désabonnés des e-mails.

S’ils sont entrés dans la Série avant de se désabonner de vos e-mails, ils correspondaient encore aux règles d’entrée de la Série à ce moment-là.

La raison pour laquelle vous voyez cette erreur est que vous utilisez une fonctionnalité spécifique dans votre Série qui ne fait pas partie de votre abonnement. Ces blocs apparaîtront en violet dans l’éditeur de Série.

​

Ce message d’erreur signifie généralement qu’un des nœuds internes n’est pas correctement connecté (et est donc perçu comme un nœud de départ) ou que le Teammate utilise autre chose qu’un bloc de règle comme nœud de départ de la Série.

Nous vous suggérons d’examiner attentivement les nœuds de la Série et d’identifier où se situe le lien manquant.

Les users peuvent ne pas entrer dans votre série en raison de divergences d’attributs lorsque les données du profil d’un user ne correspondent pas exactement aux conditions d’entrée de votre série. Cela se produit car les opérateurs de condition évaluent les données avec une précision stricte, et même de petites différences empêcheront l’entrée.

Si votre Série utilise un calendrier récurrent fondé sur un attribut (par exemple basé sur un attribut de date comme le renouvellement d’abonnement), la logique de planification peut empêcher l’entrée même si un user semble correspondre aux règles d’audience.

Ceci est un comportement attendu. La configuration du décalage de date dans le calendrier récurrent détermine la fenêtre d’entrée exacte. Vérifiez les paramètres de décalage de votre calendrier récurrent pour confirmer que la fenêtre correspond au moment où l’on s’attend à ce que le user soit qualifié.

Des erreurs dans la logique des règles, comme l’utilisation du mauvais opérateur ou la mauvaise configuration des chemins d’URL, peuvent empêcher les users d’entrer. Vérifiez vos conditions de règle et testez d’abord avec des critères simples.