Как проверить, есть ли профиль в другой базе

Обычно рекомендуется хранить всех клиентов в одной базе, а разделять аудиторию с помощью сегментов и ресурсов. Такой подход заложен в логику CDP: все данные в одном месте, единый профиль, управляемая коммуникация. Но на практике бизнес часто устроен сложнее, и данные по разным причинам оказываются в нескольких базах. Например, отдельно ведутся B2B и B2C-направления, разделяются лиды и действующие клиенты или изолированы пользователи разных продуктов.

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

Например, у вас есть основная база, где новые пользователи проходят приветственную цепочку, и отдельная база пользователей Telegram-бота. На одном из этапов онбординга вы хотите отправить письмо с приглашением в бота, но перед этим надо проверить, есть ли пользователь в базе подписчиков бота. Если да — письмо с приглашением не отправляется; если нет — он получает промо.

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

Шаг 1. Отправьте API-запрос в целевую базу

1. Добавьте в сценарий узел «API-запрос». Он будет обращаться к другой базе и спрашивать, есть ли там такой клиент.

2. Выберите тип авторизации, например, через Токен. Если у вас нет подключения для авторизации, его можно создать в разделе Настройки → Подключения → Token Authentication. Для этого надо обладать правами мастер-пользователя.

3. Задайте основные параметры запроса

• Метод: POST DATA
• URL: https://<your_platform_domain>/api/v1.1/profiles/get

4. В теле запроса передайте два параметра: номер базы для поиска и идентификатор клиента — например, email. Чтобы сценарий подтягивал email профиля, который вошёл в узел, используйте переменную {lead.email}.

{
  "db_id": 2,
  "email": "{lead.email}"
}

5. Обязательно включите опцию «Сохранить HTTP-ответ в поле {apicontent}» и придумайте название для этого поля, например content. Именно туда попадёт ответ от API, который вы будете использовать на следующем шаге.

apicontent — это временное хранилище, куда сценарий складывает ответ от API-запроса. Эти данные можно использовать дальше в сценарии: в фильтрах, письмах и других узлах. Но важно понимать, что это не поле профиля. Данные живут только внутри сценария и исчезают, как только профиль выходит из него.

Шаг 2. Проверьте ответ через JSON-фильтр

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

2. В условии напишите content.error = 0. Когда платформа отвечает на запрос, она всегда присылает код ошибки. Если код равен 0, значит профиль найден. Если код равен 404, значит профиля нет.

Пример ответа, если пользователь найден:

{
    "data": {
        "email": "john@example.com",
        ...
    },
    "error": 0,
    "error_text": "Successful operation"
}

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

Шаг 3. Сохраните результат в профиль

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

1. Создайте в базе дополнительное поле булевого типа, например: exists_in_db_2

2. Вернитесь в сценарий и в обе ветки добавьте узел «Обновить профиль».

3. На зеленой ветке установите в этом поле значение «Да»:

4. На красной ветке установите значение «Нет»:

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

Что важно иметь в виду

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

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