Zapmap : un analytics d’application construit autour des questions de l’équipe produit

À propos du projet

L’application Zapmap aide les conducteurs de voitures électriques au Royaume-Uni à trouver et utiliser les bornes de recharge publiques. Son équipe produit, dirigée par Edmund Walsh, voulait un analytics relié aux priorités business qu’elle devait atteindre. Sophus3 a commencé par convenir de ce qu’était le succès, plutôt que par un tableau de bord.

Étape 1 : convenir de ce qu’est le succès

Il est tentant de commencer par la gestion des tags ou un nouveau tableau de bord. Sans accord sur ce qu’est le succès, ces outils ne produisent que davantage de chiffres. Le travail a donc commencé par les objectifs de l’organisation :

• Discuter des objectifs business et définir le succès pour l’application.
• Traduire ces objectifs en un petit nombre de KPI clairs.
• Construire un cadre de mesure et de reporting pour guider l’audit.

Nous avons ensuite comparé l’intention et l’expérience. Le parcours client dans l’application sert-il les objectifs ? Le tracking capte-t-il les actions qui comptent ? La cartographie des outils, guides d’implémentation et tableaux de bord existants a révélé des événements manquants, des définitions incohérentes et des rapports peu fiables.

Étape 2 : réparer et valider le tracking

Une fois les objectifs convenus, nous avons audité le tracking existant et identifié où il ne fonctionnait pas comme prévu. En étroite collaboration avec l’équipe produit de Zapmap, nous avons testé et validé chaque nouvelle implémentation au regard du comportement réel dans l’application. Les priorités étaient :

• Un tracking directement relié aux objectifs convenus.
• Une gestion des tags que l’équipe peut maintenir elle-même.
• Des données fiables pour les décideurs, pas seulement pour les spécialistes.

La connaissance de l’application par l’équipe produit a été essentielle. Une implémentation n’est pas terminée parce qu’un tag existe ; elle l’est quand les données reflètent ce que font réellement les utilisateurs.

Étape 3 : un reporting pour décider

Un bon tracking est nécessaire, mais ce n’est pas la ligne d’arrivée. Nous avons construit un reporting Looker Studio qui relie les données aux priorités business de Zapmap :

• Des indicateurs clés faciles à lire et reliés aux questions business.
• Des tendances dans le temps, pour analyser les évolutions plutôt que des totaux isolés.
• Une vue partagée dont les parties prenantes peuvent discuter sans reconstituer le sens de chaque événement.

Ce qui a changé

Le projet a relié tracking et reporting aux questions auxquelles les parties prenantes devaient répondre, et a clarifié ce qui fonctionnait, ce qui manquait et ce qui demandait de l’attention. L’équipe dispose désormais d’une base commune pour discuter de ce que font les utilisateurs et des changements à examiner. La série publiée n’a pas chiffré de hausse de chiffre d’affaires ni de conversion ; sa preuve est l’approche de mesure que l’équipe utilise aujourd’hui.

Enseignements pour toute équipe app ou web

• Convenir de la décision avant de choisir l’outil.
• Considérer le tracking comme inachevé tant qu’il n’a pas été testé sur le comportement réel des utilisateurs.
• Concevoir les rapports autour des questions et des tendances, pas du nombre de pages vues.
• Impliquer l’équipe produit : elle sait ce que les données devraient montrer.

Lire la série

• Partie 1 : commencer par les objectifs business
• Partie 2 : construire un tracking fiable
• Partie 3 : un reporting pour décider

Vous préparez un projet de mesure pour une application ou un site ? Parlez à notre équipe analytics.

D’après la série en trois parties publiée par Sophus3 les 17 mars, 25 mars et 2 avril 2026. Le projet n’a publié aucun chiffre de chiffre d’affaires ni de conversion.