Lire la page de résultats Naver derrière un proxy

Vouloir mesurer un moteur de portail comme un moteur de recherche classique produit un résultat erroné dès le premier tour. Sur un moteur classique, la question « à quelle position suis-je ? » a une réponse claire ; dans une logique de portail, la même requête renvoie une page où s'empilent des blocs issus de sources indépendantes. Gagner une place dans la liste organique ne signifie rien si ce bloc a glissé très bas dans la page.

Le proxy n'agit pas sur l'ensemble de ce tableau, mais sur une seule entrée : l'appartenance apparente du réseau d'où provient la requête. Cette entrée est utile surtout pour les blocs sensibles à la localisation ; la langue, la session et les préférences d'interface, elles, restent identiques indépendamment de votre sortie et continuent de polluer la mesure.

Vous trouverez ci-dessous, dans l'ordre : les éléments qui composent la page, la hiérarchie des signaux de localisation, l'isolement de la session, le test de la recherche avancée et, enfin, le choix de la sortie et les étapes de configuration.

Pourquoi la réponse à une requête n'est-elle pas une simple liste ?

Naver est depuis longtemps un service qui s'est développé bien plus comme un portail que comme une simple boîte de recherche. La conséquence sur la page de résultats est nette : selon le type de requête, les blocs issus de ses propres services de contenu, les documents web généraux et les cartes locales sensibles à la localisation partagent la même page. Sur une requête conceptuelle, les articles et discussions de son écosystème passent au premier plan, tandis que sur une requête portant sur un établissement ou un lieu, les cartes locales et le bloc cartographique remontent.

Pour la mesure, cela a deux conséquences. Premièrement, la donnée à enregistrer n'est pas la « position », mais la « composition des blocs » : quels blocs figurent sur la page, dans quel ordre et combien d'entrées chacun affiche. Deuxièmement, pour interpréter l'écart entre deux tours, vous devez d'abord regarder si la composition a changé ; si l'ordre des blocs a bougé, la variation des entrées inférieures est un résultat attendu.

La diversité des sources des blocs détermine également la sensibilité à la langue. Sur une requête rédigée en coréen, le contenu issu de ses propres services est abondant ; sur le même concept en caractères latins, la page bascule vers des documents web généraux et un ensemble plus clairsemé. Si vous souhaitez construire une comparaison dans deux langues, menez-les comme deux séries distinctes ; une comparaison linguistique comprimée dans un seul tableau est ininterprétable.

Enfin, la version de l'interface : les rendus sur écran étroit et sur écran large peuvent présenter des ordres de blocs différents. Si vous n'enregistrez pas dans quel affichage votre tour de mesure a été effectué, il sera impossible pour quelqu'un d'autre de le reproduire ensuite.

D'où les cartes cartographiques et d'établissement tirent-elles la localisation ?

Les blocs sensibles à la localisation constituent le test de proxy le plus utile à votre disposition, car ils changent visiblement de comportement lorsque le pays de sortie change. Mais l'estimation de localisation ne provient pas uniquement de l'IP. Les entrées suivantes interviennent dans cet ordre : la région explicitement choisie par l'utilisateur au sein du service, les préférences antérieures transportées par la session, l'autorisation de localisation du navigateur et, enfin, l'inférence géographique du réseau d'où provient la requête.

Cet ordre importe, car les entrées supérieures écrasent les inférieures. Si vous avez sélectionné une région dans le service, déplacer votre sortie vers un autre pays peut ne rien changer aux cartes locales. C'est une cause très fréquente de ce que l'on interprète comme « le proxy ne fonctionne pas » : le proxy fonctionne, mais un signal plus fort l'écrase. Pour un test propre, aucune région ne doit être sélectionnée dans le profil et aucune autorisation de localisation ne doit être accordée au navigateur.

Si vous avez besoin d'un affichage au niveau de la ville, choisir un pays peut ne pas suffire. Certains pools proposent un ciblage au niveau de la ville ou du fournisseur ; la méthode et ses limites sont détaillées dans l'article ciblage par ville et par ISP . Acceptez néanmoins ceci d'emblée : l'inférence de ville est approximative, une même adresse peut être rattachée à des villes différentes selon les sources de données.

Écarter l'état connecté de la mesure

La page de résultats que vous voyez en étant connecté est façonnée par les préférences liées à votre compte. C'est souhaitable dans un usage quotidien ; en mesure, c'est le premier facteur de contamination. En effet, l'historique lié à votre compte vous suit lorsque vous changez de sortie et produit l'impression « j'ai changé de pays mais le résultat est le même ».

La bonne configuration est simple mais exige de la discipline : les tours de mesure s'exécutent toujours dans un profil vierge, sans connexion. Si vous devez mesurer un scénario nécessitant une connexion, menez-le comme une série distincte avec une sortie fixe ; ne comparez pas dans le même tableau des tours avec et sans session. Les deux séries mesurent des choses différentes.

Dans les scénarios avec session, une deuxième règle s'applique : la stabilité de l'adresse. Qu'une session provienne, à intervalles rapprochés, d'adresses situées dans des pays éloignés crée un tableau incohérent et peut entraîner une demande de vérification supplémentaire. Pour ce type de travail, utilisez une session sticky, choisissez une durée plus large que votre session de travail et n'oubliez pas que vous ne recevrez pas d'alerte à l'expiration (configuration des sessions sticky).

Quel signal pèse le plus ?

Les indicateurs ci-dessous présentent, à titre illustratif, le poids relatif des trois signaux qui façonnent les blocs sensibles à la localisation. Il ne s'agit pas de valeurs mesurées, mais de scores indiquant quelle variable neutraliser en premier lors de la configuration : le signal ayant le score le plus élevé est celui qui a le plus de force pour écraser les autres.

La règle pratique qui en découle : si vous voulez observer l'effet du proxy, vous devez d'abord neutraliser manuellement les signaux plus forts que lui. Un test par pays effectué alors qu'une sélection de région subsiste dans le service ne mesure pas du tout le côté réseau. Il n'existe aucun moyen d'inverser la hiérarchie ; la seule chose possible est de désactiver les signaux supérieurs.

La deuxième règle pratique est celle de la variable unique. Dans un tour, ne changez que le pays de sortie, sans toucher à la liste des langues ni au profil. Au tour suivant, ne changez que la langue et gardez la sortie fixe. Dans un tableau où vous faites varier deux variables ensemble, personne ne peut dire quel écart provient de laquelle — le résultat est un amas de données sur lequel aucune discussion n'est possible.

La troisième est le nombre de répétitions. Un seul relevé reflète l'état de l'index et la composition des blocs à cet instant ; le lendemain, la même requête peut donner autre chose. En répétant la même requête dans les mêmes conditions, plusieurs fois et sur plusieurs jours, vous mesurez la variation naturelle et apprenez du même coup quelle amplitude doit avoir un écart pour être réel.