Pic de trafic direct dans GA4 : 15 causes et comment le reduire
Le trafic direct dans GA4 est souvent du trafic mal attribue. Voici les 15 causes techniques et les solutions pour reduire ce bucket.
Le trafic direct n’est pas ce que vous croyez
Dans GA4, le canal Direct est un bucket par defaut. Quand GA4 ne parvient pas a determiner la source d’une session, il la classe en Direct. Le raccourci mental “trafic direct = utilisateurs qui tapent l’URL” est dangereusement reducteur. En realite, le trafic direct contient souvent une proportion importante de trafic mal attribue provenant d’autres canaux.
Si votre trafic direct depasse 25 a 30% du trafic total, c’est un signal d’alarme. Quelque chose dans votre infrastructure technique perd des referrers ou des parametres UTM en route. Voici les quinze causes les plus frequentes.
Causes liees a l’infrastructure technique
La premiere cause est l’absence de HTTPS. Quand un utilisateur passe d’un site HTTPS vers un site HTTP, le navigateur supprime le referrer par politique de securite. Si votre site est encore en HTTP, tout le trafic provenant de sites HTTPS apparait comme Direct. La solution est evidente : HTTPS partout, sans exception.
La deuxieme cause concerne les redirections JavaScript. Une redirection via window.location ou meta refresh ne preserve pas toujours le referrer, contrairement a une redirection 301 cote serveur. Auditez toutes vos redirections et remplacez les redirections client-side par des 301 server-side.
La troisieme cause est le stripping d’UTM par le cache. Certains CDN ou systemes de cache suppriment les parametres de query string pour ameliorer le taux de cache. Vos parametres utm_source, utm_medium et utm_campaign disparaissent avant que le script GA4 ne les lise. Verifiez la configuration de votre CDN et excluez les parametres UTM du cache key.
La quatrieme cause est le cross-domain mal configure. Si un utilisateur navigue entre deux domaines que vous gerez sans configuration cross-domain dans GA4, la session est coupee et la deuxieme partie atterrit en Direct. Un audit tracking revele systematiquement ce type de probleme.
Causes liees au comportement utilisateur
La cinquieme cause est le dark social. Les liens partages via WhatsApp, Slack, Messenger, email ou SMS n’incluent generalement aucun referrer. C’est un volume considerable : certaines etudes estiment que le dark social represente jusqu’a 80% des partages en ligne. La solution partielle est d’ajouter des UTM sur tous les liens que vous partagez activement.
La sixieme cause est l’autocompletion du navigateur. Quand un utilisateur commence a taper une URL et que le navigateur complete automatiquement, c’est classe en Direct. Ce trafic represente en realite le fruit de vos investissements marketing passes : ces utilisateurs ont decouvert votre site via une autre source, mais ils reviennent par habitude.
La septieme cause concerne les applications mobiles. De nombreuses applications (lecteurs RSS, applications bancaires, QR code scanners) ouvrent les liens dans un webview interne qui ne transmet aucun referrer.
Causes liees aux navigateurs et a la vie privee
La huitieme cause est Safari ITP. Intelligent Tracking Prevention limite la duree de vie des cookies first-party a 7 jours (et 24 heures pour les cookies ecrits par JavaScript). Un utilisateur Safari qui revient apres 8 jours est traite comme un nouvel utilisateur sans source connue. Le trafic tombe en Direct.
La neuvieme cause concerne les navigateurs en mode prive (Incognito, Navigation privee). Aucun cookie n’est conserve entre les sessions, donc chaque visite est sans contexte d’attribution.
La dixieme cause est la politique Referrer-Policy. Les sites modernes utilisent de plus en plus strict-origin-when-cross-origin ou no-referrer comme politique par defaut, ce qui supprime les informations de referrer detaillees. Le probleme recemment documente du stripping du gclid par Safari aggrave encore cette situation.
Causes liees au tracking
Les causes onze a quinze sont plus techniques. Les iframes sans configuration adequate perdent le referrer. Les redirections de vanity URLs (bit.ly, yourls) sans UTM cassent l’attribution. Les erreurs dans les click identifiers produisent des sessions orphelines. Les pages AMP ou les pages en cache Google transmettent un referrer Google qui peut etre mal interprete. Et enfin, le Consent Mode en mode Advanced genere des pings modelises qui, par nature, n’ont pas de source verifiable.
Comment reduire concretement le trafic direct
La priorite est de distinguer le trafic direct legitime du trafic mal attribue. Commencez par analyser les pages de destination du trafic direct. Si des landing pages de campagne apparaissent en Direct, c’est un signe clair de perte d’UTM quelque part dans la chaine.
Ensuite, mettez en place un tracking server-side qui prolonge la duree de vie des cookies first-party au-dela des limitations ITP. Ajoutez des UTM systematiques sur tous les liens que vous controlez. Et surtout, ne minimisez pas ce probleme : chaque session en Direct est une session dont vous ne connaissez pas la valeur marketing.