TGViewer
Сказки технического менеджера Сказки технического менеджера @tech_managers_tales · 447 subscribers
Post #55 363
Темная сторона data driven подхода

Сейчас модно быть data driven чуваками. Кто забыл - data driven это когда решения принимаются на основе данных. Юзеры часто заходят в этот раздел, значит качаем в первую очередь его, цвет Важной Кнопки не меняем пока не проведем А/Б-тест и не наберём статзначимый объем трафика. Этот подход имеет плюсы и минусы. Среди плюсов хотел бы отметить, что он снижает долю субъективщины, поскольку данные показывают сухие факты - решения на их основе меньше зависят от личного мнения. Оставим пока за скобками то, что данными можно успешно манипулировать:)

А вот о чем я хотел написать, так это о темной стороне всей этой data driven вечеринки - огромный объем совершенно никому не нужных данных. Аналитики покрывают событиями каждый чих пользователя "чтоб было" - а потом забывают про эти события через неделю, потому что есть другие важные задачи. Разработчики подключают сторонние SDK, которые помимо прочего, отливают куча информации производителю бесплатного SDK - масштаб бездумного сбора данных множится.

А ведь сбор любых данных несёт в себе вполне явные накладные расходы:
- на стороне клиента они стоят времени процессора (для сбора), пространства на диске (для буферизации) и интернет-трафика (для отправки), что в конечном итоге негативно влияет на перфоманс клиентской части
- на стороне сервера на порядок больше CPU, памяти и трафика для обработки данных, полученных с клиентов
- на стороне хранилища все тоже самое, только ещё и диски для хранения. Ой, вам еще и репликация нужна? Тогда умножаем объем данных на N.
- это уже не говоря о том, что все это нужно грамотно спроектировать, разработать и поддерживать, на что нужно время недешевых инженеров.
Таким образом, компании сливают кучу времени людей и денег на сбор и хранение бесполезных данных. Сам видел.

Что делать?
1. Проверить свой продукт - а не отливаем мы прямо сейчас кучу аналитики, которая нам нафиг не нужна? Вдруг мы так впустую тратим ресурсы клиента и компании?
2. При разработке новых фич учитывать аналитику минимально необходимого набора действий. Нет, не надо логировать отдельно нажатие на дропдаун и отдельно выбор варианта - достаточно затрекать параметры всей формы.

В общем, желаю всем подходить к аналитике более осознанно.
  • 👍 11
  • ❤ 2
  • 💯 1
More from @tech_managers_tales
  1. Sep 16, 2026Готовлюсь сейчас к выступлению на Yandex Scale с провокационной темой доклада - "Мониторин…
  2. Aug 30, 2026Про личный опыт с Hermes Когда я прогуливаюсь вечерами и не только, у меня частенько возни…
  3. Aug 10, 2026Про еще один важный запуск Ой, совсем забыл поделиться, что с месяц назад был важный для м…
  4. Jul 20, 2026Саммари доклада с Infraconf 2026. Часть 2 про практику Продолжаю саммари доклада — теперь…
  5. Jul 2, 2026Саммари доклада с Infraconf 2026 Как обещал, публикую краткое содержание своего доклада "О…
  6. Jun 22, 2026Запись доклада с Infraconf 2026 Finally, готова запись моего доклада "Особенности observab…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →