Метаданные видео: топливо для discovery в стриминге

TL;DR

Метаданные – это всё, что верно про тайтл, кроме самого видеофайла: название, актёры, жанр, сюжет, тот факт, что это эпизод 3 второго сезона, языки, которые он несёт, и кто, где и когда имеет право его смотреть, – и они делятся на четыре вида: descriptive, structural, technical и administrative (права). Любая функция discovery, какую ни назови, читает метаданные, а не само видео: content-based рекомендации, поиск, ряды на главном экране и результат, который Google показывает по запросу с вашим тайтлом, работают на них – поэтому бедные метаданные делают хороший каталог невидимым. Индустрия построила стандарты для тех частей, где ошибка дороже всего: универсальный идентификатор контента EIDR, чтобы все системы соглашались, какой это тайтл; схемы MovieLabs Common Metadata и Media Entertainment Core (MEC), чтобы паблишер и платформа могли обмениваться каталогом без своего парсера на каждую сделку; и структурированные данные Schema.org, чтобы поисковики могли прочитать ваши тайтлы. Практическая работа – это пайплайн, который принимает метаданные из многих источников, нормализует их к одному словарю, обогащает ручной разметкой и машинными инструментами и управляет их качеством: неприметная обвязка, которая и решает, есть ли у рекомендера из предыдущей статьи вообще с чем работать.

Почему это важно

Если вы запускаете стриминговый сервис или строите его, большую часть бюджета вы потратите на две вещи: лицензирование или производство контента и его доставку. Метаданные – это дешёвая, заброшенная третья вещь, которая решает, окупятся ли первые две, потому что тайтл, который нельзя найти, – это тайтл, который никто не смотрит, и лицензионный платёж, который вы выбросили. Рекомендательная система, поле поиска, ряд «Боевики-триллеры» и ваша видимость в Google сидят поверх метаданных и наследуют их качество ровно – дайте им каталог, описанный только названием и жанром, и они поведут себя как библиотека с вырванным каталожным ящиком. Эта статья написана для основателя, продакт-менеджера или первого стримингового CTO, которому нужно решить, какие метаданные собирать, какие стандарты принять и сколько должен стоить пайплайн разметки, – чтобы у рекомендательной системы из предыдущей статьи было топливо для сжигания. Схему вы руками писать не будете; но вы обязаны понимать достаточно, чтобы её специфицировать и чтобы отказаться от каталога, приходящего с пустыми полями.

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

Начнём с предельно простого определения. Данные, которые описывают единицу контента, – всё, что можно знать о тайтле, не смотря его, – называются метаданными, что буквально значит «данные о данных». Если видеофайл – это книга, то метаданные – это библиотечная карточка: название, автор, тема, полка, на которой книга стоит, и пометка о том, кому её разрешено брать. Карточка – не книга, но без карточки книгу не найти, и библиотека ровно настолько пригодна, насколько её карточки полны и верны.

Вот мысль, которая удивляет людей, и она же – вся причина существования этой статьи: софт не умеет смотреть ваши видео. Рекомендательная модель не видит триллер и не чувствует напряжения; поисковик не понимает сюжета. Они читают поля – текст и числа, привязанные к тайтлу, – и действуют по ним. Когда зритель набирает «документалки про космос», поле поиска не сканирует кадры в поисках звёзд; оно сопоставляет слово документальный и слово космос с полями, которые кто-то заполнил. Когда главный экран строит ряд «Потому что вы смотрели» из похожих тайтлов, он сравнивает жанр, актёров и теги одного тайтла с другим. Любое решение discovery – это решение, принятое по метаданным. Видео – это то, что вы доставляете; метаданные – это то, по чему вас находят.

Поэтому в заголовке этой статьи метаданные названы топливом. Движок – рекомендер, поисковый индекс, логика мерчандайзинга – впечатляющая машинерия, но он сжигает метаданные и не может работать на пустом баке. Блестящая рекомендательная модель, которой дали три поля на тайтл, выдаёт тусклые, повторяющиеся ряды; средняя модель, которой дали двадцать богатых полей на тайтл, ощущается персональной. Преимущество – в топливе, а не только в движке, и топливо – это та часть, на которой большинство команд экономит.

Четыре вида метаданных

Метаданные – это не одно; они приходят в четырёх видах, и разделение их помогает увидеть, какими из них вы пренебрегаете. Четыре вида – descriptive, structural, technical и administrative. Только первые два напрямую двигают discovery, но все четыре нужны для работы платформы, а именно discovery-виды команды чаще всего оставляют бедными.

Descriptive-метаданные – это понятное человеку описание тайтла: его название, синопсис, жанр, актёры и съёмочная группа, язык, год выпуска, ключевые слова и теги, настроение, темы. Это топливо discovery в самом прямом смысле – именно это сравнивает content-based рекомендер, по этому матчит поиск и из этого строятся ряды. Когда в этой статье говорится «богатые метаданные», имеются в виду в основном descriptive-метаданные, уходящие далеко за пределы «название и жанр» в фактуру тайтла: не просто «комедия», а «офисная комедия, ансамблевый каст, действие в 1990-х, тёплый финал».

Structural-метаданные описывают, как организован контент и как соотносятся его части. Стриминговый каталог – не плоский список файлов; это иерархия: сериал содержит сезоны, сезон содержит эпизоды, эпизод может иметь главы, а у фильма могут быть трейлер, дублированная версия и режиссёрская версия, описывающие одно и то же произведение. Structural-метаданные – это то, что позволяет приложению показать «Сезон 2, эпизод 3», возобновить просмотр в нужном месте, сгруппировать франшизу и знать, что трейлер и фильм связаны. Ошибитесь – и вы отгрузите стыдные баги: эпизоды не по порядку, дубляж как отдельный несвязанный фильм, «следующий эпизод», прыгающий не в тот сезон.

Technical-метаданные описывают файл и поток: разрешение, кодек, лестницу битрейтов, аудиодорожки, дорожки субтитров, длительность, соотношение сторон, применённую схему DRM. Плеер и пайплайн доставки читают их, чтобы выбрать нужную версию и знать, что 4K HDR-версия существует. Они редко двигают discovery напрямую, но всплывают как бейджи – метки «4K», «HDR», «5.1», по которым зритель фильтрует, – так что в discovery они просачиваются с краёв.

Administrative-метаданные покрывают владение, права и доступность: кто владеет тайтлом или лицензировал его, на каких территориях его можно стримить, между какими датами, по какой бизнес-модели и с каким возрастным рейтингом. Это те метаданные, что решают, может ли тайтл вообще появиться для конкретного зрителя, – то есть они закрывают discovery ещё до его начала: идеально подходящий зрителю тайтл всё равно должен быть скрыт, если лицензия не покрывает страну этого зрителя сегодня. Права и доступность подробно разобраны в блоке про лицензирование и окна релизов; здесь достаточно знать, что доступность – это поле метаданных, которое слой discovery обязан проверять всегда.

Нажмите, чтобы увеличить

Таблица ставит четыре вида рядом, с той колонкой, что важнее всего для этой статьи: двигает ли он discovery?

Таблица 1. Четыре вида метаданных и двигает ли каждый discovery. Жестокая асимметрия стриминга: каталоги почти всегда приходят полными по technical (его автоматически заполняет энкодер) и бедными по descriptive (его должен написать человек) – а ведь именно descriptive discovery и сжигает.

Почему метаданные – это топливо для discovery

Стоит конкретно перечислить каждое место, где метаданные сжигаются, потому что список длиннее, чем ждёт большинство команд, и каждый пункт деградирует ровно в тот момент, когда метаданные становятся бедными.

Первый потребитель – content-based рекомендер. Как разобрано в статье про рекомендательные системы, content-based фильтрация рекомендует тайтлы, чьи атрибуты похожи на уже понравившиеся, и эти атрибуты и есть descriptive-метаданные. Имея для сравнения только жанр, рекомендер может сказать «вы смотрели комедию – вот ещё комедия» и почти ничего больше. Имея актёров, режиссёра, настроение, тему, эпоху и двадцать тегов, он может сказать «вы досмотрели три медленные характерные драмы, действие которых в маленьких городках, – вот четвёртая, которую с ними никто не связывал». Рекомендер тот же; разница целиком в топливе.

Второй потребитель – проблема холодного старта (cold start). Предыдущая статья показала, что у совсем нового тайтла нет истории со-просмотров, поэтому collaborative filtering – подход «те, кто смотрел это, ещё смотрели то» – к нему слеп. Единственное, что может всплыть новый тайтл в день первый, – его метаданные, потому что content-based фильтрация может сразу поставить его рядом с похожими. Это самое острое бизнес-следствие бедных метаданных: ваши новейшие, активнее всего продвигаемые, дороже всего лицензированные тайтлы – ровно те, у кого нет данных о поведении, так что они живут или умирают на одном описании. Сэкономьте на метаданных – и вы построили платформу, которая хуже всего показывает контент, который вы больше всего хотите показать.

Третий потребитель – поиск. Когда зритель набирает запрос, поисковый индекс сопоставляет его с descriptive-полями. Каталог, размеченный только названием и жанром, отвечает на «комедия», но проваливает «тёплая офисная комедия с ансамблевым кастом» – запрос, на который богато размеченный каталог отвечает легко. Поиск и его связь с discovery подробно разобраны в статье про поиск; здесь суть в том, что качество поиска – это следствие глубины метаданных.

Четвёртый потребитель – мерчандайзинг, ряды и обложки на главном экране, разобранные в статье про мерчандайзинг. Ряд «Признанные критиками драмы 2010-х» может существовать только если тайтлы несут поля признание, жанр=драма и десятилетие=2010-е. Каждый тематический ряд – это запрос по метаданным; чем богаче метаданные, тем больше рядов вы можете построить и тем персональнее ощущается главный экран.

Пятый потребитель сидит вообще вне вашего приложения: поисковики и ИИ-ассистенты. Когда кто-то ищет ваш тайтл в Google или спрашивает у ассистента «где посмотреть X», ответ собирается из структурированных метаданных, которые вы публикуете на своих веб-страницах, – поля Schema.org, разобранные дальше в этой статье. Discovery не заканчивается на краю вашего приложения; его часть происходит в Google, и эта часть тоже работает на метаданных.

Нажмите, чтобы увеличить

Объединяющая мысль – старейшее правило в вычислениях: мусор на входе – мусор на выходе. Слой discovery не может быть лучше, чем метаданные под ним. Поэтому чистый пайплайн метаданных и есть неприметное ядро персонализации – это не та часть, которую кто-то демонстрирует, но именно она решает, заработает ли демо на реальном каталоге.

Проблема идентификатора: каждому тайтлу нужно имя, с которым согласны машины

Прежде чем метаданные станут полезны, каждая система должна согласиться, какой именно тайтл описывает данная запись, – и это оказывается удивительно трудно. Ваш энкодер зовёт его ассетом A-44871. Студия, лицензировавшая его вам, зовёт его WB-2019-0345. У вашего ad-сервера свой ID. У стороннего провайдера метаданных – ещё один. Когда отчёт по правам, рекомендация и проверка доступности все ссылаются на «один и тот же фильм», ничто технически не гарантирует, что они и правда имеют в виду один фильм, а рассогласование наносит реальный ущерб: не тот тайтл гаснет на территории, роялти считаются неверно, две копии одного фильма захламляют каталог как разные произведения.

Ответ индустрии – общий универсальный идентификатор под названием EIDR (Entertainment Identifier Registry). EIDR присваивает произведению один постоянный ID, которым может пользоваться любая компания, – так же как ISBN идентифицирует книгу независимо от магазина. Технически EIDR-ID – это разновидность DOI, той же системы постоянных идентификаторов, что используется для научных статей, и он резолвится в запись метаданных, описывающую произведение (EIDR, 2026). Content ID выглядит как 10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C, и реестр иерархичен ровно так, как нужно structural-метаданным: у сериала есть ID, у его сезонов – ID, указывающие на сериал, у каждого эпизода – ID, указывающий на его сезон (EIDR, 2026). IETF даже стандартизировал, как записывать EIDR-идентификатор в виде URN, чтобы он чисто путешествовал между системами (IETF RFC 7972, 2016).

Зачем основателю реестр ID? Потому что проприетарные ID стоят денег. Заявленная цель самого EIDR – устранить «дорогие трансляции между проприетарными системами ID», снизить «риски ошибочной идентификации из-за дублирования» и улучшить «способность сопоставлять ассеты и метаданные из разных баз, сервис-провайдеров и поставщиков метаданных» (EIDR, 2026). Простыми словами: примите общий ID – и тайтл, лицензированный у трёх студий, отслеживаемый вашим ad-сервером и попадающий в отчёты по роялти, сойдётся автоматически; пропустите его – и вы вечно платите инженерам за поддержку хрупких таблиц трансляции и съедаете стоимость каждого рассогласования. Любой желающий может бесплатно резолвить любой EIDR-ID и получить его descriptive-метаданные – отчасти поэтому он и работает как общая почва (EIDR, 2026).

Практическая инструкция коротка: требуйте, чтобы лицензированный контент приходил с EIDR-ID там, где они есть, и присваивайте канонические ID внутри для всего остального, чтобы «это тот же тайтл?» никогда не было догадкой.

Проблема обмена: говорить на одном языке метаданных

Идентификатор говорит, какой тайтл. Вторая проблема – как написано само описание, потому что метаданные приходят от многих поставщиков в многих формах. Одна студия присылает таблицу с колонкой «Genre»; другая – XML с «category»; третья пишет «Sci-Fi» там, где первая написала «Science Fiction». Умножьте это на тысячи тайтлов и десятки полей – и получите самую частую операционную головную боль стриминга: каждый каталог, который вы принимаете, говорит на чуть ином диалекте, а ваша платформа должна перевести их все в один.

Ответ индустрии здесь – общая схема: согласованный список полей, их значений и допустимых величин. Доминирующая в кино и ТВ – MovieLabs Common Metadata и её профиль доставки Media Entertainment Core (MEC). Эти спецификации, определённые Entertainment Merchant's Association и Digital Entertainment Group вместе с MovieLabs, существуют специально «для передачи метаданных от паблишеров ритейлерам» – то есть от студии, владеющей тайтлом, к платформе, которая его стримит (MovieLabs, 2025). MEC – это XML-схема с формальными определениями полей и даже контролируемыми словарями, такими как стандартный список жанров, чтобы «Science Fiction» означало одну согласованную вещь, а не пять написаний (MovieLabs MEC v2.25, 2025).

Ценность общей схемы та же, что у общего ID: она убирает шаг трансляции, который иначе оплачивается инженерным временем и багами качества. Когда паблишер отдаёт каталог в MEC, а ваша платформа принимает MEC, поле жанра попадает в поле жанра, актёры – в актёров, структура сезон-эпизод приходит целой – без своего парсера на каждого поставщика, без чистки «Sci-Fi против Science Fiction». Нормализовать и обогащать вы всё равно будете (об этом ниже), но вы стартуете от известной формы, а не от кучи несовпадающих таблиц. Для платформы, лицензирующей контент из многих источников, принятие отраслевой схемы – это разница между пайплайном приёма, который масштабируется, и тем, которому нужен новый кастомный импортёр на каждую сделку.

Нажмите, чтобы увеличить

Метаданные для открытого веба: структурированные данные и discovery за пределами приложения

Большая доля discovery никогда не происходит внутри вашего приложения. Кто-то ищет фильм в Google или спрашивает у ИИ-ассистента, где посмотреть шоу, – и появляется результат, в идеале ваш. Этот результат строится из третьего стандарта метаданных, нацеленного на поисковики, а не на студии: структурированных данных Schema.org, выраженных в формате JSON-LD.

Schema.org определяет типы словаря для медиа – VideoObject для отдельного видео, Movie и TVSeries для произведений, – которые вы встраиваете в свои веб-страницы, чтобы поисковик мог прочитать ваш каталог не гадая. Документация Google прямо говорит, что JSON-LD – рекомендуемый формат и что видео нужны как минимум название, URL обложки и дата загрузки, плюс ссылка на контент, а описание и длительность настоятельно рекомендуются (Google Search Central, 2026; Schema.org, 2026). Разметьте страницу правильно – и она станет претендентом на video rich results (картинка с кнопкой play в выдаче), а ключевые моменты внутри видео можно даже выставить через свойства SeekToAction и Clip, чтобы Google вёл на нужную метку времени (Google Search Central, 2026).

Почему это место в статье про discovery, а не только в SEO-чек-листе: это то же топливо, делающее ту же работу в другом движке. Внутри приложения descriptive-метаданные кормят рекомендер; в открытом вебе те же descriptive-факты – название, описание, обложка, длительность, актёры – кормят индекс Google и ответы, которые собирают ИИ-ассистенты. Платформа, собирающая богатые метаданные для внутреннего discovery, почти бесплатно получает сырьё и для внешнего. Этот раздел Learn практикует, что проповедует: каждая статья здесь отгружает структурированные данные (Article, FAQPage, BreadcrumbList) ровно по этой причине.

Как каталог на самом деле размечается: люди, провайдеры и машины

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

Первый – ручная разметка. Люди смотрят контент и фиксируют структурированные суждения о нём. Самый известный пример – Netflix, чьи усилия по метаданным стали легендой: компания нанимала и обучала «таггеров», работавших по детальному руководству, чтобы оценивать тайтлы по измерениям далеко за пределами жанра – тон, уровень романтики, личность главных героев, даже насколько определённо заканчивается сюжет, – и комбинировала тысячи таких тегов в десятки тысяч гиперспецифичных «alt-жанров» вроде «Признанные критиками эмоциональные фильмы про аутсайдеров». Репортажи вокруг этого описывают порядка 76 000 микротегов, собранных в грамматику региона, прилагательного, жанра и темы. Считайте точные числа журналистикой, а не спецификацией, но принцип верен и поучителен: ручная разметка производит ту нюансированную descriptive-метадату, которая делает content-based рекомендации сверхъестественно точными, и это вид топлива, который машина пока не умеет полностью генерировать. Цена в том, что ручная разметка медленна, дорога и – между разными людьми и поставщиками – непоследовательна без строгого словаря.

Второй – сторонние провайдеры метаданных. Специализированные компании продают готовые descriptive-метаданные – актёры, съёмочная группа, синопсисы, жанры, обложки и ID – для больших каталогов коммерческого кино и ТВ, так что вы покупаете чистое описание вместо того, чтобы его писать. Это быстро и последовательно для массового контента; слабее для нишевого, регионального или оригинального контента, который провайдер никогда не каталогизировал, – а это ровно тот контент, который обычно несёт дифференцированная платформа. Провайдеры обычно привязывают данные к общим ID (включая EIDR) – ещё одна причина, почему проблема идентификатора идёт первой.

Третий, и быстрее всего растущий, – автоматическое обогащение – генерация метаданных из самого контента софтом. Современные инструменты анализируют видео и аудио, чтобы детектировать сцены, объекты, лица, логотипы, произнесённые слова (через speech-to-text) и настроение, а затем выписывают это тегами – модели компьютерного зрения и распознавания речи, которые это делают, разобраны в разделе AI for Video Engineering, так что здесь мы остаёмся на продуктовом слое метаданных. Важная отдельная техника – фингерпринтинг контента, он же automatic content recognition (ACR): система вычисляет компактный «отпечаток» из визуальных кадров или аудиосигнала тайтла и сопоставляет его с базой, чтобы опознать контент даже без имени файла или ID (Tatari, 2024). Фингерпринтинг – это то, что позволяет платформе распознать дубль-загрузку, опознать контент без меток и связать ассет с его канонической записью. ИИ-обогащение масштабируется так, как ручная разметка никогда не сможет, – оно может разметить каталог из 50 000 тайтлов за время, за которое команда людей размечает несколько сотен, – но ему нужен контроль качества, потому что модель, ошибочно помечающая «триллер» как «комедию», загрязняет каждую рекомендацию ниже по течению. Реалистичный паттерн 2026 года – смесь: машины делают широкий высокообъёмный первый проход и фингерпринтинг; люди курируют, исправляют и добавляют нюансированные теги, которые важнее всего; провайдеры закрывают массовый каталог.

Нажмите, чтобы увеличить

Рабочий пример: бедные метаданные против богатых

Сделаем цену конкретной, потому что аргумент за траты на метаданные легко отмахнуть, пока не увидишь арифметику. Представьте каталог из 10 000 тайтлов и content-based рекомендер, который связывает два тайтла, когда у них общие descriptive-атрибуты.

В каталоге с бедными метаданными каждый тайтл несёт три полезных descriptive-поля: название, один жанр и год. Жанр – единственное поле с заметной матчинг-силой, и допустим, каталог использует 12 жанров. В среднем тогда тайтл делит жанр примерно с 10 000 ÷ 12 ≈ 833 другими тайтлами – настолько грубое совпадение, что «похожий» значит немногим больше, чем «тоже драма». Content-based ряды рекомендера будут широкими и повторяющимися, а новый тайтл падает в корзину из 833 без ничего, что бы его выделило.

Теперь обогатите тот же каталог так, чтобы каждый тайтл нёс, скажем, 25 descriptive-атрибутов: жанр, поджанр, настроение, тему, десятилетие, сеттинг, трёх актёров, режиссёра, тон, темп и дюжину тегов. Два тайтла теперь «похожи», когда совпадают по нескольким атрибутам, а не по одному. Число тайтлов, совпадающих, например, по жанр=драма И настроение=медленное И сеттинг=маленький город И десятилетие=2010-е, обрушивается с 833 до, возможно, горстки – а это ровно та точная, неожиданная рекомендация «как оно угадало», которая удерживает подписчиков. Модель не изменилась. Размер каталога не изменился. Изменилось только топливо – и вместе с ним качество каждой content-based рекомендации.

Та же арифметика объясняет и чистый бизнес-убыток. Если бедные метаданные оставляют, скажем, 15% каталога из 10 000 тайтлов фактически невсплываемыми – слишком обобщённо описанными, чтобы рекомендер или поиск когда-либо хорошо их разместили, – это 1 500 тайтлов, которые вы лицензировали или произвели, а потом спрятали. Даже при скромной средней стоимости лицензии это крупное повторяющееся списание с дешёвым лекарством: опишите каталог как следует. Метаданные – редкая статья расходов, где малая инвестиция напрямую спасает большую.

Частая ошибка: относиться к метаданным как к запоздалой мысли

Самая дорогая ошибка с метаданными она же самая частая: относиться к ним как к бумажной работе «на потом». Команда запускается с тайтлами, описанными названием и жанром, обещает «добавить теги после запуска» и отгружает рекомендер и поиск, которым не с чем работать, – а потом винит алгоритмы. Лекарство – относиться к descriptive-метаданным как к требованию запуска, а не к пункту бэклога, потому что каждая построенная вами функция discovery от них зависит.

Вторая ошибка – пропуск нормализации – позволить каждому поставщику держать свой словарь. Один фид говорит «Sci-Fi», другой – «Science Fiction», третий – «SF», и рекомендер трактует их как три несвязанных жанра, незаметно фрагментируя каталог. Лекарство – единый канонический словарь, к которому каждое принимаемое поле мапится на входе, что и даёт фору общая схема вроде MEC.

Третья ошибка – отсутствие канонического идентификатора – принять один фильм из двух источников и сохранить его дважды, потому что ничто не сказало системе, что это одно произведение. Результат – дублирующиеся записи каталога, расщеплённые данные просмотра и спутанные рекомендации. Лекарство – EIDR или внутренний канонический ID, применённый на приёме, с фингерпринтингом, чтобы ловить проскользнувшие дубли. Пропустите описание – discovery голодает; пропустите нормализацию – каталог фрагментируется; пропустите идентификатор – он дублируется. Все три провала дёшево предотвратить на приёме и дорого чинить после запуска.

Где здесь Фора Софт

Система метаданных – это та неприметная, определяющая масштаб обвязка, которую Фора Софт строила многократно: слой приёма, принимающий каталоги от многих поставщиков, шаг нормализации, мапящий диалект каждого поставщика к одному каноническому словарю и одному идентификатору, стадия обогащения, смешивающая ручную разметку с ИИ и инструментами фингерпринтинга, и слой governance, держащий каталог точным по мере роста. За 250+ реализованных проектов для 400+ клиентов с 2005 года в видеостриминге, OTT/Internet TV, e-learning и видеонаблюдении повторяющийся урок таков: качество discovery задаётся задолго до рекомендательной модели – оно задаётся в пайплайне метаданных. Наш подход scalability-first и vendor-neutral: мы стартуем от размера и «грязности» вашего каталога и числа источников, которые вы принимаете, затем строим пайплайн приём-нормализация-обогащение-governance и подключаем его к поиску, рекомендациям и вашей публичной Schema.org-разметке на web, mobile и TV – чтобы у движка discovery ниже по течению было чистое, богатое топливо для сжигания.

Ключевые выводы

• Метаданные – это всё про тайтл, кроме видео; софт находит тайтлы по ним, а не смотря.
• Четыре вида – descriptive, structural, technical, administrative – но топливо discovery это descriptive и structural.
• Каждая поверхность discovery (рекомендации, поиск, ряды, cold start, Google) работает на одних метаданных.
• EIDR даёт один универсальный ID тайтла; MovieLabs MEC – одну схему обмена; Schema.org кормит открытый веб.
• Разметка смешивает людей, сторонних провайдеров и ИИ-обогащение плюс фингерпринтинг – с контролем качества.
• Пропустите метаданные – discovery голодает; лекарство – пайплайн приём-нормализация-обогащение-governance до запуска.

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

• Рекомендательные системы для видео
• Поиск и обнаружение контента
• Data-пайплайн персонализации