📊 Почему разработчикам решений для Битрикс24 уже недостаточно мониторить только ошибки приложения
Часто мониторинг кастомизаций заканчивается на базовых вопросах.
— Пришёл ли вебхук.
— Упал ли сервер.
— Есть ли ошибки 500.
Но этого уже недостаточно.
Представим ситуацию: пользователь установил приложение, открыл его один раз и больше никогда не вернулся.
С технической точки зрения всё работает идеально. Но само решение при этом не приносит ценности.
🔹 Технический мониторинг отвечает на вопрос: «Работает ли приложение?»
Здесь всё привычно:
— ошибки и сбои вебхуков;
— время ответа API;
— состояние внешних зависимостей;
— производительность отдельных сервисов.
🔹 Продуктовый мониторинг отвечает уже на другой вопрос: «Пользуются ли приложением?»
Например:
— пользователь установил приложение;
— открыл чат с ботом;
— написал первое сообщение;
— воспользовался конкретной функцией;
— получил первый полезный результат;
— вернулся повторно.
Ещё несколько полезных идей из статьи.
✅ Не нужно хранить сырой текст пользовательских сообщений.
Для аналитики зачастую достаточно безопасных признаков: команды, количества аргументов и длины сообщения.
✅ Стоит отдельно измерять каждый внешний API-вызов.
Тогда становится понятно, где именно возникла проблема: внутри приложения, в Битрикс24 или во внешнем сервисе.
✅ Воронки в Grafana начинают показывать не только техническое здоровье решения, но и реальное поведение пользователей.
Кажется, именно такой подход постепенно становится следующим этапом развития кастомизаций для Битрикс24.
📖 Статья на Хабре
#Разработка #Маркетплейс #PHP #OpenTelemetry #Grafana #ClickHouse #DevOps
Часто мониторинг кастомизаций заканчивается на базовых вопросах.
— Пришёл ли вебхук.
— Упал ли сервер.
— Есть ли ошибки 500.
Но этого уже недостаточно.
Представим ситуацию: пользователь установил приложение, открыл его один раз и больше никогда не вернулся.
С технической точки зрения всё работает идеально. Но само решение при этом не приносит ценности.
Именно поэтому вместе с техническим мониторингом появляется второй уровень – продуктовый мониторинг.
🔹 Технический мониторинг отвечает на вопрос: «Работает ли приложение?»
Здесь всё привычно:
— ошибки и сбои вебхуков;
— время ответа API;
— состояние внешних зависимостей;
— производительность отдельных сервисов.
🔹 Продуктовый мониторинг отвечает уже на другой вопрос: «Пользуются ли приложением?»
Например:
— пользователь установил приложение;
— открыл чат с ботом;
— написал первое сообщение;
— воспользовался конкретной функцией;
— получил первый полезный результат;
— вернулся повторно.
Самое интересное начинается, когда эти два уровня объединяются.
Например, вы видите, что пользователи устанавливают приложение, но не возвращаются к нему повторно.
Тогда можно быстро проверить: проблема в самом сценарии использования или где-то по пути ломается пользовательский опыт.
Ещё несколько полезных идей из статьи.
✅ Не нужно хранить сырой текст пользовательских сообщений.
Для аналитики зачастую достаточно безопасных признаков: команды, количества аргументов и длины сообщения.
✅ Стоит отдельно измерять каждый внешний API-вызов.
Тогда становится понятно, где именно возникла проблема: внутри приложения, в Битрикс24 или во внешнем сервисе.
✅ Воронки в Grafana начинают показывать не только техническое здоровье решения, но и реальное поведение пользователей.
Кажется, именно такой подход постепенно становится следующим этапом развития кастомизаций для Битрикс24.
Недостаточно просто сделать работающее приложение. Важно понимать, получают ли пользователи от него ценность.
📖 Статья на Хабре
#Разработка #Маркетплейс #PHP #OpenTelemetry #Grafana #ClickHouse #DevOps