Пользовательские поля сделки в Битрикс24: сколько их нужно, чтобы отчёт по источникам собирался сам

Собственник открывает отчёт по каналам рекламы и вместо десяти источников видит полсотни строк: «Директ», «яндекс директ», «direct», «Яндекс». Одно и то же значение записано четырьмя разными способами, и каждое написание уходит в отдельную строку отчёта. Посчитать по такому срезу цену заявки и окупаемость канала невозможно — суммировать нечего, данные разбиты на почти-дубли.

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

Тип поля решает, будет ли отчёт группироваться

В CRM Битрикс24 доступно 14 типов пользовательских полей: строка, целое число, число с десятичными знаками, Да/Нет, дата, дата со временем, деньги, ссылка, адрес, файл, привязки к сотрудникам, справочникам и элементам CRM, и список. Список Битрикс24 описывает как заранее подготовленный набор значений, из которого можно выбрать одно или несколько.

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

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

Обязательность на стадии — чтобы поле заполнялось данными

Поле в Битрикс24 можно требовать выборочно — не по всей сделке, а на конкретной стадии. Например, «Источник» делается обязательным на стадии «В работе»: пока менеджер его не заполнил, карточку нельзя двинуть дальше по воронке. Так поле собирается принудительно там, где данные уже есть.

Стадию для требования нужно выбирать по тому, когда информация реально появляется у менеджера. Бюджет разумно требовать на стадии «КП отправлено», причину потери — на провальных стадиях. Если требовать поле раньше, чем данные появились, продавцы заполняют его заглушками «Н/Д», «не знаю», «TBD». Проверку такие значения проходят, карточка едет дальше, а отчёт ломается ровно так же, как от свободного текста — только теперь мусор выглядит заполненным полем.

Ещё одна деталь настройки: обязательность полей задаётся отдельно для каждой воронки и действует только там, где находится редактируемая карточка. При нескольких направлениях продаж требования придётся дублировать в каждой воронке, иначе в одной из них поле окажется пустым и отчёт по всем направлениям снова поплывёт. Как связать стадии с деньгами, я разбирал в материале про проектирование воронки под отчёт.

Источник сделки — через штатные UTM, без ручного дубля

Битрикс24 сам подхватывает пять меток — utm_source, utm_medium, utm_campaign, utm_content, utm_term — и сохраняет их в карточке лида; при автосоздании сделки метки переносятся и в неё. Сохранённые метки питают сквозную аналитику: система показывает, сколько заявок пришло, по какой цене и с какого источника.

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

Сколько полей и значений держать

Справочник-список разумно держать в пределах примерно 10–15 значений. Слишком дробный список вредит отчёту так же, как свободный ввод: если каждый источник разбит на десяток подвидов, срез снова рассыпается на мелочь, по которой ничего не суммируется. Значения списка должны совпадать с реальной сегментацией клиентов и каналов — тогда каждый выбор менеджера ложится в осмысленную строку отчёта.

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

Что это даёт для денег

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

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

Автор — Никита Бердников, Бизнес-партнер 1С-Битрикс.