Сегодня разберем InStream формат

Что такое Instream?
Это видео, которое играет до/ во время/ после основного потока видео контента (pre- / mid- / post-roll) например на YouTube. Ролики могут быть длительностью 5-30 сек с/ без возможности пропуска

➡️ Как интегрировать InStream в SSP?
Инстрим может быть настроен
- под разную среду (Web Desktop, Mobile, InApp SDK, AMP etc.)
- и под разные каналы доставки (Open Exchange, DealID)

Фильтрация инстрим слотов происходит на стороне аукциона SSP аналогично другим форматам. По таргетингу SSP передает данные по IP, User-Agent, geo, device, OS. Также передаются метаданные слота startdelay например 0 (pre-roll), 15 (mid-roll), -1 (post-roll)

Также SSP должна поддерживать third-party web видеоплеер (Video.js, ExoPlayer etc.), чтобы доставлять совместимый креатив. Видеоплеер инициирует VAST запрос к SSP, который в свою очередь генерирует VAST.xml с нужным креативом и трекинг-ивентами (start, progress, midpoint, complete, skip etc.)

➡️ Что по бизнес импакту?
У инстрима более узкий охват, чем у обычного вэба, но эффективен для аудитории, активно просматривающей видео, и лучше вовлекает в просмотр (это особенно верно для non-skippable видео). Из меньшего охвата могут быть ограничения на таргетинг. Но при этом с технической точки зрения встроить инстрим можно в любой сайт, где установлен видеоплеер

Интересные процессы по развитию ecomm'ом своих рекламных платформ и ухода от монополии Гугла, на которые стоит обратить внимание

Amazon остановил всю рекламу в Google Shopping

С 21 по 23 июля доля показов Amazon в Google Shopping снизилась до 0%:
- США: ~60% -> 0%
- Великобритания: ~55% -> 0%
- Германия: ~38% -> 0%

Тут два важных тренда:
- Перетекание товарных поисковых запросов из поиска в маркетплейсы
- Развитие маркетплейсами своих рекламных платформ

И тут позиция Amazon понятно - он уже может позволить себе не тратить деньги на Google, а улучшить свою unit-экономику и инвестировать в развитие своей собственной рекламной платформы.

Amazon уже снижал в мае бюджеты на Google Shopping в США на 50% в мае. Теперь решили сделать более радикальный тест. Но тренд уже понятен.

@dmcrus

CCPA

Сегодня поговорим про user privacy в рекламе. Начнем с California Consumer Privacy Act (или CCPA). Это закон о защите прав пользователей в US, который регулирует продажу или передачу их персональных данных

➡️ В чем основное отличие от GDPR?
GDPR = Privacy by default, т.е. пользователь должен сделать opt-in, а согласие по умолчанию запрещено. В CCPA идут от обратного по opt-out: данные собираются по умолчанию, но пользователь может отказаться от их продажи или передачи

➡️ Кто попадает под CCPA?
CCPA позволяет пользователям из US видеть информацию о себе, сохраненную вендором а также список third-party, с которыми платформа делится его данными. При этом интересно, что не все платформы подпадают под CCPA. Для этого нужно выполнить несколько условий
- годовая выручка >25M usd
- пользовательская база >50k
- >50% дохода генерится от персональных данных
SSP обрабатывают персональные данные (IDFA для Apple/ AAID для Android, cookies для вэб link) для таргетинга, и если попадают по критериям, то еще до кучи должны соблюдать CCPA

➡️ Что содержится в строке CCPA?
Разберем, что закодировано в consent string CCPA. Для примера возьмем 1YYN:
- 1: IAB spec version number
- Y: explicit notice to opt-out, были ли предоставлен notice и возможность opt-out. Если да, то запрещается установка новых cookie
- Y: opt-out sale, пользователь отказался от продажи своих данных
- N: является ли паблишер подписантом Limited Service Provider Agreement (LSPA)

➡️ Как реализуется в SSP?
На стороне SSP логика CCPA реализуется через consent string в запросе на ставку. Предварительно паблишер собирает согласие на сайте и генерит consent string. SSP получает ее через Prebid или в составе query param при вызове Google Pixel. Далее после получения consent string SSP вставляет его в строчку us_privacy в OpenRTB запрос для внутреннего аукциона

Что нужно знать о монетизации в рекламе? 💵

Все что вы хотели узнать, но боялись спросить про монетизацию инвентаря в программатике, теперь вы можете найти в канале Ad Cops. Его ведет AdOps менеджер Денис Рубежанский

Что вы найдете на канале?

Гайды и разборы кода адаптеров интеграций на Adfox и Prebid:
- Vibe-coding глазами AdOps специалиста. Как сделать обертку для Adfox с разными форматами и прикрутить поддержку Header Bidding?
- Разбираемся с баннерами по-умолчанию на Adfox: заглушки в РСЯ и сбор статистик adserver'ом
- Платный Adfox: почему, и что с этим делать?

Для AdOps специалистов, менеджеров по рекламным размещениям, специалистов по монетизации, менеджеров SSP регулярно размещаются вакансии (примеры раз, два, три)

В общем, рекомендую обратить внимание на Ad Cops. Хочется, чтобы такого контента в русскоязычном АдТехе было больше!

Как (не) положить сервер мониторинга, при большом количестве данных?

Одно время для мониторинга платформы мы использовали Graphite сервера. Все дашборды на Grafan'е, отображающие состояние SSP (бизнес метрики, сервисы, ML модели, инфра etc.) забирали данные с них. По мере роста продуктовых команд, каждая из них старалась отсылать все большее количество метрик. Это в итоге привело к тому, что CPU сервера стал перегружаться при частой обновлении дашбордов. Особенно это касается сложных запросов для бордов на Графане

➡️ В чем проблема?
На Graphite серверах данные закэшированы. Реализации кэшей страдали от отсутствия индексации метрик по времени, т.е. при запросе мы сканируем все файлы без указания временного интервала

Например, запрос

production.service.*.categories.*.count

- первый wildcard * : IP адрес интсанса
- второй * : категория, которая может принимать 100+ значений

Т.е. если есть 100 инстансов и 100 категорий, то мы получаем 10k путей метрик, которые будут накапливаться при частых обновлениях

➡️ Как решили?
Применили быстрое архивирование (fast archiving). Переносим пути неактивных метрик в архив после того, как они перестали отправляться от инстанса (например 24 часа). На дашборда отображаются только живые метрики. Как результат, теперь Graphite сервера могут справляться с большим количество запросов с пиковыми нагрузками

RAG Query expansion

Мы ранее рассматривали, как работает RAG. Сегодня поговорим про один из подходов к их улучшению

Query expansion (расширение запроса) - это техника улучшения ретривера в RAG-системах. Заключается в добавлении синонимов, связанных терминов и скрытых смыслов к исходному запросу

Как работает?
- На вход подаем запрос пользователя
- Просим LLM расширить запрос
- Либо напрямую, например Добавь к следующему запросу ключевые слова или синонимы, которые помогут найти больше информации: {query}
- Либо можем отдельно составить ключевые слова и соединить их с исходным запросом вручную: Приведи 5 ключевых слов или фраз, которые семантически связаны с запросом: {query}. Ответ выдай в виде списка через запятую.
- Далее проводим поиск чанков, как обычно

Пример:
- Исходный запрос: Лечение головной боли
- Расширенный запрос: Лечение головной боли, мигрень, анальгетики, таблетки от боли

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

Векторные БД. Бенчмарки

С популярностью RAG (и LLM в целом) свою популярность обрели и специализированные векторные БД.
Их используют для хранения векторных представлений (эмбнддингов) различных текстов. И в настоящее время их большое количество. Есть как отдельные приложения, так и дополнения к популярным "классическим" БД. Из наиболее известных: Qdrant, Milvus, Weaviate, Marqo, Lancedb etc.

Как выбрать?
На сайте представлена таблица векторных БД по предлагаемому функционалу, популярности и еще куче параметров. Здесь можно выбрать подходящую БД https://superlinked.com/vector-db-comparison

Еще есть бенчмарки по векторным БД, например https://ann-benchmarks.com/index.html

Есть еще бенчмарки от самих производителей векторных БД. Но относится к ним нужно с долей скептицизма:
- https://zilliz.com/vector-database-benchmark-tool
- https://qdrant.tech/benchmarks/

➡️ Внимание, программачи!

Дорогие друзья, презентую вам новый проект, который призван помочь стать рынку РТБ чуть ближе друг к другу!

Называется он OpenRTB Market и находится по адресу https://t.me/rtbexchange

Это канал, где трафик находит деманд, а люди находят деловых партнёров)

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

Для этого нужно всего лишь заполнить анкету: https://forms.yandex.ru/u/688901b202848f0432f5e97f

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

Подписывайтесь 👉 https://t.me/rtbexchange

RAG HyDE

Ранее мы рассматривали один из способов query expansion, как обогатить запрос в RAG систему и улучшить работу ретривер. Сегодня рассмотрим еще один простой способ Hypothetical Document Embeddings (HyDE)

Как работает?
- Получаем запрос пользователя
- Подаем его в LLM как есть и просим ответить на него как есть (без всякого контекста)
- Получаем ответ от LLM. Переводим его в вектор и уже по этому вектору ищем чанки
- Найденные чанки вместе с исходным запросом подаем в LLM для формирования финального ответа

Пример:

Запрос: Как работают квантовые компьютеры?

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

Как результат гипотетический ответ содержит больше контекста (более семантически насыщенный), чем исходный запрос, что улучшает качество поиска

💸 Хотите повысить прибыль бизнеса с помощью CPA-маркетинга?

CPA (Cost per Action) — это модель, где вы платите только за реальные действия вашей аудитории: покупки, регистрации или заполнения форм.

Подписавшись на CPAInform, вы получите:
💪 Тренды и стратегии CPA-маркетинга.
💪 Полезные материалы для оптимизации расходов.
💪 Советы по увеличению конверсии и дохода.

Не упустите возможность изучить эффективные методы продвижения и внедрить их в свой бизнес!

✅ Присоединяйтесь: CPAInform и станьте частью сообщества профессионалов.

CPAExchange_RegistrationBot– твоя возможность зарабатывать на арбитраже

❕Не упусти свою прибыль – подключайся прямо сейчас

Тюним гипер параметры для RAG

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

➡️ Чанки
Принимаем файлы, читаем их, разбиваем на чанки с помощью библиотеки langchain. Здесь мы можем управлять следующим
- sep: разделитель по которому мы будем шинковать файл
- chunk_size: размер чанков (в символах)
- chunk_overlap: с каким перехлестом будут делаться чанки

➡️ Bi-encoder
Конвертируем строку в вектор. Про bi-encoder важно понимать следующее
- Сколько текста он может обработать за раз, остальное будет отброшено. Если у вас длинные чанки или длинные вопросы, то вам, возможно, стоит подобрать bi-encoder с большей длиной контекста
- Какого размера вектора он возвращает. При прочих равных, чем больше длина вектора, тем больше информации в нем можно закодировать
- Также можно пробовать разные bi-encoder'ы и смотреть, какой из них лучше себя покажет

➡️ Векторная БД
Конвертируем переданные чанки в эмбеддинги и помещаем в БД, например Qdrant. При этом удаляем и вновь создаем коллекцию (аналог таблиц в реляционных БД), в которой складируем чанки. Последовательно перебираем файлы, каждый из которых делим на чанки и кладет в Qdrant

Здесь нужно обратить внимание:
- Коллекцию мы создаем такого же размера, какого размера вектора возвращает bi-encoder
- Вместе с вектором мы будем хранить сам чанк, из которого он сформирован и название файла, из которого он взят

➡️ Поиск векторов
Кодируем вопрос в вектор, далее ищем по косинусному расстоянию наиболее похожие вектора в Qdrant. Возвращаем содержимое чанков, привязанных к топ N отобранных векторов. Отсюда параметр
- n_top_cos: количество топ N отобранных векторов

➡️ LLM
Хотя LLM мы не дообучаем, но все равно можем тюнить инференс, используя следующие параметры
- max_new_tokens: максимальное количество токенов, которое будет сгенерировано LLM (не считая токены в промте)
- temperature: определяет насколько “творческим” будет ответ LLM. Чем выше значение, тем выше “творчество”
- top_k: ограничивает количество вариантов, которые модель рассматривает при генерации следующего токена

После того, как мы выделили эти параметры, то можем поручить задачу их оптимизации Optun'е

Для тех, кто в Москве. Камерная тусовка под названием «Programmatic Status» для adtech/programmatic-народа — без докладов, с живыми разговорами о закупках, оптимизации, атрибуции, антифроде и bid-стратегиях.

Когда: четверг, 18 сентября, 19:00
Где: бар «Проточный» — Проточный переулок, 2/1
Формат: напитки, нетворк, обсуждаются тренды

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

Регистрация и подробности: https://dmcrus.timepad.ru/event/3560268/

Google Ads AI Max

Google Ads представил новые метрики для отчетов по кампаниям AI Max, которые показывают трафик, приходящий от ключевых слов

Ранее рекламодатели могли только видеть, на какие целевые страницы заходили пользователи

Что за метрики?

Expanded matches: показывает трафик, генерируемый по ключевым словам с широким соответствием, которые AI Max создает на основе ключевых слов, предоставленных рекламодателем

Expanded landing pages: показывает трафик из поисковых запросов, которые совпали благодаря целевым страницам или ресурсам, работающим независимо от таргетинга по ключевым словам

Если у рекламодателя нет дополнительных фильтров или ограничений по таргетингу (например, задача сделать только охваты), то AI Max может привести к снижению контроля за РК и перекрутке бюджета

В чем проблема Last Click или why branding matters?

Рассмотрим модель атрибуции по last click. В ней, как источник конверсии учитывается площадка, с которой перешел пользователь, совершивший целевое действие. Если пользователь пришел по ссылке из контекстной рекламы, то будет считаться, что именно контекст помог привести клиента. Все логично!

Модель last click, хоть и широко используется, но имеет свои ограничения

➡️ Реклама в разных каналах
Допустим, что пользователь сначала видит рекламу продукта в TikTok, затем замечает вашу рекламу в поисковой выдаче и, наконец, переходит на сайт через ссылку на слоте в Web. В модели last click атрибуции будет приписано значение только по последнему каналу, т.е. Web. Однако другие каналы также сыграли свою роль в привлечении и убеждении пользователя. Их влияние будет недооценено, если ориентироваться только на last click

➡️Множество взаимодействий
Допустим, пользователь взаимодействует с рекламой на разных площадках и в разное время. Он видит рекламу на CTV, увидев ее идет с телефона в интернет, видит баннерку, затем по ссылке с поисковой выдачи переходит на сайт. В last click'е будет учтен только крайний клик, т.е. поисковый запрос. Все предшествующие показы и взаимодействия оказывают влияние на решение пользователся, продвигая его дальше по воронке, и важны для формирования его мнения о бренде

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

RAG troubleshoot

Что делать, если RAG начал галлюцинировать на проде? Как проверить, что сломалось: retriever или generator?

Отталкиваемся от ключевой идеи:

Качество RAG = Производительность Retriever'а × Производительность Generator'а

➡️ Метрики retrieval (достали ли мы правильный контекст?)
- Contextual Relevancy: какой процент полученных чанков действительно релевантен?
- Contextual Recall: достали ли мы всю необходимую информацию?
- Contextual Precision: ранжируются ли релевантные чанки выше нерелевантных?

➡️Метрики Generation (правильно ли LLM использует контекст?)
- Faithfulness: насколько вывод соответствует предоставленным фактам?
- Answer Relevancy: отвечает ли ответ на заданный вопрос?
- Кастомные метрики: следует ли ответ нужному формату или стилю?

➡️Далее проводим диагностику
- Высокий faithfulness + низкий relevancy: проблема в retrieval
- Низкий faithfulness + высокий relevancy: проблема в generation
- Обе метрики низкие: сломан весь пайплайн
- Обе метрики высокие, а RAG продолжает галлюцинировать: ищем edge-кейсы

В целом для отлавливания большинства проблем на проде хорошо подходит contextual recall. Retriever может находить релевантный контент, но упускать критические детали. Идеальная точность при нулевой полноте = уверенные, но неправильные ответы. Это и есть галлюцинации

RAG Multi-query

Продолжаем разбирать техники улучшения RAG. Сегодня рассмотрим Multi-query для повышения качества ретривера.

Когда пользователи пишут вопросы (в RAG) они часто допускают ошибки, пишут транслитом, путаются в формулировках и т.д. А это не хорошо для энкодера, и очень не хорошо для BM25 (и других компонентов ретривера). Multi-query позволяет это исправить за счёт разных формулировок одного и того же вопроса

Как это работает?
- Получаем исходный запрос
- Просим LLM написать несколько вариантов исходного запроса
- Выполняем поиск документов (чанков) по каждому из них (включая и исходный запрос)
- Результаты всех поисков объединяем или переаранжируем

Например: пользователь вводит: "Как испечь торт?". LLM на это может сгенерировать:
- "Рецепт торта"
- "Как приготовить торт в духовке?"
- "Ингредиенты для домашнего торта"

Такое разнообразие довольно сильно улучшит покрытие поисковой выдачи

Каждый арбитражник знает: оффер решает всё. Но как сделать так, чтобы именно ваш оффер выбрали веб-мастера?

Онлайн-вебинар CPAExchange: «Запуск оффера, который захотят веб-мастера» состоится 16 октября в 12:00😉

Разберём ключевые факторы успеха, ошибки при запуске и реальные инсайты из практики: https://clck.ru/3PHodA
Спикеры: Сухарникова Екатерина и Хохлова Александра

Когда правила аукциона не работают?

С 2020 года Минюст США ведёт дело против Google. Изначально его обвиняли только в монополизации рынка рекламы и сферы предустановленных приложений. После этого также выяснилось, что цены на рекламу в аукционах Search Ads Гугл искусственно завышались на 5%, а в отдельных вертикалях на 10%

В чем причина?
- Гугл владеет 85-90% search трафика и как монополист может устанавливать высокие барьеры для входа рекламодателей
- Низкая доля отклика рекламодателей

70 до 80% выручки Гугла делает рекламный рынок Google DV360 и Google Ads. Манипулируя ценами в обход аукциона, он в одиночку меняет весь рекламный бизнес, что вредит рынку и в моменте, и в перспективе

Что делать?
Инструмент для борьбы с монополистом это диверсифицировать DSP и перераспределить бюджеты, например между Amazon DSP, TTD etc. Могут быть проблемы с уровнем минимального бюджета и user tracking, но IMO прозрачный аукцион того стоит

Как скорость загрузки сайта влияет на монетизацию паблишера?

Сегодня мощность железа пользователей и скорость интернета позволяют не заморачиваться с технической оптимизацией сайта и не париться про то, что популярные библиотеки для фронтенда используют фреймворки. Это с одной стороны. С другой покрытие 5G далеко не повсеместное, в некоторых городах миллионниках может преобладать разве что 3G/ 4G

Как результат, тяжелые сайты на JS будут грузиться долго. Еще дольше будут отправляться запросы в Гугл, будет разрешаться аукцион, отработает задержка загрузки кода и показ рекламы. За это время пользователь уже успеет уйти с сайта. А паблишеры потеряют выручку от отсутствия возможности пользователя удержать

По теории, на это все должно уходить до 400 миллисекунд, но средний время – 3 секунды. То есть в 7,5 раз выше. Сайт грузится не мгновенно, а реклама – еще дольше, она появляется через 2–3 секунды после загрузки страницы

Google реагирует резко отрицательно. Его KPI 3 секунды в зоне видимости экрана, тогда показ засчитывается. А если пользователь увидел placement и проскроллил, пока реклама загрузилась, viewability – ноль. Площадка не получит денег, рекламодатель не получит просмотр

Как боротся с проблемой долгой загрузки страниц?
- В Гугле доступен формат AMP (Accelerated Mobile Pages). Это страницы, где минимум скриптов, по факту – сразу контент и реклама. Быстро грузится, viewability не теряется, очень высокий CPM и доход по сравнению со статичными сайтами. Реклама на AMP отрабатывает в 2–3 раза лучше

- Кроме того Гугл пессимизирует выдачу и доход с медленных сайтов. Для этого используется PageSpeed, который выдает сайту коэффициент относительно скорости его работы. И этот же коэффициент применяется на доход.  Если у паблишера по PageSpeed коэффициент 0,8, то доход на 100k монетизации с показов 80k

Что с рынком паблишеров?
Средние и малые паблишеры, которых большинство, работают через цепочку Prebid + GAM + SSP + DSP. Хотя Prebid удобен для паблишера, поскольку позволяет работать быстро, минус его в том, что 50-60% выручки оседает на платформах, и до паблишера доходит меньше половины

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