Назад | Перейти на главную страницу

Несоответствие между аналитикой на стороне клиента и журналами apache

Мне довелось сравнить отчет Google Analytics с журналами доступа к apache, и он показывает поразительные 250% -ные спады.

У нас есть установка WordPress, размещенная на aws, с двумя веб-серверами за ELB и сервером NFS, RDS и эластичным кешем.

Я провел анализ следующим образом:

  1. На всех страницах поместите простой JavaScript, который проверяет мой сервер на PageReady, т.е. событие OnDomContentLoaded, и я записываю IP-адрес в URL-адрес страницы. Поскольку это самый простой код JavaScript, я предполагаю, что он должен работать в большинстве браузеров, а результаты очень близки к результатам, сгенерированным .
  2. Я проверяю законные запросы в журналах доступа (исключаю запросы без пользовательских агентов + без URL-адресов реферера и т. Д.) И проверяю только запросы, которые генерируют 200 206 301 302 кода ответа.

Когда я сравниваю пинги сервера, сгенерированные клиентом (пользовательский JavaScript, упомянутый в 1), и журналы доступа apache, падение кажется близким к 250%.

Это означает, что клиенты с отсутствующими IP-адресами не выполняли JavaScript, но загадочная часть заключается в том, что сервер отправляет код состояния 200. Итак, я пришел к выводу, что в большинстве случаев сервер отправляет пустой ответ. (Я учел несколько пользователей, которые отключают JavaScript, некоторые ошибки и т. Д.), Но я не могу проверить это предположение. (Если это вообще так).

Учитывая все это, может ли кто-нибудь указать мне в правильном направлении?

Уточнение:

Поскольку у меня нет репутации, чтобы добавить комментарий, я хотел бы добавить сюда несколько моментов.

Я искал только запросы документов, то есть исключая все CSS, JS и файлы изображений, и я отфильтровал ботов Google и другие подозрительные обходы. С учетом всего этого наблюдается явное падение до 250%.

проверять только запросы, которые генерируют 200 206 301 302 кода ответа.

Это будет слишком. Сумма, которую он завышает, зависит от того, сколько 301 и 302 вы обслужите. Браузеры, которые получают 301 или 302, будут перенаправлять без отправки вашего пинга JavaScript и, предположительно, позже сгенерируют 200, так что это приведет к двойному подсчету.

Фильтрация запросов от ботов и запросов css, javascript и изображений может быть подвержена ошибкам. Вместо этого я бы рекомендовал выбрать одну страницу на вашем сайте, на которой, как вы знаете, работает JS-аналитика (например, домашняя страница), и подсчитывать только запросы для нее. Кроме того, выберите из журналов один общий пользовательский агент, который обычно представляет собой настоящий браузер, и подсчитайте только запросы для него. Если числа приближаются к совпадению, вы можете немного расширить свой кругозор.

Также возможно, что ваш JS не работает должным образом в каждом браузере. Попробуйте настроить тестовый экземпляр своего сайта, а затем использовать такую ​​службу, как https://www.browserstack.com/ чтобы загрузить его в нескольких браузерах. Сгруппируйте журналы по пользовательскому агенту. Любой пользовательский агент, который делает основной запрос, но не отправляет пинг, вероятно, имеет проблемы с выполнением вашего JS. Запустите копию этого пользовательского агента и проверьте свой JS.

Ваш Apache журналы сообщают о ряде вещей, которые аналитика не считается. Это включает:

  • css, javascript, изображений и другой контент, включенный в ваши содержательные страницы. Их следует кэшировать, поэтому повторным посетителям не нужно будет получать их на последующих страницах. Однако вы должны увидеть HEAD запрашивает, начинают ли они новый сеанс браузера.
  • Контент проверяется ботами, которые индексируют ваш сайт. Искать +http:// в поле пользовательского агента, хотя не все пауки следуют этому стандарту.
  • Некоторые пользователи будут использовать инструменты, отключающие скрипты, поэтому этот законный трафик будет отсутствовать аналитика отчеты.