Делюсь опытом разработки аналитики для стриминговых площадок с нуля, рассказываю о том, что из этого получилось и какие предварительные выводы я из этого сделал.
Я так себе писатель, но рассказать хочется. Может это кого-то на что-то мотивирует. Так что прошу понять и простить, если что не так.
Очень коротко о себе
Мой путь в IT начался с разработки мобильных игр на Unity, чем занимаюсь и по сей день. После устроился на работу в мобильный паблишинг, где проработал два года успешно развиваясь как Ad Monetization Manager (AMM) с сильным упором в аналитику и чуть менее сильным в разработку сопутствующих решений позволяющих упростить работу или повысить эффективность монетизации. Доработал до условного хеда (ближе к лиду, так как много хедить не было необходимости — уж слишком я все оптимизировал), после чего ушел в свободное плавание — делать игры, разрабатывать сервисы.
Я не очень хороший разработчик, не лучший в мире аналитик и уж точно не “самый умный в классе”. Но я дружу с логикой, умею искать информацию и очень широко смотрю на многие вещи. А в силу того, что я успел в своей жизни повидать некоторое дерьмо, с такой чудной “комбинацией” у меня получается видеть то, что не видят специалисты с многолетним опытом работы, так как не только туда не смотрят, а просто не знают, что голова в ту сторону крутится.
С чего все началось
Мне предложили поработать над проектом аналитики для потенциального продюсерского агентства стримеров. Задумка выглядела интересно и, в теории, перспективно. Моей основной задачей было обеспечить аналитикой потенциальных продюсеров для помощи им в развитии стримеров.
Проект по аналитике стриминговых платформ я начал со знаниями C# на уровне “сделать приемлемую игру не прося помощи” и средними знаниями SQL. Так что в статье не будет технических подробностей, кода и всего того, за что я не могу поручиться в плане качества. Да и статья не об этом.
Что нужно было получить?
Необходимо было создать аналитическую платформу, которая позволит понять:
1. Что в целом происходит с каналом стримера.
2. Где искать точки роста и как они влияют на канал и аудиторию.
3. Как ведет себя аудитория в разных ситуациях, как ведет себя в целом и что на это влияет.
4. Ответить на вопросы рекламодателей об эффективности и качестве их кампаний на канале.
Сначала был Twitch
Не имея изначально ни знаний, ни опыта — нужно было с чего-то начать.
В первую очередь необходимо было заложить основу для будущей аналитической платформы — это сбор и хранение данных. Я понятия не имел, какой сервер для этого нужен, поэтому взял самый дешевый 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 рекламный слот и мало денег.
Если такие сервисы есть — это хорошо, так как все для их зарождения уже несколько лет как появилось. Но я о них не слышал (и не особо слушал, если честно).
Возможности поработать над оценкой РК у меня так и не появилось, хотя я минимально обеспечил возможность оценить ее качество.
Trovo, goodgame, WASD
Многие стримеры, в последнее время, рассматривают возможность перехода на какую-то альтернативную платформу. Соответственно одной из задач было оценить пригодность этих платформ для аналитики.
Мне удалось поковырять API Trovo и GG.
Из них, на бумаге, только Trovo позволяет сделать приемлемую аналитику с использованием API. Но на деле оно работает очень медленно и не в соответствии с документацией, что делает эту платформу непригодной для анализа. Наверное поэтому для них нет хорошей аналитики, а рекламодатели, судя по отзывам Мэддисона, не спешат с ними работать. Фиксится нажатием примерно 7 кнопок, но их не жмут.
GG — API хуже чем у Trovo, но обмазавшись с ног до головы костылями и кучей ресурсов — можно получить аналитику того же уровня, что и на Twitch.
WASD я не трогал, но судя по докам и сайту, ситуация +- такая же, как и у GG — много костылей.
При наличии необходимого, любая платформа подключается максимум за час, так как сервис писался по принципу розетки — главное, чтобы вилка в штепсель воткнулась.
Небольшой итог
Примерно за 5 месяцев, с нуля, без большей части необходимых знаний была сделана аналитическая платформа аналогов которой пока нет, или я их не нашел. К финалу разработки общий месячный бюджет аналитической платформы был примерно 1200р/м. Планов было еще очень много — метрики донатов, подписок, кастомные эвенты и тд. и тп. но сбыться им не суждено.
Работать над ней было супер интересно, такого объема понимания процессов я давно не получал в такой короткий срок.
Куча откровений, которые могли бы помочь в работе как разработчика игр, так и работе AMM. Открыто просто море возможностей, о которых аналитики/разработчики знают, но молчат. Я предполагаю, что они просто не хотят это потом делать 🙂
Я не скажу, что за это время я сильно вырос как программист или аналитик, но понимание процессов и их тонкостей дало ощутимый буст для поиска новых возможностей в разных сферах, о которых раньше даже подумать было нельзя.
Сейчас проект успешно закопан, а я двигаюсь дальше.
