Ниаршор-команды для AdTech в Армении и на Кавказе: как проверить опыт в RTB, общие часы, язык и условия фиксированного объёма

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

Какие AdTech-команды в Армении или на Кавказе стоит рассмотреть?

Рейтинга компаний здесь нет. Включайте команду в шорт-лист, только если она строила и эксплуатировала в продакшене систему того же рода, что нужна вам: биддер или платформу на стороне спроса (DSP), которая покупает рекламу через торги в реальном времени (RTB), SSP, рекламную биржу, ad-сервер или пайплайн, который считает показы и клики. Попросите каждую компанию назвать живую систему и часть, которую построили её инженеры, и дать вам поговорить с этими инженерами, а не только с продажами.

Кое-что можно проверить публично. Prebid — это open-source программа, с помощью которой паблишеры запрашивают ставки сразу у многих SSP и бирж, и каждое такое подключение — это адаптер биддера в публичном коде Prebid с открытой историей того, кто его менял. Документация Prebid просит указывать для каждого адаптера Prebid.js «контактный email мейнтейнера адаптера». Проверьте, на каком домене этот email, а если компания говорит, что написала адаптер для какой-то платформы, попросите ссылки на её pull request'ы.

Если соглашение о конфиденциальности не позволяет назвать клиента, попросите компанию организовать звонок с этим клиентом.

Как проверить, что у команды настоящий опыт в RTB?

Дайте инженерам настоящий запрос на ставку из ваших логов, без персональных данных, и попросите разобрать его с вами. Обратите внимание, начнут ли они с дедлайна. OpenRTB 2.6, стандарт IAB Tech Lab для запросов на ставку, определяет поле tmax как «максимальное время в миллисекундах, которое биржа отводит на получение ставок с учётом задержки в интернете, чтобы избежать таймаута».

Затем спросите об уведомлениях, которые сообщают биддеру, что стало с его ставкой. OpenRTB 2.6 описывает три. Биржа отправляет уведомление о выигрыше, «если ставка выиграла (что не обязательно означает, что реклама доставлена, просмотрена или подлежит оплате)». Уведомление о биллинге она отправляет, «когда выигравшая ставка становится подлежащей оплате по бизнес-правилам конкретной биржи», а уведомление о проигрыше — «когда известно, что ставка проиграла». Команда, которая сверяла свои расходы со счетами биржи, расскажет, какое уведомление считала её система и что она делала, когда цифры расходились.

Ещё четыре вопроса:

• Что происходит со ставкой, готовой позже tmax, и как вы видите, сколько ставок приходит с опозданием?
• Как ваш биддер учитывает минимальную цену в запросе — поле bidfloor, которое OpenRTB определяет как «минимальную ставку за этот показ в CPM»?
• Расскажите об инциденте в пиковый трафик: что сломалось, что вы измерили и что изменили.
• Кто будет дежурить по нашей системе и в какие часы?

Больше всего времени уделите инциденту: на вопросы о полях можно ответить по одной спецификации.

В каком часовом поясе работают команды в Армении, Грузии и Азербайджане?

UTC+4, круглый год. По базе часовых поясов IANA, ни одна из трёх стран не переводит часы, а Европа и США переводят. Если обе стороны работают с 9 до 18, у команды в Ереване, Тбилиси или Баку общих часов:

• с Берлином, Парижем или Амстердамом — шесть рабочих часов зимой и семь летом
• с Лондоном — пять часов зимой и шесть летом
• с Нью-Йорком — один час, пока в США действует летнее время, и ни одного зимой
• с Калифорнией — ни одного рабочего часа

Аукционы не останавливаются в шесть вечера. Если ваш трафик достигает пика с 20 до 23 часов на Восточном побережье США, в Ереване это примерно с 4 до 8 утра. Договоритесь письменно, кто дежурит в ваш пик, как быстро он реагирует и как связывается с кем-то на вашей стороне.

На каком языке будет работать команда?

OpenRTB и документация Prebid публикуются на английском, так что инженер в AdTech должен хорошо читать по-английски. Писать и говорить на нём под давлением — отдельный навык, и сайт компании не скажет вам, у кого он есть.

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

Какая работа в AdTech подходит для фиксированного объёма?

Фиксированный объём работает, когда выполнены три условия: у работы есть письменная спецификация, есть приёмочный тест, который могут прогнать обе стороны, и результат не зависит от графика партнёра.

Работа в AdTech, которая часто отвечает этим условиям:

• Новая интеграция с партнёром со стороны спроса или предложения, который публикует свою спецификацию OpenRTB и тестовый эндпоинт
• Адаптер биддера для Prebid Server. Правила тестирования Prebid — отдельный JSON-файл на каждый тест-кейс и ручное сквозное тестирование — дают обеим сторонам готовый приёмочный тест
• Перенос отчётности по событиям в новую базу данных с приёмкой, когда новые подсчёты совпадают со старыми на одних и тех же днях трафика
• Довести биддер до согласованного числа запросов в секунду в пределах согласованного времени ответа, с приёмкой по нагрузочному тесту на трафике, воспроизведённом из ваших логов

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

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

При любом объёме в договоре должно быть сказано, как оценивается изменение.

Что должно быть в договоре с ниаршор-командой для AdTech?

Помимо обычных условий, пропишите:

• Часы, общие у команды с вашими, и кто дежурит вне их
• Страны, из которых работает каждый инженер
• Что код хранится в ваших репозиториях и работает в облачных аккаунтах, открытых на имя вашей компании
• Для SSP или биржи — что вашей компании принадлежат договоры с покупателями и продавцами и домен, указанный в ads.txt и sellers.json, — публичных файлах, по которым покупатели проверяют, кто вправе продавать рекламное место

Проверки по реестру, санкциям и платежам описаны в статье о выборе компании в Восточной Европе или на Кавказе.

Где здесь место amBrain?

amBrain, который ведёт этот блог, — инженерная компания из Еревана, Армения. Его услуги в AdTech на сайте перечислены так: «Разработка DSP, платформ real-time bidding и ad exchange». RTBBidder — demand-side платформа, которую amBrain построил для клиента на Rust и Go.

Он строит и другие системы, о которых идёт речь в статье, — по его собственным словам: «amBrain строит supply-side платформы (SSP) для паблишеров» и «amBrain строит пайплайны событийной аналитики для AdTech: сбор и обработка событий показов и кликов и отчётность по ним». Он делает софт с 2019 года и работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды.

О владении у него такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». Задайте amBrain те же вопросы, что и любой другой команде: взял бы он какую-нибудь из ваших задач с фиксированным объёмом и с каким приёмочным тестом, и какие именно переиспользуемые компоненты имеются в виду.

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