Améliorez la détection précoce des défaillances (EFD) dans le Web Scraping avec des données de référence

La question de la "complétude"

L'un des problèmes les plus courants en matière d'assurance qualité (QA) pour le grattage Web, mais désarmant dans sa trivialité, est de s'assurer que le grattoir collecte tous les éléments du site Web cible.

C'est un problème d'étalonnage continu d'un outil qui mesure un objet en constante évolution.

Pourquoi cela arrive-t-il ?

Du plus facile à détecter au plus difficile (ce qui ne veut pas dire facile à résoudre..), nous avons les causes suivantes de collecte de données incomplète :

• le scraper est bloqué par les systèmes anti-bot
• le grattoir se perd dans les versions de test A/B du site Web
• le scraper est limité par les limites de pagination du site Web/de l'API
• le grattoir surplombe des parties du site Web (parfois créé après la conception du grattoir)

• 
  

En conséquence, nous avons une collecte de données partielle.

Détection précoce des pannes

La plupart des cas d'utilisation de web scraping ont des accords de niveau de service (SLA) qui peuvent entraîner des clauses pénales. L'assurance qualité vise à détecter le problème potentiel le plus tôt possible, avant que les SLA ne soient violés .

Pour ce faire, nous devons augmenter le taux de détection des défaillances (FDR) et réduire le taux de fausses alarmes (FAR). Avec une cerise sur le gâteau : maintenir les coûts bas .

Comment détecter les pannes

Analyse des séries chronologiques

Nous pouvons surveiller le nombre d'articles au fil du temps et déclencher une alerte lorsqu'il baisse. C'est un bon point de départ, mais bien qu'efficace avec des changements soudains (c'est-à-dire une baisse de 50%), il est moins fonctionnel lorsque les variations sont incrémentales, générant soit trop de fausses alarmes (FAR), soit ne détectant pas les erreurs.

Cela se produit parce que :

1. Les sites Web changent rapidement, surtout lorsqu'ils sont volumineux
2. Nous n'avons pas d'historique dans les données pour comprendre les tendances ou les saisonnalités, ce qui permettrait d'appliquer des algorithmes de séries chronologiques plus sophistiqués.

La limitation la plus critique de cette méthode est qu'elle ne repère pas les éléments manquants s'ils n'ont jamais été capturés par le grattoir.

Exemple

Un site Web de commerce électronique de mode peut avoir une catégorie «ventes» du site Web qui n'apparaît que pendant les périodes de vente officielles. Si vous construisez votre grattoir alors que la section n'est pas là, vous ne réaliserez peut-être jamais qu'il vous manque les articles de vente.

Inspection manuelle (vérité terrain)

L'inspection manuelle donne la plus grande confiance dans les résultats, comme indiqué dans cet article . Il fournit une soi-disant vérité au sol, et vous pouvez comparer le nombre d'articles que vous avez collecté par rapport au nombre d'articles effectué manuellement.

Limites:

1. Difficilement faisable pour les grands sites Web (vous pouvez savoir de manière fiable combien d'articles se trouvent sur le site Web d'Allbirds , mais pas de manière aussi fiable sur Farfetch ).
2. Difficilement évolutif : cela peut fonctionner pour quelques sites Web, et cela se fait rarement, mais les choses montent rapidement lorsque vous avez besoin de plusieurs sites Web volumineux avec une fréquence élevée (lisez l'approche de la boutique de données à ce sujet dans l'article sur les tests de vérité au sol ).

Cela conserverait un bon taux de fausses alarmes (FAR) mais n'atteindrait pas un taux de détection de défaillance (FDR) raisonnable, car la fréquence serait trop faible.

Analyse comparative indépendante

Une façon intelligente de résoudre ce problème consiste à comparer votre résultat, en termes de nombre d'articles, à une collection indépendante.

Pour que cette approche fonctionne correctement, les données de référence doivent être :

• Indépendant : pour réduire le risque d'être affecté par les mêmes biais de codage
• Rentable : Ça va sans dire , le web scraping est assez coûteux.

Une collecte de données indépendante est (presque) non corrélée à votre propre collecte de données : elle est corrélée car ils regardent le même objet, donc une défaillance de l'objet observé entraînerait en effet une perte dans les deux collectes de données, mais d'un autre côté, ils ' re résultats de processus indépendants, écrits par suis maintenu par différentes équipes, avec différentes techniques.

L'utilisation d'une source de données hautement fiable augmente fortement la fiabilité des résultats.

Supposons que votre taux de détection de défaillance (FDR) actuel soit de 90 %, ce qui signifie que votre système peut détecter automatiquement 90 % des fois qu'un scraper ne collecte que partiellement du site Web. Ou, en d'autres termes, votre ensemble de données, lorsqu'il est publié, contient 90 % des fois une collection complète.

Si nous supposons que les données de référence sont

a) aussi capable de détecter les erreurs que les données de production

b) indépendant

L'utilisation de données externes pour l'assurance qualité porterait le taux de détection d'échec à 99 % ( probabilité d'union de deux événements ).

1. Surveillez le nombre total d'articles dans votre collecte de données
2. Comparez-le avec le nombre total d'articles du même site Web sur Data Boutique
3. Lorsque votre décompte est inférieur au benchmark, vous avez votre détection de panne.

Pourquoi Data Boutique est une solution intelligente

Étant donné que les ensembles de données de Data Boutique intègrent des inspections manuelles dans leur processus d'assurance qualité, l'utilisation des données de Data Boutique comme référence est évolutive , rentable et un moyen fiable d'améliorer le processus d'assurance qualité (AQ) même lorsque vous faites du web-scraping en interne parce que il est très probable que les ensembles de données publiés sur Data Boutique dépassent ces niveaux de FDR.

1. Les deux structures de données ne doivent pas nécessairement être identiques : vous comparez uniquement le nombre d'éléments et n'avez pas besoin de la même structure, ce qui facilite grandement la mise en œuvre. Seule la granularité doit être comparable.

2. Vous pouvez sélectionner la fréquence de votre QA qui peut être inférieure à la fréquence de votre acquisition (si vous achetez des articles quotidiennement, vous ne pouvez avoir que des repères hebdomadaires, ce qui contribuerait encore très largement à améliorer les tests de qualité des données.

3. Étant donné que les données de Data Boutique sont fractionnables (comme expliqué dans cet article ), le coût d'achat de ces données peut être très faible par rapport à toutes les autres mesures de qualité.

   
   

En d'autres termes, même si la structure de données de Data Boutique ne correspond pas parfaitement à votre cas d'utilisation, l'utiliser pour les tests de qualité est une approche très efficace.

Rejoignez le projet

Data Boutique est une communauté d'échanges de données web durables, éthiques et de qualité. Vous pouvez parcourir le catalogue actuel et ajouter votre demande si un site Web n'est pas répertorié. L'enregistrement des ensembles de données dans votre liste d'intérêt permettra aux vendeurs de dimensionner correctement la demande d'ensembles de données et d'intégrer la plate-forme.

Vous trouverez plus d'informations sur ce projet sur nos chaînes Discord .

Aussi publié sur Data Boutique