Пример приложения для открытых телевизионных платформ
В статье описан пример приложения для открытых платформ интерактивного телевидения. Его главной функциональностью является формирование рекомендации на просмотр одного из доступных зрителю телеканалов. Подсказка должна быть выдана платформе на момент “включения телевизора” без каких-либо усилий зрителя – исключительно исходя из оценки его предпочтений, полученных при анализе предыдущего просмотра.
Авторами предпринята попытка показать, как можно повысить удобство и практичность приложения за счет учета специфики предметной области. Перечислены допущения, которые можно сделать при разработке приложений, исходя из отраслевого опыта и анализа практики телесмотрения.
Наконец, в качестве примера реализации подобного приложения предложен тривиальный алгоритм, который применим в первую очередь при отсутствии дополнительной информации как о пользователе, так и от телепрограммах.
I. Введение
Начиная с середины девяностых годов предпринимаются серьезные попытки кардинально изменить функциональность сет-топ боксов (изначально предназначенных прежде всего для доступа к телевещанию). Переход к интерактивному телевидению и использование приложений можно считать свершившимся фактом – по крайней мере, в рамках закрытых платформ. В течении последних двух лет предприняты попытки вывести на рынок открытые платформы –такие как MHP-OCAP или Android. Образцы подобных сет-топов были продемонстрированы в прошлом году на CES 2011 и других крупнейших отраслевых выставках.
Несмотря на значительную поддержку ведущих производителей hardware и software (Google, Motorola, Cisco, etc.), видимого прогресса в переходе на открытые платформы пока не наблюдается. Операторы демонстрируют сдержанный интерес, большинство зрителей не информированы об их преимуществах. В сравнении с активным переходом пользователей на мобильные устройства с открытыми платформами, опыты с подобными сет-топами за 2 года не продвинулись существенно далее полевого тестирования.
Среди первопричин подобного положения следует упомянуть отсутствие доступных приложений для открытых систем, которое лишает эти системы преимуществ в сравнении с уже имеющимися сейчас на рынке. В свою очередь, в отсутствии потенциальных пользователей разработчики также не стремятся адаптировать существующие приложения или разрабатывать новые. Ситуацию не меняет даже наличие проработанных рекомендаций (сформулированных, например, Google еще осенью 2010 года и активно демонстрируемых в рамках Google Developer Days осенью 2011 года).
В данной работе авторы предлагают краткое описание примера приложения для открытых систем, потребность в котором очевидна и которое может быть реализовано небольшой командой разработчиков. Особое внимание будет уделено особенностям практичности и удобства (usability) подобных приложений, базирующимся на понимании специфики предметной области. Под usability авторы подразумевают не только специфику пользовательского интерфейса (которая исчерпывающе описана в вышеупомянутых рекомендациях Google), но и учет более глубоких, неявных особенностей приложений для интерактивного ТВ – а именно, организации телевещания и опыта телесмотрения. Это позволяет по максимуму использовать информацию о действиях пользователя, полученную без прямого запроса к нему о предпочтениях.
II. Постановка задачи
Базируясь на известных маркетинговых установках, главной задачей обсуждаемого приложения должно стать формирование рекомендации на просмотр одного из доступных зрителю телеканалов. Рекомендация должна быть выдана платформе (и реализована ею) на момент “включения телевизора” без явных физических, зрительных или умственных усилий зрителя – исключительно исходя из оценки его предпочтений, полученных при анализе предыдущего просмотра.
Иными словами, пользователь должен нажать на кнопку “Включить” - и из всех транслирующихся на данный момент программ ему сразу должна быть выбрана та, которая наиболее соответствует его интересам (отметим отличие от подхода “любимого телеканала”, настройка на который происходит при включении телевизора по умолчанию). Приложение должно обходиться без дополнительных запросов о предпочтениях (которые зритель зачастую не может четко сформулировать), без показа сетки программ и т д. Весьма важно, чтобы выбор осуществлялся максимально быстро, без заметной зрителю задержки.
Таким образом, зритель не общается с приложением явным образом (хотя “фоновый” сбор информации о действиях зрителя и обеспечивает самонастройку приложения). В то же время крайне желательна возможность самостоятельной инсталляции и деинсталляции приложения, равно как и свободный выбор зрителем одного из подобных решений в случае, если речь идет об отрытых платформах (разные алгоритмы обеспечивают разную эффективность подсказки).
В качестве дополнительной функциональности следует отметить постоянное наличие подобной рекомендации к просмотру (то есть зритель может смотреть одну программу и получать подсказки переключиться на другой канал, если по нему идет более интересная программа).
Можно ожидать, что данное приложение интересно не только зрителю, но и телевещателю. Широко известна отраслевая тенденция к повышению эффективности рекламы путем ее персонализации . Очевидно, что направление пользователя на тот канал, который ему более интересен, является и его направлением к более интересной телерекламе.
Перед тем, как приступить к описанию предлагаемого решения данной задачи, остановимся на самой общей постановке задачи навигации по контенту, доступному на сет-топе (под навигацией понимается и формирование персональных рекомендаций для конкретного зрителя). Отчасти это это необходимо для понимания тех упрощений, которые будут сделаны авторами в дальнейшем. Кроме того, для западных операторов комплексный подход становится стандартным. Для российского рынка он также может быть реализован в недалеком будущем (пока же – в силу технических ограничений, о которых будет сказано ниже, - и задача, и алгоритмы для ее решения значитетельно проще).
III. Навигация по контенту – комплексный подход
Несмотря на известный консерватизм телевизионной отрасли (в сравнении, допустим, с мобильной телефонией), ее развитие принципиально невозможно в существующих рамках. Во-первых, большинство населения Северной Америки, Европы, стран пост-советского пространства получает доступ как минимум к нескольким десяткам каналов. Во-вторых, на угрозу потери аудитории за счет ее "перетекания" в интернет игроки ТВ рынка (операторы, разработчики технических решений, владельцы контента и прочие) реагируют путем обеспечения доступа зрителя как к телевизионным сервисам, так и к интернету. Последние годы на рынке предлагаются решения, обеспечивающие либо полный, либо контролируемый оператором доступ к интернет-контенту (например, посредством специализированного приложения). В ряде случаев телезритель получает браузер практически с той же функциональностью, которую он имеет на компьютере. При реализации же приложений, ориентированных на определенный интернет-ресурс, зритель имеет более удобный интерфейс (адаптированный к большому экрану, устройству ввода и т.п.) при естественном ограничении доступа к контенту.
Таким образом, конвергеция телевидения и интернета оборачивается для телезрителя наличием “в телевизоре” десятков и даже сотен телевизионных каналов, множества приложений и, возможно, неограниченного доступа к интернет-ресурсам. Все это создает проблему поиска и выбора, аналогичную той, с которой пользователи компьютера массово столкнулись два десятилетия тому назад. Поэтому ведущие производители software для закрытых и открытых платформ с 2010 года предлагают приложения, кардинально изменяющие принципы навигации по контенту, доступному на связке сеттоп -телевизор. Вместо сетки вещания телеканалов известной как EPG (Electronic Program Guide) и каталогов доступного контента зрителю предлагается поисковик. Следует упомянуть Google TV - представление о его функциональности можно получить при просмотре примеров на сайте google.com/tv/. Подобные решения для закрытых платформ также демонстрировались на различных выставках.
Анализ решений на базе поисковиков, демонстрируемых на выставках CSTB, показывает, что результаты поиска могут быть улучшены (с точки зрения интересов пользователя) и управляемы (с точки зрения интересов операторов, рекламодателей, etc.), для чего используется:
а) информация о профиле и предпочтениях пользователя, явно им сообщенная или ставшая известной оператору при его регистрации (возраст, пол, локация, состав семьи, интересы) б) анализ лога просмотра (включая канал, описание программы и ее аттрибуты из EPG, время начала просмотра и его длительность) и прочих действий зрителя - например, использования специализированных приложений или запрошенных интернет-ресурсов (необходимо отметить, что в силу организационных причин подобное логирование и анализ не всегда допустимы)
в) информация о контактах в социальных сетях и рекомендации его контактов (явные или сформированные в результате анализа предпочтений контактов)
г) предположения о препочтениях на базе анализа опыта телесмотрения (например, утром можно ожидать запрос на более короткие программы или музыкальные отрывки, etc.)
д) предположения на базе информации об устройстве воспроизведения контента (как правило, более качественного; или - при наличии выбора -варианта, более адаптированного под телевизор).
е) так называемый collective knowledge, подразумевающий, синергитеческое использование вышеупомянутой информации, собранной для всех зрителей одного оператора (например, отслеживание действий и выработка рекомендаций для группы пользователей, описываемых схожим профилем).
Подобные решения могут включать в себя и элементы самообучения системы (анализ выбора пользователя при предыдущих обращениях к поисковику). Очевидно, что при этом обеспечивается интерактивный режим работы приложения и обмен данными между сет-топом и серверной частью на стороне оператора. Подразумевается наличие в EPG большого количества информации о каждой программе (зачастую, кроме детального описания ее содержания вещатель классифицирует ее по десяткам параметров – от жанра и года выпуска до режиссера и списка ведущих актеров).
Реализация решений возможна на базе достаточно мощных алгоритмов [1], обеспечивающих высокую вероятность совпадения результатов поиски и потребностей зрителя, - однако это требует весьма значительных трудозатрат.
В то же время существует значительная потребность и в более простых решениях для навигации только по телеконтенту, которые могут быть реализованы небольшим командами разработчиков, и в то же время могут обеспечить достаточную эффективность подсказок пользователю.
IV. Технические ограничения
Необходимость реализовывать очень простые алгоритмы отчасти продиктована техническими ограничениями (для российских операторов они перечислены ниже), а отчасти простым соображением, что эффективность подсказки выбора телепрограммы не связана явной, линейной зависимостью с эффективностью содержащейся в ней рекламы (в этом авторы видят отличие от выбора подобных алгоритмов для интернет-торговли, где повышение эффективности подсказки на 2-3 процента приводит к однозначному прогнозируемому увеличению доходов). С другой стороны, если имплементация сложного алгоритма, дающего идеальные подсказки, будет занимать несколько секунд, то она вступит в противоречие с основными требованиями usability - рекомендация будет либо раздражать пользователя, либо вообще окажется ему не нужна (конечно, подобную задачу можно и нужно решать в фоновом режиме, но все равно в реальных условиях ресурсы сет-топа, выделяемые приложению, весьма ограничены).
Итак, реальные (как правило, весьма скромные) ресурсы сет-топов (размер памяти, вычислительная мощность), доступные приложению, являются первым техническим ограничением. Для “слабых” сет-топов характерно и отсутствие возможности записывать программы (что лишает дополнительной косвенной информации о предпочтениях пользователя; решение записывать телепрограмму можно трактовать как явное подтверждение интереса пользователя к подобному телеконтенту).
Во-вторых, в ряде случаев обращение к серверу также невозможно (до сих пор есть большое количество сеттопов без обратной связи), что исключает реализацию collective knowledge алгоритмов и прочих решений на базе взаимодействия с сервером. Опять же, это лишает косвенной информации о предпочтениях пользователя (запрос на покупку телеконтента в режиме VOD –Video on Demand - также можно трактовать как явное подтверждение интереса пользователя к подобным телепрограммам).
В-третьих, в ряде стран передача лога действий пользователя нежелательна по организационно-законодательным причинам (например, в США).
В-четвертых, в российской практике описание программ в EPG либо отсутствует, либо минимально.
В-пятых, информация о профиле пользователя зачастую недоступна (и в случае отсутствия обратной связи ее не получить).
В-шестых, на один и тот же сет-топ может приходиться несколько пользователей (семья), и идентификация зрителя (персональный вход), как правило, не поддерживается.
Поэтому рассматриваемый вариант можно описать следующим образом:
а) сеттоп накапливает информацию о действиях пользователя в следующем формате - начало просмотра, длительность просмотра, канал, программа и ее описание - аттрибуты (в общем случае – просто массив качественных и количественных параметров; набор аттрибутов может быть разным). Отметим, что одним из самых распространненых случаев является наличие только информации о начале и длительности просмотра и соответствующем канале;
б) имеют место все вышеприведенные ограничения; нет информации о профиле пользователя, егопредпочтениях или действиях кроме просмотра телеканалов – записях или покупках видеоконтента, запуске приложений и т.п.;
в) опционально наличествует список программ для EPG на текущий момент и на несколько дней вперед (в том же формат - канал, программа, ее временные границы и аттрибуты).
V. Явные и неявные допущения
Безусловно, в таких условиях эффективно решить поставленную задачу крайне сложно. Однако мы можем сделать некоторые весьма мощные предположения, базирующиеся на понимании специфики телевещания и опыта телесмотрения. Перечислим наиболее важные из них:
1) Подавляющее большинство телеканалов придерживается достаточно строгого регулярного программирования сетки вещания. Иными словами, сериалы, новости, специальные программы идут в одно и то же время и повторяются ежедневно либо еженедельно (отметим, что в общем случае в России составляется отдельное расписание для вещания в рабочие дни, пятницу, субботу и воскресенье, для многих стран более характерна привязка к каждому недели; таким образом, в общем случае недельный график можно считать регулярно повторяющимся);
2) Вероятность показа схожей программы тем выше, чем ближе ко времени предыдущий просмотр (если зритель смотрит сериал, то новый эпизод сериала можно ожидать на следующий день либо через неделю; с увеличением промежутка времени между просмотрами данная корреляция ослабевает – сериал или спортивное мероприятие оканчивается, etc.) Вообще, телевизионный сезон можно считать максимально возможным размером “базы данных” просмотренных зрителем передач;
3) Длительность просмотра телепрограммы можно использовать в качестве как количественной оценки предпочтений пользователя, так и качественной оценки эффективности рекомендации (например, если пользователь переключился на другой канал в течении 1-ой минуты, мы можем считать рекомендацию неудачной, а программу несоответствующей предпочтениям пользователя);
4) Невозможность получения информации о профиле пользователя и отсутствие идентификации зрителя частично компенсируется данными о времени начала просмотра – можно предположить, что при совместном пользовании сет-топа и телевизора в одно и то же время определенного дня недели ими пользуется одни и те же зрители. Подобные предположения позволяют сформулировать подход, который авторы считают тривиальным, и в то же время весьма эффективным. Основные его положения описаны ниже, однако ряд практических рекомендаций (в частности, способ калибрации весовых коэффициентов) по ряду причин оставлен за пределами данной публикации.
VI. Тривиальный алгоритм формирования подсказки
Итак, в течении определенного времени сет-топ накапливает информацию о просмотре пользователем определенных программ (ожидается, что база данных поддерживается вне описываемого приложения – например, платформой либо отдельным приложением). По предварительным оценкам, получение нескольких сотен записей возможно в течении менее чем месяца (статистика американских операторов показывает, что среднее время просмотра программы не превышает 5 минут – с учетом переключений, который пользователь делает при предварительном выборе; в то же время ежедневно средний зритель и в России, и на Западе тратит несколько часов на просмотр телеканалов).
В момент “включения телевизора“ (допустим, 18 часов 53 минуты) сет-топ производит нижеприведенные вычисления (в действительности, сет-топ, как правило, при отключении переходит в спящий режим, что позволяет производить вычисления в фоновом режиме, об этом так же будет сказано ниже).
Во-первых, выясняется, какие каналы зритель смотрел в данный момент времени в предыдущие дни (для определенности возьмем период в квартал) и какова была длительность просмотра соответствующих программ. Допустим, вчера в это же время зритель смотрел 11-ый канал, и в целом он смотрел соответствущую передачу в течении получаса. Позавчера телевизор был выключен. Неделю назад пользователь смотрел 15-ый канал, и время просмотра программы было менее й минуты – и так далее.
Вторым шагом каждой из программ, которые пользователь смотрел в такое же время последнии 90 дней, ставится в соответствие рейтинг передачи - некоторое число от 0 до 1 в зависимости от длительности просмотра (рекомендуется существенно нелинейная зависимость, допустим, 0,001 для программ с длительностью просмотра менее минуты, 0,01 для программ с длительностью просмотра от минуты до 5 минут, 0,1 – при просмотре от 5 до 15 минут, и 1 – при просмотре от получаса). Отметим, что в случае наличия EPG и информации о времени начала и завершения передачи в соответствии с сеткой вещания, необходимо учитывать и тот факт, досмотрел ли зритель программу до конца либо переключился на другой канал.
В-третьих, каждому из полученных чисел ставится в соответствие весовой коэффициент от 0 до 1, зависящий от того, сколько дней отделяет момент просмотра от текущего момента. Например, для программ, просмотренных вчера и неделю назад, этот коэффициент равен 1, для программ, просмотренных три месяца назад – 0,1.
Следующим шагом рейтинги передач перемножаются на весовой коэффициент, и результаты, соответствующие одинаковым каналам, складываются – таким образом получаем рейтинги каналов, соответствующие данному конкретному моменту времени (18-53). Очевидно, что в другой момент времени значения рейтингов могут существенно отличаться. Добавим, что каналам, которые вообще не имеют полученных по такой процедуре рейтингов, рекомендуется назначить их весьма близкими к нулю, но все же превышающими нулевое значение.
Наконец, на последнем шаге случайным образом (с вероятностью, пропорциональной полученному рейтингу канала) выбирается канал, на который и переключается платформа.
Комбинация второго и третьего шагов автоматически обеспечивает постоянную перенастройку алгоритма (иными словами, если наша подсказка неудачна и пользователь сразу же переключится на другой канал, то рейтинг предложенного канала автоматически значительно упадет).
Конечно, данный тривиальный алгоритм формально “привязан” к каналам, а не конкретным передачам, и может эффективно работать только в рамках вышеперечисленных допущений. Они показывают, какой канал предпочитает смотреть пользователь в определенное время. Однако в действительности эти допущения (например, корреляция выбираемого канала и жанра программы) позволяют предположить, какого типа передачи пользователь хочет смотреть в определенный момент времени. Это позволяет ожидать сравнительно высокую эффективность подсказки при отсутствии детального описания передач в EPG. Очевидно, что при наличии дополнительных данных о программах алгоритм должен быть усовершенствован. Безусловно, что могут быть введены и более серьезные действия для обучения алгоритма на основе анализа успешности или неуспешности подсказки (если пользователь достаточно долго оставался на предложенном канале, то подсказка считается удачной, если ушел – неудачной). Возможность использовать алгоритмы различной сложности (либо отдельные элементы алгоритмов – например, обучение алгоритма) подразумевает хорошо продуманную модульную архитектуру данного приложения.
Отметим и такую особенность реализации, что даже при столь тривиальном алгоритме вычисления могут занять более десятой доли секунды (что можно считать максимально допустимым с точки зрения usability). Вероятно, для текущего промежутка времени вычисления рекомендованного канала могут быть произведены “спящим” сет-топом в фоновом режиме и мгновенно переданы платформе при его “включении”. Возможно и постоянное вычисление подобной рекомендации для следующего временного промежутка во “включенном” режиме, что позволит обеспечивать пользователя рекомендацией переключиться на, возможно, более интересную программу.
Презентация на конференции будет включать рассказ об имплементации для Android и результатах ее тестирования на сет-топе с данной платформой.
VII. Выводы
В статье описан один из примеров приложения для открытых платформ интерактивного телевидения. Самостоятельные команды разработчиков могут предложить конечному пользователю разнообразные имплементации одной и той же востребованной функциональности, и пользователь решает, нужна ли ему такая функциональность вообще, какой вариант он находит более удобным и эффективным, и готов ли он за это платить.
Авторами предпринята попытка показать, как можно повысить usability приложения за счет учета специфики предметной области, сводя к минимуму действия и усилия пользователя. Перечислены допущения, которые можно сделать при разработке приложений, исходя из отраслевого опыта и анализа практики телесмотрения.
Наконец, в качестве примера реализации подобного приложения предложен тривиальный алгоритм, которые применим в первую очередь при отсутствии дополнительной информации как о пользователе, так и от телепрограммах. Кроме того, он не требует значительных ресурсов и может быть реализован на сет-топе без обратной связи (то есть на самых простых, дешевых и массовых сет-топах).
В целом опыт разработки подобного приложения может оказаться весьма важным для последующего перехода к созданию различных коммерческих проектов для платформ цифрового телевижения [2].
Авторы:
* Дмитрий Вавилов, Руководитель отдела разработки ПО ООО ЛегалСофт
* Кирилл Костюшкин, Генеральный директор ООО АДАКТА
* Иван Платонов, Студент СПбГТУ Политех
Литература:
[1] XindongWu, Vipin Kumar, J. Ross Quinlan, Joydeep Ghosh, Qiang Yang, Hiroshi Motoda, Geoffrey J. McLachlan, Angus Ng, Bing Liu, Philip S. Yu, Zhi-Hua Zhou, Michael Steinbach, David J. Hand, Dan Steinberg, “Top 10 algorithms in data mining, SURVEY PAPER”, Published online: 4 December 2007, Springer-Verlag London Limited 2007
[2] Dmitry Vavilov, Larisa Melikhova, Alexey Logunov, “Perspectives of Digital TV applications development in Russia”, SECR 2009, Moscow, October 28-29, 2009.