Prodantix

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

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

Как устроен движок

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

Событие

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

Состояние пользователя

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

Решение

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

Действие

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

Аналитика это чтение состояния

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

Сохранить вопрос, который вы зададите снова

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

Когда число сдвинулось само

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

Люди, о которых говорит состояние

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

Один человек, несколько идентификаторов

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

Просмотр одной сессии заново

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

Что записи позволено сохранить

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

Показывать разным людям разное

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

Сообщения, которые приходят, пока ещё помогают

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

Когда вам отвечают

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

Собрать последовательность самому

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

Оркестрация ИИ и как замыкается цикл

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

Предложение ждёт человека

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

Как события попадают внутрь

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

Ключи и окружения

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

Четыре способа с ним говорить

REST разнесён по трём хостам: один для флагов и сообщений, один для приёма событий и один для повтора сессий, и каждый отдаёт собственный документ OpenAPI по адресу /openapi.json. Приём отвечает 202, что означает: событие принято к обработке, а не сохранено. Некорректное событие всё ещё может быть отброшено дальше по конвейеру. GraphQL покрывает всю модель приложения, включая проекты, флаги, сценарии, аналитику, сообщения, когорты и биллинг. Интерфейс реального времени транслирует изменения флагов, сообщения и запуски сценариев и немедленно разрывает неаутентифицированные соединения. Интерфейс MCP позволяет агентам читать и писать через вызовы инструментов; он предназначен для машин и отклоняет запросы из браузера.

Данные остаются вашими

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

Для кого это

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

Перейти Prodantix: prodantix.com