Трафик идет от сокращенных URL-адресов, например bit.ly, они отображаются в Google Analytics как прямые или они сохраняют реальный реферал?

Пример: если кто-то вводит bit.lyссылку, она считается прямой, но если кто-то щелкает bit.lyссылку из Twitter, она считается реферальным трафиком из Twitter?

Службы сокращения URL-адресов bit.lyи goo.gl(см. Примечание tinyurl.comниже) возвращают статус HTTP 301 Moved Permanently HTTP, т.е. перенаправление URL. Затем браузер отправляет новый запрос на новый (т. Е. Длинный) URL, снова передавая реферер. AFAIK это то же самое для большинства основных служб сокращения URL.

Если служба выполняет перенаправление 301 (как и должно быть), то браузер переопределяет реферер. В этом случае я не вижу причин для того, чтобы Google Analytics не показывал этого реферера в своих отчетах.

Однако обратите внимание, что сам браузер может быть настроен на подавление реферера HTTP или даже на отправку чего-либо совершенно ошибочного.

Трафик приходит из сокращенных URL-адресов, таких как bit.ly, они отображаются в Google Analytics как прямые или у них есть реальный реферал?

Они держат настоящего рефери. Это также может быть «прямым», если это действительно был прямой запрос.

Ex. Если кто-то вводит ссылку bit.ly, она считается прямой, но если кто-то нажимает ссылку bit.ly из Twitter, она считается реферальным трафиком из Twitter?

Да. Обратите внимание, что twitter теперь оборачивает все свои URL-адреса в свой собственный сервис сокращения URL-адресов, поэтому ссылающийся URL-адрес имеет вид http://t.co/xyzxyz.

Пример

Следующие сокращенные URL-адреса перенаправляют на страницу, на которой показан HTTP-реферер.

• http://bit.ly/checkreferer

• http://tinyurl.com/checkreferer (см. важное примечание ниже относительно tinyurl.com)

• http://goo.gl/7AJgP

Вы можете видеть, что по любой из приведенных выше ссылок HTTP-реферер пропускается (при условии, что ваш браузер настроен на это). Если вы копируете и вставляете URL-адрес в новом окне браузера, то реферер не передается - это прямая ссылка.

tinyurl.com (Обновлено 2015-08-08)

Я не знаю, является ли это чем-то новым, но я только что заметил, что tinyurl.comтолько выполняет обычное перенаправление 301 (и отправляет HTTP Referer) на 2-й и последующие запросы, сделанные пользователем !? При самом первом запросе tinyurl.comпоявляется загрузка промежуточной страницы, а затем выдается (JavaScript?) Редирект! Это приводит к тому, что первый запрос возвращает 200 OKстатус и рефереру присваивается сокращенный «крошечный» URL! (И делает что-то особенное с историей браузера.)

Однако по второму запросу вы получаете стандартное перенаправление 301, и ожидаемый HTTP Referer передается (он также будет кэширован). (Полагаю, это может быть определено файлом cookie tinyurl.com, который устанавливается во время первого запроса?)

2015-08-09: Ранее я проверял вышеупомянутое, используя новое окно инкогнито в Google Chrome, однако теперь оно, похоже, приводит к перенаправлению 301 независимо от этого - так что, не совсем уверенный в том, что происходит tinyurl.com, это было просто " Сбой"?!

HTTPS - Безопасные соединения

Просто дополнительная заметка о ссылках с защищенного контента (HTTPS) на небезопасный контент (HTTP) - это влияет на любые ссылки, а не только на сокращатели URL. В этом случае заголовок реферера HTTP не устанавливается браузером.

Клиенты НЕ ДОЛЖНЫ включать поле заголовка Referer в (незащищенный) HTTP-запрос, если ссылающаяся страница была передана по безопасному протоколу.

Источник: RFC 2616, раздел 15.1.3.

JavaScript Redirect

Тем не менее, переадресация JavaScript будет уничтожить исходный реферер. Нет Locationзаголовка не установлен , и вы видите только 200 OKHTTP коды статуса.

• Эта страница выполняет перенаправление JavaScript на ту же страницу, что и выше (на которой показан HTTP Referer). Но вместо передачи исходного Referer (т. Е. Этой страницы) HTTP Referer является промежуточной страницей, содержащей перенаправление JavaScript.

В качестве ссылки в этой статье перечислены многие из наиболее популярных сокращателей URL-адресов и указано, какой тип перенаправления они используют.

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

Это зависит.

При нормальных обстоятельствах, когда вы используете веб-браузер с Twitter или социальные сети в целом, при нажатии на укороченную ссылку в Google Analytics отображается исходный реферер. Однако, поскольку многие пользователи используют мобильный телефон и приложения для социальных сетей вместо браузера, вы получите прямой трафик. Если вы отфильтруете данные GA, вы, скорее всего, увидите много прямого трафика с мобильных устройств.

Как это решить?

Это на самом деле довольно легко. Добавьте переменные отслеживания кампании ко всем своим URL-адресам, прежде чем сокращать их. Тогда вы можете увидеть все правильно в GA. Под отслеживанием кампании я подразумеваю добавление utm_source, utm_mediumа также utm_campaignпеременные URL. Это лучший способ решения этой проблемы, независимо от того, какую службу сокращения вы используете, и даже для разных протоколов.

Я провел некоторое исследование и нашел это; трафик, классифицированный Google Analytics, будет зависеть от веб-сайта сокращения URL.

Обратитесь к этой ссылке для получения дополнительной информации:

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