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

Для того, чтобы правильно оценить успешность или неуспешность теста, требовалось технологичное решение. Тут рассказывали о том, как мы перешли на ClickHouse (а также о его проблемах на январь 2018). Новая схема ETL позволила нам иметь хранилище, толерантное к дубликатам. При ошибке в коде мы всегда можем откатить consumer offset в kafka и обработать часть данных снова, не прилагая лишних усилий для движения данных. Хотим рассказать о том, как мы в IVI используем ClickHouse, чтобы посчитать метрики для решения разных продуктовых задач и понять, что мы действительно делаем продукт лучше, а не придумываем фичи, которыми никто не будет пользоваться.

О массивах и «махинациях» с монетизацией контента.

Сперва введем ряд обозначений, которые будем использовать. На IVI есть несколько моделей монетизации. AVOD – большой каталог бесплатных фильмов и сериалов, для просмотра которых придётся посмотреть рекламу. SVOD – контент по подписке, расширенный каталог без рекламы. TVOD/EST – контент, который доступен за отдельную плату и не входит в SVOD. EST – покупка навсегда, TVOD – аренда фильма, нужно начать просмотр в течение 30 дней, а закончить за 48 часов.  «Почему так дорого? У меня есть подписка, а я еще должен платить за отдельные фильмы? Ну совсем! Да этому фильму уже 20 лет, а я должен за него заплатить?! 600 рублей за аренду?!» - подобное я слышу от друзей, таксистов, врачей по ДМС, преподавателей в университете и даже от родителей. Давайте разбираться. 

Есть фильм, а есть правообладатель. Последний решает, в каком формате станут продавать контент. Заключается контракт, в котором описано, по какой модели будет доступен фильм, и если в контракте указано “Доступна только TVOD-модель” (как было, например, для онлайн-премьеры «Человека-невидимки» или «Эммы»), то условия должны быть выполнены. Но времена меняются, контракты перезаключаются, а контент, который был доступен только по модели TVOD/EST, может перетечь в подписку (т. е. в SVOD). И естественно, нельзя не поделиться этой информацией с пользователями. 

В результате изменения модели монетизации контента перед нами встает задача объяснить бизнесу, как влияет коммуникация о переходе контента из TVOD/EST в SVOD на выручку и отток. Любая коммуникация с пользователем – это ресурсы: человеко-часы, деньги на смс и прочее. Соответственно, нужно убедиться в том, что эти затраты оправданы (ведь экономика должна быть экономной). Мы стараемся проводить большинство коммуникаций в виде a/b-тестирования. Во-первых, чтобы убедиться в их полезности, а во-вторых, чтобы понимать, какие работают, а какие нет.  

Переформулируем задачу для себя: провести a/b-тест, связанный с коммуникацией о переходе контента в SVOD из TVOD/EST, чтобы оценить изменение метрик. Выберем для себя ряд показателей, которые будут ключевыми в принятии решения:

  1.     количество зашедших на карточку контента;

  2.     количество смотрящих;

  3.     количество оформивших подписку SVOD;

  4.     количество купивших TVOD/EST;

  5.     выручка SVOD;

  6.     выручка TVOD/EST;

  7.     конверсия в оформление подписки после захода на карточку контента;

  8.     конверсия в покупку TVOD/EST после захода на  карточку контента.

Для нас важна последовательность действий пользователя из тестовой группы: увидел коммуникацию -> заинтересовался предложением -> оформил подписку (или посмотрел перечисленные тайтлы). Как правило, эта последовательность отличается от «блуждания»: зашел на ivi -> погулял по карточкам контента -> посмотрел бесплатно -> погулял по карточкам контента -> купил подписку (контент) -> посмотрел контент.

У нас есть инструмент, который позволяет группировать события в массивы по признакам и по флагам в сессии (подробнее о массивах в ClickHouse тут).

У каждого массива в БД своя функция, например, массив, в котором хранятся a/b-тесты, массив с url ресурса, массив с событиями и их индексами в сессии и т.д. Вот маленькая шпаргалка, то, что необходимо понять перед составлением сложных «мозгодробильных» запросов:

arrayElement( – "Вытащить” в массиве элемент номер…

details.int_value, – В массиве таком-то

indexOf( – найти номер элемента в массиве

details.name, – В массиве таком-то

‘id' – элемента такого-то

) in (1,2)

Итак, возьмем запрос, с помощью которого мы считали метрики для данной задачи, и посмотрим на него внимательно. Идея следующая:

  • берем только необходимые события захода на карточку контента, просмотров и покупок;

  • джойним на покупки, чтобы посчитать выручку;

  • собираем в массивы с группировкой по пользователю и дате и с помощью функции arrayCumSum инкрементально размечаем события перехода на карточку контента;

  • разворачиваем массивы и снова – уже дополнительно – группируем по счетчику перехода на карточку контента для того, что получить цепочки, начинающиеся с захода на КК

  • создаем флаги наличия просмотра или покупки в рассматриваемых цепочках;

  • снова разворачиваем массивы для того, чтобы было удобно посчитать необходимые события с помощью агрегатных функций;

  • считаем события в необходимой агрегации.

Итого. Массивы и возможность взять узкий срез помогли нам корректно оценить результаты эксперимента. Кратко они звучат так: общайтесь с пользователями, им это нравится.

Когда массивы излишни

Давайте отдельно поговорим о кейсе, когда нет смысла использовать массивы.

На IVI есть классная фича «вход по коду» (см. видео). Если вы авторизованы через мобильное приложение, то все, что вам надо для авторизации на ТВ – ввести код с телефона в приложении IVI в своём Smart TV. Для пользователей, у которых нет чуда техники «magic mouse», это по-настоящему полезная штука.

Вход по коду
Вход по коду

Если мы хотим понять, сколько человек активно пользуется входом по коду, массивы нам не нужны, достаточно просто сделать count() по событиям. Джойны ClickHouse даются нелегко, как и некоторые сабселекты. Но в ряде кейсов сложные конструкции и не требуются, достаточно простого решения, ведь просто – не значит “неправильно”.

Задача: оценить, как часто люди используют флоу входа по коду на Smart TV. Это нужно, чтобы понять, достаточно ли мы уведомляем людей о новых фичах. Ведь важно не только иметь классный функционал, но и понимать, сколько человек о нём знают и пользуются. 

Так выглядит стандартная схема авторизации/регистрации на Smart TV:

 

Нужно проанализировать воронку: 

  1. количество пользователей, использующих «Вход по коду» ко всем авторизовавшимся; 

  2. количество пользователей, авторизованных по почте ко всем авторизовавшимся;

  3. количество пользователей, авторизованных по телефону ко всем авторизовавшимся. 

Так мы оценим, какой % людей использует функцию входа по коду. Делаем поправку на то, что в данном случае мы оцениваем только кросс-платформенных пользователей, которые проявляют активность и на Smart TV, и на телефоне. 

Использование массивов для решения задачи авторизации/регистрации – пустая трата времени. Достаточно проследить за тем, сколько людей и на каком шаге отваливаются. 

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

Пару слов о проблеме выбора

Если вы дочитали до этого места, то вот ещё кое-что интересное. 

Как лучше показывать акционные предложения на телевизоре? Не стоит множить кнопки на экране, ставя перед пользователем проблему выбора. Мы решили провести небольшой эксперимент, в рамках которого запустили продуктовую коммуникацию, разработав два дизайна одного и того же предложения. На варианте 1 есть только одна кликабельная кнопка, «ДА» (рис. 1). На варианте 2 кнопок две – «ДА» и «Не сегодня». Кроме того, в каждом варианте есть аппаратный «back» и крестик в правом верхнем углу, их тоже учитываем. Сделав обычный «select from» посчитали CTR (количество кликов на кнопку/количество показов экрана) и поняли, что лучшее, что есть в выборе – его отсутствие. Вариант 1 оказался заметно продуктивнее. 

P.S. Благодаря эксперименту мы также узнали о том, что «крестик» носит скорее эстетический характер, а большая часть пользователей предпочитает аппаратный «back»: в среднем 7 из 10 человек нажимают на « back» вместо того, чтобы навести «magic mouse» на Х.

Рис.1

Рис.2