Отчёт обычным языком: как получать данные без SQL

Вторник, 9:12. До совещания у руководства восемнадцать минут, и руководителю маркетинга нужна одна-единственная цифра: сколько выигранных сделок в прошлом квартале пришло с каждого источника лидов. Цифра лежит в базе, её никто не прячет. Но привычных способов достать её два: попросить аналитика и получить ответ после обеда либо выгрузить три отчёта и сорок минут сводить их в таблице. Она пробует третий путь — пишет в поле «выигранная сумма по источникам за этот квартал» и через несколько секунд видит столбчатую диаграмму, по столбцу на источник. Все сроки и суммы здесь приведены как пример. Настоящий вопрос другой: что именно произошло за эти секунды и насколько такому ответу можно доверять на совещании.

В этой статье разбираем, как работает запрос отчёта на обычном языке, на какие вопросы он отвечает хорошо и в какой момент задачу пора передавать собранному вручную отчёту или хранилищу данных. Сначала посмотрим, как фраза превращается в запрос, затем — почему у одного и того же вопроса нередко несколько правильных ответов. Дальше: четыре части грамотного вопроса, проверка полученной цифры, влияние модели данных на то, что вы вообще можете спросить, и превращение повторяющихся вопросов в сохранённые представления. В конце — границы доступа, внедрение в команде и частые вопросы.

Что происходит между вашей фразой и графиком?

Запрос на обычном языке — не магия, а аккуратная задача перевода. Фраза разбирается на части: какая величина измеряется, по какому набору записей, по какому полю даты и в какой группировке. Когда эти четыре части определены, система собирает за вас структурный запрос и возвращает результат в виде графика. В Rocketly поле «Спросить обычным языком» делает именно это: читает фразу «выигранная сумма по источникам за квартал» как метрику, период и разрез, формирует запрос и показывает диаграмму.

Отличие от поиска принципиально. Поисковая строка возвращает подходящие записи; запрос на обычном языке агрегирует записи и выдаёт вычисленную величину. Введёте название компании — получите карточку. Введёте «количество сделок, закрытых в этом месяце, по менеджерам» — за ответом нет ни одной конкретной записи, есть рассчитанная таблица. Это уже отчётность, и внизу работает запрос. Механику того, как задавать вопросы к данным CRM на естественном языке, мы разбирали отдельно; здесь нас интересует, где эта механика даёт сбой на реальных отчётах.

Самое хрупкое место слоя перевода — неоднозначность. «Прошлый месяц» — это календарный месяц или последние тридцать дней? «Продажи» — это выставленные счета или выигранные сделки? Если фраза этого не уточняет, система подставит значение по умолчанию и ответит на него. Ответ будет технически верным и не вашим вопросом. Поэтому научиться спрашивать обычным языком — значит научиться точно формулировать собственные определения.

Почему у вопроса «сколько мы продали в прошлом месяце» нет одного ответа?

Задайте его трём коллегам — получите три цифры. Руководитель продаж назовёт сумму выигранных сделок. Бухгалтерия — сумму выставленных счетов. Финансовый отдел посчитает только поступившие деньги. Все трое честны, просто они измеряют разные события. День, когда сделка помечена выигранной, день выставления счёта и день поступления денег редко попадают даже в один месяц.

Выбор поля даты разводит ответы так же сильно. Считая сделки по дате создания, вы измеряете то, что произвёл маркетинг; считая по дате закрытия — то, что собрали продажи. Кривые не совпадут, и совпадать не должны. Пока не решено, вокруг каких KPI строится отчёт о продажах, обычный язык ускоряет получение цифры, но не заканчивает спор.

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

Из каких четырёх частей состоит грамотный вопрос?

Вопросы, на которые приходит точный ответ, почти всегда содержат четыре элемента явно. Первый — метрика: сумма, количество, доля или среднее. «Продажи» — не метрика, «сумма выигранных сделок» — метрика. Второй — период: этот квартал, последние тридцать дней, январь. Если период не указан, система подставит значение по умолчанию, и оно обычно шире того, что вы имели в виду.

Третий — разрез, то есть по чему группировать результат: по источнику, по менеджеру, по продукту, по этапу. Без разреза вы получите одну цифру; иногда это и нужно, но чаще для решения этого мало. Четвёртый — фильтр: только корпоративный сегмент, только один регион, только конкретная кампания. Фильтр сужает выборку и делает сравнение осмысленным.

Собирать все четыре в одну фразу — вопрос привычки, а не квалификации. Фраза «сумма выигранных сделок по источникам за этот квартал, только корпоративный сегмент» содержит всё и отрабатывает с первого раза. Тот же смысл в формулировке «как дела в корпоративе» почти наверняка вернёт не ваш ответ. Качество вопроса задаёт потолок качества ответа.

Какие вопросы работают на обычном языке, а какие нет?

У этого интерфейса есть реальные границы, и знание границ экономит время. Общее правило: суммы, подсчёты и группировка по одному измерению работают хорошо; многошаговые производные величины, когортные расчёты и вопросы о причинах — нет. Таблица ниже помогает понять, в какой полосе находится ваш вопрос, ещё до того как вы его напишете.

Тип вопроса	Пример фразы	Ожидаемый результат
Одна метрика, один период	«Выигранная сумма за этот месяц»	Отвечает сразу, возвращает одно число
Метрика и один разрез	«Выигранная сумма по источникам за квартал»	Отвечает сразу, возвращает график
Перекрёстный разрез по двум полям	«Конверсия по менеджерам и источникам»	Частично; второе измерение переведите в фильтр
Когорты и расчёт длительности	«Среднее число дней от первого контакта до покупки»	Точнее отработает готовый отчёт или конструктор
Вопрос о причине	«Почему упали продажи?»	Вернёт цифру, причину вы читаете по записям
Данные вне CRM	«Отдача на рекламный бюджет»	Пусто, если расходы в систему не попадают

Две последние строки особенно важны. Слой обычного языка не создаёт данные, которых нет; он агрегирует записи вашей системы. Если стоимость рекламы, себестоимость или логистика в CRM не приходят, никакая формулировка ответа не даст. Это не недоработка, а граница, проведённая там, где ей и место.

Как проверить полученную цифру до того, как на неё сошлётесь?

Главный риск быстрого ответа в том, что он попадает в презентацию без проверки. Любая цифра, полученная обычным языком, заслуживает трёх проверок: определение, свежесть и записи. Проверка определения — это прочитать, из чего цифра посчитана. Панель методологии рядом с каждой метрикой пишет: какой источник, какие фильтры, какое поле даты. Когда на совещании спрашивают, что входит в эту выручку, ответ читается с экрана, а не восстанавливается по памяти.

Вторая проверка — свежесть. Индикатор актуальности данных показывает, когда карточка обновлялась в последний раз; живая панель обновляется сама с регулярным интервалом, пока вкладка открыта, а кнопка обновления обходит кеш и тянет данные заново. Принять устаревшую цифру из кеша за свежую — ошибка не менее дорогая, чем неверный расчёт. Третья проверка — сами записи: детализация позволяет кликнуть по сегменту графика и открыть постраничный список строк за ним. Двадцать секунд такого взгляда почти всегда показывают, правдоподобна ли цифра.

Есть ещё уровень подачи. Верно посчитанное число на обрезанной оси или в неверном масштабе выглядит крупнее, чем есть. Принципы визуализации, которые не дают графику лгать, действуют и для автоматически построенных диаграмм: быстро полученный график — это ещё не проверенный график.

Как модель данных ограничивает круг ваших вопросов?

Потолок здесь задаёт не язык, а структура данных. У вопроса «средний чек сделки по отраслям» есть ответ, если поле отрасли в карточках компаний заполнено, и нет ответа, если оно пустое. Связи важны не меньше: если непонятно, к какой компании относится сделка и какой контакт принадлежит компании, любой разрез вернётся наполовину. Система, где контакты, компании и сделки связаны корректно, отвечает на кратно большее число вопросов.

Второе ограничение — качество данных. Один и тот же источник, записанный как «Яндекс», «яндекс директ» и «Яндекс Директ», делит каждый график по источникам на три части и тихо портит результат. Такие сбои не выдают ошибку — они просто выдают неверную таблицу. Работа над чистыми и проверенными данными клиентов — списки значений вместо свободного текста, проверка на вводе — напрямую повышает точность каждого вашего вопроса.

Третье ограничение — полнота охвата. Если часть клиентов по-прежнему живёт в таблице или в старом списке, любой вопрос отвечает только по срезу внутри системы. Собрать базу клиентов в одном месте — предварительное условие отчётности; на разрозненных данных движок запросов быстрее всего покажет саму разрозненность.

Что делать вместо того, чтобы задавать один вопрос каждую неделю?

Обычный язык прекрасен для разведки и расточителен как рутина. Если вы задаёте вопрос второй раз, это уже не вопрос, а отчёт. Правильный ход — закрепить его. Сохранённые представления отчётов хранят комбинацию фильтров, диапазона дат, группировки и порядка колонок как одно именованное представление, которым можно поделиться с командой. Вместо того чтобы каждый понедельник заново описывать тот же срез, вы открываете сохранённое представление.

Следующий шаг — доставка. Отчёты по расписанию позволяют задать время ежедневной, еженедельной или ежемесячной отправки; отчёт приходит списку получателей на почту в формате PDF или Excel. Заказчику отчёта больше не нужно заходить в систему, и поток просьб «пришли мне эту цифру» прекращается. Для контроля порогов есть правила оповещений по отчётам: метрика, порог, период и адресат уведомления задаются вами, а не тем, что система сочла необычным.

Некоторым командам результат нужен в их собственных рабочих файлах. В этом случае вместо ручной выгрузки в PDF, Excel или CSV устойчивее настроить регулярную синхронизацию между CRM и таблицами: любой скачанный вручную файл начинает устаревать в момент сохранения.

Когда обычного языка уже мало и пора идти в конструктор?

Признаков три. Первый — вы задали один и тот же вопрос трижды и трижды получили разный результат: определение перестало помещаться во фразу. Второй — вы регулярно выгружаете ответ и правите его руками. Третий — в вопросе несколько правил сразу: «и ещё», «кроме», «только если». Во всех трёх случаях точнее сработает конструктор своих отчётов: вы выбираете поля, фильтры, группировку и агрегацию по лидам, клиентам, сделкам, предложениям, задачам и встречам, собираете отчёт один раз, и определение живёт в структуре, а не во фразе.

Если вопрос выходит за пределы CRM, граница смещается совсем. Свести рекламные расходы, себестоимость или веб-аналитику с данными продаж на одном графике — это задача объединения, а не отчётности. Здесь и появляется смысл переносить данные CRM в хранилище и BI-инструмент: вы соединяете данные на правильном уровне вместо того, чтобы выжимать интерфейс запросов.

Когда нужно объединить поведение клиента в нескольких каналах в один профиль, разговор переходит в другой класс инструментов. Именно здесь становится видно, чем платформа клиентских данных отличается от CRM: одна ведёт отношения и сделку, другая собирает поведенческие данные. Ждать обоих результатов от одной строки запроса нереалистично.

Должен ли каждый иметь право спросить любую цифру?

Открыть строку запроса не значит открыть данные всем. Здесь работает принцип охвата по правам доступа: отчёт показывает те строки, которые видит запустивший его человек. Пользователь с охватом на уровне команды получает данные только своей команды, и при запросе обычным языком действует та же граница. Меняется интерфейс, охват не меняется — именно это делает такой слой безопасным в организации любого размера.

Второй вопрос — обмен. Ссылка на отчёт позволяет выдать отчёт наружу без входа в систему: с паролем, сроком действия и лимитом просмотров, с возможностью отключить в любой момент. Эта гибкость приносит и обязанность следить, у кого ссылки остались: бессрочная ссылка означает бессрочный доступ.

Третий вопрос — где данные обрабатываются. Движок запросов при построении ответа работает с записями в конкретном месте, и в ряде отраслей страна этого места — предмет договора. Вопрос о том, где ваши данные физически находятся, остаётся на столе наравне с удобством интерфейса и обязательно всплывает при закупке.

Как эта привычка приживается в команде?

Самый быстрый путь — в первую неделю попросить каждого написать три вопроса о собственной работе. Менеджер спрашивает про свою воронку, маркетинг — про эффективность каналов, руководитель — про итоги команды. Когда эти три вопроса превращаются в сохранённые представления, привычка закрепляется сама: инструкции никто не читает, рабочий пример копируют охотно.

Второй шаг — общий словарь формулировок: складывайте удачные фразы дословно там, где их видит команда. Как только «выигранная сумма по источникам за этот квартал» дала верный ответ, тот же шаблон сработает для продукта, менеджера и региона. Чем больше словарь, тем выше качество вопросов и тем меньше обращений в поддержку. Библиотека готовых отчётов питает ту же привычку: прочитав описание готового отчёта, вы понимаете, как сформулировать такой же вопрос.

Третий шаг — измерение. В конце месяца посчитайте, сколько вопросов стало сохранёнными представлениями и сколько — отчётами по расписанию; эти две цифры показывают, действительно ли изменился способ, которым команда добирается до данных. Чтобы проверить всё это на своих записях, откройте бесплатный аккаунт в Rocketly и задайте первый вопрос по собственной базе.

Частые вопросы

Нужно ли знать SQL или уметь строить отчёты?

Нет. Достаточно назвать во фразе метрику, период и разрез — например, «выигранная сумма по источникам за этот квартал». Запрос соберёт система. Но команде нужно заранее договориться, что именно означает метрика.

Как понять, что ответ неверный?

Прочитайте в панели методологии, из какого набора записей и по какому полю даты посчитана цифра, проверьте актуальность по индикатору свежести, затем кликните по графику и посмотрите строки за ним. Три проверки занимают несколько минут и отсекают большую часть ошибок.

Что делать, если ответ пустой?

Сначала расширьте период, затем снимите фильтр, потом упростите разрез. Если пусто и после этого, нужных данных в системе может просто не быть: рекламные расходы — типичный пример.

Как получать один и тот же отчёт каждую неделю?

Задайте вопрос один раз, сохраните результат как представление и настройте отчёт по расписанию. Он уйдёт списку получателей в PDF или Excel в выбранные вами день и время, и заходить в систему никому не придётся.