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