Регистрации и заявки
Считаем нужные события GetCourse, а не весь технический поток действий пользователя.
Когда обучение, заявки и оплаты живут в GetCourse, а менеджеры работают в CRM, руководителю трудно получить единую картину. Собираем согласованные показатели из двух контуров и показываем их в одном отчёте без ручной склейки таблиц.
Задача
Показатель имеет смысл только тогда, когда понятно, из каких данных он считается и как связывается один клиент между системами.
Считаем нужные события GetCourse, а не весь технический поток действий пользователя.
Отделяем созданный заказ от фактически оплаченного и учитываем согласованный момент признания оплаты.
Добавляем контекст продаж: этап сделки, ответственный, причины отказа и дальнейшие действия.
Связываем маркетинговый источник с дальнейшим движением клиента, если исходные данные позволяют это сделать надёжно.
Срезы по сотрудникам строятся по одинаковым формулам и периодам.
При необходимости отделяем первую покупку от последующих заказов и возвращений клиента.
Методика
До визуализации фиксируем, что считается заявкой, оплатой, конверсией, источником и периодом.
Какие решения должен принимать руководитель.
Где находится первичный факт для каждого показателя.
Как сопоставляется один человек между GetCourse и CRM.
Дата события, возвраты, дубли и повторные заказы.
Проверяем итог на конкретных клиентах и операциях.
Что можно вывести
Набор блоков зависит от доступных данных и реальных вопросов бизнеса.
Регистрация → заявка → заказ → оплата → дальнейшая работа.
Оплаты и выручка по периодам, продуктам или менеджерам.
Конверсии по каналам при корректно сохранённых исходных метках.
Продукты, группы клиентов, типы заказов и другие согласованные признаки.
Границы
Если показатель рассчитывается однозначно, используем обычные формулы и код. ИИ подключаем только там, где нужно понимать текст, разговор или другие сложные данные.
Считается обычной аналитикой и проверяется до исходной записи.
Можно дополнительно классифицировать ИИ, если это даёт практическую пользу.
Могут дополнять отчёт отдельными признаками, которые ИИ выделяет по заданным правилам.
Стараемся убрать из постоянной цепочки, если данные уже есть в системах.
Связанные направления
Если данные появляются несистемно, сначала имеет смысл исправить сам обмен и только потом строить отчёт.
Смотреть также
Отдельно можно настроить передачу событий GetCourse в CRM, общую аналитику, дашборды и KPI.
Вопросы
Для небольшой задачи иногда достаточно прямых API-запросов и локального кэша. Для регулярной аналитики по большому периоду обычно надёжнее хранить нормализованную историю отдельно.
Да, если в процессе есть надёжное правило сопоставления клиента и ответственного. Его нужно зафиксировать до расчёта показателя.
Можно, если метки или идентификаторы источника стабильно сохраняются на входе. Если исходные данные потеряны, корректно восстановить источник задним числом не всегда возможно.
Не для обычных числовых показателей. ИИ полезен там, где нужно разобрать текст, разговор или другие данные, которые нельзя свести к простой формуле.
Покажите текущий отчёт или таблицу и источники данных. Разберём формулы и предложим схему, в которой показатели обновляются без ручной склейки.