Как работает SSP?

# Part 1

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

Все начинается, когда пользователь заходит на сайт с рекламным слотом. В этот момент паблишер трекает пришедшего пользователя и отправляет на Prebid Bid Request о том, что нужно проводить аукцион. В составе Bid Request паблишер также передает список партнерских SSP, которые могут биддить на слотах (или по-другому adUnits) на его сайте. Также в паблишер прикрепляет в запросе характерные для каждого SSP параметры.

bids: [{
   bidder: 'appnexus',
   params: {
  placementId: 13144370
   }
 },
 {
   bidder: "adyoulike",
   params: {
  placement: "e622af275681965d3095808561a1e510"
   }
}]

Далее также на браузере запрос обрабатывается кодом Prebid.js, который рассылает его по разным SSP через их соответствующие Bid Adapter'ы.

1️⃣ Placement Call
В момент, когда запрос приходит на SSP, тригерится первый внутренный ивент placementCall. SSP сервер принимает POST запрос на ставку.

Далее внутри SSP происходят различные проверки этого запроса, например
- SSP отправляет запрос на Double Verify для проверки сайта на MFA (Made For Advertising) и Brand Safety
- Запрос проверяется на наличие ошибок: adUnit not found, SDK deprecated, publisher blacklisted etc.


2️⃣ Bid Request Hydration
После то, как все проверки корректности запроса проведены, он обогащается данными о пользователе (геолокация, статы User Agent). Эти данные добываются разными способами: с помощью 1st/ 3rd party-cookie (как работают куки мы рассматривали в предыдущих постах раз, два), Google Privacy Sandbox, при запросе на третье-сторонние Data Management платформы вроде Exelate.

Также на этом этапе запускаются первые ML модели, которые предсказывают
- P(bid | request) вероятность хотя бы одно бида в DSP аукционе при условии реквеста
- P(impression | ssp_hb_win) вероятность показа при условии победы SSP в Prebid аукционе


3️⃣ DSP Bid Request
После того, как проверки и фильтры на стороне SSP пройдены запрос рассылается на DSP для ставки во внутреннем SSP аукционе. Предарительно SSP кастует запрос в стандартный формат Open RTB 2.5. Также SSP выставляет floor price, минимальную цены, ниже которой ставки не принимаются.

Здесь также запрашивается ML модель, которая предсказывает P(bid_dsp_i != null & is_not_timeout) вероятность ставки от конкретного DSP. Это нужно, поскольку 95% RTB бид реквестов, отправляются в пустоту и не получают ответов от DSP. Таким образом экономятся ресурсы на HTTP запросы.


#adtech

Optuna для препроцессинга данных

Как правило оптуну воспринимают исключительно, как инструмент оптимизации гипер-параметров модели. Но ее возможности несколько шире. Например, можно повесить на нее и препроцессинг

Предположим, у нас есть датасет, а внем колонки с пропусками. От колонок с большой долей пропусков нам нужно избавляться.
- Чтобы понять, колонки с какой долей пропусков (70%, 80%, 90% etc) удалять, мы сначала подсчитываем это значение в каждой колонке.
- Затем в цикле генерируем количество пропусков, которое хотим оставить
- Отбираем колонки по этому количеству
- Формируем датасеты для обучения и валидации

nulls_perc = (X.isna().sum() / X.shape[0] * 100).astype(int).sort_values(ascending=False)

def objective(trial):
    params = {
        'objective': 'regression',
        'metric': 'mse',
        'learning_rate': trial.suggest_float('learning_rate', 1e-5, 0.7, log=True),
        'num_leaves': trial.suggest_int('num_leaves', 20, 150),
        'verbose': -1
    }
    
    nulls_max = trial.suggest_int('nulls_max', 10, 100)
    f_cols = list(nulls_perc[nulls_perc < nulls_max].index)

    X_train = train[f_cols]
    X_test = test[f_cols]

    model = lgbm.train(
        params = params,
        train_set = lgbm.Dataset(X_train, y_train),
        valid_sets = lgbm.Dataset(X_test, y_test),
        verbose_eval = None
    )

    score = model.best_score['valid_0']['l2']
    print(score, len(f_cols))

    return score

study = optuna.create_study(direction='minimize')
study.optimize(objective, n_trials=3000, timeout=300)

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

Floor Price Optimization in RTB Auctions

Хочу сделать разбор статьи по оптимизации floor прайса в RTB аукционах в Yahoo Ad Exchange.

1️⃣ Какая мотивация?
Floor price (или еще Reserved price) - минимальная цена, ниже которой ставки не принимаются. Это также минимальная цена, которую выплачивает биддер в случае победы. Выставляется паблишером и характеризует в какой-то степени ценность продаваемого инвентаря.

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

При изменении флора мы с одной стороны влияем на выручку (чем выше флор, тем выше средняя выручка с аукциона). Но с другой стороны, если сильно задрать флор, то это поднимет порог на вход в аукцион, и меньше DSP будут готовы биддить, что наоборот понизит выручку. Поэтому ставится задача найти такое значение минимальной цены, которое обеспечить максимальный revenue.

2️⃣ Что по статье?
Задача оптимизации ставится следующим образом:

Целевая функция 

eRev(floor | X) = rev(floor | X) + ADXRev * proba (bids < floor | X)

- т.е. берется выручка как функция от флора при условии фичей (девайс, user-agent, dsp)
- если на бид реквест все биды ниже флора, то Yahoo отправляют реквесты на Google Ad Exchange и через него продают инвентарь

постановка задачи: найти такой флор, чтобы максимзировать суммарную выручку floor * = argmax eRev(floor | X)
- rev(floor | X) представляется в виде интеграла
- rev(floor | X) = sum(k_i * sum(bid_i * mult(F(bid_i | floor, X))). Здесь суммарную выручку считают как интеграл от бида ДСП  умноженного на функциую распределения бида ДСП при условии флора. k_i = {0, 1} и нужен для того, если ДСП бидить или не бидит. Аналогичный интеграл приводится и для Google ADX

далее оценивают распределение F(bid_i | floor, X)  из исторических данных как распределение Weibull’а с параметрами scale, shape .
- чтобы нащупать кривую F рандомизируют флоры и логируют значения бидов. При этом отсекают 95% квантиль, чтобы убрать выбросы. Данные берут за 7 дней
- далее оценивают параметры  scale, shape для F. Здесь просто фитят это распределение на гистограмму, полученную с прошлого шага
- далее решают задачу максимизации rev(floor | X) , после того как узнали параметры распределения F. При этом считают флор отдельно для связки (placement, site, publisher, DSP)
- после этого пушат флор в SSP

Также сама статья по оптимизации флора

Привет! Если вы интересуетесь внутренней кухней и инсайтами Avito.Tech, то рекомендую вам канал big_ledovsky.

Его ведет Александр Ледовский, Team Lead команды монетизации Avito.

У себя в постах я уже рассказывал о его выступлении на DataFest'е, например по дискуссии на тему рекламных аукционов с ребятами из Яндекс Директ и Ozon. Несмотря на то, что бизнесы маркетплейса и display-рекламы отличаются друг от друга, многие технические задачи и модели очень схожи, например,

- предсказание кликабельности слотов и их ранжирование в выдаче
- или механизмы монетизации инвентаря и аукционы

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

Кроме технической части здесь вы сможете узнать о буднях DS команд в Avito.Tech, актуальные вакансии, а также полезные советы о том, как сохранять work-life баланс, будучи менеджером команды.

Го подписываться! 🔥

Ранее я рассказывал про метод Adversarial Validation. Он помогает проверять, приходятся ли фичи из train/ test из одного распределение. Эта задача также называется ковариационный сдвиг между фичами в выборках

Несмотря на то, что это очевидный недостаток в данных, мы можем попробовать использовать его в свою пользу
- С помощью классификатора Adversarial Validation на train/ test для каждого объекта трен. выборки возьмем его вероятность принадлежности к тесту P(y=1)
- Далее будем использовать полученную вероятность как вес сэмпла при обучении модели
- Модель при обучении будет обращать больше внимания на примеры, схожие с тестовой выборкой

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

Как работает SSP?

# Part2

Итак, в прошлом посте о работе SSP мы остановились на отправке RTB запросов на DSP после их предварительной фильтрации.

▶️ Auction Resolution
Допустим, мы получили ответ от некоторых DSP, и теперь можем разрешить аукцион и выбрать победителя. Внутренний аукцион, как правило, первой цены, значит победитель платит свою ставку.

На этом же этапе происходят следующие вещи
- SSP создает xml файл VAST, в котором прописываются ставка, ссылка на креатив, его формат, и tracking ивенты (это более актуально для видео, где трекаются inview, start, midpoint, complete)
- Если SSP закупает инвентарь у паблишера напрямую, и цель рекламной кампании забидевшего рекламодателя CPM, т.е. branding показа, то мы минуем Prebid аукцион. И в этот же момент триггериться биллинг ивент, и SSP платит паблишеру.
- Также проверяем креатив на наличие ошибок error-vast перед тем, как его отправить паблишеру (например, формат креатива не соответствует заявленному на слоте, или ломаная ссылка в VAST)

Ниже приведен пример, как может выглядеть VAST файл

<VAST version="3.0">
  <Ad id="20001" sequence="1">
    <InLine>
      <AdSystem version="1.0">Criteo</AdSystem>
      <AdTitle>Adidas Video Ad</AdTitle>
      <Description>VAST 3.0 compliant video ad</Description>
      <Advertiser>Adidas</Advertiser>
      <Pricing model="CPM" currency="USD">25.00</Pricing>
      <Impression><![CDATA[https://criteo.com/impression]]></Impression>
      <Creatives>
        <Creative sequence="1" AdID="20001">
          <Linear>
            <Duration>00:00:30</Duration>
            <TrackingEvents>
              <Tracking event="complete"><![CDATA[https://sample-ssp.com/tracking/complete]]></Tracking>
            </TrackingEvents>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4" bitrate="500" width="640" height="360" scalable="true" maintainAspectRatio="true">
                <![CDATA[https://sample-ssp.com/mediafile.mp4]]>
              </MediaFile>
            </MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</VAST>

▶️ Header Bidding SSP Bid Response
В случае, если SSP бидит на Prebid, то она прокидывает полученную ранее ставку DSP с модификаторами и вычтенной маржой. Формулу ставки SSP можно представить в следующем виде

ssp_price = clearing_price * (1 - margin) * P(impression|auction_resolved) * bid_modifier

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


▶️ SSP Header Bidding Win
Если SSP победила в HB аукционе, то триггерится ивент ssp_hb_win. Prebid отсылает уведомление о победе, а SSP отправляет ему tag VAST с креативом. В этот момент SSP оплачивает инвентарь паблишера в размере своей ставки.


▶️ Impression
Собственно, сам ивент показа. Он триггерится в момент, когда пользователь доскролил до Ad слота и ему виден пиксель, заранее размещенный на слот. На показе DSP платит SSP clearing_price. Из этой цены аккумулируется средний CPM, который можно видеть в Yandex Direct или Google DV360 при отслеживании кампании

Также на моменте показа тригеррятся ML модели предсказывающие полноту показа (для видео) и клики для performance кампаний. В зависимости от цели кампании ее биллинг ивенты смещаются соответсвенно на complete или click
- Viewability: P(inview | impression)
- Compeltion: P(complete | impression)
- CTR: P(click | impression)

#adtech

Немного инфографики. Подкапотное описание команд Docker для образов и контейнеров вдобавок к шпаргалке.

Сохраняем к себе!

Подъехала запись моего выступления на ODS DataFest на тему ML моделей для Traffic Filtering в программатик рекламе (также пост с описаннием по ссылке)

ONNXRuntime для ускорения ML моделей ⚡️

Сегодня речь пойдет про формат ONNX. Он помогает портировать ML модели в стандартном формате на другие языки, например на JVM. Для запуска моделей в этом формате используется фреймворк ONNXRuntime. Кроме того ONNXRuntime позволяет ускорить инференс. Об этом мы сегодня и поговорим. В качестве примера возьмем модель на PyTorch и сравним скорость инференса до и после конвертация в ONNX.

Как работает ускорение?

В PyTorch обработка данных ленивая, т.е. команды сначала добавляются в очередь и потом из нее выполняются. Для выполнения всех запланированных вычислений нужен torch.cuda.synchronize(). Запустим torch модель на входном массиве (1,3,224,224) , запишем время инференса и оценим FPS. Также удалим, из результатов первые 20 запусков, которые как правило уходят на прогрев.

n_steps = 200
n_warmup_steps = 20
times = []
data = torch.ones((1,3,224,224), device="cuda")

torch.cuda.synchronize()

for step in range(nsteps):
 start_inference = time.time()
 result = model(data)
 torch.cuda.synchronize()
 end_inference = time.time()
 times.append(end_inference - start_inference)
times = times[n_warmup_steps:]
print(np.mean(times), np.std(times))

PyTorch выдает 400 FPS. Этот результат получился в следствие того, что граф модели PyTorch - динамический, что ограничивает его скорость инференса. Теперь скастуем из динамического графа torch'а статический граф и запишем в формат ONNX

torch.onnx.export(
 model,
 torch.randn(1, 224, 224).to(device),
 'mobilenet_v2.onnx',
 input_names = ['input'],
 output_names = ['output'],   
)

Для того, чтобы подгрузить ONNX модель, нам нужно создать InferenceSession. Далее читаем модель и запускаем инференс на ONNXRuntime. Также засечем время инференса, чтобы проверить ускорение.

import onnxruntime as ort
import numpy as np

providers = [('CUDAExecutionProvider', {'device_id': 0})]
ort_sess = ort.InferenceSession("mobilenet_v2.onnx", providers=providers)

n_steps = 200
n_warmup_steps = 20
times = []
image_as_numpy = np.ones((1,3,224,224))

for step in range(n_steps):
 start_inference = time.time()
 outputs = ort_sess.run(None, {'input': image_as_numpy})
 end_inference = time.time()
 times.append(end_inference - start_inference)

times = times[n_warmup_steps:]
print(np.mean(times), np.std(times))

ONNXRuntime выдает 630 FPS, т.е. мы получаем прирост скорости инференса в полтора раза. Здесь запуск проводился на CUDA, но ONNX также поддерживает и запуски на CPU

Мы собрали папку тг каналов про AdTech

Что вы здесь найдете
- Авторские мнения, дайджесты новостей: Сookie, Connected TV, Direct Sold контракты в обход SSP и многое другое
- Инженерная часть: как технически устроены SSP/DSP, как работает Prebid, как применять ML модели в программатике
- Монетизация: какими метриками измерять, как влиять на ставки в Header Bidding, настройки форматов в рекламной сети Яндекса
- Инфографика, разбор отчетности крупных игроков, и что происходит в мире AI-based стартапов в рекламе и ecomm
- Sales в маркетинге и рекламе, как обрабатывать лиды и закрывать сделки

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

Ранее я уже писал про функционал Optun'ы, что ее можно использовать, как для оптимизации параметров модели, так и для препроцессинга

Сегодня обсудим прунинг экспериментов с Optuna. Прунинг здесь - это прерывание эксперимента, по какой-либо метрике, когда она уже вышла на плато и перестала значимо менятсья. Т.е. если мы поставили CatBoost модель обучаться на 500 шагов и видим, что после 50 шагов лучший скор уже получен и его не превзойти, то логично обучение остановить и тестировать следующую итерацию параметров

Какие Pruner'ы есть в Оптуне?
- MedianPruner: останавливает испытание, если скор ниже медианы скоров с предыдущих шагов
- PercentilePruner: останавливает испытание, если скор находится в нижних персентилях с предыдущих шагов
- SuccessiveHalvingPruner: прунер на основе многоруких бандитов. Помогает не только во время остановить обучение, но и выбрать лучшую комбинацию гиперпараметров
- ThresholdPruner: останавливает испытание по пороговому значению

Лучший вариант для классических моделей SuccessiveHalvingPruner. Здесь пример, как его можно реализовать

X, y = load_iris(return_X_y=True)
X_train, X_valid, y_train, y_valid = train_test_split(X, y)
classes = np.unique(y)


def objective(trial):
    alpha = trial.suggest_float("alpha", 0.0, 1.0)
    clf = SGDClassifier(alpha=alpha)
    n_train_iter = 100

    for step in range(n_train_iter):
        clf.partial_fit(X_train, y_train, classes=classes)

        intermediate_value = clf.score(X_valid, y_valid)
        trial.report(intermediate_value, step)

        if trial.should_prune():
            raise optuna.TrialPruned()

    return clf.score(X_valid, y_valid)


study = optuna.create_study(
    direction="maximize", pruner=optuna.pruners.SuccessiveHalvingPruner()
)
study.optimize(objective, n_trials=20)