Побудувала власну продуктову аналітику в PostgreSQL — 47 функцій над партиціонованими таблицями подій, які самі себе очищають, — псевдонімізовану за ротаційною сіллю та обумовлену згодою відвідувача.

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

Завдання. Продуктовій команді потрібні були воронки, retention і дані про події, зібрані у спосіб, за який платформі не соромно й від якого користувач може відмовитися.

Дія. Аналітика оселилася в PostgreSQL — у схемі з 7 таблиць і 47 функцій. Таблиці подій партиціоновані — 22 визначення партицій — і самі себе очищають за розкладом, бо ціна власної аналітики не в тому, щоб зібрати події, а в тому, щоб зберігати їх вічно. Ідентичність псевдонімізовано за ротаційною сіллю, тож відвідувача не можна простежити через межу ротації навіть зсередини бази даних; це свідомо встановлена стеля для того, на що ці дані взагалі здатні відповісти. Клієнт знає про стан згоди й не надсилає нічого, доки згоду не дано, замість надсилати, а потім фільтрувати. Воронки конверсії обчислюються в базі даних, поруч із самими даними, а не експортуються кудись назовні, щоб потім бути приєднаними назад.

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