# Виміряла тринадцять адрес лише за власним журналом доступу вебсервера — без кукі, без трекерів і без сторонніх сервісів — маскуючи мережу клієнта в момент запису рядка та згортаючи результат у постійний архів із 21 денного показника та 20 місячних фасетів. вересень 2026 **Ситуація.** Сайт не мав жодного способу дізнатися, чи його хтось читає. Кожне звичне розв'язання цієї задачі чогось коштує читачеві — кукі, скрипт, піксель, стороння служба, яка мимохідь дізнається про відвідувача, — і від кожного з них відмовилися ще до того, як було написано перший рядок цієї роботи. Залишався власний журнал доступу вебсервера — єдиний запис, який існує в будь‑якому разі, бо на запит треба відповісти. **Завдання.** Питання полягало в тому, чи можна отримати корисні відомості про читацьку аудиторію з рядка журналу, з якого вже вилучено ідентифікаційні дані, і чи можна це вилучення довести, а не лише пообіцяти. **Дія.** Маскування відбувається в момент запису рядка, а не під час окремого очищення згодом, бо обіцянку не зберігати щось порушено вже тоді, коли це збережено, навіть якщо згодом прибрати. Сервер формує адресу клієнта під двома назвами, і замасковано обидві — якщо замаскувати лише одну, конфігурація має правильний вигляд, а повна адреса тим часом лежить на диску під іншою, і виявила це лише перевірка на живому сервері. Сім заголовків із переадресованими адресами відкидаються повністю, бо кодувальник записує мапу заголовків саме так, як її надіслав клієнт, і відвідувач за корпоративним проксі інакше заніс би власну повну адресу у файл під назвою, на яку жодна маска не зважала. Заголовок кукі, заголовок авторизації та ефемерний порт джерела відкидаються так само, а рядки запиту обрізаються ще до того, як будь‑що прочитає шлях, тож ні слова, які хтось набрав у пошуковій системі, ні слова, набрані в пошуковому полі самого сайту, не можуть потрапити в жоден файл. Збір працює за принципом витягування (pull): скрипт, що використовує лише стандартну бібліотеку, у потоковому режимі читає поточний журнал і його файли після ротації на хості й виводить лічильники, а не рядки, причому скрипт обмежений кількістю різних шляхів, а не розміром журналу, бо машина має 464 МБ. Для зберігання знадобилося два механізми, а не один, після того як з'ясувалося, що ліміт за розміром і ліміт за часом для одного сховища означають, що непомітно перемагає менший — жвавий сайт зберігав десять днів замість тридцяти, а тихий не видаляв узагалі нічого. Після журналу лишається архів: 21 лічильник на день і 20 фасетів на місяць, які зливаються, а не дописуються, за правилом, що вікно спостереження може лише недорахувати, і поряд із кожним рейтингом зберігається загальна сума, щоб урізана таблиця показувала, скільки вона відкинула. **Результат.** Так вимірюються тринадцять адрес, і сайт не використовує ні кукі, ні трекерів, ні сторонніх запитів, тож немає на що давати згоду й немає де виконатися тегу. Ця схема частіше відмовляє у відповіді, ніж відповідає — унікальні відвідувачі, пошукові запити, шлях відвідувача сайтом, час на сторінці, кліки, географія та пристрій тут недоступні, і про це прямо сказано, — а обмеження виводяться поряд із числами, а не ховаються у виносках, бо грубе число, прочитане як точне, гірше, ніж його відсутність. --- - Роль: Інженер з надійності (SRE) - Категорії: [Управління даними](https://data.engineer.company/uk/categories/data-governance/), [Інфраструктура](https://data.engineer.company/uk/categories/infrastructure/), [Автоматизація та CI/CD](https://data.engineer.company/uk/categories/automation/), [Моніторинг і спостережуваність](https://data.engineer.company/uk/categories/observability/), [Безпека](https://data.engineer.company/uk/categories/security/), [Python](https://data.engineer.company/uk/categories/python/) - Послуги: [Data Governance та якість даних](https://data.engineer.company/uk/services/data-governance/), [Надійність та моніторинг (SRE)](https://data.engineer.company/uk/services/site-reliability/), [Безпека та керування доступом](https://data.engineer.company/uk/services/security-access/)