Как определить потенциальный хит — опыт издательства AppQuantum

Тесты, метрики и отношения с командами разработчиков.

Руководительница отдела развития бизнеса мобильного издательства AppQuantum Виктория Беляева и старший менеджер по развитию бизнеса Егор Павлюк написали для DTF колонку, в которой рассказали, как компания подходит к выбору партнёров и как этот процесс менялся со временем: под влиянием перемен в индустрии, структурных сдвигов в компании и с ростом опыта команды.

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

Отбор проекта на паблишинг со стороны может показаться похожим на конвейер. Берёшь проект, пропускаешь через тест, смотришь на KPI: хорошие — берём, плохие — не берём. На самом деле, внутри скрывается приличное число нюансов.

За всё время существования издательства, мы попробовали применять разные варианты: смотрели на KPI и сравнивали с бенчмарками, отказались от этого и смотрели только на ROAS (показатель рентабельности рекламных расходов — ред.), снова возвращались к бенчмаркам и так далее.

В итоге, мы пришли к тому, что у нас нет единого стандарта для тестов. Правильнее будет сказать, что у нас есть определённый общий паттерн: интеграция конкретных SDK, а затем — тест на заранее выбранных GEO. А вот результаты мы анализируем всегда по-разному. Принимаем во внимание и стадию разработки, и актуальность проекта для рынка, и саму команду разработчика (насколько они готовы улучшать игру, насколько приятно и удобно с ними общаться и работать).

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

Поэтому, как бы мы ни старались, мы не сможем описать чёткий, красивый и единственно верный подход к тестам — всё индивидуально. Но мы постараемся рассказать о процессе принятия решений в AppQuantum, и показать путь, который проект проходит до подписания. Будет полезно и информативно, поехали!

Новые проекты, которые могут попасть на паблишинг, приходят к AppQuantum двумя основными путями: сами связываются с нами или их находят наши биздевы (в сторах, в специальных аналитических сервисах, в подборках; такие игры мы называем «холодными»).

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

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

Как только взаимоотношения издателя и разработчика юридически закреплены, начинается плавный перевод общения на продюсера, который будет заниматься проектом. На этом этапе создаются рабочие чаты, планируются еженедельные синки. Когда продюсер забирает всё общение на себя, биздев практически перестает заниматься проектом.

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

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

Поэтому ещё на самом раннем этапе отбора наши биздевы оценивают продукт и команду по нескольким критериям:

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

Если результат такого анализа показывает отсутствие жизнеспособности проекта на рынке, то часто тест вообще не производится. Биздев связывается с разработчиком и рассказывает, что не так с игрой, как её можно улучшить и стоит ли вообще это делать. Иногда силы, затраченные на доработку, будут равны по объёму тем, которые можно было бы потратить на создание нового продукта с учётом всех ошибок предыдущего. К этому нужно быть готовым заранее.

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

Важно также оценить и проконсультировать саму команду разработки. Понимают ли они объём доработок, который предстоит сделать? Потянут ли его текущими силами? Если нет, то какой минимально необходимый объём смогут сделать?

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

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

Таким образом, ещё до теста наши сотрудники погружаются в команду, проект, нишу. Для многих ниш и жанров у нас уже есть база знаний — результаты предыдущих тестов, анализ за разные периоды времени, разборы конкурентов.

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

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

Всю собранную информацию об игре и команде биздев передает коллегам, а те, в свою очередь, детальнее изучают продукт. Дальнейшее решение остается за продюсером. Даже когда сохраняется неуверенность в какой-то конкретной ситуации, мы можем дать «зелёный свет», если в компании есть человек, который верит в успех и готов вложиться в него своими силами и временем.

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

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

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

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

В нашем опыте есть хороший пример с игрой Idle Light City. Разработчики пришли к нам с метриками от другого издателя, которые были неудовлетворительными: CPI — слишком высокий, рекламные креативы смотрели плохо, проект не окупался.

Перед началом тестирования мы предложили разработчикам оптимизировать текущие рекламные размещения и добавить несколько новых. Проведённое тестирование показало отличные результаты: да, CPI не изменился, но зато рекламные показатели выросли и это вывело проект в окупаемость. Дальнейшая работа с оптимизацией рекламы, её размещениями, in-app монетизацией, грамотная закупка и поиск креативов позволили нам набрать 8 миллионов установок за 10 месяцев и в дальнейшем ещё долго и эффективно работать с этой игрой. Больше подробностей о работе с Idle Light City можно узнать из нашего кейса.

Наши тесты мы условно делим на три категории:

В идеале структура тестов для большинства проектов выглядит следующим образом.

Первым проводится retention-тест. Для него мы просим разработчика интегрировать SDK Facebook и Appsflyer с минимальным количеством ивентов. Пока разработчик интегрирует необходимые SDK, мы начинаем подготовку геймплейных креативов. Как только все интегрировано, а креативы — подготовлены, мы запускаем тест (об этом подробнее рассказано в статье о привлечении платного трафика). На нём мы смотрим продуктовые и маркетинговые метрики игры.

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

На этом этапе необходимо понять, заинтересовала ли игра пользователей. Для этого достаточно хотя бы одного из двух параметров — retention или среднее время игровой сессии. Если показатели достаточно высокие — интерес есть. Некоторым командам мы можем предложить совместную доработку игры и паблишинг уже на этом этапе, если мы уверены, что можем помочь разработчику развить продукт.

Если же у нас есть сомнения, или метрики не дотягивают до нужных, то мы можем предложить рекомендации и повторить retention-тест или сразу перейти к монетизационному.

Однако всегда есть «фактор продюсера» — все результаты тестов мы выкладываем в общий канал в рабочем мессенджере, а продюсеры их отсматривают. Несколько раз бывали ситуации, когда проекты с довольно низкими метриками брались в доработку, потому что сильно понравились продюсерам и они увидели там потенциал.

Кроме того, есть ещё и «фактор лапочки» — если команда очень хочет работать, готова вкладываться в игру и успела запасть биздеву, который её ведет, в самое сердечко, то бывает, что он сам «вытряхивает» из продюсеров и рекомендации, и фидбек, чем, в итоге, и помогает команде пройти отбор.

Самый главный вопрос, который задают все разработчики: «А на какие KPI вы ориентируетесь в тестах?». Те, кто дочитал статью до этого момента, скорее всего, уже сами понимают, что KPI для нас не являются строгим ориентиром. Но, при этом, не верно будет говорить, что мы вообще не смотрим на цифры. Бенчмарки по казуальным проектам у нас приняты такие:

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

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

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

ROAS-тест (или расширенный тест) проводится в нескольких случаях:

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

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

Такие тесты отличаются от других, в первую очередь, объёмами: мы запускаем большее количество разных рекламных кампаний, тестируем связки и оптимизации, перебираем разные подходы в креативах. Весь процесс может занять более месяца, но результат получается очень точный. Проект сразу оценивается «в бою», его подключают к нашей внутренней аналитике, оценивают так же, как и проекты в полноценном оперировании, поэтому условия максимально похожи на «боевые».

Например, так мы тестировали проект Idle Space Farmer, который к моменту прихода к AppQuantum уже вёл активную закупку трафика и привлёк несколько сотен тысяч пользователей. Разработчики упёрлись в потолок масштабирования. Наше тестирование показало, что на самом деле потенциал игры был гораздо выше, нужна была только грамотная стратегия и большое количество разных креативов.

Но бывают и обратные случаи: с одним из проектов тестирование показало, что наши результаты примерно такие же, как и результаты разработчиков, работа над продуктом дала лишь небольшой положительный эффект. В таком случае разработчику выгоднее выпускать свой продукт самостоятельно. Задача паблишера — добиваться таких результатов, которые даже при модели profit share (разделение прибыли), позволят разработчику зарабатывать с нами больше, чем без нашего участия.

Для большинства проектов этап тестирования обязательный. Но бывают и исключения. Так было, например, с Idle Evil Clicker. Когда мы познакомились со студией Red Machine, проект уже приносил деньги. Но мы увидели огромный потенциал в масштабировании со стороны маркетинга.

Мы пропустили стандартный этап тестирования и сразу перешли к подписанию, поскольку вопрос окупаемости проекта не стоял.

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

Но иногда даже с таким длинным этапом отбора могут случаться неудачи. У нас был кейс, когда проект высоко оценен всеми вовлечёнными специалистами, успешно прошел тестирование, но на масштабировании оказалось, что тест показал случайный успешный результат. К сожалению, его оказалось невозможно масштабировать и мы разошлись с разработчиками.

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

Первой игрой, на которой мы опробовали такой подход, стала Gold and Goblins. Мы увидели G&G на ранних стадиях разработки и было сложно оценить ее перспективность в плане окупаемости, поскольку на тот момент там не были реализованы многие важные механики.

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

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

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

Отбор потенциального хита — это долгий и сложный процесс. В эту работу вовлечены сотрудники многих отделов: биздевы, продюсеры, маркетинг, креативная команда, QA и release-менеджеры.

Каждая игра проходит многоступенчатый процесс отбора: оценивается её актуальность для рынка или ниши, соответствие современным трендам. Продукт разбирается на кирпичики и детально анализируется. Насколько интересен и понятен геймплей, насколько грамотно реализованы механики, монетизация, количество багов в проекте, уровень качества разработки.

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

Если вы верите, что у вас есть потенциальный хит, то можете показать его нам.

#опыт #мобайл #маркетинг