Що показує статистика без cookie — і чого вона не покаже
Лічильник переглядів — маленьке чесне число. Воно каже, що запит надійшов, приблизно звідки, і більше нічого. Розчарування в аналітиці майже завжди починається там, де від неї чекають продовження фрази, якого ніколи не було.
Чому звичні цифри для посилання в біо брешуть
Клієнтська аналітика впізнає відвідувача, який повернувся, за міткою в браузері: cookie, записом у local storage, ідентифікатором в IndexedDB. Для звичайного сайту, який відкривають у Chrome з ноутбука, це працює стерпно. Для сторінки-посилання в біо — погано, бо її майже завжди відкривають усередині чужого застосунку.
Instagram і TikTok показують посилання у вбудованому WebView. Він має власне сховище, окреме від системного браузера, і живе воно недовго. Та сама людина, яка натиснула те саме посилання у вівторок і в четвер, обидва рази приходить із порожнім сховищем. Інструмент малює двох нових відвідувачів і при цьому не бреше — дізнатися інакше він просто не може.
Тому співвідношення нових і тих, хто повернувся, на такій сторінці — величина беззмістовна. Загальний трафік теж занижується: блокувальники на iOS працюють і всередині WebView, а частина вбудованих браузерів затримує сторонні скрипти так надовго, що відвідувач встигає піти раніше, ніж лічильник спрацює.
Що бачить серверний підрахунок
Рахувати на сервері — означає зафіксувати запит, що надійшов, ще до того, як відпрацює бодай один скрипт. Рахує сама сторінка, тож блокувати нічого і завантажувати нічого. Натомість ви отримуєте число, яке є завжди, і втрачаєте подробиці.
| Cookie-аналітика | Серверний підрахунок | |
|---|---|---|
| Візит був | Так, якщо скрипт відпрацював | Так, завжди |
| Приблизна географія | Так | Так, за адресою |
| Тип пристрою | Так | Так, із запиту |
| Та сама людина завтра | У теорії; але не в WebView | Ні, навмисно |
| Яке посилання натиснули | Так, якщо налаштовано | Лише через редирект |
| Куди пішов далі | Інколи | Ні |
| Поведінка на інших сайтах | Зі сторонніми даними | Ні |
Останній стовпець короткий навмисно. Серверний підрахунок знає, що запит надійшов, приблизно з якої країни та міста і з якого класу пристрою. Він не знає, хто ви, що ви робили далі й що відбувалося в решті вашого браузера.
Хеш, який живе одну добу
Унікальних відвідувачів усе одно треба якось розрізняти. Без cookie це роблять так: беруть адресу відвідувача, домішують секрет, який змінюється опівночі, рахують хеш і зберігають лише його. У tapmy.link сіль змінюється о київській півночі, а рядки видаляються через дев’яносто днів.
Усередині однієї доби два запити з однієї адреси дають однаковий хеш і рахуються як один відвідувач. Наступного дня та сама адреса дає зовсім інший хеш, ніяк не пов’язаний із учорашнім. Зі збереженого неможливо відновити адресу, і ніщо не пов’язує людину з нею ж через межу доби.
Це справжнє обмеження, а не примітка дрібним шрифтом. Не можна спитати, скільки відвідувачів понеділка повернулися в п’ятницю: даних для відповіді свідомо не існує. Унікальні за тридцять днів — це сума денних унікальних, а не тридцять днів спостереження за тими самими людьми.
Єдине місце, де натискання можна порахувати
З усього цього є один виняток, і береться він із будови вебу, а не з хитрощів. Посилання, яке веде просто до мети, спостерігати себе не дає: браузер іде за адресою з коду сторінки, і до нас запит не доходить узагалі. Посилання з власною короткою адресою — mia.tapmy.link/shop — веде спершу до нас, і так само поводиться те, що відправляє iPhone до App Store, а Android — до Google Play. На обидва ми відповідаємо редиректом. Відповідь на запит і є той самий момент, коли натискання можна порахувати.
Тому коротке посилання рахується так само, як перегляд сторінки: на сервері, до будь-яких скриптів, без cookie, під тією ж сіллю, що змінюється опівночі, і з тим самим зберіганням у дев’яносто днів. Заради цього на сторінку нічого не додається — ні маячка, ні обробника натискання, нічого, що зламається з вимкненими скриптами. Якщо на сторінці ввімкнено UTM-розмітку, мітки їдуть разом із відвідувачем і читає їх аналітика того, куди він прийшов, а не наша; мітку, яку ви проставили вручну, ми не чіпаємо.
Це вибір, який роблять окремо для кожного посилання, і він не безкоштовний. Посилання, яке й далі веде просто до мети, зберігає цю адресу в коді сторінки, тому працює, хай би що сталося з нами, — і не рахується зовсім. Скорочення міняє цю прямоту на число. Зазвичай коротких посилань на сторінці виявляється два-три — ті, від яких щось залежить, — а решта лишаються як були.
Банер, якого не потрібно
Правила згоди в Європі зазвичай прив’язані до того, що записують на пристрій відвідувача або читають із нього, а не до аналітики як заняття. Сторінці, яка не ставить cookie і нічого не пише у сховище, просто нема про що питати. Звідси й різниця: одні сайти зустрічають банером, інші чесно обходяться без нього.
Звідси ж невелика асиметрія. Панелі керування cookie сесії необхідний: без нього вхід неможливий. Публічній сторінці, яку бачить відвідувач, не потрібен жоден, і вона його не ставить.
Як читати те число, яке у вас є
Перегляди й унікальні відвідувачі за сім і тридцять днів відповідають на меншу кількість питань, ніж від них чекають, — зате на ці небагато відповідають добре. Уся дисципліна в тому, щоб ставити лише їх.
- Порівнюйте тижні, а не дні: вівторок — не середа, а в одному дні надто мало трафіку, щоб він щось означав.
- Сплеск — це питання, а не відповідь. Щось сталося: відео зайшло, хтось поділився дописом. Число каже коли, решту ви знаєте самі.
- Дивіться на співвідношення переглядів до унікальних. Переглядів значно більше — люди повертаються протягом дня; приблизно порівну — заходять по разу.
- Ніколи не читайте перегляд як клік: рахуються приходи на сторінку, а не натискання на посилання всередині неї.
- Записуйте, що і коли ви змінювали. Статистика без переліку власних дій — просто лінія на графіку.
Яке саме посилання натиснули, лічильник переглядів не скаже ніколи: це інший вимір, і тут він є лише там, де посиланню дали власну коротку адресу. Розуміти, де проходить межа, корисніше, ніж вдавати, що число багатше, ніж воно є.