QoE-метрики: что должен показывать любой дашборд видеостриминга

Кратко

Quality of Experience (QoE) в видеостриминге – это измеримый ответ на один вопрос: получил ли зритель ту картинку, которую ожидал, в нужный момент, с нужным качеством, и остался ли он смотреть. Отраслевой консенсус 2026 года – это ядро из шести метрик: Video Start Failure (VSF), Exit Before Video Start (EBVS), Video Startup Time (VST), Rebuffering Ratio, Video Playback Failure (VPF) и перцептуальная оценка качества картинки. Все шесть стандартизированы документом Consumer Technology Association – CTA-2066 – и теперь надёжно извлекаются из любого современного плеера через CMCD v2 (CTA-5004-A, опубликованный в апреле 2024 года и массово развёрнутый к середине 2026 года). Цифры за этими метриками безжалостны: статья Кришнана и Ситарамана 2012 года, основанная на 23 млн сессий из сети Akamai, показала, что зритель начинает уходить уже после двух секунд задержки старта, а каждая дополнительная секунда добавляет 5,8 процентных пункта оттока; один процентный пункт rebuffering ratio стоит около пяти процентных пунктов общего времени просмотра. Современный дашборд превращает эти факты в пороги, алерты, сегментацию и единый композитный балл, который одновременно понятен финансовому директору, тимлиду инженерии и продакт-менеджеру.

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

Если ваш бизнес зависит от того, чтобы зрители смотрели видео – OTT-подписка, права на спортивную трансляцию, платформа вебинаров, телемедицина, корпоративное обучение, видеонаблюдение, – QoE – это мост между «протокол работает» и «бизнес работает». Каждый доллар, потраченный на более быструю CDN, плотный битрейтный лестничный список, низколатентный протокол или умный ABR, отображается всего в двух местах: улучшается QoE-метрика, и в ответ меняется бизнес-метрика (минуты просмотра, конверсия в сессию, отток). Дашборды, где смешаны не те метрики, агрегированы не так, как нужно, или не сегментированы по ключевым осям, скрывают и победы, и провалы – а операционная команда тратит часы на поиск проблем, которых не видно, пока реальная авария (например, региональный failover CDN, удвоивший VST на Roku) остаётся незамеченной.

Это девятая статья Блока 9 (Эксплуатация, DRM, реклама и QoE) в учебном корпусе Фора Софт Learn по видеостримингу. Читайте после «Криминалистические водяные знаки и A/B-стриминг» и перед сравнением аналитических платформ «Mux Data, Conviva, Bitmovin Analytics, Datazoom, NPAW». Продакт уйдёт зная, какие шесть метрик должны быть на исполнительном дашборде, почему каждая важна и как выглядит «хорошо» в 2026 году. Инженер уйдёт с определениями CTA-2066, картой полей CMCD v2, правилами агрегации, которые отделяют осмысленное число от вводящего в заблуждение, и восемью производственными ловушками – нестационарная агрегация, EBVS как метрика вовлечённости, рекламный буфер, «глобальные пороги», – которые превращают зелёный дашборд в ложное чувство безопасности.

Что такое QoE – и чем оно не является

Quality of Experience – это не Quality of Service. QoS описывает сеть: пропускную способность, потери пакетов, джиттер, RTT – нижний транспортный слой, разобранный в статье «TCP и UDP в стриминге». QoE описывает человека: появилась ли картинка, не прервалась ли, выглядит ли она достаточно хорошо, остался ли зритель. Они скоррелированы – сеть с 5% потерь пакетов почти всегда деградирует QoE, – но это разные вещи. Дашборд, показывающий только QoS, надёжно пропустит проблемы QoE, которые рождаются выше транспортного уровня: баг плеера, ошибку в манифесте, всплеск промахов CDN-кеша, таймаут DRM-лицензии, провал midroll-рекламы на Smart TV.

Техническое определение, которое индустрия теперь использует, прописано в спецификации CTA-2066 – «Streaming Quality of Experience Events, Properties and Metrics», опубликованной в октябре 2020 года проектом CTA WAVE – кросс-вендорной рабочей группой, в которую входят Akamai, AWS, Cisco, Comcast, Conviva, Disney, Fox, Mux, Verizon и большинство аналитических вендоров, которых оператор может рассмотреть. CTA-2066 стандартизировала имена, определения, единицы и правила агрегации для более чем тридцати метрик качества стриминга – так что число с подписью «Rebuffering Ratio» в дашборде Mux означает то же, что и в дашборде Conviva или в самописном решении. До 2020 года это свойство не выполнялось.

Рабочее определение, адаптированное из CTA-2066 и технического бюллетеня SVTA «OTT Streaming QoE Requirements»: QoE – это набор измеримых свойств сессии воспроизведения, которые вместе предсказывают, соответствует ли восприятие видеоопыта зрителем его ожиданиям. Две половины важны: «измеримый» исключает дашборды на эмоциях, а «предсказывают восприятие зрителя» исключает метрики, которые зритель не чувствует. Uptime CDN в 99,99% – не QoE-метрика; зритель не почувствует 30-секундный сбой в свой обеденный перерыв. Пятисекундный rebuffer, прервавший последнюю минуту финала Лиги чемпионов, – почувствует. Дашборд должен быть построен вокруг того, что чувствует зритель, а не того, что сообщает инфраструктура.

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

Шесть базовых метрик каждого дашборда

Многие операторы выкатывают дашборды с тридцатью, пятьюдесятью или сотней метрик. Производственный консенсус 2026 года – видимый в Conviva Streaming Performance Index, Mux Data Viewer Experience Score, Bitmovin Analytics QoE Score и NPAW Happiness Score – в том, что шесть метрик несут примерно 90% сигнала. Остальные двадцать-девяносто – диагностика. Постройте сначала эти шесть; диагностику накладывайте по мере того, как этого требует ваш incident-response плейбук.

1. Video Start Failure (VSF)

VSF – процент попыток воспроизведения, которые завершились до первого кадра с фатальной ошибкой плеера. Зритель нажал Play; плеер попытался стартовать; что-то – 404 на манифесте, истёкшая DRM-лицензия, неподдерживаемый кодек на устройстве, неверная конфигурация CORS, таймаут TLS – прервало сессию до появления картинки. CTA-2066 называет это Stream Initialisation Failure; все аналитические вендоры зовут это VSF.

VSF – первая метрика на дашборде, потому что неудачный старт не порождает зрителя; он порождает раздражённого человека, который уходит. Хорошие отраслевые пороги в 2026 году – 0,5–1,0% для устоявшихся сервисов; топовые OTT-бренды держат VSF ≤ 0,3%. Рост VSF на 1% при пяти миллионах ежедневных запусков – это пятьдесят тысяч дополнительных провалов в день; при среднем доходе 0,10$ за сессию недельная потеря выражается тысячами долларов, не считая ущерба бренду от пятидесяти тысяч зрителей, считающих, что у вас сломан продукт.

2. Exit Before Video Start (EBVS)

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

Обновление определения EBVS от Mux Data в августе 2024 года – самое явное: любая сессия, закончившаяся за меньше чем одну секунду, не получает QoE-балла вообще – на том основании, что зритель не пытался смотреть. Streaming Performance Index от Conviva трактует EBVS без заметного ожидания как событие «поведения зрителя» и исключает его из балла, тогда как EBVS-сессии, длившиеся более двух секунд до отказа пользователя, оцениваются на 50 (хуже успешного старта, лучше полного провала). Этот нюанс важен: наивная метрика «учитывать весь EBVS» будет красить дашборд красным при каждой смене лейаута карусели на главной, хотя в стриминге не сломалось ничего.

Best practice 2026 года – отслеживать два ряда EBVS: EBVS-Wait (сессии, которые сдались после измеримой задержки старта) – QoE-проблема, и EBVS-Bounce (сессии, закрытые за менее чем 1 с) – продуктовая / UX-проблема. Размещайте оба на дашборде, но в разных панелях.

3. Video Startup Time (VST)

VST – wall-clock в секундах между моментом, когда плееру сказали воспроизводить (клик пользователя на Play или триггер автозапуска), и моментом, когда отрисован первый кадр запрошенного контента. CTA-2066 называет это Initial Buffer Length; индустрия использует VST. Большинство вендоров исключает pre-roll-рекламу из измерения – VST это content-VST, не ad-VST. Восприятие зрителя, конечно, включает оба; ad-VST получает отдельную строку на серьёзном дашборде, потому что медленная реклама теряет зрителя ещё до того, как контент попытается стартовать.

Почему это важно простыми цифрами: статья Кришнана и Ситарамана 2012 года Video Stream Quality Impacts Viewer Behavior, опубликованная на ACM Internet Measurement Conference на основе 23 млн сессий из CDN Akamai, установила эмпирическую кривую, по которой теперь планирует каждый оператор. Зритель терпит до двух секунд задержки старта. После этого отток растёт линейно – 5,8 процентных пункта на каждую дополнительную секунду: пятисекундный VST теряет около 17% зрителей до появления первого кадра; десятисекундный – около 45%.

Цели 2026 года, взятые из бенчмарков Conviva и Mux: веб ≤ 2,0 с p50 и ≤ 4,0 с p95; iOS native ≤ 1,5 с p50 и ≤ 3,0 с p95; Android native ≤ 2,0 с p50 и ≤ 4,0 с p95; CTV (Roku, Tizen, webOS, Vidaa, Fire TV, Android TV) ≤ 2,5 с p50 и ≤ 5,0 с p95. Live-потоки на 0,5–1,0 с медленнее VOD на любой платформе – из-за стоимости join-к-live-кромке. Дашборд, показывающий только среднее VST, прячет длинный хвост, где сидят 5% зрителей с худшим соединением; всегда выводите p50, p90 и p95 вместе – см. Ловушку №1 ниже.

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

4. Rebuffering Ratio

Rebuffering Ratio – доля общего wall-clock-времени воспроизведения, проведённого с пустым буфером, после отрисовки первого кадра. CTA-2066 называет событие Stall, длительность – Stall Duration, агрегированное отношение – Rebuffering Ratio. Операторам нужно выбрать одно из двух определений и держаться его. Первое – session ratio: общие секунды rebuffer в сессии, делённые на длительность сессии. Второе – viewer-level ratio: общие секунды rebuffer по всем сессиям, делённые на суммарное время воспроизведения, взвешенные по минутам просмотра. Session ratio даёт одинаковый вес пятисекундной сессии и пятичасовой; viewer-level ratio – пропорционально времени просмотра. На viewer-level ratio должен смотреть CFO – он прямо коррелирует с единственным числом, которое имеет значение: с минутами просмотра.

Арифметика: зритель смотрит 60-минутный эпизод, три rebuffer по 5 секунд – это 15 секунд stall на 3 600 с просмотра, session-level rebuffering ratio 0,42%. Умножьте на парк в 2 млн ежедневных часов просмотра – получите 504 часа stall в день, wall-clock двадцати финалов Лиги чемпионов, потерянных на спиннерах, каждые сутки. То же исследование, оплаченное Conviva, нашло, что один процентный пункт rebuffering ratio стоит около пяти процентных пунктов completion rate, – так что rebuffer-панель в денежном выражении самая дорогая на экране.

Цели 2026 года: здоровый VOD-сервис работает на ≤ 0,4% viewer-level rebuffering ratio; здоровый live – на ≤ 0,8% (live тяжелее, потому что буфер по дизайну мельче – пропуски пропускной способности негде спрятать). Выше 1,5% rebuffering ratio риск оттока измерим внутри одного биллингового цикла. Выше 3,0% у сервиса структурная проблема (под-провижированная CDN, слишком агрессивный ABR, сломанный LL-HLS, держащий буфер слишком тонким), которую не починит никакой полировкой дашборда.

Серьёзный дашборд также отслеживает rebuffering frequency отдельно от ratio. Один stall на 10 с и десять stall по 1 с имеют одинаковый ratio (10 с на ту же длительность), но разный эффект на зрителя: десять коротких stall гораздо раздражительнее, потому что каждый ломает внимание. Conviva называет это Connection-Induced Rebuffering Time vs Connection-Induced Rebuffering Frequency; отслеживайте и алертите по обоим.

5. Video Playback Failure (VPF)

VPF – процент сессий, которые завершились фатальной ошибкой после отрисовки первого кадра. Картинка пошла; что-то её убило до того, как зритель сам решил перестать смотреть. Распространённые причины: таймаут перевыпуска DRM-лицензии, сетевой handoff (Wi-Fi → LTE), который плеер не пережил, повреждённый сегмент с edge CDN, переключение манифеста HLS↔DASH, с которым плеер не справился, краш OS-уровневого кодека.

VPF – там, где большинство операторов открывает, что сервис, который хорошо стартует, может хорошо и упасть – и где дашборд делит популяцию по семейству устройств, версии ОС, версии приложения, CDN, типу контента и DRM-системе. 2% VPF, который оказывается 8% на Samsung Tizen 7 с PlayReady SL3000, – это одна строка в playbook; то же число, отчитанное как «2% VPF», прячет его. Хорошие отраслевые пороги: ≤ 0,5% веб, ≤ 0,3% мобильные, ≤ 1,0% CTV.

6. Качество картинки (перцептуальное)

Шестая и последняя базовая метрика – единственная, до которой глазам зрителя есть прямое дело: как хорошо выглядит картинка. Ответ 2010-х был «средний доставленный битрейт»; в 2020-х появился ответ «перцептуальный балл качества», потому что сервис может отдавать высокий битрейт плохо закодированного контента и проигрывать гонку качества сервису с более низким битрейтом чистого кодирования.

Де-факто индустриальный балл – с момента, когда Netflix открыл исходники в 2016 году, – это VMAF (Video Multimethod Assessment Fusion): метрика на машинном обучении, объединяющая пространственную детализацию, движение и контраст в балл 0–100, откалиброванный по субъективным рейтингам человеческих зрителей. VMAF ≥ 95 – «отлично, неотличимо от источника»; 85–95 – «хорошо»; 70–85 – «удовлетворительно»; ниже 70 – «заметно деградировано». Netflix, Disney+, Amazon Prime Video, YouTube и каждый крупный вендор кодеров теперь оптимизируют битрейтную лестницу против VMAF, не против битрейта, и конвенция дашборда 2026 года – отслеживать доставленный VMAF как заголовочное число качества картинки, с SSIM и PSNR как инженерной диагностикой.

Для live-потоков, где per-frame-вычисление VMAF слишком дорого, дашборды используют прокси: средний доставленный битрейт, нормализованный по разрешению – например, долю минут сессий, отданных в HD (≥ 720p) и 4K (≥ 2160p), и долю минут сессий на верхней ступени битрейтной лестницы. Прокси достаточно хорош, чтобы ловить аномалии content steering; для решений о самой лестнице оффлайн-проход VMAF на репрезентативной выборке заголовков остаётся золотым стандартом.

Агрегация: как считать, чтобы не врать

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

Ловушка 1 – среднее вместо перцентиля. Сервис со средним VST 2,1 с и p95 VST 9,7 с – это два сервиса, а не один. 5% зрителей с плохим соединением дают 30% оттока. Дашборды должны показывать p50, p90, p95 – а в идеале и p99 – для каждой латентностной метрики (VST, длительность rebuffer, время загрузки манифеста). Среднее – правильная сводная статистика для отношений (rebuffer ratio, VSF rate); неправильная – для латентностей. CTA-2066 § 8 фиксирует это правило, и каждый современный аналитический вендор ему следует.

Ловушка 2 – одинаковый вес сессий. Пятисекундная сессия и пятичасовая сессия с одним rebuffer не должны считаться одинаково. Взвешивайте агрегированные метрики по времени просмотра, когда вопрос «сколько минут просмотра пострадало», и по числу сессий, когда вопрос «сколько сессий провалилось».

Ловушка 3 – нестационарная агрегация через окно деплоя. Новую версию приложения, выкаченную во вторник 14:00, нельзя сравнивать с «вчера» предыдущей версии – это разные популяции. Режьте дашборд по версии приложения и временному окну, и явно держите производительность предыдущей версии как референсную линию хотя бы один полный недельный цикл после раскатки.

Ловушка 4 – EBVS как метрика вовлечённости. Высокий EBVS-Bounce – UX-проблема, не стриминговая. Слив EBVS-Bounce в общий failure rate с VSF будет красить дашборд красным в день, когда маркетинг добавит ещё одну автовоспроизводимую карусель.

Ловушка 5 – рекламный rebuffer, посчитанный как контентный. Server-side ad insertion (SSAI) врезает рекламу в таймлайн сегментов. Просадка буфера на рекламе раздует content-rebuffering ratio, если таймлайн сессии не исключает ad-промежутки. Схема CTA-2066 разделяет playback_state = ad и playback_state = content; держитесь этого разделения.

Композитные баллы: SPI от Conviva, VES от Mux, QoE Score от Bitmovin

Дашборд с шестью панелями честен, но большинство залов заседаний хотят одно число. Каждый крупный аналитический вендор теперь предлагает единый композитный балл по шкале 0–100.

Правильный способ использовать композитный балл – поставить его на исполнительный дашборд и никогда не ставить на инженерный. Композит прячет диагностику – 78 SPI может быть проблемой VST, или rebuffer, или VPF, и реагирующему инженеру нужно знать, какой именно. Всегда сопровождайте композит его составляющими; если вендор не умеет их раскрывать, ваш дашборд непрозрачен.

Где Фора Софт подключается

Фора Софт с 2009 года выпускает QoE-инструментированные плееры и дашборды в проектах видеоконференций, OTT, live-спорта, e-learning, телемедицины и видеонаблюдения – включая SDK-обвязку для эмиссии CMCD v2, сегментные аналитические конвейеры, питающие Mux Data, Conviva, Bitmovin Analytics, Datazoom и NPAW, и кастомные Grafana-дашборды, когда ни один готовый вендор не подходит под задачу. Мы регулярно диагностируем пять ловушек агрегации в боевом трафике, инструментируем CTV-приложения там, где готовый SDK не дотягивает, и пересобираем битрейтную лестницу против VMAF, когда сервис отдаёт высокий битрейт при низком перцептуальном качестве. Если у команды есть метрики, но они не превращаются в действие, – это наша задача.

CMCD v2: труба данных, питающая дашборд

Дашборд хорош ровно настолько, насколько хороши события, которые в него втекают. Отраслевой стандарт для этой трубы в 2026 году – CMCD v2, опубликованный как CTA-5004-A в апреле 2024 года проектом CTA WAVE и сейчас широко развернутый в hls.js, Shaka Player, dash.js, Video.js v10, Bitmovin Player и THEOplayer.

CMCD v1, опубликованный в 2020 году, определил небольшой набор полей плеера (длина буфера, запрошенный битрейт, измеренная пропускная способность, content ID, session ID), которые плеер прицеплял к каждому HTTP-запросу как query-параметр или заголовок – чтобы CDN могла логировать их вместе с запросом. Изначальный кейс был наблюдаемость на стороне CDN, не аналитика – операторы видели, почему был сделан конкретный запрос. CMCD v2 значительно расширяет модель: настоящие события состояния воспроизведения (start, buffering, seeking, paused, ended), стандартизированные коды ошибок плеера, и возможность отправлять данные не только в CDN, но и напрямую в сторонний аналитический endpoint через HTTP POST. Это последнее изменение замыкает цикл – плеер 2026 года может стримить события, которые хочет дашборд 2026 года, без какой-либо кастомной SDK-обвязки.

Импликация для дашборда мала, но важна: каждая метрика из ядра шести вычисляется из событий CMCD v2 без какого-либо специфичного для вендора SDK в плеере. Это не означает, что аналитические вендоры исчезают – они по-прежнему поставляют дашборды, алерты, сегментацию, хранилище, ML, – но это означает, что слой данных теперь интероперабелен, и оператор может мигрировать с одного аналитического вендора на другого, не переинструментируя каждый плеер. Это значимое изменение по сравнению со статусом до 2024 года, где вендор-лок начинался с SDK.

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

Сегментация: дашборд бесполезен без срезов

Одно агрегированное число – «VST p95 = 4,2 с» – это начало вопроса, не ответ. Вопрос всегда – для кого. Боевые дашборды сегментируют каждую метрику минимум по восьми осям, а серьёзный incident-response-плейбук ждёт, что каждый алерт сработает с тремя из них.

Комбинаторный взрыв реален: восемь осей с приведённой кардинальностью – это сотни миллионов возможных сегментов. Боевые дашборды не предвычисляют их все; они предвычисляют маржинальные rollup-ы (каждая метрика × каждая ось) и дают инженеру интерактивно нырять через два-три уровня во время инцидента. Бенчмарк интерактивной задержки в серьёзном дашборде 2026 года – менее трёх секунд от клика до результата.

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

Частая ошибка: «глобальные пороги»

Самый частый провал дашборда QoE, который мы видели, – это фиксированный глобальный порог: дашборд алертит, когда VST p95 превышает 4,0 с по всей популяции. Порог хорош для веба на оптоволокне; он плох для 4G в Индонезии, где 4,0 с p95 – локальный steady-state. Дашборд либо переалертит (on-call будит пейджер, потому что Индонезия работает в норме), либо ставит порог по индонезийской норме и никогда не сработает на регрессии на оптике.

Лечение – сегментированные пороги: каждый алерт определён против baseline той же категории устройства, того же региона и того же типа сети. Современные вендоры предлагают это нативно – «Auto-Detected Alerts» у Mux, «Smart Alerts» у Conviva, «Anomaly Detection» у Bitmovin – а самописный дашборд на Grafana может сделать это чуть более сложным запросом. Цена – сложность дашборда; выигрыш – пейджер, срабатывающий только когда что-то реально сломалось.

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

Целевые ориентиры 2026 года

Таблица ниже – стартовый лист целей, который наша команда использует для нового клиента. Откалибровано против опубликованных бенчмарков Conviva и Mux и наших собственных боевых данных из OTT- и live-проектов до мая 2026 года. Цели – p95-латентности и viewer-level-отношения, не средние.

Это стартовая точка, не закон. Правильные цели зависят от аудитории: премиум-спортивный оператор, гонящийся за четырёхсекундным live-бюджетом, ставит цели VST и rebuffer плотнее, чем длинно-хвостовая VOD-библиотека, а глобальный SVOD с разнообразной last-mile стратифицирует цели по регионам. Смысл таблицы не в конкретных числах, а в форме – шесть метрик, сегментированных, с p50 и p95 для латентностей, и композитом сверху.

Главные выводы

• QoE – это число про человека; QoS – про сеть. Стройте дашборд вокруг того, что чувствует зритель.
• Шесть метрик несут весь сигнал: VSF, EBVS, VST, Rebuffering Ratio, VPF и перцептуальное качество картинки.
• CTA-2066 даёт имена; CMCD v2 (CTA-5004-A) поставляет данные; современные вендоры рисуют дашборд.
• Показывайте p50, p90 и p95 для каждой латентностной метрики – среднее прячет длинный хвост, где живёт отток.
• Сегментируйте всё – по устройству, версии приложения, CDN, региону, типу контента, DRM, типу сети.
• Алертите на нижележащие метрики, не на композитный балл; композит – для исполнительного экрана.

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

• Аналитические платформы в сравнении: Mux Data, Conviva, Bitmovin Analytics, Datazoom, NPAW
• Incident response в стриминге: плейбук
• Наблюдаемость плеера и метрики, которые отгружаются в проде

Призыв к действию

Поговорите со стриминг-инженером – принесите образец вашего текущего дашборда или сырой экспорт аналитики, и мы пройдёмся по тому, где сидят шесть метрик, что неправильно агрегировано и какие сегменты прячут самый большой риск. Посмотрите наши кейсы – боевые OTT, live-спорт, телемедицина, e-learning с QoE-инструментированными плеерами. Скачайте «QoE KPI Definition Pack» – одностраничный справочник с определениями CTA-2066, целями 2026 года, картой полей CMCD v2 и семью ловушками агрегации.