Les données d'un parcours

Quand un client utilise une borne, le Wogeez Engine exécute le scénario: il enchaîne les étapes, attend les choix du client, pilote le terminal de paiement, l'imprimante ou les casiers. Wogeez ne garde pas seulement ce que le client a saisi, il garde cette exécution tout entière.

Une exécution, aussi appelée exécution, réunit les étapes jouées dans l'ordre, la réussite ou l'échec de chacune et ce que chaque widget a produit: les champs d'un formulaire, un panier, une autorisation bancaire, un ticket imprimé, un casier ouvert. Elle est rattachée à la borne, au scénario et à la version exacte qui l'ont jouée. À la fin du parcours, elle est figée dans un snapshot, conservé dès que la borne est connectée.

Un embasement classique se résume à un fichier plat: nom, prénom, e-mail, téléphone. Ces données s'affichent dans un tableau ou s'importent dans un CRM, mais elles disent seulement qui a laissé ses coordonnées, pas ce qu'il a vécu.

L'exécution raconte le parcours. Elle dit qu'un client a choisi deux articles, que son paiement a été autorisé, que le casier s'est ouvert mais que le ticket n'est pas sorti faute de papier. Elle montre aussi où les autres se sont arrêtés: si la moitié des clients abandonne à l'écran de paiement, cela se voit sans enquête. Et comme chaque exécution porte la version du scénario, deux versions se comparent sur des faits.

Une exécution n'est pas qu'un enregistrement. Sa fin déclenche les tâches de fond du scénario, comme un webhook vers votre caisse, selon qu'elle a réussi ou échoué. Les données servent ainsi à agir au moment du passage, pas seulement à être consultées après coup.

Chaque widget interactif laisse une production dans l'étape où il a été joué, avec sa réussite et, en cas d'échec, l'erreur rencontrée. Une étape sans widget interactif n'en laisse pas: on sait seulement qu'elle a été jouée.

Les exécutions contiennent ce que les clients ont saisi et les références de leurs paiements. Leur accès dépend donc des droits de chacun. La page Données n'apparaît dans le menu du manager que pour les personnes qui ont un droit sur les données d'au moins une entreprise.

La page s'ouvre sur les exécutions des 30 derniers jours, les plus récentes en premier. Les filtres se cumulent: une exécution n'est affichée que si elle correspond à tous.

• Entreprise, si vous avez accès aux données de plusieurs entreprises.
• Du et Au, les deux jours inclus.
• Scénario, puis Version pour ne garder qu'une version de ce scénario. La liste des versions reste grisée tant qu'aucun scénario n'est choisi.
• Borne.

Le bouton Réinitialiser revient aux 30 derniers jours sans autre filtre.

Chaque exécution a un numéro de corrélation unique. Saisissez-le en entier dans la barre de recherche puis validez avec Entrée. La période est alors ignorée: l'exécution est retrouvée quelle que soit sa date.

Le numéro de corrélation figure en bas du détail d'une exécution, dans l'onglet Support de la borne et dans le contexte envoyé à vos webhooks.

Chaque ligne donne la date de l'exécution, la borne, le scénario et sa version, le numéro de mission, le nombre d'étapes, le montant du panier et le résultat. Une exécution est réussie quand toutes ses étapes et toutes les données qu'elles ont produites sont réussies. Les exécutions suivantes se chargent avec le bouton Exécutions plus anciennes.

Au-dessus de la liste, quatre indicateurs résument la sélection. Seul le nombre d'exécutions porte sur toute la sélection. Les trois autres sont calculés sur les exécutions affichées: chargez les exécutions plus anciennes pour les étendre.

Cliquez sur une ligne pour ouvrir l'exécution. Ses étapes s'affichent dans l'ordre du parcours, chacune avec les données qu'elle a produites: les lignes et le total du panier, la référence de l'autorisation bancaire, le ticket imprimé ou le casier ouvert, les champs du formulaire et leurs valeurs. Une donnée en échec apparaît en rouge avec son message d'erreur.

En bas du détail, les variables de l'exécution reprennent les valeurs calculées pendant le parcours, dont les saisies des formulaires que le scénario réutilise.

Le bouton Exporter en CSV télécharge toutes les exécutions qui correspondent aux filtres, pas seulement celles affichées, dans la limite des 10 000 plus récentes. Le fichier utilise le point-virgule comme séparateur et s'ouvre directement dans Excel, accents compris.

Il contient une ligne par exécution. Chaque champ de formulaire a sa propre colonne, nommée form.<étape>.<champ>: les réponses d'un même scénario s'alignent d'une exécution à l'autre. Quand les données sont anonymisées, le nom du fichier se termine par -anonymized.

Avec le droit « Consulter les données anonymisées », trois informations sont remplacées par ***: les valeurs saisies dans les formulaires, les références des autorisations bancaires et les valeurs des variables de l'exécution. Le nom des champs et des variables reste visible, et un champ laissé vide reste vide.

Tout le reste est conservé: dates, bornes, scénarios, étapes, paniers, délivrances et erreurs. Les taux de réussite et les montants restent donc exploitables.

Le masquage est fait par l'API au moment de la lecture, à l'écran comme dans l'export. Les données enregistrées ne sont jamais modifiées: un propriétaire ou un analyste de données les voit toujours en clair. Un bandeau rappelle en haut de la page que les données sont anonymisées.

• La page Données du manager liste les exécutions, les filtre par période, scénario, version ou borne et les exporte en CSV. Choisir les exécutions
• L'onglet Support d'une borne retrace ses dernières exécutions pour répondre à un client, les échecs en premier.
• Un webhook de scénario envoie l'exécution complète à votre serveur à la fin du parcours, pour alimenter un CRM ou déclencher un traitement. Lire un passage reçu
• L'API des snapshots rend les exécutions consultables à tout moment, avec les mêmes filtres et les mêmes droits que la page Données. Depuis l'API

Partout, le numéro de corrélation et le numéro de mission désignent la même exécution. Gardez-les dans vos propres outils pour relier une ligne de votre CRM au passage d'origine.

Les mêmes exécutions s'obtiennent avec GET /companies/{id}/resources/scenarios/contexts/snapshots, avec les mêmes règles de droits. Les paramètres from et to (jours au format AAAA-MM-JJ, inclus), scenarioId, scenarioVersionId, deviceId, mission et correlation se cumulent. La pagination se fait avec page, qui commence à 0, et pageSize, 100 au plus.

La réponse indique avec anonymized si les données ont été masquées. Elle est décrite dans le Swagger. Utiliser l'API

• Nommez clairement les champs et les étapes. Les identifiants des champs deviennent les colonnes de l'export, ceux des étapes se retrouvent dans les messages reçus par vos outils.
• Prévoyez un écran d'échec. L'erreur est enregistrée dans l'exécution, et le client n'est pas laissé sans réponse. Réussite ou échec
• Comparez les versions. Chaque exécution indique la version jouée, ce qui permet de mesurer l'effet d'un changement de parcours.
• Limitez l'accès aux données en clair. Le rôle Analyste de données les voit, le droit « Consulter les données anonymisées » les masque. La matrice des droits

Pour les données collectées par vos bornes, vous êtes responsable du traitement et Wogeez agit comme sous-traitant. Politique de confidentialité