Большинство команд смотрят на error rate как на единственную правду. Это удобно — и почти всегда недостаточно.

Большинство команд смотрят на error rate как на единственную правду. Это удобно — и почти всегда недостаточно.

Стек-трейс отвечает на вопрос «где упало». Breadcrumbs — на более важный: «почему пользователь вообще дошёл до падения». Это не украшение к багрепорту, а контекст, без которого ошибка превращается в догадку.

Пример: упал checkout. В отчёте видно только исключение в payment step. Но breadcrumbs показывают:
— пользователь 3 раза менял адрес;
— дважды получил 422 на валидации;
— перед ошибкой был повторный submit;
— сеть дала таймаут на запросе.

И вот уже проблема не в «сломанной кнопке», а в сценарии, который ломается на стыке UX, API и повторных действий. 🔍

Для growth-команды это особенно важно: один и тот же баг может бить по разным метрикам по-разному. Где-то падает активация, где-то — конверсия в оплату, где-то — retention у новых когорт. Без цепочки событий вы лечите симптомы, а не узкое место.

Breadcrumbs не заменяют логи, но сокращают время до причины. А в продуктовой аналитике это часто дешевле, чем ещё один алерт.