Erreurs custom

Le suivi de l'expérience dispose d'outils pour capturer les erreurs d'API ou les erreurs JS non gérées. Par ex. Erreurs techniques qui ne devraient pas se produire.

Cependant, il existe de nombreuses autres erreurs (certaines attendues) qui peuvent entraîner l'affichage de messages aux utilisateurs. Par ex. "Oups, ce produit est en rupture de stock" ou "Ce n'est pas un code postal valide".

Les erreurs personnalisées vous permettent de collecter et de classer par impact commercial, tout message d'erreur géré qui se produit pendant l'expérience de l'utilisateur afin que vous puissiez mieux comprendre quelles corrections prioriser en premier.

Qu'est-ce que les erreurs personnalisées

Les erreurs personnalisées collectent tout texte affiché sur l'écran de l'utilisateur, par ex. Message texte dans des bannières et des pop-ups ou dans un champ de formulaire basé sur une action de l'utilisateur.

Exemple d'une erreur de validation de formulaire :

Vous pouvez également utiliser les erreurs personnalisées pour collecter des erreurs qui ne sont pas visibles pour les utilisateurs.

Les erreurs personnalisées contiennent les informations suivantes :

Comment collecter des erreurs personnalisées

Un maximum de 20 erreurs personnalisées peut être collecté par page vue (cette limite inclut messages de console).

Étape un : Mise en œuvre de la fonction

Vous devez mettre en œuvre une fonction directement dans le code de la page web pour pouvoir collecter des erreurs personnalisées. La fonction doit être déclenchée chaque fois que le texte à collecter est affiché à l'écran.

Exemple statique : Collecte d'une chaîne de texte spécifique (Vous devrez mettre en œuvre cette fonction pour chaque chaîne de texte spécifique que vous souhaitez collecter).

window._uxa.push(["trackError","140000 n'est pas un code postal valide"])

Exemple dynamique : Collecte d'une chaîne générique (Vous pouvez utiliser cette option afin de ne pas avoir à configurer un extrait différent pour chaque chaîne d'erreur).

window._uxa.push([
"trackError",
document.querySelector("div[class='newMessagesInfo newError']").textContent,
])

L'étiquette de suivi utilisera la trackError commande et acheminera les données vers le point de terminaison /custom-errors.

Vous pouvez utiliser la commande trackError avec des attributs et nous recommandons de spécifier des attributs afin que l'erreur puisse être catégorisée.

Exemple d'une commande trackError avec des attributs :

window._uxa.push(["trackError", "140000 n'est pas un code postal valide", 
{type: "formValidation", severity:"minor", language: "anglais"}])

Étape deux : Configurer des attributs optionnels

L'attribut est un objet javascript sous la forme 'clé':'valeur'.

Remarque : La 'Clé' ne doit être utilisée que pour la catégorisation, et la 'Valeur' est le nom exact de la catégorie.

Voici un exemple d'objet d'attributs :

{type: "formValidation",
severity: "minor",
language: "anglais"
}

Les limitations de l'objet d'attributs incluent :

• Le nombre de propriétés (c'est-à-dire le nombre d'attributs) est limité à 5
• Longueur maximale de la clé : 30 caractères
• Longueur maximale de la valeur : 30 caractères

Exemples d'erreurs custom et bonnes pratiques de nommage

Veuillez trouver des exemples d'erreurs custom potentielles et des conventions de nommage recommandées, pour la mise en œuvre d'erreurs custom, par cas d'utilisation. 

Pour pouvoir filtrer et prioriser facilement les erreurs custom, il est fortement recommandé d'utiliser notre guide sur l'utilisation des attributs pour spécifier le message d'erreur. 

Remarque : La 'Clé' ne doit être utilisée que pour la catégorisation, et la 'Valeur' est le nom exact de la catégorie.

{type: formValidation}

{type: formSubmitFail}

{language: anglais}

{type: formValidation}

{language: anglais}

{type: formValidation}

{language: anglais}

{type: formValidation}

{language: anglais}

{type: timeout}

{language: anglais}

{type: formValidation}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais},

{severity: critical}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

{type: httpError}

{language: anglais}

{errorStatus: 404}

{type: textInfo}

{language: anglais}

{type: caughtError}

{language: anglais}

{type: textError}

{language: anglais}

{type: textInfo}

{language: anglais}

{type: textError}

{language: anglais}

FAQ

1. Les erreurs custom peuvent-elles être collectées rétrospectivement ?

Non, les erreurs custom ne peuvent pas être collectées rétrospectivement.

2. Dois-je ajouter des attributs lors de la configuration des erreurs custom ?

Les attributs sont optionnels, mais nous vous conseillons fortement de spécifier des attributs afin que l'erreur puisse être catégorisée.