Когда заходит речь о том, как поставляется рекламная платформа, в одну строку обычно валят разные вещи: SaaS, On-Premise, White Label, передачу исходного кода. На практике это не пункты одного списка, а характеристики, которые описывают сделку с четырёх разных сторон. Ниже разбираем, почему так, и как читать любой контракт на поставку AdTech-решения, не запутавшись.
Главная ошибка: пять «моделей» вместо четырёх осей
Типичная классификация выглядит как линейный перечень: SaaS, On-Premise, On-Premise PaaS, White Label, Source Code License. Проблема в том, что эти позиции не исключают друг друга. Одна и та же сделка спокойно попадает сразу в несколько пунктов: решение может стоять в дата-центре заказчика (On-Premise), работать под его брендом (White Label) и при этом поставляться с исходным кодом (Source Code License). Если держать всё это в одном списке, договорная и аналитическая работа превращается в спор о терминах.
Правильнее развести четыре независимых измерения и по каждому из них задавать отдельный вопрос:
- Где разворачивается ПО - модель развёртывания.
- Кто его эксплуатирует - операционная модель.
- Как оно лицензируется и оплачивается - лицензионная и коммерческая модель.
- Под чьим брендом поставляется - модель брендирования и каналов продаж.
Любая сделка - это комбинация по одному значению с каждой оси. Дальше разберём оси по очереди.
Ось 1. Где разворачивается ПО
Эта ось отвечает на вопрос, в чьём периметре физически работает платформа и где лежат данные. Для рекламного ПО это решающий фактор, потому что вместе с развёртыванием переезжают и first-party data рекламодателя.
Public SaaS. Платформа размещена в инфраструктуре поставщика, один экземпляр приложения обслуживает множество клиентов (мультитенантность). Данные заказчика попадают на сторону поставщика. Это самый быстрый старт и самая слабая позиция по контролю над данными.
Private Cloud (Hosted Single-Tenant). Тоже в облаке поставщика, но выделенный экземпляр под одного клиента. Часто путают с SaaS, хотя для банков и телекома разница принципиальная: выделенный контур закрывает часть требований к изоляции.
On-Premise. Платформа разворачивается в инфраструктуре заказчика, данные не покидают его периметр. Это и есть главная коммерческая ценность модели для крупного бизнеса с большими собственными данными.
Hybrid. Часть компонентов у заказчика, часть у поставщика. Типичный случай: чувствительные данные и биддер внутри периметра, а вспомогательные сервисы и аналитика снаружи.
Ось 2. Кто эксплуатирует систему
Развёртывание отвечает на вопрос «где», а эта ось - на вопрос «кто отвечает за работу»: установку, обновления, мониторинг, реакцию на инциденты. Часто именно её забывают и зашивают в определение On-Premise, хотя это отдельное измерение.
Self-managed. Заказчик сам обслуживает систему своими силами. Подходит командам с сильным внутренним DevOps.
Vendor-managed. Эксплуатацию полностью ведёт поставщик. Стандарт для Public SaaS и Private Cloud.
Co-managed. Инфраструктура у заказчика, а обновления, DevOps и SRE - на поставщике. Это очень распространённый сценарий для On-Premise, и именно он выпадает, если жёстко требовать «самостоятельной эксплуатации» в определении On-Premise. То, что иногда называют «On-Premise PaaS», по сути и есть Co-managed On-Premise, а не PaaS в строгом смысле.
Отдельно стоит оговорить термин PaaS. По классике (NIST SP 800-145) это среда для разработки и запуска приложений заказчика в инфраструктуре поставщика. Поэтому «On-Premise PaaS» - неудачное название: оно вводит в заблуждение и технически, и в нормативной части, включая работу с реестрами отечественного ПО.
Ось 3. Как лицензируется и оплачивается
Эта ось описывает права на использование и финансовую модель. Она не зависит от того, где стоит софт: подписку можно платить и за On-Premise, а бессрочную лицензию оформить и для облачного развёртывания.
Subscription (подписка). Периодические платежи за право пользования. Применима к любой модели развёртывания.
Perpetual License (бессрочная лицензия). Разовый платёж за бессрочное право использовать конкретную версию. Поддержка и обновления оформляются отдельным договором.
Source Code License. Право использования с передачей исходного кода заказчику. Подварианты различаются по объёму прав: бессрочное исключительное (фактически отчуждение в пользу заказчика), бессрочное неисключительное (поставщик вправе лицензировать ту же кодовую базу другим), срочное (term license) и полное отчуждение (assignment). Условия дальнейшей доработки и поддержки пишутся отдельно.
Source Code Escrow. Исходный код депонируется у независимого эскроу-агента и передаётся заказчику только при наступлении заранее оговорённых событий: банкротство поставщика, прекращение поддержки, систематическое нарушение SLA. Промежуточная форма, которая снижает риск зависимости от поставщика, не отдавая код в повседневную работу.
Open Source / Dual Licensing. Часть кодовой базы открыта под свободной лицензией (MIT, Apache 2.0, GPL), а коммерческие условия действуют для поддержки или для закрытых частей продукта. Это самостоятельная коммерческая модель, и к Source Code License её относить не надо.
Revenue Share. Платежи привязаны к доходу или объёму обрабатываемых событий: доля от media spend, оплата за обработанные показы. Встречается в основном в SaaS и Hosted-сценариях.
Ось 4. Под чьим брендом поставляется
Последняя ось не про технологию, а про то, чьё имя видит конечный пользователь. Она сочетается с любой комбинацией первых трёх.
Vendor-branded. Продукт идёт под брендом поставщика.
White Label. Продукт работает под брендом заказчика, без упоминания поставщика. Применимо к DSP, SSP, DMP, CDP, Ad Server и их комбинациям.
Co-branded (Powered by). Продукт под брендом заказчика, но с явным указанием технологии поставщика - «Powered by …». От White Label отличается условиями упоминания поставщика в интерфейсе, документах и публичных коммуникациях, а значит и распределением ответственности по доменам, контактам и поддержке.
Как одна сделка раскладывается по осям
Сила подхода в том, что любую конфигурацию можно записать одной строкой через четыре оси. Несколько типовых примеров:
- Крупный телеком или банк с большими first-party data: On-Premise + Co-managed + Subscription + (Vendor-branded или White Label). Данные не выходят за периметр, обслуживание на поставщике.
- Рекламная сеть или агентство: Private Cloud + Vendor-managed + Subscription + White Label. Заказчик продаёт под своим брендом, не держа инфраструктуру.
- Рекламодатель или среднее агентство: Public SaaS + Vendor-managed + Subscription + Vendor-branded. Быстрый старт, минимум обязательств.
Эти связки не нормативны, конкретная конфигурация согласуется в каждом договоре. Но как только сделка описана через четыре оси, исчезают разночтения: видно, где данные, кто отвечает за работу, какие права передаются и чьё имя на продукте.
Что важно именно для AdTech на российском рынке
Локализация и обработка данных. Выбор по первой оси сразу тянет за собой требования к данным. Public SaaS означает, что first-party data уходят на инфраструктуру поставщика, а это включает требования 152-ФЗ к локализации и обработке персональных данных, а в банковской и телеком-вертикалях - банковскую тайну и тайну связи. On-Premise эти риски снимает на уровне архитектуры.
White Label и ОРД. Работа под брендом заказчика не отменяет обязанностей по маркировке рекламы и передаче данных в ЕРИР через ОРД. Ответственность и техническая интеграция с ОРД должны быть прописаны отдельно и не зависят от модели брендирования.
Риск зависимости от поставщика (vendor risk). Чем критичнее платформа для бизнеса, тем важнее план на случай ухода поставщика. Source Code Escrow и депонирование - стандартный способ застраховаться, не требуя передачи кода в обычной работе.
Open Source как канал. Открытая часть кодовой базы - это не «бесплатно», а отдельная модель с собственной коммерческой логикой: поддержка, закрытые модули, гарантии. Её стоит оценивать как канал, а не как уступку.
Мини-глоссарий смежных терминов
Чтобы корректно пользоваться четырьмя осями, полезно держать рядом несколько понятий.
First-party / second-party / third-party data. Свои данные, данные партнёра по прямому обмену и данные, полученные от третьей стороны. При передаче данных между сторонами их класс меняется: то, что для компании было first-party, для внешней DMP становится third-party.
Tenant, multi-tenancy, single-tenancy. Один общий экземпляр на многих клиентов против выделенного экземпляра под одного. Граница между Public SaaS, Private Cloud и On-Premise проходит именно здесь.
SLO и SLA. Целевые показатели и договорные обязательства по уровню сервиса. Для AdTech это отклик в RTB-аукционе, доступность биддера, время реакции на инциденты.
Source Code Escrow. Депонирование кода у независимого агента с передачей по заранее оговорённым триггерам.
ОРД и ЕРИР. Оператор рекламных данных и единый реестр интернет-рекламы - обязательная часть поставки рекламного ПО в России, не зависящая от модели развёртывания.
Если нужно разложить конкретную поставку по этим осям применительно к программатик-стеку - DSP, SSP, DMP, CDP, биддеру, ML и Ad Server - мы готовы помочь. Узнать больше о платформе →