Как наладить работу отдела маркетинга с техническими специалистами — рассказ G5 Games

Статья составлена на основе доклада, с которым Александр выступил на White Nights Moscow 2019.

Александр Безобразов

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

Такое взаимодействие порой напоминает мне ролевой сурвайвал (Survival RPG), где ты должен прокачать себе набор скиллов, чтобы выжить в этом жестоком мире, или хидден (Hidden Object Game), где от твоей внимательности к деталям зависит успешное прохождение уровня.

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

***

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

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

Теперь давайте поговорим о принципах и кейсах.

1. Общайся с разработчиками, продукт делающими

У меня есть друг, который несколько лет назад пришел в новую компанию и решил познакомиться с командами продуктов, узнать как они взаимодействуют с маркетингом. Все команды дали почти идентичный по сути ответ: «Мы не знаем, что делает маркетинг». А как же они могли это знать, если никто не пробовал им донести эту информацию? Команда маркетинга не была в этом заинтересована.

Даже когда команда маркетинга стала более заинтересованной в общении, регулярно происходили ситуации, которые можно было свести к двум фразам «Чем эта девочка занимается?» и «А, это та девочка по иконкам…» Такой образ появился в результате активного взаимодействия с командами продуктов ASO-специалиста, периодически просившего заменить иконку в билде игры после успешного A/B-тестирования.

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

2. Проверяй данные, к тебе приходящие

Во фритуплейных играх маркетологи очень часто, если не всегда, трекают событие покупки в приложении (IAP) и событие первого платежа. В кейсе, про который я расскажу, у компании в оперировании было несколько игр, в которых указанные ивенты были «имплементированы». При выходе новой игры маркетинг просто попросил команду этой новой игры внедрить такие же события. «Нам нужны покупки и первый платеж», — сказали они.

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

События были внедрены, игра запущена, все довольны… только через некоторое время почему-то начинают сильно расходиться показания Marketing Measurement Partner (MMP) и консоли стора по выручке. Большую разницу на конверсию курсов или рефанды в сторе не спишешь.

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

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

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

3. Документируй реализацию, для тебя выполненную

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

Команда User Acquisition, с которой работал мой друг, обратила внимание, что конверсия в плательщиков по органическому трафику превосходит таковую по платному трафику в части стран. Несущественно, но это казалось им «контр-интуитивным»: во-первых, Paid UA был «супер-таргетированный» из-за жестких KPI по окупаемости; во-вторых, на органическую конверсию должны были «давить» фичеры, трафик с которых хоть и поднимает общую выручку, но в среднем конвертируется хуже обычной органики.

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

Некоторое время даже команда игры не могла объяснить, почему так происходит: сотрудник, занимавшийся внедрением, уволился. При этом все были уверены: ивент отправляется в корректный момент, с корректными метриками – это было проверено. Высказывались предположения о каком-то новом, неведомом фроде или о том, что «это проблема на той стороне». В данном случае «той стороной» выступал MMP.

Что было на самом деле? Игра «устанавливала», первый это платеж или нет, на своих собственных данных и отправляла ивент в MMP. Проблема в том, что в части случаев MMP и собственный сервер игры по-разному трактовали «уникальность» установки: для одних это была новая установка и новый пользователь, а для других – старый пользователь, переустановивший игру.

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

Это приводит нас к третьему принципу: документируй реализацию, для тебя выполненную. Если для вас что-то сделали и вам показалось, что все работает, – убедитесь, что у вас есть документация. Нет документации? Тогда общайтесь с разработчиками, разбирайтесь и пишите сами. Иначе через полгода выяснится, что никто не знает, как это вообще работает.

4. Фиксируй договоренности, тобою достигнутые

Когда у вас одна игра и вы все локально расположены в одном городе – взаимодействовать проще, чем с несколькими проектами и в распределенной команде. Особенно, когда маркетинг «выделен» из продукта.

В этом кейсе команда маркетинга занималась App Store Optimization приложений, которые разрабатывали не зависящие друг от друга по ресурсам команды разработки. Для ASO критически важно знать даты выхода билдов в сторы, как минимум для того, чтобы спланировать свою работу применительно к подготовке мета-данных для App Store, где вы ничего без билда изменить не можете. Более того, для подготовки этих мета-данных ASO-специалисту необходимо было готовить креативы с дизайнерами и переводы текстов с командой локализации. У этих команд тоже были свои планы и ограничения по ресурсам, они, как и маркетинг, не были завязаны на какую-то одну игру.

Маркетинг неоднократно просил продуктовые команды предупреждать заранее о датах релизов, не сдвигать эти даты «по-тихому» и не делать несколько релизов на одной неделе. Пока это были устные договоренности – они работали через раз и, по ощущению, скорее случайно. Это важный урок, который можно выразить фразой: фиксируй договоренности, тобою достигнутые.

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

После того как появились отдельные задачи, маркетингу стала доступна информация по изменениям. Если что-то меняется или «накладывается» между несколькими играми – это видно сразу, а не пост-фактум; сразу же видны и потенциальные «накладки» у игр, маркетинга, дизайнеров и локализаторов.

5. Читай техническую документацию, тебе доступную

Летом этого года я подробно рассказывал на White Nights в Питере об опыте внедрения рекламной монетизации во «взрослые» проекты.

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

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

Казалось бы, что сложного? Делаешь аккаунт, даешь разработчикам ссылки на документацию, SDK и ключ аккаунта + доступ к нему – и поехали. Это в идеале. Мой друг решал похожую задачу, и у него что-то пошло не так. Внедрение заняло месяца полтора. Полтора месяца на добавить одну строку. Согласитесь, как-то многовато будет?

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

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

6. Прими ограничения, технологией созданные

Этот принцип я продемонстрирую на следующим кейсе: внедряя рекламную монетизацию, компания, в которой работал мой друг, решила пойти по пути разработки in-house медиации. Это было решение собственника, а одной из целей была прозрачность и полный контроль за количеством просмотров (impressions) как одной из метрик, влияющих на выручку по рекламе.

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

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

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

Отсюда следующее правило: прими ограничения, технологией созданные.

7. Прими изменения, в команде происходящие

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

Один мой друг продвигал игру, в которой за полтора года сменилось 5 проджект-менеджеров и 3 продюсера. 18 месяцев, 8 разных «ключевых персон», с которыми необходимо выстраивать взаимоотношения, достигать договоренностей. Естественно, что такая ситуация негативно влияла и на продукт, и на команду.

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

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

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

Вместо заключения

Когда я смотрю на принципы выше, особенно сформулированные таким немного пафосным образом, я задаюсь вопросом: это больше о технарях или маркетологах? Мне кажется, что это больше о вас самих. Хотите ли вы быть «девочкой с иконками» и не понимать, на каком языке с вами говорят технари? Хотите ли вы рассказывать, что это они не умеют общаться? Может быть, стоит начать с себя: прочитать документацию, поговорить с людьми, в общем, прокачать свои технические скиллы, чтобы взаимодействие с технарями если и напоминало ролевую игру, то скорее Puzzle RPG, чем Survival RPG.