O tráfego proveniente de URLs encurtados bit.ly, como , eles aparecem no Google Analytics como diretos ou mantêm o seu real referenciador?
Ex .: se alguém digitar um bit.lylink, isso será considerado direto, mas se alguém clicar em um bit.lylink do Twitter, será considerado tráfego de referência do Twitter?
Respostas:
Os serviços de encurtamento de URL bit.lye goo.gl(consulte a observação tinyurl.comabaixo) retornam um status HTTP 301 movido permanentemente - ou seja. um redirecionamento de URL. O navegador envia uma nova solicitação para o novo URL (longo), passando o referenciador novamente. AFAIK é o mesmo para a maioria dos serviços de encurtamento de URL.
Se o serviço executar um redirecionamento 301 (como deveria), o navegador repassará o referenciador. Nesse caso, não vejo razão para o Google Analytics não mostrar esse referenciador em seus relatórios.
Observe, no entanto, que o próprio navegador pode ser configurado para suprimir o referenciador HTTP ou até mesmo enviar algo completamente errado.
O tráfego proveniente de URLs encurtados como bit.ly, eles são exibidos no Google Analytics como diretos ou mantêm o seu real referenciador?
Eles mantêm o verdadeiro referenciador. Isso também pode ser "direto", se de fato foi um pedido direto.
Ex. Se alguém digitar um link bit.ly, será considerado direto, mas se alguém clicar no link bit.ly no Twitter, será considerado tráfego de referência do Twitter?
Sim. Nota que o Twitter agora envolve todos os seus URLs em seu próprio serviço de encurtamento de URL, então o URL de referência é da forma http://t.co/xyzxyz.
Os seguintes URLs encurtados são todos redirecionados para uma página que mostra o referenciador HTTP.
http://tinyurl.com/checkreferer (veja a observação importante abaixo sobre tinyurl.com)
Você pode ver que, seguindo qualquer um dos links acima, o referenciador HTTP é passado (desde que seu navegador esteja configurado para isso). Se você copiar e colar o URL em uma nova janela do navegador, nenhum referenciador será passado - é um link direto.
Não sei se isso é algo novo, mas acabei de notar que tinyurl.comapenas executa um redirecionamento 301 regular (e envia o Referenciador HTTP) na 2ª e nas solicitações subsequentes feitas por um usuário !? Na primeira solicitação, tinyurl.comparece carregar uma página intermediária e, em seguida, emite um redirecionamento (JavaScript?)! Isso resulta na primeira solicitação retornando um 200 OKstatus e o referenciador sendo definido como o URL "minúsculo" reduzido! (E faz algo peculiar com o histórico do navegador.)
No entanto, na segunda solicitação, você recebe um redirecionamento 301 padrão e o Referenciador HTTP esperado é passado (isso também será armazenado em cache). (Acho que isso pode ser determinado por um cookie tinyurl.com definido durante a primeira solicitação?)
09-08-2015: eu testei anteriormente o procedimento acima usando uma nova janela anônima no Google Chrome, no entanto, agora parece resultar em um redirecionamento 301 independentemente. Portanto, não sei exatamente o que está acontecendo tinyurl.com, era apenas um " falha "?!
Apenas uma observação adicional sobre links de conteúdo seguro (HTTPS) para conteúdo não seguro (HTTP) - isso afeta qualquer tipo de link, não apenas os encurtadores de URL. Nesse caso, o cabeçalho do referenciador HTTP não é definido pelo navegador.
Os clientes não devem incluir um campo de cabeçalho de referência em uma solicitação HTTP (não segura) se a página de referência foi transferida com um protocolo seguro.
Fonte: Seção 15.1.3 da RFC 2616
No entanto, um redirecionamento JavaScript irá destruir o referer originais. Nenhum Locationcabeçalho está definido e você vê apenas 200 OKcódigos de status HTTP.
Como referência, este artigo lista muitos dos encurtadores de URL mais populares e indica que tipo de redirecionamento eles usam.
http://searchengineland.com/analysis-which-url-shortening-service-should-you-use-17204
Depende.
Em circunstâncias normais, ao usar um navegador da Web com o Twitter ou a mídia social em geral, clicar em um link reduzido exibirá o referenciador original no Google Analytics. No entanto, como muitos usuários estão usando um telefone celular e aplicativos de mídia social em vez de um navegador, você terá tráfego direto. Se você filtrar seus dados do GA, provavelmente verá muito tráfego direto do celular.
Como resolver isso?
É realmente muito fácil. Adicione variáveis de rastreamento de campanha a todos os seus URLs antes de encurtá-los. Então você pode ver tudo correto no GA. Com campanha de rastreamento I significar a adição utm_source, utm_mediume também utm_campaignvariáveis de URL. Essa é a melhor maneira de resolver isso, independentemente do serviço de encurtamento que você está usando e mesmo em diferentes protocolos.
Eu fiz algumas pesquisas e descobri isso; o tráfego categorizado pelo Google Analytics varia de acordo com o site do encurtador de URL.
Consulte este link para obter mais informações: