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

В деньгах Прикидка: 100 гарантированных лидов по 1500 ₽ — 150 тысяч в месяц. Если в сделку конвертится 1% вместо привычных для канала 10%, сделка обходится в 150 тысяч вместо 15. Сверху — часы менеджеров на прозвон анкет.

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

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

Гарантия объёма без критерия качества переносит риск с подрядчика на ваш отдел продаж.

По каким записанным критериям ваши менеджеры отличают лид от анкеты с номером телефона — и есть ли эти критерии в договоре с подрядчиком?

Типичная картина: с компьютера конвертится 4% посетителей, с телефона — 1%. При этом телефон — это 70% трафика. В среднем выходит прилично, и глубже никто не смотрит. А реклама тем временем льёт большую часть бюджета туда, где форму перекрывает баннер про куки, карта не грузится, а кнопка «Купить» уезжает за экран.

В деньгах Прикидка: бюджет 800 тысяч, 70% кликов — мобильные. При конверсии 1% против десктопных 4% больше полумиллиона в месяц работает с КПД вчетверо ниже возможного. Поднять мобильную конверсию с 1% хотя бы до 2% — мобильные заявки удвоятся, а общий поток вырастет примерно на треть без роста бюджета.

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

Замечание В B2B мобильная конверсия честно ниже: с телефона изучают, а заявку отправляют с рабочего компьютера. Там мобайл сравнивают со своей же историей, и чинить в нём тоже есть что.

Средняя конверсия склеивает два разных сайта в одну цифру. Управлять можно только каждым по отдельности.

Вы знаете конверсию своего сайта с телефона — отдельно от красивой средней цифры?

Ежедневный взгляд провоцирует ежедневные решения: вчера цена заявки подскочила — отключили кампанию, порезали ставку, поменяли креатив. Но день — это шум: 5 заявок против 9 ничего не говорят о тренде. А крупные правки — ставка, бюджет, смена цели, перезапуск кампании — сбрасывают обучение автостратегии, и она заново тратит бюджет на разгон.

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

Решение Развести ритмы: смотреть можно хоть каждый день, менять — раз в неделю, по недельному окну и по заранее записанному правилу («снижаем ставку, если цена заявки выше X две недели подряд»). Аварийное вмешательство — только на поломки: бюджет улетел в разы, ссылка ведёт в 404, открутка встала.

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

Реклама — из тех систем, где выдержка приносит больше денег, чем реакция.

Сколько раз за последний месяц вы или подрядчик меняли настройки кампаний — и по какому записанному правилу?

Как это происходит. Сайт «морально устарел», дизайнеры сделали современно и воздушно. Под нож ушли «перегружающие» блоки: таблица цен на первом экране, кривоватые, но живые отзывы, форма заявки в шапке. Именно они и продавали. Конверсия падает с 3% до 2% — сайт стал красивее ровно на треть заявок.

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

Связь при этом не видна: конверсию «до» никто не зафиксировал, падение списывают на сезон, конкурентов и «наверное, реклама испортилась». Студия свои деньги за дизайн получила, а за заявки почему-то отвечает подрядчик по трафику.

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

Замечание Бывает и наоборот: редизайн поднимает конверсию, и заметно. Отличить один сценарий от другого можно единственным способом — замером.

У сайта одна метрика — заявки и сделки. Красота учитывается в ней только через конверсию.

Вы знаете конверсию своего сайта прямо сейчас — чтобы было с чем сравнивать после следующего редизайна?

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

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

Решение Раз в квартал — проверка руками: прослушать десять звонков по проигранным сделкам или позвонить пяти проигравшим клиентам. Звонит пусть кто-то, кроме менеджера, который вёл сделку, — так отвечают честнее. И развести коды в CRM: «сравнивал цены, купил дешевле у конкурента» и «сказал „дорого“ и пропал» — разные причины с разными выводами. Первая и правда о цене. Вторая — почти всегда о ценности.

Замечание Иногда «дорого» — правда, и десять звонков это быстро покажут. Тогда разговор о цене станет предметным: с кем сравнивают и что за эти деньги дают там.

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

Ваше «дорого» в CRM — оно проверено хотя бы одним звонком клиенту?

Расклад на модельных числах. Бюджет 2 млн в месяц, им управляет начинающий специалист за 60 тысяч — «зачем переплачивать за настройку кабинетов». Типовые потери начинающего: поздно заметил рост CPA, оставил крутиться выгоревший креатив, скопировал настройки из чужой статьи, не отминусовал мусорные запросы. Каждая мелочь — 2–5% бюджета. В сумме набегает 10–15% неэффективности: 200–300 тысяч в месяц. Экономия на зарплате съедена трижды, и это без учёта упущенных заявок.

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

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

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

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

Кто сегодня управляет вашим рекламным бюджетом — и во сколько вам обходится разница между его уровнем и нужным?

Механика. Запустили баллы 5% всем покупателям. Львиная доля выплат достаётся самым лояльным — тем, кто и раньше покупал часто, безо всяких баллов. Их поведение программа не изменила, они просто стали платить на 5% меньше. Инкремент — покупки, которых без программы не случилось бы, — дают процентов 15–20 участников. Прикидка; у кого есть контрольная группа, тот знает свою цифру точно.

В деньгах Выручка 100 млн, начислено баллами 5 млн. Если программа изменила поведение только у 15% — около 4 млн вы раздали за покупки, которые произошли бы и так. По сути это скидка задним числом, размазанная по лучшей части базы.

Решение Проектировать лояльность как инструмент изменения поведения, у каждой механики — свой адресат: реактивация спящих («вернитесь, вот повод»), подъём частоты («третья покупка месяца даёт…»), выход в соседнюю категорию. Ковровый кэшбэк заменить целевыми предложениями сегментам, где есть что менять. И обязательно держать контрольную группу — без неё эффект программы неотличим от естественного поведения базы.

Замечание «Удержание дешевле привлечения» — правда. Но только когда программа реально удерживает, то есть меняет поведение, а не документирует его за деньги.

Бюджет лояльности должен покупать изменение поведения — всё остальное он просто дарит.

Сколько из ваших бонусных выплат за прошлый квартал ушло клиентам, которые купили бы и без них?

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

Простыми словами Когорта — все лиды одного месяца, за которыми следят отдельно: что с ними стало через 3, 6, 9 месяцев. Канал с полугодовым циклом оценивают только по когортам, дозревшим хотя бы до этого срока.

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

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

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

По каким данным вы закрывали последний канал — успели ли они дозреть?

О формате Статья написана в два голоса. Обычный текст — мой: задача, симптомы, решения. Всё, что помечено Агент, — от Claude Code, который этот код и писал: разбор причины, код и способ, которым он до причины дошёл. Я правил эти куски по длине и выкидывал жаргон; разбор и факты — его. Так честнее, чем изображать, будто я сам разобрался в цепочках сертификатов. К тому же полезное здесь лежит по разные стороны: приёмы диагностики — у него, решение о том, что делать с ограничением платформы, — у меня.

Задача и первый упор

Дано: Telegram-канал, 1065 постов с 2019 года. Нужно: тот же контент в канале MAX, дальше новые публикации туда автоматически. Условие, которое сразу отсекает половину решений: в канале MAX уже лежала примерно сотня постов — часть перенесли руками, часть написана только там и в Telegram отсутствует. Дублей быть не должно, «отправить всё подряд» не годится.

Упор случился раньше, чем я успел что-то запланировать: архив канала боту недоступен.

Агент Telegram Bot API не отдаёт историю канала — ни одному боту, ни за какие права. Бот видит только то, что опубликовано после его добавления, событием channel_post. Архив достаётся двумя путями: клиентский API (MTProto, отдельная авторизация живым аккаунтом) или ручной экспорт из Telegram Desktop в JSON. Я предложил экспорт: одна кнопка в клиенте, на выходе result.json и папки с медиа, никакой второй авторизации и никаких вопросов к тому, чьей сессией ходит бот. Отсюда архитектура из двух потоков: старое из экспорта, новое из channel_post, память о перенесённом — JSON-файл с ключом по id сообщения Telegram, он стабилен между переэкспортами. Стек скучный намеренно: Node, grammY на стороне Telegram, официальный @maxhub/max-bot-api на стороне MAX, один процесс, long polling — так у бота нет ни одного открытого порта.

Грабля 1. Бот молчал при верном токене

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

Агент Ошибка выглядела так:

TypeError: fetch failed
  cause: UNABLE_TO_GET_ISSUER_CERT_LOCALLY

Гипотезу про токен я отсёк одним запросом: getMyInfo падал точно так же, как обращение к чужому чату, а при неверном токене API отвечает осмысленной 401 — симптом не совпадал. Верхний слой ошибки в Node вообще малоинформативен: TypeError: fetch failed — обёртка undici поверх любой транспортной проблемы, от DNS до TLS. Настоящая причина лежит в err.cause, и она указала на проверку цепочки сертификатов.

Дальше вопрос сузился: наш клиент или сервер. openssl s_client -connect platform-api2.max.ru:443 показал, что цепочка выстраивается до корня, которого нет в хранилище Node: MAX отдаёт сертификат российского доверенного удостоверяющего центра (Минцифры). Браузер и часть системных клиентов этот корень знают, Node — нет, поэтому в браузере ссылка открывается, а из кода не работает. Расхождение и сбивает прицел. Telegram API проблемы не имеет — там обычный публичный УЦ, и это добавляет уверенности, что «сеть в порядке, сломан MAX-бот».

Решение — подсунуть Node недостающие корни:

curl -fsSL -o root.crt https://gu-st.ru/content/lending/russian_trusted_root_ca_pem.crt
curl -fsSL -o sub.crt  https://gu-st.ru/content/lending/russian_trusted_sub_ca_pem.crt
awk 1 root.crt sub.crt > russian-trusted-ca.pem

NODE_EXTRA_CA_CERTS=russian-trusted-ca.pem node src/index.js

Две детали, на которых легко потерять ещё по получасу. Склеивать бандл нужно через awk 1: если в первом файле нет завершающего перевода строки, cat приклеит -----END CERTIFICATE----- к -----BEGIN CERTIFICATE----- следующего, и OpenSSL ответит bad end line. И NODE_EXTRA_CA_CERTS читается процессом Node при старте, до того как отработает dotenv, — положить переменную в .env нельзя, только в окружение: npm-скрипт, systemd-юнит, Dockerfile. В репозитории она зашита в package.json, чтобы про сертификат не помнил никто.

Ограничение, которое переписало ТЗ

Дальше я озвучил план, который казался очевидным: гоним архив пакетом, ночью, с выключенными уведомлениями. Тысяча постов приедет за час, подписчики утром увидят наполненный канал и не получат тысячу пушей. Попросил проверить, что уведомления выключаются.

Агент Проверять пришлось эмпирически: документация про канальные ограничения молчала, типы SDK описывали notify?: boolean без оговорок — оба источника отвечали «можно». Я написал скрипт на двадцать строк, который шлёт один и тот же вызов в трёх вариантах:

const variants = [
  ['notify: true',      { notify: true }],
  ['без поля notify',   {}],
  ['notify: false',     { notify: false }],
];

for (const [label, extra] of variants) {
  try {
    const r = await api.sendMessageToChat(chatId, `diag: ${label}`, extra);
    console.log(`OK   [${label}] → mid=${r?.body?.mid}`);
  } catch (e) {
    console.log(`FAIL [${label}] → ${e?.message}`);
  }
}

На канале вывод получился такой:

OK   [notify: true]    → mid=…
OK   [без поля notify] → mid=…
FAIL [notify: false]   → 400 errors.send-message.channel-notify

Каналы MAX не игнорируют notify: false молча, а отвечают ошибкой. Отдельно я проверил приватный чат — туда тихая отправка проходит, значит ограничение относится именно к каналам. Правило, которое я из этого вынес: предположение о поведении молодого API стоит дороже, чем его проверка. Особенно когда на предположении держится вся архитектура.

Что я с этим сделал

Костыля здесь нет. Ждать ночи бессмысленно — пуши придут утром пачкой. Растянуть отправку на недели — тот же спам, только медленный. Тихой миграции архива не существует, и план надо было не чинить, а менять.

Ограничение переехало в продукт. Бот показывает владельцу канала пост за постом прямо в личку в Telegram: превью с медиа и две кнопки, «Шлём» и «Не шлём». Нажали — пост ушёл в MAX и записан, показан следующий. Прерваться можно в любой момент, /status покажет остаток.

Дальше выяснилось, что это решение закрывает ещё две задачи, которые я собирался решать отдельно.

Сверка с тем, что уже лежит в MAX. Помните сотню постов, перенесённых руками? Я думал, придётся сравнивать содержание автоматически. Не понадобилось: человек, глядя на превью, помечает такие «Не шлём». Хеш содержания агент всё-таки считает и хранит, но решение по нему не принимает — цена ошибки в дубле у подписчиков выше, чем экономия десяти минут.

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

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

Грабля 2. В MAX приезжал пост без картинки

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

Агент Симптом сбивал прицел дважды. Сначала сервер отвечал 505 NO_IMAGE — читается как «не принял формат», и я пережимал jpeg, менял размер, пробовал другие файлы. Потом отправка падала с 400: No 'photos','url' or 'token' provided — читается как «неверно собрал вложения», и я полез перечитывать формат сообщения. Обе гипотезы были про мой код, обе оказались мимо.

Отсекло их одно наблюдение: toJson() возвращал пустой payload ещё до отправки. Значит, ломается загрузка, а сообщение и картинка тут ни при чём. Дальше я перестал гадать и пошёл читать node_modules/@maxhub/max-bot-api. Там нашлись две ветки загрузки: для изображений SDK идёт multipart-веткой, где в FormData кладётся псевдо-File, — undici на Node 20+ такой объект не принимает, и до сервера доезжает пустое тело. Видео, аудио и документы уходят другой веткой и путём грузятся нормально.

Достаточно передать буфер, тогда SDK уходит в буферную ветку с настоящим Blob:

// приезжает пустое вложение
await api.uploadImage({ source: '/path/to/pic.jpg' });

// работает
await api.uploadImage({ source: await fs.promises.readFile('/path/to/pic.jpg') });

Версия SDK — @maxhub/max-bot-api 0.2.5, Node 24; к моменту публикации могут починить, проверяется одной картинкой. Приём, который здесь окупился: исходники в node_modules — такой же источник правды, как документация, и обычно свежее. Типы я по ним же и сверял: пара методов в документации называлась иначе, чем в коде.

Грабля 3. Видео обрывалось на середине

Фотографии поехали, видео — нет: загрузка прерывалась примерно на двадцатой секунде. Выглядело как плохая связь, и я честно перезапускал.

Агент This operation was aborted ровно через двадцать секунд — это дефолтный таймаут загрузки в SDK. MAX принимает файлы медленно: видео на 7 МБ в двадцать секунд не укладывалось. Ретраи обрывались на той же секунде, что подтверждало версию про связь. Фикс — задать таймаут явно:

await api.uploadVideo({ source: path, timeout: 300_000 }); // пять минут

Грабля скучная, но показательная: дефолт библиотеки рассчитан на другой профиль нагрузки, а формулировка ошибки уводит в сторону сети.

Чего я чуть не лишился молча

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

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

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

Что ещё вылезло на стыке двух платформ

Агент Два ограничения, которые стоит знать заранее.

Bot API Telegram не отдаёт файлы больше 20 МБ: getFile на большом видео возвращает ответ без file_path, скачать его ботом нельзя никак. Такие посты уходят текстом, а оператору падает предупреждение; обходится либо руками, либо переездом на клиентский API.

Альбомы живут по-разному в двух источниках. В живых постах Telegram присылает альбом несколькими сообщениями с общим media_group_id — их надо буферизовать (у нас две секунды после последнего) и склеивать в один пост MAX с несколькими вложениями. В экспорте Telegram Desktop группировки нет вовсе: каждое фото лежит отдельным сообщением со своим id, восстанавливать альбомы пришлось бы эвристикой по времени. Мы не стали — в разборе истории каждое фото показывается отдельно.

Сводка граблей

Агент Всё, на что мы наступили, одной таблицей.

Приёмы, которые агент вынес из этой недели

Агент Четыре вещи, которые я теперь делаю на любой интеграции с молодым API.

Читать cause, а не сообщение. Верхний слой ошибки в Node обычно не значит ничего. Полминуты на печать причины экономят перевыпуск токенов и переустановку зависимостей.

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

Считать node_modules источником правды. У молодых SDK документация отстаёт от кода: расходятся и названия методов, и поведение внутренних веток.

Сначала инструмент потерь, потом инструмент переноса. Любая миграция что-нибудь выбрасывает молча; отчёт «что я не взял и почему» находит это до того, как данные уедут.

Что из этого понял я

Про API мне сказать нечего, а про постановку задачи — есть.

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

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

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

Если хотите повторить у себя

Агент Минимальный путь от клона до первого перенесённого поста:

git clone https://github.com/evstygney/telegram-to-max
cd telegram-to-max && npm install
cp .env.example .env       # заполнить пять значений, см. ниже
npm run probe              # связь с MAX: токен, канал, чтение истории, тестовая отправка
npm start                  # дальше всё в личке с ботом: /practice on → /backfill

В .env нужны пять значений: два токена (Telegram — у @BotFather, MAX — у мастер-бота платформы), собственный Telegram id (бот подскажет его на /start) и два chat_id MAX-каналов, боевого и тестового, — оба покажет npm run get-max-chat-id.

Два условия, без которых ничего не поедет. Telegram-бот должен быть администратором канала: иначе он не получает channel_post и новые посты для него не существуют. MAX-бот должен состоять в целевом канале с правом писать.

Тестовый канал заведите до первого запуска, а не после. Тихого режима в каналах MAX нет, отменить отправку нельзя, и первое знакомство с кнопками лучше пережить в пустом канале на одного зрителя. Сертификат Минцифры отдельно ставить не нужно — он лежит в репозитории и подключён в npm-скриптах.

Где это не работает

• Каналу до сотни постов бот не нужен — настройка двух ботов и сервера дольше ручного переноса.
• Комментарии и реакции не переносятся, только посты.
• Разбор истории требует человека: тысяча постов — тысяча решений.
• Видео тяжелее 20 МБ придётся публиковать руками, пока источник — ботовый API Telegram.
• Всё описанное верно для @maxhub/max-bot-api 0.2.5 и августа 2026. API молодой, поведение меняется; каждая грабля проверяется одной командой.

Краткие выводы

1. fetch failed при работе с MAX указывает на корневой сертификат Минцифры. Лечится переменной окружения, которую нельзя положить в .env.
2. Отправить пост в канал MAX без уведомления подписчиков нельзя. Любой сценарий массового переноса нужно проектировать вокруг этого факта.
3. Картинки в SDK 0.2.5 грузятся буфером, файлы — путём. Дефолтный таймаут в 20 секунд не рассчитан на видео.
4. Поведение незрелого API дешевле измерить, чем вычитать: три варианта вызова в тестовом чате отвечают быстрее, чем документация и типы вместе взятые.

Код целиком — github.com/evstygney/telegram-to-max, MIT, около тысячи строк без сборки и фреймворков. Грабли вынесены в отдельный документ: если пишете своего бота для MAX, он сэкономит вам вечер.

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

Математика неприятная. При конверсии около 3% и полусотне конверсий на вариант случайный разброс легко даёт разницу ±20%. То есть «победа B на 15%» и «победа A на 15%» — равновероятные исходы одной и той же монетки. Чтобы надёжно отличить конверсию 3% от 3,5%, нужны десятки тысяч визитов на вариант — у большинства малых и средних бизнесов столько трафика копится месяцами.

В деньгах Цена вопроса — решения, принятые по шуму: переделали лендинг под «победителя», перекроили оффер, отчитались о росте. Реального эффекта нет, а трафик на тест и время команды потрачены настоящие. Хуже того — вы теперь уверены в цифре, которой не существует.

Решение Два честных пути. Первый — тестировать только крупное: оффер, цену, структуру первого экрана, форму заявки. Там эффект бывает +30–50%, и его видно на скромном трафике. Цвет кнопок оставьте корпорациям с миллионами визитов. Второй — заранее посчитать нужный объём выборки (бесплатные калькуляторы ищутся по запросу «размер выборки A/B-теста») и честно решить: «на нашем трафике тест займёт четыре месяца — принимаем без теста, по здравому смыслу и пяти разговорам с клиентами».

Замечание Осознанное решение без теста лучше решения по фальшивому тесту — как минимум вы помните, что это гипотеза, и следите за ней.

Тест стоит запускать тогда, когда у него есть шанс что-то доказать именно на вашем трафике.

Ваш последний «победивший» вариант — сколько конверсий стояло за той победой?

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

Модельные числа. Кампания на 100 тысячах бюджета даёт CAC 2000 ₽ — 50 клиентов. Подняли до 200 тысяч — средний CAC стал 2600, клиентов 77. Терпимо? Теперь посчитаем маржинальный CAC — почём обошлись клиенты именно со вторых ста тысяч: 27 клиентов, по 3700 ₽ каждый. При марже с клиента 3000 ₽ вторая половина бюджета убыточна, а средняя цифра в кабинете это прячет.

Простыми словами Маржинальный CAC — сколько стоили клиенты с последней добавленной порции бюджета. Решения о масштабировании принимаются по нему, средний оставьте для отчётов.

Решение Наращивать шагами по 20–30% с паузой на стабилизацию, после каждого шага сверять маржинальный CAC с предельно допустимым. Перестало сходиться — расти через новые сегменты, офферы и каналы, вместо доливания в выжатую связку.

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

Вы знаете, сколько клиентов принёс последний вложенный в рекламу рубль, — или только средний по кабинету?

Простыми словами RAG здесь — поиск по смыслу: текст режется на куски, каждый кусок превращается в вектор, вопрос тоже превращается в вектор, дальше ищем ближайшие. Карта (main.md) — файл-оглавление, по строке на каждый проект и раздел базы: агент читает его и понимает, куда идти.

Зачем я полез проверять собственное утверждение

Четыре месяца мой ИИ-агент живёт на файловой памяти: карта воркспейса, память по проекту, база знаний в markdown. Про эту конструкцию была прошлая статья, и в ней я двумя абзацами закрыл тему семантического поиска: инфраструктура ради задачи «не пересказывать проект», результат поиска по эмбеддингам не отревьюишь глазами так же просто, как файл. И оставил себе лазейку: «если у вас тысячи заметок с перекрёстными смысловыми запросами — RAG вернётся в разговор».

Потом я посчитал файлы. Их 3156.

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

База и что в неё вошло

3156 markdown-файлов, 64 МБ текста. Из них 31 МБ — выгрузки таблиц в markdown, куски исследований по 1–2 МБ. Табличные дампы я из индекса выкинул сразу: чанк из такой простыни — набор ячеек без смысла, он будет мусорить выдачу и портить сравнение в пользу карты.

Осталось 1978 файлов и 26 МБ живого текста. При чанках по 600 токенов я прикинул 12–18 тысяч кусков. Реально получилось 29 295 — промах вдвое, потому что заголовков в базе больше, чем я думал, и резка по секциям даёт много коротких чанков. Первый урок дешёвый: считайте чанки токенизатором целевой модели до того, как планировать время индексации.

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

Стек и 18 часов на процессоре

• Эмбеддер: bge-m3, 1024 измерения, мультиязычная. Веса 2,2 ГБ на диске.
• Хранилище: SQLite с расширением sqlite-vec для векторов и штатным FTS5 для BM25. Один файл на 120 МБ, никакого сервера. Векторов мало (29 тысяч), приближённый поиск не нужен — полный перебор укладывается в миллисекунды.
• Поиск: гибрид, вектор и BM25 идут параллельно, результаты сливаются ранговым методом RRF. Это важно для чистоты сравнения: режим RAG получил внутрь и лексический поиск тоже, так что проигрыш нельзя списать на «вектор не знает слова».
• Чанкинг: по заголовкам, 600 токенов, перекрытие 100, метаданные из frontmatter.
• Интерфейс для агента: MCP-сервер с одной тулой search_kb(запрос, k, префикс_пути), отдаёт текст чанков с путями.

Дальше начались измерения, которые я в план не закладывал. Бенчмарк bge-m3 на моём ноутбуке (12 логических ядер, дискретной видеокарты нет) — 0,45 чанка в секунду. Это 18 часов на полный прогон.

Я честно попробовал разогнать. ONNX через onnxruntime — 0,46 чанка/с. Динамическое int8-квантование — 0,42, то есть медленнее. Векторы при этом совпали с исходными до косинуса 1,0, так что квантование как минимум ничего не сломало, просто не помогло. Вывод для тех, кто пойдёт тем же путём: такая модель упирается в пропускную способность памяти, поэтому типовые процессорные ускорители на ней не дают ничего. Индекс собирался ночами, полтора суток по календарю; инкрементальность по SHA-256 спасла, когда прогон оборвался на 60% — второй запуск продолжил с того же места.

Плюсы запросы работают мгновенно. Эмбеддинг вопроса — десятые доли секунды, поиск по 29 тысячам векторов — миллисекунды. Медленная только индексация, и она разовая.

Грабли, на которые я потратил вечер:

Как я мерил, чтобы не обмануть себя

Соблазн при таком замере один: подсознательно подыграть системе, в которую вложил три дня. Поэтому методику я зафиксировал до первого прогона.

Эталонный набор — 24 вопроса, замороженные заранее. 14 точечных (ответ лежит в одном конкретном месте: значение параметра, правило, шаблон ссылки) и 10 обзорных, где ответ собирается из 2–5 файлов разных проектов. К каждому вопросу — список эталонных файлов и ключевой факт, который обязан прозвучать.

Эталоны собирал отдельный агент-разведчик обычными Grep и Glob. Если искать источники правды тем же инструментом, который потом тестируешь, набор молча подгонится под его выдачу. Разведка по двум вопросам поправила меня: я помнил цифры не так, как они записаны в базе. Формулировки этих двух вопросов я привёл к тому, что реально лежит в файлах.

Два режима, одинаковые условия Режим R: агенту доступна только поисковая тула, читать можно лишь файлы из её выдачи. Режим G: только main.md, Grep, Glob и чтение. Одна и та же модель, один и тот же промпт, жёсткий лимит 15 вызовов инструментов, свежая сессия на каждый вопрос — 48 прогонов.

Слепое судейство Судья получал вопрос, эталон и два обезличенных ответа со сменным порядком внутри пары. Какой ответ чьей системы — он не знал.

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

Весь эксперимент — 72 агентских прогона и около 3 миллионов токенов.

Числа

Ничьих по решению судьи — 6, все на точечных вопросах. Общий счёт по всем 24 вопросам: 9:9.

Про значимость сразу и честно. Ничья 9:9 сама по себе не говорит ничего. Каждая половина по отдельности тоже не дотягивает до значимости: двусторонний знаковый тест даёт p ≈ 0,07 на точечных и p ≈ 0,11 на обзорных. А вот разворот между типами вопросов держится: точный тест Фишера на таблице 2×2 (тип вопроса × победитель) даёт p ≈ 0,015. То есть выборка мала для утверждения «RAG лучше на точечных на столько-то», но достаточна для утверждения «тип вопроса меняет победителя».

Где семантический поиск выиграл

Точечный факт достаётся с тем же качеством, что у grep, и почти вдвое дешевле по шагам. На четырёх вопросах хватило одного вызова: спросил человеческим языком — получил канонический файл с нужной строкой. Режим G на тех же вопросах шёл цепочкой: карта → раздел → файл → чтение, четыре-пять шагов.

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

В шагах 2,3 против 4,1 на точечных вопросах. Для агента шаг — это чтение файла в контекст, то есть деньги и место в окне. На сотне точечных запросов в неделю разница заметна в счёте.

Где проиграл

На обзорных вопросах RAG находил правильные файлы (0,69 против 0,77 — почти паритет), но ключевой факт передавал вдвое реже: 0,50 против 0,80. Два показательных случая.

Потерянный статус Вопрос: «где всё, что касается интеграции с внешним рекламным API, и в каком она состоянии». Режим R собрал механику целиком — порядок вызовов, авторизацию, ограничения. И не сказал главного: работа стоит на паузе. Строка про статус живёт во frontmatter памяти проекта, короткая, тематически не похожая на вопрос о содержании — в топ выдачи она не попала. Режим G прочитал README проекта и увидел статус в шапке файла.

Полный промах Вопрос: «какие материалы у нас есть по такой-то теме и в каком проекте они лежат». Режим R сжёг 12 вызовов из 15, не достал ни одного эталонного файла и собрал ответ по косвенным упоминаниям в соседних проектах — с ошибками в деталях (насчитал три материала вместо четырёх и потерял ещё один). Канонический README проекта утонул среди тематически похожих чанков. Режим G дошёл через карту за 4 вызова с полным попаданием.

Ноль галлюцинаций на 48 прогонов — единственная метрика, где системы одинаково хороши. Оба режима отвечали строго от источников, разница была в полноте.

Почему так вышло

Гипотеза механизма, которую я вынес из разбора: вектор ищет похожее, карта хранит каноническое. На вопрос «где правда про X» похожесть — плохой заменитель авторитетности. Канонический документ и десять чанков, упоминающих X по касательной, для эмбеддера выглядят одинаково релевантными; карта же прямо указывает: вот источник правды.

Отсюда три следствия, которые видно в числах:

1. Мета-слой не попадает в чанки. Статус, владелец, дата, «что уже закрыто» лежат во frontmatter и README — короткими строками, не похожими на содержательный вопрос. Поиск по смыслу их системно недооценивает.
2. Чанк теряет место в дереве. Принадлежность файла проекту записана структурой каталогов; в тексте самого чанка её нет. Grep со списком путей эту структуру видит бесплатно.
3. Карта — уже посчитанный слой синтеза. Кто-то (я или агент по моим правилам) один раз проделал работу по агрегации и записал результат. RAG каждый раз выводит картину заново из фрагментов и на этом теряет.

Отдельно отмечу: BM25 у режима R был внутри гибрида. Проигрыш на обзорных вопросах не объясняется тем, что «вектор не знает точных слов» — не хватало именно курирующего слоя.

Где мой тест врёт

• 24 вопроса — мало. Разворот значим, абсолютные величины разрывов — нет. На другой базе цифры поедут.
• Судья — модель, и один на вопрос. Я перепроверил выборку оценок руками и согласился с ними, но полноценной второй разметки человеком не было.
• Число вызовов — самоотчёт агента. Телеметрию рантайма я не снимал: порядок величин верный, точность до десятых — нет.
• Время не сравнивал. У режима R оно искажено загрузкой модели и очередью к общему серверу; честный замер требовал бы отдельной обвязки.
• Соперник — не голый grep, а ухоженная карта. Это сознательный выбор: я сравнивал с реальной своей навигацией. На базе без карты и README расклад на обзорных вопросах почти наверняка сместился бы в пользу RAG. Если вы прикидываете RAG на свалку из тысячи заметок — мой результат к вам применим только наполовину.
• Вопросы придумывал я, зная базу. Я старался держаться человеческого языка и подальше от лексики документов, но полностью снять этот эффект нельзя.
• Прогоны шли в два захода (упёрся в лимит сессии), продолжение делалось с кэшем. На слепоту судейства это не влияло.

Что с этим делать

Если вы стоите перед тем же выбором для своей базы:

Оставить карту руками Слой синтеза окупается на обзорных вопросах и не воспроизводится поиском по смыслу автоматически. Двадцать минут в неделю на обновление статусов дают то, чего 18 часов индексации не дали.

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

Считать чанки заранее — токенизатором целевой модели. Оценка на глаз промахнётся: разница между «прикинул 15 тысяч» и «получил 29 тысяч» — это разница между вечером и двумя ночами.

Проверить на своей базе Методика переносится за вечер: 20–25 вопросов с эталонами (самая дорогая часть, часа полтора), два режима с одинаковым лимитом шагов, обезличенные пары, слепой судья. Заморозьте набор до первого прогона — иначе замер превратится в подгонку.

Краткие выводы

1. Семантический поиск по личной базе окупается на точечных фактах: то же качество за половину шагов. На вопросах «собери картину» он теряет статусы и рамку и проигрывает курируемой карте 8:2.
2. Тип вопроса определяет победителя сильнее, чем сам инструмент. Общий счёт 9:9 без разбивки по типам не значит ничего.
3. Локальный bge-m3 на процессоре — 0,45 чанка в секунду, и ускорители тут не помогают. Планируйте ночи, делайте индексацию инкрементальной.
4. Курируемая карта оказалась сильным соперником, которого в сравнениях RAG обычно не измеряют: меряются с поиском по ключевым словам, а живой человек, поддерживающий оглавление, в сравнение не попадает.

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

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

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

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

В деньгах Прикидка: лид стоит 5000 ₽, менеджер тратит на квалификацию полчаса. Если 40 лидов из 100 — люди, которым нужна была только цена и которым она не подошла, вы ежемесячно платите 200 тысяч плюс 20 часов отдела продаж за работу, которую мог сделать один абзац на сайте.

Решение Дать опору: вилка «от и до», три пакета с ценами, примеры проектов с бюджетами («проект такого объёма обошёлся в N»). Ответ «у нас всё индивидуально» этому не мешает — индивидуальный расчёт прекрасно живёт рядом с честным «от». Лидов станет меньше, сделок обычно столько же, стоимость сделки падает.

Замечание В энтерпрайзе с чеками от десятков миллионов скрытая цена — норма рынка, там её на сайте никто и не ищет. Речь про средний сегмент, где клиент сравнивает пятерых поставщиков за один вечер.

Скрытая цена перекладывает работу фильтра с сайта на рекламный бюджет и менеджеров — по цене лида за каждую проверку.

Сколько ваших лидов за прошлый месяц спросили цену и пропали — и что мешало им узнать её без звонка?

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

Почему «вставь оффер в чат и спроси» не работает

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

Это лечится не формулировкой промпта, а конструкцией. Опор три.

Опора 1. Заземление: карта пути и чужие слова

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

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

Живой язык 15–25 дословных цитат реальных людей о категории продукта: отзывы (свои и конкурентов), форумы, переписки с продажами, вопросы из заявок. Цитаты дают лексику, страхи и возражения, которых носитель знания о своих клиентах либо не знает, либо стесняется. Персонаж, говорящий языком реальных отзывов, реагирует на оффер заметно ближе к рынку, чем персонаж на литературном русском.

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

Опора 2. Состав: в группе должно быть кому не купить

Десять «средних довольных клиентов» дадут десять оттенков вежливого «да». Ценность прогона — в разбросе, поэтому персонажи разводятся по осям: сегмент × этап пути × отношение к категории (минимум два скептика) × осведомлённость о проблеме × платёжеспособность относительно чека.

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

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

Опора 3. Протокол прогона и принудительный реализм

Каждый персонаж проходит пять шагов независимо от остальных:

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

Самый информативный шаг — второй. Расхождение пересказа с замыслом автора — это и есть слепая зона формулировки, найденная механически, без экспертных оценок. Модельный пример (прикидка, не из реального проекта): оффер «ведение соцсетей под ключ для малого бизнеса за 30 000 ₽/мес» персонажи пересказывают как «будут постить за меня картинки» и «30 тысяч за посты?!» — обещание «клиенты из соцсетей» не пересказал никто, потому что в оффере его нет, оно есть только в голове автора.

Второй ингредиент — принудительные искажения. Живые респонденты дают социально приличные ответы, путают детали, рационализируют прошлые решения задним числом, уходят от неудобных тем, заполняют пробелы памяти выдумкой и ленятся. Всё это прописывается в карточку и протокол явно: искажения — в 25–40% ответов, треть ответов — односложные («ну да», «долго, не дочитал, что по цене?»). Зазор между «что говорит про бюджет» и «что реально готов потратить» — обязательное поле карточки.

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

Одна сверка с реальностью

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

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

Пять типовых промахов синтетики

Накопились за несколько исследований; предупреждают большинство ошибок интерпретации.

1. Путает «единичного фаворита» и «универсальность». Фичу, полезную во всех сценариях понемногу, синтетика недооценивает — драматургия персонажа требует одного яркого фаворита. Спрашивайте отдельно «что главное» и «что полезно везде».
2. Тянет выводы в яркие личные драмы. История про страх весит в синтетическом отчёте больше, чем скучное «непонятно, что входит в цену» от шести персонажей из десяти. Взвешивайте по частоте: реальный агрегат ответов суше и логистичнее синтетического.
3. Пропускает скучные факторы. Погода, доставка в регион, ассортимент, состояние дорог — то, что не делает персонажа интересным, выпадает из ответов. Добавляйте такие факторы в протокол явно.
4. Сглаживает нюансы до полюсов. «Иногда, если недалеко» превращается в «да» или «нет». Сохраняйте оговорки и условия — в них половина пользы.
5. Склеивает look-alike сегменты с противоположными рецептами. «Мне надо пощупать руками» и «хотел купить онлайн, но в мой город не везут» внешне дают одинаковое «не купил онлайн» — а лечатся противоположными действиями. Разводите такие пары руками при синтезе.

Протокол целиком

Для повторения руками в любом LLM-чате с доступом к файлам — или без автоматизации вовсе:

1. Интервью о бизнесе: продукт и чек → группы покупателей → чем решают сейчас и почему не покупают → карта пути с причинами отвала → 5–10 живых фраз клиентов → артефакт проверки (оффер, текст лендинга, тарифы, сообщение).
2. Грунд-сбор: 15–25 цитат о категории из открытых отзывов и форумов, с пометкой «дословно / близко к тексту». Цитаты не выдумываются — либо нашлись, либо их нет, и это честно понижает доверие к прогону.
3. Десять персонажей по осям, из них 2–3 контрольных с конкретными причинами отвала. В каждой карточке — зазор «говорит/реально» по деньгам и 1–2 адаптированные живые цитаты.
4. Калибровка состава заказчиком. Без подтверждения прогон не запускается.
5. Прогон: пять шагов на персонажа, независимо, с принудительными искажениями.
6. Отчёт: пересказы против замысла → возражения, отсортированные по частоте → слепые зоны → водораздел «кому попадает / кому нет» → причины отказа контрольной группы → список «что проверить на живых» → 3–5 правок формулировок «было → стало».

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

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

Где метод не работает

• Количественные решения. Ранжирование фич, доли сегментов, ценовая чувствительность, прогноз конверсии — за пределами метода, см. таблицу выше.
• Категории без открытого следа. Узкий B2B, энтерпрайз под NDA: живых цитат не собрать, заземление держится на одном интервью — доверие к прогону ниже, и это стоит честно указывать в отчёте.
• Замена исследований. Это нулевая итерация: репетиция перед живой аудиторией, генератор гипотез и фильтр очевидных ошибок. Отчёт без блока «что проверить на живых» — признак, что инструментом пользуются для самоуспокоения.

Краткие выводы

1. Синтетические персонажи надёжно находят проблемы формулировок и типовые возражения; количественные ответы остаются за живыми исследованиями.
2. Метод держится на трёх опорах: заземление в живых цитатах, контрольная группа «не купит», принудительный реализм ответов. Любая из трёх опущена — получаете генератор комплиментов с уверенным тоном.
3. Сверяйте с реальностью при первой возможности: одна параллельная сверка синтетического и живого исследования калибрует доверие к методу лучше любых рассуждений о нём.
4. Протокол воспроизводим руками; упакованная версия — интервью, генерация карточек, прогон и отчёт по шаблонам — в репозитории synthetic-customers (MIT, скилл для Claude Code, работает и как простая текстовая инструкция для других агентов).

Пробовали синтетических респондентов в работе? Интереснее всего, на чём они врали у вас — копилка промахов выше пополняется именно так.

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

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

Решение Попросите три вещи в каждом отчёте: план/факт по деньгам (заявки, сделки, выручка — что доступно), динамику к прошлому периоду по тем же метрикам и честный раздел «что не получилось и что меняем». Добросовестный подрядчик от такой просьбы выдыхает с облегчением — прятать провалы утомительно.

Замечание Красивый отчёт сам по себе не приговор. Приговор — когда на вопрос «а где выручка?» отвечают «это сложно атрибутировать» и быстро листают на следующий слайд.

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

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

Модельный пример. Интернет-магазин: средний чек 3000 ₽, маржа 35%, доставка обходится в 350 ₽. В среднем всё прекрасно. Теперь разрез по корзинам: 35% заказов — до 1500 ₽. Считаем такой заказ отдельно: маржа 525 ₽, минус доставка 350, минус эквайринг, упаковка и обработка — заказ в нуле или в минусе. Его дотируют крупные корзины, а «в среднем» всё по-прежнему прекрасно.

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

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

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

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

Одной строкой: средние показатели скрывают структуру, а прибыль живёт в структуре.

Вы знаете, с какой суммы заказ становится для вас прибыльным, — и какая доля заказов сейчас ниже этой планки?

Простыми словами ИИ-агент — это LLM с доступом к файлам и терминалу (Claude Code, Cursor, Codex CLI). Он читает и пишет файлы на вашем диске по инструкциям на естественном языке. Дальше считаю, что вы таким пользовались.

Почему не хватает того, что есть из коробки

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

Длинная сессия Контекстное окно конечно, при переполнении история сжимается автосаммари. Что именно выживет при сжатии — вы не контролируете: первыми обычно теряются мотивировки решений («почему выбрали B, а не A»), сами решения остаются. И сессия всё равно когда-нибудь закрывается.

Один большой CLAUDE.md Рабочий приём до определённого размера. Дальше файл превращается в свалку: контексты десяти проектов вперемешку, агент тащит в каждую задачу всё подряд, стоимость и шум растут.

Встроенная память агента У Claude Code есть автоматическая память. Она полезна, но непрозрачна ровно настолько, насколько автоматична: вы не выбираете, что в неё попадёт, она не переносится между инструментами и не читается глазами как единый документ.

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

Файловый воркспейс закрывает ту же задачу дешевле: обычные папки и markdown, полная прозрачность (всё читается глазами и лежит в git), переносимость между агентами. Плата — дисциплина структуры. Её и разбираем.

Архитектура: три контракта

За четыре месяца структура устоялась такой (35 проектов, база знаний на 15 тем):

workspace/
├── main.md                  ← карта: все проекты и разделы, по строке на каждый
├── CLAUDE.md                ← контракт поведения: агент читает сам при старте
├── AGENTS.md                ← однострочник «читай CLAUDE.md» для других агентов
├── .claude/skills/          ← автозапуск навыка-хранителя (шим, о нём ниже)
├── _inbox/                  ← приёмник непонятного; разбирается раз в неделю
├── _meta/templates/         ← шаблоны: README проекта, память, wiki-заметка
├── rules/global/            ← правила устройства воркспейса
├── skills/                  ← навыки агента (источники)
├── knowledge-base/
│   ├── AGENTS.md            ← контракт ведения базы знаний
│   └── <домен>/main.md      ← карта домена + страницы
└── projects/<имя>/
    ├── README.md            ← что это и зачем
    ├── memory.md            ← память проекта: агент читает первым
    ├── docs/ prompts/ assets/
    └── app/                 ← код, отдельный git-репозиторий

Несущих элемента три, остальное — обвязка.

Контракт №1: memory.md на проект Файл с фиксированными секциями: что это за проект, ключевые решения с мотивировками, текущий статус, следующий шаг, договорённости с агентом. Правило в CLAUDE.md: при входе в проект читать память первой, после значимого шага — обновлять. Новая сессия стартует не с нуля, а с последнего чекпоинта. По сути это ручной, человекочитаемый снапшот контекста — и в отличие от автосаммари, что в него попадает, решаете вы (точнее, агент по вашим правилам, а вы ревьюите глазами).

Контракт №2: main.md как карта По строке на проект и домен знаний. Агенту не нужно сканировать дерево, чтобы понять, что где лежит: одна загрузка карты — и он знает, куда идти. Это же спасает от дублей: прежде чем создать проект, агент сверяется с картой.

Контракт №3: правила поведения, записанные файлами. Договорённость «клади файлы аккуратно» агент забудет со сменой сессии — контракт должен лежать там, откуда он читается автоматически. У меня это три уровня: CLAUDE.md в корне (краткий контракт, подхватывается при старте), правило в rules/ (полная версия с обоснованиями) и навык-хранитель в skills/ (операционные рецепты: куда положить, как назвать, какой frontmatter). Тройное дублирование намеренное: инструкции для LLM исполняются вероятностно, и вероятность соблюдения растёт с числом мест, откуда правило может попасть в контекст.

Замечание База знаний устроена отдельным паттерном — три слоя с разными правами записи: raw/ (первоисточники, агент только читает), wiki-страницы (агент пишет и перезаписывает), схема-контракт (меняется редко, руками). Плюс правило противоречий: новый факт, конфликтующий со старым, не затирает его молча, а помечается блоком с указанием источников. Это тема отдельной статьи; схема лежит в references репозитория.

Допущения, которые пришлось принять

Каждое решение в структуре — ответ на конкретный отказ. Три показательных.

Архив вместо удаления Агент (и человек) плохо предсказывает, что «точно больше не понадобится». Правило: ничего не удаляется, устаревшее переезжает в archive/ рядом с оригиналом. Перемещение обратимо, удаление — нет, а диск дешевле восстановления удалённого.

Латиница и kebab-case в путях Кириллица и пробелы в путях ломаются на стыках: git на разных ОС, shell-скрипты, часть инструментов. Контент заметок — на любом языке, пути — только latin-kebab-case. Скучное правило, которое экономит часы отладки.

Код отдельно от заметок Код проекта живёт в app/ со своим git-репозиторием; workspace-репозиторий его игнорирует (projects/*/app/ в .gitignore). У кода и заметок разные жизненные циклы: заметки хочется коммитить пачкой раз в день, код — атомарно и с CI.

Паттерн «шим»: один источник для навыка

Инженерная деталь, на которой я застрял. Claude Code автоматически подхватывает навыки из скрытой .claude/skills/, а «витринная» skills/ воркспейса для него — просто папка с файлами. Хочется и автозапуск, и видимый пользователю источник. Держать две копии — гарантированный рассинхрон: правишь одну, вторая молча устаревает.

Решение В .claude/skills/workspace-organizer/SKILL.md кладётся файл-переадресация: тот же YAML-frontmatter с description (по нему движок решает, когда навык триггерить), а вместо тела — три строки: «прочитай и выполни ../../../skills/workspace-organizer/SKILL.md; здесь ничего не редактировать». Автотриггер работает, источник один, дублируется только description. Если источник переименуют или удалят — шим прямым текстом скажет об этом пользователю и предложит восстановить навык повторным запуском мастера.

Инструкция для LLM — это код. Тестируйте соответственно

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

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

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

• План не совпадал с постройкой. Дерево, которое мастер показывает пользователю для подтверждения («строим вот это, ок?»), было короче того, что реально создаётся на следующем этапе. Пользователь подтверждал один набор, получал другой.
• Невыполнимая ветка. «Если тем для базы знаний нет — создай домен по профессии из блока 2». А в блоке 2 пользователь сказал «работаю и всё». Профессии нет, ветка виснет. Агент выкрутился сам (создал нейтральный домен work), но это была его догадка, не моя инструкция.
• Самопротиворечие. «Создай пустую папку _inbox/ (и положи в неё README)». Папка с файлом — не пустая. Мелочь, но свежий исполнитель споткнулся и записал в журнал.
• Молчание про плейсхолдеры. Шаблоны копируются в воркспейс «как есть», с {{PROJECT_NAME}} внутри — а конвенция «подставляй значения вместо {{...}}» нигде не была записана для будущих сессий.
• Пустые папки и git. Каркас создаёт пустые docs/, prompts/, assets/ — а git пустых папок не хранит. Первый же клон воркспейса потерял бы половину структуры. В инструкции не было ни слова.

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

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

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

Грабли дистрибуции, собранные лбом

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

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

Где подход не работает

• Команда. Всё выше — про одного человека. Совместная память на файлах упирается в merge-конфликты человеческих решений; для команды нужен другой контур согласования, у меня его нет.
• Поиск по смыслу. Здесь нет эмбеддингов: агент ходит по картам (main.md) и grep'у. На моих объёмах хватает; если у вас тысячи заметок с перекрёстными смысловыми запросами — RAG вернётся в разговор.
• Протухание памяти. memory.md обновляет агент, агент подчиняется правилу вероятностно. Без еженедельной ревизии («разбери inbox, обнови статусы») память дрейфует от реальности. Ритуал занимает минут двадцать, но он обязателен — это цена подхода.
• Другие агенты. Структура переносима (markdown есть markdown), но автозапуск навыков — механика Claude Code. В Cursor тот же контракт приходится скармливать через AGENTS.md, триггер слабее.

Краткие выводы

1. Память агента между сессиями решается файлами: memory.md на проект + карта + правила, записанные там, откуда агент читает их автоматически. Дорогая инфраструктура для этой задачи не нужна.
2. Инструкции для LLM исполняются вероятностно. Контракт стоит дублировать по уровням (CLAUDE.md → правило → навык), а критичные конвенции записывать явно, даже если агент «и так догадался».
3. Инструкция для LLM — это код. Тестируйте её как код: свежий исполнитель без знания замысла + сценарий худшего пользователя + журнал неоднозначностей. 16 находок на «трижды перечитанном» тексте — моя цена этого урока.
4. Дистрибуция текста ломается как софт: YAML, пути, скрытые папки, порядок активации. Таблица граблей выше сэкономит вам вечер.

Каркас воркспейса, скилл-мастер с интервью, шаблоны и обе справки — в репозитории ai-workspace-starter (MIT). Ставится за 15 минут, работает без программирования.

А ваш агент завтра утром помнит, почему вы вчера выбрали вариант B, а не A? Если нет — посчитайте, сколько минут в день вы тратите на пересказ контекста, и умножьте на цену своего часа.

Интересно, как эту задачу решаете вы: файлы, встроенная память, RAG, что-то своё? И переживает ли ваш вариант смену сессии без пересказа проекта с нуля?

Разложим, куда уходит время. Месяц — онбординг: доступы, погружение в бизнес, «а почему у вас так настроено». Ещё месяц-полтора — перезапуск кампаний: автостратегии Яндекса обучаются заново, и пока учатся, CPA гуляет на 20–40% выше нормы (прикидка из практики, зависит от объёма данных). Параллельно теряется контекст: какие гипотезы уже проверяли, какие креативы выгорели, почему отключили те ключи. Новый подрядчик честно проверит всё это ещё раз — за ваши деньги.

В деньгах При бюджете 1 млн в месяц три месяца просадки на 25% — порядка 750 тысяч переплаты за тот же результат. Плюс часы вашей команды на пересказ всего с нуля.

Решение Менять по симптомам, которые реально требуют замены: нет прозрачности, нет доступов к вашим же кабинетам, цифры отчётов не бьются с CRM. Обещание «минус 30% CPA» от нового агентства симптомом не считается — это цена входа в переговоры, а не расчёт. И главное: кабинеты и счётчики изначально оформляйте на себя — тогда накопленное обучение кампаний переезжает вместе с вами, и три месяца сжимаются до одного.

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

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

Ваши рекламные кабинеты оформлены на вас — или при разводе с агентством вы начнёте с нуля?

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

Замечание Обратная ловушка тоже работает: «включили рекламу — продажи выросли» на старте сезона доказывает силу сезона, а вклад рекламы — ещё нет.

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

Решение Честный тест отключения делается с контрольной группой: выключаем в части регионов, оставляем в остальных, сравниваем динамику между группами. Окно наблюдения — минимум два цикла покупки, для большинства ниш это 6–10 недель. Дольше и скучнее, зато вывод стоит на данных, а ставкой в нём не рискует вся выручка.

Недельное окно измеряет инерцию вашего спроса. Вклад рекламы на нём не виден в принципе.

Если завтра выключить весь платный трафик, через сколько недель вы это почувствуете — и готовы ли столько ждать ради чистоты вывода?

В B2B перед сделкой на миллионы ваш сайт изучают внимательно — и даты смотрят обязательно. Свежий кейс говорит «они в форме прямо сейчас». Кейс пятилетней давности говорит «когда-то умели». Логотипы гигантов из прошлой жизни не спасают: рядом с ними должно лежать хоть что-то из этого года.

В деньгах Коварство в невидимости потерь: клиент, которого смутила устаревшая витрина, не оставляет заявку — он молча уходит, и в CRM его нет. Сколько сделок проиграно на этом этапе, вы не узнаете никогда. Прокси-замер: спросите пять последних проигранных клиентов, что смутило при изучении компании. «Не нашли свежих работ» звучит чаще, чем приятно слышать.

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

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

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

Какой год стоит на самом свежем кейсе вашего сайта?

Механика простая. Выручка просела на 15% — бюджет автоматически режут на 15%. Меньше рекламы — меньше новых клиентов — выручка проседает дальше. Правило снова требует резать. Каждый виток этой спирали компания проходит своими руками, строго по регламенту.

Обиднее всего, что происходит это ровно в тот момент, когда трафик дешевеет. Конкуренты на спаде тоже режут бюджеты, аукцион остывает, клик стоит на 20–30% меньше обычного (прикидка, зависит от ниши). Правило «процент от выручки» уводит вас с рынка именно тогда, когда долю на нём раздают со скидкой — и забирает её тот, кто остался.

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

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

Бюджет от процента выручки смотрит в зеркало заднего вида, бюджет от юнит-экономики — на дорогу. На растущем рынке разница незаметна, на падающем она стоит доли рынка.

Что произойдёт с вашим бюджетом при просадке выручки на 20% — и есть ли в этом сценарии хоть одно решение, кроме «резать»?

Числа модельные, картина из практики. Было: 300 заявок в месяц, два менеджера, конверсия в сделку 12% — 36 сделок. Собственник доволен, бюджет удваивают. Стало: 600 заявок и те же два менеджера. Время ответа выросло с 10 минут до 3 часов, заявки остывают, менеджеры хватают только «горячих». Конверсия падает до 7% — 42 сделки.

В деньгах Бюджет вырос вдвое, сделок стало больше на 17%. Стоимость сделки выросла примерно на 70%. Половина новых заявок оплачена и потеряна — при этом в рекламных отчётах всё отлично: заявки же пришли.

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

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

Замечание Обратное тоже верно: если менеджеры сидят без заявок, долить трафика обычно дешевле, чем держать простаивающую команду.

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

Сколько заявок в день способен переварить ваш отдел продаж — и знает ли эту цифру тот, кто планирует рекламный бюджет?

Простыми словами CAC — стоимость привлечения одного нового клиента: расходы на привлечение делим на число новых клиентов.

Кабинетная версия: рекламный бюджет 300 тысяч, 100 новых клиентов — CAC 3000 ₽. С этой цифрой идут принимать решения.

Теперь честная версия. Добавим зарплату маркетолога и комиссию подрядчика — 150 тысяч. Контент, дизайн, лендинги — 50 тысяч. Промокод на первую покупку — минус 10% чека. Эквайринг, доставка первого заказа, возвраты. Реальный CAC выходит 5500–6000 ₽. Числа модельные, но пропорция из практики: полный CAC в полтора-два раза выше кабинетного.

В деньгах Опасность не в самой цифре, а в решениях по ней. При марже с первого заказа 4000 ₽ кабинетный CAC 3000 говорит «масштабируем, окупаемся сразу». Реальный 5500 говорит «окупаемся только со второго заказа — сначала проверьте, есть ли у вас повторные покупки». Это два разных бизнес-решения, и одно из них убыточное.

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

Коротко: заниженный CAC опасен тем, что экономика с ним сходится на бумаге и расходится на расчётном счёте.

Ваш CAC — он с зарплатами и скидками или только с рекламным бюджетом?

Компания продаёт «надёжность и экспертизу», а сайт кричит про «сроки от 3 дней». Или наоборот: клиенты покупают за скорость, а на сайте — миссия, ценности и «комплексный подход». Реклама приводит людей под одно обещание, отдел продаж закрывает другим аргументом, и на стыке конверсия тихо умирает.

В деньгах Прикидка: лид в B2B стоит 3000–8000 ₽. Если 30 из 100 лидов пришли за обещанием, которое вы на звонке не подтверждаете, — вы оплатили их зря. При сотне лидов в месяц это 100–250 тысяч ежемесячно за трафик, который почти не мог сконвертироваться.

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

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

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

За что вам на самом деле платят — и написано ли это на вашей главной странице?

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

Модель

Магазин: выручка 100 млн ₽/год, себестоимость товара 60 млн, реклама 15 млн, прочие расходы (фикс) 20 млн. Прибыль — 5 млн. Маржинальность по вкладу (цена минус себестоимость к цене) — 40%.

Рычаг 1: +10% к бюджету

Реклама 15 → 16,5 млн. В линейном мире это +10% выручки, но линейного мира нет: горячая аудитория уже выкуплена, каждый следующий клиент дороже предыдущего (подробно про предельные величины и насыщение каналов — [статья про классифайд и Директ]). Возьмём оптимистичные +6% выручки:

• Выручка: +6 млн → 106 млн
• Себестоимость: +3,6 млн → 63,6 млн
• Реклама: +1,5 млн → 16,5 млн
• Прочие: без изменений
• Прибыль: 5 → 5,9 млн (+0,9 млн)

Почти миллион — неплохо. Запомним и посчитаем соседний рычаг.

Рычаг 2: +10% к цене

Подняли цены на 10%, потеряли 10% покупателей в штуках — сценарий, которого обычно и боятся:

• Выручка: 0,9 × 110 = 99 млн (просела на 1%)
• Себестоимость: на 10% меньше штук → 54 млн
• Реклама и прочие: без изменений → 15 + 20 = 35 млн
• Прибыль: 99 − 54 − 35 = 10 млн (+5 млн, ×2)

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

Формула допустимого оттока

Главный страх — «уйдёт слишком много». У «слишком» есть точное значение. Пусть m — маржинальность по вкладу, p — процент повышения цены. Прибыль не уменьшится, пока потеря объёма q не превышает:

q = p / (m + p)

Вывод в одну строку: приравниваем вклад до и после, (1−q) · (m+p) = m, и выражаем q. Таблица порогов для +10% к цене:

Читается так: при марже 40% вы остаётесь при своей прибыли, даже если уйдёт каждый пятый покупатель. Уйдёт меньше — вы в плюсе. Низкомаржинальный бизнес защищён ещё сильнее: при 20% маржи надо потерять треть покупателей, чтобы повышение не окупилось.

Замечание Формула сравнивает прибыль по вкладу и молчит о выручке — а с выручкой связаны бонусы команды, ковенанты и амбиции. Решение «минус оборот, плюс прибыль» стоит проговорить до теста.

Поправка на LTV

Формула считает разовые сделки. Если клиент покупает повторно, потерянный покупатель уносит не одну маржу, а поток будущих — и порог ужесточается: в формулу вместо маржи сделки подставляйте маржу жизненного цикла клиента, а повышение цены — только по тем позициям, где оно не рвёт удержание. Для подписочных моделей и частых повторных покупок консервативнее считать q по LTV-марже; порог получится заметно ниже табличного.

Где рычаг ломается

• Сравнимость в один клик. Маркетплейсы, агрегаторы, идентичный SKU у десяти продавцов: эластичность зашкаливает, +10% к цене — минус позиция в сортировке и кратная потеря штук. Формула честно скажет «нельзя», если подставить реальный отток.
• Конкурентная реакция. В узкой нише сосед может не подняться следом — и таблица допустимого оттока встретится с реальностью раньше времени. Страховка — тест на части ассортимента, не фронтальное повышение.
• Психологические пороги. Одинаковые +10% переживаются по-разному: 990 → 1089 перескакивает через круглую тысячу и бьёт сильнее, чем 890 → 979. Учитывается на уровне конкретных позиций.
• Регулируемые и контрактные цены. Долгие договоры, тендеры, госцены — рычаг двигается раз в цикл перезаключения, не когда захотелось.

Как тестировать

1. Снять маржинальность по вкладу флагманских категорий — из управленки, не из ощущений.
2. Посчитать порог q по формуле (для повторных — по LTV-марже).
3. Поднять цену на одной категории (или в одном регионе), сопоставимую оставить контролем.
4. Мерить 4–6 недель штуки, выручку, вклад против контроля. Потеря меньше порога — раскатывать дальше; больше — откатить. Откат стоит один клик, что выгодно отличает этот тест от большинства маркетинговых экспериментов.

Откуда числа P&L модельный, проценты округлены для читаемости; +6% выручки на +10% бюджета — оптимистичное допущение (реальную кривую насыщения снимайте по своей истории трат). Формула порога — арифметика вклада, проверяется подстановкой за минуту.

Краткие выводы

1. На модельной экономике +10% к цене дал +5 млн прибыли, +10% к бюджету — +0,9 млн. Асимметрия структурная: надбавка цены не тянет затрат.
2. Допустимая потеря объёма считается, а не угадывается: q = p / (m + p). При марже 40% повышение на 10% терпит уход 20% покупателей.
3. Для бизнеса с повторными покупками порог считать по LTV-марже — он жёстче.
4. Рычаг не работает при сравнимости в один клик и требует теста на части ассортимента с контролем.

Бюджет вы пересматриваете каждый месяц — а когда последний раз пересматривали цену флагманской категории и считали её порог оттока по формуле, а не по ощущению «клиенты уйдут»? Если тестировали повышение — сколько покупателей потеряли фактически против расчётного порога?

Как это устроено. В отчёте по last-click вся заслуга достаётся тому, на что кликнули последним: ретаргетингу и брендовому поиску. CPA у них красивый — условные 800 ₽ против 4000 ₽ у охватных кампаний. Логичное решение: перелить бюджет из «дорогого» верха в «дешёвый» низ. Отчёт становится ещё красивее.

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

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

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

Last-click измеряет, кто дожал клиента, и молчит о том, кто его привёл. Оптимизация только по нему срезает будущий спрос.

Какая доля вашего бюджета работает на людей, которые про вас ещё не знают?

За 10 лет в перформансе я видел десятки случаев, когда кампанию к сезону запускали за неделю до его конца. Креатив был готов в июле, а «финальное финальное» согласование закончилось в сентябре. Аукцион, сезон и спрос никого не ждали.

В деньгах Представьте: сезонный пик длится 8 недель и приносит 40% годовой выручки. При обороте 200 млн это 80 млн, по 10 млн в неделю. Каждая неделя согласований на старте пика — 10 млн выручки, за которую вы даже не поторговались. Прикидка грубая, но порядок цифр отрезвляет.

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

Решение Посчитайте стоимость недели задержки для каждой кампании и впишите её прямо в задачу на согласование. «Согласовать баннер (цена вопроса — 10 млн выручки сезона)» двигается по цепочке заметно бодрее, чем просто «согласовать баннер».

Замечание Контроль нужен, юристы тоже. Речь про третий и четвёртый круг правок, где меняют оттенок синего и двигают логотип на два пикселя.

Подведём итог: скорость решений — статья расходов, просто её нет в P&L, поэтому её никто не защищает на бюджетном комитете.

Сколько недель у вас занимает путь от «идея» до «запустили» — и кто-нибудь считал, во что обходится каждая из них?

Маркетолог показывает собственнику дашборд: лиды растут, стоимость заявки падает, всё зелёное. Собственник смотрит на кассу — а касса стоит. Знакомая сцена в B2B на сотни миллионов выручки. Я Егор, перформанс-маркетолог; причина тут обычно скучнее заговора: маркетинг физически не видит, чем его заявки закончились в продажах, — и чинится это не платформой за миллионы, а неделей аккуратной работы. Разберём минимальную схему. Числа в примерах — модельная прикидка, не из реального проекта.

Что строим

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

Зачем — одна таблица вместо тысячи слов. Два канала, одинаковый месячный бюджет ~150–160 тыс. ₽:

По CPL канал A лучше в три раза, по стоимости сделки — хуже в полтора, по выручке — вдвое. Отчёт «лиды и CPL» рекомендует масштабировать A; отчёт до денег — B. Обе рекомендации логичны, данные разные.

Пять элементов схемы-минимум

1. Скрытые поля формы. В каждую форму сайта — hidden-поля: utm_source, utm_medium, utm_campaign, client_id счётчика, landing_url, дата. Заполняются скриптом из URL и куки при загрузке страницы; при отправке уезжают вместе с заявкой. Час работы фронтендера.

2. Поля в CRM. Те же атрибуты — на карточке лида, не в комментарии («пришёл с рекламы» аналитикой не считается). Плюс жёсткое правило: лид без источника не создаётся, для ручного ввода есть значение manual/менеджер.

3. Телефония. Половина B2B-заявок — звонки, и без привязки звонка к источнику схема дырявая. Минимум без затрат — отдельные подменные номера на канал (статический коллтрекинг): грубо, зато бесплатно и честно. Динамический коллтрекинг точнее, но это уже бюджет — в схему-минимум не входит.

4. Нормализация контактов. Матчить сделку с лидом будем по телефону и email. +7 (912) 345-67-89, 89123456789 и 8-912-345-67-89 — один человек и три разные строки; без приведения к единому формату (E.164, нижний регистр для почты) джойн потеряет треть связок.

5. Витрина. Один запрос, который собирает всё:

SELECT
  l.utm_source, l.utm_campaign,
  count(DISTINCT l.id)                          AS leads,
  count(DISTINCT d.id)                          AS deals,
  sum(d.amount)                                 AS revenue,
  sum(d.amount) / NULLIF(count(DISTINCT d.id),0) AS avg_deal,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY d.closed_at - l.created_at) AS median_cycle
FROM leads l
LEFT JOIN deals d
  ON (d.phone_norm = l.phone_norm OR d.email_norm = l.email_norm)
 AND d.created_at BETWEEN l.created_at AND l.created_at + INTERVAL '180 days'
GROUP BY 1, 2;

Окно 180 дней — под длинный цикл; для быстрых ниш хватит 60–90. Выгрузку из рекламных кабинетов с расходами приклеиваете к этой же витрине по utm_campaign — получаете CPA сделки и ДРР по каналам.

Дыры схемы — честный список

Схема-минимум дырявая по построению; важно знать, где именно.

• Доля несматченных сделок. Часть сделок не свяжется ни с одним лидом (пришли ногами, по рекомендации, телефон другой). Эту долю выводите в витрину явной строкой unmatched. Пока она под 20–30% — выводы по каналам работают; 60% несматченных — это отчёт о качестве данных, решения по нему принимать рано.
• Last touch в CRM — это last touch. Источник у лида один, а касаний до заявки могло быть пять. Про то, как правило приписывания искажает картину и что с этим делать, — [статья про атрибуцию]; здесь важно помнить: витрина отвечает «через какую дверь вошёл», без претензии на полный вклад канала.
• Фан-аут джойна раздувает выручку. Джойн по phone OR email связывает сделку со всеми подходящими лидами: если их несколько, sum(d.amount) сложит сумму сделки столько раз, сколько лидов она поймала, — а count(DISTINCT d.id) покажет 1, и метрики разъедутся. Прежде чем суммировать, сверните связку к одному лиду на сделку (last touch или первый лид по времени) — иначе выручка по каналам не сойдётся с фактической.
• Ручной ввод. Менеджеры будут заводить лиды мимо правил — валидация телефона на входе и дефолт manual спасают частично. Доля manual в витрине — метрика дисциплины отдела продаж, за ней стоит следить отдельно.
• Офлайн-первые касания. Выставка, вебинар, звонок по визитке — размечаются только руками (поле «офлайн-источник»). Дёшево и криво, но лучше пустоты.
• Малые числа. 4 и 6 сделок из таблицы выше — это ещё не статистика, это повод копить окно в 2–3 квартала до жёстких решений о каналах.

План на неделю

• День 1–2. Hidden-поля на все формы; поля источника в CRM; правило «лид без источника не создаётся».
• День 3. Нормализация телефонов и почт (миграция по старым записям + триггер на новые).
• День 4–5. Витрина-джойн, приклейка расходов, строка unmatched. Первый отчёт «источник → сделки → выручка».
• Дальше и навсегда. Дисциплина заполнения. Это самая трудная часть проекта, и она не техническая: договорённость с руководителем продаж о том, что доля manual и unmatched — общая метрика двух отделов, стоит любых регламентов.

Когда схемы-минимум мало

• Много каналов и звонков — нужен динамический коллтрекинг, статика перестаёт различать кампании.
• Розничные офлайн-точки в цепочке — без систем лояльности/промокодов связку не собрать.
• Нужен вклад каналов по всей цепочке касаний — это мультитач и эксперименты, отдельная лига по сложности и цене.

Откуда числа Таблица каналов — модельная прикидка для иллюстрации расхождения CPL и CPA сделки; SQL — схема запроса (псевдо-Postgres), поля переименуете под свою CRM. Пороги (окно 180 дней, unmatched 20–30%) — практические ориентиры, не стандарт индустрии.

Краткие выводы

1. Канал с лидами втрое дешевле может приносить сделки в полтора раза дороже — видно это только в витрине «источник → выручка».
2. Схема-минимум = hidden-поля + поля в CRM + телефония + нормализация контактов + SQL-витрина. Неделя работ без покупки платформ.
3. Дыры (unmatched, ручной ввод, офлайн, last touch) не отменяют пользу — они требуют выводить качество данных в ту же витрину явной строкой.
4. Самое трудное — дисциплина заполнения: это договорённость двух отделов, и никакой SQL её не заменит.

Какая доля сделок в вашей CRM имеет заполненный источник — вы её хоть раз считали? Если строили такую связку руками — обо что споткнулись сильнее всего? У меня в топе нормализация телефонов.

Простыми словами ДРР — доля рекламных расходов в выручке: потратили 2 млн при выручке 20 млн — ДРР 10%.

Посчитаем на модельных числах, маржа 30%. Вариант первый: ДРР 8%, выручка 20 млн — после рекламы остаётся 22% × 20 = 4,4 млн. Вариант второй: ДРР 12%, выручка 35 млн — остаётся 18% × 35 = 6,3 млн. Процент хуже, прибыли на 1,9 млн больше.

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

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

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

Посмотрите последний отчёт по рекламе: вы оптимизируете процент или рубли прибыли?

В регламенте отдела продаж написано: на заявку отвечаем за 15 минут. В выгрузке из той же CRM p90 времени ответа — четыре часа, и в команде об этом никто не подозревает. Я Егор, перформанс-маркетолог; десять лет я оптимизировал то, что слева от заявки, — ставки, креативы, посадочные, — пока не увидел, что справа, между «лид упал в CRM» и «менеджер взял трубку», теряется больше. Разберём, как замерить это у себя и не обмануться выгрузкой. Все числа — модельная прикидка, не из реального проекта.

Что меряем

Простыми словами Время первого ответа (first response time, FRT) — интервал между созданием заявки и первым исходящим контактом по ней: звонком, письмом, сообщением. Не «взял в работу» в CRM, а реальным касанием клиента.

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

Модель остывания, на которую дальше будем смотреть критически:

В деньгах при CPL 1500 ₽: заявка, отвеченная на следующий день, стоит вам тех же полутора тысяч, но приносит почти впятеро меньше квалов. Цена квалифицированного лида (назовём её эффективным CPL): 12 500 ₽ при ответе в первые пять минут — и 60 000 ₽ при ответе назавтра. Реклама в обоих случаях отработала одинаково.

Как снять замер у себя

Понадобятся два таймстампа на заявку: создание и первый исходящий контакт. Дальше — запрос уровня:

SELECT
  date_trunc('week', l.created_at)            AS week,
  l.source,
  extract(hour FROM l.created_at)             AS hour_of_day,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY a.first_touch - l.created_at) AS median_frt,
  percentile_cont(0.9) WITHIN GROUP (ORDER BY a.first_touch - l.created_at) AS p90_frt,
  count(*) FILTER (WHERE a.first_touch IS NULL) AS never_answered
FROM leads l
LEFT JOIN (SELECT lead_id, min(created_at) AS first_touch
           FROM activities WHERE direction = 'outbound' GROUP BY lead_id) a
  ON a.lead_id = l.id
GROUP BY 1, 2, 3;

Три решения в этом запросе важнее самого запроса.

• Медиана и p90, не среднее. Пара заявок, отвеченных через неделю, утащит среднее в космос; медиана покажет типичный случай, p90 — хвост, в котором и живут потери.
• LEFT JOIN и счётчик never_answered. Заявки, по которым исходящего контакта не было вообще, — самая дорогая категория, и при INNER JOIN она молча исчезает из отчёта.
• Разрез по источнику и часу. Без него следующий раздел превратит ваш замер в самообман.

Четыре ловушки корреляции

Наивная выгрузка «FRT против конверсии» почти всегда покажет эффект сильнее реального. Причины:

1. Время суток. Ночные и выходные заявки получают медленный ответ — и они же по составу холоднее дневных (импульсные, «просто прицениться»). У медленности и низкой конверсии здесь общая причина — час поступления заявки; прямой связи в таких данных меньше, чем кажется. Обход: сравнивать скорость с конверсией внутри одного часового слота, а слоты — между собой отдельно.

2. Источник. Заявкам с «горячих» каналов менеджеры отвечают быстрее — видят знакомый источник и хватают. В общей выгрузке это читается как «быстрый ответ конвертит», хотя работает интент канала. Обход: разрез по источнику обязателен, сравнение — только внутри источника.

3. Обратная причинность. Опытный менеджер быстрее берёт заявки, которые выглядят жирными (крупный запрос, знакомая компания). Скорость здесь следствие качества лида. Обход до конца не существует; частично помогает сравнение по менеджерам с разной дисциплиной на одинаковом пуле.

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

Замечание После очистки от всех четырёх эффект остывания обычно сохраняется, но сжимается — условно с «в 5 раз» из наивной выгрузки до «в 2–3 раза». Этого всё равно достаточно, чтобы SLA первого ответа был дешевле любого улучшения кампаний: он не требует бюджета вообще.

Чего без эксперимента не узнать

Честная причинная оценка требует рандомизации — случайно задерживать ответ половине клиентов. Такой тест дорог и этически сомнителен, делать его не предлагаю. Доступные квазиэксперименты:

• Естественные провалы. Отпуска, болезни, недоукомплектованные смены — периоды, когда скорость падала по внешним причинам при том же трафике. Сравнение конверсии таких периодов с обычными — грубая, но честная оценка.
• До/после внедрения SLA. Ввели дежурство и алерты — сравните квартал до и после с поправкой на сезон и структуру источников. Слабее рандомизации, сильнее голой корреляции.

Что делать практику

1. Снять факт: медиана и p90 FRT по источникам и часам, доля неотвеченных. По регламенту у всех «15 минут»; по факту я видел p90 в часах у команд, искренне уверенных в обратном.
2. Поставить SLA в минутах на рабочие часы и отдельное правило на ночь/выходные (автоответ с обещанием времени + первый слот утра).
3. Алерт, который невозможно пропустить, — в мессенджер дежурному, не письмом на общую почту.
4. Пересчитать эффективный CPL по корзинам скорости — это аргумент, который переводит разговор с «менеджеры стараются» на язык денег.

Где это не работает

• Тендерный и комитетный B2B. Когда решение принимает закупочная процедура месяцами, минуты первого ответа решают мало — там важнее полнота ответа.
• Заявка-бронь. Если форма — запись на конкретный слот (клиника, сервис), интерес зафиксирован самой записью, остывание слабое.
• Премиум с консьержем. Там скорость и так в SLA, а сделку решает качество сопровождения.

Откуда числа Таблица остывания и CPL — модельная прикидка: форма кривой согласуется с известными исследованиями скорости ответа (InsideSales/HBR о кратном падении контактируемости после первых минут) и с тем, что я видел в выгрузках за 10 лет, но ваши коэффициенты будут своими. Метод замера выше — как раз способ их снять.

Краткие выводы

1. Время первого ответа — метрика денег: остывшая заявка стоит столько же, а конвертит в разы хуже. Эффективный CPL по корзинам скорости делает это видимым.
2. Мерить медиану и p90 с разрезом по источнику и часу; неотвеченные заявки держать в знаменателе.
3. Наивная корреляция преувеличивает эффект: время суток, источник, обратная причинность и выжившие работают на приукрашивание. После очистки эффект меньше, но остаётся.
4. SLA первого ответа — редкий рычаг конверсии с нулевым медиабюджетом.

Какая у вас медиана и p90 времени первого ответа — по факту из CRM? И в чём измеряется ваш хвост p90 — в минутах или в сутках?

Смотрите, что постоянная скидка делает с экономикой. Товар за 1000 ₽, себестоимость 600, маржа 400. Дали −20% — продаёте за 800. Маржа упала с 400 до 200, то есть вдвое. Чтобы вернуть ту же прибыль, надо продать не на 20% больше штук, а в два раза больше. Акция почти никогда столько не добавляет.

Что происходит с базой Клиент быстро обучается. Он видит, что у вас раз в месяц −20%, и перестаёт покупать по полной — просто ждёт следующую распродажу. Вы своими руками приучили лучшую часть аудитории не платить полную цену. Теперь даже те, кто купил бы и так, ждут купон.

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

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

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

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

Какая доля ваших продаж проходит вообще без скидки — по полной цене, потому что продукт того стоит?

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

Как устроена цена клика

Простыми словами В аукционах семейства второй цены (GSP/VCG — на них исторически строятся торги в поисковой рекламе) победитель платит не то, что поставил сам, а чуть больше ставки следующего за ним участника.

Из этого свойства растут два следствия, которые двигают всю статью.

Первое: ваша ставка — это не ваша цена. Это цена того, кто стоит над вами. Подняв ставку и оставшись вторым, вы не потратили ни рубля дополнительно — но подняли счёт лидеру.

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

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

Симуляция: шесть ходов войны

Три участника. A и B воюют за первое место, C — фоновый игрок со ставкой 30 ₽, которую не меняет. Шаг цены — 1 ₽. A и B перебивают друг друга по очереди, каждый раз с запасом ~20%.

Что произошло за шесть ходов. Цена топ-клика выросла с 41 до 105 ₽ — в 2,6 раза. Число показов в категории не изменилось, конверсия сайта не изменилась, покупателей больше не стало: вся дельта — плата за очерёдность между двумя участниками. А второе место весь матч стоило 31 ₽ — его цена определяется фоновым C и войной вообще не задета.

Теперь в лидах. При конверсии клика в заявку 3% лид с первой позиции на ходе 5 стоит 3 500 ₽, со второй — 1 033 ₽. Разница трафика между первой и второй позицией — процентов 15–25 кликов (зависит от трафарета и запроса). То есть на ходе 5 участники платят тройную цену лида за пятую часть дополнительного объёма. Если экономика не отбивает такой предельный CPL — топ в этом аукционе покупать просто не нужно, и таблица сообщает это до списания бюджета.

Потолок ставки: формула

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

max_CPC = маржа_на_клиента × CR(клик → сделка)

Маржа на клиента — с учётом повторных покупок, если они есть. И вот здесь гонка решается ещё до первого хода.

Продавец с разовой сделкой: маржа 5 000 ₽, конверсия клика в сделку 1,2% → потолок 60 ₽. Конкурент с подпиской или повторными покупками: маржа на клиента за горизонт 16 000 ₽, та же конверсия → потолок 192 ₽. Вернитесь к таблице: на ходе 3 цена топа (73 ₽) уже выше потолка первого игрока — каждый следующий клик приносит ему убыток, который он увидит в P&L через месяц. Второй же может спокойно сидеть в войне до 190 ₽ и пересидит любого «разового» соперника. Не потому, что лучше настроил кампанию — у него длиннее экономика клиента.

Простыми словами Гонку ставок выигрывает тот, кто больше зарабатывает на одном покупателе за всю его жизнь. Ставка — только видимая часть; торгуются на самом аукционе LTV двух бизнесов.

При чём тут автостратегии

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

• Занизили целевой CPA → робот сам выйдет из подорожавшего аукциона, и вы увидите падение трафика. Это не «стратегия сломалась» — это ваш потолок сработал как задуман.
• Завысили → робот будет исправно финансировать чужую гонку вашими деньгами, а отчёт покажет «рост CPA по рынку».

Война ставок между двумя автостратегиями с завышенными целями выглядит ровно как таблица выше, только раунды занимают минуты вместо недель.

Что делать практику

• Посчитать потолок по формуле для каждой кампании. Маржа на клиента × конверсия клика в сделку, по данным CRM, не по средним из головы. Это одна ячейка в таблице, а решает больше, чем недельная оптимизация ставок.
• Сравнить потолок с фактической ценой топа (отчёты о доле выигрышей и цене позиций в кабинете). Потолок ниже — не воевать: вторая-третья позиция, как видно из симуляции, может стоить втрое дешевле при сопоставимом объёме.
• Уходить туда, где сосед не торгуется. Низкочастотные и длинные запросы, свой сегмент, гео и часы с меньшей конкуренцией: та же аудитория часто достаётся по цене фонового игрока C.
• Поднимать потолок, а не ставку. Потолок растёт от двух вещей: конверсии (оффер, посадочная, скорость ответа на заявку) и маржи на клиента (повторные продажи, средний чек). Каждый пункт конверсии сверху — это законное право торговаться выше без убытка. У соперника этого права от вашей ставки не убавится, а вот экономику вашу оно догонит.

Где эта модель врёт

• Симуляция — учебная. Живой аукцион считает ставку с прогнозом CTR и качеством объявления, объём трафика по позициям задают трафареты, участников больше двух, и они меняются по часам. Числа в таблице иллюстрируют механику; свой аукцион замеряйте своими отчётами.
• Не всякая дорогая ниша — «война». Иногда клик дорожает, потому что в аукцион пришли игроки с честно большей экономикой (страховки, финансы, недвижимость). Против LTV-преимущества тактика ставок бессильна — там конкурируют продуктом.
• Полный уход из топа имеет цену. На витринных запросах первая позиция — ещё и элемент присутствия: уступив её надолго, вы отдаёте не только клики, но и привычку аудитории видеть вас первым. Эффект медленный и на коротком окне не измеряется — честно говорю, что в формулу потолка он не входит.

Откуда числа Ставки, конверсии и маржи — модельная прикидка на округлённых числах; шаг перебивки 20% и разница трафика позиций 15–25% — типовые ориентиры из практики. Метод воспроизводится на своих данных: цена позиций — из отчётов кабинета, конверсии и маржа — из CRM.

Краткие выводы

1. В аукционе второй цены ваша ставка задаёт цену сопернику сверху. Гонка двух участников кормится их же повышениями: в симуляции топ-клик подорожал в 2,6 раза при неизменном трафике.
2. Второе место в той же войне стоило 31 ₽ против 105 ₽ у топа — при разнице объёма в 15–25%. Предельная цена этого объёма и есть решение, покупать ли первое место.
3. Потолок ставки = маржа на клиента × конверсия клика в сделку. Гонку выигрывает длинная экономика клиента, и автостратегии этого не отменяют — они лишь исполняют заданный вами потолок быстрее.
4. Потолок поднимают конверсия и LTV. Ставка без них — только взнос в выручку площадки.

Посмотрите цену клика в своём главном аукционе год назад и сейчас: если она выросла на десятки процентов при том же трафике, кто-то финансирует чью-то гонку — возможно, вашу. Считали ли вы свой потолок ставки по CRM-данным — и насколько он ниже фактической цены топа?

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

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

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

Что чинить Не сайт и не новые каналы. Сквозную аналитику до выручки: чтобы по каждому источнику было видно не «сколько заявок», а «сколько денег и с каким циклом сделки». Тогда маркетинг начинает крутить экономику, а не отчётность.

Замечание В B2B это труднее, чем в e-com: длинный цикл, сделки в CRM ведут руками, часть закрывается офлайн. Идеальной точности не будет. Но даже грубая привязка лида к сделке меняет то, на что тратится бюджет.

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

По каким источникам вы знаете не стоимость лида, а стоимость закрытой сделки?

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

Почему CPL здесь не метрика

Простыми словами Классифайд — площадка объявлений, куда покупатель приходит с уже сформированным спросом и выбирает из витрины (авто, недвижимость, техника, услуги). Контекст — реклама по поисковым запросам, которая перехватывает спрос раньше, на этапе выбора.

Сравнивать их по цене лида мешают три вещи.

Лид ≠ лид Контакт с классифайда — человек, который посмотрел конкретный товар с ценой и фото и нажал «позвонить». Лид из Директа — заявка с лендинга, часто на этапе «расскажите подробнее». Конверсия в сделку у них отличается в разы, поэтому сравнение по CPL сломано уже на входе.

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

У обоих есть неинкрементальная доля. Часть контактов с платного продвижения вы собрали бы и без него — с органической позиции в той же витрине. В Директе ту же роль играют брендовые запросы. Про это ниже отдельно.

Считаем на модели

Вводные: продавец товара длительного выбора, маржа на сделке — 40 000 ₽. Классифайд: базовый пакет размещения уже оплачен, считаем только бюджет на продвижение поверх. Конверсия контакта в сделку — 8% (человек звонит по конкретному товару). Директ: CPC 45 ₽, конверсия клика в лид 3%, лида в сделку — 6% (заявка «на разговор»). Разложим бюджет ступенями по 100 000 ₽ и посмотрим на предельные величины — что приносит именно следующая сотня тысяч.

Что видно из таблицы. Первые две сотни тысяч в классифайде покупают сделку за 5–9 тысяч — Директ рядом не стоит. А вот третья сотня тысяч в классифайде приносит сделку уже за 31 250 ₽ — дороже, чем первая сотня в Директе. Вы упёрлись в дно спроса категории: выше витрины не прыгнуть, продвижение начало толкаться само с собой.

Теперь главный фокус. Посчитайте по той же таблице средний CPL классифайда на бюджете 300 000 ₽: 430 контактов, 698 ₽ за контакт — против 1500 ₽ в Директе. По средним классифайд «в два раза лучше», и отчёт скажет: наращивайте. По предельным — третью сотню тысяч надо было отнести в Директ. Средние величины прячут перелом; видно его только на ступенях.

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

Поправка на инкрементальность

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

Классифайд Вы и без продвижения стоите в выдаче — на неё приходит органическая доля контактов. Продвижение поднимает вас выше, но часть «купленных» контактов — те же люди, которые долистали бы и до старой позиции. Если инкрементальность продвижения 80%, предельный CPA всех ступеней делится на 0,8 — и перелом в таблице сдвигается на более раннюю ступень.

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

Честный способ снять оба коэффициента — эксперимент: отключить продвижение на части объявлений (или бренд-кампанию на части регионов) и сравнить с контролем. Грубый способ — сравнить динамику контактов в месяцы с продвижением и без, если такие были в истории.

Метод целиком

1. Развести природу лидов. Снять свои конверсии в сделку отдельно для контактов классифайда и лидов контекста — из CRM, не из ощущений.
2. Построить ступени. По истории трат (или тестами с шагом в месяц) снять предельные контакты и лиды на каждую следующую порцию бюджета.
3. Поправить на инкрементальность оба канала — экспериментом или хотя бы грубой оценкой по истории.
4. Заполнять от дешёвой предельной сделки к дорогой. Лить в канал, пока его предельный CPA не сравняется с предельным CPA соседа, — и переключаться. Оптимум — равные предельные цены сделки, а не «весь бюджет в канал с лучшим средним».
5. Пересматривать раз в квартал. Кривые насыщения плавают по сезону и конкуренции; точка перелома — не константа.

Где метод ломается

• В категории нет живого классифайда — сравнивать нечего, вопрос закрыт географией спроса.
• Малые бюджеты. На 50 000 ₽ в месяц ступени не построить: шума больше, чем сигнала. Тогда проще тест «месяц туда, месяц сюда» с одинаковой посадкой.
• B2B и сложные услуги. Там, где сделка закрывается полгода и вручную, предельный CPA считается только при связке маркетинга с CRM — без неё метод не запустится.
• Классифайд не создаёт спрос. Он собирает сформированный. Если задача — вывести новый продукт или категорию, у витрины вас ещё никто не ищет; тут работает охват и контекст по смежным запросам, и сравнивать каналы по CPA сделки рано.
• Зависимость от площадки. Складывая 100% производительности в один классифайд, вы отдаёте рычаг цен его прайс-листу — говорю это, работая на той стороне. Диверсификация каналов стоит денег — считайте это ценой страховки.

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

Краткие выводы

1. Лид классифайда и лид Директа — разные сущности с разной конверсией в сделку. Сравнение каналов начинается с CPA сделки, снятого из CRM.
2. Классифайд насыщается об дно спроса категории; в модели третья сотня тысяч подняла предельный CPA с 5 000 до 31 250 ₽. Средний CPL этот перелом прячет.
3. Оба канала требуют поправки на инкрементальность: органическая позиция в витрине и брендовые запросы приписывают каналам чужие продажи.
4. Рабочее правило сплита: заполнять каналы от дешёвой предельной сделки к дорогой до выравнивания предельных цен.

Посчитайте предельный CPA последней сотни тысяч в вашем главном канале — вы уверены, что она всё ещё дешевле первой сотни в соседнем? И знаете ли вы, на каком бюджете у вас наступает перелом?

Цифра, которую неприятно проверять у себя: по разным замерам, ответ на заявку в первые 5 минут доводит её до сделки в разы чаще, чем ответ через час. Не на проценты — в разы. Человек оставил заявку на пике желания, и это желание остывает по минутам. Через час он уже листает конкурентов или передумал вовсе.

В деньгах Реклама привела заявку за 1500 ₽. Менеджер перезвонил через два часа и попал на «спасибо, я уже купил в другом месте». Полторы тысячи — в мусор, и так с каждой остывшей заявкой. Это дороже, чем любой неоптимизированный ключ в кампании.

Где обычно дырка Заявки падают на почту, которую смотрят два раза в день. Или в CRM без уведомлений. Или менеджер обедает, а лиды копятся. Реклама при этом работает идеально — деньги утекают между «заявка пришла» и «менеджер её увидел».

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

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

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

Через сколько минут в среднем у вас отвечают на заявку — и кто-нибудь это вообще считает?

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

В деньгах Допустим, клик стоил 50 ₽. Вы с соседом месяц бодаетесь за первое место — клик стал 80 ₽. Трафик тот же, конверсия та же, но каждый лид подорожал на 60%. Никто не вырос, оба заплатили больше.

Кто выигрывает гонку Тот, у кого выше LTV. Он может позволить себе дорогой клик, потому что отбивает его на втором и третьем заказе. Если у вас разовая продажа, а у соседа подписка или повторные покупки, в лобовой гонке ставок вы проиграете заранее — он вас просто пересидит.

Решение Не выигрывать там, где у вас нет преимущества по экономике. Уходить в запросы, где конкурент не торгуется, в свой узкий сегмент, в рост LTV (это честно поднимает ваш потолок ставки) — а не толкаться лбами по общим высокочастотным запросам.

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

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

За какие запросы вы бодаетесь прямо сейчас — и выше ли у вас LTV, чем у того, с кем бодаетесь?

Это когда человек уже знает вашу компанию, гуглит её по названию, кликает по вашему же объявлению наверху выдачи и покупает. Агентство ставит эту продажу себе в результат. А купил бы он и так — название-то он вбил сам, по памяти.

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

Прикидка по рунету: в нишах с узнаваемым именем на брендовые запросы приходится 20–40% «рекламных» продаж в отчёте. При бюджете 1 млн в месяц это 200–400 тыс., размазанных по людям, которые уже ваши.

Как проверить Попросите разбить отчёт на два: брендовые запросы (с вашим названием) и небрендовые (категория, конкуренты, общие слова). Работу рекламы — сколько новых клиентов она приводит — видно только во второй части. Первая — это скорее налог на узнаваемость, чем заслуга канала.

Замечание Совсем выключать брендовую рекламу обычно нельзя: уберёте — на ваш запрос встанет конкурент и перехватит готового клиента. Но считать её отдельно и не платить агентству процент за «защиту вашего же имени» — можно и нужно.

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

Какая доля ваших «рекламных» продаж — это люди, которые и так искали вас по названию?

Привет, я Егор. 10 лет в performance-маркетинге, через мои руки прошли миллиарды рублей рекламных бюджетов — точную цифру не назову, NDA. Сегодня разберём атрибуцию — механизм, из-за которого в отчётах наказывают правильные каналы и премируют неправильные. Будут числа, таблица и разбор допущений. Все цифры в статье — модельная прикидка, не из реального проекта; важна логика, а сами числа условны.

Что не так с last-click, если по-взрослому

Определение для порядка, одной строкой.

Простыми словами Атрибуция — это правило, по которому вы делите одну продажу между несколькими рекламными касаниями, которые к ней привели. Last-click отдаёт 100% заслуги последнему клику перед покупкой.

Last-click часто списывают на «неточность». Точность тут ни при чём: он смещён в одну сторону систематически. Последним касанием почти всегда оказывается то, что стоит у самого края покупки: брендовый поиск (человек уже решил и вбил ваше имя), ретаргет (догнали того, кто и так возвращался), прямой заход. А то, что создало спрос за две недели до этого — охватная кампания, статья, видео, — в момент покупки уже не «последнее» и получает ноль.

Дальше включается управленческая логика, и она губительна. В отчёте верх воронки убыточен → его режут → спустя лаг проседает и низ, потому что брендовый поиск не берётся из воздуха, его кто-то должен был создать. Классический способ зарезать себе продажи, глядя в «объективный» отчёт.

Считаем на модели

Возьмём простую воронку из двух касаний. Канал A — охватная кампания (создаёт спрос, работает вверху). Канал B — брендовый/ретаргет (собирает уже прогретых внизу). 1000 покупок, у каждой был путь. Разложим одни и те же покупки по разным моделям атрибуции.

Пусть реальные пути такие (это вход модели, помечаю честно):

• 400 покупок: касание только B (пришли по бренду сами, A их не касался);
• 100 покупок: касание только A (увидели охват, купили без брендового догона);
• 500 покупок: сначала A, потом B (охват создал спрос, бренд/ретаргет закрыл).

Теперь смотрим, кому разные модели припишут эти 1000 покупок.

Одни и те же 1000 покупок. По last-click канал A принёс 100 продаж, по first-click — 600. Разница в шесть раз — следствие одного только выбора правила деления заслуги. Округление и «погрешность атрибуции» тут ни при чём. Если вы платите бонус команде по last-click, канал A выглядит кандидатом на отключение. Отключаете — и теряете те 500 покупок «A→B», где охват был обязательным первым звеном. В отчёте следующего месяца это прилетит как падение брендового поиска, и виноватым назначат совсем другой канал.

Замечание Position-based и linear не «правильнее» last-click. Они просто размазывают заслугу по другому произвольному правилу. Строки position-based и linear совпали не случайно: на путях из двух касаний схема 40/20/40 вырождается в 50/50 — среднего касания, которому положены 20%, здесь просто нет. Ни одна строка в таблице не измерила, что было бы, если бы канала A не было. А именно это — единственный вопрос, который имеет значение.

Почему «выбрать правильную модель» — неправильная постановка

Здесь обычно начинается спор, какая модель атрибуции лучше. Спор беспредметный: все модели отвечают на вопрос «как поделить», а бизнесу нужен ответ на вопрос «что изменится, если убрать канал». Это разные вопросы, и второй атрибуцией в принципе не решается.

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

Простыми словами Атрибуция считает, через какие двери прошли покупатели. Инкрементальность считает, скольких покупателей эти двери реально привели, а не просто оказались у них на пути.

Что измеряет вклад канала: эксперимент

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

• Holdout / PSA-тест. Выключаем канал (или показываем плейсхолдер) на случайной доле аудитории, смотрим разницу в конверсии между теми, кто видел, и контрольной группой. Разница — это инкремент. Так проверяют ретаргет и брендовый поиск, и результат регулярно неприятный: часть «заслуженных» продаж случилась бы и без показа.
• Geo-lift. Гео-эксперимент: в части регионов канал крутим, в сопоставимой части — нет, разницу выручки чистим статистикой (тот же принцип, что в A/B, только единица — регион). Рабочий инструмент для охватных каналов, которые нельзя разрезать по пользователю.
• Инкрементальность самого дорогого канала — в первую очередь. Мерить всё сразу не нужно. Начните с канала, в который льёте больше всего денег и которому last-click рисует лучшие цифры: там цена ошибки максимальная.

Чем плох этот метод (честно) Эксперименты стоят денег и времени: вы сознательно недопоказываете рекламу части аудитории и на время теряете часть выручки в контрольной группе — это плата за знание. Geo-lift шумит на малых объёмах и требует сопоставимых регионов, которых не всегда хватает. Holdout по брендовому поиску технически неудобно ставить. Идеальной чистоты не будет.

Чем хорош Это единственный метод из перечисленных, который отвечает на главный вопрос: что будет, если канал убрать. Одна честная цифра инкремента по дорогому каналу переигрывает любой красивый дашборд атрибуции.

Что с этим делать практику в понедельник

Если бюджета на эксперименты и data-driven атрибуцию нет — вот минимум, который снимает большую часть боли:

• Смотрите на коридор из моделей. Положите рядом last-click и first-click по каждому каналу. Канал, который по last-click «убыточен», а по first-click — герой, трогать нельзя без эксперимента: это ваш верх воронки. Расхождение моделей — это карта того, кто создаёт спрос, а кто собирает.
• Вынесите брендовый поиск в отдельную строку и не смешивайте с небрендовым. Его «заслуги» — самые спорные, и именно он раздувает last-click.
• Считайте лаг. Если после паузы охватного канала брендовый поиск падает через 2–4 недели — вы только что наблюдали инкрементальность бесплатно, самым болезненным способом.
• Для дорогого канала поставьте один holdout или geo-тест. Не ради науки — ради того, чтобы не резать бюджет вслепую по показаниям заинтересованной стороны.

Откуда числа Все значения в таблице и в примерах — модельная прикидка на round-числах для наглядности, не выгрузка из реального проекта. Ваши распределения путей будут другими — потому и стоит снять их у себя и посмотреть, насколько сильно расходятся модели именно в вашей воронке.

Где этот разбор не работает

• Короткий цикл, один канал, мало данных. Если у вас 50 заказов в месяц и один источник, вся эта история про мультитач избыточна — там атрибуция не проблема номер один.
• Оффлайн-конверсии и длинный B2B. Когда сделка закрывается руками в CRM через полгода, ни одна модель атрибуции клика туда не дотянется — там нужна сквозная аналитика до выручки, это отдельный разговор.
• Data-driven атрибуция (Markov / Shapley) не отменяет эксперимент. Она делит заслугу умнее — по вероятностям путей, — но вопрос у неё тот же: «как поделить». Инкремент из неё не достать. Лучше linear, но holdout не заменяет.

Краткие выводы

1. Last-click смещён систематически: хвалит низ воронки, топит верх. Так устроено само правило деления заслуги.
2. Любая модель атрибуции — произвольное правило деления заслуги. На одних и тех же 1000 покупок last-click и first-click разошлись в шесть раз.
3. «Что изменится, если убрать канал» отвечает только эксперимент — holdout или geo-lift. Начинать с самого дорогого канала.
4. Без бюджета на эксперименты — минимум это коридор из двух моделей (last- и first-click) и брендовый поиск отдельной строкой.

А какой моделью атрибуции размечен ваш дашборд прямо сейчас — вы её выбирали осознанно, или она досталась по умолчанию? Если по умолчанию — велик шанс, что вы уже год премируете не тот канал.

Собственник скажет «продажи». РОП — «нормальные лиды, а не как сейчас». Маркетолог — «узнаваемость, трафик и поддержка отдела продаж». Каждый после этого возвращается к работе над своей версией. Бюджет один, направления три.

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

Решение Одно предложение, написанное собственником и подписанное всеми тремя: «Задача маркетинга на этот год — X, измеряем по Y, бюджет Z». Например: «Поток квалифицированных лидов для отдела продаж, метрика — лиды по согласованному чек-листу не дороже N ₽, всё остальное — по остаточному принципу».

Замечание Формулировка будет неидеальной, и это нормально. Спорная задача, записанная на бумаге, управляется лучше, чем идеальная, живущая у каждого в голове в своей редакции.

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

Проведите этот эксперимент с тремя ответами на ближайшей планёрке — и посмотрите, насколько разойдутся версии.

Покажу на прикидке. Магазин: выручка 100 млн, себестоимость 60, реклама 15, прочие расходы 20. Прибыль — 5 млн.

Способ первый, любимый: добавить +10% к рекламному бюджету. В идеальном мире это +10% выручки. Но реклама не масштабируется линейно — горячая аудитория уже выбрана, каждый следующий клиент дороже предыдущего. Реально получите +5–7%, CAC подрастёт, прибыль почти не сдвинется.

Способ второй: поднять цены на 10%. Часть клиентов отвалится — пусть уйдёт даже 10% продаж. Выручка останется около тех же 100 млн. Но эти «новые» 10% цены легли почти целиком в прибыль: себестоимость на упавших заказах вы уже не платите. Прибыль удваивается — из 5 млн в ~10 млн.

Простыми словами +10% к бюджету собственник чувствует инстинктивно. +10% к цене — страшно: «уйдут клиенты». Уходят не все, а арифметика прибыли — на стороне цены.

Замечание Рычаг ломается там, где товар сравнивают в один клик — маркетплейсы, агрегаторы, идентичный SKU: подняли на 10% — ушло не 10% покупателей, а половина. Работает он там, где сравнить в лоб нельзя: бренд, сервис, бандл, ниша, B2B. Поэтому цену не задирают по всему прайсу «на веру», а поднимают на одной категории и смотрят: при этой экономике можно потерять до 20% покупателей и всё равно выйти в плюс по прибыли. Потеряли больше — откатили.

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

Когда вы последний раз поднимали цены — и что тогда по факту произошло с продажами и прибылью?