Когда речь о трекинге, часто спорят не о том, что считать, а о том, где держать логику.

Когда речь о трекинге, часто спорят не о том, что считать, а о том, где держать логику.

Подход 1 — всё собирать на стороне аналитики: события летят «сырыми», а правила применяются уже в дашбордах и отчетах. Плюс — гибкость и быстрые изменения. Минус — риск получить зоопарк метрик, если разные команды трактуют одно и то же событие по-разному.

Подход 2 — максимально обогащать данные еще на этапе трекинга: заранее задавать статусы, типы пользователей, источники, валидации. Плюс — чище данные и меньше ручной магии в отчетах. Минус — выше цена ошибки: если заложили неверную логику, она разъедется сразу везде.

Практика обычно посередине: критичные поля фиксируем в трекинге, а бизнес-правила оставляем в аналитике. Так проще масштабироваться и не ломать систему при каждом новом вопросе 📊