В онлайн-школе работает несколько систем одновременно. Рекламные кабинеты записывают расходы и клики, образовательная платформа фиксирует регистрации и прогресс учеников, CRM ведёт сделки и платежи, таблицы хранят планы и корректировки. Каждая система показывает свою версию происходящего. Проблема возникает, когда нужно понять, сколько стоит привлечение одного платящего ученика или какой курс окупается быстрее остальных. Цифры из разных источников не совпадают, и непонятно, какой из них доверять.
Такая ситуация не означает, что одна из систем ошибается. Чаще всего каждая правильно выполняет свою задачу, но задачи эти разные. Рекламный кабинет считает конверсии по своим правилам атрибуции, платформа регистрирует момент создания аккаунта, CRM фиксирует первое обращение менеджера, а бухгалтерия отмечает поступление денег. Все четыре события могут произойти в разные дни и относиться к разным отчётным периодам.
Консолидация данных помогает свести эти источники в единую картину. Но чтобы она работала, нужно заранее договориться о том, где хранится первичный факт, кто отвечает за определение каждого показателя и как вести изменения, когда правила расчёта меняются.
Почему одних таблиц недостаточно?
Таблица — удобный инструмент для быстрого анализа и разовых расчётов. Она позволяет собрать несколько столбцов, написать формулу, построить сводную и сразу увидеть результат. Многие компании начинают с того, что выгружают данные из систем в Excel или Google Sheets, объединяют их вручную и передают руководителю готовый файл.
Этот подход работает, пока отчёт нужен редко, источников немного, а структура данных стабильна. Но как только количество курсов, каналов трафика и менеджеров растёт, таблица превращается в узкое место. Каждое обновление требует повторить весь путь: открыть рекламный кабинет, выгрузить статистику, скопировать нужные столбцы, перейти в CRM, экспортировать сделки, сопоставить идентификаторы, проверить формулы и отправить файл дальше.
Ошибки появляются не из-за невнимательности, а из-за объёма ручной работы. Достаточно пропустить одну строку, скопировать данные со смещением или забыть обновить период выгрузки, чтобы итоговые цифры перестали сходиться. Проверить правильность сложно, потому что каждый файл содержит только снимок на момент выгрузки, а не полную историю изменений.
Ещё одна проблема — отсутствие единого источника правды. Если один сотрудник выгружает данные утром, а другой вечером, в их таблицах окажутся разные суммы. Если формула изменилась, но старые файлы остались нетронутыми, сравнение прошлых и текущих периодов станет некорректным. Руководитель получает несколько версий отчёта с разными итогами и не может понять, какая из них актуальна.
Таблицы полезны для финального представления данных, но они не заменяют систему хранения и обработки. Когда отчёт строится регулярно, а источников больше двух, имеет смысл автоматизировать сбор и расчёт показателей, оставив таблицу или дашборд только для визуализации.
Где хранится первичный факт?
Первичный факт — это событие, которое произошло в реальности и было зафиксировано системой. Клик на объявление, регистрация ученика, создание сделки, поступление платежа — каждое из этих событий имеет свой источник, время и контекст. Задача архитектуры данных — сохранить эти факты в том виде, в котором они были записаны, и не подменять их расчётными значениями.
Когда я говорю о хранении первичного факта, имею в виду не копирование всей базы рекламного кабинета или CRM в отдельное место. Речь о том, чтобы каждый раз, когда система передаёт данные дальше, она отправляла именно исходное событие с его атрибутами, а не результат промежуточного расчёта. Например, рекламная система должна передавать сумму расхода по каждой кампании и дату, а не готовую стоимость лида, рассчитанную по её внутренним правилам.
Это важно, потому что правила расчёта меняются. Сегодня конверсией считается регистрация на платформе, через месяц — первый урок, ещё через квартал — покупка любого курса. Если в хранилище лежат только готовые показатели, пересчитать историю по новым правилам невозможно. Если хранятся первичные события с метками времени и идентификаторами, любой показатель можно пересчитать заново.
Образовательная платформа фиксирует регистрации, старты уроков, завершения модулей. CRM записывает обращения, звонки, смену статусов сделок, выставленные счета. Платёжная система или бухгалтерская таблица хранит фактические поступления денег. Каждая система остаётся владельцем своих фактов. Задача хранилища — собрать эти факты в одном месте, сохранить связь между ними через общие идентификаторы и дать возможность рассчитывать показатели на их основе.
Связь между событиями строится через ключи. Обращение в CRM может содержать utm-метки из рекламы, идентификатор пользователя с платформы и номер заказа из платёжной системы. Если эти ключи согласованы, можно проследить путь от клика до оплаты. Если ключей нет или они записаны по-разному, связать события не получится, и отчёт останется приблизительным.
Кто владеет определением показателя?
Показатель — это результат расчёта на основе первичных фактов. Средний чек, конверсия из регистрации в покупку, стоимость привлечения ученика, lifetime value — всё это производные величины. Они не существуют в исходных системах, их создаёт тот, кто пишет формулу.
Проблема в том, что одно и то же название может означать разные вещи. Для отдела маркетинга конверсия — это доля кликов, превратившихся в регистрации. Для продуктовой команды — доля зарегистрированных, которые начали первый урок. Для финансового директора — доля обращений, которые привели к оплате. Все три определения имеют право на существование, но если их не разделить явно, в отчёте появятся три разных процента под одним заголовком.
Поэтому каждый показатель должен иметь владельца. Это не обязательно один человек, но точно одна команда или функция, которая отвечает за определение формулы, проверку корректности расчёта и объяснение изменений. Если владелец не назначен, показатель становится ничейным. Каждый отдел начинает считать его по-своему, и единой управленческой картины не возникает.
Владение не означает монополию на использование. Маркетинг может определить стоимость лида, но этот показатель будут использовать продажи, финансы и руководство. Важно, чтобы все они обращались к одной формуле, а не пересчитывали показатель заново в своих таблицах. Иначе в переписке появятся фразы вроде «у нас стоимость лида 1200, а у вас почему-то 1400», и обсуждение уйдёт в выяснение того, кто прав, вместо анализа реального результата.
Чтобы избежать этого, определения показателей стоит записать в общедоступном месте. Это может быть документ, вики-страница или комментарий в коде хранилища данных. Главное — чтобы любой человек, использующий показатель, мог посмотреть его точную формулу, понять, на каких первичных фактах она основана, и узнать, когда определение менялось в последний раз.
Как вести изменения формул?
Бизнес меняется, и вместе с ним меняются правила расчёта показателей. Онлайн-школа начинает продавать подписки вместо разовых курсов — определение выручки требует корректировки. Появляется новый рекламный канал с другой моделью атрибуции — стоимость привлечения нужно пересчитать. Меняется структура воронки продаж — конверсия между этапами перестаёт быть сопоставимой с прошлыми периодами.
Если формулу изменить бесшумно, старые отчёты потеряют смысл. Руководитель сравнит текущий месяц с предыдущим и увидит резкое изменение показателя. Но это изменение может быть вызвано не реальным ростом или падением, а новым способом расчёта. Чтобы этого избежать, каждое изменение формулы нужно фиксировать и либо пересчитывать всю историю по новым правилам, либо явно указывать, с какого момента показатель считается иначе.
Пересчёт истории возможен, если в хранилище сохранены первичные факты. Тогда новая формула применяется ко всем прошлым данным, и динамика остаётся сопоставимой. Это удобно, но требует вычислительных ресурсов и времени. Если данных много, полный пересчёт может занять несколько часов.
Если пересчёт невозможен или нецелесообразен, изменение фиксируется как граница версии. В отчёте появляется пометка: до 15 марта конверсия считалась от регистрации до первого урока, после 15 марта — от регистрации до покупки. Это честнее, чем делать вид, что показатель всегда считался одинаково. Сравнивать периоды через границу версии всё ещё можно, но нужно учитывать разницу в определениях.
Частые изменения формул — признак того, что показатель ещё не устоялся. Это нормально на старте проекта или при запуске нового направления. Но если показатель используется для управленческих решений, его определение должно быть достаточно стабильным. Иначе каждое изменение формулы будет восприниматься как изменение реальности, хотя на самом деле изменился только способ измерения.
Как построить минимальную архитектуру?
Минимальная архитектура данных для онлайн-школы состоит из четырёх частей: источники, хранилище, слой расчёта и представление. Источники — это системы, где происходят события. Хранилище собирает первичные факты и сохраняет их в согласованном виде. Слой расчёта применяет формулы и создаёт показатели. Представление — это дашборд или таблица, в которой руководитель видит итоговые цифры.
Начинать стоит с самых важных источников. Для большинства онлайн-школ это рекламные кабинеты, образовательная платформа, CRM и учёт платежей. Каждый источник должен передавать данные в хранилище автоматически, по расписанию или в реальном времени. Если автоматическая передача невозможна, можно начать с регулярной выгрузки, но тогда кто-то должен отвечать за её своевременность.
Хранилище не обязано быть сложной системой. На старте это может быть база данных, куда записываются таблицы с рекламными расходами, регистрациями, сделками и платежами. Главное — чтобы данные попадали туда в исходном виде, с сохранением времени события и идентификаторов, которые позволят связать записи между собой. Подробнее о механике объединения данных из разных систем я писал в статье о сборе и консолидации .
Слой расчёта — это набор запросов или скриптов, которые читают данные из хранилища, применяют формулы и записывают результат в отдельные таблицы. Например, один запрос рассчитывает стоимость лида по каждому каналу, другой — конверсию между этапами воронки, третий — средний чек по курсам. Эти расчёты выполняются регулярно, и их результаты используются для построения отчётов.
Представление может быть дашбордом в специализированном инструменте или таблицей, которая обновляется автоматически. Важно, чтобы руководитель видел актуальные данные без необходимости запрашивать выгрузку у аналитика. Если данные обновляются раз в сутки, это нормально для большинства управленческих решений. Если нужна более высокая частота, можно настроить обновление несколько раз в день.
Такая архитектура не требует дорогих инструментов на старте. Хранилищем может быть PostgreSQL, слоем расчёта — SQL-запросы, представлением — Metabase, Superset или Looker Studio. По мере роста школы можно добавить более мощные решения, но логика останется той же: собрать факты, рассчитать показатели, показать результат.
Если у вас уже есть несколько систем и вы хотите понять, как их данные могут работать вместе, посмотрите материал про сквозную аналитику и дашборды для онлайн-школ . Начать стоит с выбора двух-трёх ключевых показателей, проверки того, какие первичные факты для них нужны, и настройки их автоматической передачи в одно место.