Chronometrica ou ScraperLink : pourquoi une page de résultats Google peut sembler contenir des doublons

Commencez par définir l’unité à compter

Un élément de jeu de données est un objet enregistré. Il ne représente pas toujours 1 résultat de recherche. Un objet de page peut contenir plusieurs résultats dans une liste. Une liste stockée dans un autre objet est un tableau imbriqué.

Avant de compter les résultats, déterminez ce que représente chaque élément enregistré. 2 objets peuvent présenter 2 vues des mêmes observations. Si votre importation déplie les 2 vues, son total peut dépasser le nombre d’observations que vous souhaitiez utiliser.

Le signalement public concernant ScraperLink rapporte une préoccupation d’un lecteur au sujet de résultats en double. Ce signalement est ancien et clôturé. Il justifie la question du lecteur, mais ne démontre pas l’existence d’un défaut ou d’une panne actuelle. Ancien signalement de résultats en double

Les spécifications publiques des produits utilisées ici ont été vérifiées le 20 octobre 2026. Aucune collecte dans des conditions équivalentes ni aucune vérification de résultats en direct n’a été effectuée. Cette comparaison explique les entrées et les formats de sortie documentés.

3 décomptes répondent à des questions différentes :

• Éléments du jeu de données : combien d’objets ont été enregistrés ?
• Observations de résultats : combien d’entrées de résultats appartiennent aux recherches sélectionnées ?
• Destinations uniques : combien de pages cibles distinctes figurent dans ces entrées ?

Choisissez ce que vous comptez avant d’examiner le total. Un décompte correct des objets enregistrés peut tout de même donner une réponse erronée sur les résultats de recherche.

Appliquez la correction directe à votre requête actuelle

Utilisez cette entrée ScraperLink pour l’exemple fourni :

{
  "keyword": "Nike",
  "limit": "10",
  "page": 1,
  "include_merged": false
}

La spécification publique actuelle des entrées prend en charge ces réglages. Conservez `limit` sous forme de chaîne de caractères, comme indiqué ici. L’exemple demande 1 page avec une limite définie et désactive la sortie fusionnée. Version par défaut et schéma d’entrée de ScraperLink

Remplacez `Nike` par la requête souhaitée. Examinez la sortie avant de l’envoyer à un autre programme.

Repérez la liste de résultats imbriquée dans l’élément de page sélectionné. Comptez ses entrées. Vérifiez ensuite quel objet votre importation lit et quelle liste elle déplie. L’importation doit utiliser la représentation voulue 1 seule fois.

Ne multipliez pas la longueur de la liste par le nombre d’objets enregistrés. Déterminez d’abord si ces objets contiennent des observations distinctes ou différentes vues des mêmes observations.

Limitez la taille de cette première requête. Elle sert à vérifier le format de sortie et votre règle de comptage. Si l’élément de page convient déjà à votre prochaine étape, vous avez répondu au besoin immédiat. Envisagez un changement d’outil uniquement après avoir défini une exigence distincte que le processus actuel ne satisfait pas.

Comparez les sorties selon les besoins de votre prochaine étape

Un critère d’acceptation est une condition que la sortie doit remplir avant son utilisation. Utilisez le tableau pour rédiger ce critère. La ligne consacrée aux entrées énumère les réglages de ces exemples ; elle n’affirme pas que chaque champ est obligatoire.

Les colonnes des produits s’appuient sur leurs spécifications documentées actuelles. Actor ScraperLink, Actor Chronometrica, Schéma d’entrée de Chronometrica

Le dépliage consiste à transformer chaque entrée d’une liste imbriquée en une ligne distincte. Pendant cette opération, conservez le contexte de recherche propre à chaque entrée.

Une étape de dépliage qui fonctionne peut rester dans votre processus. Le choix dépend du système destinataire. S’il accepte les objets de page, un changement de format de sortie peut ne rien apporter d’utile. S’il exige des observations individuelles, décidez si vous souhaitez conserver l’étape de dépliage ou recevoir directement ce format en lignes.

Exemple fictif : 2 objets ne prouvent pas la présence de 20 résultats

Cet exemple est fictif. Il ne s’agit ni d’un test de produit, ni d’un résultat mesuré, ni d’un cas client.

Un analyste demande 1 page. Dans cet exemple inventé, la page brute contient 10 observations de résultats imbriquées. Un objet fusionné facultatif reprend ces mêmes 10 observations.

L’analyste voit 2 objets enregistrés. Son importation déplie les 2 :

10 observations from the raw page
+ 10 repeated observations from the merged object
= 20 imported sightings

Le calcul est correct : 10 + 10 = 20. L’interprétation est erronée. Le décompte attendu pour cette seule page est de 10 observations. La feuille de calcul contient 2 copies de chaque observation, car l’importation a utilisé les 2 représentations.

L’analyste désactive la sortie fusionnée. Il lit ensuite 1 seule fois la liste de résultats de la page brute et vérifie sa longueur. Dans cet exemple fictif, cette opération évite le double dépliage.

Cet exemple ne montre pas qu’un Actor a récupéré une page 2 fois ou l’a facturée 2 fois. Le seul décompte des objets enregistrés ne permet d’établir aucun de ces 2 faits.

L’analyste doit faire un autre choix plus tard, lorsqu’une autre API exige que chaque élément envoyé représente 1 observation. Il peut conserver l’étape de dépliage ou choisir un Actor dont la sortie documentée répond déjà à cette exigence.

Chronometrica répond à ce besoin ultérieur de données en lignes. Le total inventé ne prouve aucun avantage en matière de performances de collecte.

Quand Chronometrica répond au besoin

Chronometrica documente 1 observation de résultat de recherche par ligne du jeu de données, avec le moteur, la requête, le rang et le contexte. Sa documentation décrit aussi `maxResultsPerExecutedQuery`, qui fixe un plafond de lignes de résultats pour chaque combinaison de moteur et de requête exécutée. Actor Chronometrica

Utilisez cet exemple d’entrée fourni comme point de départ :

{
  "queries": [
    "Nike"
  ],
  "engines": [
    "google"
  ],
  "maxResultsPerExecutedQuery": 10,
  "country": "US",
  "language": "en"
}

Les clés, les champs obligatoires, les valeurs autorisées, les limites des listes et les bornes numériques ont été vérifiés dans le schéma public actuel. Cet exemple n’a pas été exécuté. Version par défaut et schéma d’entrée de Chronometrica

Le plafond est une limite supérieure. Il ne prouve pas qu’une requête renverra exactement 10 observations. Vérifiez la sortie réelle avant d’en communiquer le décompte.

Ce format convient à une feuille de calcul qui stocke 1 observation par ligne. Il convient aussi à une API qui attend 1 observation dans chaque élément envoyé. L’unité enregistrée correspond à celle dont l’étape suivante a besoin.

Cette correspondance évite de devoir d’abord déplier une liste de résultats imbriquée. Vous devez toujours sélectionner les champs utilisés par votre système, conserver les valeurs inconnues comme telles et vérifier la sortie. Vous pouvez aussi avoir besoin d’une liste distincte de destinations uniques.

Choisissez Chronometrica pour cette adéquation vérifiée. Les éléments disponibles ne démontrent aucun avantage en matière de vitesse, de fiabilité, d’exactitude ou de coût. Avant de changer d’outil, confirmez toute autre fonction nécessaire dans la documentation actuelle.

Effectuez 5 vérifications avant de changer d’outil

1. Consultez le réglage actuel de la sortie fusionnée. Déterminez quelle représentation de sortie votre processus exige. Traitez séparément le problème immédiat de comptage et le choix ultérieur d’un format en lignes.
2. **Demandez 1 page avec une limite définie et `include_merged:false`.** Enregistrez l’entrée exacte. Vous pourrez ainsi relier la sortie à la requête et à la page demandées.
3. Comptez les entrées de résultats imbriquées. Examinez la liste de résultats de la page brute sélectionnée. Vérifiez que votre importation lit cette liste 1 seule fois. Comparez le nombre d’entrées au nombre de lignes créées par le dépliage.
4. Définissez l’unité exigée par l’étape suivante. Écrivez une phrase, par exemple : « Chaque ligne importée doit représenter 1 résultat pour 1 requête exacte. » Utilisez cette phrase comme critère d’acceptation.
5. Conservez le contexte de recherche avant de créer une liste de destinations uniques. Gardez le moteur, la requête exacte, le rang et les informations temporelles disponibles. Indiquez clairement que toute heure enregistrée par votre propre processus provient de celui-ci.

Ces vérifications conduisent à 2 décisions. Déterminez d’abord si vous pouvez compter correctement la sortie actuelle. Décidez ensuite si son unité enregistrée convient au système suivant.

Pour une feuille de calcul gérée manuellement, une étape de dépliage peut être facile à contrôler. Pour une importation répétée, des lignes de résultats fournies directement peuvent mieux correspondre au système destinataire. Examinez le travail nécessaire dans votre processus avant de supposer un gain de temps.

Si vous comparez ensuite les coûts, définissez séparément l’unité de facturation. Un objet enregistré, une observation de résultat et une recherche facturée sont des concepts différents. Le total d’une sortie fusionnée ne permet pas d’établir le nombre de recherches facturées ni un avantage tarifaire.

Vérifiez l’importation avant d’utiliser ses totaux

Rendez le critère d’acceptation assez précis pour pouvoir le vérifier. « La sortie semble correcte » vous aide peu lorsque les totaux diffèrent. Un critère utile précise la liste source, l’unité comptée et le contexte que chaque ligne importée doit conserver.

Commencez par la sortie sélectionnée, avant le dépliage. Comptez les observations que vous souhaitez utiliser. Examinez ensuite les lignes créées à partir de cette sortie. Si ces totaux diffèrent, vérifiez quels objets et quelles listes l’importation lit avant de supprimer des lignes.

Une règle qui supprime les URL répétées peut masquer la cause d’une erreur de comptage. Elle peut aussi supprimer des observations valides issues de requêtes distinctes. Corrigez d’abord la sélection des représentations de sortie. Créez une liste de destinations uniques uniquement si vous avez besoin de ce décompte distinct.

Consignez le résultat de la vérification en termes simples. Précisez si vous avez compté des objets de page, des observations ou des destinations. Le total sera ainsi utile à une personne qui n’a pas examiné la sortie d’origine.

Distinguez les observations des destinations uniques

Une même destination peut apparaître pour différentes requêtes. Ces apparitions peuvent constituer des observations distinctes, même si elles renvoient à la même page.

Une liste de destinations uniques indique quelles pages sont apparues. Les enregistrements d’observations indiquent où une page est apparue, pour chaque requête et chaque rang. Conservez les 2 sorties si vous avez besoin des 2 réponses.

Créez la liste de destinations à partir des enregistrements d’observations. Conservez ces enregistrements pour pouvoir retrouver le contexte de recherche d’une destination. Ne supprimez pas une observation uniquement parce que son URL est aussi apparue pour une autre requête.

Cette distinction aide aussi lorsque 2 personnes communiquent des totaux différents. L’une peut avoir compté les observations et l’autre les destinations. Précisez l’unité avant de considérer leurs totaux comme des résultats contradictoires.

Pour combiner ensuite des exports issus de plusieurs exécutions, consultez Comment fusionner des exports de recherche Bing sans perdre les informations de requête et de rang. Ce guide porte sur la fusion entre exécutions. La présente comparaison commence plus tôt, avec le choix des représentations de sortie et des unités enregistrées.

Conservez les valeurs inconnues comme telles pendant l’importation

Une valeur absente ne signifie pas 0. Un rang manquant ne doit pas devenir un rang de 0. Un décompte inconnu ne doit pas devenir un décompte confirmé de 0.

Laissez une valeur inconnue vide ou utilisez la représentation des valeurs manquantes prise en charge par votre système destinataire. Documentez ce choix pour que les calculs ultérieurs ne traitent pas les données manquantes comme un résultat mesuré.

Appliquez la même règle aux informations temporelles. N’inventez pas d’horodatage provenant de la source. Si vous connaissez uniquement le moment où votre propre processus a reçu les données, enregistrez-le avec un libellé clair.

Vérifiez ces règles avec chacun des formats de sortie. Des lignes distinctes peuvent être plus faciles à accepter pour un système destinataire, mais elles exigent toujours une interprétation correcte. Un décompte valide des lignes ne prouve pas que tous les champs sont présents ni que chaque valeur a le sens supposé dans votre rapport.