Comment TELUS a transféré 50 % de son trafic web vers la solution Launch d’Adobe en une semaine
Intelligence des données · 18 oct. 2018
Sommaire
Si vous voulez des applications performantes pour améliorer l’optimisation pour les moteurs de recherche (SEO) et l’expérience client, passez à la solution Launch d’Adobe (en mode asynchrone). Pour ce faire, vous devrez planifier le transfert, former une équipe principale d’analytique (composée de développeurs de plateforme, d’analystes et de développeurs analytiques) pour un marathon de programmation, passer à l’exécution, et être prêt à faire un nettoyage.
Si vous êtes nouveau dans l’écosystème de Stratégie numérique de TELUS, vous ne connaissez probablement pas bien notre pile de données. Pour un aperçu, lisez cet article.
Il est largement reconnu que plus une application est performante, mieux elle se classe dans les résultats de recherche de Google. Intuitivement, nous savons que les gens n’aiment pas attendre pour le chargement d’un site web. Donc, du point de vue de l’analytique, que pouvons-nous faire pour aider?
La méthode de travail de Stratégie numérique de TELUS
Actuellement, l’équipe Stratégie numérique de TELUS compte plus de 450 membres, divisés en quatre équipes responsables des résultats et deux équipes responsables de la mise en œuvre. Chacune comprend de multiples groupes répartis entre Toronto et Vancouver. Chaque groupe doit faire configurer les données et l’analytique dans les applications qu’il crée afin de procéder à des itérations constantes et de mesurer son succès.
Dans la plateforme Github de TELUS, nous avons 886 répertoires, dont environ 200 applications actives (dont l’analytique repose sur Openshift). Idéalement, nous devrions mettre à jour les 200 répertoires pour transférer entièrement la mise en œuvre vers un nouveau gestionnaire de balises.
Optimisation et performance : quelle motivation?
Je crois que ce qui a réellement poussé l’équipe à optimiser la performance se résume dans le titre suivant, tiré du site Techcrunch : « Google will make page speed a factor in mobile search ranking starting in July » (Google tiendra compte de la vitesse de chargement dans les recherches sur appareil mobile à compter de juillet). Lorsque nous nous sommes penchés sur les principaux facteurs influant sur la performance des pages, nous avons réalisé que nous devions vraiment commencer à optimiser notre performance si nous ne voulions pas perdre les 14 % de visites provenant de l’optimisation pour les moteurs de recherche.
Parmi les premières choses auxquelles nous nous sommes attaquées en tant qu’équipe responsable de la plateforme de données : les gestionnaires de balises qui bloquaient l’affichage (DTM et Ensighten). Comme nous ne pouvions pas les empêcher de faire[1], nous avons évidemment sauté sur la solution Launch lorsque nous avons appris qu’elle pouvait être déployée en mode asynchrone.
En plus d’améliorer nos indicateurs de rendement clé pour la performance et l’optimisation pour les moteurs de recherche, nous voulions simplifier l’analytique dans Launch et réduire le nombre total d’appels réseau à Adobe. Moins d’appels réseau équivalent à moins de dépenses!
Remarque : Josh Arndt, notre architecte technologique principal, a récemment écrit un article de blogue sur l’importance de la performance des sites web pour TELUS. Son article creuse le sujet en profondeur. Jetez-y un coup d’œil.
Planification et considérations
Vu l’ampleur de la tâche, nous avons décidé de faire ce que TELUS fait le mieux : accorder la priorité aux tâches d’analytique qui pourraient améliorer l’expérience client.
Du point de vue de l’analytique, nous avons examiné quel gestionnaire de balises les pages utilisaient (Ensighten ou DTM) et combien de trafic elles obtenaient. Nous avons pris en considération le fait que la page soit une page de marketing ou une page Mon TELUS authentifiée, car les pages de marketing sont extrêmement moins complexes[2].
De plus, nous devions aussi savoir si les pages comprenaient une couche de données (dataLayer). Pour compliquer un peu les choses, nous devions aussi comprendre QUANDla couche de données était ajoutée[3] aux pages afin d’éviter les problèmes de délai liés à la lourde configuration de notre changement à l’élément de données (dataElement)[4].
Après délibération, nous nous sommes arrêtés sur un plan.
Nous organiserions un marathon de programmation d’une semaine où nous nous concentrerions sur le transfert des pages qui comprenaient déjà une couche de données et qui généraient le plus de trafic. Nous avons aussi décidé de privilégier les pages les moins complexes afin de maximiser nos chances de réussite.
L’objectif était de transférer les 10 pages qui généraient le plus de trafic dans chacune des quatre équipes responsables des résultats. Nous devions d’abord nous attaquer en groupe à ces pages qui se chevauchaient d’une équipe à l’autre, puis revenir par équipe sur la liste déjà établie en ignorant les pages déjà transférées.
Pour ce faire, nous avons demandé à notre équipe préférée d’experts-conseils d’Adobe de venir passer la semaine avec nous (quatre personnes). Nous avons aussi invité quatre développeurs, un de chaque équipe responsable des résultats, ce qui nous a permis d’avoir un point de vue technique sur les applications concernées.
La dernière partie du plan était la séquence d’exécution :
Tester la page selon un cadre préétabli dans la solution Launch d’Adobe en utilisant l’extension Launch Command de Google Chrome (ceci ne teste pas les problèmes de délai décrits plus haut)
Extraire l’application de Github et remplacer les scripts de développement, intermédiaire et de production pour l’analytique
Envoyer le site au stade intermédiaire et mettre à l’essai les changements dans Launch pour vérifier si des problèmes de délai ou des conflits avec les autres scripts surviennent
Apporter les changements à la version de production dans l’application et dans Launch
Tester, tester, tester et procéder à une reprise
Résultats et conclusion
À la fin de la semaine, nous avions mangé et bu toutes sortes de choses, et nous avions transféré 50 % de notre trafic sur une page Launch (en nombre de visites), ce qui est énorme.
Bien que nous voulions initialement livrer les changements immédiatement, nous avons décidé de reporter le dernier lot de changements aux applications parce que beaucoup de membres de l’équipe partaient pour le long week-end.
Comme vous pouvez le voir dans le graphique, nous avons continué la publication des sites la semaine suivante et avons atteint 54 % pour finalement grimper jusqu’à 60 %. À ce stade, notre progression s’est stabilisée pendant quelque temps. Nous avons alors examiné trois différentes itérations de modèle Launch, chacune réglant une variation différente du problème de délai que nous avions découvert.
Si vous voulez relever le défi, je vous recommande fortement de le faire. Nous avons obtenu un énorme gain de performance de 15 à 18 points après avoir nettoyé la mise en œuvre et optimisé les scripts exécutés sur les pages de l’entreprise.
La corrélation n’indique pas nécessairement un lien de cause à effet, mais nous savons que l’amélioration de l’optimisation pour les moteurs de recherche provient des changements que nous avons faits.
Tout bien compté, nous avons aimé notre mini marathon de programmation, qui nous a permis de livrer d’incroyables résultats à TELUS.
Si vous vous demandez comment nous mesurons la performance de nos applications, lisez l’article de Josh Arndt sur la façon dont nous nous sommes approprié le logiciel ouvert Lighthouse de Google.
Vous pensez avoir ce qu’il faut pour faire partie de l’#équipeTELUS? Postulez dès maintenant en mentionnant cet article dans votre candidature. Cliquez ici pour poser votre candidature!
Annexe :
[1] Nous avions déjà essayé de configurer l’outil de gestion dynamique des balises en mode asynchrone. Les résultats? Je ne vous conseille tout simplement pas d’essayer. La plupart des événements et quelques règles de chargement de page ont été corrompus.
[2] La plupart des pages de marketing reposent sur une application qui n’authentifie pas les clients, ce qui facilite le travail, car les interfaces de programmation d’application peuvent retarder la disponibilité des données. Au-delà de ça, nous avons tenu compte des événements générés par l’utilisateur et par le système (clavardage proactif) et des complexités qu’ils apportent.
[3] Nous avons dû porter attention au moment où la bibliothèque d’analytique se chargeait, au moment où la couche de données était ajoutée et au moment où nos règles étaient appliquées (conditions liées au changement à l’élément de données [dataElement] ou au chargement de la page [pageLoad] dans les règles).
[4] Une fonction de l’outil de gestion dynamique des balises d’Adobe qui vous permet de lancer un événement lorsqu’une fonction JavaScript renvoie une valeur différente de celle précédemment mise en commun.
Ingénieur de données à TELUS le jour, blogueur la nuit – suivez le blogue d’Ajay :http://www.ajayajaal.com
