Le SEO à l'heure de l'IA
avec BigQuery et l'expérimentation
- GSC et GA4 réunis dans BigQuery : vision complète de la requête à la conversion.
- SEO priorisé en fonction de la valeur commerciale et optimisé par des tests A/B.
- Se concentrer sur les conversions plutôt que sur la simple visibilité - y compris avec les overviews de l'IA.
Conseils pratiques pour les débutants
Se lancer dans une requête relativement complexe comme celle-ci peut donner l'impression d'un grand saut, mais vous n'avez pas besoin d'être un expert SQL pour en tirer profit. Voici quelques conseils pour vous aider à démarrer :
Définissez d'abord vos variables : Les premières lignes de la requête définissent des variables pour vos dates de début et de fin (start_date, end_date) ainsi que vos chaînes de caractères de variantes d'expériences (variant_a, variant_b). Modifiez-les tout en haut du script pour les adapter à votre test spécifique. Ici, vous pouvez facilement adapter l'analyse. Il s'agit d'une méthode éprouvée qui rend la requête réutilisable et réduit le risque d'erreur.
Commencez simplement : N'essayez pas de comprendre chaque ligne de code à la fois. La requête est composée de plusieurs sous-requêtes (les clauses WITH). Chacune d'entre elles est une petite pièce du puzzle, facile à comprendre. Exécutez d'abord uniquement la partie gsc_data pour voir la sortie, puis la partie variant_data et ainsi de suite. Cette approche par étapes vous aidera à construire progressivement votre compréhension.
Concentrez-vous sur les liens : La partie la plus importante de l'ensemble du script est la manière dont les différentes parties sont reliées entre elles. Notez les instructions LEFT JOIN dans la section user_level_data. C'est crucial, car cela garantit que nous conservons tous nos utilisateurs de variantes, même ceux qui ne sont pas convertis. Un INNER JOIN supprimerait les utilisateurs sans achat, ce qui entraînerait un taux de conversion faussé. Le LEFT JOIN préserve le groupe test complet, ce qui est essentiel pour une analyse A/B test précise.
Lisez les commentaires : Les commentaires (marqués par -) dans la requête sont là pour vous aider. Ils expliquent ce que fait chaque section du code. Lisez-les attentivement, ils sont votre guide dans la logique du script.
Utiliser la sortie finale : La sortie finale du script est un tableau avec deux parties principales : query_level_results et overall_results. Le premier tableau vous montre comment chaque variante s'est comportée pour certaines recherches, et le second vous donne un résumé général. Vous y trouverez les réponses à vos questions clés : "Où est-ce que ça marche bien ?", "Où est-ce que ça marche mal ?" et "Où y a-t-il un potentiel inexploité ?".
Ce script est plus qu'un simple outil de création de rapports. C'est un cadre de base qui vous permet de passer de l'analyse à l'action en toute confiance. Il vous fournit les données précises dont vous avez besoin pour identifier les problèmes, formuler des hypothèses et les tester avec une rigueur scientifique.
Ventilation de la requête
Un script comme celui-ci peut sembler intimidant à première vue, mais il repose sur un principe simple : nous relions différentes tables d'informations à l'aide d'un ID utilisateur unique. L'ensemble de la requête est créé à l'aide d'une série d'expressions de table commune (CTE), c'est-à-dire les parties commençant par WITH. Pensez à chaque instruction WITH comme à une étape logique et autonome de notre traitement de données. C'est comme si vous construisiez avec des briques LEGO : vous créez d'abord quelques blocs simples et les assemblez à la fin pour former un modèle complet.
Regardons de plus près les différentes "briques" :
gsc_data : Il s'agit de notre point de départ. Nous demandons à BigQuery d'appeler notre tableau Search Console et de récupérer toutes les données pour une période donnée. Les impressions, les clics et les pages sont alors agrégés, ce qui nous permet d'obtenir une base pour notre performance organique.
variant_data : Ici, nous récupérons des données directement à partir de nos événements GA4. En particulier, nous recherchons l'événement défini par l'utilisateur qui consigne à quelle variante d'expérience (A ou B) un utilisateur a été exposé. Cela permet d'établir un lien important entre un utilisateur et l'expérience à laquelle il a participé.
organic_users : Cette partie de la requête identifie tous les utilisateurs qui sont arrivés sur notre site via une recherche organique Google. Elle nous aide à filtrer nos données afin de nous assurer que nous n'analysons que les utilisateurs pertinents pour notre expérience liée au référencement.
user_purchases & user_add_to_cart : Nous obtenons ici les données de conversion (remarque : l'exemple utilise des KPI de commerce électronique, mais ceux-ci peuvent très bien être remplacés par des conversions lead-gen). Nous demandons à BigQuery de trouver tous les événements d'achat et d'add_to_cart et de les associer à nos utilisateurs. Nous ne considérons pas seulement le nombre de conversions, mais aussi d'autres indicateurs précieux comme le chiffre d'affaires total.
Lorsque nous arrivons aux sections user_level_data et query_level_results, nous avons déjà fait tout le gros du travail. Le script fusionne ensuite tous ces petits ensembles de données à l'aide de l'unique user_pseudo_id et agrège finalement toutes les données pour fournir une sortie claire et facile à lire. C'est la logique de base qui transforme vos données isolées en un modèle unifié, de sorte que vous puissiez répondre à des questions telles que : "Le nouveau contenu de la page a-t-il augmenté les conversions mobiles pour les mots-clés de longue traîne à haute fréquence ?"
Des questions sur le script ?
L'auteur, Bas Linders, se réjouit d'un échange et se tient à disposition pour toute question ou suggestion d'amélioration.