Statistiques de visiteurs et de recherche

Vue d’ensemble — à quoi cela sert

Deux icônes se trouvent à côté du nombre de visiteurs uniques sur chaque carte de Service ▸ Web, et chacune ouvre une fenêtre modale.

Là où les informations d’accès nginx_meta_ct de la carte vous disent ce que votre serveur a reçu, ces deux fenêtres vous disent d’où venaient les visiteurs et quels termes de recherche les ont amenés — des informations que vos journaux de serveur ne contiennent tout simplement pas.

Ce que fait Site Kit sous WordPress revient au fond à construire les requêtes de rapport à votre place. Sous Laravel, vous les construisez vous-même et obtenez des chiffres identiques : nous n’utilisons donc ni extension ni google/apiclient — tout le travail consiste à « signer un JWT avec la clé privée, puis l’échanger contre un jeton d’accès », et le serveur le signe nativement. Traîner un vaste arbre de dépendances pour atteindre deux points de terminaison REST est un mauvais calcul.

Quand l’utiliser

• Le trafic a augmenté sur une carte et vous voulez savoir quel canal et quelle source l’ont produit.
• Vous voulez les mots-clés de recherche qui génèrent impressions et clics, et sur quelle page chacun d’eux atterrit.
• Vous voulez voir d’un coup d’œil la composition de l’audience : part de nouveaux visiteurs, répartition par appareil, origine du trafic.
• Vous suivez les impressions, les clics et la position moyenne après la publication d’un contenu.

Disposition

Les deux fenêtres se répartissent en onglets Aperçu / Mots-clés / Trafic (l’onglet Mots-clés n’existe que dans la fenêtre de recherche) : on change d’onglet plutôt que de faire défiler. Le sélecteur de période propose 7 / 28 / 90 jours — exactement l’ensemble autorisé côté serveur.

Analyse des visiteurs (GA4)

• Six KPI : visiteurs, nouveaux visiteurs, sessions, pages vues, taux d’engagement, session moyenne — chacun accompagné de son évolution par rapport à la période immédiatement précédente.
• Trois bandeaux de composition : fidélité des visiteurs (nouveaux/fidèles), répartition par appareil (ordinateur contre mobile et tablette), origine du trafic (recherche contre autre). Les trois sont des partages en deux, ils partagent donc un même langage visuel, et comme les KPI portent déjà les chiffres absolus, ceux-ci n’indiquent que la proportion.
• Graphique d’évolution : visiteurs, sessions et pages vues.
• Six panneaux (onglet Trafic) : canaux, sources, villes, pays, appareils, pages les plus vues.

Canal et source ne sont pas la même chose. Le canal est la réponse regroupée (Organic Search) ; la source est la réponse concrète (google, naver, github.com). Pour les sites coréens en particulier, naver ou google, ce sont deux histoires d’acquisition entièrement différentes.

Trafic de recherche (Search Console)

• Cinq KPI : clics, impressions, CTR, position moyenne, nombre de mots-clés.
• Nuage de mots : la taille et la couleur codent les impressions, un ● signale les mots-clés ayant produit de vrais clics, et les chiffres sont les impressions ~1d / ~7d / all.
• Tableau des mots-clés : clics, impressions, CTR, position.
• Page d’entrée × requête : dépliez une page pour voir les mots-clés par lesquels on y est entré.
• Trois panneaux : pages d’entrée, pays, appareils.

La position moyenne est pondérée par les impressions. Une simple moyenne laisse une impression en position 1 compenser dix mille impressions en position 40, ce qui flatte gravement le chiffre.

Comment le configurer

1. Créer un compte de service (Google Cloud)

1. Google Cloud Console → choisissez ou créez un projet → IAM et administration ▸ Comptes de service → Créer un compte de service. Aucun rôle au niveau du projet n’est requis.
2. Ouvrez le compte → Clés → Ajouter une clé ▸ Créer une clé ▸ JSON → téléchargez le fichier.
3. Sous API et services ▸ Bibliothèque, activez Google Analytics Data API et Google Search Console API.

2. L’enregistrer dans InfraGuard

Dans Service ▸ Web ▸ Gérer les sites web ▸ onglet d’édition du site, sous Intégration Google :

L’ID de propriété GA4 n’est pas l’ID de compte. Dans #/a405285491p550688232/, la partie après a est le compte et la partie après p est la propriété. Google ne distingue délibérément pas « propriété inexistante » de « pas d’autorisation » (l’existence même d’une propriété est une information) : un mauvais numéro ressemble donc exactement à un problème de droits. Vérifiez d’abord l’ID de propriété.

Ne déduisez jamais la propriété Search Console du domaine. Seule la personne qui a fait la validation sait s’il s’agit d’une propriété de domaine (sc-domain:) ou d’un préfixe d’URL (https://…/), et un mauvais choix renvoie un résultat vide plutôt qu’une erreur.

3. Inviter le compte de service sur chaque propriété

Le JSON n’est qu’une identité ; l’accès est accordé propriété par propriété. Copiez le client_email affiché après l’enregistrement, puis :

Dans GA4, il s’agit de la gestion de l’accès à la propriété, et non de la gestion de l’accès au compte (la colonne de gauche est le compte, celle du milieu la propriété). Dans Search Console, il faut Complet et non Restreint — la Search Analytics API refuse les utilisateurs restreints. Les comptes de service n’ont pas de boîte de réception : décochez donc la case « notifier par e-mail ».

4. Tester la connexion

[Tester la connexion], dans la fenêtre de gestion, interroge une fois chaque API (7 derniers jours) avec l’identifiant enregistré et rend compte de chaque partie séparément.

Sans aucun identifiant, rien n’est appelé (zéro requête sortante). Les modifications non enregistrées ne sont pas testées — enregistrez d’abord.

Règles d’exactitude — pourquoi les chiffres sont construits ainsi

Elles suivent les pièges que Site Kit a déjà mis en évidence, tous étayés par des faits.

Sources de données

Services : Services\Google\{GoogleTokenService, GoogleReportService, SiteInsightService} ; points de terminaison Service\WebController@insight{Visitors,Search,Test}.

Mise en cache : les réponses des rapports sont mises en cache, et la clé de cache inclut l’identité qui agit (client_email). La même URL et le même corps demandés sous un autre compte constituent une autre autorisation : partager une clé reviendrait à livrer à un site la réponse mise en cache d’un autre.

Pourquoi les identifiants sont par site

Une unique clé globale dans .env ne peut pas fonctionner ici. Les sites enregistrés appartiennent à des propriétaires différents, donc à des comptes Google différents, et un compte de service ne lit que les propriétés sur lesquelles il a été invité — dès que les sites de deux clients sont enregistrés, l’un au moins échoue systématiquement. D’où le champ à coller site par site.

• Stocké avec Crypt (APP_KEY) et en écriture seule : le modèle masque le texte chiffré, si bien que l’interface ne voit jamais qu’un booléen et le client_email, qui n’est pas secret. La clé privée ne ressort pas.
• L’enregistrement effectue trois vérifications : le JSON s’analyse, client_email/private_key sont présents, et un contrôle de clé de signature accepte la clé. Les copier-coller tronqués sont fréquents, et en laisser passer un se manifeste plus tard par un faux « autorisation refusée » qui vous envoie fouiller l’IAM de Google.
• Un identifiant valable pour tout le serveur subsiste comme solution de repli pour les déploiements à compte unique ; l’identifiant propre à un site l’emporte toujours.

Le champ d’identifiant n’est transmis que si vous y touchez. Le formulaire ne reçoit jamais la clé privée en retour : traiter « absent » comme « effacer » supprimerait donc l’identifiant chaque fois que quelqu’un ne modifie que la remarque. Le vider explicitement est le seul moyen de le supprimer.

Autorisations

• Lecture : tout utilisateur connecté (infr.auth, niveau ≥ 1). L’écran ne fait que lire des statistiques externes et ne change rien, ni dans InfraGuard ni chez Google : il n’y a donc ni ré-authentification ni entrée d’audit (la même discipline que la consultation de réputation d’IP).
• Enregistrement des identifiants/propriétés : user_level >= 2 (comme l’enregistrement d’un site web), consigné dans infr_audit_log.

La cible est désignée uniquement par l’id du site enregistré — un ID de propriété ne peut pas être passé en paramètre. Si l’appelant pouvait nommer une propriété, les autorisations de notre compte de service deviendraient un moyen de lire les propriétés GA4/Search Console d’autrui (la même discipline anti-SSRF que les tests en direct du Catalogue). La période est de même restreinte côté serveur à 7/28/90.

Dépannage · FAQ

• Aucune icône sur la carte — un site a besoin à la fois d’un identifiant et d’une association de propriété pour que les boutons apparaissent. Le contrôle est fait par site : un site doté de son propre identifiant fonctionne donc même si le .env global est vide. Enregistrez, puis rechargez.
• Tous les contrôles sont au vert et pourtant le résultat est 0 — c’est un problème de collecte, pas de requête. ① La fenêtre se termine hier : une balise installée aujourd’hui est encore en dehors. ② Vérifiez que l’ID de mesure (G-…) réellement servi par le site appartient bien à la propriété interrogée (Administration GA4 ▸ Flux de données) ; si les données atterrissent dans une autre propriété, vous lirez zéro indéfiniment. ③ Search Console accuse environ 2 jours de retard, et un site récent peut n’avoir encore aucune impression.
• User does not have sufficient permissions — soit l’étape 3 (l’invitation du compte) manque, soit l’ID de propriété GA4 est faux. Les deux produisent exactement la même formulation : vérifiez d’abord l’ID de propriété.
• Seul Search Console revient vide — la chaîne de propriété ne correspond très probablement pas à la réalité (sc-domain: ou https://…/). L’échec prend la forme d’un résultat vide et non d’une erreur : comparez-la au sélecteur de propriétés.
• L’identifiant a disparu après l’enregistrement — enregistrer avec le champ vidé constitue une suppression explicite. Le laisser intact le préserve.
• La fenêtre affiche un badge Sample — aucune donnée n’a encore été collectée : un échantillon illustratif est affiché pour juger de la mise en page. Le passage aux données réelles est automatique dès leur arrivée.

Voir aussi

• Service ▸ Web — l’écran de supervision web lui-même (cartes, disponibilité, certificats)
• Page d’accueil publique et analyse des visiteurs — le côté collecte (gtag/GTM, validation Search Console)
• Consultation de réputation d’IP — le même modèle d’autorisation pour une consultation externe en lecture seule