Pourquoi le trafic direct est le fourre-tout de tout ce que l'analytics n'a pas pu attribuer

Qu'est-ce que le trafic direct ?

Les outils d'analytics classent une session en trafic direct quand la requête arrive sans referrer et sans paramètre de campagne, ce qui fait de l'étiquette le constat d'une donnée d'attribution manquante, et non le constat que des gens tapent votre URL dans la barre d'adresse. Google Analytics 4 énonce la règle dans ses définitions de groupes de canaux par défaut : une session est Direct quand "Source exactly matches '(direct)' AND Medium is one of ('(not set)', '(none)')". Lisez le chiffre comme une lacune de mesure et cherchez laquelle des causes ci-dessous la remplit.

Pourquoi le direct n'est-il pas un canal ?

Le direct n'est pas un canal, c'est le fourre-tout de tout ce que l'outil n'a pas pu attribuer. Tous les autres canaux sont définis par une preuve que la requête portait, un nom d'hôte référent ou une valeur utm_medium, tandis que le Direct est défini par l'absence de cette preuve, et une absence n'a aucun comportement marketing attaché. Traitez une ligne Direct qui monte comme une alerte d'instrumentation et auditez les liens sur lesquels les gens cliquent réellement, de la même façon que vous auditeriez le trafic que GA4 n'enregistre jamais.

GA4 pousse la distinction un cran plus loin. Son bucket Unassigned est "la valeur qu'Analytics utilise quand aucune autre règle de canal ne correspond aux données de l'événement", donc une session qui porte une source mais ne correspond à aucune règle part en Unassigned, tandis qu'une session qui ne porte rien du tout part en Direct.

Qu'est-ce qui atterrit réellement dans le fourre-tout direct ?

Sept mécanismes retirent le referrer ou le tag de campagne avant que votre script tourne, et chacun produit une session impossible à distinguer d'un clic sur un favori. Le navigateur en décide la plupart, donc aucune configuration de tag ne récupère la source.

Cause	Ce qui atteint votre serveur	Pourquoi
Une page HTTPS pointe vers une page HTTP	Aucun en-tête Referer	L'algorithme W3C Referrer Policy ne renvoie aucun referrer sur un passage de sécurisé à non sécurisé
Le site référent envoie Referrer-Policy: no-referrer	Aucun en-tête Referer	MDN : "L'en-tête Referer sera omis : les requêtes envoyées ne comportent aucune information de referrer"
Le lien porte rel="noreferrer"	Aucun en-tête Referer	MDN : le mot-clé demande au navigateur "d'omettre l'en-tête Referer et de ne divulguer par ailleurs aucune information de referrer"
Une application native ou une messagerie ouvre le lien	Aucun en-tête Referer	Le tap ne vient pas d'un document HTML, donc il n'y a aucune adresse référente que le client puisse envoyer
Un lien dans un PDF ou un document Office	Aucun en-tête Referer	Le lecteur passe l'URL au navigateur comme une navigation neuve, pas comme un saut de document à document
Une chaîne de redirections qui passe par un saut HTTP ou un service no-referrer	Referrer perdu à ce saut	La spécification Referrer Policy réinitialise la politique de referrer de la requête à chaque réponse de redirection, donc un seul saut peut la supprimer pour tout le reste de la chaîne
Un lien d'e-mail non tagué ou un scan de QR code	Aucun referrer, aucun UTM	Le client mail ou l'application appareil photo ouvre l'URL sans rien attaché, et vous n'avez ajouté aucun paramètre de campagne

Comment les referrer policies suppriment-elles le referrer ?

Une referrer policy est une règle par requête qui décide quelle part de l'URL référente le navigateur met dans l'en-tête Referer. La spécification W3C Referrer Policy fixe strict-origin-when-cross-origin comme politique de referrer par défaut : elle envoie l'origine, le chemin et la chaîne de requête sur les requêtes de même origine, l'origine seule sur les requêtes cross-origin HTTPS vers HTTPS, et rien du tout sur un passage HTTPS vers HTTP. Sous no-referrer l'en-tête n'apparaît jamais, et sous origin vous recevez https://example.com/ sans chemin, assez pour nommer le canal mais pas la page.

La règle du passage à HTTP surprend les équipes. L'algorithme de la spécification ne renvoie aucun referrer "si referrerURL est une URL potentiellement digne de confiance et que l'URL courante de la requête ne l'est pas", donc une seule URL non HTTPS quelque part dans votre entonnoir convertit du vrai trafic de referral en direct. Corrigez-le en servant chaque saut en HTTPS, puis lisez ce que les politiques de referrer des navigateurs font à l'analytics avant d'accuser l'outil.

Pourquoi les apps, les PDF et les QR codes arrivent-ils en direct ?

Les applications natives, les lecteurs de documents et les applications appareil photo arrivent en direct parce que l'en-tête Referer décrit une navigation de document à document et qu'aucun d'eux ne part d'un document. MDN définit l'en-tête comme contenant "l'adresse absolue ou partielle depuis laquelle une ressource a été demandée", et un message Slack, un PDF de tarifs et un QR code imprimé n'ont aucune adresse de ce genre à rapporter. Le remède est de mettre vous-même la source dans l'URL.

C'est à cela que servent les paramètres de campagne. Ajoutez utm_source et utm_medium au lien avant qu'il parte dans le deck, le PDF, la newsletter ou le générateur de QR, et la session arrive étiquetée même si le referrer a disparu. Flowsery lit ces paramètres dans son suivi de campagnes UTM, et le guide complet des paramètres couvre les règles de nommage qui gardent les étiquettes lisibles dans une équipe.

Comment calculer la part de trafic direct ?

La part de trafic direct est le nombre de sessions directes divisé par le nombre total de sessions sur la même période, exprimé en pourcentage. Utilisez-la comme mesure avant et après sur un projet de tagging, pas comme référence face à d'autres sites, parce que le chiffre bouge avec votre mix de canaux et avec les navigateurs de vos visiteurs.

direct traffic share = (direct sessions / total sessions) x 100

Un site enregistre 42,000 sessions dans un mois et 9,660 d'entre elles sont directes. 9,660 divisé par 42,000 donne 0.23, donc la part de trafic direct est de 23 pour cent. L'équipe tague chaque lien de newsletter, fait passer une ancienne redirection de HTTP à HTTPS, et ajoute des paramètres au QR code de sa banderole de conférence. Le mois suivant, le direct tombe à 5,880 sur les mêmes 42,000 sessions. 5,880 divisé par 42,000 donne 0.14, soit une part de 14 pour cent, et les 9 points d'écart se trouvent maintenant dans des lignes e-mail et événement sur lesquelles vous pouvez agir. Comptez les sessions de la même façon sur les deux périodes, puisque les définitions de session diffèrent d'un outil à l'autre et qu'un changement de définition suffit à déplacer le ratio.

Part du trafic direct, avant et après le balisage

Avant le balisage23 %

Après le balisage14 %

Comment réduire le fourre-tout direct ?

Réduire le fourre-tout direct est un projet d'hygiène des liens, pas un réglage de reporting. Traitez-le par ordre de volume : taguez les liens d'e-mail et de newsletter, taguez chaque lien que vous collez dans Slack, LinkedIn ou un fil de communauté, taguez les QR codes et les URL imprimées, taguez les liens dans les PDF et les présentations, puis auditez vos chaînes de redirections pour tout saut qui n'est pas en HTTPS.

Vérifiez ensuite ce que votre propre site envoie vers l'extérieur. Un en-tête Referrer-Policy: no-referrer sur vos pages vous rend invisible dans les rapports de referral de vos partenaires, un choix de confidentialité légitime tant que vous le faites délibérément. Les éditeurs qui veulent rester attribuables gardent strict-origin-when-cross-origin et tous leurs liens sortants en HTTPS.

Que vérifier quand le trafic direct s'envole ?

Un bond soudain du trafic direct signale un changement dans vos liens ou dans votre script de tracking, pas une vague de gens qui se souviennent de votre domaine. Vérifiez quatre choses dans l'ordre : une nouvelle redirection qui a fait tomber un paramètre de campagne, un en-tête Referrer-Policy ajouté à votre site ou à celui d'un partenaire, une campagne partie sans tags UTM, et un script qui a commencé à se déclencher avant la lecture de la chaîne de requête.

Comparez le pic à la même fenêtre dans une seconde source de mesure, parce que les outils comptent le même trafic différemment et qu'un écart entre deux d'entre eux réduit vite le champ de recherche.

Questions fréquentes

Le trafic direct signifie-t-il que les gens ont tapé mon URL ?

Non. Les URL tapées et les favoris atterrissent en direct, mais chaque session dont le referrer a été retiré par une referrer policy, un passage HTTPS vers HTTP, un lien rel="noreferrer", une application native, un PDF ou une redirection y atterrit aussi. Le direct est le fourre-tout de tout ce que l'outil n'a pas pu attribuer, et les URL tapées n'en sont qu'une entrée.

Quel est un pourcentage de trafic direct normal ?

Il n'existe pas de référence défendable, parce que la part dépend de votre mix de canaux, des navigateurs de vos visiteurs et de la proportion de vos liens qui portent des paramètres de campagne. Mesurez votre propre chiffre, taguez vos liens, et mesurez à nouveau. C'est le mouvement entre ces deux relevés qui vous apprend quelque chose.

Pourquoi mon trafic direct a-t-il augmenté après une migration de site ?

Les migrations ajoutent des sauts de redirection, et chaque saut peut faire tomber le referrer ou retirer la chaîne de requête qui porte vos paramètres UTM. La spécification W3C Referrer Policy réinitialise la politique de referrer d'une requête à chaque réponse de redirection, donc un seul saut mal configuré change le comportement pour tout le reste de la chaîne. Suivez une vraie URL de campagne à travers chaque redirection et confirmez que les paramètres atteignent la destination finale.

GA4 traite-t-il le direct et l'unassigned de la même façon ?

Non. GA4 assigne Direct quand "Source exactly matches '(direct)' AND Medium is one of ('(not set)', '(none)')", ce qui veut dire que rien n'est arrivé du tout. Unassigned est "la valeur qu'Analytics utilise quand aucune autre règle de canal ne correspond aux données de l'événement", ce qui veut dire que quelque chose est arrivé mais n'a correspondu à aucune règle, ce qui pointe vers un utm_medium malformé.

Puis-je récupérer la vraie source d'une session directe ?

Pas après coup. L'en-tête Referer est arrivé ou ne l'est pas, et aucun traitement côté serveur ne reconstruit un en-tête que le navigateur n'a jamais envoyé. Récupérez la source pour l'avenir en la mettant dans l'URL sous forme de paramètres de campagne avant que le lien soit partagé.

Passer tout en HTTPS réduit-il le trafic direct ?

Cela retire une cause. La politique strict-origin-when-cross-origin par défaut n'envoie aucun referrer quand une page HTTPS pointe vers une page HTTP, donc toute URL HTTP dans votre entonnoir convertit des sessions de referral en sessions directes. Servir chaque page et chaque saut de redirection en HTTPS restaure l'origine sur ces requêtes, et laisse intactes les causes app, PDF et QR.

Pourquoi le trafic venant de Slack ou LinkedIn apparaît-il en direct ?

Un clic dans Slack ou LinkedIn ouvre le lien directement depuis l'application, pas depuis une page HTML, donc le client n'a aucune adresse de référence à envoyer dans l'en-tête Referer. La session arrive exactement comme un clic sur un favori, impossible à distinguer d'une URL tapée à la main. Ajoute utm_source et utm_medium à chaque lien avant de le coller dans une appli de chat ou un post social, car c'est le seul moyen de l'étiqueter avant que le referrer ne disparaisse.

Que fait rel="noreferrer" à mes rapports de trafic ?

Le mot-clé noreferrer demande au navigateur d'omettre l'en-tête Referer et de ne laisser fuiter aucune information de référence, le même effet qu'une politique no-referrer complète appliquée à tout un site. Un clic sur ce lien atterrit dans le fourre-tout direct même s'il provient d'une page qui t'appartient, indiscernable d'une visite depuis un favori. Ajoute des paramètres de campagne au lien lui-même si tu veux que la source reste visible dans tes rapports.

Faut-il mettre Referrer-Policy: no-referrer sur mon propre site ?

Cet en-tête rend ton site invisible dans le rapport de référencement de chaque partenaire, puisqu'aucun de tes clics sortants ne porte plus d'en-tête Referer. C'est un choix de confidentialité légitime tant qu'il est délibéré, pas un réglage par défaut laissé sans examen. Les sites qui veulent rester attribuables sur leurs liens sortants gardent strict-origin-when-cross-origin et servent chaque lien en HTTPS.

Quelle est la différence entre les politiques origin et no-referrer ?

Avec origin, le navigateur envoie toujours un en-tête Referer, mais réduit au seul domaine, quelque chose comme https://example.com/ sans chemin ni chaîne de requête. Avec no-referrer, l'en-tête n'apparaît jamais, donc la requête ressemble à une URL tapée à la main. origin indique encore quel site a envoyé le clic, no-referrer efface complètement la source.