1
Вход
Рекламодатель авторизуется через Mitgo ID. PRM получает базовую идентичность пользователя.
PRM advertiser onboarding
Как заводится рекламодатель и что даёт верификация
Текущий flow: пользователь входит через Mitgo ID, проходит setup из двух шагов, получает legal entity в статусе pending, а внутренняя команда проверяет карточку и документы.
!
Главный вывод
Сейчас verification status не выглядит как общий замок на кабинет рекламодателя. Он показывает состояние проверки и влияет на внутренние операции, но не закрывает основной продуктовый доступ.
Основной flow
Без внутренних деталей реализации, только то, как процесс выглядит продуктово.
2
Бизнесовый профиль
Контакт, типы продвижения, сайт, affiliate network, mobile app и marketplaces.
3
Юридическая карточка
Legal name, страна, адреса и налоговые идентификаторы по правилам страны.
4
Создание профиля
Создаётся legal entity. Первый пользователь становится Owner этой компании.
5
Pending
Карточка ожидает внутренней проверки. Команда получает уведомление.
6
Проверка
Внутри смотрят company, tax, адреса, advertiser info, payment terms и документы.
7
Решение
Статус становится verified или moderation required с комментарием.
Что собираем на onboarding
После setup у PRM уже есть коммерческий footprint и юридико-налоговая идентичность рекламодателя.
Бизнесовая информация
- предпочтительный канал связи и контакт;
- типы продвижения;
- website URL;
- affiliate network и доля продаж, если применимо;
- mobile app, analytics systems и mobile sales share;
- marketplaces и доля продаж через них.
Юридическая и налоговая информация
- legal name и страна регистрации;
- юридический и почтовый адрес;
- VAT, TAX, TRN, EDRPOU, CIN, GST, PAN, BIN, RFC, CIF, CNPJ или TIN, в зависимости от страны;
- country-specific upload, если страна требует файл.
Как работает проверка
Верификация сейчас выглядит как внутренний процесс контроля данных, документов и финансовой готовности.
Ожидает проверки
Новый рекламодатель уже заведен в системе, но его legal entity ещё не подтверждён внутренней командой.
Проверка пройдена
Карточка подтверждена. Для этого должны быть готовы payment terms.
Нужны уточнения
Проверяющий оставляет комментарий. Отдельный клиентский self-service сценарий исправления сейчас не выражен.
Кто проверяет: внутренний пользователь с правом менять статус верификации. Практически это может быть ops, finance, legal или admin-пользователь, в зависимости от процесса команды.
Договоры и документы
Место, где можно “догрузить договор”, сейчас находится на внутренней стороне, не в клиентском setup.
Внутреннее добавление
Agreements and addenda добавляются внутри: номер договора, дата, файл, комментарий и кто загрузил. Partner documents также добавляются внутри с датой подписания и сроком действия.
Что видит рекламодатель
В My company рекламодатель видит доступные документы и может их скачать. Клиентской кнопки “догрузить договор” в текущем flow нет.
На что влияет verification status
Ключевая таблица: где статус реально меняет поведение, а где только отображается.
| Зона | Текущий эффект | Вывод |
|---|---|---|
| Переход из setup | Если legal entity создан, пользователь попадает в основной кабинет. Verified для этого не требуется. | не блокирует |
| My company | Pending отображается как предупреждение и статус карточки. | видимый статус |
| Документы | Просмотр и скачивание документов завязаны на доступ к компании, не на verified. | не блокирует |
| Company details | Клиент не редактирует ключевые legal/tax поля сам. Это общий UX, не только ограничение до verified. | ограничено всегда |
| Finance admin invoice | Создание invoice из reconciliation report требует verified legal entity. | блокирует |
| Основной кабинет | Не найдено общего правила, которое закрывает кабинет до verified. | hard-block не найден |