Ruch przychodzi 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?

Np .: jeśli ktoś wpisze bit.lylink, jest on liczony jako bezpośredni, ale jeśli ktoś kliknie bit.lylink z Twittera, liczy się to jako ruch polecający z Twittera?

Usługi skracania adresów URL bit.lyi goo.gl(patrz uwaga tinyurl.componiż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.

• http://bit.ly/checkreferer

• http://tinyurl.com/checkreferer (patrz ważna uwaga poniżej dotycząca tinyurl.com)

• http://goo.gl/7AJgP

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.comwykonuje tylko zwykłe przekierowanie 301 (i wysyła odnośnik HTTP) na 2. i kolejne żądanie użytkownika !? Przy pierwszym żądaniu tinyurl.compojawia się strona pośrednia, a następnie wydaje przekierowanie (JavaScript?)! Powoduje to, że pierwsze żądanie zwraca 200 OKstatus, 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 Locationustawiono nagłówka, a widoczne są tylko 200 OKkody 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.

Jako odniesienie w tym artykule wymieniono wiele najpopularniejszych skracaczy adresów URL i wskazano, jakiego typu przekierowania używają.

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

To zależy.

W normalnych okolicznościach podczas korzystania z przeglądarki internetowej z Twittera lub mediów społecznościowych kliknięcie skróconego linku spowoduje wyświetlenie oryginalnego polecającego w Google Analytics. Ponieważ jednak wielu użytkowników korzysta z telefonu komórkowego i aplikacji społecznościowych zamiast przeglądarki, ruch będzie bezpośredni. Jeśli odfiltrujesz dane GA, prawdopodobnie zauważysz duży ruch bezpośredni z urządzeń mobilnych.

Jak to rozwiązać?

To jest naprawdę dość łatwe. Dodaj zmienne śledzenia kampanii do wszystkich adresów URL, zanim je skrócisz. Wtedy możesz zobaczyć wszystko poprawnie w GA. Ze śledzeniem kampanii mam na myśli dodawanie utm_source, utm_mediuma także utm_campaignzmienne URL. Jest to najlepszy sposób rozwiązania tego problemu bez względu na to, jakiej usługi skracania używasz, a nawet w różnych protokołach.

Zrobiłem trochę badań i znalazłem to; ruch skategoryzowany przez Google Analytics będzie się różnić w zależności od witryny skracającej adresy URL.

Aby uzyskać więcej informacji, skorzystaj z tego łącza:

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