Неделя 156. Когда аналитика перестала врать

Неделя 156. Когда аналитика перестала врать

Разбор этой статьи

AI-подкаст BotsellerПочему рекламные алгоритмы не видят реальных денег
0:00 / 0:00

Эту тему разобрали в подкасте. Слушай параллельно с чтением.

Это сто пятьдесят шестая неделя с момента, как мы запустили Botseller в августе 2023 года. Период: с 20 июля 00:00 до 27 июля 00:00 по Москве.

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

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

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

Сырой счётчик недели: 137 записей разработки в 8 рабочих контурах, из них 60 объединённых задач и 77 прямых правок. По объёму это 21,5 тысячи добавленных строк.

Меня зовут Дмитрий Дьяконов, я основатель и CEO Botseller AI. Мы делаем платформу с AI-продавцом, CRM, мессенджерами, автоматизациями, рассылками, календарём и звонками. Каждую неделю я разбираю, что реально сдвинулось в продукте и зачем это нужно бизнесу. Поехали по 156-й.

Пульс недели

Пульс недели 156: 137 записей разработки (60 объединённых задач, 77 прямых правок), 21 481 добавленная строка кода. Фокус недели: офлайн-конверсии и точность данных. Реклама узнаёт о продажах 36 записей, аналитика и точность 24, почта партнёров 14, защита контуров 12, мессенджеры 12.

НаправлениеЗаписей разработкиЧто это значит простыми словами
Реклама узнаёт о продажах36когда лид оплатил, рекламные кабинеты узнают об этом автоматически
Аналитика и точность подсчёта24конверсии перестали теряться, задваиваться и уходить в чужой кабинет
Почта партнёров под своим брендом14письма клиентам уходят от имени партнёра, а не платформы
Защита двух контуров в коде12российские данные технически не могут уйти в зарубежные сервисы
Мессенджеры и каналы12можно написать клиенту первым, появилась пауза между сообщениями
Обновление ядра и техдолг8невидимая работа под капотом

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

Реклама, которая не знает, кто заплатил

Объясню проблему на понятном примере, потому что она касается почти каждого, кто вообще запускает рекламу.

Иллюзия успешной рекламы: бюджет тратится вслепую. Рекламное объявление даёт 100 кликов, из них 20 оставили заявку, но реально купили только 3 клиента. Обратная связь алгоритму идёт только до этапа заявки. Проблема: алгоритмы обучаются на тех, кого вы им показываете. Следствие: система ищет кликеров и любителей заполнять формы, а не тех, кто платит. Реальные продажи остаются невидимыми для рекламного кабинета.

Вы запустили объявление. К вам пришло сто человек. Двадцать из них оставили заявку. Три в итоге купили. Что об этом знает рекламный кабинет? Он знает про сто кликов. Если вы настроили счётчик, он знает про двадцать заявок. Но про три реальные оплаты он не знает ничего.

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

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

Технически это называется офлайн-конверсиями. Данные о продаже, которая случилась уже вне сайта, возвращаются обратно в рекламный кабинет. Крупные компании настраивают это месяцами силами подрядчиков. Малый бизнес не настраивает вообще, потому что не знает, что так можно.

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

Как это работает у клиента

Решение: замыкаем цикл офлайн-конверсиями. Менеджер переводит лида в статус «Оплачено» в CRM, нода автоматизации перехватывает событие, данные о реальной выручке возвращаются в Meta, Google Ads и Яндекс.Метрику. Полный цикл обратной связи замкнут. Теперь алгоритм ищет людей, похожих на плательщиков. Настройка не требует кода: это простая нода в конструкторе автоматизаций, которую вешаешь мышкой.

Ночью с понедельника на вторник мы собрали весь конвейер за шесть заходов подряд.

Теперь это выглядит так. Менеджер переводит лида в статус «Оплачено». Автоматизация ловит это событие и отправляет сообщение в рекламные кабинеты: вот этот человек купил, вот на такую сумму. Платформа поддерживает три направления сразу: рекламный кабинет Meta, Google Ads и Яндекс.Метрику, через которую данные попадают в Директ.

Privacy First: никаких открытых данных. Имя, телефон и почта клиента превращаются в необратимый цифровой отпечаток, и только он уходит в рекламную систему. Безопасность: мы не отправляем контакты в открытом виде. Матчинг: рекламная система понимает, что это тот же человек, но восстановить исходный контакт из отпечатка математически невозможно.

Отдельно скажу про персональные данные, потому что это важно. Мы не отправляем в рекламные системы почту и телефон клиента в открытом виде. Данные превращаются в необратимый цифровой отпечаток, и уже он используется для сопоставления. Рекламная система понимает, что это тот же человек, но восстановить из отпечатка исходный контакт нельзя.

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

Но написать код это только половина

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

А дальше началась та часть, из-за которой я и говорю, что неделя вышла честнее, чем планировалась.

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

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

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

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

Диагностика платформы: системные сбои. Оплаты зарубежных клиентов уходили в российский счётчик и молча отвергались, из-за чего терялись данные о международных конверсиях: теперь счётчик определяется автоматически по домену клиента. Из 11 ключевых действий в маршрут лида попадали только 3, а менеджер тегов в личном кабинете не грузился: добавлены 8 недостающих событий, тег-менеджер подключён через сборку. Уязвимое внутреннее соединение без проверки сертификата закрыто, введён сквозной идентификатор для защиты от задвоения.

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

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

Пятая: боты не будили друг друга. Об этом отдельно, потому что история хорошая.

Боты научились запускать друг друга

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

Мы обнаружили это случайно, тестируя офлайн-конверсии.

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

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

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

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

Неделя, когда аналитика перестала врать

Раз уж мы полезли в аналитику, оказалось невозможным остановиться. Каждая находка тянула следующую.

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

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

Личный кабинет не грузил менеджер тегов вообще. Это, пожалуй, самое обидное. Мы старательно размечали события регистрации и пополнения баланса, а контейнер, который должен был их передавать наружу, в кабинете просто не подключался. События уходили в никуда. Нашли, подключили через сборку.

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

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

Два контура: теперь это защита, а не обещание

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

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

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

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

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

Партнёры получили свою почту

Инфраструктура партнёров: white-label email. При регистрации клиента, если настройки партнёра корректны, письмо уходит от имени домена партнёра. Если партнёр настроил почту криво, срабатывает автопереключение и письмо уходит от платформы. Защита ключей: при смене провайдера система принудительно сбрасывает секретные ключи доступа, чтобы они не утекли в чужую компанию. Главное правило: если партнёр ошибся в настройках, процесс регистрации его клиентов не должен ломаться.

Отдельная большая работа воскресенья, важная для тех, кто продаёт платформу под своим брендом.

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

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

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

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

Мессенджеры: пишем первыми и делаем паузу

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

Две небольшие, но заметные для работы вещи.

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

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

Что с платёжными рельсами

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

Возвращаюсь к тому, с чего начал.

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

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

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

Главный итог недели

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

Эта неделя была про то, что почти вся аналитика в малом бизнесе показывает неправду, и никто об этом не догадывается.

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

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

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

Приходите в Telegram-канал

Если этот формат отчётов вам полезен, подпишитесь на наш Telegram-канал @botseller_ai. Там я каждую неделю выкладываю бортовые журналы и короткие заметки про продуктовые решения, эксперименты и инциденты. Без рекламы, без воды, только то, что мы сами считаем важным.

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

FAQ

Что такое офлайн-конверсии простыми словами?

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

Мои персональные данные клиентов уходят в рекламные системы?

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

Какие рекламные площадки поддерживаются?

Три направления: рекламный кабинет Meta, Google Ads и Яндекс.Метрика, через которую данные попадают в Яндекс.Директ. Набор доступных площадок зависит от контура: на российском контуре работают российские сервисы, на международном зарубежные.

Нужен ли программист, чтобы это настроить?

Нет. Офлайн-конверсия настраивается как обычный блок в конструкторе автоматизаций: выбираете, при каком событии отправлять, на какие площадки и откуда брать сумму сделки. Дальше система работает сама.

Почему повторные платежи не считались и почему это важно?

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

Что значит «боты научились запускать друг друга»?

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

Партнёр может отправлять письма клиентам от своего имени?

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