Audit de compte

Repérez dans GA4 les renvois de connexion, de paiement et de réservation qui volent le crédit des conversions

Prouve, grace à des ventilations par source, événement et page de destination, si GA4 attribue des conversions à un domaine externe de connexion, de paiement ou de réservation lorsque les visiteurs en reviennent. Liste les domaines à ajouter aux renvois indésirables et le désordre dans les noms de sources payantes.

Quand l'utiliser

Lorsque les conversions de votre GA4 semblent attribuées à la mauvaise source et que vous soupçonnez que des visiteurs revenant d'un domaine externe de connexion, de paiement ou de réservation démarrent de nouvelles sessions.

Ce que vous obtenez

Un tableau des référents suspects avec leur part des événements clés, une norme de nettoyage pour les noms de sources payantes et les domaines exacts à ajouter aux références indésirables et à la mesure inter-domaines.

Modifie-t-il quelque chose dans mon compte ?

Non. L'assistant lit seulement vos données et vous fait un compte rendu.

Fonctionne avec

GA4

À compléter avant l'envoi

[GA4 property]

Certaines conversions de ma propriété GA4 [GA4 property] affichent peut-être une source erronée. Lorsqu'un visiteur quitte mon site pour un domaine externe (connexion Google, prestataire de paiement, système de réservation) puis revient, GA4 peut démarrer une nouvelle session et attribuer la conversion à ce domaine. Prouve si c'est bien le cas. Les services externes que j'utilise : [your payment, login, appointment or booking providers, or write "not sure"]. Il s'agit d'une analyse en lecture seule. 1. Confirme la propriété. Liste la propriété avec ga4_list_properties, les flux web et les identifiants de mesure avec ga4_list_data_streams, et les événements clés avec ga4_list_conversions. 2. Récupère les sources. Avec ga4_report, extrais les 28 derniers jours avec dimension=channel et dimension2=source_medium, puis isole les lignes du canal Referral. 3. Relie les événements clés aux sources. Avec ga4_report, utilise dimension=event et dimension2=source_medium pour voir de quelle source provient chaque événement clé. Sans dimension=event, la colonne des conversions correspond à la somme de tous les événements clés de la propriété : ne saute donc pas cette étape. 4. Examine les pages de destination. Avec ga4_report, utilise dimension=landing_page et dimension2=source_medium. Repère les sessions de renvoi qui atterrissent sur des pages telles qu'un retour de connexion (par exemple /auth/.../callback), une page de remerciement après paiement ou une page de confirmation de réservation. Règles pour identifier un renvoi suspect : 1. Les lignes de renvoi dont la source est un service de connexion (accounts.google.com, login.microsoftonline.com, appleid.apple.com et similaires), un prestataire de paiement ou un système de réservation. 2. Mon propre domaine ou mes sous-domaines qui apparaissent comme des renvois. 3. Les lignes de renvoi dont le nombre d'événements clés par session est supérieur à deux fois la moyenne du site. 4. Les sessions de renvoi dont la page de destination est une page de retour, de remerciement ou de confirmation. Présente le résultat comme suit : 1. Tableau des renvois suspects : source / support, canal, sessions, événements clés, page de destination la plus fréquente, raison du caractère suspect. 2. Le total des événements clés de ces lignes et leur part dans l'ensemble des événements clés. Les données GA4 seules ne révèlent pas la vraie source de ces conversions ; dis-le clairement et n'estime aucune redistribution. 3. Les lignes des canaux payants où une même plateforme apparait sous plusieurs noms (par exemple fb / paid, ig / paid, meta / paid, ou une source classée dans Paid Other), avec une proposition de standard utm_source et utm_medium pour les harmoniser. 4. À faire : les domaines à ajouter à la liste des renvois indésirables dans GA4 et, si nécessaire, les domaines à configurer pour la mesure inter-domaines. Aucun outil ne modifie ces paramètres ; je les saisirai moi-même dans Admin > Flux de données > flux web > Configurer les paramètres de la balise dans GA4, donc écris les domaines exactement. Précise que cette modification ne corrige pas les données passées et n'a d'effet que sur les sessions à venir.

1. Confirme la propriété. Liste la propriété avec ga4_list_properties, les flux web et les identifiants de mesure avec ga4_list_data_streams, et les événements clés avec ga4_list_conversions.
2. Récupère les sources. Avec ga4_report, extrais les 28 derniers jours avec dimension=channel et dimension2=source_medium, puis isole les lignes du canal Referral.
3. Relie les événements clés aux sources. Avec ga4_report, utilise dimension=event et dimension2=source_medium pour voir de quelle source provient chaque événement clé. Sans dimension=event, la colonne des conversions correspond à la somme de tous les événements clés de la propriété : ne saute donc pas cette étape.
4. Examine les pages de destination. Avec ga4_report, utilise dimension=landing_page et dimension2=source_medium. Repère les sessions de renvoi qui atterrissent sur des pages telles qu'un retour de connexion (par exemple /auth/.../callback), une page de remerciement après paiement ou une page de confirmation de réservation.

Règles pour identifier un renvoi suspect :
1. Les lignes de renvoi dont la source est un service de connexion (accounts.google.com, login.microsoftonline.com, appleid.apple.com et similaires), un prestataire de paiement ou un système de réservation.
2. Mon propre domaine ou mes sous-domaines qui apparaissent comme des renvois.
3. Les lignes de renvoi dont le nombre d'événements clés par session est supérieur à deux fois la moyenne du site.
4. Les sessions de renvoi dont la page de destination est une page de retour, de remerciement ou de confirmation.

Présente le résultat comme suit :
1. Tableau des renvois suspects : source / support, canal, sessions, événements clés, page de destination la plus fréquente, raison du caractère suspect.
2. Le total des événements clés de ces lignes et leur part dans l'ensemble des événements clés. Les données GA4 seules ne révèlent pas la vraie source de ces conversions ; dis-le clairement et n'estime aucune redistribution.
3. Les lignes des canaux payants où une même plateforme apparait sous plusieurs noms (par exemple fb / paid, ig / paid, meta / paid, ou une source classée dans Paid Other), avec une proposition de standard utm_source et utm_medium pour les harmoniser.
4. À faire : les domaines à ajouter à la liste des renvois indésirables dans GA4 et, si nécessaire, les domaines à configurer pour la mesure inter-domaines. Aucun outil ne modifie ces paramètres ; je les saisirai moi-même dans Admin > Flux de données > flux web > Configurer les paramètres de la balise dans GA4, donc écris les domaines exactement. Précise que cette modification ne corrige pas les données passées et n'a d'effet que sur les sessions à venir.

Ouvrir dans Claude Ouvrir dans ChatGPT En discuter sur le forum

Exemple de résultat

Un exemple du résultat de ce prompt. Sa structure provient de la sortie réelle des outils ; les chiffres et les noms sont fictifs.

Exemple de résultat (basé sur un compte fictif, pas sur des données client réelles)

Propriété : sampleclinic.com (G-XXXXXXX), événements clés : generate_lead, purchase.

Source / support	Canal	Sessions	Événements clés	Page de destination la plus fréquente	Pourquoi c'est suspect
accounts.google.com / referral	Referral	188	64	/auth/google/callback	Service de connexion, page de retour
pay.samplepos.com / referral	Referral	52	47	/order/complete	Prestataire de paiement, page de remerciement
booking.sampleclinic.com / referral	Referral	31	22	/booking/confirmed	Mon propre sous-domaine

Ces trois lignes concentrent 133 événements clés, soit 38 % de l'ensemble des événements clés de la propriété. La véritable source de ces conversions (publicités, organique, direct) ne peut pas être retrouvée après coup à partir des données GA4.

Pagaille dans les sources payantes : le trafic Meta est réparti en trois entrées, fb / paid, ig / paid et meta / paid ; la ligne an / paid atterrit dans Paid Other. Proposition : utiliser utm_source=meta, utm_medium=paid_social et déplacer le placement dans utm_content.

À saisir dans GA4
1. Référents indésirables : accounts.google.com, pay.samplepos.com
2. Mesure multidomaine : sampleclinic.com, booking.sampleclinic.com

Cette modification ne corrige pas les données passées, elle n'affecte que les sessions à partir de maintenant.

Recherches associées

ga4 mauvaise source auto-référencement références indésirables mesure inter-domaines référent passerelle de paiement référent connexion référent système de réservation attribution des conversions trafic référent ga4 nommage utm

Ces prompts donnent le meilleur résultat quand votre assistant IA est connecté à vos comptes avec Opus Growth.

Connecter vos comptes gratuitement

Autres prompts

Audit de compteLecture seule

Audit complet d'un compte Google Ads avec les trois corrections à faire en priorité

Passe en revue l'ensemble du compte en une seule fois, de la mesure et des enchères à la structure et aux pages de destination. Classe les constats par impact et désigne les trois premières corrections à faire, sans rien modifier.

Quand l'utiliserLorsque tu reprends un compte Google Ads ou que tu t'en méfies et que tu veux savoir ce qui cloche vraiment et par où commencer les corrections.

Réalise un audit complet de mon compte Google Ads [nom du compte]. Si le compte a moins de 90 jours, utilise tous les jours disponibles, sinon utilise les 90 derniers jours. Il s'agit d'une analyse en lecture seule, ne modifie rien.

Commence par account_snapshot pour obtenir le statut, le budget, la stratégie d'enchères, l'ancienneté et les résultats de chaque campagne depuis son lancement. Sépare les campagnes qui apportent des résultats de celles qui dépensent sans convertir. Passe ensuite en revue les points suivants, dans cet ordre :

1. Mesure. Liste les actions de conversion principales avec list_conversion_actions. Signale toute action principale qui n'a rien enregistré au cours des 30 derniers jours. Repère les configurations qui peuvent compter deux fois la même personne, par exemple un clic sur le téléphone et un clic sur WhatsApp sur le site configurés comme deux actions principales distinctes, ou la balise Google Ads et un événement GA4 importé tous deux définis comme principaux pour le même formulaire. Vérifie combien de clics ont été envoyés vers le bouton d'appel des annonces et si ces appels ont bien été enregistrés, avec google_ads_query sur call_view.
2. Enchères et budget. Utilise impression_share_analysis pour afficher, par campagne, la part d'impressions perdue à cause du budget et du classement. Utilise keyword_quality_report pour trouver les mots clés dont l'enchère est inférieure à celle de la première page ou qui sont rarement diffusés à cause d'un faible niveau de qualité. Pour les campagnes en enchères intelligentes, indique si les 30 derniers jours comptent suffisamment de conversions pour l'objectif utilisé.
3. Structure. Vérifie si les recherches de marque partagent une campagne avec les recherches génériques, si chaque groupe d'annonces envoie vers la page correspondant à son propre service, et si un même mot clé figure dans plusieurs groupes d'annonces.
4. Termes de recherche. Utilise search_terms_report pour distinguer les termes qui dépensent sans convertir, les marques concurrentes et les recherches informationnelles. Ne considère jamais comme du gaspillage un terme ayant au moins une conversion.
5. Annonces et assets. Examine la force des annonces, les assets refusés et vérifie que les liens annexes pointent vers la bonne page. Signale à part tout texte ou asset qui décrit un service que l'entreprise ne propose pas : [services non proposés, ou écrire « aucun »].
6. Pages de destination. Récupère les clics, le coût et le taux de conversion par page depuis landing_page_view avec google_ads_query. Sur les pages qui absorbent le plus de dépenses, vérifie qu'un bouton téléphone et un bouton WhatsApp existent, et contrôle la vitesse sur mobile avec core_web_vitals.
7. Zone géographique, horaires et appareils. Indique si l'option de ciblage géographique est réglée sur « Présence », quelle part des dépenses va en dehors de la zone ciblée, ainsi que les dépenses et les conversions en dehors de [heures d'ouverture].

Présente le résultat ainsi : d'abord un résumé de cinq phrases sur l'état du compte. Ensuite un tableau des constats classés par importance : problème, preuve, impact estimé, recommandation. Pour finir, les trois corrections à faire en priorité et pourquoi chacune passe en premier. Lorsque les données ne suffisent pas pour conclure, ne devine pas : indique ce qui manque.

Audit de compteLecture seule

Audit complet d'un compte Meta Ads avec les trois corrections à faire en premier

Passe en revue en une seule fois la mesure, les problèmes de diffusion, la phase d'apprentissage, le ciblage, les emplacements et la fatigue créative. Classe les constats par priorité et désigne les trois premières corrections, sans rien modifier.

Quand l'utiliserQuand les résultats de tes publicités Meta ont chuté ou stagnent et que tu veux savoir ce qui cloche dans le compte avant de modifier quoi que ce soit.

Audite mon compte publicitaire Meta [ad account] de bout en bout. Prends les 30 derniers jours comme période principale et les 30 jours précédents comme période de comparaison. Il s'agit d'une analyse en lecture seule : ne modifie rien.

Commence par account_snapshot pour la plateforme meta afin de récupérer le statut, le budget, l'objectif, l'ancienneté et les résultats de chaque campagne depuis son lancement. Meta n'a pas de compteur de conversions unique : utilise donc le résultat que chaque campagne optimise réellement (leads, conversations de messagerie démarrées, achats). Passe ensuite en revue les domaines suivants, dans cet ordre :

1. Mesure. Vérifie la date du dernier événement du pixel avec list_meta_pixels. Confirme que l'événement optimisé par chaque campagne est bien enregistré. Signale les configurations qui risquent de compter deux fois le même résultat, par exemple des leads collectés à la fois par le pixel et par un formulaire instantané.
2. Diffusion. Liste les ensembles de publicités refusés, bloqués en cours de validation, sans aucune publicité active ou qui dépensent moins de la moitié de leur budget. Indique pour chacun le motif communiqué par Meta.
3. Phase d'apprentissage. Repère les ensembles de publicités segmentés de façon si fine qu'ils ne peuvent pas atteindre 50 résultats par semaine. Utilise meta_change_history pour montrer les modifications des 14 derniers jours qui ont réinitialisé l'apprentissage.
4. Ciblage et audiences. Signale les ensembles de publicités qui ciblent la même audience et ceux dont la fréquence dépasse [maximum frequency].
5. Emplacements et appareils. Avec get_report, compare le coût par résultat par publisher_platform et par appareil à la moyenne du compte. Ne tire aucune conclusion sur des segments de moins de 20 résultats.
6. Créations. Considère qu'une publicité est fatiguée lorsque la fréquence augmente alors que le taux de clics baisse et que le coût par résultat grimpe. Décris brièvement l'angle commun aux publicités les plus performantes.
7. Destination. Vérifie que la page ou le lien WhatsApp vers lequel les publicités envoient les internautes fonctionne et correspond à l'objectif.

Présente le résultat ainsi : d'abord un résumé en cinq phrases de la situation du compte. Ensuite, un tableau des constats classés par importance : problème, preuve, impact estimé, recommandation. Enfin, les trois corrections à faire en premier, avec pour chacune la raison de sa priorité. Lorsque les données ne suffisent pas pour conclure, ne devine pas : indique ce qui manque.

Audit de compteModifie après votre accord

Fusionner les demandes par téléphone et WhatsApp en une seule conversion fiable

Évite qu'une même personne soit comptée deux fois lorsqu'elle appelle et envoie un message. Relie les deux boutons du site à une seule conversion et vérifie si le bouton d'appel des annonces est bien mesuré.

Quand l'utiliserLorsque des prospects vous appellent et vous écrivent sur WhatsApp depuis votre site et que vous soupçonnez qu'une même personne compte pour deux conversions, ce qui rend votre coût par conversion artificiellement bas.

Dans mon compte Google Ads [nom du compte], les prospects nous contactent via les boutons téléphone et WhatsApp du site. Si une même personne qui clique sur les deux boutons compte pour deux conversions, mon coût par conversion paraît plus bas qu'il ne l'est réellement et l'algorithme d'enchères apprend de travers. Corrige cela.

1. Cartographie la configuration actuelle. Liste les actions principales, leurs catégories et leurs types de comptage avec list_conversion_actions. Dans mon conteneur Tag Manager [ID du conteneur GTM], utilise list_gtm_tags pour montrer quelle balise déclenche quelle étiquette de conversion. Estime, chiffres à l'appui, à quelle fréquence un même clic sur une annonce a pu générer plus d'une conversion de contact au cours des 30 derniers jours.
2. Le bouton d'appel dans les annonces. Avec google_ads_query, vérifie combien de clics et quelle part des dépenses sont allés au bouton d'appel des annonces, et utilise call_view pour contrôler si ces appels ont bien été enregistrés. S'il y a des clics mais aucun enregistrement, dis-le clairement et propose deux options : supprimer l'extension d'appel, ou accepter ces clics comme du trafic non mesuré.
3. Présente le plan. Propose une seule action de conversion nommée "Clic contact (Téléphone + WhatsApp)" avec un comptage réglé sur une seule conversion. Relie-la à une seule balise qui se déclenche à la fois sur le déclencheur téléphone et sur le déclencheur WhatsApp. Passe les deux anciennes actions en secondaires. Indique si les campagnes en enchères intelligentes (Smart Bidding) nécessitent une révision de leur objectif, car le nombre de conversions va baisser.
4. Applique après mon accord. Crée l'action de conversion, règle le comptage sur une seule conversion, mets à jour la balise dans Tag Manager et montre-moi la liste des modifications avant publication. Après la publication, note quelle version peut être restaurée.

Termine par un court plan de test : comment vérifier en mode aperçu que seule la nouvelle balise se déclenche lorsque les deux boutons sont utilisés, et combien de jours il faut pour que la correction apparaisse dans les données réelles.

Audit de compteLecture seule

Lancer un audit SEO, AEO et GEO complet et obtenir un scorecard étayé par des preuves

Note l'accès, la santé technique, les données structurées, la citabilité du contenu, les signaux de confiance et la visibilité IA mesurée sur six domaines de cinq contrôles concrets chacun. Présente les preuves pour chaque point et classe les correctifs par impact et effort, sans rien modifier.

Quand l'utiliserQuand vous voulez savoir à quel point votre site est visible et fiable dans la recherche classique, les moteurs de réponses et la recherche IA, et qu'il vous faut une liste priorisée de ce qu'il faut corriger en premier.

Audite mon site [site URL] de bout en bout pour la recherche classique, les moteurs de réponse (AEO) et la recherche IA (GEO). Ma propriété Search Console : [Search Console property]. Concurrent principal : [competitor domain, or "none"]. Marché : [country], langue : [language code]. Les 3 recherches qui m'apportent le plus d'affaires : [3 commercial queries]. Mes gabarits de pages les plus importants : [homepage, one service page, one blog post URL]. Cet audit est en lecture seule.

Règle des crédits : avant de commencer, vérifie les exécutions précédentes avec seo_history et relance avec les mêmes arguments celles qui sont réutilisables. Montre-moi une seule fois la liste des nouveaux appels qui consommeront des crédits et attends mon accord.

Collecte des données :
1. Lance l'analyse groupée avec seo_full_analysis en indiquant le domaine, le concurrent, la localisation et la langue. Sa section de visibilité IA mesure le seul mot-clé sur lequel le site se classe le mieux, qui peut n'avoir aucun rapport avec mon activité ; n'utilise pas cette section pour la notation, mais mesure mes 3 requêtes commerciales avec seo_ai_overview et target=[domain]. Si references est vide, compte les domaines des liens présents dans ai_answer.
2. Lance seo_site_crawl avec max_pages proche du nombre de pages du site (au maximum [page limit]). Il renvoie un task_id ; rappelle-le avec le même task_id après 60 à 90 secondes et attends l'arrivée du résumé. Récupère la liste complète des URL d'un problème avec le paramètre issue si nécessaire. Si la limite du crawl ne couvre pas tout le site, indique que les résultats sont un échantillon.
3. Lis robots.txt, sitemap.xml et llms.txt avec site_read_url. Lis mes pages de gabarit avec text=true (si truncated vaut true, relance avec max_bytes=1000000) et avec outline=true. Pour le JSON-LD, lis les mêmes pages avec max_bytes=1000000 et extrais les blocs.
4. Mesure la page d'accueil et la page de service avec seo_audit et strategy='mobile'. Pour les Core Web Vitals, utilise les données réelles des utilisateurs (field) quand elles existent, sinon la valeur de laboratoire, et précise laquelle tu as utilisée.
5. Utilise get_report avec platform='search_console' et les ventilations « query by impressions » et « page by impressions » sur les 90 derniers jours. Inspecte avec gsc_inspect_urls les 10 pages qui ont le plus d'impressions. Récupère l'état du sitemap avec gsc_sitemaps.
6. Garde en tête que des outils différents peuvent voir des versions différentes d'une même page : si seo_technical_audit ou seo_site_crawl mesure un titre dans une autre langue que celui affiché par site_read_url, consigne-le comme un constat, car le site redirige peut-être les visiteurs selon leur pays.

Scorecard : six domaines, cinq contrôles chacun, chaque contrôle étant réussi (1) ou échoué (0). Si un contrôle n'a pas de données, écris « non mesuré » et retire-le du dénominateur ; ne note jamais en devinant.
1. Accès et exploration : robots.txt est ouvert aux robots IA de type recherche ; les pages clés renvoient 200 avec au plus une redirection ; aucun noindex sur les pages clés ; le sitemap ne contient pas d'erreurs et comprend les pages clés ; le contenu principal est visible sans JavaScript.
2. Santé technique et vitesse : LCP mobile inférieur à 2,5 secondes ; CLS inférieur à 0,1 ; INP inférieur à 200 ms ; aucune page cassée ni lien interne cassé dans le crawl ; aucun titre ni description en double.
3. Données structurées et entité : un nœud Organization ou LocalBusiness existe ; les nœuds sont reliés par @id ; le schéma correspond au type de page (Service, Article, Product) ; les faits du schéma concordent avec le texte visible ; les URL sameAs fonctionnent.
4. Citabilité du contenu : le premier paragraphe des pages clés répond directement à la question ; les titres nomment clairement le sujet ou la question ; les faits comparables sont dans un tableau ; une FAQ propre à la page existe ; il y a des chiffres et des dates concrets.
5. Signaux de confiance : la page à propos est concrète (qui, où, depuis quand) ; les coordonnées figurent sur le site et sont cohérentes ; les articles affichent un auteur ou un éditeur ; les dates de publication et de mise à jour sont visibles ; les pages légales sont accessibles depuis le pied de page par des liens statiques.
6. Visibilité IA mesurée : cité dans la réponse IA de Google pour au moins une des 3 requêtes commerciales ; cité pour la requête de marque ; llms.txt existe et est exact ; Search Console montre des clics issus de requêtes hors marque ; si le concurrent principal est cité sur ces requêtes, il existe au moins une requête où je le suis aussi.

Formate la sortie ainsi. D'abord une synthèse de direction en cinq phrases. Ensuite le tableau des scores : domaine, score (par ex. 3/5), contrôles échoués. Puis le tableau des preuves : domaine, contrôle, résultat, preuve (nom de l'outil et valeur renvoyée), URL concernées. Puis la liste des correctifs : pour chaque élément, l'impact (élevé, moyen, faible), l'effort (heures, jours, semaines) et qui s'en charge ; impact élevé et effort faible en premier. À la fin, les trois premiers correctifs et pourquoi ils passent en premier. Ne porte aucun jugement sur ce qui n'a pas été mesuré.