Про управление в командах

Хочу разобрать понятие недирективного управления и порассуждать, насколько оно применимо в работе с командами разработчиков.

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

Но с другой стороны директивный стиль лучшего всего показывает себя в ситуациях:
- горящих дедлайнов, когда нет времени мусолить альтернативные идеи, надо делать 🔥
- на заводе, когда есть четкий тех. процесс и меры техники безопасности 🏭
- в работе с junior-коллегами и стажерами. Чтобы неопределенность в сложных задачах их не демотивировала, мы даем точные понятные инструкции и такой же фидбек
- в случае инцидентов/ критических ситуациях, когда на кону стоят миллионы денег, и нужно принимать решения быстро

Зачем тогда нужно недирективное управления?
Оно нужно, когда мы хотим построить более автономную команду, способную действовать в условиях неопределенности и принимать собственные решения. Здесь вместо того, чтобы давать инструкции сотрудника, мы поощряем инициативу и личную ответственность и даем свободу в принятии решений на его уровне (например выбор фреймворков, design паттернов, оценку сроков задач, взаимодействие со смежниками etc.)

Вроде бы все просто. Что может пойти не так? 🤔
- Отсутствие мотивации у сотрудника: сколько волка не корми, он все равно в лес смотрит. Здесь особо ничего не сделаешь 🤷‍♂️
- Наличие/ отсутствие безопасной среды: инициатива должна правильно восприниматься менеджерами без херни и токсичности. С другой стороны есть инициативы, а есть приоритеты команды на квартал, и поскольку ресурсы команды ограничены, ими нужно распоряжаться разумно
- Фокус на сотруднике: менеджер должен понимать, как сотрудник видит свое личное развитие, и задавая правильные вопросы, направлять его на благо команды
- Обоюдная готовность к переменам: изменения состава/ направления работы команды требуют сил и времени, и не все к этому могут быть готовы

Attention is all you need 🧐

Сегодня поговорим про Attention, только не тот, что в трансформерах (архитектуры сеток мы обсудим в следующих статьях).

Речь пойдет про метрику внимания в рекламе. Пару лет назад программатик открутчиками и трейдерами было выявлено, что метрики конверсий (CPA, qualified visit, доля конверсий) коррелирует с длительностью просмотра рекламного слота. Тогда же выяснилось, что если для видео оптимизировтаь только view-through-rate, то 70% от всех viewable ads уходят в пустоту, и за ними не следует ни досмотров, ни кликов, ни конверсий

➡️ Отсюда и зародилась концепция "борьбы за внимание" пользователя.
- Ввели метрику под названием Attentive seconds per mille impressions (APM), или количество секунд просмотра на тысячу показов. Далее выявлено, что APM обратно скоррелирована с метриками перформанса CPA, CPC.
- Вдобавок к времени просмотра также ввели cost per mille attentive impressions (aCPM), т.е. косты на тысячу показов, время просмотра, которых не ниже определенного порога, например в 3 секунды

➡️ Зная эти метрики можно поступить двумя способами
- Разбить трафик на бакеты с высоким, средним и низким aCPM, и если цель кампании CPA, то закупать только трафик из нижнего бакета aCPM и высоким временем просмотра
- Аналогично можно поступить и на таргетинге пользователей, доставляя показы только до сегментов IAB с высоким APM
- Зная APM и aCPM, их можно добавить в АБТесты креативов. Поскольку мы находимся на post-impression, привлекательность и цепкость креатива здесь играет важную роль

➡️ Как измерять attention?
- Самый простой способ - это замерить время, когда пиксель слота, трекаемый адсервером GAM или Яндекс Метрикой находится во view-порте устройства пользователя. Достаточно просто реализовать для Desktop'а и мобилок, но точно не сработает для DOOH и CTV. К слову именно на CTV достигаются самые высокие доли досмотров CVTR
- Можно поступить чуть хитрее и измерять время пролета мышки над слотом. Проблема здесь та же, что и в предыдущем пункте: нигде кроме desktop'а это не реализовать
- В британской компании Lumen пошли еще дальше и начали трекать взгляд пользователя на экран. В результате строится тепловая карта просмотра слота в разные моменты времени, откуда и замеряются метрики внимания. Ясное дело, заставить всех пользователей дать согласие на eye-tracking не получится, используют тестовые группы из пары сотен/тысяч пользователей, которые за денюжку соглашаются установить eye-tracking приложение, с которого 24/7 собираются тепловые карты просмотров слотов

В целом подход к оптимизации метрик внимания помогает снизить CPA и повысить конверсии, и потому является неплохой прокси метрикой для перформанса

Я подготовил новую хабр статью. На этот раз про виртуальную рекламу в спортивных видео. Здесь вы найдете примеры форматов рекламы в индустрии спорта и демку на OpenCV с детектированием ключевых точек (ранее про задачу я также писал), в которой разместил баннер Адидаса в видео

Как оптимизировать CPA?

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

➡️ Избавляйтесь от ботового трафика и MFA, поскольку они первыми блэклистятся основными DSP и Google Ads

➡️ Используйте везде, где возможно, server-side логирование ивентов. Это касается всех ивентов пользователя, conversion paths, time-to-conversion etc. В противном случае будете терять до 30% данных о пользователе. Это значит, что вам нужен собственный пиксель на странице паблишера или свои first-party cookie

➡️ Также проблемой может быть то, что агенство/ реселлер не умеет различать новых и вернувшихся клиентов. Для алгоритмов DSP это имеет значение. Вводите сквозной user_id для корректного отслеживания пользователя

➡️ Отслеживайте пользователей с разными устройствами. Так показ клиенту может быть залогирован на мобиле, а покупка на десктопе. Вы должны объединять профили этого клиента и отправлять полные данные в DSP

➡️ Принимайте во внимание ускоренное выгорание креативов. Раньше можно было крутить АБ тесты над креативами по 2-3 недели. Сейчас этот срок ужимается до 5-7 дней, после чего креатив выгорает. Решением может быть ускорять итерации АБ тестов, запускать до десятка активных вариантов креативов. В совокупности это поможет снизить CPA на треть

Касательно полезностей в работе с CPA хочу порекомендовать канал CPAInform 💵

Что вы найдете
- На какие вертикали нужно заливать трафик в 2025 году, чтобы быть в плюсе?
- Топ-5 Gen AI сеток для обработки креативов и голоса, подписки на которые не загонят вас в долги
- Влияние налога на рекламу и инфляции на CPA и CPC в недвижимости, ecomm'е, фарме etc.

Кроме того, получать инсайты по офферам и взаимодействовать с партнеркой можно через бота. CPAExchange_RegistrationBot – ваша возможность зарабатывать на арбитраже!

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

Сделал подборку туториалов по промпт инжинирингу для LLM:

Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial

OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api

Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf

Материалы на русском
https://www.promptingguide.ai/ru

Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.

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

Bid Cap, или как связать CPM и CPA в одной формуле? 💵

У каждого объявления есть общая ценность за целевое действие (допустим в случаю с CPA за конверсию). Назовем ее bid_per_action. Умножив эту ценность на estimated_action_rate частоту целевых действий при условии показа (поскольку DSP списывает с нас деньги за показ), то получим следующую формулу

bid_per_impression = bid_per_action x estimated_action_rate

Мы ограничиваем bid_per_action , когда устанавливаем bid cap. Для будущей открутки estimated_action_rate мы можем оценить, как p(conversion | features) вероятность конверсии для текущего показа, за который идет борьба в аукционе при условии признаков исторической эффективности слота, аудитории, контекста etc. p(conversion | features) может предсказываться для каждого слота классической бинарной ML-моделью.

estimated_action_rate = p(conversion | features)

Ставку за показ мы можем связать с CPM достаточно просто

CPM = bid_per_impression x 1000

В результате получим

bid_cap = CPM / (1000 x p(conversion | features))

Альтернативно, если оценить вероятность конверсии при условии показа напрямую мы не можем, то вместо этого воспользуемся цепочкой показ -> клики -> конверсия и запишем в формулу CTR (клики при условии показа) и CR (конверсия при условии клика), залогированные в DSP (или таргеты РК)

estimated_action_rate = CTR x CR

Тогда bid cap пересчитается следующим образом

bid_cap = CPM / (1000 x CTR x CR)

Пример:
Рассмотрим гео с CPM $15, и РК с таргетами CTR 3% и CR 2%. Посчитаем bid cap

bid cap = $15 / (1000 x 0.03 x 0.02) = $25

Т.е. с такой максимальной ставкой мы сможем себе обеспечить необходимые таргеты CTR, CR. Мы выставили bid cap, исходя из цены конверсии. Если в процессе открутки РК начинает задирать вверх наблюдаемый дневной CPM, то умеряем аппетит и постепенно снижаем bid cap с шагом, например 10%

Давненько у нас не было инфографики.

Здесь собраны основные директории файловой системы Linux с коротким описанием. Сохраняем себе!

Привет! Сегодня стрим в 21:15 мск

https://youtube.com/live/E_0V6CApFq4?feature=share

Жмите Notify чтобы не пропустить

В гостях Evgenii Munin, автор канала @dsinsights

В выпуске поговорим об архитектуре рекламных платформ ставок (RTB — Real-Time Bidding), включая программматик-цепочки, ML Pipeline, Data Pipeline и механизм формирования ставок (Bidder). Евгений расскажет о фильтрации трафика, динамическом ценообразовании и оптимизации резервной цены аукциона. Также будут рассмотрены практические подходы к построению высоконагруженных систем в сфере AdTech.

Ключевые слова: Программматик-реклама,SSP (Supply Side Platform),DSP (Demand Side Platform),Ad Server,ML Pipeline,Обучение моделей,Фильтрация трафика,Динамическое ценообразование,ONNX Runtime,Биддер,Резервная цена (floor price), Data Pipeline, Kafka,S3, BigQuery, Flink, Traffic Shaping, Оптимизация маржинальности, Аукцион ставок (RTB), Потоковая обработка данных

Мы провели стрим с FaangTalk

Вышло классно, я сделал многовато материала по ML части, но зато дальше хорошо обсудили Кафку, кэширование и хранилища данных. Спасибо всем, кто был на стриме 🥰

Хочу отдельно поблагодарить ребят:

Ника @analytics_engineer ⬅️
Рекомендую его канал по Data Engineering'у и DE практикам в крупных компаниях. Также здесь проводятся митапы по dbt

Диму @faangtalk @javaswag ⬅️
Всем, кто готовится или планирует готовиться к собесам по литкоду, System Design в FAANG и не только, нужно в этот чат и в одноименный канал на ютубе

Предсказываем клики по данным Criteo

10 лет назад на Каггле проводилось соревнование по предсказанию кликов на рекламные слоты на сайтах пользователей на мобилках, организованное Criteo. С того момента прошло много времени, но датасет не утратил своей актуальности в среде адтеха и до сих пор служит бенчмарком для сравнения ML моделей, пресказывающих клики. Актуальный лидерборд архитектур можно найти на PapersWithCode

И сегодня мы разбирем одну из таких SOTA архитектур предсказания кликов FinalMLP

Что с данными?
Для начала разберемся, какие данные доступны для обучения. Criteo опубликовала данные с 7 дней трафика своих пользователей mobile web. Это примерно 340Gb данных. Все фичи поделены на 2 категории: пользовательские (user) и контекстные (publisher, инфа о сайте). Значения всех фичей анонимизированы. И собственно бинарный таргет о наличии/ отсутствии клика на рекламный слот.

Как работает?
Как заявлено в статье на Arxiv, архитектура FinalMLP состоит из следующих основных компонент

➡️ Feature Embedding Layer
Преобразуем разреженные признаки в плотный (dense) вектора. Категориальные признаки one-hot encod'им и перемножаем на обучаемую матрицу весов эмбеддингов. Числовые фичи бакетизируем и дальше обрабатываем, как категориальные. Multi-valued фичи (или те же списки, типа adomain) обрабатываем следующим образом: обрезаем списки длиной до средней длины k. Далее заводим эти фичи в one-hot вектора длины k и снова перемножаем на веса эмбеддинга.

➡️ Feature Selection Layer
Слой отбора признаков: оценивает важность признаков, понижает влияние зашумленных, усиливает значимые. Здесь используется т.н. gating-based feature selection, который выдает веса важности каждого признака, пропустив их через сигмоиду и умножив на 2. В итоге эти веса лежат в диапазоне 0..2. Далее они перемножаются с эмбеддингами фичей. Разбиваем фичи на 2 ветки на пользовательские и контекстные и прогоняем весь процесс отдельно на каждую ветку. Так мы получаем входы в MLP (персептрон) два потока.

➡️ Stream-Level Fusion Layer
Теперь нам нужно объединить эти 2 потока (пользовательский и контекстный). Вместо простого сложения или конкатенации в FinalMLP предлагают т.н. bilinear fusion. Если в двух слова, как это работает, то вектора с 2х веток пользовательских и контекстиных эмбеддингов разбиваются на k частей (голов). В каждой части применяется билинейное преоблазование. Далее результаты пропускаются через сигмоиду, чтобы получить вероятности.

Билинейное преобразование для одной головы записывается следующим образом

BF(o1, o2) = b + w1 * o1 + w2 * o + o1 * W3 * o2

Здесь
- w1, w2 - это веса модели для ветки o1, o2 соответственно
- W3 - это матрица билинейного преобразования (тоже обучаемая)
- b - intersect

Для k голов выходная вероятность запишется

proba_pred = sigma(sum_k(BF(o1i, o2i)))

Такой подход обработки признаков на два потока дает следующие преимущества по сравнению с классической табличной моделью, например тем же CatBoost'ом:
- Взаимодействие фичей задается с помощью отдельной матрицы W3, что дает возможность обучать более сложные зависимости
- В FinalMLP мы конвертируем все фичи в эмбеддинги, что особенно помогает в случае разреженных фичей

Далее мы разберем имплементацию FinalMLP на PyTorch и запустим ее с помощью либы FuxiCTR

Как размечать данные для промышленных ML моделей правильно?

Зачем это надо?
В индустрии существует такая парадигма Data-Centric AI. Ее в свое время сформулировал великий Andrew Ng. Она гласит, что важна не гонка за сложными моделями, а системная работа с данными. Т.е. большинство ошибок моделей происходит из-за некачественных, грязных данных. Не забываем правило: garbage in — garbage out.

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

➡️В чем проблема разметки данных в промышленном масштабе?
- Плавающие инструкции: инструкция живёт в голове у тимлида, меняется в процессе, а команда может размечать по старой. В результате имеем в одном датасете — разные логики.
- Отсутствие версионирования: не фиксируется, кто, когда и по какой логике размечал. При проверке сложно понять: ошибка ли это или просто старая версия правила.
- Отсутствие описания пограничных случаев: инструкция охватывает только «идеальные» примеры. Разметчики по-разному трактуют сложные случаи → низкое согласие между ними.
- Отсутствие обратной связи: разметчик не знает, что он ошибается. Ошибки повторяются, система не обучается.
- Один разметчик — один мир: без перекрёстной проверки (двое размечают одно и то же) невозможно отследить согласие.
- Отсутствие контрольных примеров (golden set): Без заранее проверенного набора эталонных аннотаций невозможно оценить качество работы всей команды.
- Человеческий фактор: усталость, выгорание, желание «быстрее сдать». Если не учитывать мотивацию и рутину, качество страдает даже у отличных специалистов.

➡️ Настраиваем процесс разметки, начиная с коммуникаций
Четко ставим задачу и делаем пошаговый онбординг для разметчиков. Проходимся ручками по калибровочным задачам. Также наладиживаем канал обратной связи: куда задавать вопросы, как быстро получать ответы.

➡️ Валидация разметки
Проверка — обязательный этап, организовать ее можно следующим способами:
- Peer review: один разметчик проверяет другого
- Экспертная проверка: отдельный специалист валидирует выборку
- Перекрёстная аннотация: две разметки сравниваются, рассчитывается согласие (Cohen's Kappa)
- Модельный консенсус: если есть обученная модель, используйте её для нахождения расхождений.

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

➡️ Версионирование инструкций
Поступаем аналогично, как если мы версионируем код в гите. Новые/ правленные инструкции ревьюим. Обязательно указываем, какая версия применялась при разметке конкретной партии данных. Если в процессе возникали спорные кейсы — добавляем их в инструкцию с пометкой «обновлено».

➡️ Контроль и метрики
Управлять можно только тем, что измеряется. Метрики помогают выявить слабые места и улучшить процесс:
- Согласие между аннотаторами (Inter-Annotator Agreement)
- Процент правок после валидации
- Скорость + качество: лучше жертвовать скоростью ради стабильности
- Количество уточнений по инструкции: если их много, нужно менять инструкцию

➡️Автоматизация процесса
- Предразметка моделью: человек проверяет вместо разметки с нуля
- Автопроверки на лету: например, логические правила: «если выбрано А, поле B не может быть пустым»
- Интеграция с тулзами: Label Studio, Prodigy, doccano позволяют встроить автоматическую проверку и экспорт / импорт в пайплайн
- Контроль качества через скрипты: сравнение с эталонными разметками, метрики качества, алерты на резкое падение согласия.

Как подготовить ТЗ для разработчика? 🗂

Хотя я официально не числюсь на позиции менеджера, мне периодически приходится привлекать коллег-разработчиков на проекты, которые я веду или фичи, которые находятся в периметре моей ответственности, например алгоритмы для паблишеров, Header Bidding, фильтрация трафика и с некоторого времени алгоритмы ставок для YouTube'а.

При этом если человеку попробовать сумбурно накидать идей off top of my head, то запросто можно получить кота в мешке и впоследствии дружно плясать с бубном, объясняя менеджерам, как работает продукт. Чтобы этого избежать, готовим ТЗ. Сейчас расскажу, как.

1️⃣ Даем контекст. Почему возникла потребность в фиче, какие боли мы решаем. Упоминаем контекст, и что идет не так на данный момент. Например, хотим повысить долю in-view для формата shorts'ов и infeed для видео рекламы на YouTube. Делаем это, поскольку досмотры на этих форматах не оптимизируешь (они максимум 2%), а дать возможность заводить РК под эти форматы нужно. Для этого хотим по умному рулить ставкой, чтобы выдать высокий view-through rate и при этом не срезать трафик показов и открученный таргет по бюджету.

2️⃣Определяем клиентов, которые будут пользоваться фичей. Кто они и где обитают. Например бренды-рекламодатели, которые хотят повысить brand-awareness и заводят РК через Google DV360 под трафик ютуба.

3️⃣ Описываем сценарии использования (user flow). Здесь всегда хочется впихнуть невпихуемое, но вместо этого определяем базовые сценарии - без которых продукт попросту не имеет смысла. Желаемые вещи - их хорошо бы иметь, но можно допилить после релиза. Например клиент заводит РК в интерфейсе DSP и ставит галку напротив поля autobidding. На нашей стороне мы эту настройку читаем по API DSP и запускаем алгоритм на данного клиента.

4️⃣ Фиксируем основной стек. Фреймворки, тулзы, языки программирования, OLAP vs OLTP базы etc. Здесь все достаточно понятно, используем тот стек, который наша команда умеет поддерживать и знает практики.

5️⃣ Описываем зависимости. Вероятнее всего ваш продукт будет крутиться не в вакууме, и нужно будет тянуть часть данных из корпоративной базы, метрики из DSP, залогировать дополнительный ивент в очереди. Для всего этого прикладываем нужные API и схемы к ТЗ.

6️⃣ Делаем макеты. Не чураемся использовать Jupyter Notebook и расписать, как алгоритм будет работать на примере семплированных или синтетических данных. Прикладываем нужные графики в ТЗ.

7️⃣ Поясняем Definition of Done. Какие критерии сделанной работы? Мы запускаем джобу на Airflow? Или мы релизим сборку в Container Registry? Как мы будем рулить релизом и запуском РК клиентов?

8️⃣ Делаем чек-лист для приема работы. На каких сценариях, РК, бюджетах мы прогоним продукт перед тем, как сказать, что он работает хорошо. Какие бизнес метрики будем мониторить, например VTR, budget spent, показы, CPM, CPV.

Объединяя вместе все вышеперечисленные разделы, у нас получится мощное ТЗ, от которого менеджеры будут в восторге, а от исполнителей вам будет респект и уважение.

Как настроить DataLake с медальной архитектурой данных на платформе ставок?

Стандартный способ построения DataLake в компании — это использование медальной архитектуры, при которой данные трансформируются по этапам.

1️⃣ Из каких этапов состоит медальон?

- 🥉Bronze : логируем данные as-is на выходе с очередей, БД, внешних запросов по API (Salesforce, DMP etc.)
- 🥈Silver : сырые логи вычищаются. Удаляем дубликаты, аукционы с отсутсвующим auction_id, невалидные реквесты
- 🥇Gold : аггрегируем данные Spark джобами (groupby user, country, campaign, publisher etc.), подготавливаем для записи в витрины


2️⃣Где могут возникнуть проблемы?

- Gold слой хаотичен и непригоден для общего пользования. В компании могут быть десятки команд, которые считают одни и те же вещи разными метриками и по разному их трактуют. Например, определение eCPM для supply/ demand команд разное. Или могут присутствовать два разных расчета относительной маржи (revenue - cost) / cost и (revenue - cost) / revenue в бухгалтерии и на платформе. Эти вещи наводят путаницу в использовании Gold слоя

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

- Мнение о том, что gold - "лучше", чем silver, а он "лучше", чем bronze. Здесь может дойти до того, что события или отдельные датасеты копируются по слоям потому, что дашборды аналитики разрешено строить только по gold слою

- Ownership. Кто управляет и поддерживает каждый слой?


3️⃣А как надо?

- Bronze: отвечает за запись данных. Схема данных соответствует источнику (очереди, API etc.). Данные партицируются по времени. Пишем либо в S3, либо в Snowflake, поскольку в нем можно создавать таблицы на основе сырых данных без необходимости делать дополнительную копию.

- Silver: Очищаем данные, делаем join'ы. Если есть вложенные полуструктурированные данные, то делаем их плоскими (explode). При этом сюда НЕ заводим бизнес-логику, а оставляем ее для следующего этапа. За этот и предыдущий этап отвечает, как правило, DE команда, которая поддерживает в том числе и стриминговую запись в bronze.

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

Почему я перестал читать AdExchanger?

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

Но сейчас от избытка новостных ресурсов можно запросто словить FOMO (удачи пересмотреть весь AdExchanger, AdWeek, AdMonsters, Business Insider etc). А статьям, написаным адтех журналистами, как правило, не хватает остроты и персонального взгляда.

Поэтому, уже на протяжении года за новостями я иду в канал Ивана AdTech: персональное мнение и НеAdfox. Здесь несколько раз в неделю я читаю подборки из топ 3..5 новостей индустрии. Самое главное с авторскими заключениями и оценкой импакта той или иной фичи для всех стейкхолдеров: паблишеров, SSP/DSP, рекламодателей, пользователей.

Обсуждается все
- новые полезные и не очень AI фичи адтеха
- борьба паблишеров с монополией поисковиков на трафик
- скандалы, интриги, расследования среди walled gardens, M&A, и как на них влияет идущая рецессия

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