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

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

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

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

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