Piano analytics a mis en ligne il y a quelques semaines une nouvelle fonctionnalité, appelée sobrement « funnel », qui vient compléter le toolkit des analyses séquentielles déjà disponibles. Celle-ci propose de visualiser les volumes, les taux de passages et le temps moyen pour des séquences de plusieurs évènements que vous allez pouvoir définir.

C’est l’occasion de vous expliquer le fonctionnement de cette nouvelle feature, ses principales différences avec les outils de séquences déjà disponibles (l’analyse « Navigation » et la segmentation séquentielle) et finalement quelques use cases afin que vous puissiez vous projeter dans son utilisation. A noter qu’il s’agit à l’heure actuelle d’un MVP, et que de nouvelles fonctionnalités sont à venir très prochainement (enregistrement des templates, partages, breakdown).

Présentation de l’interface

La fonctionnalité est disponible depuis Data Query, en allant dans « Nouveau » > « Créer un rapport tunnel » :

Dans le menu supérieur, vous retrouvez le même menu que Data Query, avec :

• La sélection de votre/vos site(s) de niveau 1 (et oui, vous pourrez créer un tunnel multi-sites) (1)
• La selection de la période d’analyse (2)
• La barre de segment (et oui, vous pourrez segmenter un tunnel) (3)

La zone de gauche va vous proposer de choisir le premier évènement que vous souhaitez cibler dans votre tunnel (4), ou le segment que vous souhaiteriez éventuellement appliquer (5)

Finalement, la bande « configuration » vous propose de choisir la granularité de votre tunnel (visites, visiteurs, users). (6)

Création de votre premier tunnel

Maintenant que l’interface est présentée, créons ensemble notre premier tunnel ! Voici le cas que nous allons traiter : sur un site e-commerce, nous allons recréer un tunnel complet de notre parcours d’achat, en y incluant à la fois les évènements Sales Insights, mais aussi les évènements de connexion au compte (trackés en pages vues).

La première étape pour vous va être ici de déterminer les évènements représentant chaque étape. Dans mon cas les voici :

• cart.display (affichage du panier)
• page.display (page de connexion)
• cart.delivery (choix mode de livraison)
• cart.payment (choix mode de paiement)
• transaction.confirmation (confirmation de l’achat)

Nous allons donc placer ces évènements sur la timeline du tunnel :

La deuxième étape sera de définir si des filtres doivent être placés sur certains évènements. Dans mon cas je vais devoir préciser que l’évènement page.display concernant la page de connexion au compte client. Je vais ainsi cliquer sur l’évènement « page.display » et ajouter le filtre « connexion_tunnel_achat » sur la propriété « page » :

Les autres évènements symbolisent déjà l’avancée dans le tunnel d’achat, je n’ai donc pas besoin d’ajouter de filtres sur d’autres étapes. Je souhaite cependant me concentrer sur les paniers importants, je filtre donc ceux ayant au moins 100€ de marchandise :

Vous pouvez également segmenter votre tunnel, pour par exemple ne visualiser que les parcours effectués sur mobile, ou ceux ayant été exposés à une auto-promotion :

Notre tunnel est prêt, il ne reste plus qu’à lancer le calcul, comme un Template Data Query classique !

Astuce 1 : les étapes avec filtres apparaissent avec un petit entonnoir à gauche du nom de d’évènement.

Astuce 2 : vous n’êtes pas obligé de spécifier un évènement dans une étape, vous pouvez uniquement y appliquer des filtres. Ainsi tout évènement correspondant aux filtres sera inclus dans l’étape. Pour cela il suffit d’éditer l’évènement et de sélectionner « any event » dans le menu déroulant.

Analyse d’un tunnel

Votre tunnel maintenant affiché, vous allez pouvoir analyser sur la partie graphique :

• Le volume de visites à chaque étape (1)
• Le volume de déperdition à chaque étape (2)
• Le taux de passage et le taux de sortie, en survolant une des étapes (3)

Sur la partie KPi’s, vous allez retrouver :

• Les visites (combien de visites étaient présentes à la première étape de mon tunnel ?) (4)
• La durée moyenne (combien de temps s’est écoulé entre la première et la dernière étape ?) (5)
• Le taux de conversion (volume de la dernière étape divisé par le volume de la première) (6)
• Sorties (nombre de visites ayant quitté le tunnel sur une des étapes) (7)

Libre à vous maintenant de modifier votre tunnel en ajoutant une étape, en modifiant votre segment ou encore en supprimant un filtre présent sur une étape !

Les calculs derrière la fonctionnalité

Pour bien utiliser cette fonctionnalité, il convient de comprendre les calculs qui sont effectués en coulisse.

Les étapes des séquences que vous définissez ne sont pas obligatoirement consécutives. Ainsi, d’autres évènements peuvent se glisser entre 2 étapes, ce qui n’empêchera pas la prise en compte de la visite dans le tunnel. Contre intuitif de prime abord, cela me semble un très bon choix, puisque cela vous permettra, par exemple, d’éviter les évènements parasites se glissant dans votre tunnel (par exemple des évènements de clics entre 2 pages car vous avez marqué votre menu principal avec des évènements click.navigation).

Ainsi, si je définis la séquence « chargement page A » > « lecture video B » > « chargement page C », voici les visites qui seront retenues :

Gardez donc en tête qu’une visite réalisant la séquence complète de votre tunnel pourra potentiellement avoir fait plusieurs aller-retours sur le site avant de convertir.

Cette logique est également valable pour les granularités visiteurs et utilisateurs, où seul l’ordre des évènements compte et non leur enchainement.

Les principales différences avec les autres fonctionnalités de séquençage

Comme indiqué en introduction, d’autres outils permettaient déjà de faire du séquençage :

• la segmentation séquentielle
• l’analyse navigation

Voyons rapidement les principales différences entre ces outils et quels sont leurs avantages/inconvénients.

La segmentation séquentielle

La segmentation séquentielle va avoir le même mode de calcul que l’analyse tunnel, à savoir la comptabilisation des visites/visiteurs/users ayant suivi un enchainement d’évènements dans un certain ordre, mais pas obligatoirement consécutifs (celui-ci est disponible dans le module de segmentation avancée, via le bouton « puis » ou « then »). Exemple ici :

Il serait donc en théorie possible de recréer un tunnel, en créant plusieurs métriques calculées basées sur des segments séquentiels, et vous obtiendriez le même résultat, mais cela serait bien sûr chronophage. L’avantage est en revanche que vous pouvez placer un taux de passage dans un dashboard ou un template Data Query, ce qui n’est pas possible avec tunnel. Il permet également d’être utilisé comme segment dans l’ensemble de vos analyses Explorer.

L’analyse navigation

L’analyse navigation va, elle, avoir une autre logique de calcul. Celle-ci dispose uniquement d’une granularité « visites », centrée sur les évènements page.display() et la propriété page_full_name (le nom de votre page, concaténé avec ses chapitres). Exemple ici avec le sunburst :

L’analyse va également être concentrée sur les chargements de pages consécutifs, on peut ainsi parler ici de séquences directes (enchainement des évènements les uns derrières les autres), ce qui fait une grosse différence avec tunnel. Je vous place ici le lien vers la documentation Piano, qui explique les détails du mode de calcul.

Finalement, la navigation va plus avoir un rôle d’analyse exploratoire, puisque que vous vous verrez proposer à chaque étape sélectionnée, les étapes suivantes, OU, les étapes précédentes. Cela n’a donc pas le même objectif qu’un tunnel.

Je vous place ci-dessous un tableau récapitulatif des spécificités et usages de chaque fonctionnalité :

Les nouveaux use cases possibles avec l’analyse tunnel

Maintenant que vous avez acquis toutes les subtilités de cette nouvelle analyse, il est maintenant temps de se projeter dans des exemples d’analyses, que vous n’auriez pas pu faire auparavant.

Créer un tunnel avec plusieurs type d’évènements

C’est le fameux cas que j’ai donné comme exemple en introduction. Comme l’analyse navigation ne traite que les évènements de pages et que le tunnel disponible dans Sales Insights ne gère que ses propres évènements, il n’était auparavant pas possible de créer un tunnel mixant plusieurs typologies d’évènements.

Le cas du tunnel d’achat marqué avec des évènements Sales Insights, mais comprenant une étape de connexion marquée avec un évènement page.display() devient maintenant réalisable.

Rassembler plusieurs évènements en une seule étape

Définir les étapes d’un tunnel ne veut pas nécessairement dire qu’elles ne doivent contenir qu’un seul évènement. Reprenons notre exemple précédent avec le tunnel d’achat. Imaginons que je veuille avoir une étape supplémentaire concernant la connexion, à savoir :

• ceux qui ont été exposés au formulaire de connexion
• ceux qui ont été au bout du processus de connexion (connexion au compte ou création de compte)

Problème : la connexion et la création d’un comptes sont 2 évènements page.display() différents, avec leur propre label (« connexion_succes » et « validation_creation_compte »).

Je peux cependant définir dans mon tunnel une étape « validation connexion » qui aura un filtre « page = connexion_succes ou validation_creation_compte« , permettant de prendre en compte les 2 cas de figures.

Créer des entonnoirs de conversion

Avec l’exemple précèdent, nous voyons qu’il est possible, en jouant avec les filtres, de rassembler plusieurs évènements au sein d’une étape. Nous pouvons appliquer ce principe en créant un entonnoir de conversion, qui pourra comprendre des milliers d’évènements pour chacune des étapes. Restons sur notre site e-commerce, où nous voudrions connaitre la déperdition de trafic entre la home page et la commande. Nous aurons donc comme étapes :

• La home page, qui est en soi une page unique
• Les listes produits, qui sont des centaines de pages
• les pages produits, qui sont des milliers de pages
• le panier et la confirmation d’achat, qui sont des évènements uniques

Faire un suivi des conversions multi-visites

Dès que nous sortons d’une conversion à scope visites, les analyses vont devenir plus complexes. En effet, même si l’interface dispose des outils nécessaires pour suivre un visiteur ou un user, la plupart des analyses et des métriques se rapportent à la visite (sources, temps passé, conversions…). Ce module tunnel va nous permettre de visualiser plus facilement des parcours multi-visites, et surtout d’estimer le temps nécessaire pour réaliser une conversion longue.

Imaginons que vous êtes le web analyste de Voyageurs du Monde, une société vous proposant de réaliser des voyages sur mesure. Très clairement, le temps entre la première prise de contact et la validation d’une proposition de voyage va être de l’ordre de plusieurs jours, à plusieurs semaines.

Notre objectif va donc être de suivre ce processus, de la création du compte jusqu’à l’achat et d’en déterminer la déperdition ainsi que le temps moyen. Voici nos étapes clés :

• La création d’un nouveau compte
• L’envoi d’une première liste de souhaits
• la consultation de la proposition de Voyageur du monde (sachant qu’il peut y en avoir plusieurs, en fonction des retours du client)
• La validation de la proposition (synonyme de paiement)

Nous allons analyser cela sur une période de 6 mois, afin de laisser le temps aux plus indécis d’éventuellement terminer leur parcours.

Cependant nous allons ici avoir un problème : un utilisateur peut aussi bien créer son compte le premier mois que le dernier mois de l’analyse. Ainsi, celui ayant débuté le parcours ciblé le sixième mois aura eu beaucoup moins de temps pour réaliser l’ensemble, impactant donc négativement le taux de conversion global.

Afin d’annuler ce comportement, nous allons appliquer un segment à portée Utilisateurs qui ciblera ceux ayant créé leur compte lors du premier mois de notre période d’analyse. Ainsi, uniquement ces utilisateurs seront suivis en terme de déperdition dans le reste du parcours.

Créer un tunnel omnicanal

Vous ne l’aviez peut-être pas en tête, mais il est possible d’envoyer des évènements offline vers Piano analytics. Retrait d’un produit en magasin, rendez-vous physique, appel call center… sont des évènements offline, que vous pouvez rattacher au reste du parcours online d’un utilisateur. Exemple ici avec un event click&collect, qui sera rattaché à l’utilisateur ayant fait la commande en ligne, tout en ne générant pas de visite dans vos données.

https://logx.xiti.com/event?s=12345&events=
[{"name":"confirmation_retrait_clickandcollect",
"data":{
"user_id":"12345678",
"transaction_id":"T8787878887"
}}]

Pensez bien à déclarer votre évènement personnalisé comme offsite, au risque de générer des visites parasites dans vos données :

• Le visiteur arrive depuis une landing page
• Il consulte l’offre et remplit un formulaire pour une demande de rappel par un conseiller
• le conseiller parvient à joindre le visiteur au téléphone et lui fait parvenir un contrat (event offline)
• Le client consulte son espace en ligne, puis signe le contrat envoyé

Bien entendu, il faudra préalablement mettre en place un système de requêtes server to server, afin que le serveur de la centrale d’appels envoie l’information de l’appel réussi en temps réel au serveur Piano Analytics.

A noter que seule la granularité « User » sera disponible pour ce type de tunnel, puisque les evènements offline ne peuvent être rattachés qu’au user_id.

Conclusion

Le module est amené à évoluer à très court terme, aussi cet article sera mis à jour au fur et à mesure des évolutions de tunnel. Comme vous avez pu le voir à travers ces exemples, il permet de répondre dès maintenant à des problématiques qui n’étaient pas réalisables auparavant. il a donc toute sa place dans vos habitudes d’analyses à partir de maintenant.