Suivi transactionnel synthétique
Le monitoring de transactions de HostTracker rejoue un véritable parcours utilisateur - connexion, recherche, ajout au panier, paiement - dans un vrai navigateur depuis 300+ emplacements, et vous alerte dès qu’une étape échoue.
Comment se déroule une vérification de transaction, de la première étape à l'alerte
Chaque exécution, de la première navigation jusqu'au verdict.
Pas d'enregistreur de macros qui devient obsolète. Nommez les étapes - ce nom est ce que dit l'alerte.
checkout · 5 étapes · 3.6 s
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
navigate, click, type, select, checkContent, hover, waitForNavigation, sleep, screenshot et back - chacune avec son propre délai et son propre nom.
Toute erreur de la console du navigateur fait échouer le contrôle, avec une liste blanche allant jusqu'à dix sous-chaînes pour un script tiers bruyant.
Créez et modifiez des moniteurs de transaction via REST, les SDKs, Terraform ou MCP - avec l'ensemble complet des actions.
En savoir plusCommencez par le seul parcours dont la panne vous coûte de l’argent, faites-le passer au vert, et ajoutez les autres seulement ensuite. Un parcours surveillé auquel vous faites confiance vaut mieux que cinq configurés à moitié.
Ouvrez une fiche produit, cliquez sur ajouter au panier, vérifiez que le badge du panier affiche un article, ouvrez le paiement, vérifiez que le total et le formulaire de paiement se sont bien affichés. Arrêtez-vous une étape avant que la commande ne soit passée, et vous obtenez une couverture complète sans commande de test dans votre base de données.
Saisissez les identifiants d’un compte de test dédié, validez, attendez la navigation, puis vérifiez un texte qui n’existe qu’une fois la session réellement établie. C’est le scénario à plus forte valeur pour la plupart des applications - une connexion cassée est une panne totale qui renvoie pourtant du 200 sur chaque page.
Remplissez les champs, validez, vérifiez le message de remerciement. La panne silencieuse d’un formulaire est la panne invisible classique : rien ne plante, rien n’alerte, et les demandes cessent simplement d’arriver jusqu’à ce que quelqu’un s’en aperçoive des semaines plus tard.
Saisissez une requête qui doit toujours renvoyer un résultat, validez, puis vérifiez à la fois qu’un résultat connu est présent et que le message d’absence de résultat est absent. C’est cette seconde vérification qui détecte un index de recherche ayant discrètement cessé de se reconstruire.
Parcourez le formulaire d’inscription jusqu’à l’écran de confirmation final et vérifiez-le, en pointant le formulaire vers une cible de test afin que la surveillance ne crée jamais de vrais comptes. L’inscription se casse discrètement, et cela coûte cher - personne ne se plaint d’une inscription qu’il n’a pas pu terminer.
Demandez une réinitialisation et vérifiez que l’écran de confirmation s’affiche. Cela dépend de votre chaîne d’envoi d’e-mails, de votre file d’attente et de votre service de jetons : c’est donc un remarquable indicateur avancé de problèmes backend que la page d’accueil ne révèle jamais.
Le service de vérification transactionnelle de HostTracker garantit que toutes les étapes d’un processus de transaction en ligne fonctionnent correctement. Il teste chaque étape du processus, de l’ajout d’articles au panier jusqu’à la finalisation de l’achat. Cela permet de détecter et de corriger les problèmes susceptibles d’empêcher les clients d’acheter, ce qui améliore l’expérience client et réduit les ventes perdues.
La fonction de vérification transactionnelle de HostTracker est complète et couvre divers aspects d’une transaction e-commerce. Elle inclut la soumission de formulaires, les clics sur des boutons et les redirections de page, afin de reproduire le comportement des utilisateurs réels. Cela permet de tester l’ensemble du processus d’achat pour s’assurer de son bon fonctionnement. Elle fournit également des journaux et rapports détaillés pour aider les administrateurs à identifier et corriger rapidement tout problème, sans perturber le parcours d’achat de l’utilisateur.
Les vérifications transactionnelles rendent les sites e-commerce plus fiables et plus performants. Elles aident à maintenir un fonctionnement fluide des transactions en corrigeant les problèmes avant qu’ils ne surviennent. Les clients sont ainsi plus satisfaits et font davantage confiance au site. Cela contribue également à fidéliser les clients en évitant les ventes perdues, ce qui en fait un outil précieux pour les boutiques en ligne.
L'étape par son nom, sa capture d'écran, et le temps de chaque étape qui la précède.
Le résultat et l'alerte reprennent le nom de l'étape, si bien que "down" devient "3 - submit login stopped redirecting".
Capturée lorsqu'une étape échoue, à côté de celle prise après la dernière étape - ce à quoi ressemblait la page en cours de route.
Sites web, serveurs, API, certificats. Un type de vérification par page, avec les mêmes emplacements, alertes et rapports derrière.
"Je travaille avec ce service de surveillance depuis longtemps, et ma routine quotidienne n’est plus un problème. Il surveille silencieusement tous mes sites et me permet de réagir dès que quelque chose ne va pas."
Adopté par des équipes chez
Chaque chapitre s'ouvre sur place, pour que la page reste courte.
Le suivi synthétique signifie que le trafic est généré volontairement : plutôt que d’attendre qu’un visiteur rencontre un problème en espérant qu’il vous le signale, un service de surveillance sollicite lui-même votre site, selon un calendrier, depuis l’extérieur de votre réseau. Le suivi des transactions en est la forme multi-étapes. Une simple vérification synthétique interroge une URL et observe la réponse. Une vérification transactionnelle ouvre un véritable navigateur, parcourt un scénario ordonné - ouvrir la page, se connecter, effectuer une recherche, ajouter au panier, payer - et vérifie ce qu’elle constate à chaque étape.
Cette différence compte, car l’essentiel de ce que font réellement les clients sur un site web est une séquence, pas un simple affichage de page. Chaque page individuelle d’un parcours de paiement peut renvoyer un code HTTP 200 alors que le paiement lui-même est cassé : un bouton supprimé par un déploiement, un formulaire qui poste vers un endpoint qui renvoie désormais une 404, une erreur JavaScript qui bloque l’assistant à l’étape trois. Rien de tout cela n’apparaît dans un code de statut, donc rien de tout cela n’apparaît dans un suivi de disponibilité classique.
À ne pas confondre avec la surveillance des transactions financières. Dans la banque et la conformité, « transaction monitoring » désigne le contrôle des paiements pour détecter la fraude et le blanchiment d’argent. Cette page traite du sens « opérations web » : rejouer automatiquement un parcours utilisateur sur votre propre site pour prouver qu’il fonctionne toujours. HostTracker est un service de surveillance de sites web - il surveille votre parcours de paiement, pas votre grand livre de paiements.
Une vérification HTTP rapide est le bon outil pour répondre à « le site est-il en ligne ? ». Il s’agit d’une seule requête, donc son verdict tient en une seule réponse : le code de statut, le temps de réponse, et le mot-clé ou la règle d’assertion que vous avez définis sur le corps reçu. C’est une large couverture pour un coût très faible - et elle s’arrête précisément là où se termine la première réponse. Tout ce qui figure ci-dessous dans ce tableau se produit après ce point.
| Ce qui a réellement cassé | Vérification HTTP rapide | Vérification transactionnelle |
|---|---|---|
| Serveur injoignable, échec DNS, poignée de main TLS refusée | Détecté | Détecté |
| La page d’atterrissage renvoie une 500 après un déploiement | Détecté | Détecté |
| La page se charge, mais le bouton « Ajouter au panier » a été supprimé par une mise en production | Manqué - le HTML renvoie toujours 200 | Détecté - l’étape de clic ne parvient pas à résoudre son sélecteur |
| Le formulaire de connexion poste vers un endpoint qui renvoie désormais une 404 | Manqué - la page du formulaire elle-même est intacte | Détecté - l’étape suivant la soumission n’atteint jamais la page du compte |
| Une exception JavaScript bloque l’assistant de paiement à l’étape deux | Manqué - le JavaScript ne s’exécute jamais | Détecté - le navigateur exécute le script, et la vérification peut échouer sur les erreurs de console |
| La page de paiement affiche une bannière d’erreur au lieu de la confirmation | Manqué - une erreur affichée reste un 200 | Détecté - une assertion de contenu sur le texte de confirmation échoue |
| Le cookie de session cesse d’être défini, si bien que l’étape trois renvoie vers la page de connexion | Manqué - il n’y a pas de session à perdre | Détecté - une même session de navigateur exécute tout le scénario |
| Un script tiers - widget de chat, gestionnaire de balises, SDK de paiement - bloque l’affichage | Manqué - les ressources tierces ne sont jamais chargées | Détecté - le navigateur les charge comme le ferait un visiteur |
| Le parcours fonctionne, mais chaque étape prend désormais huit secondes | Partiellement - seule la première réponse est chronométrée | Détecté - chaque étape est chronométrée, et une étape peut expirer |
Aucune des deux vérifications ne remplace l’autre. La recommandation honnête est de faire tourner les deux : une vérification HTTP toutes les minutes sur le même site pour détecter rapidement les pannes, et une vérification transactionnelle sur les un ou deux parcours qui génèrent réellement du chiffre d’affaires. Si vous voulez commencer par le volet disponibilité, démarrez avec le suivi de disponibilité distribué depuis plus de 300 points de contrôle et ajoutez le parcours par-dessus.
Chaque exécution démarre un véritable navigateur Chromium headless sur l’un des points de contrôle de HostTracker et lui attribue une seule session de navigation pour tout le scénario. C’est ce détail, à lui seul, qui rend la vérification pertinente : les cookies, jetons et états de connexion définis à l’étape deux sont toujours présents à l’étape cinq, exactement comme ce serait le cas pour une personne naviguant sur votre site. Le JavaScript s’exécute, les redirections sont suivies - y compris celles déclenchées par vos propres scripts - et les ressources tierces se chargent comme le ferait le navigateur d’un visiteur.
Le scénario est séquentiel et s’arrête au premier échec. Les étapes s’exécutent dans l’ordre où vous les avez écrites, et la première étape qui échoue met fin à l’exécution et devient la cause rapportée. Vous n’obtenez jamais un mur d’erreurs en cascade causées par un seul bouton cassé - vous obtenez le bouton cassé.
Deux options facultatives modifient le degré de rigueur d’une exécution. Échouer sur erreur de console transforme toute erreur de la console du navigateur en échec de la vérification - puissant sur une application bien élevée, et associé à une liste d’autorisation pouvant contenir jusqu’à dix sous-chaînes, pour qu’un script tiers connu pour être bruyant ne déclenche pas de fausses alertes. Ignorer le chargement des fichiers médias est activé par défaut ; désactivez-la lorsque ce que vous testez est justement le média lui-même.
Une transaction est une liste d’étapes, et chaque étape est une action exécutée sur la page. Il n’y a pas d’enregistreur de macros susceptible de se périmer - vous construisez le scénario explicitement, ce qui explique aussi pourquoi il continue de fonctionner quand votre équipe marketing change le texte d’un bouton.
| Action | Ce que fait l’étape |
|---|---|
| navigate | Ouvrir une URL. La première navigation - vers l’adresse propre du moniteur - est ajoutée automatiquement comme étape zéro. |
| click | Cliquer sur un élément résolu par un sélecteur CSS, ou sur une coordonnée de la fenêtre d’affichage. Bouton gauche, droit ou du milieu, avec un délai de maintien facultatif. |
| type | Saisir du texte dans un champ, avec éventuellement un délai entre les frappes pour que les gestionnaires de saisie propres à la page suivent le rythme. |
| select | Vérifier la cardinalité d’un sélecteur : il doit correspondre à rien, exactement un élément, au moins un, ou un nombre quelconque. Agit sur toutes les correspondances, la première, ou une correspondance aléatoire. |
| checkContent | Vérifier le texte affiché. Jusqu’à dix mots-clés, dont un seul ou la totalité, sensibles ou non à la casse, présents ou volontairement absents, et facultativement uniquement dans le texte visible. |
| hover | Survoler un élément - la façon d’atteindre un menu ou une infobulle qui n’existe qu’au survol de la souris. |
| waitForNavigation | Attendre que la page navigue, en faisant éventuellement échouer l’étape si aucune navigation ne se produit à temps. |
| sleep | Marquer une pause, de 1 milliseconde jusqu’à 10 secondes, avec une variation aléatoire facultative pour que le scénario ne sollicite pas le même instant à chaque exécution. |
| screenshot | Capturer la page en cours de parcours, afin qu’un échec survenant deux étapes plus tard vous montre malgré tout à quoi ressemblait la page en chemin. |
| back | Revenir en arrière d’une entrée dans l’historique du navigateur. |
Toute étape peut être accompagnée d’une capture d’écran et d’une attente de navigation après son exécution, de son propre délai personnalisé, et d’un nom court de 19 caractères maximum. Nommez vos étapes - c’est ce nom qui apparaît dans le résultat et dans l’alerte, si bien que « 3 - soumettre connexion » fait toute la différence entre une page « en panne » et une page dont le POST de connexion a cessé de rediriger. Dans l’éditeur web, les captures d’écran et les attentes de navigation sont proposées comme comportements après-étape ; l’ensemble complet des actions, y compris le survol, est disponible via l’API.
id ou un attribut
data- que vous maîtrisez, et non un nom de classe généré qui change à la prochaine
build.checkContent après chaque transition
significative est ce qui transforme une suite de clics en un véritable test : après la
connexion, vérifiez le texte de la page de compte ; après le paiement, vérifiez le libellé de
confirmation.Si vous souhaitez vérifier la cohérence de l’URL de départ avant de construire le scénario, effectuez une vérification HTTP instantanée gratuite dessus - sans connexion requise - ou mesurez le chargement de la page dans un navigateur réel avec le test de vitesse de page gratuit.
L’exécution s’arrête à l’étape en échec et enregistre ce qu’elle a constaté. Le résultat nomme l’étape, classe l’échec - un délai dépassé, un élément que le sélecteur n’a pas pu résoudre, une assertion de contenu non vérifiée, une erreur HTTP, une erreur de connexion, une erreur de console du navigateur, ou une étape mal configurée - et conserve les durées par étape, l’URL, l’IP et le statut HTTP sur lesquels chaque navigation a abouti, les messages de la console du navigateur, ainsi qu’une capture d’écran de la page au moment de la panne.
Ce constat est ensuite recontrôlé avant que quiconque ne soit réveillé. Une seule observation en échec n’est pas traitée comme une panne : la vérification est relancée depuis d’autres points de contrôle indépendants, et le changement d’état n’est confirmé que lorsque le quorum est d’accord. Par défaut, le verdict repose sur une majorité parmi jusqu’à sept agents, avec un minimum de trois - de sorte qu’un point de contrôle instable, ou un incident réseau passager entre un centre de données et votre hébergeur, ne peut pas déclencher une alerte à lui seul.
Une fois la transition confirmée, l’alerte suit le délai choisi par chaque contact : immédiatement, ou seulement après 3, 5, 15, 30 ou 60 minutes, ou 3, 6, 12 ou 24 heures d’échec continu. Les alertes sont envoyées via les neuf canaux de notification pris en charge par HostTracker - e-mail, SMS, appel vocal, webhook, Slack, notification push et les messageries Telegram, Discord et Viber - et un avis de rétablissement suit lorsque le parcours recommence à se terminer avec succès.
Une vérification transactionnelle est le moniteur le plus puissant proposé par HostTracker, et celui qui comporte le plus de contraintes concrètes. Les connaître à l’avance vous fera gagner un après-midi.
Ces deux approches répondent à des questions différentes, et une équipe qui comprend cette distinction cesse d’attendre de l’une qu’elle fasse le travail de l’autre. HostTracker est un service de surveillance de sites web synthétique : il génère lui-même le trafic, depuis ses propres points de contrôle, selon un calendrier que vous contrôlez.
| Suivi transactionnel synthétique | Suivi des utilisateurs réels (RUM) | |
|---|---|---|
| Qui génère le trafic | Le service de surveillance, selon un calendrier fixe | Vos visiteurs réels, quand ils se présentent |
| Fonctionne avant même d’avoir du trafic | Oui - un site de préproduction sans utilisateurs est quand même vérifié | Non - pas de visiteurs, pas de données |
| Détecte une panne à 3 heures du matin | Oui - le calendrier ne dort jamais | Pas avant qu’un visiteur ne se présente |
| Nomme l’étape exacte qui a échoué | Oui - le scénario est déterministe | Rarement - vous voyez le symptôme, pas la séquence |
| Reflète ce qu’ont réellement vécu les clients | Non - c’est un échantillon contrôlé | Oui - c’est tout l’intérêt |
| Nécessite du code sur votre site | Non - tout s’exécute depuis l’extérieur | Un script ou SDK sur chaque page |
| Couvre un parcours que les clients terminent rarement | Oui - vous choisissez ce qui est testé | Non - les parcours rares restent non mesurés |
Si ce que vous cherchez ensuite est le volet performance plutôt que le volet parcours, HostTracker mesure aussi le chargement réel des pages dans un navigateur - voir le suivi du temps d’accès navigateur et de chargement des pages - et pour l’équivalent machine-à-machine d’une transaction, une vérification de surveillance d’API valide le contrat de réponse plutôt que la page affichée. Côté serveur, un moniteur de requêtes de base de données explique souvent pourquoi un parcours a d’abord ralenti.
Le suivi des transactions d’un site web est une vérification qui automatise un véritable parcours utilisateur en plusieurs étapes - comme remplir un formulaire, se connecter, ajouter un article au panier ou finaliser un achat - et confirme que chaque étape s’exécute correctement et que l’ensemble du parcours produit le résultat attendu. Contrairement à une simple vérification qui se contente de confirmer qu’une page se charge, le suivi des transactions suit le même chemin qu’un visiteur réel, en soumettant des données et en naviguant de page en page dans l’ordre, puis valide le résultat selon les règles que vous définissez. C’est important car un site peut sembler parfaitement fonctionnel selon tous les indicateurs de disponibilité simples - la page d’accueil se charge, les pages individuelles renvoient un code 200 - alors qu’un processus critique en plusieurs étapes comme le passage en caisse est silencieusement défaillant à mi-parcours. Le suivi des transactions de HostTracker est conçu spécifiquement pour détecter ce type de panne.
Le suivi des transactions de HostTracker peut automatiser et valider un large éventail d’interactions sur un site web, notamment la soumission de formulaires, les clics sur des boutons et les redirections de page en page qui, ensemble, reproduisent la façon dont un utilisateur réel navigue sur votre site. Cela couvre des scénarios courants comme la finalisation d’une inscription ou d’une connexion, la soumission d’un formulaire de contact ou de génération de prospects, et les processus d’achat en plusieurs étapes tels que l’ajout d’articles au panier suivi du passage en caisse. Comme la vérification simule le comportement réel d’un utilisateur étape par étape plutôt que de simplement charger une seule page, elle peut confirmer que chaque phase du processus fonctionne réellement et produit le résultat attendu, et pas seulement que les pages concernées se chargent. Cela la rend utile pour tout site où un parcours interactif défaillant - pas seulement une page en panne - vous ferait perdre des prospects, des inscriptions ou des ventes.
Le suivi de disponibilité de base vérifie si une seule page ou un seul point d’accès répond et renvoie un code de statut normal, ce qui indique que le serveur est joignable mais ne dit rien sur le bon fonctionnement d’un processus en plusieurs étapes construit par-dessus. Le suivi des transactions va plus loin en automatisant une séquence complète d’étapes - soumission d’un formulaire, navigation entre les pages, finalisation d’un parcours d’achat - et en vérifiant que chaque étape réussit et que le processus de bout en bout produit le résultat correct. Un site peut réussir toutes les vérifications de disponibilité alors que son processus de paiement est totalement défaillant à l’étape du règlement, car chaque page individuelle continue de se charger normalement prise isolément ; seule une vérification qui parcourt réellement la transaction peut détecter ce problème. Pour tout site dont les conversions dépendent d’un parcours en plusieurs étapes, le suivi des transactions couvre une catégorie de pannes que les vérifications de disponibilité de base ne peuvent tout simplement pas voir.
Oui, c’est l’un des principaux cas d’usage du suivi des transactions. Les vérifications transactionnelles de HostTracker parcourent une séquence d’étapes définie - comme ajouter un article au panier, passer à la caisse, remplir les champs requis et atteindre une page de confirmation - et vérifient que chaque étape se déroule comme prévu tout au long du parcours. Cela signifie qu’une panne introduite n’importe où dans le processus, qu’il s’agisse d’un bouton "ajouter au panier" cassé, d’un bug de validation de formulaire, ou d’une page de paiement qui ne se charge plus après un déploiement récent, est détectée et signalée avec des journaux détaillés pointant vers l’étape précise en cause. Détecter rapidement ce type d’incident est essentiel car un paiement défaillant coûte directement des ventes, et il peut passer inaperçu pendant longtemps avec de simples vérifications de disponibilité, puisque les pages individuelles concernées peuvent continuer à renvoyer un code de statut normal.
Lorsqu’une étape d’une vérification transactionnelle échoue - un formulaire ne se soumet pas, une page attendue ne se charge pas, ou une règle de validation n’est pas respectée - HostTracker enregistre le point de panne et envoie une alerte via vos canaux de notification configurés, afin que vous sachiez non seulement qu’un problème est survenu, mais aussi à quel endroit du parcours. Des journaux et rapports détaillés accompagnent l’alerte, fournissant aux administrateurs l’étape précise et le résultat nécessaires pour investiguer rapidement, plutôt que de devoir retracer manuellement l’ensemble du parcours. Ce niveau de détail par étape est ce qui rend le suivi des transactions concrètement utile pour résoudre les problèmes rapidement : savoir que "le paiement est cassé" est bien moins exploitable que de savoir que la panne survient précisément à l’étape de confirmation de paiement après un changement récent particulier, ce qui restreint considérablement les causes probables.
Non, bien que les parcours d’achat en plusieurs étapes en soient un exemple courant, le suivi des transactions est utile pour tout site web où une séquence d’actions utilisateur - et pas seulement le chargement d’une page - doit fonctionner correctement. Cela inclut les parcours de connexion et d’inscription pour les applications SaaS, les formulaires de génération de prospects et de contact pour les entreprises de services, les processus applicatifs en plusieurs pages, et tout parcours sur le site où un lien cassé ou une soumission de formulaire échouée en cours de route empêcherait un visiteur de terminer ce qu’il était venu faire. Tout processus interactif où perdre un utilisateur en cours de route a un coût réel - une inscription manquée, un formulaire de prospect abandonné, une candidature incomplète - bénéficie d’avoir ce parcours précis automatisé et vérifié régulièrement, plutôt que de supposer qu’il fonctionne toujours simplement parce que les pages concernées se chargent sans erreur.
Une vérification transactionnelle s’exécute selon un intervalle que vous choisissez, entre 10 minutes et 24 heures - 10, 15, 30 et 45 minutes, puis 1, 2, 4, 6, 12 et 24 heures. Ce plancher est plus élevé que le minimum d’une minute proposé par HostTracker pour les vérifications HTTP simples, et ce n’est pas un hasard : une vérification transactionnelle démarre un véritable navigateur, charge la page avec son JavaScript et parcourt votre scénario étape par étape, ce qui représente plusieurs secondes de travail réel plutôt qu’une simple requête. Le schéma habituel consiste à combiner les deux : une vérification HTTP ou ping toutes les minutes répond à la question « le site est-il joignable en ce moment ? », tandis qu’une vérification transactionnelle toutes les 10 ou 15 minutes répond à la question plus difficile de savoir si le paiement, la connexion ou le parcours d’inscription qui les sous-tend fonctionne toujours. Cette combinaison détecte une panne franche en une minute et un parcours défaillant en un seul cycle de vérification, sans faire tourner une session de navigateur contre votre application toutes les soixante secondes.
Non, et vous ne devriez pas le faire. Une vérification transactionnelle soumet de vrais formulaires sur votre site réel : la bonne configuration consiste donc à utiliser un compte de test dédié, un produit ou une référence de test et, si le parcours va jusqu’au paiement, le mode bac à sable ou carte de test de votre prestataire de paiement, exactement comme vous le feriez pour tout test de bout en bout automatisé. De nombreuses équipes arrêtent le scénario surveillé une étape avant l’action irréversible : atteindre la page de paiement, vérifier qu’elle s’affiche avec le bon montant total, et s’arrêter là. Cela suffit à prouver que toutes les étapes jusqu’au point de vente fonctionnent, sans créer de commande toutes les dix minutes. La même règle s’applique aux parcours d’inscription et de génération de prospects : pointez le scénario vers un formulaire de test dédié, ou filtrez de votre côté les soumissions issues du monitoring, afin que le trafic de surveillance ne pollue jamais vos données réelles.
Démarrez un essai gratuit et surveillez vos parcours utilisateur critiques - connexion, recherche, paiement - 24h/24 et 7j/7.
Fait partie du logiciel de monitoring site web de HostTracker.