Les expériences numériques sont la façon dont les marques se connectent avec les clients. En coulisses, les équipes techniques sont responsables de l’optimisation et du déploiement de ces expériences sur différents points de contact numériques. En tant que tel, il est important pour les organisations de comprendre les principaux défis liés au déploiement, en particulier lorsqu’il s’agit de saisir les différences entre la livraison B2C et la livraison B2B expérience client.
B2B expérience client les défis de la livraison
Bien qu’ils aient les deux tiers d’un acronyme en commun, la mise à l’échelle pour la diffusion B2B expérience est catégoriquement différente – et potentiellement plus difficile – que la mise à l’échelle pour la diffusion B2C expérience. Voici quelques-unes des principales raisons :
- Même les engagements B2B les plus simples impliquent plusieurs parties prenantes ayant des attentes et des besoins différents. Une taille unique ne convient pas à tous, ni même à la plupart.
- Les engagements B2B impliquent généralement plusieurs points de contact sur une période plus longue, s’étendant souvent sur des mois, voire des années. Ne pas dynamiser et impressionner les clients à l’un de ces points de contact peut effectivement mettre fin à la relation. Et pour garder chaque nouvel engagement à jour, il faut capturer et analyser les données à chaque point d’interaction ultérieur pour tirer parti des informations.
- Étant donné que tant de données peuvent être déconnectées et que plusieurs équipes peuvent engager le même client, il est difficile d’évaluer avec précision la santé et l’élan du client tout au long du parcours. Le parcours après-vente peut être tout aussi complexe que le parcours avant-vente, ce qui est particulièrement important pour les organisations telles que celles de l’espace SaaS dont les modèles d’entreprise dépendent du fait que les clients restent sur la liste pendant plusieurs années.
5 questions clés
Pour évoluer efficacement d’un point de vue opérationnel et répondre à B2B expérience client demandes (par exemple, performances, répartition géographique, redondance et haute disponibilité), il est important de prendre en compte les cinq questions clés suivantes :
1. À quoi ressemble le succès ?
Il est essentiel de répondre clairement à cette question avant de faire quoi que ce soit d’autre, car une mise à l’échelle réussie nécessite une compréhension approfondie de :
- À quoi ressemble le parcours de l’utilisateur
- Niveaux d’utilisation prévus
- Tendances anticipées de la demande sur le réseau
- Aspects acceptables liés aux performances (par exemple, les temps de réponse du serveur, les temps de chargement des pages, la fonctionnalité, la disponibilité, etc.)
Généralement, la première étape consiste à bien comprendre et définir les exigences de la solution. Les exigences ont une incidence considérable sur la composition de l’environnement de prestation et, au final, sur le coût. Les principaux problèmes à résoudre sont les suivants : Où les visiteurs entrent-ils généralement sur le site ? Combien de visiteurs visitent généralement en même temps ? Y a-t-il des pics de trafic prévisibles à certaines périodes de l’année ?
Ces types de questions vous guideront dans la compréhension et la cartographie du comportement de vos visiteurs, ce qui peut vous aider à définir les frictions et à éclairer vos plans de test de performance. Les tests de performances s’appuient sur les exigences pour modéliser avec précision les interactions des utilisateurs et les attentes en matière de niveau de service, et ces informations peuvent être utilisées pour indiquer quand une solution est prête pour la production.
L’équipe doit également déterminer ce qui sera considéré comme un succès. Il est essentiel de comprendre le parcours, mais quel niveau de performance et de disponibilité est considéré comme acceptable ? Différentes organisations auront des tolérances différentes pour les pannes et les temps de réponse en fonction de l’importance des différentes parties de l’application pour l’entreprise.
deux. Où sont vos clients ?
Avoir une réponse rapide dans une région stratégique empêche vos visiteurs de vous abandonner et favorise de nouvelles conversions.
Le besoin de vitesse — considérez ce qui suit :
- 47 % des clients s’attendent à ce qu’un site Web se charge en 2 secondes ou moins.
- 40% des clients abandonneront un site web qui prend plus de 3 secondes à charger.
- Un délai de 100 millisecondes dans le temps de réponse de la page diminue les taux de conversion de 7%.
- Après 3 secondes d’attente, il y a un 16% de réduction de la satisfaction client pour chaque seconde.
- La vitesse de la page est désormais un facteur de classement SEO direct par Mise à jour de la vitesse de l’algorithme de Google.
Le maintien d’une infrastructure hautement disponible et distribuée à l’échelle mondiale peut s’avérer complexe et coûteux à exploiter, ainsi qu’à héberger. Pour atténuer les risques et accroître l’efficacité, il est essentiel de savoir où se trouvent vos clients et quel type de latences est autorisé dans les régions qui ne sont pas stratégiques pour votre entreprise.
Vous pouvez également vérifier si l’expérience de vos visiteurs peut tirer parti des réseaux de diffusion de contenu (CDN) ou d’autres technologies de diffusion en périphérie telles que la solution Experience Edge de Sitecore pour atteindre votre public là où il se trouve.
3. Le Prévoyez-vous de tirer parti de la personnalisation ?
La personnalisation est une tactique de plus en plus essentielle pour réussir. Toutefois, l’utilisation de personnalisation considérablement augmente la complexité d’un déploiement, car elle a un impact sur les performances et les caractéristiques d’évolutivité. Il est également nécessaire d’projet les pics d’utilisation à l’avenir, afin d’augmenter la capacité de collecte base de données. Des tests de performance précis sont le seul moyen de valider la capacité de collecte d’une solution particulière.
Il peut être intéressant de planifier des jours ou des périodes de pointe en raison de campagnes saisonnières ou de lancements de produits. Les données analytiques d’expérience doivent être dimensionnées pour le pire des scénarios s’il s’agit d’un cas unique, mais il n’est pas toujours logique du point de vue des coûts de créer un environnement pour ces circonstances extraordinaires. En tant que tel, vous pouvez choisir de désactiver les données analytiques pendant les périodes de pointe et de les adapter aux pics moyens trouvés tout au long de l’année.
Analytics : à activer ou à désactiver ?
Analytics a un impact considérable sur chaque visite d’une solution. Les organisations doivent effectuer une évaluation coûts-avantages pour décider s’il est plus avantageux de construire l’infrastructure pour les pics attendus et d’obtenir des données données analytiques précises ou de désactiver données analytiques pour réduire les coûts liés à la topologie de déploiement requise.
Une considération importante est que la limitation de l’échelle des données analytiques peut entraîner des pistes commerciales à des temps d’arrêt dans des situations d’utilisation extrêmes, et en tant que tel, garder les données analytiques activées pour les périodes de pointe connues est un risque que de nombreuses organisations (en particulier celles de l’espace B2C) ne sont pas disposées à prendre.
Il est également nécessaire de porter une attention particulière lors de la combinaison de la distribution géographique avec les données analytiques. Si vous utilisez Sitecore Experience Database™ (xDB) (qui est utilisée pour créer une vue client à 360 degrés en collectant et en connectant des données sur tous les canaux en temps réel) et un capacités de suivi natif, chaque demande nécessitera soit un nouveau contact, soit un contact connu réhydraté. Si le données analytiques base de données Sitecore n’est pas proche de l’emplacement de la demande d’origine, cela a un impact sur les performances observées à ce client. En règle générale, il est préférable d’avoir des données analytiques géographiquement situées avec le déploiement de la solution. Toutefois, lorsque plusieurs emplacements géographiques font partie de la solution, un développement supplémentaire est souvent nécessaire pour garantir à la fois les performances et les problèmes fonctionnels.
Toujours en ce qui concerne l’exploitation des personnalisation par analyse de l’expérience, il est important d’être prudent avec les appels JavaScript et XML asynchrones (AJAX) qui refluent vers les serveurs de livraison. Analytics s’appuie sur des fournisseurs de session ASP.NET, ce qui peut entraîner des problèmes de performances lorsque plusieurs demandes provenant du même flux de contacts sont effectuées en parallèle. En outre, les solutions doivent définir les demandes qui doivent être suivies et définir toute demande en lecture seule.
À propos des demandes en lecture seule
Une étape critique dans l’optimisation de l’utilisation de Sitecore xDB par une solution consiste à identifier les demandes qui ne doivent pas faire partie du suivi xDB et les demandes qui peuvent être marquées en lecture seule car elles n’écrivent aucune information de contact ou d’interaction.
Les requêtes en lecture seule sont particulièrement importantes dans les solutions qui intègrent des requêtes parallèles avec le même contact et sont souvent associées à AJAX. Les requêtes parallèles qui ne sont pas marquées comme étant en lecture seule peuvent introduire des problèmes de temps de réponse, car chaque requête doit attendre un accès exclusif à l’objet de session.
En règle générale, Redis est le fournisseur de session recommandé. Cependant, l’un des problèmes avec Redis est que la base de données est en mémoire, ce qui limite les sessions utilisateur de pointe. Vous devrez prendre en compte le nombre maximal de sessions parallèles et dimensionner Redis de manière appropriée pour s’adapter à l’utilisation.
Il est également meilleures pratiques d’inclure une stratégie pour le nettoyage de la base de données de la collection, qui consiste à déterminer la durée pendant laquelle les données doivent être conservées. En règle générale, une routine est configurée pour nettoyer les données en fonction de la valeur métier, ce qui permet aux points de terminaison de données analytiques de maintenir la qualité des performances. Dans les déploiements plus importants, il est conseillé d’utiliser une instance d’expiration de session dédiée, ce qui garantit une utilisation optimale des ressources de livraison.
4. Vendez-vous quelque chose ?
Une quantité considérable de contenu peut être mise en cache pour optimiser la diffusion. Cependant, les expériences d’achat sont transactionnelles et uniques à chaque client. Si votre organisation prévoit d’avoir une capacité de commerce par votre canal, vous devrez aborder les points suivants :
- Où la transaction a-t-elle lieu (pays, état) ?
- Où sont les goulots d’étranglement dans le flux d’achats/commandes ?
- Y a-t-il des saisons de forte activité ?
- Quelle est la taille de votre catalogue (combien de produits, de relations, de langues, de cartes de prix, de coupons, de catégories) ?
- Combien y a-t-il de chèques/deuxième pic attendus ?
- Quels sont les profils de clients les plus recherchés ?
- Combien d’articles sont attendus dans les paniers ? (notez que le B2B a tendance à nécessiter des chariots plus grands que le B2C)
L’équilibre entre les besoins en capacité et la vitesse pour divers scénarios d’en haut peut améliorer les performances et la planification. Par exemple, vous pouvez exécuter une grande partie de votre contenu en tant que site statique avec des vitesses de réponse globales considérables sur votre réseau de diffusion périphérique. Les utilisateurs peuvent avoir un excellent expérience avec cette partie du site, mais si votre backend de commande ne peut pas gérer les transactions d’une région ou d’un pays donné, votre commerce expérience en souffrira. Il est essentiel de mettre à l’échelle vos fonctionnalités de commerce pour que cette expérience reste rapide.
5. Comment pouvons-nous voir ce qui se passe ?
La surveillance et l’observabilité sont essentielles pour pouvoir répondre aux demandes de mise à l’échelle. Vous devez être en mesure de définit les changements de performances tout en permettant à vos équipes d’explorer plus en profondeur pour découvrir où se trouvent les goulots d’étranglement des performances et les problèmes d’intégrité du service. Une surveillance efficace aide votre organisation à anticiper les problèmes et à mettre à l’échelle les bonnes ressources au bon moment.
Kubernetes (K8s) peut aider à simplifier ce processus en établissant une infrastructure d’hébergement dynamique. Cela alloue efficacement des ressources à différentes charges de travail et assure l’équilibrage de charge entre les instances qui composent les charges de travail d’une solution. Grâce à un contrôle granulaire de l’infrastructure, les équipes d’exploitation peuvent réagir de manière dynamique à de nombreuses situations de manière plus rentable que d’essayer de surprovisionner dès le départ.
Vous pouvez également tirer parti d’outils de surveillance ou d’observabilité tels qu’Azure Application Insights, Grafana, Prometheus, New Relic, Datadog, Honeycomb ou un certain nombre d’autres outils disponibles. Ces outils vous permettent de visualiser les données relatives à vos indicateurs de performance, de définit les fluctuations, les scénarios de danger et d’explorer les problèmes possibles. Vous pouvez également faire appel à Sitecore Managed Cloud ou à votre partenaire de solution d’hébergement pour vous aider à ajouter ces capacités à votre solution.
Par exemple, supposons que l’infrastructure est configurée pour évoluer automatiquement en fonction d’une demande particulière pour maintenir une grande expérience. Les utilisateurs sont contents ! Cependant, à long terme, vous souhaitez réduire vos coûts d’exploitation afin que votre équipe soit également satisfaite. Cela signifie que vous devez être en mesure de voir quand ces problèmes de performances se produisent et de commencer à analyser les causes profondes des problèmes. Il peut y avoir une erreur dans la logique de votre application, ou une configuration particulière qui provoque un verrou, ou une autre raison qui entraîne la mise à l’échelle de votre application. Si vous pouvez définit et éliminer cette cause sous-jacente, cela éliminera également le besoin d’une mise à l’échelle automatique future pour ce scénario.
Étapes suivantes
Les expériences numériques relient les marques aux clients. Pour établir une connexion solide, les développeurs doivent créer et diffuser ces expériences sur plusieurs points de contact numériques. Pour faire évoluer votre organisation dans cette direction, nous vous recommandons les étapes suivantes :
- Passez en revue les réponses aux cinq questions mises en évidence ci-dessus avec votre équipe.
- Déterminez votre niveau d’aisance à l’égard de la gestion et de la surveillance de votre processus de mise à l’échelle.
- Continuez à répondre à ces questions périodiquement, et avant tout événement qui générera de nouveaux modèles de trafic et / ou utilisera de nouveaux canaux.
Nous vous encourageons également à consulter les blogs Sitecore Insights, qui offrent une bibliothèque croissante d’articles de leadership éclairé, s’adressant à divers publics sur de nombreux aspects de la transformation numérique. Visitez maintenant.