Як ми відстежуємо перегляди сторінок

Оригінал: philipwalton.com 

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

Здебільшого ці інструменти передбачають (за замовчуванням), що кожен перегляд сторінки відповідає повному завантаженню сторінки, і що кожне завантаження сторінки запускає певний код відстеження аналітики та надсилає перегляд сторінки на внутрішній сервер. Все, що відхиляється від цієї моделі, вимагає додаткової роботи з боку розробника сайту, а більшість з розробників не мають на це часу чи досвіду.

Реальність полягає в тому, що Інтернет сильно змінився за останні 10-15 років, і все більше вебсайтів не відповідають цій традиційній моделі. Наші інструменти аналітики відстають.

Проблема

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

Переважна більшість користувачів Gmail майже ніколи не перезавантажує сторінку, що викликає кілька важливих питань з точки зору аналітики:

  • Якщо користувач завантажує Gmail один раз, а потім використовує його сотні разів протягом наступних кількох днів без перезавантаження, чи справді це слід вважати лише одним переглядом сторінки?
  • Якщо користувач натискає логотип для оновлення вмісту (або за допомогою “протягування” для оновлення в мобільній версії програми), чи слід це вважати переглядом сторінки? Чи це використання функціонально відрізняється від оновлення сторінки для завантаження нового вмісту?
  • Як щодо того, коли користувач відкриває нове повідомлення, чи слід це вважати новим переглядом сторінки?
  • Якщо два користувачі відвідують Gmail однакову кількість разів на день, але один з них кожен раз завантажує сайт заново, а інший залишає його відкритим у фоновій вкладці, чи повинні ці два способи використання мати різко відрізнятися за кількістю переглядів сторінки?

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

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

На жаль, у наведеному вище сценарії кількість переглядів сторінки напевно зменшиться під час внесення цих змін, хоча ви покращуєте зручність використання.

Це досить неприємна ситуація: де ви (розробник) хочете вдосконалити UX сайту, але ви не можете переконати когось, що це варто робити, оскільки аналітика доводить протилежне.

Рішення

Я думаю, що рішення є, і рішення, яке я пропоную, бере підказку з самої назви метрики: Pageviews (Перегляди сторінок).

Замість того, щоб відстежувати, скільки разів сторінка завантажувалася, відстежуйте, скільки разів її переглядали. Можна зробити це за допомогою API видимості сторінок, що насправді існує вже досить давно і добре підтримується у всіх браузерах, як на ПК, так і на мобільному пристрої.

Як виявляється, відстеження того, як часто сторінку переглядали, а не як часто її завантажували, досконало обробляє вражаючу кількість випадків, які не працюють з поточною моделлю:

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

API видимості сторінки містить як властивості document.visibilityState, так і  події visibilitychange. За допомогою цих двох фрагментів ви можете переконатись, що перегляди сторінок ніколи не надсилаються, якщо не відображається visibilityState сторінки, а також надсилаються, коли користувач повертається на ваш сайт після того, як він деякий час перебуває на фоновій вкладці, очікуючи події visibilitychange. API Visibility Page розв’язує проблему, як відстежувати перегляди сторінок у програмах, які ніколи не потребують перезавантаження.

Другою частиною рішення є History API, який (тепер, коли підтримується у всіх браузерах) є де-факто способом створення SPA розробниками. Як результат, інструменти аналітики можуть обліковувати зміни URL-адреси та надсилати перегляди сторінок, коли це трапляється. Це дозволяє відстежувати SPA-об’єкти так само, як і традиційні сайти.

Технічні деталі

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

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

Третій крок вище – найважливіший, і він також є найбільш неоднозначним. Питання: скільки часу було б “достатньо” з моменту попередньої взаємодії з користувачем?

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

З іншого боку, ви хочете зафіксувати той факт, що користувач повертається на ваш сайт або додаток після того, як деякий час не використовував його (тобто окремий екземпляр використання, а не один, безперервний екземпляр використання).

На щастя, усі інструменти аналітики вже визначають спосіб розрізнення різних екземплярів використання, вони називаються сесіями.

Сесія – це група взаємодій, що відбуваються протягом заданого проміжку часу, і вона закінчується, коли пройшов якийсь заздалегідь визначений період очікування. Наприклад, за замовчуванням у Google Analytics сесія закінчується, коли проходить 30 хвилин бездіяльності. Більшість інструментів аналітики дають користувачам можливість налаштувати кількість часу очікування сесії, якщо вони цього хочуть.

Тож повертаючись до третього кроку у наведеному вище списку, моя пропозиція полягає в тому, що якщо сесія користувача закінчилася, а стан видимості сторінки змінився із прихованого на видимий, слід надіслати новий перегляд сторінки. Зміни стану видимості, що відбуваються в середині сесії, не слід вважати окремими переглядами сторінок (хоча їх все одно можна відстежувати як події, якщо ця інформація є релевантною).

Примітка: якщо ви використовуєте автотрек (зокрема плагіни pageVisibilityTracker та urlChangeTracker), вам не доведеться турбуватися про те, щоб реалізувати цю логіку самостійно. Ці плагіни обробляють все це автоматично (з опціями конфігурації для налаштування поведінки).

Обробка помилкових спрацьовувань

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

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

Під час мого тестування значна частина переглядів сторінок, які виникли внаслідок зміни стану видимості на видимий після тайм-ауту сесії, супроводжувалися подальшою зміною стану видимості назад на приховану протягом декількох секунд після початкової зміни. Більше ніж у 99% нових сесій, що містили лише цей єдиний перегляд сторінки, повернення до прихованого відбулося протягом п’яти секунд після вихідної зміни до видимої.

Це має сенс, оскільки я знаю із власних схем використання, що досить часто випадково переходити на вкладку лише для негайного виходу, переходити на вкладку лише тому, що вона перебуває на іншій вкладці, на яку я насправді намагаюся перейти, або перейти на вкладку, щоб просто закрити її. У всіх цих випадках немає сенсу ініціювати черговий перегляд сторінки (що також ініціюватиме нову сесію), а додавання п’яти секундного тайм-ауту запобігає понад 99% цих помилкових спрацьовувань.

Перегляди сторінок vs Завантаження сторінок

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

Хоча ви можете створити спеціальний вимір для відстеження цього (а я зазвичай це роблю), ця проблема дає зрозуміти, що насправді нам потрібні дві окремі метрики: Перегляди Сторінок та Завантаження Сторінок.

На щастя, більшість інструментів аналітики сьогодні дозволяють користувачам визначати власні метрики для відстеження будь-яких даних за бажанням. Функція автоматичного відстеження вже має можливість відстежувати завантаження сторінок окремо від переглядів сторінок за допомогою спеціальної метрики.

Від’єднавши перегляди сторінки від завантажень сторінки, ми можемо повністю зрозуміти ціль, що лежить в основі метрики Перегляду Сторінок: виміряти, скільки разів користувачі фактично переглядали вашу сторінку, незалежно від того, скільки разів вони її завантажили.

Як перегляди сторінок впливають на сесії

Деякі читачі можуть запитати, чому все це важливо. Яка різниця, якщо відстежувати лише початкове завантаження сторінки? Якщо відстежувати відповідні взаємодії користувачів після початкового завантаження сторінки, чому має значення, називати це переглядом сторінки або ні?

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

Більшість інструментів аналітики припускають, що кожна сесія містить принаймні один перегляд сторінки, і що перегляд сторінки використовується для визначення таких вимірів, як Цільова Сторінка, та таких показників, як Виходи. Якщо ви відстежуєте лише перегляд сторінки для початкового завантаження сторінки, а потім усі наступні сесії просто містять події, більшість звітів про ваші сесії будуть зіпсовані.

Сьогодні це трапляється майже з усіма вебпрограмами, які використовують традиційну аналітику, і це додатково ілюструє обмеженість старої моделі.

Якщо не брати до уваги обмеженість інструментів, я все ще вважаю вагомим аргументом, що всі сесії, які містять взаємодію користувачів, повинні містити принаймні один перегляд сторінки. Зрештою, як можна взаємодіяти зі сторінкою, яку ви не переглядали? Надсилаючи нові перегляди сторінок, коли стан видимості змінюється після закінчення попередньої сесії, ви можете розв’язати цю проблему. [2]

Підведення підсумків

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

Інструменти аналітики повинні вимірювати залучення користувачів і не повинні поєднуватися із реалізацією сайту. Коли покращується взаємодія з користувачами, ми маємо змогу довести це за допомогою аналітичних звітів. Це найпростіший спосіб досягти прогресу.

Якщо ви використовуєте Google Analytics, ви вже можете скористатися цими рішеннями, встановивши функцію автоматичного відстеження (що я наполегливо рекомендую, якщо ви створюєте SPA або PWA). Щоб побачити приклад, як налаштувати автоматичне відстеження для цієї мети, перегляньте мій звіт analyticsjs-boilerplate.

Примітки:
  1. Крім видимого та прихованого стану видимості, існує також попередній перегляд, який трапляється, якщо браузер завантажує сторінку у фоновому режимі в очікуванні ймовірного відвідування. Перегляд сторінки в цьому випадку точно не варто відстежувати.
  2. Єдина ситуація, коли сесія не буде включати перегляд сторінки, це якщо вона містить лише події, що не стосуються взаємодії (наприклад, вона була завантажена у фоновій вкладці та ніколи не переглядалась).