Кастомная разработка MDM-слоя: OTT-платформы уровня Netflix

Почему этот плейбук написала Фора Софт

Мы делаем стриминговые продукты с 2005 года: 625+ завершённых проектов, 300+ из них — в области real-time видео и аудио. Наши команды строили OTT-бэкенды, white-label-приложения для smart-TV, кластеры WebRTC SFU и DRM-защищённые VOD-библиотеки для клиентов в e-learning, телемедицине, спорте, безопасности и развлечениях. За эти годы один и тот же вопрос звучит почти на каждом стартовом созвоне: как нам управлять устройствами, потоками и правами так же, как Netflix, но без штата Netflix?

В этом плейбуке мы собрали то, что обычно говорим основателю или продуктовому VP на первом разговоре. Здесь архитектура, выбор DRM, расчёт бюджета, готовые альтернативы и пять ловушек, которые превращают запуски OTT в посмертные разборы. Если хотите краткую версию — у нас есть страница про разработку платформ Internet TV и OTT с описанием объёма работ и поставляемого результата. Но если вы взвешиваете build vs. buy, читайте дальше.

Каждая конкретная цифра ниже взята либо из публичных бенчмарков (Netflix, Disney+, Vimeo OTT, Bitmovin, AWS), либо из наших проектных журналов, либо из прайс-листов вендоров. Где мы не уверены — так и пишем, а не подставляем диапазон, за который не готовы отвечать.

Что на самом деле делает кастомный MDM-слой

В OTT слой Multi-Device Management — это невидимый контракт между подпиской и экраном. На каждый запрос плейбэка он отвечает на три вопроса: Кто запрашивает? С какого устройства? По какому тарифу? Все остальные решения — лестница битрейтов, выбор DRM, вставка рекламы, рекомендации — исходят из того, что эти ответы корректны.

Конкретно, кастомный MDM-слой обрабатывает:

• Регистрацию устройств и фингерпринтинг — фиксацию стабильной идентичности для каждого телефона, браузера, smart-TV или приставки.
• Контроль одновременных стримов — 1, 2 или 4 параллельных потока на тариф, на любой комбинации устройств.
• Привязку профилей и родительского контроля — какой профиль сейчас на каком телевизоре и что ему доступно.
• Проверку прав — действительна ли подписка, разрешён ли регион, открыто ли окно показа для этого региона и устройства.
• Брокеринг DRM-лицензий — запрос ключей Widevine, FairPlay или PlayReady только после подтверждения прав.
• Жизненный цикл сессии — создание, хартбит, миграция и завершение плейбэк-сессий между устройствами.
• Деактивацию устройств и кулдауны — возможность выйти с потерянного устройства и защита от злоупотреблений с подменой устройств.

Аббревиатура MDM путает покупателей, потому что в корпоративной IT она означает mobile device management (Intune, Jamf). Это другое. Если вы делаете стриминговый продукт, MDM — это слой, который не даёт одному домохозяйству на тарифе Standard крутить 11 потоков одновременно.

Что на самом деле контролируют ведущие OTT-сервисы

Прежде чем проектировать собственную MDM-политику, посмотрите, что делают мейджоры. Цифры ниже взяты из публичных справочных страниц и прайсов каждого сервиса, перепроверены в 2026 году.

Бросаются в глаза две закономерности. Во-первых, одновременные стримы — это и есть продукт: именно ими каждый сервис разводит ценовые тарифы. Во-вторых, регистрация устройств фактически безлимитна: ограничивают только число одновременных сессий. Ваш MDM-слой должен держать обе истины сразу: фиксировать каждое устройство, которое подписчик когда-либо использовал, но блокировать только N+1-й активный плейбэк.

Эталонная архитектура: пять сервисов, на которых держится нагрузка

Production-grade OTT MDM — это пять связанных сервисов плюс стек доставки видео. Любой из них можно заменить на SaaS, но сначала разберитесь, чем вы платите за это.

1. Реестр устройств (Device Registry)

Каноническое хранилище всех устройств, которые пользователь когда-либо регистрировал. Каждая запись содержит стабильный идентификатор (Android ID, IDFA, сгенерированный приложением UUID для веба), фингерпринт устройства (user agent, экран, WebGL-хэш), модель, ОС, версию приложения, последний IP и время последней активности. Кластеры уровня Netflix крутят это на Cassandra с мультирегиональной репликацией; платформа на 1–5 млн подписчиков может стартовать на PostgreSQL или DynamoDB и переехать позже. Горячий путь — чтение: каждая проверка сессии бьёт по реестру.

2. Менеджер сессий (Session Manager)

Создаёт, обновляет и закрывает плейбэк-сессии. Это единственный сервис, который реально отвечает на вопрос «сколько стримов у пользователя X прямо сейчас?» — и должен отвечать менее чем за 50 мс на 99-м перцентиле. Стандарт по умолчанию — Redis: атомарные INCR/DECR на пользовательских счётчиках, авто-экспирация по TTL, чтение за доли миллисекунды. Redlock защищает от гонок, когда две сессии стартуют в один и тот же тик.

3. Сервис прав (Entitlement Service)

Дано: пользователь, устройство, тайтл — можно ли проигрывать? Этот сервис сводит четыре входа: статус подписки (из биллинга), права на контент (из CMS), гео (через IP-лукап) и счётчик одновременных стримов (из менеджера сессий). Это привратник перед запросом DRM-лицензии: нет прав — нет лицензии — нет плейбэка. Держите его синхронным, без состояния, с кэшем 30–60 секунд на пользователя.

4. Брокер DRM-лицензий (DRM License Broker)

Тонкий прокси перед лицензионными серверами Widevine, FairPlay и PlayReady. Брокер прицепляет к каждому запросу лицензии данные сессии и устройства, чтобы DRM мог отказать в выдаче или выдать укороченную лицензию сессии, уже превысившей лимит тарифа. В этом же месте в ответ лицензии вшивается политика защиты выхода (HDCP 2.2, блок захвата экрана).

5. Пайплайн аналитики и QoE

Каждый клиент шлёт события старта, хартбит (10–60 с), переключения качества, буферизации и ошибки. Эти события идут в Kafka или Kinesis, агрегируются Flink или Spark Streaming и приземляются в Snowflake или BigQuery. Keystone от Netflix прогоняет через эту схему 2+ трлн событий в день; платформа на 1 млн подписчиков обработает 10–50 млрд в месяц. Ваш MDM-слой потребляет тот же поток для детекции аномалий — невозможные гео-входы, быстрая ротация устройств, пропадание хартбита сессии.

Вокруг этих пяти сервисов располагается стек доставки видео — пакетировщик, мульти-CDN, origin shield, плеерные SDK — и клиентские приложения для iOS, Android, веба, tvOS, Android TV, Fire TV, Roku и smart-TV. Шаблоны кодирования и доставки мы подробно разбираем в материале про корпоративный видеостриминг с MDM-слоем (архитектура, eCDN и стоимость).

Мульти-DRM: Widevine, FairPlay, PlayReady

Премиальные студии требуют все три основные DRM-системы. Хитрость в том, что вам не нужно кодировать библиотеку трижды. Запакуйте один раз в CMAF с Common Encryption (CENC для Widevine/PlayReady, CBCS для FairPlay), а затем отдавайте DASH-манифесты для Android/Chrome/smart-TV и HLS-манифесты для устройств Apple — из тех же сегментов.

Практический совет. Свой лицензионный сервер сегодня почти никто не пишет. Управляемый мульти-DRM от EZDRM, Axinom или BuyDRM стоит примерно от 0,07 до 0,75 ₽ за выданную лицензию и экономит вам месяцы интеграции. Брокер лицензий вы при этом всё равно делаете сами — это сервис, который вшивает в каждый запрос данные вашей сессии и устройства. Это не обсуждается: без него вы не сможете контролировать ни одновременные стримы, ни защиту выхода.

Шаблоны контроля одновременных стримов

Рабочих шаблонов три. Все они масштабируются, но различаются по UX, поверхности атаки и операционной стоимости.

1. Токен на этапе выдачи лицензии. Плеер запрашивает у сервиса прав короткоживущий (5–15 мин) плейбэк-токен. Токен предъявляется на эндпоинте DRM-лицензии; брокер отказывает или выдаёт укороченную лицензию, если счётчик одновременных стримов уже на максимуме. Просто, детерминированно, но уязвимо к replay-атаке, если токен не привязан к фингерпринту устройства.

2. Хартбит-сессии. Плеер пингует менеджер сессий каждые 10–60 с. Пропавшие хартбиты экспирят сессию за ~5 минут, освобождая слот. Хорошо ловит брошенные сессии на залоченном iPad. Добавляет 1–5% трафика контрольной плоскости — обычно незаметно.

3. Мягкий лимит с грейс-периодом. Стиль Netflix: разрешить N+1-й стрим на 10–30 с, чтобы не наказывать члена семьи, переходящего из комнаты в комнату, а затем закрыть самую старую сессию, если пользователь сам её не остановил. Лучший UX, самый сложный в корректной реализации.

В продакшене внедряйте все три. Токен на лицензии — ваша юридическая стена; хартбит ловит реальный мир; мягкий лимит отличает вас от дешёвых сервисов, которые выкидывают пользователя посреди серии.

Фингерпринтинг устройств и детекция шеринга аккаунтов

По оценкам, после глобальной кампании против шеринга паролей, развёрнутой с 2023 года, Netflix получил 50 млн новых платных аккаунтов. В 2024-м тот же ход повторили Disney+ и Hulu. Сегодня этот паттерн — стандарт продуктовой стратегии в OTT, и держится он целиком на фингерпринтинге устройств на уровне MDM-слоя.

Рабочий фингерпринт — это связка стабильного идентификатора устройства (IDFA, Android ID или сгенерированный приложением UUID для веба и ТВ), хэша user-agent, хэша экрана и WebGL для браузеров, IP + ASN-лукапа для кластеризации по домашним сетям и часового пояса. Ни одно поле в одиночку не уникально — уникален именно кортеж. Сохраняйте кортеж при регистрации и сравнивайте при создании каждой сессии.

Эвристики, которые реально работают для детекции шеринга:

• Невозможное гео. Две активные сессии с IP, разнесённых более чем на 1000 км, в течение 60 минут.
• Ротация устройств. Более 30–50 уникальных фингерпринтов на аккаунт в месяц. Реальные домохозяйства редко набирают и 10.
• Разнообразие ASN. Более трёх разных домашних провайдеров за скользящие 30 дней. Путешественники сюда тоже попадают, но шеринг — вдвое чаще.
• Дрейф часового пояса. Часовой пояс меняется быстрее, чем человек физически способен перелететь.

Ничто из этого не должно вызывать жёсткую блокировку. Публичный подход Netflix — мягкое предупреждение, затем запрос подтверждения одноразовым кодом на основном телевизоре, затем апселл на платный sharing-тариф. Доля ложных срабатываний на легитимных путешественниках — порядка 0,5–2%; прирост выручки с лихвой покрывает этот отток.

Пакетирование: CMAF, HLS, DASH и низкая задержка

CMAF — это правильный дефолт для любого нового OTT в 2026 году. Один набор фрагментированных MP4-сегментов, два манифеста (MPD для DASH, M3U8 для HLS), три DRM покрыты. Типичная длина сегмента — 2–6 с для VOD и 1–2 с чанков для low-latency-лайва. Хранилище и счета за CDN падают примерно вдвое по сравнению с раздельными HLS/DASH-пайплайнами.

В лайве low-latency HLS (LL-HLS) и low-latency DASH сокращают задержку «глаз-камера» до ~3–5 с против 10–30 с у легаси HLS. Среди плееров с поддержкой LL-HLS — Safari 14+, ExoPlayer, Shaka и Video.js с плагином hls.js. Плеерные компромиссы мы подробно разбираем в нашем гайде по разработке кастомных видеоплееров.

Выбор кодека определяется охватом устройств. H.264 всё ещё работает страховкой; HEVC снимает 30–40% битрейта там, где он поддерживается; AV1 убирает ещё 20–30%, но аппаратные декодеры пока неровно работают на старых smart-TV. Прагматичная лестница 2026 года — H.264 baseline для легаси, HEVC основной поток, AV1 там, где CDN и плеер цепочкой это поддерживают.

Безопасность, комплаенс и защита контента

Лицензирование премиального контента приводит за собой аудиторов. MPA/CDSA Trusted Partner Network (TPN) проверяет платформы по реализации DRM, управлению ключами, логированию и инциденту-менеджменту до того, как крупные студии лицензируют новые релизы. Что это значит на практике:

• Widevine L1, PlayReady SL3000, FairPlay с HDCP 2.2. Всё, что ниже, — стоп-фактор для 4K и большинства новых студийных окон.
• Аппаратное хранение ключей. Лицензионные серверы должны подписывать ключи сертификатами под HSM-защитой; такие вендоры, как EZDRM и Axinom, это закрывают.
• Аудит-логи на каждую выданную лицензию. Студии могут попросить — и попросят. Храните логи лицензий 12–24 месяца.
• GDPR и фингерпринты устройств. IP, IDFA, Android ID — это персональные данные. Документируйте сроки хранения, согласие и удаление. Два года — типичный потолок.
• Гео-контроль. Окна показа привязаны к территориям. Проверка IP + ASN на каждый запрос прав; держите эти правила вне плеера.

Ничего экзотического здесь нет, но всё это превращается в неприятные открытия на шестом месяце сборки, если стартовали без комплаенса в роадмапе. Закладывайте с первой недели.

Аналитические крючки, которые сами себя окупают

Аналитика — это второй заработок MDM-потока. Данные контрольной плоскости — старты сессий, хартбиты, переключения качества, ошибки — это ровно тот поток, который нужен QoE-дашборду. Подключите один раз — пользуйтесь и для контроля, и для инсайтов.

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

• Время старта. От тапа на «play» до первого кадра. < 2 с — хорошо; > 8 с предсказывает отток.
• Доля ребуферизации. Секунды ожидания буфера, делённые на общее время сессии. Держите ниже 1%; 5% — это уже кризис.
• Выход до старта видео. Пользователи, которые тапнули play и ушли до первого кадра. Почти всегда — ошибка манифеста или DRM.
• Переключения битрейта в минуту. Сигнал нестабильной сети или ABR-алгоритма.
• Потерянные кадры по моделям устройств. Вылавливает тот единственный чипсет smart-TV, которому не нравится ваш HEVC-профиль.
• Доля отказов лицензии по DRM. > 0,5% — это баг в конфиге лицензирования, который прячется на виду.

Подключайте Conviva, Youbora (NPAW), Mux Data или собственный пайплайн Kafka → Snowflake. Для первых 100 тыс. подписчиков управляемая QoE-платформа дешевле. Свыше 1 млн собственный пайплайн часто выигрывает по стоимости и задержке.

Build vs. buy: матрица сравнения вендоров

Большинство основателей переоценивают, сколько им придётся писать самим. Большинство корпораций — недооценивают, во что обойдётся коробка на масштабе. Честный ответ обычно лежит в разделении стека.

Наша типичная рекомендация: возьмите Mux, Bitmovin или AWS Elemental на энкод и пакетирование; EZDRM или Axinom на лицензионные серверы; MDM, сервис прав и аналитику пишите сами. Это та граница, где собственная инженерия даёт сложный процент — и где на Agent Engineering мы заметно быстрее агентств, которые работают только числом людей.

Модель стоимости: реалистичная сборка за 12 месяцев

Цифры ниже — наши оценки 2026 года для типичного кастомного OTT с MDM-слоем класса Netflix, выполненного на Agent Engineering. Они намеренно консервативны: лучше прийти ниже, чем заявить много.

Этап 1 — MVP (4 месяца). Реестр устройств, менеджер сессий на Redis, сервис прав, мульти-DRM-брокер с подключением к управляемому лицензионному вендору, HLS/DASH через CMAF, веб- + iOS- + Android-приложения. Бюджет: ~6–10 млн ₽ в зависимости от объёма дизайна и числа интеграций.

Этап 2 — ТВ и smart-TV (2–3 месяца). tvOS, Android TV, Fire TV, Roku, LG/Samsung — там, где есть бизнес-обоснование. Каждая дополнительная платформа — две-шесть недель работы; smart-TV-платформы добавляют QA и сертификационные накладные расходы. Бюджет: ~3–6 млн ₽.

Этап 3 — Масштабирование и аналитика (2 месяца). Kafka-пайплайн, QoE-дашборд, модель детекции шеринга аккаунтов, админка, наблюдаемость. Бюджет: ~2,2–4,5 млн ₽.

Операционные расходы на 1 млн подписчиков. Обычно доминирует исходящий трафик CDN: 60–150 ₽ за ТБ доставленного контента, что выходит примерно в 1,1–3,7 млн ₽ в месяц для каталога средней вовлечённости. Транскодинг, лицензионные платежи и облачные вычисления добавляют ещё 750 тыс.–3 млн ₽ в месяц. Сам MDM-слой в эксплуатации стоит дёшево — основная цена это пиксели, которые он защищает.

Мини-кейс: чему мы научились, выкатывая платформу подписочного видео

Один недавний клиент попросил нас перестроить продукт подписочного видео, у которого счётчик одновременных стримов уезжал под нагрузкой. Симптом классический: пользователи на тарифе Standard (2 потока) иногда могли запустить третий; на Premium (4 потока) проскакивал седьмой. Корневая причина — неатомарный счётчик, обновляемый через REST-вызов длительностью ~120 мс: достаточно, чтобы две одновременные сессии обе прочитали «1» и обе записали «2».

Мы перенесли счётчик в Redis с Lua-скриптами для атомарного check-and-increment, привязали каждый сессионный токен к хэшу фингерпринта устройства и вынесли проверку параллелизма в брокер DRM-лицензий — так, чтобы она срабатывала после штампа прав, но до выдачи ключа. Двенадцать недель end-to-end. Результат: доля «перерасхода» упала с примерно 2,3% сессий до нуля за неделю после раскатки, обращения с тегом «неверный счёт стримов» сократились на 94%, а клиент перешёл на новые тарифы без возвратов.

Хотите похожий разбор по своему стеку? Свяжитесь с нами — приходите со схемой архитектуры, уйдёте со списком конкретных правок.

Каркас решения: ваш путь в пяти вопросах

1. Какая у вас цель по подписчикам на 18 месяцев? До 100 тыс. — стартуйте на Vimeo OTT или JW Player. 100 тыс.–500 тыс. — Mux или Bitmovin плюс тонкий кастомный MDM. Свыше 500 тыс. — стройте контрольную плоскость сами.

2. Нужен ли премиальный студийный контент? Если да — мульти-DRM (Widevine L1 + FairPlay + PlayReady SL3000) обязателен, и управляемый лицензионный вендор будет самым быстрым путём. Если нет — на старте может хватить и одного Widevine L3.

3. Сколько устройных платформ на дне запуска? Каждая платформа сверх iOS/Android/веба — это 4–8 недель и накладные на сертификацию. Расставляйте приоритеты по окупаемости CAC, а не по тщеславному охвату.

4. Будете ли вы тарифицировать одновременные стримы? Если да — счётчик сессий должен жить в MDM атомарно, не в плеере и не в биллинге.

5. Нужен ли гео-контроль и контроль окон показа? Если да — сервис прав должен видеть IP + ASN + страну на каждом запросе. Достраивать это потом больно: проектируйте с первой недели.

Пять ловушек, на которых рушатся запуски OTT

1. Считать стримы в плеере. Плеер можно подделать, закэшировать, реверс-инжинирить. Счётчик одновременных стримов должен жить на сервере, в идеале в DRM-брокере. Всё остальное — театр.

2. Долгоживущие DRM-токены. Лицензионный токен на 24 часа — это replay-атака, которая ждёт своего часа. Держите плейбэк-токены 5–15 минут, привязывайте к фингерпринту устройства и ротируйте на переключениях сессии.

3. Один режим шифрования для FairPlay и Widevine. FairPlay требует CBCS; Widevine исторически использовал CTR. CMAF разруливает это одним CBCS-энкодом, который принимают обе экосистемы, но старые тулчейны до сих пор пакуют криво. Проверяйте на живом Apple TV до запуска.

4. Игнорирование фрагментации smart-TV. Samsung Tizen 2019, LG webOS 4 и Roku-модели до 2021 года имеют нетривиальные пробелы в DRM и HEVC. Решите заранее, какие годы поддерживаете: каждый год вглубь — это ещё шесть недель QA.

5. Откладывать аналитику на «после запуска». Без QoE-данных с первого дня вы не поймёте, что 3% ребуферизации — это ваш CDN, ваш пакетировщик, ваш плеер или один сломанный HEVC-профиль на одном чипсете телевизора. Подключайте пайплайн до открытия беты.

KPI, которые стоит вынести на дашборд

KPI качества. Время старта < 2 с p75 на широкополосном, < 4 с на мобильном; доля ребуферизации < 1%; выход до старта видео < 0,5%. Разбивайте все три показателя по семействам устройств: один плохой профиль smart-TV способен испортить глобальную цифру.

Бизнес-KPI. Утилизация одновременных стримов по тарифам (используют ли пользователи Premium те 4 потока, за которые платят?); конверсия с шеринга аккаунтов на платный sharing-тариф; апгрейды тарифов, инициированные предупреждениями о лимите устройств. Это и есть числа, которыми окупается MDM-слой.

KPI надёжности. Доля отказов DRM-лицензии < 0,5%; задержка менеджера сессий по 99-му перцентилю < 50 мс; инциденты «перерасхода» на миллион сессий = 0. Если не получается выйти на ноль — счётчик не атомарен.

Когда кастомный MDM не нужен

Полный кастомный MDM — неверная инвестиция, если вы запускаете нишевый SVOD на горстке авторов, проводите ограниченную по времени маркетинговую кампанию или публикуете внутреннюю корпоративную обучающую библиотеку. Экономика не сходится ниже ~50 тыс. платных пользователей. Возьмите Vimeo OTT, JW Player или коробочную white-label-платформу, выпустите за недели и вернитесь к вопросу о собственной сборке только после того, как нащупаете product-market fit и счёт CDN, оправдывающий найм.

Аналогично, если ваша монетизация — только реклама и одновременные стримы вам безразличны, инженерные силы лучше вкладывать во вставку рекламы, SSAI и frequency capping, а не в MDM. Задача контроля у вас другая.

FAQ

«MDM» в OTT — это mobile device management, как Intune?

Нет. В контексте OTT MDM — это Multi-Device Management, бэкенд-сервис, который регистрирует пользовательские устройства, контролирует одновременные стримы и выдаёт DRM-лицензии для телефонов, планшетов, телевизоров и приставок. К корпоративным MDM-продуктам вроде Intune или Jamf это не имеет отношения.

Нам нужны Widevine, FairPlay и PlayReady — или можно выбрать одну?

Если в каталоге есть премиальный студийный контент — нужны все три. Widevine закрывает Android/Chrome/большинство smart-TV, FairPlay — экосистему Apple, PlayReady — Windows/Xbox/Roku/многие телевизоры. С пакетированием в CMAF контент кодируется и хранится один раз, а отдаётся всем трём DRM через разные манифесты.

Какой реалистичный бюджет на кастомный OTT MDM?

MVP с реестром устройств, менеджером сессий, сервисом прав, DRM-брокером и веб-/iOS-/Android-приложениями обычно укладывается в 6–10 млн ₽ за примерно четыре месяца. Полная сборка с приложениями для smart-TV, аналитикой и моделями детекции шеринга добавляет ещё 5–10 млн ₽ и три-четыре месяца. На масштабе операционные расходы определяются CDN и лицензиями.

Сколько одновременных стримов выставлять на тариф?

Отраслевой дефолт — 1/2/4 (Basic/Standard/Premium). Стартуйте отсюда и подстраивайтесь по реальной утилизации. Перебор с лимитами съедает апселл; недобор провоцирует поведение «отписался — переподписался», которое бьёт по LTV. Понаблюдайте 90 дней за фактической утилизацией по тарифам, прежде чем двигать пороги.

Можно ли добавить контроль шеринга после запуска?

Да, но это сильно проще, если MDM с самого начала собирает фингерпринты устройств и связку IP+ASN на каждую сессию. Достроить фингерпринтинг по живым клиентским приложениям — задача с релиз-поездом: ваши самые старые версии клиентов не пришлют нужные данные. Собирайте с первого дня, контроль включайте, когда будете готовы.

Что делать, когда пользователь действительно уехал в командировку?

Не блокируйте жёстко. Повторите паттерн Netflix: мягкое предупреждение по сигналу «невозможное гео», запрос одноразового подтверждения на основном домашнем устройстве в течение 7 дней и скользящее окно поездок (обычно 31 день). Логируйте IP-след, чтобы потом аудировать ложные срабатывания — ожидайте, что 0,5–2% реальных путешественников зацепят эту эвристику.

MDM должен жить в одном сервисе с биллингом?

Нет. Держите их раздельными сервисами с чистым контрактом. Биллинг владеет состоянием подписки; MDM — состоянием устройств и сессий. Сервис прав их сводит. Это разделение окупается в первый же раз, когда вы меняете биллинг-провайдера или выходите на новый рынок с другой логикой тарифов.

Почему Фора Софт делает быстрее, чем большинство OTT-агентств?

Две причины. Во-первых, мы переиспользуем боевое ядро реестра устройств, менеджера сессий и брокера лицензий из прошлых OTT-проектов — каждый новый проект стартует уже примерно на отметке 30%. Во-вторых, наши команды применяют Agent Engineering на дизайне, генерации кода, написании тестов и QA — это измеримо сжимает фазу сборки без компромиссов по архитектуре и комплаенсу.

Что читать дальше

Готовы построить OTT-платформу, которая масштабируется?

Кастомный слой Multi-Device Management — не самая яркая часть OTT-платформы, но именно он решает, удержатся ли ваши тарифы, согласятся ли студии выдать лицензию и останется ли счёт за CDN адекватным. Эталонная архитектура из пяти сервисов — реестр устройств, менеджер сессий, сервис прав, DRM-брокер, аналитика — это тот же паттерн, на котором работают Netflix, Disney+ и HBO Max. Ваша задача — реализовать его честно и сделать невидимым для пользователя.

Если вы ниже 100 тыс. подписчиков — покупайте. Если выше 500 тыс. или туда движетесь — стройте, но раскладывайте сборку так, чтобы что-то рабочее показывалось через четыре месяца, а не через двенадцать. Мульти-DRM через CMAF — решённая задача; коробочные лицензионные серверы — дешёвые; искусство сидит в контрольной плоскости. Именно там мы проводим большую часть времени на OTT-проектах.