Analyse du module QualityNsrPQData

Que signifie QualityNsrPQData ?

Dans la Google Leak, QualityNsrPQData signifie à peu près « Signaux de qualité / Données sur la qualité de page / Classement de site normalisé ».

Pour aboutir à cette signification approximative, il faut décomposer ainsi :

• Quality : des dizaines de modules comportent ce terme dans leur intitulé. A chaque fois, il est question d’évaluer la qualité par des séries de « signaux », et par signaux il faut comprendre des éléments objectifs et mesurables, des métriques.
• NSR : j’ai fait une analyse détaillée du concept, et suis à peu près sûr qu’il signifie « classement de site normalisé ». Contrairement à la compréhension intuitive du terme « rank », qu’on est tenté d’interpréter comme un concept ordinal de type « 1er ou 25è du classement », mon analyse du module PerDocData tend à démontrer qu’il s’agirait plutôt d’une typologie, une liste des types de site (blog, site de vidéo, site d’une autorité électorale, etc), chaque type étant probablement évalué différemment par Google.
• PQ : il s’agit clairement de « Page Quality », qualité de la page.
• Data : données.

Analyse des attributs du module QualityNsrPQData

Ce module de taille moyenne compte 19 attributs et comme on va le voir, plusieurs constituent des groupes cohérents.

Le module est appelé en tant qu’attribut pqDataProto du module CompressedQualitySignals.

chard (type: integer(), default: nil) – URL-level chard prediction (encoded as an int).

La « prédiction de chard au niveau url ».

Une hypothèse est que chard soit une mesure de la profondeur de la page dans l’arborescence du site.

chardScoreEncoded (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrVersionedIntSignal.t), default: nil) – URL-level Chard (encoded as an int).

Le « score de chard encodé ».

contentEffort (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrVersionedFloatSignal.t), default: nil) – LLM-based effort estimation for article pages (see landspeeder/4311817).

« Effort de contenu », et le commentaire indique : « Estimation de l’effort de pages articles, basée sur un LLM » (un modèle de langage, semblable à ChatGPT, Gemini etc).

En plus clair : quand une page consiste en un article (et pas en une vidéo, une image, ou un autre type de contenu), Google donne le contenu (pas toute la page : il retire probablement tout le contenu qui n’est pas propre à cette page, par exemple l’en-tête et le pied de page, la barre latérale si elle n’est pas contextuelle, etc), à évaluer à un modèle de langage, qui renvoie une estimation de l’effort.

Cette notion d’effort se retrouve ailleurs dans la doc de l’API Google :

• le module CompressedQualitySignals contient un attribut ugcDiscussionEffortScore

Quels sont les critères d’estimation de l’effort selon Google ? On l’ignore évidemment, mais on pourrait envisager :

• le niveau de formatage typographique : l’effort est plus élevé dans un texte qui contient des titres, du gras, de l’italique, que dans un texte plat
• le nombre et la taille des images
• la présence de tableaux HTML
• les listes à puces
• les autres éléments de webdesign : colonnes etc

Au final, à quoi pourrait servir une mesure de la quantité d’effort mise dans l’édition d’une page ? Probablement, à différencier les contenus :

• spammy (qualité nullissime, effort minimal, vite fait mal fait)
• amateur (qualité passable, faible diversité des éléments de webdesign)
• pro (bonne qualité, effort soutenu)
• et « premium », pour réutiliser un concept qu’emploie Google dans sa doc (excellente qualité, gros effort)

Bien entendu, une classification dans ce style servirait à faire passer d’abord les contenus d’excellente qualité ayant demandé beaucoup d’efforts, et inversement à priver de trafic les contenus nullissimes faits pour des raisons frauduleuses (pages générées en masse en juxtaposant des fragments de contenus pillés sur le web, par exemple).

deltaAutopilotScore (type: number(), default: nil) –
deltaLinkIncoming (type: number(), default: nil) –
deltaLinkOutgoing (type: number(), default: nil) –
deltaSubchunkAdjustment (type: number(), default: nil) – Total deltaNSR adjustment based on subchunks. This is a page-level adjustment (subchunks are retrieved based on the page classification).

Ces 4 attributs commencent par le terme « delta ». Ce terme est souvent utilisé en informatique – et à l’origine, en maths – pour représenter la différence. J’avais une valeur x, je la transforme, elle devient delta de x.

Par ailleurs, on remarque que par la suite, on trouve les mêmes attributs mais sans le terme delta.

Si cette interprétation de delta est correcte, on pourrait donc comprendre ces attributs ainsi :

• Google mesure un « score Autopilot », un nombre « lien entrant », un nombre « lien sortant », un nombre « ajustement de sous-morceau ».
• Il stocke ces mêmes données sous forme différentielle : la différence entre l’ancienne valeur et la nouvelle, ce qui lui permet de représenter l’évolution de la page ainsi évaluée.

On sait par ailleurs que Google stocke les 20 dernières versions indexées d’une même page.

De là, on peut faire l’hypothèse que ces valeurs delta servent à :

• booster ou déclasser dans Google les pages qui marchent mieux ou moins bien qu’avant
• détecter les fraudes et les changements anormaux, par exemple une page qui gagne beaucoup de backlinks d’un coup

keto (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrVersionedFloatSignal.t), default: nil) – Keto score.

Le terme Keto est difficile à traduire car il n’est pas un mot anglais standard. Il fait penser au mot grec Kétos, « monstre marin, baleine », qui a donné cétus en latin, racine du mot cétacé.

Une recherche dans la doc Google montre qu’il existe un module nommé QualityNsrKetoKetoVersionedData, qui contient que 3 attributs et cette description : « Data populated to NsrData and hence propagated to docjoins/ascorer/superroot/etc« , donc il s’agit de « données peuplées dans NsrData et propagées à docjoins/ascorer/superroot/etc ».

L’attribut siteScore est défini ainsi : « Site-level aggregated keto score« , score keto agrégé au niveau du site.

On trouve aussi mention de keto dans le module QualityNsrNsrData.

Je n’en sais pas plus.

linkIncoming (type: number(), default: nil) –
linkOutgoing (type: number(), default: nil) –

Littéralement, « lien entrant » et « lien sortant ».

A noter : le terme link, lien, est au singulier et pas au pluriel, on ne peut donc pas interpréter cette valeur comme un décompte du nombre de liens entrants (backlinks) et sortants.

numOffdomainAnchors (type: number(), default: nil) – The total number of offdomain anchors seen by the NSR pipeline for this page.

Littéralement, « Nombre d’ancres hors-domaine ». Commentaire : « Le nombre total d’ancres hors-domaine vues par le pipeline NSR (normalized site-rank) pour cette page« .

Je rappelle d’abord que l’ancre, ce sont les mots, ou l’image, sur lesquels on place un lien ; en d’autres termes, c’est le contenu d’une balise <a href= » »>ANCRE</a>

On peut envisager 2 interprétations :

• le nombre d’ancres différentes, par exemple si j’ai 10 liens vers ma page, que 5 ont l’ancre « QualityNsrPQData », 2 ont l’url de la page comme ancre, et les 3 autres ont chacune une url différente, alors cette valeur compte 5 ancres différentes
• ou, ça pourrait être le décompte brut des ancres, y compris les ancres répétées, donc 10 liens = 10 ancres ; mais dans ce cas, l’attribut devrait plutôt s’appeler numOffdomainLinks.

Je penche donc pour la première hypothèse.

A quoi peut servir cet attribut ? Peut-être, à mesurer la probabilité de spam des liens entrants. Un nombre anormalement faible d’ancres différentes évoquerait un netlinking non-naturel, utilisant la même ancre encore et encore.

page2vecLq (type: number(), default: nil) –

Je pense pouvoir décrypter cet attribut :

• page2vec, qui signifie page to vector, transformation de la page en vecteurs, désigne une technique d’analyse du sens nommée vectorisation sémantique
• LQ signifie je pense Low Quality

Donc, cet attribut mesurerait la faible qualité d’une page sémantiquement vectorisée.

Imaginons une page de charabia, ou une page qui paraphrase encore et encore les mêmes banalités : elles obtiendraient un page2vecLq élevé.

predictedDefaultNsr (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrVersionedFloatSignal.t), default: nil) – Predicted default NSR score computed in Goldmine via the NSR default predictor (go/default-nsr-predictor).

« NSR (classement de site normalisé) prédit par défaut ». Cet attribut renvoie au module QualityNsrVersionedFloatSignal qui ne contient que 3 attributs techniques.

Le commentaire indique : « Score NSR prédit par défaut calculé dans Goldmine via le prédicteur NSR par défaut« .

Je pense qu’il s’agit d’une détection du type de page selon la typologie NSR.

rhubarb (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrVersionedFloatSignal.t), default: nil) – Site-URL delta signals based quality score computed in Goldmine via the Rhubarb model (go/rhubarb-dd).

Cet attribut « rhubarbe » a le commentaire suivant : « Score de qualité basé sur les signaux delta d’url de site, calculé dans Goldmine via le modèle Rhubarbe« .

Ce modèle Rhubarbe pourrait être un LLM d’estimation ou de classification.

subchunkData (type: list(GoogleApi.ContentWarehouse.V1.Model.QualityNsrPQDataSubchunkData.t), default: nil) –

« Données de sous-partie ». Cet attribut renvoie au module QualityNsrPQDataSubchunkData, que l’intro du module décrit ainsi :

« Data used to compute delta_subchunk_adjustment. (I.e, the subchunks looked up, with their confidences and weights). This data is not propagated to ascorer. »

Traduction : « Données utilisées pour calculer le delta_subchunk_adjustment. (c’est-à-dire les sous-morceaux recherchés, avec leurs confiances et leurs poids). Ces données ne sont pas transmises à ascorer. »

A ce que j’ai compris, Ascorer est le système primaire de classement des contenus par Google, et doit son nom à l’ancien directeur de la recherche chez Google, Amit Singhal. Ascorer effectue un premier classement, que les « Twiddlers » viennent ensuite modifier en fonction des signaux utilisateur.

Le module QualityNsrPQDataSubchunkData contient les attributs suivants :

• confidence (type: number(), default: nil) – Confidence associated with the chunk.
• deltaNsr (type: number(), default: nil) – Subchunk delta in nsr.
• pageWeight (type: number(), default: nil) – Weight with which this document belong to this subchunk (greater than 0).
• type (type: String.t, default: nil) – Type of this chunk. Eg, ymyl_health, d2v, etc.

Cette dernière info est intéressante : un type de « morceau » nommé ymyl_health servirait à détecter qu’une partie de la page a un enjeu médical (et donc en fonction d’autres signaux, que Google peut ou pas l’utiliser comme Featured Snippet, par exemple).

tofu (type: number(), default: nil) – URL-level tofu prediction.

On a déjà rencontré ce curieux attribut tofu dans l’analyse du module QualityNsrNsrData :

« tofu (type: number(), default: nil) – Site-level tofu score: site quality predictor based on content. » « Score tofu au niveau du site : prédicteur de qualité de site, basé sur le contenu ».

Ici, il s’agit d’une « prédiction tofu au niveau de l’url« .

unversionedRhubarb (type: number(), default: nil) – The delta score of the URL-level quality predictor.

« Rhubarbe non-versionné ». « Le score delta du prédicteur de qualité niveau url« .

Le terme « versionné » fait référence à la pratique où on numérote les versions d’un document, d’un logiciel etc, par exemple Windows 10, Apple 15, WordPress 4.6.3, PHP 8.3 etc.

J’ignore pourquoi Google a besoin d’une version versionnée et non-versionnée de son attribut rhubarbe.

urlAutopilotScore (type: number(), default: nil) –

« Score d’autopilote d’url ». Impossible à décrypter en l’absence de commentaire.

vlq (type: number(), default: nil) – URL-level score of the VLQ model.

On a déjà rencontré cet attribut vlq dans le module QualityNsrNsrData. Je pense qu’il signifie Video Low Quality, faible qualité de vidéo.

Synthèse

C’est spéculatif, mais je dirais que ce module nous apprend plusieurs choses intéressantes :

• Avec les attributs delta, Google fait un suivi de l’évolution d’un contenu. Il faut se rappeler que certaines pages web existent depuis plus de 25 ans, avant même la naissance de Google, or le web a beaucoup changé pendant ce temps. Il semble logique que Google réévalue chaque contenu, dès lors qu’il détecte que ce contenu a changé.
• L’attribut contentEffort pourrait indiquer que la qualité éditoriale fait partie des facteurs de référencement.
• Deux attributs évaluent la médiocrité du texte ou de la vidéo (je pense que cela peut expliquer pourquoi du contenu généré par IA sans valeur ajoutée ne ranke pas)

Si vous avez des infos, des hypothèses à partager, discutons-en en commentaire !