Erreurs personnalisées

Digital Experience Monitoring met à votre disposition des outils pour capturer les erreurs d'API ou les erreurs JS non gérées de votre site. Par exemple : des erreurs techniques qui n'étaient pas prévues.

Néanmoins, il existe beaucoup d'autres erreurs (certaines sont attendues) qui peuvent conduire à des messages s'affichant aux utilisateurs. Par exemple : “Oops, ce produit est en rupture de stock” ou "Ce code postal n'existe pas".

Les erreurs personnalisées ("custom errors" en anglais) vous permettent de collecter et de classer n'importe quel message d'erreur qui apparaît sur votre site au cours de l'expérience utilisateur en fonction de leur impact sur le business pour pouvoir prioriser les corrections à apporter.

Les erreurs personnalisées : qu'est-ce que c'est ?

Les erreurs personnalisées collectent n'importe quel texte affiché sur l'écran de l'utilisateur. Par exemple : le texte contenu dans les bannières, les pop-ups ou dans un champ de formulaire à la suite d'une action utilisateur.

Exemple d'erreur de validation de formulaire :

Vous pouvez aussi utiliser les erreurs personnalisées pour collecter les erreurs qui n'apparaissent pas sur les écrans des utilisateurs.

Les erreurs personnalisées comportent les informations suivantes :

Collecter les erreurs personnalisées

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

Étape 1 : Implémentation de la fonction

Vous devez implémenter une fonction directement dans le code de la page web pour pouvoir collecter des erreurs personnalisées. La fonction devrait se déclencher à chaque fois que du texte devant être collecté apparaît à l'écran. 

Exemple statique : Collecter une chaîne de texte spécifique (Vous devrez implémenter cette fonction pour chacune des chaînes de textes spécifiques que vous souhaitez collecter).

window._uxa.push(["trackError","140000 is not a valid postcode"])

Exemple dynamique : Collecter une chaîne générique (Vous pouvez utiliser cette option pour ne pas avoir à configurer différents extraits de code pour chaque chaîne de message d'erreur).

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

Le tag de tracking (ou "Tracking Tag") utilisera la commande trackError et acheminera les données vers le point de terminaison "custom-errors".

Vous pouvez aussi utiliser la commande trackError avec des attributs. Par ailleurs, nous vous recommandons de spécifier des attributs afin que les erreurs collectées puissent être catégorisées.

Exemple de commande trackError avec des attributs :

window._uxa.push(["trackError", "140000 is not a valid postal code", 
{type: "formValidation", severity:"minor", language: "english"}])

Étape 2 : Configurer des attributs optionnels

L'attribut est un objet JavaScript qui se retrouve dans le format suivant : "key":"value".

Note : La "Key" ne sert qu'à catégoriser, tandis que la "Value" représente le nom exacte de la catégorie.

Exemple d'attributs d'objet :

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

Les limites des attributs d'objet sont :

• Le nombre de propriétés, c'est-à-dire le nombre d'attributs, est limité à 5.
• La longueur maximale de la key est de 30 caractères.
• La longueur maximale de la value est de 30 caractères.

Exemples d'erreurs personnalisées et bonnes pratiques pour leur appellation

Veuillez trouvez ci-dessous des exemples d'erreurs personnalisées, ainsi qu'une présentation des conventions d'appellations pour leur implémentation, classé par cas d'usage.

Pour pouvoir filtrer et hiérarchiser facilement vos erreurs personnalisées, il est fortement recommandé d'utiliser notre guide sur l'utilisation des attributs pour spécifier un message d'erreur.

Note : La "Key" ne sert qu'à catégoriser, tandis que la "Value" représente le nom exacte de la catégorie.

{type: formValidation}

{type: formSubmitFail}

{language: english}

{type: formValidation}

{language: english}

{type: formValidation}

{language: english}

{type: formValidation}

{language: english}

{type: timeout}

{language: english}

{type: formValidation}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english},

{severity: critical}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

{type: textInfo}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

{type: httpError}

{language: english}

{errorStatus: 404}

{type: textInfo}

{language: english}

{type: caughtError}

{language: english}

{type: textError}

{language: english}

{type: textInfo}

{language: english}

{type: textError}

{language: english}

FAQ

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

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

2. Est-il nécessaire d'ajouter des attributs lorsqu'on configure une erreur personnalisée ?

Les attributs sont facultatifs, mais nous vous recommandons fortement d'en spécifier néanmoins. Cela permettra de catégoriser l'erreur.