Contexte
Marketplace outdoor, secteur E-commerce. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
realisations/6:Project
Marketplace React SSR + app mobile React Native, tunnel checkout refondu.
Marketplace outdoor, secteur E-commerce. La contrainte de départ : faire évoluer le produit sans jamais couper le service à ceux qui l'utilisaient déjà tous les jours.
Marketplace React SSR + app mobile React Native, tunnel checkout refondu.
×3 sur « conversion mobile ». Derrière ce chiffre : une base de code couverte par des tests, une documentation à jour dans le dépôt, et une équipe interne capable de reprendre la main.
Réalisé avec React, Mobile, sur une chaîne d'intégration et de déploiement continue montée avec le projet. Les technologies ont été choisies pour ce contexte-là, pas parce que nous les préférons.
Un tunnel d'achat mobile perd des gens à chaque écran, et il en perd le plus là où on lui demande un effort sans contrepartie visible : créer un compte, saisir une adresse, choisir une option qu'on ne comprend pas. L'optimisation ne consiste pas à embellir ces écrans mais à en supprimer.
S'y ajoute une contrainte propre au commerce en ligne : les pages doivent être trouvables par un moteur de recherche, donc lisibles sans JavaScript, tout en restant une application riche une fois chargées. Ces deux exigences tirent dans des directions opposées et c'est là que se joue l'essentiel des décisions techniques.
Le rendu côté serveur répond à deux besoins et deux seulement : être lu par un moteur, et afficher quelque chose d'utile avant que le JavaScript soit arrivé. Les pages de catalogue en ont besoin. Le tunnel de paiement, derrière une authentification, n'en tire presque rien et paie l'infrastructure supplémentaire.
Nous appliquons donc les deux régimes dans la même application plutôt que de choisir globalement. C'est plus de configuration et moins de dogme, et cela évite de faire supporter à tout le site le coût d'un besoin qui ne concerne que la moitié des pages.
L'achat sans création de compte n'est pas une concession : c'est le retrait d'une étape qui n'apporte rien à l'acheteur au moment où il la rencontre. Le compte peut être proposé après le paiement, quand il a une contrepartie évidente — suivre sa commande — plutôt qu'avant, quand il ressemble à un péage.
Le même raisonnement vaut pour la saisie d'adresse, la confirmation par courriel et le choix du transporteur. Chaque écran doit justifier son existence par ce qu'il apporte à l'acheteur, et non par ce qu'il apporte au système d'information.
Un score obtenu sur une machine de développeur en fibre ne dit rien de l'expérience réelle. Nous mesurons sur les visiteurs, avec leurs appareils et leurs réseaux, et l'écart avec les mesures de laboratoire est systématiquement défavorable — pas de quelques pour cent, mais d'un facteur.
Cette mesure change les priorités. Ce qui pèse le plus sur un téléphone d'entrée de gamme n'est pas le poids des images mais le temps d'exécution du JavaScript, qui ne se voit pas du tout sur une machine puissante. On optimise alors ce qui compte au lieu de ce qui se mesure facilement.
Le facteur trois porte sur le taux de conversion mobile entre l'avant et l'après refonte, sur des périodes comparables. Un taux de conversion dépend aussi de la saison, du trafic entrant et des campagnes en cours : une refonte ne s'attribue jamais la totalité de la variation, et présenter le contraire serait malhonnête. Ce que la refonte explique directement, ce sont les abandons mesurés écran par écran dans le tunnel, où l'attribution est propre parce que l'écran a disparu.
Et ce qu'il ne mesure pas. Un indicateur qu'on n'explique pas ne vaut rien.
Continuer:Project[3]
Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.