Счётчик не видит оплату
Сделка закрывается в CRM, по звонку или в салоне. Для рекламной системы этого события просто не существует.
Sales Ninja непрерывно передаёт во внешние системы то, чем действительно закончился лид: оплату, квалификацию, выручку, возврат или фрод. Алгоритмы учатся на результате бизнеса, а не на отправке формы — без ручных выгрузок и собственной интеграции с API.
Алгоритм оптимизируется на том, что получает: клике, отправке формы, микроцели. Оплата, квалификация, возврат или фрод появляются позже — в CRM, по звонку, в кассе или офлайне. Пока эти факты не вернулись в рекламную систему, бюджет масштабирует похожий трафик, а не похожих покупателей.
Сделка закрывается в CRM, по звонку или в салоне. Для рекламной системы этого события просто не существует.
Отправок формы много, они дешёвые — автостратегия выбирает их. Заявок становится больше, продаж — нет.
Пока оплаты за месяц соберут в таблицу и зальют вручную, кампания уже переучилась и бюджет потрачен.
Фрод и спам-лиды выглядят для площадки конверсией. Без минус-события она продолжает искать такой же трафик.
Стриминг закрывает этот разрыв: конверсии, которые проект уже собрал, непрерывно возвращаются наружу в понятном получателю формате. Источник истины остаётся у бизнеса, а реклама получает свежий сигнал для следующего решения.
Стриминг нужен не ради ещё одной интеграции. Он возвращает в закупку факты, которые появляются после клика и живут в CRM, кассе, коллтрекинге или антифроде.
Сайт видит добавление товара и чекаут. Оплату, фактическую сумму и возврат знает касса или CRM — именно эти события и нужно вернуть в закупку.
Реклама ищет покупателей, а не пользователей с незавершённой корзиной.
В недвижимости, образовании, B2B и финтехе решение принимают не в день клика. Поток подхватывает поздний факт, когда он появится в учётной системе.
Алгоритм видит, какой трафик приводит к сделкам, даже если цикл продажи длинный.
Форма считает конверсией и ценного лида, и спам. Менеджер, скоринг и антифрод знают разницу — положительные и негативные исходы уходят отдельными потоками.
Бюджет перестаёт масштабировать дешёвый мусор и собирает больше качественных обращений.
Поток связывает три вещи: какие события везём, по каким правилам их отбираем и в какую систему доставляем. Дальше он ходит по расписанию сам. Потоков может быть несколько — плюс-обучение, минус-цели и разные кабинеты не обязаны жить в одном маршруте.
что отправляем
Цели Sales Ninja, события которых попадают в поток: оплата из CRM, квалифицированная заявка, минус-событие антибота. Дата старта — нижняя граница чтения, чтобы не отдать всю историю разом.
что отсекаем
Условия цели — по данным самой конверсии: составу заказа, сумме, полям формы. Условия сессии — по источнику трафика, UTM, устройству. Пустые фильтры — нормальная настройка: они нужны, только если наружу должна уехать не вся масса.
куда доставляем
Сегодня это офлайн-конверсии Яндекс Метрики: интеграция, счётчик, цель, тип конверсии и валюта ценности. Получатель — свойство конкретного потока, а не имя раздела, поэтому новые маршруты не ломают существующие.
Стриминг не добавляет рекламе новых кликов. Он меняет качество обратной связи — и поэтому постепенно меняет состав трафика, который алгоритм покупает дальше.
Наружу уходит факт, который бизнес считает победой, — заказ, квал-лид, выданный займ. Не просто отправка формы.
Оплата, пришедшая через неделю после клика, всё равно попадёт в поток — с фактическим временем конверсии.
Фрод, спам-заявку, отказ и возврат можно отдавать отдельным потоком — чтобы площадка перестала искать такой же трафик.
Тип конверсии и валюта говорят получателю, как читать сумму заказа. Оптимизация по выручке работает на числах, а не на факте «конверсия была».
Если рекламная система уже видит те же события своим счётчиком, дублировать их потоком незачем. Стриминг нужен там, где проект знает результат раньше, точнее или с другой ценностью, чем площадка: оплата в CRM, квалификация менеджером, возврат, отказ, фрод.
Редактор потока отвечает ровно на четыре вопроса: что везём, что отсекаем, куда доставляем и в каком контракте. Всё остальное — расписание, повторы, курсор по новым событиям — наша сторона.
Выбираете цели Sales Ninja, события которых должны попадать в поток, и дату старта.
Нужны, только если наружу должна уехать не вся масса выбранных целей, а её часть.
Куда доставляем. Сегодня это офлайн-конверсии Яндекс Метрики.
Как получатель прочитает ценность и когда поток начнёт работать.
Ничего не уедет наружу, пока вы сами не переведёте поток в статус «Работает». До этого можно спокойно менять цели, фильтры и получателя и смотреть, какая доля конверсий вообще пригодна к передаче.
Интеграция, про которую известно только «вроде бы настроена», — это чёрный ящик. Поток показывает по каждому запуску: сколько событий передано, сколько ждёт следующей попытки и почему конкретное событие отправить нельзя.
До первого запуска видно, какую долю конверсий за последние 30 дней вообще можно отправить: у события должен быть идентификатор, по которому получатель узнаёт пользователя. Считается на ваших данных.
Каждое непереданное событие получает машинную причину — без «что-то пошло не так».
По каждому запуску — время, сколько передано, сколько не сопоставлено, сколько поставлено в очередь, какая выручка ушла в получатель и чем запуск закончился.
Передача идемпотентна: повторный запуск не задвоит конверсию у получателя, даже если поток перезапустили руками.
Если получатель ответил ошибкой, курсор потока не двигается: та же партия событий уедет на следующем запуске, а не потеряется.
Сайт и браузер посетителя не обращаются к API рекламных систем. Отправку выполняет backend Sales Ninja по правам вашей интеграции.
Стриминг — последний шаг контура, а не первый: сначала проект собирает факт, потом поток отдаёт его наружу. Поэтому требования короткие и почти всегда уже выполнены у действующих клиентов.
Оплата, квал-лид или минус-событие должны существовать в проекте как цель. Пока цель не собирается, отдавать наружу нечего.
Доступ к внешней системе и право записывать события. Доступ и права — со стороны клиента, настройка потока — с нашей.
Поток отправляет события в выбранную цель внешней системы и не создаёт её за вас: чужой контракт мы не меняем.
Получатель должен узнать пользователя по своему ключу. Для Метрики это yclid или ClientID; если его нет в конверсии, пробуем взять из связанной сессии.
Сегодня поток доставляет офлайн-конверсии в Яндекс Метрику. Оттуда свежие события забирает автостратегия Директа.
Получатель — свойство потока, а не имя раздела. Новые направления доставки добавляются как ещё один получатель и не трогают уже работающие маршруты.
Дальше по теме: моделируемые конверсии дают плотный сигнал, когда реальных оплат мало; интеграция с amoCRM и коллтрекингом приносят в проект сам факт продажи; антибот размечает мусорные заявки, которые стоит отдавать минус-потоком; мало конверсий для обучения — типовая ситуация, ради которой поток и настраивают.
Метрика поведение тоже пишет — просто заметно меньше. Наш скрипт снимает подробный слепок каждой сессии.
Клики, скроллы и движения мыши вплоть до микромоторики курсора. Вкладки и время активности в каждой. Корзина, просмотренные товары, цели прошлых сессий. UTM, устройство до модели и её цены, город, погода. И ваши собственные параметры.
Признаки, которых в сыром событии нет, платформа добавляет сама. Передавать их нам не нужно.
Пол, возраст, платёжеспособность и интересы — с уверенностью по каждому. Вероятность конверсии, ожидаемая выручка и цена клика. Оценка ботности по поведению.
Оттуда приходит то, чего на сайте не видно: звонки, сделки и деньги. Доступ — с вашей стороны, настройка — с нашей.
Офлайн-конверсия часто приходит без стабильного идентификатора: есть только UTM, а он указывает на группу трафика, а не на человека. Раньше такие конверсии просто терялись.
Модель восстанавливает их вероятностно: разбирает всю группу трафика и реконструирует наиболее вероятное распределение конверсий по ней.