# Глубокая интеграция цифрового диалога в бизнес-процессы: практический гайд

<span style="font-weight: 400;">Для примера мы разберем интеграцию веб-сайта с чат-ботом для Telegram, но все сказанное ниже справедливо для любого мессенджера.</span>

### <span style="font-weight: 400;">Зачем это нужно</span>

<span style="font-weight: 400;">Представьте, что вам необходимо реализовать один или сразу все из представленных ниже сценариев:</span>

- <span style="font-weight: 400;">Привязать веб-сайт к чат-боту, чтобы отправлять уведомления зарегистрированным пользователям веб-сайта прямо в их Telegram, например, сообщать о смене статуса заказа;</span>
- <span style="font-weight: 400;">Привязать веб-сайт к чат-бот, чтобы зарегистрированные пользователи веб-сайта могли работать с вашим веб-сайтом через чат-бот в мессенджере, используя чат-бот как диалоговый пользовательский интерфейс;</span>
- <span style="font-weight: 400;">Авторизоваться или зарегистрироваться на веб-сайте через чат-бот, без ввода логина и пароля на самом веб-сайте;</span>
- <span style="font-weight: 400;">Открыть страницу веб-сайта в чат-боте с графическим интерфейсом, например, показать список товаров;</span>
- <span style="font-weight: 400;">Зарегистрировать пользователя на веб-сайте через чат-бот, </span><span style="font-weight: 400;">чтобы упростить путь пользователя. </span>

<span style="font-weight: 400;">Эти и другие подобные сценарии применения можно реализовать на платформе Metabot с помощью глубокой интеграции мессенджеров и веб-сайта (deep messaging integration). </span><span style="font-weight: 400;">Вам потребуются базовые навыки программирования, умение работать с REST API и немного терпения.</span>

### <span style="font-weight: 400;">Что это даёт</span>

<span style="font-weight: 400;">С помощью глубокой интеграции вы получите следующие возможности:</span>

- <span style="font-weight: 400;">Сможете упростить онбординг пользователей в ваш бизнес/на сайт, тем самым повысить конверсию и снизить стоимость привлечения пользователя;</span>
- <span style="font-weight: 400;">Сможете захватывать пользователей, которые находятся на очень раннем этапе в воронке продаж, например, тех кто не готов к покупке и обычно не регистрируется при переходе по рекламе;</span>
- <span style="font-weight: 400;">Сможете автоматизировать задачи на любых участках пути покупателя;</span>
- <span style="font-weight: 400;">Отправлять уведомления в мессенджер в любой момент.</span>

### <span style="font-weight: 400;">Как это работает </span>

<span style="font-weight: 400;">Все довольно просто! Хотя нам пришлось много потрудиться, чтобы сделать сложное простым.</span>

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

Основной момент, который важно понимать, заключается в том, что у пользователя (у Алисы) взаимодействие с веб-сайтом происходит в одном приложении т.е. в веб-браузере, а взаимодействие с чат-ботом в другом приложении т.е. в мессенджере.

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

Схематично глубокую интеграцию можно изобразить следующим образом:

<div drawio-diagram="30"><img src="https://docs.metabot24.ru/uploads/images/drawio/2022-07/2hTS5uRz6rF3k7XR-drawing-4-1659123178.png" alt=""/></div>

<span style="font-weight: 400;">Теперь разберем логику интеграции подробнее. </span>

#### <span style="font-weight: 400;">В какой системе хранить ID</span>

<span style="font-weight: 400;">Есть три подхода связать чат-бот и веб-сайт вместе:</span>

- Чат-бот хранит ID пользователя веб-сайта;
- Веб-сайт хранит ID персоны в чат-боте;
- Веб-сайт и чат-бот одновременно хранят ID пользователей другой системы.

<span style="font-weight: 400;">Нет каких-либо жёстких правил для принятия решения о том, как лучше организовать хранение ID и что лучше использовать для идентификации пользователя при вызове API. Делайте как вам удобно, исходя из реалий конкретной ситуации.</span>

<span style="font-weight: 400;">Например, если разработчикам веб-сайта затруднительно внести изменения в базу данных и код веб-сайта, вы можете принять решение хранить ID пользователя сайта у себя в боте, а разработчикам веб-сайта предложить API для отправки сообщений пользователям, используя User Id веб-сайта.</span>

#### <span style="font-weight: 400;">Разница между ID персоны и ID лида</span>

<span style="font-weight: 400;">В терминах Metabot **лид (lead)** — это подписчик на ваш чат-бот (можно сказать bot user), который подключен к конкретному мессенджеру. Лид создается на платформе автоматически в тот момент, когда человек поздоровался с вашим чат-ботом т.е. послал первое сообщение.</span>

[![image.png](https://docs.metabot24.ru/uploads/images/gallery/2022-07/scaled-1680-/0PMimage.png)](https://docs.metabot24.ru/uploads/images/gallery/2022-07/0PMimage.png)

<span style="font-weight: 400;">**Персона (Person)** — это запись о конкретном человеке, которая создается вручную разработчиком чат-бота во время регистрации или авторизации в чат-боте. У персоны теоретически может быть несколько лидов т.е. когда один и тот же человек написал в один и тот же чат-бот, подключенный к разным мессенджерам, но такие проекты не так часто встречается. Обычно у людей есть предпочтительный мессенджер, через который они общаются с компанией.</span>

[![image.png](https://docs.metabot24.ru/uploads/images/gallery/2022-07/scaled-1680-/lnEimage.png)](https://docs.metabot24.ru/uploads/images/gallery/2022-07/lnEimage.png)

<span style="font-weight: 400;">М</span><span style="font-weight: 400;">ы обычно всегда рекомендуем во время регистрации и авторизации в чат-боте создавать в Metabot персону, привязывать к этой персоне лид и использовать ID персоны для связки с веб-сайтом, потому что это правильно. У вашего приложения должна быть реляционная структура данных, которая независима от того в каких мессенджерах кто предпочитает общается. </span>

<span style="font-weight: 400;">Но если проект простой и не надо сильно заморачиваться, то можете сделать очень просто: храните ID лида на веб-сайте и используйте ID лида для идентификации API запросов. В таком подходе есть свои плюсы. В Metabot вызов триггеров и API завязан на Lead ID, что означает код на стороне чат-бота существенно упрощается — вам не нужно будет писать прослойку, которая будет по ID персоны в боте или ID пользователя сайта будет искать ID лида, чтобы в этот лид отправить сообщение – вам достаточно вызвать API для отправки сообщения, указав конкретный лид.</span>

#### Таблица соответствия

<span style="font-weight: 400;">Для хранения данных соответствия ID в двух системах мы рекомендуем создать кастомную таблицу</span><span style="font-weight: 400;">. Назовите эту таблицу например, **web\_users** (веб-пользователи).</span>

[![image.png](https://docs.metabot24.ru/uploads/images/gallery/2022-07/scaled-1680-/oABimage.png)](https://docs.metabot24.ru/uploads/images/gallery/2022-07/oABimage.png)

<span style="font-weight: 400;">Ниже описан технический процесс организации совместной работы веб-сайта и мобильного приложения, которым является мессенджер, с помощью чат-бота:</span>

1. <span style="font-weight: 400;">В таблицу добавляем поле с хэшом ID персоны, чтобы не передавать ID персоны в явном виде в ссылках (для безопасности).</span>
2. <span style="font-weight: 400;">Также в таблицу добавляем поле PIN код, которое будем формировать случайным образом в чат-боте и затем просить ввести PIN на сайте для подтверждения идентификации.</span>

#### <span style="font-weight: 400;">Ссылка в боте для перехода на сайт</span>

<span style="font-weight: 400;">Для авторизации пользователя на сайте через чат-бот, формируйте временный PIN код и присылайте его в чат-бот с инструкциями для пользователя о том, что нужно перейти на сайт по ссылке и ввести PIN.</span>

<span style="font-weight: 400;">Сразу же присылайте ссылку на сайт, добавляя в нее GET параметр с хэшом персоны. Хэш персоны позволит сайту идентифицировать пришедшего пользователя из бота, без необходимости спрашивать логин и пароль, но нужно только проверить, что пользователь ввел именно тот PIN, который получил в чат-боте.</span>

<span style="font-weight: 400;">После формирования значений, сохраните данные в таблицу соответствия web\_users.</span>

<span style="font-weight: 400;">Cсылка для перехода на сайт может выглядеть, например, следующим образом: </span>[<span style="font-weight: 400;">https://site.com?buid=ZRvJxYsn6Vr2sQVQ</span>](https://site.com?buid=ZRvJxYsn6Vr2sQVQ)<span style="font-weight: 400;">, где BUID — акроним от Bot User ID.</span>

#### <span style="font-weight: 400;">Подтверждение PIN-кода </span>

<span style="font-weight: 400;">В роутере разработчик сайта добавляет код, который при наличии параметра BUID загружает страницу для ввода PIN кода. После ввода, сайт на бэке по REST API проверяет валидность PIN, отправляя в бот три параметра:</span>

- <span style="font-weight: 400;">**BUID** — хэш ID персоны в чат-боте;</span>
- <span style="font-weight: 400;">**PIN** — введённый пользователем код;</span>
- <span style="font-weight: 400;">**ID** — ID пользователя сайта, если пользователь в текущий момент уже авторизован на сайте.</span>

<span style="font-weight: 400;">Чтобы обработать API запрос на валидацию PIN-кода со стороны чат-бота, в чат-боте создайте внутренний API Endpoint. Metabot поддерживает создание двух видов эндпоинтов: внутренних и внешних. В</span><span style="font-weight: 400;">нутренние предназначены для обращения внешних систем к вашему боту, а внешние, наоборот, для обращения из вашего ботом к внешним системам.</span>

<span style="font-weight: 400;"> Назовите эндпоинт, например, **authorize** (авторизация). Напишите код, который в таблице web\_users будет искать запись с нужным нам BUID и проверит PIN на правильность. Если запись найдена, то сообщаем сайту об успехе, или в противном случае о провале.</span>

<span style="font-weight: 400;">Рассмотрим вероятные сценарии, представленные ранее на упрощенной схеме и дополненные новыми:</span>

- **PIN не верный**: 
    - <span style="font-weight: 400;">Это означает перед нами либо пользователь, который ошибся в воде кода, либо злоумышленник, пытавшийся взломать чужой аккаунт, либо неосторожный пользователь, который по тем или иным причинам переслал страницу ввода PIN кода другому человеку;</span>
    - <span style="font-weight: 400;">В этом случае, на сайте нужно обработать ответ от бота, например, показав соответствующие сообщения об ошибке (например, что PIN истек) и предложить выслать новый PIN в мессенджер;</span>
    - <span style="font-weight: 400;">Или же можете создать новый PIN на лету и выслать его пользователю в чат-бот;</span>
- **user\_id есть в web\_users, но нет в запросе**: 
    - <span style="font-weight: 400;">Это означает, что пользователь веб-сайта привязан к чат-боту. Возвращаем user\_id в ответе, чтобы веб-сайт авторизовал пользователя;</span>
- <span style="font-weight: 400;">**user\_id есть в web\_users и есть в запросе**:</span>
    - <span style="font-weight: 400;">Если user\_id совпадают, то это означает, пользователь уже авторизован на сайте и бот привязан к его аккаунте. Предлагаем вернуться на сайт;</span>
    - <span style="font-weight: 400;">Если user\_id отличаются, то скорее всего пользователь пытается привязать свой новый аккаунт на сайте к боту, а тот уже привязан к другому аккаунте на сайте. Решите как хотите обработать эту исключительную ситуацию, например, предложите пользователю варианты на выбор: отвязать старый аккаунт и привязать новый, оставить привязку к другому аккаунту;</span>
- **user\_id нет в web\_users**: 
    - Если в запросе нет user\_id, то это означает пользователь входит на сайте через бота и скорее всего аккаунта на сайте у него тоже нет, но это не точно;
    - В идеале нужно поискать наличие аккаунта, например, запросив регистрационные данные и выполнив поиск по API;
    - В самом простом сценарии, мы полагаем, что пользователь входит на сайт через чат-бот и одновременно регистрирует аккаунт на сайте.

#### Авторизация без ввода PIN

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

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

#### Повышение безопасности авторизации

<span style="font-weight: 400;">Опционально, вы можете улучшить безопасность, добавив дополнительные проверки, например, время жизни PIN-кода или сделав одноразовый ввод кода. Обработайте нужные вам ситуации и верните сайту ответ о результате проверки.</span>

### <span style="font-weight: 400;">Что дальше?</span>

<span style="font-weight: 400;">А дальше все зависит от ваших конкретных задач и проблем. Теперь когда у вас в таблице соответствия есть взаимно-однозначная связь между ID персоны в боте и ID пользователя на сайте, вы можете как работать с сервисами веб-сайта через чат-бот от имени пользователя сайта, так и со стороны сайта инициировать в чат-боте те или иные действия для пользователя. </span>

<span style="font-weight: 400;">Также, мы рекомендуем разместить в боте функцию выхода из аккаунта, а на сайте опции для отвязки и привязки бота заново.</span>