Panneaux d’avertissement de Google Analytics – Builtvisible

Panneaux d’avertissement de Google Analytics – Builtvisible

[ad_1]

1. Suivi de campagne interrompu

Vous êtes peut-être déjà en train de rechercher un suivi de campagne incorrect en surveillant le volume de trafic attribué à (Autre). Mais il y a un autre problème qui n’est souvent pas surveillé: un suivi de campagne interrompu causé par des URL mal formées.

Cela se produit souvent lorsque les spécialistes du marketing appliquent des paramètres de suivi à des URL qui contiennent déjà des paramètres de requête, tels que des PLP filtrés, ou lorsqu’une autre plate-forme ajoute ses propres ID.

Dans l’exemple ci-dessous, je partage un lien vers tous nos articles de blog relatifs aux données – pouvez-vous repérer le problème?

https://builtvisible.com/?s=data&post_type=post?utm_medium=email&utm_source=newsletter&utm_campaign=2021-jan

C’est vrai – j’ai commis l’erreur courante d’ajouter un point d’interrogation au suivi de la campagne. Bien que ce soit généralement ainsi, il ne peut y avoir qu’un seul point d’interrogation dans une URL et tout ce qui se trouve après le second sera perdu!

Au lieu de cela, j’aurais dû utiliser une esperluette. Comme ça:

https://builtvisible.com/?s=data&post_type=post&utm_medium=email&utm_source=newsletter&utm_campaign=2021-jan

Alors, comment repérez-vous si cela affecte vos données? Simple, affichez votre rapport Pages et filtrez pour « utm_ ». Étant donné que Google Analytics supprime tous les paramètres UTM qu’il trouve, tout ce qui est renvoyé indique un problème.

2. Fragmentation de la page

Un autre problème courant est la fragmentation des pages, j’entends par là les cas où les données d’une seule page sont réparties sur plusieurs lignes dans les rapports Google Analytics.

La cause la plus courante de fragmentation de page est les paramètres de requête dans l’URL. Ceci est souvent négligé car il n’y a techniquement rien de mal ici – c’est vraiment inutile pour l’analyse.

En règle générale, vous souhaitez supprimer tous les paramètres de requête de vos données de page qui n’affectent pas de manière significative le contenu de la page ou l’expérience utilisateur. Par exemple, je souhaite conserver les paramètres de pagination mais pas les identifiants marketing.

Pour déterminer si cela affecte vos données, il vous suffit de filtrer le rapport Pages sur « ? » et voyez quelle proportion de vos pages vues est affectée. Vous devrez ensuite examiner chacun des paramètres pour déterminer s’il affecte réellement suffisamment le contenu de la page pour constituer une nouvelle page.

Comme il y a probablement de nombreuses instances du même paramètre – je vois régulièrement des murs de fbclid, par exemple – il peut être utile de faire apparaître le résultat dans un script pour trouver les clés uniques.

Vous trouverez ci-dessous un exemple utilisant un bloc-notes Python qui renvoie une liste de paramètres de requête uniques avec un exemple de valeur pour chacun.

import pandas as pd
from urllib.parse import urlparse

data = pd.read_csv('location/of/data.csv')

keys = []
values = []

for index, row in data.iterrows():
    queries = urlparse(str(row['Page'])).query.split('&')
    for query in queries:
        q = query.split('=')
        if q[0] != '' and q[0] not in keys:
            keys.append(q[0])
            values.append(q[1])

unique_queries = pd.DataFrame({'keys': keys, 'values': values})

unique_queries.to_csv('location/to/save/file.csv')

unique_queries.head()

Le tableau devrait ressembler à ceci:

clés valeurs
0 p 34689
1 preview_id 34689
2 preview_nonce e4dbb1c5b5
3 Aperçu vrai
4 fbclid iwar1pkudrh5sho0neahchnojfacu5hee4p6qce37vrady…

3. Référents de paiement

Pour un site de commerce électronique, il est fort probable que vos utilisateurs passent par un tiers pour l’authentification de paiement – soit à partir de leur émetteur de carte, soit d’un service de paiement, tel que Paypal. Si cela vous semble familier, je vous recommande de consulter votre rapport de parrainage si vous ne l’avez pas déjà fait.

Lorsque Google Analytics détecte un changement de source, il démarre automatiquement une nouvelle session, toutes les données suivant le changement étant attribuées à cette nouvelle source. Dans le cas de la vérification des paiements, le risque est que de nombreuses transactions soient incorrectement attribuées au domaine de paiement en tant que référent, plutôt qu’à vos efforts de marketing.

Pour identifier s’il s’agit d’un problème, je vous recommande de filtrer le rapport des référents pour certaines chaînes de paiement courantes:

  • Payer – Assez explicite, mais nous recherchons des services tels que Paypal. Google Pay et Apple Pay.
  • 3ds et acs – 3D Secure et ActiveAccess (ACS) sont des normes de vérification utilisées par les émetteurs de cartes et apparaissent régulièrement dans les domaines des points de terminaison de paiement, par exemple 3ds.bank.com.
  • visage – Arcot Systems propose des solutions de vérification à de nombreux émetteurs de cartes; leurs points de terminaison ressemblent souvent à bank.arcot.com ou secure2.arcot.com.

Si vous obtenez une bonne partie des résultats, il vaut la peine de parcourir les données plus en détail et d’ajouter tous les domaines de paiement à la liste d’exclusion de parrainage.

Pour les sites mondiaux, cela peut rapidement devenir un jeu de whack-a-mole, vous pouvez donc envisager de supprimer toutes les données de référence pour la page de confirmation en modifiant votre marquage – les utilisateurs ne devraient en aucun cas entrer ici.

4. Transactions en double

Cela semble évident, mais les problèmes les plus courants que je trouve lors de l’audit d’une mise en œuvre de commerce électronique sont toujours les transactions en double.

Par défaut, Google Analytics dédupliquera la transaction par ID de transaction, mais uniquement pour les enregistrements en double collectés au cours de la même session. Cela signifie que si l’utilisateur retourne à la page de confirmation après l’expiration de la session et que le paquet de données est renvoyé, un duplicata sera enregistré. Il y a aussi quelques nuances avec les rapports personnalisés que je n’entrerai pas ici.

Bien que vous puissiez utiliser des techniques de stockage local pour réduire cela, vous devrez effectuer des développements pour l’arrêter complètement, surtout maintenant que le stockage local est susceptible d’expirer sur les appareils Apple. Donc, vous allez avoir besoin de données pour créer un cas clair pour que cela soit priorisé.

Heureusement, c’est la plus simple des vérifications dont nous avons discuté jusqu’à présent. Vous avez juste besoin d’un rapport personnalisé affichant les transactions par ID de transaction, triées par transactions dans l’ordre décroissant.

Comme astuce supplémentaire, choisissez la plage de dates la plus large possible sans toucher à l’échantillonnage, une année serait idéale, car il est possible que la visite de retour puisse avoir lieu des mois plus tard. Si vous avez beaucoup de données, vous devrez peut-être exporter des plages de dates plus petites et les assembler dans une feuille de calcul.


Vérifier l’exactitude d’un nouvel ensemble de données est une partie importante du travail d’un analyste. Mais cela peut être délicat lorsque vous n’avez pas accès à la table de données brutes, comme avec Google Analytics.

En suivant les simples vérifications décrites ci-dessus, vous serez en mesure de repérer certaines des erreurs les plus courantes qui continuent de nuire aux comptes Google Analytics et, plus important encore, de les corriger.

Si vous avez trouvé de nombreux problèmes et souhaitez un audit plus approfondi, ou avez besoin d’un coup de main pour les résoudre, nos consultants en données sont à votre disposition.

[ad_2]

Les commentaires sont clos.