Le trafic provenant d'URL raccourcies comme bit.ly, apparaissent-ils dans Google Analytics comme directs ou conservent-ils leur véritable référent?

Ex.: Si quelqu'un tape un bit.lylien, cela compte comme direct, mais si quelqu'un clique sur un bit.lylien depuis Twitter, cela compte comme du trafic de référence depuis Twitter?

Les services de raccourcissement d'URL bit.lyet goo.gl(voir la remarque tinyurl.comci-dessous) renvoient un statut HTTP 301 Moved Permanently - c'est-à-dire. une redirection d'URL. Le navigateur envoie ensuite une nouvelle demande à la nouvelle URL (c'est-à-dire longue), en passant à nouveau le référent. AFAIK c'est la même chose pour la plupart des services de raccourcissement d'URL traditionnels.

Si le service effectue une redirection 301 (comme il se doit), le navigateur repasse le référent. Dans ce cas, je ne vois aucune raison pour que Google Analytics ne montre pas ce référent dans ses rapports.

Notez cependant que le navigateur lui-même peut être configuré pour supprimer le référent HTTP, ou même envoyer quelque chose de complètement erroné.

Le trafic provenant d'URL raccourcies comme bit.ly, apparaissent-ils dans Google Analytics comme directs ou conservent-ils leur véritable référent?

Ils gardent le vrai référent. Cela pourrait aussi être "direct", s'il s'agissait en fait d'une demande directe.

Ex. Si quelqu'un tape un lien bit.ly, cela compte comme direct, mais si quelqu'un clique sur un lien bit.ly depuis Twitter, cela compte comme du trafic de référence depuis Twitter?

Oui. Notez que Twitter encapsule désormais toutes ses URL dans son propre service de raccourcissement d'URL, donc l'URL de référence est du formulaire http://t.co/xyzxyz.

Un exemple

Les URL raccourcies suivantes redirigent toutes vers une page qui affiche le référent HTTP.

• http://bit.ly/checkreferer

• http://tinyurl.com/checkreferer (voir la note importante ci-dessous concernant tinyurl.com)

• http://goo.gl/7AJgP

Vous pouvez voir qu'en suivant l'un des liens ci-dessus, le référent HTTP est transmis (à condition que votre navigateur soit configuré pour le faire). Si vous copiez et collez l'URL dans une nouvelle fenêtre de navigateur, aucun référent n'est transmis - il s'agit d'un lien direct.

tinyurl.com (Mise à jour 2015-08-08)

Je ne sais pas si c'est quelque chose de nouveau, mais je viens de remarquer que tinyurl.comn'effectue qu'une redirection 301 régulière (et envoie le référent HTTP) sur la 2e demande et les suivantes effectuées par un utilisateur!? À la toute première demande, il tinyurl.comsemble charger une page intermédiaire puis émet une redirection (JavaScript?)! Il en résulte que la première demande renvoie un 200 OKétat et que le référent est défini sur l'URL "minuscule" raccourcie! (Et fait quelque chose de particulier avec l'historique du navigateur.)

Cependant, à la 2e demande, vous recevez une redirection 301 standard et le référent HTTP attendu est transmis (cela sera également mis en cache). (Je suppose que cela pourrait être déterminé par un cookie tinyurl.com qui est défini lors de la première demande?)

2015-08-09: J'ai déjà testé ce qui précède en utilisant une nouvelle fenêtre de navigation privée dans Google Chrome, cependant, il semble maintenant que cela entraîne une redirection 301 - donc, je ne sais pas exactement ce qui se passe tinyurl.com, était-ce juste un " pépin "?!

HTTPS - Connexions sécurisées

Juste une note supplémentaire sur les liens du contenu sécurisé (HTTPS) vers le contenu non sécurisé (HTTP) - cela affecte tout type de lien, pas seulement les raccourcisseurs d'URL. Dans ce cas, l'en-tête du référent HTTP n'est pas défini par le navigateur.

Les clients NE DEVRAIENT PAS inclure un champ d'en-tête Referer dans une demande HTTP (non sécurisée) si la page de référence a été transférée avec un protocole sécurisé.

Source: RFC 2616 Section 15.1.3

Redirection JavaScript

Cependant, une redirection JavaScript va détruire le referer d' origine. Aucun en- Locationtête n'est défini et vous ne voyez que 200 OKles codes d'état HTTP.

• Cette page effectue une redirection JavaScript vers la même page que ci-dessus (qui montre le référent HTTP). Mais au lieu de transmettre le référent d'origine (c'est-à-dire cette page), le référent HTTP est la page intermédiaire qui contient la redirection JavaScript.

À titre de référence, cet article répertorie la plupart des raccourcisseurs d'URL les plus populaires et indique le type de redirection qu'ils utilisent.

http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204

Ça dépend.

Dans des circonstances normales, lorsque vous utilisez un navigateur Web avec Twitter ou les réseaux sociaux en général, cliquer sur un lien raccourci affichera le référent d'origine dans Google Analytics. Cependant, comme de nombreux utilisateurs utilisent un téléphone mobile et des applications de médias sociaux au lieu d'un navigateur, vous vous retrouverez avec du trafic direct. Si vous filtrez vos données GA, vous verrez probablement beaucoup de trafic direct depuis les mobiles.

Comment résoudre ça?

C'est en fait assez simple. Ajoutez des variables de suivi de campagne à toutes vos URL avant de les raccourcir. Ensuite, vous pouvez tout voir correctement dans GA. Avec suivi de campagne que je veux dire ajouter utm_source, utm_mediumet aussi des utm_campaignvariables URL. C'est la meilleure façon de résoudre ce problème, quel que soit le service de raccourcissement que vous utilisez et même entre différents protocoles.

J'ai fait des recherches et j'ai trouvé cela; le trafic classé par Google Analytics variera selon le site Web du raccourcisseur d'URL.

Reportez-vous à ce lien pour plus d'informations:

• http://www.fathomdelivers.com/twitter-url-shortener-google-analytic/