Comment fusionner des exports Bing sans perdre les traces des requêtes et des positions

1. Définissez vos règles de collecte

1. Définissez vos règles de collecte en remplaçant entièrement les listes enregistrées de requêtes et de moteurs par 1 requête voulue et `["bing"]`, avec `maxResultsPerExecutedQuery: 2`, les États-Unis comme pays, l’anglais comme langue, `safeSearch: true` et `includeSponsoredResults: false`. Aucun paramètre public de limitation du nombre de pages n’est prescrit.
2. Enregistrez les lignes brutes des résultats Bing et les métadonnées OUTPUT. Les champs natifs des lignes comprennent `runId`, `country`, `language`, `safeSearch`, `engine`, `executedQuery`, `page`, `rankOnPage`, `rank`, `title`, `canonicalUrl`, `resultDomain`, `snippet`, `isSponsored`, `advertiserDomain`, `observedAt` et `schemaVersion`. Conservez toutes les informations qui identifient l’exécution et ses paramètres.
3. Construisez une clé d’observation à partir de `runId` + `engine` + `executedQuery` + `page` + `rankOnPage`. Conservez rank et observedAt comme éléments de preuve. Retirez de votre table de travail les lignes d’export strictement identiques et consignez chaque doublon. Si une clé répétée présente des valeurs d’URL contradictoires, mettez les 2 valeurs candidates en attente d’un examen de la source. Ne choisissez pas une valeur sans le signaler et ne vous fiez pas à la majorité.
4. Créez une clé de cible à partir de la `canonicalUrl` renvoyée : une adresse candidate normalisée, et non une preuve d’URL canonique HTML ou un href d’origine. Partez des chaînes d’URL exactes qui ont été renvoyées. Si vous normalisez la casse du nom d’hôte, les fragments ou les paramètres de suivi, consignez pourquoi la destination reste la même. Les chemins ou les paramètres de requête différents restent distincts.
5. Reliez les observations à la table des cibles au moyen d’une colonne de clé de cible. Une même URL trouvée par 2 requêtes ou à 2 moments différents correspond à plusieurs observations et à 1 cible examinée. L’association à une requête repose uniquement sur des observations réelles.
6. Exportez les tables de travail sans altérer les données. Préservez les guillemets, les virgules, les sauts de ligne et les caractères Unicode des requêtes. Utilisez le JSON ou le JSONL brut comme référence principale, car les outils d’export ou d’import CSV peuvent effacer la distinction entre une valeur nulle et une valeur vide. Vérifiez la restitution exacte après export et réimport avec un petit jeu de données de test avant de fusionner de grands exports.
7. Présentez des décomptes distincts pour les lignes brutes, les lignes d’export en double, les observations valides distinctes, les conflits et les clés de cible distinctes. Les URL distinctes ou les associations aux requêtes ne permettent pas d’estimer le volume total des recherches ni l’ensemble des sites web. Conservez les recherches en échec, sans résultat ou ayant atteint une limite dans votre compte rendu de collecte.
8. Transmettez les adresses cibles et les références des observations à une vérification distincte des destinations. La fusion des ressources ne prouve ni l’accès aux pages, ni leur pertinence, ni la fiabilité des sources. Précisez que le périmètre se limite à Bing.

Registre de fusion fictif et contrôle des données

*Remarque : les tableaux et les enregistrements suivants sont des exemples fictifs originaux conçus à des fins pédagogiques.*

Imaginez un test où l’exécution R1 avec la requête "AI agents" donne U1 en position 1 et U2 en position 2. L’exécution R1 avec la requête "small business automation" donne U2 en position 1 et U3 en position 2. L’exécution R2 avec la requête "AI agents" donne U1 en position 1 et U4 en position 2. Tous sont des résultats Bing obtenus avec des paramètres déclarés identiques, chacun avec son propre horodatage. Les 6 clés d’observation correspondent à 4 clés de cible : U1, U2, U3 et U4. U1 compte 2 observations à des moments différents ; U2 compte 2 observations pour des requêtes différentes. Aucune de ces répétitions n’est une ligne d’export en double.

Une 7e ligne brute répète exactement R1 / requête "AI agents" / page 1 / position 2 U2. Elle reproduit à l’identique chaque valeur brute d’origine et constitue donc une ligne d’export en double. Une 8e ligne portant la même clé contient U9. La clé R1+bing+AI agents+1+2 présente un conflit pour U2 ET U9 ; mettez les 2 valeurs candidates en attente dans le registre des conflits au lieu de vous fier à la première valeur ou à la majorité. On conserve ainsi 8 lignes brutes, 1 ligne d’export en double, 6 clés d’observation, 1 clé en conflit, 5 observations sans conflit et 4 cibles validées. U9 reste exclue des cibles validées.

*Tableau fictif original de 8 lignes brutes.*

*Tableau fictif original des statuts de 6 clés.*

*Tableau fictif original de référence des cibles (4 cibles validées).*

*Petit jeu de données de test CSV fictif original contenant un saut de ligne intégré, des guillemets doublés, le mot Unicode café et une requête avec une virgule :*

Extrait de code

runId,engine,executedQuery,page,rankOnPage,title,canonicalUrl
"R1","bing","garden, tray",1,1,"Café guide
""Best picks""","https://example.com/garden"

*Valeurs décodées du jeu de données de test et vérification par le lecteur :* Le champ de requête se décode en `garden, tray`. Le champ de titre se décode en `Café guide`, suivi d’un véritable saut de ligne et d’une seule paire de guillemets autour de `Best picks`. Le champ canonicalUrl se décode en la chaîne simple `https://example.com/garden` sans syntaxe Markdown. Une vérification par le lecteur après export et réimport confirme que la séparation par virgules, les sauts de ligne intégrés, les paires uniques de guillemets et les caractères Unicode sont correctement préservés. Toute affirmation selon laquelle une analyse, une écriture ou une lecture en Python a été effectuée s’applique uniquement à ce jeu de données fictif, jamais à un export d’Actor ou à un grand jeu de données.