La surveillance des avis ressemble à un problème de reporting mais se comporte comme un problème de collecte de données. Les avis sont publics, les pages sont faciles à lire, et puis le premier balayage sérieux se heurte aux deux éléments qui rendent ce travail non trivial : ce qu’affiche une page d’avis dépend de l’origine de la requête, et demander les mêmes pages chaque jour est exactement le type de comportement de trafic que les systèmes anti-bot sont conçus pour repérer.
Cet article explique comment les proxies s’intègrent dans ce contexte, ce qu’il faut collecter, et comment maintenir un pipeline d’avis stable une fois qu’il fonctionne selon un calendrier.
Ce qui casse réellement sans proxies
Commençons par la localisation. Les avis Google, les boutiques d’applications, les domaines pays de Trustpilot et les grandes places de marché font tous varier leur contenu selon la région du demandeur. La note moyenne peut différer, l’ensemble des avis diffère, des versions traduites apparaissent dans certaines régions et pas dans d’autres, et sur les places de marché, l’annonce elle-même peut ne pas exister dans un pays donné. Une équipe qui surveille depuis l’IP d’un seul bureau ne voit pas une image globale. Elle voit l’image d’un seul pays et l’appelle globale.
Vient ensuite le volume. Une marque qui suit quelques centaines de produits, ou quelques centaines d’emplacements de magasins, demande des milliers de pages par jour, tous les jours, depuis une adresse stable. C’est une empreinte identifiable. La réponse n’est généralement pas un bannissement immédiat au début, c’est une dégradation : réponses plus lentes, page interstitielle, liste d’avis tronquée, page de vérification qui renvoie un 200 valide sans aucune donnée. Les pipelines qui ne vérifient pas cela enregistrent silencieusement des zéros et le tableau de bord affiche une sécheresse d’avis qui n’a jamais existé.
Les proxies répondent aux deux problèmes. Le ciblage géographique place la requête dans le marché dont vous voulez les avis, et répartir le trafic sur un large pool résidentiel maintient chaque adresse individuelle bien en dessous du seuil à partir duquel un site commence à s’en préoccuper.
Quel type de proxy convient à quelle cible
Les surfaces d’avis grand public sont le cas difficile. Google, Trustpilot, G2, Capterra, l’App Store et le Play Store, Amazon et les places de marché régionales sont tous protégés par une gestion mature des bots. Ces sites veulent des IP résidentielles, car ces adresses appartiennent à de vraies connexions de consommateurs et portent le profil de confiance sur lequel le site évalue. C’est la majeure partie de la plupart des programmes de surveillance des avis.
Les proxies ISP trouvent leur place là où le flux a un état. Si les avis n’apparaissent qu’après avoir choisi un magasin, défini un lieu de livraison, ou s’être connecté à un compte vendeur que vous possédez, une adresse stable tout au long de ces étapes vaut plus que la rotation. Les adresses ISP sont statiques et acheminées comme des connexions grand public, ce qui est exactement la combinaison dont ce scénario a besoin.
Les proxies datacenter restent pertinents sur la longue traîne : sites d’avis de niche spécifiques à un secteur, forums, flux publics, tout ce qui a des défenses légères. Le coût par requête est plus faible et la pénalité de confiance ne s’applique pas. Les envoyer contre les avis Google est là où les équipes gaspillent de l’argent, car une requête bon marché qui renvoie une page de vérification n’est pas bon marché.
La plupart des configurations matures acheminent par cible plutôt que de choisir un seul type. Les plateformes grand public difficiles passent par le résidentiel, les flux avec état passent par le sticky, le reste, plus simple, passe par ce qui est le moins cher. Notre note sur comment éviter les blocages lors du scraping traite du même problème au niveau de la requête.
Rotation, sessions et rythme
La plupart des collectes d’avis sont une simple lecture de page : demander une URL, analyser les avis, passer à la suivante. Faire tourner l’IP à chaque requête est le bon réglage par défaut, et c’est ce qu’un point de terminaison résidentiel rotatif fait sans aucun travail de votre part.
Les sessions sticky importent pour les exceptions. La pagination d’une liste d’avis dépend souvent d’un curseur que le site attribue à une session, et les avis conditionnés par la localisation dépendent d’un choix que le site a stocké pour cette session. Changer d’IP en cours de flux réinitialise cet état et vous obtenez soit la première page à nouveau, soit un résultat vide. Maintenez la session pendant toute la durée du flux, puis abandonnez-la.
Le rythme est l’aspect dans lequel les équipes sous-investissent. Le nombre d’avis évolue lentement. Il n’y a aucun intérêt à marteler une page produit toutes les heures quand les données sous-jacentes changent chaque semaine, et le coût de le faire est un taux de blocage plus élevé sur les pages qui vous importent réellement. Adaptez la fréquence d’exploration à la vitesse d’accumulation des avis sur cette cible : quotidienne pour les annonces de places de marché à fort volume et les boutiques d’applications, hebdomadaire pour la plupart des annuaires de logiciels B2B, et déclenchée par événement autour des lancements et campagnes lorsqu’un pic est attendu.
Choisir ce qu’il faut collecter
Le réflexe est de tout récupérer. Un pipeline plus utile collecte les champs qui appuient les décisions et laisse tomber le reste.
La note et le nombre d’avis par produit, par emplacement et par marché vous donnent la tendance. Le texte de l’avis, la date et la langue vous donnent la substance, et la langue est ce qui permet d’orienter une réclamation vers une équipe capable de la lire. Les indicateurs d’achat vérifié et l’historique du rédacteur séparent le vrai signal des campagnes. L’identité du vendeur ou de l’annonce compte sur les places de marché, où le même produit vendu par un contrefacteur porte des avis que vous voulez connaître mais ne voulez pas mélanger avec votre propre moyenne.
Deux choses valent la peine d’être évitées. Stocker plus de données personnelles que ce dont l’analyse a besoin transforme un pipeline d’avis en problème de protection des données sans aucun bénéfice, et les noms des rédacteurs d’avis se justifient rarement. Et le texte des avis est écrit par d’autres personnes, donc l’agréger pour l’analyse est une chose, mais le republier comme contenu de site en est une autre.
Pour les équipes dont l’intérêt pour les avis est réputationnel plutôt qu’analytique, la protection de marque et la veille sociale couvrent les surfaces adjacentes où la même réclamation apparaît généralement en premier.
Construire le pipeline
Les mécanismes sont ordinaires. Un planificateur pilote une liste de travail d’URL par marché, chaque requête sort via un point de terminaison proxy avec le pays défini pour cette ligne, la réponse va vers un analyseur, et les avis analysés atterrissent dans un stockage indexé par plateforme, produit et marché, de sorte que le même avis ne soit jamais compté deux fois.
Les éléments qui déterminent s’il survit au contact avec la production sont moins évidents.
Validez les réponses plutôt que de faire confiance aux codes de statut, car une page de vérification renvoie un 200 et s’analyse en zéro avis. Une exécution qui découvre soudainement aucun avis sur une page qui en avait quatre cents hier est un échec de collecte, pas un événement commercial, et le pipeline devrait le signaler.
Récupérez à moindre coût. Les pages d’avis contiennent des images, des polices et des scripts d’analyse qui ne contribuent en rien à l’analyse. Les bloquer réduit considérablement la bande passante, et sur un forfait facturé à la bande passante, c’est la différence entre quelques Go par mois et une facture qui vaut la peine d’être contestée.
Ne faites du rendu que lorsque c’est nécessaire. Certaines sections d’avis sont rendues côté serveur et une simple requête HTTP suffit. D’autres nécessitent un navigateur headless, ce qui coûte un ordre de grandeur de plus, tant en bande passante qu’en temps. Vérifiez par cible plutôt que de faire passer tout par défaut par un navigateur.
Conservez la réponse brute pendant une courte fenêtre. Quand un analyseur casse parce qu’une plateforme a changé son balisage, et cela arrivera, avoir le HTML d’hier transforme la correction en un travail de dix minutes plutôt qu’en une nouvelle exploration complète.
Si votre équipe n’a aucune envie de maintenir tout cela, une API de scraping renvoie une sortie structurée et absorbe la rotation, le rendu et la logique de nouvelle tentative à un prix par requête plus élevé. Le compromis est de l’argent contre du temps d’ingénierie, et pour un programme d’avis qui traite quelques milliers de pages par jour, c’est généralement un compromis équitable seulement tant que le programme reste petit.
Ce que cela coûte
La surveillance des avis est l’une des charges de travail proxy les moins coûteuses, car les pages sont petites une fois que vous arrêtez de télécharger les ressources, et la fréquence d’exploration est faible.
Avec la tarification résidentielle qui commence à 1,00 $/Go, un balayage quotidien sur quelques milliers de pages produits et plusieurs marchés représente généralement un chiffre de bande passante mensuel à un chiffre. Les variables qui le font bouger sont le rendu headless, le chargement des images et les explorations trop fréquentes, dans cet ordre. Les trois sont des décisions d’ingénierie plutôt que des décisions de tarification, ce qui est utile à savoir avant de blâmer la facture proxy.
L’adéquation de Shifter ici est la classique : plus de 205 millions d’IP résidentielles dans plus de 195 pays avec ciblage au niveau de la ville et ciblage ASN, sessions rotatives et sticky sur le même compte, et connexions simultanées illimitées afin qu’un balayage de marché puisse s’exécuter en parallèle plutôt qu’en séquence. Les chiffres indépendants sur le comportement du réseau se trouvent sur la page des benchmarks plutôt qu’affirmés ici.
La partie qui n’est pas de l’infrastructure
La collecte est la moitié facile. Les avis ne valent la peine d’être surveillés que si quelque chose en résulte, et les programmes qui portent leurs fruits acheminent un avis négatif vers l’équipe propriétaire du produit, pas vers un tableau de bord que personne n’ouvre.
Cela signifie décider à l’avance ce qui déclenche une action : une note qui tombe sous un seuil dans un marché spécifique, un pic d’avis mentionnant un mot précis, une annonce apparaissant sous un vendeur que vous ne reconnaissez pas, la note d’un concurrent dépassant la vôtre dans une catégorie que vous défendez. La couche proxy existe pour s’assurer que ces signaux sont complets et à jour sur chaque marché où vous vendez. Ce que vous en faites est le véritable travail.
À lire ensuite : comment scraper des données d’entreprises locales avec des proxies, qui traite de la version au niveau local du même problème de collecte.