Аналитика стриминговых площадок Twitch, Trovo, GoodGame, WASD

Делюсь опытом разработки аналитики для стриминговых площадок с нуля, рассказываю о том, что из этого получилось и какие предварительные выводы я из этого сделал.

Я так себе писатель, но рассказать хочется. Может это кого-то на что-то мотивирует. Так что прошу понять и простить, если что не так.

Мой путь в IT начался с разработки мобильных игр на Unity, чем занимаюсь и по сей день. После устроился на работу в мобильный паблишинг, где проработал два года успешно развиваясь как Ad Monetization Manager (AMM) с сильным упором в аналитику и чуть менее сильным в разработку сопутствующих решений позволяющих упростить работу или повысить эффективность монетизации. Доработал до условного хеда (ближе к лиду, так как много хедить не было необходимости - уж слишком я все оптимизировал), после чего ушел в свободное плавание - делать игры, разрабатывать сервисы.

Я не очень хороший разработчик, не лучший в мире аналитик и уж точно не “самый умный в классе”. Но я дружу с логикой, умею искать информацию и очень широко смотрю на многие вещи. А в силу того, что я успел в своей жизни повидать некоторое дерьмо, с такой чудной “комбинацией” у меня получается видеть то, что не видят специалисты с многолетним опытом работы, так как не только туда не смотрят, а просто не знают, что голова в ту сторону крутится.

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

Проект по аналитике стриминговых платформ я начал со знаниями C# на уровне “сделать приемлемую игру не прося помощи” и средними знаниями SQL. Так что в статье не будет технических подробностей, кода и всего того, за что я не могу поручиться в плане качества. Да и статья не об этом.

Что нужно было получить?

Необходимо было создать аналитическую платформу, которая позволит понять:

1. Что в целом происходит с каналом стримера.

2. Где искать точки роста и как они влияют на канал и аудиторию.

3. Как ведет себя аудитория в разных ситуациях, как ведет себя в целом и что на это влияет.

4. Ответить на вопросы рекламодателей об эффективности и качестве их кампаний на канале.

Не имея изначально ни знаний, ни опыта - нужно было с чего-то начать.

В первую очередь необходимо было заложить основу для будущей аналитической платформы - это сбор и хранение данных. Я понятия не имел, какой сервер для этого нужен, поэтому взял самый дешевый VPS за 300р с возможностью повысить мощности в пару кликов в случае необходимости.

Для хранения был выбран Clickhouse, так как с ним я уже работал на уровне пользователя БД. Поставить его на сервер по гайдам было несложно.

Сбор данных оказался самым тяжелым этапом на котором методика сбора и структура хранения менялись по несколько раз в день. А для того, чтобы не терять данные - приходилось реструктурировать имеющиеся данные и записывать заново. Все обработчики собранных данных были на питоне и работали очень медленно, в связи с моей неопытностью на этом языке.

К концу первых двух недель я был просто закопан в куче легаси кода из сборщиков, обработчиков и анализаторов.

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

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

Суть была проста. В бота отправляется запрос с данными по необходимому стримеру или стриму, далее на сервере обрабатывается запрос, в зависимости от него генерируется график/таблица/любая другая информация, и отправляется обратно в телеграм. На тот момент это был лучший вариант в плане скорости разработки и качества. До закрытия проекта этот бот потом использовался для управления сервером и получением алертов с логами.

Так прошла еще неделя в поисках решения и наиболее оптимального варианта. Параллельно также улучшалась аналитика и появлялись новые таблицы и графики.

Было решено в первую очередь сосредоточится на том, что не обеспечивают другие аналитические платформы. А также мониторить чат, что могло быть полезным для потенциальных рекламодателей при отслеживании упоминания бренда/товара.

Спустя еще неделю выглядело это примерно так.

На графике удобно отслеживать основное движение аудитории. Очень четко видно влияние одних стримеров на других

Полезная таблица. Позволяет понять качество аудитории у стримера. Например, для рекламодателей стример с большим процентом аудитории <5 минут будет менее интересен чем тот, у кого аудитория распределена ближе к центру. Чем дольше смотрят - тем выше шанс конверта.

Благодаря простой системе определения принадлежности зрителя - позволяет понять распределение текущей аудитории стримера, относительно других стримеров.

С этого момента появилось понятие “свой зритель” - зритель, который преимущественно смотрит этого стримера.

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

На них четко виден приход и уход аудитории, а главное - сразу понятно, чья она.

Похожий функционал, но в другом виде.

Так же, благодаря более сложным вычислениям, пришлось повышать мощности сервера и теперь его стоимость ~500р/м

Объем информации для анализа был достаточный, поэтому дальше я решил сделать кое-что потяжелее. То, куда аналитики твича не поворачивали головы - я решил добавить Retention.

Спустя несколько дней оптимизаций реструктуризации базы - он был готов.

Были и другие его вариации, в том числе и нормализованные.

Очень полезная в нужных руках метрика, кто знает - тот поймет.

После retention захотелось сделать предикт по аудитории, но стримеры не самые стабильные ребята и от этого пришлось отказаться.

И тут настал момент, когда я уперся в качество. Графикам не хватало интерактивности, а разглядывание мелкого шрифта и попытки понять, к кому какой цвет относятся стали вызывать все больше раздражения.

В этот момент морально я уже был готов к тому, чтобы приступить к сайту. Под сайт был взят отдельный сервер, самый дешевый - ~300р. Больше, как оказалось, и не нужно.

И вот я, без знаний и понимания, как это вообще работает приступил к сбору информации.

Все сильно упростило то, что не было задачи “делать для всех”. Нужно было сделать удобно и функционально. Спустя пару дней сбора был выбран django, бесплатный шаблон дашборда работающий на apexcharts и еще некоторые мелочи.

Гайда “Как сделать аналитический дашборд для стриминговых платформ с вот такими графиками на основе такого-то шаблона” я в интернете не нашел (кто бы сомневался). Так же мне не очень хотелось тратить кучи времени на изучение основ JS, HTML,CSS, чтобы понять, как это вообще работает.

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

В итоге, где-то через 20 дней у меня была готова первая, рабочая версия дашборда. Туда были перенесены все основные графики. Была авторизация, доступы, API, и две страницы с необходимыми полями и графиками.

Больше всего времени я потратил на то, чтобы разобраться с apexсharts, так как он упорно отказывался визуализировать таблицу так, как мне нужно. (Ох уж этот log scale)

Но в целом - это был прорыв. Теперь все щупается и трогается. В любом графике можно отключать лишнее, и концентрироваться на нужном. Все интерактивно и понятно. Даже на смартфоне это +- хорошо работало.

Спустя еще примерно неделю были перенесены все таблицы, отслеживание Retention было увеличено до 28 дней, была оптимизирована БД, повышена частота сбора данных и я наконец научился нормально использовать API.

Проект в стадии “Из говна и палок”, постепенно начал приобретать приличный вид и уже был похож на “просто из палок”. С одним но. Я опять уперся в мощности сервера. Так как мне не очень хотелось увеличивать бюджет - я погрузился в оптимизацию.

Спустя еще какое-то время мне удалось полностью переработать структуру базы данных и сервер за 500р вполне неплохо жил с базой в миллиард строк. Появилось много промежуточных таблиц, но зато сервер почти не нагружался и дашборд стал работать ощутимо быстрее.

Наконец появилась страница стримера с еженедельным отчетом и новыми метриками.

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

Попутно улучшая алгоритмы сбора и хранения данных, спустя еще какое-то время я вывел еще часть планируемых метрик.

И тут началось самое интересное. После получения всех возможных на текущих мощностях метрик и без особого желания увеличивать бюджет, я начал изучать то, на сколько мои метрики соответствуют другим платформам и как еще их можно применять.

В этом разделе я пойду по о***но тонкому льду предположений, догадок и не только. Не судите строго, если я где-то заблуждаюсь.

Самая важная метрика стримера для любого рекламодателя, из доступных не по факту - это просмотры. И вот с ними есть определенные сложности, так как сама формулировка просмотр - очень расплывчатая и нигде ее не регламентируют.

Это приводит к разногласиям, кто их правильнее считает.

Когда я только начинал этот проект - основным ориентиром для меня был twitchtracker и я часто сверялся с ним на предмет достоверности. Потом я увидел более интересные варианты, но они также не обеспечивали необходимыми данными, хоть их и было больше + за них уже надо было платить.

На данный момент я примерно понимаю логику того, как twitchtracker считает просмотры, так как смог стабильно получать +- то же самое. (не буду описывать логику) И я не сказал бы, что они выдают честные просмотры.

Показатель twitchtracker по просмотрам занижен, относительно того, что дает твич где-то в 2-3 раза. Я не видел всех кейсов, но на тех что видел - это так. И если я не ошибся с логикой подсчета, то из-за своей примитивности twitchtrecker выгоден рекламодателям, но невыгоден стримерам, так как ощутимо занижает показы относительно более авторитетной платформы (twitch) у которой есть возможность считать их честно.

Но. Я не говорю, что логика подсчета просмотров twitch верная или что они считают их честно. Мне не хватило мощностей проверить справедливые просмотры, так как сервер за 500р к такому не приспособлен, но я склоняюсь больше к варианту с twitch, хотя и считаю, что справедливая реальность где-то между, так как предполагаемая логика подсчета от twitchtrecker очень грубая.

Вся эта суматоха приводит к тому, что twitch не обеспечивает потребности стримеров и рекламодателей в справедливой оценке просмотров, но хотя бы обеспечивает необходимыми данными для их самостоятельного получения.

Когда я копнул чуть глубже (Совсем малость. Не имею представления, как это работает сейчас, но понимаю, как оно должно быть) - я понял, что проблема не в просмотрах, а в самой сути того, как крутится реклама на твич и как она анализируется.

Просмотры, в зависимости от того, что считать за просмотр, скачут от х0.2 до х3 относительно twitchtracker - это очень шаткий показатель на который нельзя полагаться в принципе. В отличие от мобильной рекламы, он тут играет роль очень далекого ориентира, так как нет жесткого регламента, что это. (В мобилках есть жесткая привязка к эвенту)

Логичный вывод тут один - прокладка в виде сервиса, которая будет лежать между стримером и рекламодателем, которая обеспечит справедливую оценку РК как для стримера, так и для рекламодателя.

Суть сервиса максимально проста - обеспечить справедливую жесткую привязку стриминговых метрик, к метрикам рекламодателя.

По идее, этим должна заниматься сама стриминговая платформа, так как у нее для этого есть все, что нужно. Но у twitch, наверное, не хватает на это денег или они просто не хотят монетизироваться и зарабатывать миллионы/арды $, обеспечив качественный, удобный, а главное справедливый сервис для рекламодателей.

Без такого сервиса есть несколько условных вариантов, известных мне. (само собой есть еще, но я о них не знаю. Напоминаю - лед все еще тонкий)

CPM по twitch - Выгодно стримеру, невыгодно рекламодателю.

CPM по twitchtracker и тд. - Нормально рекламодателю, не очень стримеру.

CPC, CPA - очень выгодно рекламодателю, очень невыгодно стримеру.

Если по первым двум понятно, то по последнему - все очень плохо. Тут стример теряет по всем фронтам, и в основном по вине рекламодателя, так как любая ошибка с его стороны может сломать вообще все. Пример - Рекламодатель не позаботился о таргете и предложил стримеру с аудиторией одной страны, рекламировать услуги в другой, из которой его не смотрят. Итог - низкие показатели, а у стримера -1 рекламный слот и мало денег.

Если такие сервисы есть - это хорошо, так как все для их зарождения уже несколько лет как появилось. Но я о них не слышал (и не особо слушал, если честно).

Возможности поработать над оценкой РК у меня так и не появилось, хотя я минимально обеспечил возможность оценить ее качество.

Многие стримеры, в последнее время, рассматривают возможность перехода на какую-то альтернативную платформу. Соответственно одной из задач было оценить пригодность этих платформ для аналитики.

Мне удалось поковырять API Trovo и GG.

Из них, на бумаге, только Trovo позволяет сделать приемлемую аналитику с использованием API. Но на деле оно работает очень медленно и не в соответствии с документацией, что делает эту платформу непригодной для анализа. Наверное поэтому для них нет хорошей аналитики, а рекламодатели, судя по отзывам Мэддисона, не спешат с ними работать. Фиксится нажатием примерно 7 кнопок, но их не жмут.

GG - API хуже чем у Trovo, но обмазавшись с ног до головы костылями и кучей ресурсов - можно получить аналитику того же уровня, что и на Twitch.

WASD я не трогал, но судя по докам и сайту, ситуация +- такая же, как и у GG - много костылей.

При наличии необходимого, любая платформа подключается максимум за час, так как сервис писался по принципу розетки - главное, чтобы вилка в штепсель воткнулась.

Примерно за 5 месяцев, с нуля, без большей части необходимых знаний была сделана аналитическая платформа аналогов которой пока нет, или я их не нашел. К финалу разработки общий месячный бюджет аналитической платформы был примерно 1200р/м. Планов было еще очень много - метрики донатов, подписок, кастомные эвенты и тд. и тп. но сбыться им не суждено.

Работать над ней было супер интересно, такого объема понимания процессов я давно не получал в такой короткий срок.

Куча откровений, которые могли бы помочь в работе как разработчика игр, так и работе AMM. Открыто просто море возможностей, о которых аналитики/разработчики знают, но молчат. Я предполагаю, что они просто не хотят это потом делать :)

Я не скажу, что за это время я сильно вырос как программист или аналитик, но понимание процессов и их тонкостей дало ощутимый буст для поиска новых возможностей в разных сферах, о которых раньше даже подумать было нельзя.

Сейчас проект успешно закопан, а я двигаюсь дальше.