Как мы отслеживаем просмотры страниц

Ссылка на оригинал - https://philipwalton.com/articles/how-we-track-pageviews-is-all-wrong/, автор публикации - PHILIP WALTON

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

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

Реальность такова, что Сеть сильно изменилась за последние 10-15 лет, и все больше и больше сайтов не соответствуют этой традиционной модели. Наши инструменты аналитики не сохранились.

Проблема

Чтобы дать вам конкретный пример, рассмотрите mail.google.com (Gmail). Большинство пользователей, которые используют Gmail в своем браузере, открывают его в фоновом режиме и периодически переключаются на него, чтобы узнать, есть ли у них новые сообщения. Когда они это сделают, они нажимают на сообщение, чтобы прочитать его.

Подавляющее большинство пользователей Gmail почти никогда не перезагружают страницу, что вызывает несколько важных вопросов с точки зрения аналитики:

  • Если пользователь загружает Gmail один раз, а затем использует его сотни раз в течение следующих нескольких дней без перезагрузки, следует ли это рассматривать только один просмотр страницы?
  • Если пользователь нажимает логотип для обновления содержимого (или через pull для обновления в мобильной версии приложения), следует ли считать его просмотром страницы? Является ли это использование функционально отличным от обновления страницы для загрузки нового контента?
  • Как насчет того, когда пользователь загружает новое сообщение, следует ли считать его новым просмотром страницы?
  • Если два пользователя посещают Gmail точно такое же количество раз в день, но один из них загружает сайт заново каждый раз, а другой оставляет его открытым на вкладке фона, должны ли эти два шаблона использования приводить к значительному разному количеству просмотров страниц?

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

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

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

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

Решение

Я думаю, что есть решение, и решение, которое я предлагаю, берет сигнал от самого имени метрики: Pageviews (Просмотры страниц).

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

Как выясняется, отслеживание того, как часто просматривалась страница, а не как часто ее загружалось, элегантно обрабатывает удивительное количество случаев, которые не работают с текущей моделью:

  • Когда пользователи покидают приложение на вкладке фона и переключаются на него через несколько часов или дней без перезагрузки.
  • Когда пользователи оставляют вкладку открытой как ссылку и часто переключаются на нее для быстрого доступа к контенту (опять же, без перезагрузки страницы).
  • Когда пользователи открывают страницу на вкладке фона, а затем забывают об этом (никогда не просматривая контент).

API видимости страницы содержит как document.visibilityState свойство, так и visibilitychange событие. С помощью этих двух частей , которые Вы можете гарантировать, что Просматриваемые никогда не посылается , если данная страница visibilityStateнет visible, и вы можете также отправить просмотры страниц в тех случаях , когда пользователь возвращается на ваш сайт после того, как это было в фоновой вкладке на некоторое время, путь прослушивания visibilitychangeсобытий. API видимости страницы решает проблему отслеживания просмотров страниц в приложениях, которые никогда не нужно перезагружать.

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

Технические подробности

Основная идея отслеживания просмотров страниц с помощью API-интерфейсов видимости страниц и истории выглядит следующим образом (и эти действия могут быть применены к любому веб-сайту, независимо от того, является ли это традиционным сайтом контента, SPA или PWA):

  1. Когда страница загружается, отправьте просмотр страницы, если вид видимости виден.
  2. Если состояние видимости не отображается, подождите, пока состояние видимости изменится на видимое и отправьте просмотр страницы в этот момент. [1]
  3. Если состояние видимости изменяется со скрытого на видимое и достаточно прошло с момента предыдущего взаимодействия этого пользователя, отправьте просмотр страницы.
  4. Если URL-адрес изменяется (просто имя пути или части поиска, а не хеш-часть, так как это используется для ссылок привязки), отправьте просмотр страницы.

Третий шаг выше - самый важный, и он также является самым двусмысленным. Вопрос в следующем: как долго «достаточно времени» с момента предыдущего взаимодействия с пользователем?

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

С другой стороны, вы хотите зафиксировать тот факт, что пользователь возвращается на ваш сайт или приложение после его ненадолго (т.е. отдельный экземпляр использования, а не один экземпляр непрерывного использования).

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

Сеанс представляет собой группу взаимодействий, которые происходят в течение заданного временного интервала, и сеанс заканчивается, когда прошел некоторый заданный период таймаута. Например, по умолчанию в Google Analytics сеанс заканчивается, когда есть 30 минут бездействия. Большинство инструментов аналитики дают пользователям возможность настроить количество тайм-аутов сеанса, если они этого захотят.

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

Примечание. Если вы используете autotrackчастности, плагины pageVisibilityTracker и urlChangeTracker), вам не нужно беспокоиться о том, чтобы реализовать эту логику самостоятельно. Эти плагины обрабатывают все это для вас автоматически (с настройками для настройки поведения).

Обработка ложных срабатываний

Когда я был первоначально созданием pageVisibilityTracker плагин для автотрека я сделал много тщательного тестирование различных реализаций отслеживания Page Visibility API на основе, и стало ясно , что эвристики необходимы, чтобы избежать ложных срабатываний.

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

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

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

Просмотры страниц и страниц

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

Хотя вы можете создать настраиваемый параметр для отслеживания этого (и на самом деле я обычно это делаю), эта проблема дает понять, что нам действительно нужны две отдельные метрики: Pageviews и Page Loads.

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

Разделяя просмотры страниц из загрузок страниц, мы можем полностью охватить намерение по метрике Pageviews: измерение того, сколько раз пользователи просматривали вашу страницу независимо от того, сколько раз они ее загружали.

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

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

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

Большинство инструментов аналитики предполагают, что каждый сеанс содержит по крайней мере одно просмотрение страниц, а это просмотр страницы используется для определения таких параметров, как «Целевая страница» и показатели, такие как «Выход». Если вы отслеживаете только просмотр страницы для начальной загрузки страницы, а затем все последующие сеансы просто содержат события, большинство ваших отчетов сеансов будут испорчены.

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

Ограничения в области инструментов в сторону, я по-прежнему думаю, что можно сделать убедительный аргумент, что все сеансы, содержащие пользовательские взаимодействия, должны содержать по крайней мере одно просмотрение страницы. В конце концов, как вы можете взаимодействовать со страницей, которую вы не просматривали? Отправляя новые просмотры страниц, когда состояние видимости изменяется после истечения предыдущего сеанса, вы можете решить эту проблему. [2]

Завершение

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

Инструменты Google Analytics должны измерять взаимодействие пользователей, и их не следует связывать с реализацией сайта. Когда пользовательский опыт улучшится, мы должны быть в состоянии доказать это через наши аналитические отчеты. Это самый простой способ сделать бизнес-кейс для прогресса.

Если вы используете Google Analytics, вы уже можете воспользоваться этими решениями, установив autotrack (который я настоятельно рекомендую, если вы создаете SPA или PWA). Чтобы увидеть рабочий пример настройки autotrack для этой цели, ознакомьтесь с моим аналитическим плагином repo.