Лічильник першої сторони для WordPress

Що таке лічильник першої сторони і чому він добре підходить для WordPress

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

Таке рішення добре підходить видавцям, яким важливі швидкість і контроль. Один запит із вашого сайту, один запис у вашій системі. Без зайвої мережі відстеження. Без громіздкої панелі з 40 вкладками, які ви ніколи не відкриєте.

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

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

Визначте, що саме має відстежувати лічильник

Почніть з однієї цифри. Лише перегляди сторінок? Унікальні відвідування? Авторизовані користувачі? Оберіть найменший обсяг, який відповідає на реальне запитання. Лічильник, що намагається виміряти все, зазвичай не дає чіткої картини ні про що.

Якщо вам потрібні лише перегляди сторінок, налаштування буде простим. Якщо потрібні унікальні відвідування, треба правило для визначення повторних браузерів, а це може вимагати cookies або серверних відбитків. Якщо ви хочете окремо рахувати авторизованих користувачів, пам’ятайте: WordPress уже знає, хто вони, але вашому лічильнику все одно потрібне правило зберігання цієї відмінності.

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

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

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

Оберіть шлях налаштування плагіна аналітики WordPress

Вибір «налаштувати плагін аналітики WordPress» зазвичай зводиться до трьох шляхів: плагін, хук теми або власний фрагмент коду. Усі варіанти робочі. Правильний залежить від того, хто підтримуватиме сайт після запуску.

Плагін — найпростіший варіант для нетехнічних користувачів. Він дає налаштування в wp-admin, і це зручно, коли власник сайту хоче змінювати правила збору даних без редагування файлів. Компроміс — ще один плагін, який потрібно оновлювати. Також варто уважно перевірити, що саме він завантажує на кожній сторінці.

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

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

Для багатьох сайтів плагін — найкращий варіант для першого релізу. Хук теми — найкращий, коли важить мінімум накладних витрат. Власний фрагмент коду — найкращий, коли на сайті вже є розробник, який підтримує розгортання. Ось і вся логіка вибору.

Спочатку встановіть лічильник першої сторони на тестову копію

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

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

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

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

Короткий тест на staging економить час пізніше. Один пропущений підрахунок у день запуску дратує. Десять пропущених підрахунків — це вже погана звітність.

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

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

Розташування скрипта має значення. Скрипт із власної папки assets виглядає акуратніше, ніж вставка ззовні. Якщо у вас плагін, він має підключати скрипт із самого сайту WordPress. Якщо використовуєте власну кінцеву точку, переконайтеся, що вона доступна через HTTPS-сертифікат цього ж сайту.

Правила домену для cookies теж важливі. Cookie, встановлений для кореневого домену, працює інакше, ніж той, що діє лише на www або лише на основному хості. Поведінка піддоменів може здивувати команди, особливо коли блог розміщено на blog.example.com, а головний сайт — на www.example.com. Визначте, де має обліковуватись лічильник, ще до запуску.

Правила шляху мають менше, але теж важливе значення. Лічильник може записувати всі URL або лише шляхи /posts/ та /news/. Якщо у вашому сайті є приватні розділи, переконайтеся, що вони виключені, якщо тільки ви справді не хочете їх рахувати. Одне неправильне правило може зробити підсумки шумними на тижні.

Документуйте всі правила переписування та проксі. Запишіть кінцеву точку, домен cookie та дозволені шляхи в одному місці. Майбутні адміністратори будуть вам вдячні. А ще — ви самі в майбутньому.

Перевірте, чи підрахунок працює правильно

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

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

Звірте панель або збережені записи з фронтендом. Якщо на сторінці написано «1 перегляд», а база даних показує 3 записи, шукайте повторні спроби, префетчі або кешовані повтори. Деякі теми й плагіни WordPress запускають фонові завантаження, які схожі на відвідування. Вони не мають роздувати ваш лічильник, якщо ви цього не хочете.

Корисний тест — послідовність із 5 відвідувань із 2 браузерів. Ви маєте точно знати, скільки рядків або інкрементів очікується. Якщо результат неможливо передбачити, налаштування ще не готове. Ось це і є справжній тест.

Подбайте про згоду, конфіденційність і термін зберігання даних

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

Термін зберігання — це практичне питання, а не розпливчастий рядок у політиці. Визначте, чи залишає лічильник сирі журнали на 7 днів, 30 днів або довше. Якщо вам потрібні лише місячні підсумки, зберігати детальні рядки рік може бути зайвим. Коротший термін також зменшує ризики, якщо буде скомпрометовано обліковий запис адміністратора.

IP-адреси заслуговують на окрему примітку. Деякі лічильники зберігають повні IP-адреси. Інші їх обрізають або хешують. Якщо не впевнені, який саме варіант використовує ваша реалізація, перевірте налаштування плагіна або код перед запуском. Те саме стосується user-agent і session ID.

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

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

Запустіть, відстежуйте та усувайте проблеми з живим лічильником

Переміщайтеся з staging у продакшен лише після успішних тестів. Розгорніть ті самі налаштування, а потім спостерігайте за живим сайтом упродовж перших 24 годин. Порівняйте показники продакшену з тестами на staging, щоб переконатися, що лічильник пережив перенесення. Чистий запуск має дати ту саму поведінку, тільки вже на реальному трафіку.

Слідкуйте за пропущеними підрахунками. Найчастіше вони з’являються через кешування, заблоковані запити або змінене кінцеве посилання. Також перевіряйте дублікати. Вони можуть виникати через оновлення сторінки, попереднє завантаження або скрипт, який спрацьовує двічі. Обидві проблеми настільки поширені, що перевіряти їх варто вже в перший день.

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

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

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