Как уже было показано, совершенно невозможно сравнивать результаты, полученные различными методами сбора данных. Подобное сопоставление просто неправомочно. Но можно ли достичь непротиворечивости при использовании двух сравнимых методов сбора данных — например, использующих страничные теги? К сожалению, даже сравнение результатов тех поставщиков данных веб-аналитики, которые используют страничные теги, связано со своими трудностями. Факторы, которые ведут к различию в метриках, полученных различными поставщиками, описаны в последующих статьях.

Основные и сторонние файлы cookie

Данные, полученные с их помощью, плохо согласуются между собой, поскольку сторонние файлы cookie гораздо чаще блокируются пользователями, брандмауэрами и антишпионскими программами. Например, последние версии Microsoft Internet Explorer блокируют сторонние файлы cookie по умолчанию, если у сайта нет четко сформулированной политики конфиденциальности (см. http://www.w3.org/P3P).

Страничные теги: соображения по размещению

в веб-браузере код JavaScript, как и любой другой код веб-контента, загружается последовательно. То есть фрагменты кода следуют один за другим, наряду с другим контентом страницы, таким как текст, таблицы стилей и изображения. Поэтому поставщики страничных тегов рекомендуют размещать их теги страниц непосредственно над дескриптором </body> HTML-страницы (расположенным в нижней части страницы), чтобы вначале загружался визуальный контент страницы. Это означает, что любые задержки, связанные с работой серверов поставщиков данных, не будут мешать загрузке страницы. Но в этом случае возможна следующая проблема: вернувшиеся посетители, которые знакомы с системой навигации веб-сайта, могут быстро перейти на другую страницу до того, как будет загружен страничный тег, предназначенный для сбора данных. Чем больше контента содержат страницы, тем медленнее они будут загружаться и тем вероятнее, что посетители будут переходить на другую страницу, прежде чем выполнится код отслеживания.

Возможный способ решения этой проблемы — размещение страничных тегов в верхней части страниц, чтобы они загружались до загрузки любого контента, это касается графических файлов, например детские новогодние костюмы фото. Но при этом существует риск, что задержка в работе, отказ или перебой в работе сервера поставщика веб-аналитики приведет к остановке загрузки страниц. Ни одна из описанных ситуаций не идеальна, но понятно, что задержка предоставления контента посетителям — наихудший сценарий из возможных. Поэтому размещение тегов в нижней части страниц стало фактическим стандартом.

Размещение тегов было исследовано в официальном докладе, опубликованном TagMan.com в 2009 г Исследование влияния задержек показало, что приблизительно 10% зафиксированного трафика теряется из-за каждой лишней секунды задержки страницы. Поэтому «тяжеловесный» контент страницы ведет к недобору трафика. Перенос страничного тега Google Analytics с нижней части страницы в верхнюю повышало зафиксированный трафик на 20%.

Кроме того, не связанный с отслеживанием код JavaScript, который помещен вверху страницы, может вступить в противоречие со страничными тегами JavaScript, которые размещены на странице ниже. Страничные теги большинства поставщиков работают независимо от других кодов JavaScript и могут успешно сосуществовать со страничными тегами других поставщиков. Однако ошибки JavaScript на одной и той же странице приведут к остановке механизма сценариев браузера и помещают выполнению любого ниже расположенного кода JavaScript, в том числе вашего страничного тега.

Все ли помечено тегами?

Многие инструменты веб-аналитики требуют, чтобы ссылки на PDF-файлы, документы Word и исполняемые файлы либо исходящие ссылки на другие веб-сайты были модифицированы, для того чтобы их можно было отслеживать. Возможно, ссылки придется модифицировать вручную. Модификация представляет событие или действие, которое происходит при клике на ссылке; это иногда называют виртуальным просмотром страницы. Для сравнения данных различных поставщиков это действие необходимо выполнить несколько раз с их кодами (обычно, кодами JavaScript). Учтите, что при написании кода страниц всегда существует вероятность синтаксических ошибок. Если страница обновляется часто, то старайтесь регулярно проверять страничные теги.

Просмотры страниц: посещение или посетитель?

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

Тайм-ауты файлов cookie

Допустимая продолжительность тайм-аутов — т.е. интервал времени, в течение которого веб-страница остается неактивной у посетителя — варьируется у разных поставщиков. Для большинства поставщиков страничных тегов стандартом для файлов cookie является 30-минутный тайм-аут в сеансе работы посетителя. Это означает, что продолжение просмотра того же веб-сайта по истечении 30-минутного интервала пассивности считается новым посещением. Но некоторые поставщики предоставляют возможность изменения этого параметра. В результате данные будут не согласованы, что повлияет на отчеты о посетителях. У других файлов cookie, например, таких, которые сохраняют данные об источнике перехода, будут иные значения тайм-аутов. Например, для файлов cookie Google Analytics, содержащих данные об источнике перехода, это значение составляет 6 месяцев. Различные значения этих параметров у разных поставщиков пакетов веб-аналитики, очевидно, повлияют на результаты отчетов о количестве посетителей.

Похищение кода страничных тегов

В зависимости от поставщика веб-аналитики, коды страничных тегов могут быть похищены, скопированы и выполнены на другом или не связанном с данным контентом веб-сайте. Результатом станут ложные данные о просмотрах страниц в отчетах. Используя фильтры, можно обеспечить, чтобы отчеты содержали данные только с ваших доменов.

Выборка данных

Под выборкой понимается выбор поднабора данных из трафика веб-сайта. Выборки широко используются в статистическом анализе, поскольку результаты анализа поднабора данных в большой степени совпадают с результатами анализа полного набора, но позволяют значительно ускорить обработку больших объемов информации. Различные поставщики могут использовать различные методики и критерии формирования выборок, что ведет к несовпадению данных. Вопросы отбора данных для Google Analytics рассмотрены в разделе «Пояснение выборки отчета».

PDF-файлы: особые замечания

Если вы используете странргчные теги, то в отчеты помещаются данные не о завершенной загрузке PDF-файлов, а только о том, что посетитель кликнул на ссылке PDF-файла. Это важное различие, поскольку информация о том, завершил ли посетитель загрузку (например, 50-страничного PDF-файла), не доступна. Поэтому клик на ссылке PDF-файла будет отражен в отчетах как одно событие или просмотр страницы.

В случае использования журнальных файлов ситуация иная. При просмотре PDF-файла в браузере Adobe Reader может загружать файл по одной странице, а не целиком. В результате журнальный файл веб-сервера будет содержать несколько иную запись, с кодом состояния HTTP 206 (частичная загрузка файла). Пакеты веб-аналитики на основе журнальных файлов могут трактовать каждую запись о коде состояния 206 как отдельный просмотр страницы. Когда все страницы PDF-файла загружены, в журнальный файл вносится запись о полной загрузке с окончательным HTTP-кодом состояния 200 (загрузка завершена). Поэтому пакет на основе журнальных файлов сообщит в отчете о завершенной загрузке 50-страничного PDF-файла как об одной загрузке и о 50 просмотрах страниц. Однако конечный результат будет зависеть от ряда факторов — браузера посетителя, надстройки браузера и от того, кликнул посетитель левой кнопкой (для просмотра в браузере) или правой кнопкой (чтобы выполнить загрузку для просмотра вне браузера).

Электронная торговля: отрицательные транзакции

Всем организациям, которые занимаются электроьшой торговлей, время от времени приходится иметь дело с возвратами товаров из-за брака, ошибок в заказе или по другим причинам. Часто веб-аналитики забывают об учете этих возвратов в своих отчетах. Для некоторых поставщиков в этих случа51х требуется вручную вводить данные об отрицательной транзакции, эквивалентной транзакции покупки. При использовании инструментов других поставщиков приходится повторно обрабатывать файлы данных электронной торговли. Но какой бы метод ни использовался, согласование данных веб-аналитики и внутренних систем организации вряд ли пройдет гладко. Например, удаление или кредитование транзакции обычно происходит намного позже первоначальной покупки и, следовательно, в другой отчетный период.

Фильтры и настройки: возможные препятствия

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

В качестве примера можно привести фильтр страничного уровня для исключения из отчетов всех ошибочных страниц. От поставщика инструментов аналитики зависит, можно ли настроить для фильтра такие метрики посещений, как длительность пребывания на сайте, глубина посещения и т.д. Это связано с тем, что некоторые поставщики пакетов аналитики выполняют обработку метрик страничного уровня отдельно от метрик уровня посетителей.

Расхождения в значениях времени

Когда дело доходит до вычисления времени, проведенного посетителем на сайте, или продолжительности просмотра страницы в ходе сеанса пользователя, у любого поставщика пакета аналитики возникают сложности при вычислении метрик для последней просмотренной страницы. Например, время, проведенное на странице А, вычисляется как разность между временной меткой станицы А и последующей временной меткой страницы В, и т.д. Но как быть, если никакой страницы С не существует? Как вычислить продолжительность пребывания на странице В, если не существует никакой последующей временной метки?

Различные поставщики решают эту проблему по-разному. Некоторые просто игнорируют в расчетах просмотр последней страницы. Другие используют событие onUnload для добавления временной метки в тех случаях, когда посетитель закрывает свой браузер или переходит на другой веб-сайт. Оба метода вполне допустимы, хотя и не все поставщики применяют метод с использованием события onUnload. Причина, по которой некоторые поставщики предпочитают игнорировать последнюю страницу, заключается в том, что она считается наиболее неточной с точки зрения измерения времени — не исключено, что посетителя прервали, или же он оставил свой браузер в текущем состоянии, занявшись чем-либо другим. Многие пользователи ведут себя подобным образом — т.е. завершают просмотр веб-страниц и просто оставляют свой браузер открытым на последней просмотренной странице во время работы в другом приложении. Небольшое количество просмотров страниц этого типа непропорционально искажают результаты вычислений продолжительности пребывания на сайте и продолжительности просмотра страниц. Поэтому большинство поставщиков стараются избежать этой проблемы.

Частота обработки

Понятие частоты обработки лучше всего можно проиллюстрировать на следующем примере. Для составления отчетов Google Analytics проводит вычисления каждый час. Но поскольку на объединение всех журнальных файлы со всех серверов, осуществляющих сбор данных по всему миру, требуется время, отчеты запаздывают относительно текущего времени на три-четыре часа. В большинстве случаев этот процесс проходит гладко, но иногда возникают проблемы. Например, если передача журнального файла прерывается, то он будет обработан только частично. Поэтому в конце дня Google Analytics собирает и вновь обрабатывает все данные за 24-часовой период. Другие поставщики пакетов аналитики могут поступать так же, поэтому не стоит обращать внимание на расхождения, относящиеся к текущему дню.

Конверсия целей и просмотры страниц: согласование

В качестве примера будем использовать рис. 2.4. Предположим, что эти пять страниц — часть определенной вами последовательности конверсии (т.е. последовательности кликов на ссылках), где последний шаг (страница 5) представляет целевую конверсию (покупку). Во время процесса покупки посетитель возвращается на одну страницу назад, чтобы проверить цену доставки (шаг А), а затем продолжает оформление заказа вплоть до оплаты покупки. Посетителю настолько нравится простота процесса покупки, что он покупает второй товар, проходя в точности тот же путь во время того же сеанса посещения (шаг В).

В зависимости от поставщика пакета веб-аналитики, этот процесс может трактоваться по-разному, следующим образом:

• 12 просмотров страниц последовательности, 2 конверсии, 2 транзакции;
• 10 просмотров страниц последовательности (шаг А игнорируется), 2 конверсии, 2 транзакции;
• 5 просмотров страниц последовательности, 2 конверсии, 2 транзакции;
• 5 просмотров страниц последовательности, одна конверсия (шаг В игнорируется), 2 транзакции.

Большинство поставщиков, но не все, применяют к своим отчетам последний подход. То есть посетитель становится покупателем (одна конверсия), и это может случиться только один раз за сеанс, поэтому дополнительные конверсии (при условии, что они направлены на ту же цель) игнорируются. Чтобы такой подход был правомерным, те же соображения должны применяться к страницам последовательности. В результате данные становятся более ориентированными на посетителя. Google Analytics действует описанным образом.