Руководство it territory

IT Territory (известна также как «АйТи Территория» и «Территория ИТ») — российская компания, занимающаяся разработкой и изданием онлайновых многопользовательских игр (MMORPG, BBMMORPG) и игр формата casual games, а в последнее время и mobile games. Основана в 2004 году, главный офис компании находится в Москве. С 2007 года по 2010 входила в состав холдинга Astrum Online Entertainment^[1]. С 2010 года входит в холдинг Mail.ru Group Ltd^[2].

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

Для дистрибуции casual игр компания IT Territory использует как собственные площадки, так и партнерские площадки с крупными сайтами и порталами Интернета.

С момента своего появления IT Territory занимается, в основном браузерными играми, однако в 2007 году в структуре компании открыл отдел разработки клиентских MMO, а также подписаны контракты на издание ряда зарубежных клиентских MMO, среди которых «Властелин Колец Онлайн», «Пара Па: Город Танцев» и «Монато. Мир Снов», «Поднебесье» (впоследствии закрыто)

Игры компании[править]

Список многопользовательских онлайновых игр, которые оперирует IT Territory:

• Ground War: Tanks
• Кодекс пирата
• Фрагория

Список мобильных игр, которые оперирует IT Territory:

• Эволюция: Битва за Утопию
• Jungle Heat
• Juggernaut Wars
• Iron Desert — Fire Storm
• Jungle Clash
• Juggernaut Champions
• HAWK: Freedom Squadron
• Эволюция: Герои Утопии
• Эволюция: Битва за Утопию 2

Награды[править]

Игры компании были отмечены наградами «Выбор Редакции» платформ App Store и Google Play

• Эволюция: Битва за Утопию

Игра вошла в список «Лучшие игры 2014 года» по версии Google Play^[3] и «Выбор Редакции» App Store^[4]

• Juggernaut Wars

Игра вошла в список «Лучшие игры 2016 года» по версии App Store.^[5]

Источники[править]

Ссылки[править]

• http://it-territory.ru/  — официальный сайт компании IT Territory
• Профайл компании на DTF
• astrumonline.ru — сайт холдинга Astrum Online Entertainment] (сайт закрыт)
• Мобильная игра IT-Territory Juggernaut Wars

Игры IT Territory [+]
Разработчик:	Легенда: Наследие Драконов • Герои: Возрождение • Троецарствие • Территория • ‘ • BloodyWorld • Бильярдный клуб • Love City • Десант: Рейдеры Мериона • Faor • Жуки@Mail.ru • Драйв@Mail.ru • Территория футбола
Локализатор и издатель:	Властелин Колец Онлайн • Пара Па: Город Танцев • Монато. Мир снов • Silkroad Online • Last Chaos • Поднебесье • Pandora Saga • Flyff

Продуктовая аналитика в студии полного цикла

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

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

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

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

1. Кто такой продуктовый аналитик?

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

1.1. Подход к аналитике

Мы считаем, что у нас в студии применяется системный подход к аналитике.

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

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

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

1.2. Основные задачи

Основные задачи аналитика в нашем отделе:

• Анализ изменений KPI по мере развития продукта.
• Обнаружение и изучение аномалий.
• Поиск «узких мест» и точек роста. Это очень важная задача, которая позволяет человеку развиваться профессионально. Он сам ставит перед собой гипотезы, проверяет их, находит новую информацию, которую больше никто не видит, и таким образом получает опыт, который не даст ни один руководитель.
• Поддержка принятия решений. Мы помогаем членам команды отвечать на стоящие перед ними вопросы.
• Поддержка и развитие аналитической инфраструктуры.

О последнем пункте я расскажу подробнее. Инфраструктура состоит из следующих уровней:

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

На втором уровне у нас хранилище на базе Hadoop, куда мы из БД проектов переносим информацию для исторического анализа очень больших объёмов.

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

На последнем уровне у нас визуализация. За нее исторически отвечает проприетарное программное обеспечение — QlikView. А Excel — это классика, для быстрых задач мы всегда его используем.

1.3. Компетенции продуктового аналитика

Мы выделяем такой список:

• SQL и подобные языки;
• архитектура баз данных;
• языки программирования (Python, R, Scala);
• математика и математическая статистика;
• логика и продуктовое мышление;
• умение защищать свою позицию;
• коммуникативные навыки.

Я хочу подчеркнуть два последних пункта. Принято считать, что аналитик — это интроверт с IQ выше 130, который готовит 50-страничные отчёты о том, что происходит в его сфере ответственности. Но на самом деле в нашей парадигме аналитик — это тот человек, который является драйвером обнаруживаемых им проблем и точек роста. В коллективе сложно убедить людей в том, что ты нашёл что-то важное, потому что каждый занимается своей приоритетной задачей. А просто передать эту информацию и забыть о ней — такая позиция нам не подходит. Поэтому для аналитика очень важно уметь строить отношения в коллективе, находить способы защитить свою позицию и свои выводы, «драйвить» реализацию своих рекомендаций.

2. Методики

Теперь немного расскажу о примерах методик, которые мы транслируем сотрудникам отдела аналитики. На наш взгляд, три кита успешного free-to-play продукта — экономика, удержание и монетизация. Для каждой из этих сущностей в отделе аналитики разрабатываются методики для оценки и сравнения с другими проектами. Их можно разделить на три большие группы:

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

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

2.1. Методики первичной оценки

Примеры методик первичной оценки:

• Retention;
• CARPU (LTV) по ключевым рынкам;
• FPE (конверсия в платящих);
• конверсия фиксированного старта (туториала);
• точки прогресса, вызывающие уход;
• точки прогресса, стимулирующие платежи;
• приток и отток ресурсов в разрезе прогресса и/или времени жизни;
• WinRate первых попыток + количество попыток до успешного прохождения.

Расскажу чуть подробнее о нескольких из них.

2.1.1. Экономика первых дней жизни

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

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

2.1.2 Конверсия прогресса

Одним из важнейших аспектов для игры является первичное удержание. В первые минуты после установки люди знакомятся с игрой и принимают решение, будут они в это играть или нет. Большинство проектов теряет половину аудитории в первые 30 минут. Как можно быстро найти проблемы в удержании аудитории? В привязке к прогрессу, мы делаем это с помощью классической воронки:

Строим график количества пользователей, которые достигают определённых ключевых точек. На графике ярко выражены спады в точках 4, 10 и 20. Если вычислить относительную конверсию от точки к точке, будут сразу видны провалы, в которых конверсия резко падает относительно соседних точек. Причины бывают разные: проблемы в UX, проблема выбора между разными режимами, когда пользователи идут не по вашей стратегии, а идут в PvP или другие режимы, сложность, технические сбои и т.д. Но в целом, это те точки, на которые следует сразу обратить внимание, поскольку они провоцируют пользователей либо уйти, либо действовать не по выбранной вами кривой прогресса.

2.1.3 Точки ухода и платежей

Вот пример проекта, в котором эти точки очень сильно выражены:

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

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

2.1.4. Важные вопросы монетизации

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

Какой товар лучше всего конвертирует пользователя в платящего? У нас был проект, который очень хорошо «выстрелил» на старте. Но буквально через несколько месяцев после получения featuring’ов, после переваривания достаточно большого объёма аудитории проект по выручке начал падать, и достаточно серьёзно. У него было неплохое удержание для midcore-проекта, а игровой процесс был достаточно трудный. Нам не хватало платящей массы, чтобы проект вышел на финансовое плато за счёт платежей ядра аудитории.

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

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

Какая доля пользователей конвертируется в платящих на поздних этапах игры? Если у вас после 30-го дня жизни появляется много новых платящих, то, скорее всего, вы недополучаете деньги. Эти люди играли месяц, уже выполнили краткосрочные и среднесрочные цели. Но при этом у них не было достаточной мотивации, чтобы начать платить. А на поздних этапах она внезапно появилась. Напомню, что если пользователь конвертируется поздно, то его удельная выручка будет снижаться по сравнению с ситуацией, если бы он конвертировался в первые дни жизни проекта. Поэтому необходимо найти мотивацию для игроков конвертироваться в платящих на раннем этапе.

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

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

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

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

2.2. Оценка изменения продукта

Теперь поговорим о методиках оценки изменений в продукте. Это:

• [Все методики первичной оценки] +
• метрики потоковой монетизации: DPU, ARPPU, ARPDAU;
• поминутный Rolling Retention;
• приток и отток ресурсов в динамике;
• Churn Rate;
• средняя длительность пребывания в приложении;
• динамика ключевых активностей;
• баланс ресурсов на руках.

Остановлюсь подробнее на некоторых методиках.

2.2.1. Поминутный Rolling Retention

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

Логарифмическая кривая, всё понятно: чем дольше игрок пробыл в игре, тем меньше вероятность ухода. Второй проект тоже здоровый, но результат немного лучше. После часа игры у нас остается больше пользователей. А затем мы внесли во второй проект изменения, которые что-то сломали — график изменился.

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

2.2.2. Churn rate, или уровень оттока

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

Обычно мы анализируем отток по уровням, возрасту, статусу платящего. Резкий рост метрики говорит о том, что вероятность ухода игроков этого сегмента выросла, и нужно искать причины. Если Churn Rate стабильно повышен после заметного обновления — имеет смысл бить тревогу.

2.2.3. Приток и отток ресурсов

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

Жёлтая линия — расходы, чёрная — бесплатный доход. Между ними большая разница, доход ниже расходов. Дельта — это дефицит, формирующий спрос на наши продаваемые ресурсы. Я встречал несколько проектов, в которых ситуация была абсолютно противоположная: они монетизируются только за счёт крупных платящих пользователей. В общем плане, если у вас удельные расходы по монетизируемому ресурсу превышают удельный бесплатный доход, то это здоровая дефицитная экономика.

3. Советы

3.1. Сглаживание для оценки долгосрочных трендов

Допустим, мы с вами следим за каким-то важным параметром. Например, LTV (накопительный ARPU) на отрезке 30 дней для новой аудитории. С ним сложно работать. Он очень чувствителен к крупным плательщикам, имеет высокую дисперсию, поэтому его график для последовательных когорт в динамике будет выглядеть совершенно не репрезентативно. Мы можем разбить этот параметр по месяцам или группам, но это не совсем то, что хочется видеть в динамике.

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

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

3.2. A/B-тесты

Мы очень любим A/B-тесты. У нас есть проект, в котором мы провели 70 полноценных A/B-тестов всего за 2 года. Если суммировать наш опыт в некую выжимку, можно сказать следующее:

• A/B-тесты — самый честный (из реалистичных) способ проверки гипотез.
• Лучше всего их делать на новой аудитории. Если тестировать фичу, которую старая аудитория уже видела, и потом показать ей новый вариант, то восприятие и реакция будут не такими, как у людей, которые фичу не видели. Скорее всего, реакция будет негативной и публичной, и может повлиять на результаты теста. Лишь в отдельных случаях, с неочевидными для игроков различиями или в специфических ситуациях, тесты можно проводить на всей аудитории.
• Очень важно проверять статистическую значимость результатов. Вселенная устроена так, что даже в идентичных условиях будет определенная разница в подсчитанных показателях благодаря фактору случайного распределения. Математическая статистика обладает методами, позволяющими с высокой степенью вероятности определить, укладывается ли результат в нормальную погрешность или отражает реальную разницу. Такая работа критически важна для оценки результатов A/B-тестов.
• Если вы собираетесь проводить несколько A/B-тестов, затрагивающих один и тот же параметр, то лучше всего их разносить во времени. Иначе любая странность в результатах спровоцирует дискуссию о том, повлияли ли эксперименты друг на друга, или же есть другое объяснение.
• Не стоит проверять все идеи A/B-тестами. Лучше пропускать их через фильтр команды и выбирать самые сильные гипотезы. У каждого драйвера фичи будет большой соблазн проверить свою гипотезу через A/B-тест. Но на это уйдёт время, и часть пользователей мы не сможем использовать для более важных экспериментов.
• Если вы делаете A/B-тест, то заранее решите, что будет для вас минимальным значимым результатом. В таком случае вы сможете оценить, сколько вам понадобится аудитории для такого теста и сколько примерно времени это займет. Если по окончании срока планка не достигнута, нет смысла продолжать тест. Не увлекайтесь.

3.3. Моделирование проекта

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

У нас есть проект, выручка которого по месяцам выглядит так:

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

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

Важно понимать, что хорошая бизнес-модель обладает определенными свойствами:

• Во-первых, она моделирует процессы внутри сервиса. Это не просто формула вроде «ARPU умножить на аудиторию и получить деньги».
• Модель позволяет сформировать baseline. Не ждите чудес. Она не сможет вам предсказать «чёрных лебедей», например, фичеринги или изменение стратегии привлечения.
• Она правильно моделирует исторические данные. Можно подставить данных из предыдущих временных периодов и получить реальный результат.
• Она легко экстраполируется в будущее. Зная текущее состояние проекта и его поведение в последние месяцы, мы можем продлить эти процессы в будущее. Если в проекте что-то будет меняться, вдруг случится экстренный приток регистрации, или монетизационные акции повысят вашу выручку, то модель при этом не сломается. Она должна уметь это предусматривать.
• Модель учитывает развитие продукта. Если вы сделали важные шаги в проекте, показатели выросли, и модель из-за этого перестала работать, то она была некорректной.
• Модель позволяет задать разные сценарии. Какой результат мы получим через полгода, потратив в этом месяце на рекламу миллион долларов? Хорошая бизнес-модель умеет это предсказать.
• И самое главное для аналитика. Мы не просто делаем какой-то прогноз. Да, часто случается много событий, которые корректируют наши планы. Но в каждый момент времени, разбирая результат моделирования, мы понимаем, почему произошло именно так. Если мы прогнозировали одно число, а получилось другое, то мы сразу можем понять, что пошло не по прогнозу. Может быть, мы не учли какой-то важный фактор. Возможно, внезапно сыграло что-то, что нам нужно учитывать в дальнейшем. Так мы растем не только в контексте прогнозирования и моделирования, но и понимания взаимосвязей факторов, определяющих траекторию роста или падения.

4. Резюме

1. Большому кораблю — глубокая аналитика!
2. Аналитики должны пользоваться продуктом!
3. Разрабатывайте единые подходы и методики, делитесь опытом!
4. Проводите A/B-тесты по сильным гипотезам!
5. Моделируйте поведение проектов!

Перед студией IT Territory стояла непростая задача — показать принадлежность к одному бренду разных проектов и вместе с тем подчеркнуть их индивидуальность. Это удалось благодаря одежде со сменными стикерами.

Многовариативность применения мерча

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

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

IT Territory — это одна из старейших игровых студий внутри VK. У нас много сотрудников и много различных проектов. Именно разнообразие и было основной проблемой при создании мерча. Мы делали сувенирную продукцию с логотипами самых популярных проектов. А в это время сотрудники из других проектов оставались обделёнными. В какой-то момент мы решили, что нам нужен универсальный мерч, который подойдёт всем. Но в то же время важно было подчеркнуть значимость каждого отдельного проекта.

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

Однако оставался нерешённым вопрос с индивидуализацией под проекты. И вот здесь помог StickPeek. Когда я впервые увидела мерч со стикерами, сразу подумала: «Вот оно. То, что поможет охватить все наши проекты».

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

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

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

Самым сложным в создании мерча IT Territory стала разработка стикеров, подходящих для всех сотрудников

Выбор модели и стиля мерча взяла на себя Ольга Карпина, как представитель IT Territory. Для мерча было выбраны толстовки универсальной модели. Цветовую гамму определили корпоративные цвета — чёрный, белый, красный. Белый цвет не стали брать из-за маркости. Остановились на красно-чёрной расцветке. Получилось стильно и практично.

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

Набор стикеров получился действительно универсальным. Специалистам IT Territory удалось охватить всё: и деятельность студии, и индивидуальность отдельных проектов, и общий дух команды.

Одна часть стикеров получилась более официальной. Она была посвящена идентификации проектов. Был создан общий логотип студии — «IT Territory». Также для каждого текущего проекта был создан свой стикер с логотипом. Например, «Castle Duels», «Evolution 2», «Rush Royale», «Аллоды онлайн». Ещё один стикер из «официальной» части был посвящён значимому событию — 18-летию компании — «18 мне уже».

Другая часть стикеров вобрала в себя атмосферу, которая царит внутри студии. Это мемы, популярные фразы про разработку, негласные символы проектов. Например, такие фразы, как «собирись», «дедлайн», «ору» понятны без дополнительных пояснений. Гневный смайл «ъуъ» отражает боль всех программистов. А милое, криворукое создание с надписью «я сделяль» применимо ко всей ручной разработке. Зелёный монстрик и жёлтый резиновый утёнок — негласные символы одного из самых успешных проектов студии Rush Royale.

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

Работа на удалёнке — не повод отказываться от ношения корпоративного мерча

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

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

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

Сначала толстовки, потом бейсболки и сумки, и большие планы на будущее…

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

Нужно отметить, что частично свои планы IT Territory уже воплощает. Например, одна из идей нового мерча — это поясная кобура-сумка (напузник), на которой можно размещать сменные стикеры. Кроме того, сейчас студия решила сделать бейсболки со стикерами. Уже готовы и дизайн, и стикеры. Скоро у сотрудников IT Territory появится очередной мерч от StickPeek.

Кратко о StickPeek

StickPeek — это бренд корпоративного мерча со сменными стикерами. Нашу продукцию уже оценили многие крупные компании и бренды — Ozon Tech, Tutu.ru, Учи.ру, Genotek, Beyosa, ВсеИнструменты.ру, HARZ Labs и другие. Мы создаём одежду из премиум-материалов. Благодаря особому вниманию качеству наша одежда выдерживает длительное использование без потери внешнего вида. Ткани не выцветают, не скатываются, не растягиваются.

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

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

Наш мерч уже оценили более 100 разных компаний и крупных брендов — Azur Games, Raiffeisen Bank, Cognitive, Rostelecom и другие. География применения мерча StickPeek давно вышла за пределы России, и мы даже создали сайт бренда на английском языке. Мы продолжаем развиваться и рассказывать вам об интересных историях сотрудничества.

Эта статья могла быть удалена из Википедии

Студия IT Territory
Тип	Общество с ограниченной ответственностью
Основание	2004 (12 апреля)
Основатели	Сергей Жуков
Расположение	Россия: Москва
Отрасль	Компьютерные игры
Продукция	Локализация и издание: Ground War: Tanks, Кодекс пирата, Фрагория Разработка: Легенда: Наследие Драконов, Джаггернаут, Троецарствие, Территория, Джаггернаут: Месть соверинга, Lucky Fields

IT Territory (известна также как «АйТи Территория» и «Территория ИТ») — российская компания, занимающаяся разработкой и изданием онлайновых многопользовательских игр (MMORPG, BBMMORPG) и игр формата casual games, а в последнее время и mobile games. Основана в 2004 году, главный офис компании находится в Москве. С 2007 года по 2010 входила в состав холдинга Astrum Online Entertainment. С 2010 года входит в холдинг Mail.ru Group Ltd.

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

Для дистрибуции casual игр компания IT Territory использует как собственные площадки, так и партнерские площадки с крупными сайтами и порталами Интернета.

С момента своего появления IT Territory занимается, в основном браузерными играми, однако в 2007 году в структуре компании открыл отдел разработки клиентских MMO, а также подписаны контракты на издание ряда зарубежных клиентских MMO, среди которых «Властелин Колец Онлайн», «Пара Па: Город Танцев» и «Монато. Мир Снов», «Поднебесье» (впоследствии закрыто)

Игры компании[править]

Список многопользовательских онлайновых игр, которые оперирует IT Territory:

• Ground War: Tanks
• Кодекс пирата
• Фрагория

Ссылки[править]

• Официальный сайт компании IT Territory
• Профайл компании на DTF
• Сайт холдинга Astrum Online Entertainment (сайт закрыт)

Игры IT Territory
Разработчик:	Легенда: Наследие Драконов • Герои: Возрождение • Троецарствие • Территория • Cosmics: Галактические войны • BloodyWorld • Бильярдный клуб • Love City • Десант: Рейдеры Мериона • Faor • Жуки@Mail.ru • Драйв@Mail.ru • Территория футбола
Локализатор и издатель:	Властелин Колец Онлайн • Пара Па: Город Танцев • Монато. Мир снов • Silkroad Online • Last Chaos • Поднебесье • Pandora Saga • Flyff