Le trafic provenant de raccourcisseurs d’URL est-il traité comme direct?
Le trafic provenant d'URL abrégées telles que bit.ly s'affiche-t-il directement dans Google Analytics ou conserve-t-il son véritable référent?
Ex .: si quelqu'un tape dans un lien bit.ly, il compte comme étant direct, mais si quelqu'un clique sur un lien bit.ly de Twitter, il compte comme un trafic de parrainage provenant de Twitter?
Les services de raccourcissement d'URL bit.ly et goo.gl (voir la remarque sur tinyurl.com ci-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 transmettant à nouveau le référant. Autant que je sache, c’est la même chose pour la plupart des services de réduction d’URL courants.
Si le service effectue une redirection 301 (comme il se doit), le navigateur repasse le référant. Dans ce cas, je ne vois aucune raison pour que Google Analytics n’indique 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 raccourcis, par exemple bit.ly, apparaît-il directement dans Google Analytics ou conserve-t-il son vrai référent?
Ils gardent le vrai référant. Cela pourrait aussi être "direct", si en fait c'était une demande directe.
Ex. Si quelqu'un tape un lien bit.ly, cela compte comme étant direct, mais si quelqu'un clique sur un lien bit.ly de Twitter, cela compte comme un trafic de parrainage provenant de Twitter?
Oui. Notez que Twitter encapsule désormais toutes ses URL dans son propre service de réduction d'URL. L'URL de renvoi est donc de la forme http://t.co/xyzxyz.
Un exemple
Les URL abrégées suivantes redirigent toutes vers une page contenant le référent HTTP.
http://tinyurl.com/checkreferer (voir la remarque importante ci-dessous concernant tinyurl.com)
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 le 2015-08-08)
Je ne sais pas s'il s'agit de quelque chose de nouveau, mais je viens de remarquer que tinyurl.com n'effectue qu'une redirection 301 régulière (et envoie le référent HTTP) le 2e et les demandes ultérieures faites par un utilisateur !? À la toute première demande, tinyurl.com apparaît pour charger une page intermédiaire puis émettre une redirection (JavaScript?)! Cela a pour résultat que la première requête renvoie un statut 200 OK et que le référent est défini sur l'URL "petite" raccourcie! (Et fait quelque chose de particulier avec l'historique du navigateur.)
Toutefois, lors de la deuxième demande, une redirection 301 standard est servie et le référent HTTP attendu est transmis (celui-ci 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 à l'aide d'une nouvelle fenêtre de navigation privée dans Google Chrome. Toutefois, il semble maintenant qu'il en résulte une redirection 301, peu importe - alors je ne sais pas exactement ce qui se passe avec tinyurl.com, était-ce juste un "pépin"?!
HTTPS - Connexions sécurisées
Juste une note supplémentaire sur les liens allant du contenu sécurisé (HTTPS) au contenu non sécurisé (HTTP) - cela concerne 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 de champ d’en-tête de référent dans une requête HTTP (non sécurisée) si la page de renvoi a été transférée avec un protocole sécurisé.
Source: RFC 2616 section 15.1.
Redirection JavaScript
Cependant, une redirection JavaScript détruira le référent d'origine. Aucun en-tête Location n'est défini et vous ne voyez que 200 OK Codes d'état HTTP.
- Cette page effectue une redirection JavaScript vers la même page que ci-dessus (qui affiche 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 courants 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 médias sociaux en général, un clic sur un lien raccourci affichera le parrain d'origine dans Google Analytics. Cependant, étant donné que de nombreux utilisateurs utilisent un téléphone portable et des applications de réseaux sociaux au lieu d'un navigateur, vous allez vous retrouver avec un trafic direct. Si vous filtrez vos données GA, vous verrez probablement beaucoup de trafic direct en provenance de mobile.
Comment résoudre ceci?
C'est en fait assez facile. Ajoutez des variables de suivi de campagne à toutes vos URL avant de les raccourcir. Ensuite, vous pouvez voir que tout est correct dans GA. Par suivi de campagne, je veux dire en ajoutant utm_source, utm_medium et aussi utm_campaign variables 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 à travers différents protocoles.
J'ai fait des recherches et j'ai trouvé ça; le trafic catégorisé par Google Analytics variera en fonction du site Web de raccourcisseur d'URL.
Reportez-vous à ce lien pour plus d'informations: