Usługi skracania adresów URL bit.ly
i goo.gl
(patrz uwaga tinyurl.com
poniżej) zwracają status 301 Przeniesiony na stałe HTTP - tj. przekierowanie adresu URL. Przeglądarka wysyła następnie nowe żądanie na nowy (tj. Długi) adres URL, ponownie przekazując odnośnik. AFAIK to samo dotyczy większości głównych usług skracania adresów URL.
Jeśli usługa wykonuje przekierowanie 301 (tak jak powinno), przeglądarka przekierowuje odsyłacz. W takim przypadku nie widzę powodu, dla którego Google Analytics nie wyświetla tego odsyłacza w swoich raportach.
Pamiętaj jednak, że samą przeglądarkę można skonfigurować tak, aby ukrywała odsyłacz HTTP, a nawet wysyłała coś całkowicie błędnego.
Ruch przychodzący ze skróconych adresów URL takich jak bit.ly, czy są one wyświetlane w Google Analytics jako bezpośrednie, czy też utrzymują swoje prawdziwe strony polecające?
Zatrzymują prawdziwego arbitra. Może to być również „bezpośrednie”, jeśli rzeczywiście było to bezpośrednie żądanie.
Dawny. Jeśli ktoś wpisze link bit.ly, liczy się on jako bezpośredni, ale jeśli ktoś kliknie link bit.ly z Twittera, liczy się to jako ruch polecający z Twittera?
Tak. Pamiętaj, że Twitter otacza teraz wszystkie swoje adresy URL własną usługą skracania adresów URL, więc odsyłający adres URL ma formę http://t.co/xyzxyz
.
Przykład
Poniższe skrócone adresy URL przekierowują na stronę z odsyłaczem HTTP.
Możesz zobaczyć, że podążając za jednym z powyższych linków, odsyłacz HTTP jest przekazywany (pod warunkiem, że Twoja przeglądarka jest ustawiona na to). Jeśli skopiujesz i wkleisz adres URL w nowym oknie przeglądarki, żaden odnośnik nie zostanie przekazany - jest to bezpośredni link.
tinyurl.com (zaktualizowano 08.08.2015)
Nie wiem, czy to jest coś nowego, ale właśnie zauważyłem, że tinyurl.com
wykonuje tylko zwykłe przekierowanie 301 (i wysyła odnośnik HTTP) na 2. i kolejne żądanie użytkownika !? Przy pierwszym żądaniu tinyurl.com
pojawia się strona pośrednia, a następnie wydaje przekierowanie (JavaScript?)! Powoduje to, że pierwsze żądanie zwraca 200 OK
status, a obiekt odsyłający jest ustawiony na skrócony „mały” adres URL! (I robi coś dziwnego z historią przeglądarki).
Jednak na drugie żądanie otrzymasz standardowe przekierowanie 301 i oczekiwany odnośnik HTTP zostanie przekazany (to również zostanie zapisane w pamięci podręcznej). (Wydaje mi się, że może to wynikać z pliku cookie tinyurl.com, który jest ustawiany podczas pierwszego żądania?)
2015-08-09: Wcześniej testowałem powyższe przy użyciu nowego okna incognito w Google Chrome, jednak teraz wydaje się, że skutkuje przekierowaniem 301 niezależnie od tego - więc nie jestem pewien, co się dzieje tinyurl.com
, czy to tylko „ usterka"?!
HTTPS - Bezpieczne połączenia
Tylko dodatkowa uwaga na temat linków od bezpiecznej treści (HTTPS) do niezabezpieczonej treści (HTTP) - wpływa to na każdy rodzaj linku, nie tylko skracacze adresów URL. W takim przypadku nagłówek odsyłacza HTTP nie jest ustawiany przez przeglądarkę.
Klienci NIE POWINNI zawierać pola nagłówka odsyłacza w (niezabezpieczonym) żądaniu HTTP, jeśli strona odsyłająca została przesłana za pomocą bezpiecznego protokołu.
Źródło: RFC 2616 sekcja 15.1.3
JavaScript Przekierowanie
Jednak przekierowanie JavaScript będzie niszczyć oryginalnego Referer. Nie Location
ustawiono nagłówka, a widoczne są tylko 200 OK
kody stanu HTTP.
- Ta strona przekierowuje JavaScript na tę samą stronę, co powyżej (która pokazuje odnośnik HTTP). Ale zamiast przekazywać oryginalny odnośnik (tj. Tę stronę), odnośnik HTTP jest stroną pośrednią, która zawiera przekierowanie JavaScript.