Метрики просмотра в OTT: плеи, время просмотра, конкурентность

TL;DR

Числа аудитории и вовлечённости на OTT-платформе – той, что доставляет видео через интернет, а не через кабельную приставку – выглядят простыми, но это самые числа в отрасли, которыми проще всего обмануть самого себя, ведь каждое из них – это определённое событие, а не самоочевидный факт. «Плей» – это плей, только если вы решили, что считается минимумом; watch time – это не то же самое, какую долю видео досмотрели; completion rate прячет, дошли ли зрители до конца или вышли на заставке; а единственная метрика, что реально задаёт размер инфраструктуры – concurrency, число людей, смотрящих в один момент – та самая, что дневные итоги вам никогда не покажут. Эта статья точно определяет каждую метрику просмотра, проходит арифметику, которая превращает пик concurrency в счёт за полосу, под который надо провижиниться, и называет ловушки подсчёта – autoplay-превью, окно возобновления, аккаунты, принятые за зрителей, и трафик ботов – из-за которых наивные числа врут. Сделайте эти определения верно – и у всей вашей аналитики будет фундамент; сделайте неверно – и каждая панель над ними унаследует ошибку.

Зачем это нужно

Если вы управляете OTT-платформой или планируете её, метрики просмотра – это числа, что вы назовёте борду, рекламодателям и контент-партнёрам, и числа, по которым они будут с вас спрашивать. Опасность в том, что заголовочные цифры тривиально легко завысить и так же легко прочитать неправильно: платформа может честно отчитаться «десять миллионов плеев в месяц», хотя большая доля этих плеев – двухсекундные autoplay-превью, которые никто не выбирал смотреть. Эта статья для нетехнического оператора, которому нужно определить плей, уникального зрителя, completion rate и число concurrency так, чтобы они выдержали проверку, и которому нужно знать, какая из этих метрик задаёт инженерный счёт. Она лежит под картой аналитики OTT, которая раскладывает три семьи метрик; здесь мы уходим вглубь чисел аудитории и вовлечённости внутри первых двух семей.

Одна идея: каждое число просмотра – это определение, которое вы выбираете

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

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

Атом: что считается «плеем» (просмотром)?

Наименьшая единица просмотра – это один случай, когда зритель начинает кусок контента. Разные команды зовут его плеем (play) или просмотром (view); они имеют в виду один атом. Всё остальное – watch time, completion, даже некоторые числа аудитории – строится агрегацией плеев, так что, если плей определён вольно, каждое число над ним наследует эту вольность.

Первое решение – когда плей засчитывается. Чистейшее инженерное определение приходит от вендоров аналитики, что инструментируют плеер напрямую. Mux, например, определяет view как «попытку (успешную или нет) воспроизвести видео», созданную в момент, когда зритель жмёт play или воспроизведение запускается программно – так что плей, который загрузился и затем упал, всё равно считается одним view, ведь меряется намерение смотреть. Тот же view затем отслеживается, пока воспроизведение явно не завершено или пока не пройдёт шестьдесят минут после остановки, а пауза и возобновление внутри этого окна остаются одним view, а не разбиваются на два. Это разумный дефолт, но заметьте: это всё равно выбор – шестидесятиминутное окно возобновления это правило, и другое правило дало бы другие числа из идентичного поведения зрителя.

Рекламный мир проводит черту иначе и строже, ведь на ней меняются деньги. Digital Video Impression Measurement Guidelines от Interactive Advertising Bureau (IAB, v1.1) требуют, чтобы показ видеорекламы засчитывался client-initiated и только когда реклама начинает рендериться – когда первый кадр реально начинает рисоваться на экране зрителя – явно не когда буфер лишь инициирован. Гайдлайны отвергают server-initiated подсчёт, ведь он дальше всего от того, чтобы зритель что-либо увидел. Урок для оператора платформы: «видео начало загружаться» и «зритель увидел первый кадр» – два разных события, и достоверное определение плея считает второе, не первое.

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

Порог засчёта и «правило 30 секунд»

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

Конвенции актуальны на 2026; правила платформ меняются – датируйте любую цифру, что приводите. Вопрос «supported?» здесь – «считает ли это правило autoplay-превью за просмотр?» – ответ показывает, насколько раздутым может быть число.

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

Частая ошибка: позволить autoplay раздуть «плеи»

Вот самая дорогая ошибка просмотра, и она почти всегда честная, а не нечестная. Допустим, ваш домашний экран показывает двадцать autoplay-превью-плиток за визит, и вы получаете 100 000 визитов в день. Если счётчик «плеев» срабатывает на каждом стартующем превью, это 20 × 100 000 = 2 000 000 «плеев» в день ещё до того, как кто-либо выбрал что-то смотреть. Если число плеев, где зритель реально выбрал тайтл и посмотрел дольше реального порога, скажем, 300 000, то ваша заголовочная цифра «плеев» завышает настоящий просмотр почти в 6,7×. Назовите раздутое число рекламодателю или контент-партнёру – и у вас проблема с доверием в первый же раз, когда они проведут аудит. Лечение не в том, чтобы выключить autoplay; оно в том, чтобы считать засчитанные плеи отдельно от стартов превью и никогда их не смешивать.

Watch time – это не «какую долю видео досмотрели»

Следующая метрика вверх – watch time: суммарное время, что зрители провели за просмотром. Это сырое топливо бизнеса – оно питает рекламный инвентарь в моделях с рекламой и это ключ использования, по которому многие платформы распределяют выручку на отдельные тайтлы. Но оно несёт тонкость, что подводит почти каждого в первый раз.

Watch time меряет прошедшее время воспроизведения, не объём досмотренного контента. Чистейшая иллюстрация снова приходит из определений Mux: если зритель смотрит двухминутное видео на скорости 2×, watch time равен одной минуте, ведь watch time считает, сколько настенного времени прошло за воспроизведением, не сколько хронометража контента было покрыто. И наоборот, watch time – как его определяют некоторые вендоры – включает секунды на ребуферинг, перемотку и старт – время, что зритель провёл в ожидании, не за удовольствием. Mux проводит это различие явно: watch time включает ребуферинг и перемотку, тогда как playing time – более строгая метрика, что считает только время, когда контент реально играл, исключая ребуферинг, перемотку и паузы. Рабочий пример из их документации: 90 секунд игры, 4 секунды ребуферинга, 2 секунды перемотки, затем ещё 60 секунд игры дают 156 секунд watch time (90 + 4 + 2 + 60), хотя меньшая их часть была чистым воспроизведением.

Для оператора это важно двояко. Во-первых, когда вы называете «средний watch time», скажите, включает ли он буферизацию – два определения могут отличаться на несколько процентов на плохо работающей платформе, и разница это ровно та проблема QoE, что вы иначе спрятали бы. Во-вторых, watch time и completion – разные вопросы: большой watch time на коротком видео может значить, что зритель пересмотрел его; малый watch time на длинном фильме всё равно может быть счастливым зрителем, что досмотрел клип. Держите метрику времени и метрику прогресса раздельно.

Completion rate: дошли ли они до конца?

Completion rate отвечает на вопрос прогресса напрямую: какую долю куска контента зрители реально досмотрели? Это яснейший сигнал того, оправдал ли контент своё обещание – трейлер, что теряет 80% зрителей в первые десять секунд, и документалка, что 70% начавших смотрят до титров, говорят вам очень разное о вашем каталоге.

У отрасли уже есть точный, стандартизованный способ мерить прогресс, и он приходит из рекламного стека: Video Ad Serving Template (VAST) от IAB определяет события отслеживания квартилей, что срабатывают, когда воспроизведение пересекает фиксированные вехи прогресса – start, firstQuartile (25% просмотрено), midpoint (50%), thirdQuartile (75%) и complete (100%). Эти события были придуманы, чтобы рекламный сервер мог проверить, как далеко была досмотрена реклама, но та же модель квартилей – верный ментальный инструмент и для completion контента: вместо единого «completion rate» отслеживайте долю зрителей, что доживают до каждого квартиля, ведь форма этой кривой оттока говорит вам, где ваш контент теряет людей. Тайтл, где большая часть потери происходит между start и firstQuartile, имеет проблему с началом; тот, где зрители утекают на thirdQuartile, может быть просто слишком длинным.

Ловушка с completion rate та же, что преследует watch time и любое среднее: единое среднее число completion прячет распределение. «Среднее completion 55%» может описывать и здоровый тайтл, где большинство досматривает, а немногие пробуют и уходят, и сломанный, где половина аудитории уходит в первую минуту, а лояльный остаток досматривает – две совершенно разные проблемы контента с одним заголовочным числом. Читайте completion кривой квартилей и когортами, никогда одним средним.

Concurrency: метрика аудитории, что задаёт инженерию

Важнейшая метрика просмотра, что вы никогда не увидите на панели дневных итогов – concurrency – число зрителей, смотрящих в один и тот же миг. Дневные плеи и месячные уникальные зрители описывают размер аудитории во времени; concurrency описывает нагрузку на вашу систему прямо сейчас, и это число, под которое размерён каждый кусок вашей инфраструктуры доставки. Это также метрика, что сильнее всего отличает стриминг почти от любого другого веб-продукта, ведь live-событие может разогнать concurrency до многих кратных от дневного среднего за считаные минуты.

Здесь аналитика просмотра встречает инфраструктурный счёт, так что пройдём арифметику вслух. Допустим, live-финал по спорту на вашей платформе даёт пик 200 000 одновременных зрителей, а ваше адаптивное кодирование отдаёт в среднем 5 мегабит в секунду (Mbps) на зрителя в этот момент. Совокупная полоса, что вы должны уметь толкать на пике:

200 000 зрителей × 5 Mbps = 1 000 000 Mbps = 1 000 гигабит в секунду (Gbps) ≈ 1 терабит в секунду (Tbps).

Эта цифра в один терабит в секунду – пик concurrency × битрейт на зрителя – и есть то, под что вы провижините мощность доставки контента, не под удобное дневное среднее. Платформа, что планировала под «два миллиона плеев сегодня» и проигнорировала всплеск 200 000 разом, упадёт ровно тогда, когда смотрят больше всего людей. Инженерию этого всплеска – мощность multi-CDN, защиту origin и плавную деградацию – мы разбираем вглубь в масштабировании и concurrency для OTT; для аналитики смысл в том, что concurrency – метрика аудитории, что заодно служит вашим важнейшим числом планирования мощности, и следить надо за пиком concurrency, не средним.

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

Уникальные зрители: перестаньте считать аккаунты за людей

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

Честная метрика аудитории – уникальные зрители: разные люди или профили, что реально смотрели в заданный период, без дублей по устройствам. Определение Mux снова чистый ориентир – уникальные зрители считаются по стабильному Viewer ID, и один зритель считается один раз, даже когда смотрит с нескольких экранов одновременно. Разрыв между аккаунтами и активными уникальными зрителями сам по себе сигнал здоровья: платформа с миллионом подписчиков, но двумястами тысячами месячных уникальных зрителей имеет проблему удержания, спрятанную за здоровым числом подписчиков – ровно тот тип проблемы, что призвана выявлять аналитика удержания и вовлечённости.

Для моделей с рекламой есть четвёртая метрика подсчёта людей – охват (reach) – число уникальных зрителей, кого реклама или тайтл реально коснулись, и здесь стандарты измерения становятся строгими, ведь кросс-медийные сравнения от них зависят. Cross-Media Audience Measurement Standards от Media Rating Council требуют для дедуплицированного кросс-медийного охвата порога видимости в 100% пикселей на экране минимум 2 непрерывные секунды, применённого и к цифровому, и к линейно-телевизионному компоненту, чтобы число «охвата» значило одно и то же, пришло ли оно из приложения connected TV или из эфирного сигнала. Вам не нужно внедрять этот стандарт, чтобы держать подписочный сервис, но если вы продаёте рекламу против своего охвата, ваши покупатели будут мерить вас по нему.

Держим числа честными: боты и невалидный трафик

Ещё одна ловушка подсчёта заслуживает своего имени, ведь она может тихо испортить каждую метрику выше: невалидный трафик – плеи, просмотры и показы, сгенерированные чем-то, кроме реального человека, выбравшего смотреть. Рекламная отрасль это формализовала. Invalid Traffic (IVT) Detection and Filtration Guidelines от Media Rating Council делят его на два уровня: General Invalid Traffic (GIVT), рутинный, опознаваемый по спискам вид – известные боты, спайдеры, краулеры и трафик дата-центров; и Sophisticated Invalid Traffic (SIVT), более сложный вид, что требует продвинутой аналитики для поимки – угнанные устройства, фальсифицированные измерения и просмотры, движимые малварью. Платформа, что не фильтрует хотя бы GIVT из своих чисел просмотра, отчитывается о смеси людей и машин и зовёт это аудиторией. Вам не нужна аккредитация MRC, чтобы начать; вам нужно знать, что какая-то доля сырых плеев – никогда не человек, и отфильтровать очевидных ботов до того, как назвать число кому-либо, кто важен.

Откуда берутся числа

Метрики просмотра собираются из двух источников, и понимание, что есть что, держит вас честными насчёт их надёжности. Сигналы аудитории и вовлечённости – кто записался, кто платит, кто нажал play и как надолго – приходят из ваших прикладных и биллинговых систем в сочетании с событиями плеера: маленькими сообщениями, что плеер испускает, когда плей стартует, проходит свои квартили, ставится на паузу, возобновляется и останавливается. Concurrency вычисляется подсчётом активных в один момент хартбитов плеера. Построение этого инструментирования чисто – чтобы «плей» срабатывал один раз и значил одно и то же на web, mobile и TV – это тема инструментирования QoE на стороне плеера, а события квартилей VAST выше испускаются тем же слоем плеера, когда задействована реклама, что покрыто в ad serving, VAST/VMAP и рекламном стеке. Правило надёжности простое: метрика надёжна ровно настолько, насколько надёжно единое, согласованное событие, что её питает.

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

Слой просмотра должен быть верным и держаться на масштабе live-премьеры – миллионы событий плеев в день и сотни тысяч одновременных хартбитов во время всплеска, превращённые в числа, что оператор сможет защитить перед рекламодателем. Фора Софт строит видеостриминг и OTT/Internet TV платформы с 2005 года, по 250+ проектам для 400+ клиентов, включая инструментирование плеера и пайплайны событий, что определяют «плей», «уникального зрителя» и число concurrency один раз и применяют их согласованно на web-, mobile- и smart-TV-клиентах. Мы проектируем определения метрик вместе с вами – порог засчёта, окно возобновления, модель квартилей, фильтр ботов – чтобы числа были честными ещё до того, как достигнут панели, и размеряем доставку под пик concurrency, а не под удобные средние. Мы вендоро-нейтральны: инструментируем на платформе измерения вроде Mux или Conviva либо на открытой телеметрии – что подходит вашему масштабу и бюджету.

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

• Каждое число просмотра – правило подсчёта, что вы выбираете; публикуйте определение рядом с числом.
• «Плей» считается на первом кадре и после порога засчёта – никогда на старте буфера или autoplay.
• Watch time – прошедшее время воспроизведения, не объём контента; может включать ребуферинг, так что укажите.
• Completion – кривая квартилей (25/50/75/100%), не одно среднее, что прячет, где зрители ушли.
• Concurrency × битрейт на зрителя задаёт счёт за полосу; провижиньтесь под пик, не под дневное среднее.
• Считайте уникальных зрителей, не аккаунты, и фильтруйте ботов (GIVT) до того, как назвать число аудитории.

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

• Карта аналитики OTT: аудитория, вовлечённость, качество – как просмотр ложится в три семьи метрик.
• Quality of experience (QoE): startup time и ребуферинг – числа качества, что движут вовлечённостью выше.
• Масштабирование и concurrency: от 1 000 до 1 000 000 зрителей – инженерия всплеска пика concurrency.