Персонализация и A/B‑тесты по API
API-режим Sales Ninja для мест, где нельзя поставить скрипт: мобильные приложения, бэкенд, CRM, личные кабинеты. Один POST — одно решение, без куки, без хранения состояния и без вынесения данных за контур.
Что такое персонализация по API
На сайте Sales Ninja подключается JS‑скриптом и дальше сам решает, кому какой вариант показать. Но есть мир, где скрипт поставить нельзя — мобильное приложение, бэкенд, CRM, личный кабинет, телефония, рассылка. Там нужен другой формат интеграции.
Персонализация и A/B‑тесты по API — это режим Sales Ninja без установки скрипта. Вы собираете состояние пользователя у себя, отправляете POST‑запрос с нужными полями — в ответ получаете решение: какую персонализацию или вариант A/B применить. Без скриптов на клиенте, без куки, без вынесения данных за контур.
JS‑скрипт на сайте — следит за поведением, сам выбирает вариант, сам применяет изменения через DOM.
Отлично работает на сайте. Не работает в нативном приложении, бэкенде или CRM.
Бэкенд / мобильное приложение собирает идентификатор пользователя и контекст, шлёт POST — получает решение и применяет его на своей стороне.
Stateless‑запрос: что передали — то и участвует в решении. Ничего лишнего, никакой «магии со стороны».
Как это работает
Sales Ninja по API — это удалённый движок решений. Один запрос — одно решение. Тот же вход даст тот же вариант. Никаких куки, никаких сессий на стороне Sales Ninja, которые надо синхронизировать с вашим бэкендом.
// что вы отправляете { "customerId": "934f17b6-ffba-…", "projectId": "4e0b71c2-…", "context": { "page": "/checkout", "sessionNumber": 3, "pagesOpened": 7, "utmSource": "yandex", "device": "mobile", "params": { "plan": "pro", "cartTotal": 12490 } } }
// что возвращается [ { "personalizationId": "934f17b6-…", "optionId": "variant_b", "isControl": false, "version": 17, "validUntil": "2026-05-12T00:00:00Z", "params": { "discount": "10%", "copy": "Заберите со скидкой" } } ]
Stateless
Никакого «состояния пользователя» на нашей стороне, которое надо синхронизировать. Что вы кладёте в запрос — то и учитывается.
Идемпотентность
Один и тот же customerId на одну версию персонализации получит один и тот же вариант. Sticky‑поведение из коробки.
Скорость
Ответ обычно за единицы — десятки миллисекунд. Не добавляет заметной задержки на ваш сценарий.
ValidUntil
В ответе приходит срок жизни решения. Можно безопасно кэшировать на своей стороне и экономить вызовы.
Не выносите из избы — только то, что хотите
Стандартный блокер интеграции с внешним сервисом — «нам нельзя отдавать персональные данные». В API‑режиме Sales Ninja вы сами решаете, что отдать. Мы не запрашиваем PII, не ставим куки, не трекаем поведение скрытым скриптом.
Идентификатор — в захешированном виде
customerId — это любой устойчивый ID, который вы считаете нужным. SHA‑256 от email, ID строки в БД, GUID мобильной сессии, anonId. Sales Ninja не знает, что это, и не пытается обратно расшифровать.
customerId: 76f21ce7-365a-45f6-b416-49b5cd238a8bКонтекст — на ваше усмотрение
Хотите дать только UTM и тип устройства — дайте только их. Готовы поделиться суммой корзины и тарифом — добавьте в params. Чем больше сигнала — тем точнее персонализация, но это всегда ваш выбор, не наш.
- UTM, реферер, страница, устройство
- Произвольные user‑params и page‑params
- Сегменты, теги, признаки CRM
IP — опционально
Если хотите гео‑логику — передайте IP. Не хотите — не передавайте, всё работает и без него: persistent customerId, контекст и params уже дают системе достаточно сигнала.
Авторизация — токеном проекта
Проектный токен в заголовке X‑SN‑TOKEN. Никаких пользовательских ключей, ничего, что нужно генерить per‑user. Ротация — в один клик в кабинете.
Что доступно по API
Через API доступны три ключевых сценария Sales Ninja: персонализация по ML‑модели, A/B‑тестирование с контрольной группой и учёт целей — чтобы решения улучшались сами.
AI персонализация
Один и тот же эндпоинт отдаёт персонализированные предложения, тексты, цены и бизнес‑логику. Модель сама учит, какой вариант лучше для кого. Через API возвращается готовое решение — вы применяете его в своём интерфейсе.
A/B‑тесты
Отдельный endpoint для классических экспериментов. Многорукий бандит, четыре статистических метода остановки, sticky‑разделение — всё то же, что и на сайте, только без скрипта.
Цели и конверсии
Когда у вас на стороне сработала покупка, заявка, оплата — стукните POST /goal/reach. Модель учится на этих сигналах. Цели бывают офлайн — дозвон, выкуп, окончание подписки.
Контекст — любой
UTM, устройство, страница, пройденные шаги, признаки CRM, любые ваши params. Условия таргетинга и сегменты настраиваются в кабинете — код менять не надо.
Sticky‑вариант
Если пользователь уже попал в вариант, он продолжит видеть его же при следующих запросах. Можно дополнительно прислать appliedPersonalizations — чтобы решение было консистентно даже между разными каналами.
Куда чаще всего подключают
Базово API нужен в четырёх случаях: на нативных мобильных приложениях, на вашем бэкенде, в CRM / автоматизациях и в личных кабинетах, где нельзя положить произвольный JS‑скрипт.
Мобильные приложения
iOS и Android. Запрос идёт либо напрямую с клиента, либо через ваш бэкенд. Ответ применяете в нативных экранах: подменяете предложение, показываете другой онбординг, включаете другую механику чек‑аута.
Backend
Ваш сервер собирает контекст и принимает решение перед рендерингом ответа. Подходит для SSR‑сайтов, лендингов с heavy‑BI, систем где UI собирается на сервере.
CRM и автоматизации
Перед отправкой письма, пуша, SMS — запрос за вариантом. У разных сегментов получаются разные предложения, темы, скидки. Цели по офлайн‑конверсиям возвращаются обратно через /goal/reach.
Личные кабинеты и Enterprise
Когда сторонние скрипты на сайт ставить нельзя по корпоративной политике — всё работает по серверному API. Ничего лишнего на клиенте, токен живёт только на вашем бэкенде.
Три шага интеграции
Базовая интеграция собирается за день. Логика остаётся в кабинете Sales Ninja, на вашей стороне — только два HTTP‑вызова.
Настройте персонализацию или A/B‑тест в кабинете
Опишите варианты, условия таргетинга, цель оптимизации. Это всё делается в UI — маркетолог справится без разработчика. Опубликуйте — получаете ID и токен.
Шлите запрос за решением
В нужной точке кода — перед рендером экрана, перед отправкой письма, при открытии чек‑аута — делаете POST. В ответе — идентификатор варианта и его параметры. Применяете их.
Передавайте достижения целей
Когда пользователь сделал то, ради чего всё затевалось — покупка, заявка, продление — стукните /goal/reach. Дальше модель сама подкручивает раздачу вариантов в сторону того, что работает.
# 1. Получить вариант curl -X POST 'https://api.sales-ninja.me/outer/v1.0/personalizations' \ -H 'X-SN-TOKEN: ********' \ -d '{"customerId":"u_8421","projectId":"…","context":{"page":"/checkout"}}' # 2. Зафиксировать достижение цели curl -X POST 'https://api.sales-ninja.me/outer/v1.0/goal/reach' \ -H 'X-SN-TOKEN: ********' \ -d '{"goalId":"checkout_paid","customerId":"u_8421"}'
Давайте поговорим
Берёте Персонализацию по API — остальной сайтовый стек получаете бесплатно
Это одна лицензия, а не набор отдельных продуктов. Без доплат, без кросс‑сейла — всё ниже сразу включено и работает в связке.
Ответы на часто задаваемые вопросы
Чем API-режим отличается от стандартной персонализации Sales Ninja?
Стандартная персонализация работает через JS-скрипт на сайте: он сам собирает контекст, выбирает вариант и применяет изменения через DOM. API-режим — это движок решений без установки скрипта: вы собираете контекст у себя, отправляете POST, получаете JSON с вариантом и применяете его в своём интерфейсе. Это нужно там, где скрипт поставить нельзя — мобильные приложения, бэкенд, CRM, enterprise-кабинеты.
Это отдельный продукт или часть основной персонализации?
Это режим работы тех же продуктов — глубокой AI персонализации и A/B-тестов. Конфигурируете персонализацию или тест в одном кабинете, можете включить и работу через скрипт, и через API. Тарификация общая.
Можно ли смешивать веб-режим и API в одном проекте?
Да. Например, на сайте — через скрипт, в мобильном приложении — через API, в письмах из CRM — тоже через API. Если передать в API параметр appliedPersonalizations, то решение будет согласованным между каналами для одного пользователя.