Май 27

Кто такой AdOps Engineer и за что отвечает

Привет! Меня зовут Евгений Дорфман. В прошлом я Senior AdOps Engineer. Сейчас я ушел в технический менеджмент и работаю на позиции TPM (Technical Project Manager) в компании Postindustria, но продолжаю заниматься подбором и обучением AdOps-инженеров.

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

AdOps (Advertising Operations) Engineer — достаточно редкая позиция как в Украине, так и в мире. Большинство IT-компаний еще не пришли к тому, чтобы выделить эту роль в отдельную специальность. Поэтому чаще всего разные элементы работы AdOps берут на себя инженеры, менеджеры по продукту, бизнес-аналитики, маркетологи и другие специалисты.

Задачи и обязанности

Издатели (владельцы сайтов, мобильных приложений и так далее) могут использовать различные механизмы монетизации: например, подписки, платный контент или рекламу. AdOps-инженер имеет дело с последней: такой специалист отвечает за часть стека монетизации сайта или приложения, которая происходит через рекламу.

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

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

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

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

В ходе работы AdOps-инженер выбирает:

Источники рекламы. Как правило, это рекламные сети и Supply-side platform, платформы для продажи рекламных мест. На рынки есть сотни вендоров: MoPub Marketplace, Smaato, PubMatic, InMobi, Chartboost, AdColony, OpenX и так далее.
Механизмы поставки рекламы. Например, для баннерной рекламы можно настроить медиацию с несколькими партнерами. Это означает, что мы интегрируем одновременно нескольких источников на одно рекламное пространство — с последовательным или параллельным перебором их для каждого показа.
In-app Bidding решение. Это решение для проведения параллельных торгов между несколькими источниками перед каждым показом внутри приложения. Одно из самых популярных — Amazon TAM и Prebid.org.
Ad Servers. Это сервер, на котором настраивается, как доставлять рекламу в приложение на каждое рекламное пространство.

Есть много типовых и шаблонных рекламных решений, и каждое имеет свои преимущества и недостатки. Вот несколько примеров:

Google Ad Manager как Ad Server и платформа для медиации. Это максимально гибкий вариант, минусов практически нет.
MoPub как Ad Server и площадка медиации с подключенным MoPub Advanced Bidding решением. Это удобно, но у такого решения чуть меньше гибкости по сравнению с Google Ad Manager.
AdMob как платформа для медиации с теми партнерами, которые поддерживаются «из коробки», а также кастомный Bidding. Такая архитектура позволяет провести быструю интеграцию, но дает минимум фич.

Затем AdOps-инженер устанавливает контакт со всеми партнерами, чтобы получить аккаунты издателя на стороне каждого из них. Процедуры могут отличаться: где-то работает self-service registration, а где-то нужно личное интро.

После этого он настраивает инвентарь в аккаунтах партнеров и на Ad Server. Это делается в панелях управления. После настройки на стороне партнера AdOps-инженер должен подключить его к аккаунту на рекламном сервере для рекламного юнита. Для этого он копирует ID партнера и вставляет их в соответствующих полях в панели управления Ad Server.

Следующий этап — интеграция. AdOps-инженер прописывает разработчикам задачи на интеграции мобильных SDK, а также детали интеграции — Ad Unit IDs, Account IDs и тому подобное. А затем размещает итоговые ads.txt / app-ads.txt файлы в корневом домене издателя.

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

После релиза AdOps-инженер обязан отслеживать показатели монетизации (Fill Rate, CPM, CTR, Viewability) и на их основании продумывать дальнейшие шаги для оптимизации: добавить ли источников, инвентарь и так далее.

Особенности направления

Типичный рабочий день AdOps-инженера зависит от того, на каком этапе находится проект. Например, на этапе планирования и проектирования рекламного стека это может быть 5–10 дней фултайм-работы с полным погружением в специфику одного проекта: нужно изучить его как на уровне UX, так и на уровне кода. Артефакты, которые создаются на этом этапе, — это детальный план по инвентарю и поставке рекламы, а также модель архитектуры и список выбранных вендоров.

Когда мы уже интегрировали рекламу в продукт, AdOps-инженер в основном задействован в проекте по несколько часов в неделю. Он работает с отчетами (Google Ad Manager, аналитика продукта и различные дашборды конкретных вендоров), а также принимает решения, куда двигаться дальше, расписывает задачи разработчикам и берет на себя различную коммуникацию.

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

KPI-граф и как AdOps на него влияет:

Чтобы улучшить рекламные показатели, AdOps-инженер может использовать типичные приемы из продакт-менеджмента и инструменты для тестирования гипотез. Например, A/B-тесты: тестируем два источника рекламы. На одном и том же рекламном пространстве 50% пользователей видят один источник, 50% — другой. Затем мы сравниваем показатели. Например, первый источник приносит больше денег — значит раскатываем его на всех пользователей. Это простейшая оптимизация.

Как и работа менеджера по продукту, работа AdOps-инженера — это бесконечный цикл develop → release → accumulate feedback → learn → decide → develop. Индустрия и продукт все время меняются, мы постоянно накапливаем знания и адаптируем рекламные механизмы. В этом состоит и основной вызов и драйв работы в AdOps.

Таким образом, AdOps-инженер — это специалист, который работает на стыке инженерии, бизнес-анализа и управления продуктом. Эта роль требует, чтобы человек комплексно понимал продукт и поведение пользователей, так как все это влияет на монетизацию.

Зарплаты AdOps-инженеров соизмеримы с зарплатами проектных менеджеров и менеджеров по продукту.

К слову, часто в IT-компаниях нет отдельной позиции «AdOps-инженер», и тогда функции AdOps берет на себя менеджер по продукту или техлид. Другой вариант: эта роль размазана между несколькими специалистами. Например, менеджер по продукту отвечает за бизнес-часть — установление контактов с источниками рекламы, репортинг и отслеживание показателей, а инженер занимается техническими интеграциями.

Преимущества и недостатки

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

На этой позиции меня привлекает сложность и нетривиальность рыночных структур и возможность решать интересные задачи оптимизации. Собственно, задача всегда одна и та же: как заработать больше денег? К примеру, на одном из проектов мы долго решали, какими источниками наполнить свои рекламные пространства, чтобы Fill Rate был выше 80%. Потом начали решать задачу повышения CPM — отобрать такие источники, которые позволяют максимально повысить этот показатель.

Это бесконечный процесс: мы постоянно экспериментируем с новыми источниками. Например, интегрировали три In-app Bidding решения в одно приложение: Amazon TAM + PubMatic OpenWrap + Prebid. Это обеспечивает конкуренцию между большим количеством источников.

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

Если говорить о недостатках специальности, я могу выделить обилие рутины. Из-за слабой автоматизированности AdOps-инженеры вынуждены выполнять много шаблонных и простых действий вручную. Например, обычный copy-paste: при конфигурировании источников рекламы нужно копировать ID рекламных пространств, которые настроены в конкретных сетях, и вставлять их в свой Ad Server через Web UI. Это ручная работа с высокой ценой ошибки.

Но мы боремся и с этой проблемой рутинности: например, разработали инструмент автоматизации типичных задач AdOps при настройке Header Bidding ордеров.

Как стать AdOps-инженером

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

Начинать изучение специальности я советую с профессиональных терминов. Хороший глоссарий есть у Google. Затем можно освоить IAB-стандарты.

Что касается конкретных технологий — возможно, я многих разочарую, но точного перечня нет. Чем больше вы знаете, тем лучше. Главное — иметь комплексное понимание, как устроена физика рекламной цепочки, то есть механика движения трафика. Вот хорошие статьи по механике медиации на клиенте, всей цепочки снизу доверху, Header Bidding (один, два).

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

Для этого стоит ознакомиться с инструментами, которые AdOps-инженеры используют в работе. Например, в моем случае это:

софт для аналитики самого продукта (Firebase, Amplitude, Flurry, Indicative, кастомные BI-решения вроде Python ETLs, Time series DBs);
инсталл-атрибуция, то есть софт, что помогает определить источники, из которых пришли пользователи (AppsFlyer, Kochava);
инструменты для A/B-тестирования (например, Firebase);
инструменты для маркетинг-автоматизации (Swrve, Braze, Firebase);
рекламные серверы (Google Ad Manager, MoPub, AdMob);
специальный софт для настройки Header Bidding ордеров на рекламных серверах (PubMonkey);
девелоперские инструменты (Charles Proxy).

Из софт скилов AdOps-инженеру нужно знать английский, а также развивать:

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

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