Какие решения нужно назвать первыми
Прежде чем команда открывает конструктор дашбордов, стоит ответить на один простой вопрос: кто и какое решение будет принимать, глядя на этот экран. Аудит аналитики онлайн-школы начинается именно с этого, а не с перечня таблиц и интеграций.
На практике решения в онлайн-школе делятся на несколько уровней. Руководителю отдела продаж нужно понимать, сколько заявок доходит до оплаты и на каком этапе воронка проседает. Маркетологу важно видеть, какой канал и какая кампания приводят учеников, которые реально доходят до покупки, а не просто оставляют заявку. Методисту или руководителю учебной части нужны данные о том, кто бросает курс на середине и почему. Собственнику интересна общая картина: сходится ли реклама с продажами и устойчив ли поток новых учеников месяц к месяцу.
Если список решений не сформулирован заранее, аудит рискует превратиться в сбор всего, что технически можно вытащить из систем. В итоге дашборд получается перегруженным, а главный вопрос — ради чего он нужен — остаётся без ответа. Поэтому первый шаг аудита — короткое интервью с ключевыми людьми: что они хотят понять, как часто им нужен ответ и что они будут делать, если цифра окажется плохой. Если на последний вопрос нет ответа, скорее всего, показатель не нужен на главном экране, даже если его легко посчитать.
Полезно сразу разделить решения по горизонту. Одни принимаются ежедневно — например, кому из менеджеров перераспределить заявки. Другие — раз в месяц, когда оценивают эффективность рекламных каналов и окупаемость курсов. Третьи — несколько раз в год, когда пересматривают линейку продуктов или решают, стоит ли открывать новое направление. Разные горизонты требуют разной детализации данных: ежедневному решению нужны почти свежие цифры за сутки, а квартальному вполне достаточно сводки раз в месяц. Смешивать эти горизонты в одном отчёте почти всегда неудобно, потому что человек либо тонет в деталях, либо не находит нужную глубину.
Какие события уже фиксируются
Когда понятно, какие решения важны, следующий шаг — честно посмотреть, что система уже умеет записывать, а что существует только в головах сотрудников. В онлайн-школе события обычно живут в нескольких системах одновременно: на сайте или в лендинге, в рекламных кабинетах, в CRM, в платформе для обучения и иногда в отдельных таблицах у бухгалтера или методиста.
Сайт или форма записи фиксирует визит и заявку. Рекламный кабинет знает показы, клики и расход. CRM хранит статус сделки: взяли в работу, назначили созвон, выставили счёт, получили оплату. Платформа обучения видит, кто зашёл в курс, какой урок прошёл, где застрял. На бумаге это выглядит как полноценная цепочка, но на деле части этой цепочки часто записаны по-разному или не записаны вовсе.
Типичная проблема — событие «оплата» существует в CRM как смена статуса сделки, а в бухгалтерской таблице как факт поступления денег, и эти две записи не всегда происходят в одно время и не всегда совпадают по сумме. Другая ситуация: заявка с сайта фиксируется, но дальше, если менеджер забыл обновить статус в CRM, в системе остаётся старое значение, хотя по факту ученик уже отказался или, наоборот, оплатил напрямую.
Отдельно стоит проверить события внутри обучения: начал курс, прошёл первый модуль, не заходил неделю, закончил курс, оставил отзыв. Эти данные особенно ценны для школ, потому что показывают не только продажу, но и то, получает ли ученик результат, за который платил. Если платформа обучения не передаёт такие события никуда за свои пределы, их просто нет для аналитики, даже если внутри интерфейса преподаватель эту картину видит.
Полезно также заметить разницу между событием и его интерпретацией. «Ученик открыл урок» — это событие. «Ученик усвоил материал» — уже интерпретация, которую одно событие само по себе не подтверждает. Если команда путает эти два уровня, в будущем дашборде появляются показатели, которые звучат убедительно, но не выдерживают проверки простым вопросом «а что именно здесь посчитано».
Практический итог этого этапа — таблица: какое событие нужно для решений из первого раздела, фиксируется оно сейчас или нет, и если фиксируется, то где именно и насколько надёжно. Там же обычно становится ясно, что часть нужных событий сейчас либо не записывается, либо записывается только человеком вручную.
Где теряются идентификаторы клиента
Идентификатор клиента — это то, что связывает запись о рекламном клике, заявку в CRM и факт оплаты в одного и того же человека. Если такой связки нет, аналитика умеет считать отдельные числа, но не умеет отвечать на вопрос, какая реклама привела к деньгам.
В онлайн-школах разрыв идентификаторов случается в нескольких предсказуемых местах. Первое — переход между каналами. Человек увидел рекламу в одной соцсети, а записался через форму на сайте или написал в мессенджер напрямую; рекламный кабинет и CRM в этот момент видят разных «людей», хотя это один и тот же ученик. Второе — ручной ввод номера телефона или почты с ошибкой: лишняя цифра, другой регистр, случайный пробел превращают одного клиента в два профиля. Третье — оплата через другую площадку или напрямую на карту, минуя CRM; в этом случае деньги есть, а связи с заявкой и с рекламным источником нет вообще.
Отдельная история — повторные покупки. Ученик прошёл один курс, а через полгода купил другой. Если идентификатор не сохраняется между сделками, система видит два разных события вместо истории одного клиента, и аналитика не может показать, какие ученики возвращаются и за счёт чего держится повторная выручка.
Похожая ситуация возникает с рассрочками и частичной оплатой, которые в онлайн-школах встречаются часто. Если каждый платёж по рассрочке попадает в систему как отдельная запись без привязки к общей сделке, легко посчитать выручку с ошибкой: либо задвоить сумму, либо, наоборот, не увидеть ученика, который платит исправно, но мелкими частями.
Проверка на этом этапе довольна конкретна: берётся несколько реальных сделок за последние месяцы и прослеживается цепочка от клика или заявки до оплаты. Если на каком-то шаге путь обрывается или сходится только по косвенным признакам, это и есть то место, где идентификатор теряется. Иногда разрыв можно закрыть на уровне настроек систем, иногда для этого нужна отдельная логика связывания и объединения данных из разных источников, о чём подробнее можно почитать в материале про сбор и объединение данных. Но до дашборда важно хотя бы зафиксировать, какие разрывы существуют и насколько сильно они искажают картину.
Как оценить качество исторических данных
Отдельный вопрос — можно ли доверять тому, что уже накоплено за прошлые месяцы, или дашборд придётся строить фактически с нулевой историей. Качество исторических данных проверяется не на глаз, а через несколько простых сверок.
Первая сверка — полнота. Нужно посмотреть, не менялась ли структура CRM или форм на сайте за последний год: добавлялись новые поля, менялись статусы сделок, перезапускалась рекламная кампания с новыми настройками. Если такие изменения были, часть истории может быть устроена иначе, чем текущие данные, и прямое сравнение «было — стало» окажется не совсем честным.
Вторая сверка — согласованность чисел между источниками. Берётся один и тот же месяц, и сравнивается, например, число оплат в CRM с суммой поступлений в бухгалтерской таблице. Небольшая разница объяснима задержками и возвратами, но если цифры расходятся в разы, значит, один из источников не отражает реальность, и его нельзя закладывать в основу отчёта без оговорок.
Третья сверка — доля пустых и дублирующихся записей. Если у трети заявок не указан источник или телефон, статистика по каналам будет приблизительной, даже если формулы расчёта верны. Это не значит, что данные бесполезны, но важно заранее понимать степень погрешности и не выдавать такие цифры за точный результат.
Четвёртая проверка касается ручных данных: таблиц, которые ведут сотрудники вручную. У них стоит посмотреть, как давно и регулярно они обновлялись, и не было ли периодов, когда ответственный менялся или просто забывал вносить записи. Такие пробелы на дашборде лучше явно отмечать как периоды с неполными данными, а не сглаживать усреднением.
Отдельно стоит прикинуть глубину истории, с которой есть смысл работать. Если школа год назад поменяла платформу обучения или CRM, сравнивать показатели до и после переезда напрямую бессмысленно: это фактически два разных набора данных с разной логикой учёта. В таком случае честнее явно обозначить точку отсечения и строить дашборд от неё, а не пытаться склеить историю, которая физически не сходится.
Итог этой проверки — не оценка «данные хорошие» или «данные плохие», а понимание, какой истории можно доверять полностью, какую можно использовать с оговорками, а какую разумнее не выводить на экран вовсе, пока источник не наладят.
Какой результат аудита считать полезным
Полезный результат аудита — это не отчёт на несколько страниц, а конкретный список решений, в основе которого лежит разобранная выше работа. В него входит перечень решений, под которые строится дашборд, список событий, которые нужно фиксировать и которых пока не хватает, карта мест, где теряются идентификаторы клиента, и честная оценка качества данных за прошлые периоды с указанием, какой истории можно верить.
Отдельно полезно, если аудит заканчивается списком конкретных доработок перед запуском: что нужно донастроить в формах, какие события добавить в CRM или платформу обучения, какие поля сделать обязательными, чтобы заявки не терялись без идентификатора. Это рабочий список для технической команды, а не абстрактная рекомендация «улучшить качество данных».
Хороший признак завершённого аудита — когда по каждому пункту списка понятно, кто отвечает за исправление: разработчик сайта, администратор CRM, методист или бухгалтер. Если доработки повисают без ответственного, они обычно откладываются до следующего аудита, и накопленные за это время данные снова придётся разбирать с нуля.
Если по итогам аудита выясняется, что часть нужных событий и связей уже можно получить, дальше разумно переходить к тому, что именно должно быть на экране и для кого, — этот вопрос подробно разобран в материале про дашборд для бизнеса. А если решений и данных для школы много и воронка охватывает рекламу, CRM и платформу обучения одновременно, обычно речь идёт уже о сквозной аналитике и дашбордах для онлайн-школ, а не об одном изолированном экране.
Проверить применимость такого подхода к своей школе можно без привлечения команды: достаточно выписать три-четыре решения, которые вы хотите принимать на основе данных, и попробовать вручную пройти путь одного реального ученика от клика по рекламе до оплаты и прохождения курса. Если на этом пути легко находятся разрывы или противоречивые цифры, аудит аналитики будет полезен раньше, чем разработка самого дашборда.