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