Опубликовано: 07.05.2026 | Источник: The Verge (IT)

Анализ цифровой рекламы для ВКР: как технически оценить влияние регуляторов на архитектуру ad-tech систем

Федеральная торговая комиссия (FTC) США и восемь штатов инициировали судебное разбирательство против крупных рекламных агентств, обвиняя их в нарушении антимонопольного законодательства через координацию «правил безопасности бренда» — в частности, через GARM. Это не просто политический скандал: технически он затрагивает архитектуру систем таргетинга, фильтрации контента и принятия решений в real-time bidding (RTB). Для студентов, пишущих ВКР в сфере Data Engineering или Системного анализа, этот кейс — готовая основа для анализа влияния внешних факторов на технические решения. Вы научитесь моделировать, как юридические ограничения трансформируются в требования к системам обработки данных, и сможете защитить работу с аргументами из реального мира.

Основная часть: как использовать кейс FTC в дипломе по Data Engineering

Этот случай — не просто новость. Это реальный триггер изменений в архитектуре цифровых рекламных платформ. Раньше агентства могли использовать единые правила фильтрации контента (например, через GARM), чтобы автоматически исключать сайты с «рискованным» контентом. Теперь FTC требует прекратить координацию — и это вынуждает платформы пересматривать логику обработки данных и принятия решений.

1. Интеграция в Главу 1: анализ существующих решений

В первой главе вы не просто описываете, как работают ad-tech платформы. Вы показываете, как внешние факторы влияют на архитектурные решения. Это повышает научную ценность работы.

Пример структуры:

• Обзор экосистемы digital advertising: DSP, SSP, Ad Exchange, DMP
• Анализ механизмов brand safety: черные списки, контент-анализ, репутационные метрики
• Роль GARM и других коалиций в стандартизации фильтрации
• Правовые риски централизованного принятия решений (на примере FTC)

Используйте C4-модель для визуализации:

Контекст (C1):
[Рекламодатель] --(RTB-аукцион)--> [Ad Exchange]
[Ad Exchange] --(показ)--> [Пользователь на сайте X]
[Агентства] --(согласованные правила)--> [GARM] --(рекомендации)--> [Фильтры в DSP]

Контейнеры (C2):
- DSP (Demand-Side Platform): принимает решения о ставках
- SSP (Supply-Side Platform): предлагает инвентарь
- DMP: хранит и анализирует данные о пользователях
- Сервис фильтрации brand safety: оценивает контент страницы

2. Проектирование в Главе 2: архитектура без централизованных правил

Если агентства больше не могут координировать правила, каждая платформа должна самостоятельно оценивать риски. Это меняет архитектуру данных.

Ваша задача — предложить решение, где:

• Фильтрация контента происходит на уровне DSP
• Используются ML-модели для классификации контента (без опоры на внешние списки)
• Система гибкая: правила можно менять под политику конкретного рекламодателя

Пример архитектуры:

[Источник данных: веб-скрейпинг] 
       ↓
[Очередь сообщений: Kafka] 
       ↓
[ML-сервис: анализ текста/изображений] → (оценка риска: 0–1)
       ↓
[База репутации доменов: Redis + PostgreSQL]
       ↓
[DSP: принимает решение о ставке с учётом risk_score]

Для оценки качества используйте метрики по ISO/IEC 25010:

Атрибут качества	Метрика	Как измерить
Функциональная полнота	Доля оценённых доменов	Кол-во проанализированных / общее кол-во
Точность	F1-score модели	На валидационной выборке
Производительность	Latency обработки страницы	OpenTelemetry + Grafana
Безопасность	Наличие OWASP ASVS	Аудит API сервисов

3. Реализация и тестирование в Главе 3

В третьей главе вы не просто запускаете систему. Вы доказываете её эффективность и соответствие требованиям регуляторов.

Пример задач:

• Собрать датасет из 1000 URL с разметкой (риск / безопасно)
• Обучить модель на BERT-подобной архитектуре (например, DistilBERT)
• Замерить TPS (транзакций в секунду) при обработке 1000 страниц/сек
• Сравнить эффективность с подходом на основе GARM-списков

Пример кода для оценки риска:

from transformers import pipeline

# Загрузка предобученной модели
classifier = pipeline("text-classification", model="distilbert-base-uncased-finetuned-sst-2-english")

def assess_risk(text: str) -> float:
    result = classifier(text[:512])  # Ограничение модели
    label = result[0]['label']
    score = result[0]['score']
    return score if label == "NEGATIVE" else (1 - score)

Используйте OpenTelemetry для сбора метрик:

# В коде сервиса
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.prometheus import PrometheusSpanExporter

# Запуск экспорта метрик для Grafana

Темы для ВКР на основе кейса

Чему вы научитесь

• Проектировать data pipelines с учётом правовых ограничений
• Строить C4-диаграммы для ad-tech систем
• Оценивать качество ML-моделей по метрикам ISO/IEC 25010
• Оформлять технические требования по ГОСТ 34.19
• Интегрировать OpenTelemetry для мониторинга производительности

FAQ

Какой стек выбрать для реализации?

Для data pipeline — Python + Kafka + PostgreSQL. Для ML — Hugging Face Transformers. Для мониторинга — OpenTelemetry + Prometheus + Grafana. Это промышленный стек, применимый в реальных проектах.

Сколько кода должно быть в приложении?

Достаточно 300–500 строк ключевого кода: обработка текста, модель, API. Остальное — конфиги, тесты, скрипты. Главное — чтобы код был работоспособным и воспроизводимым (лучше с Dockerfile).

Как считать эффективность, если нет доступа к реальным данным?

Используйте публичные датасеты: Common Crawl, Kaggle (например, «Toxic Comment Classification»). Смоделируйте сценарий: 1000 URL, оцените precision/recall. Этого достаточно для ВКР.

Как оформить схемы по ГОСТ?

Для UML/C4 — используйте PlantUML или draw.io. Сохраните в PNG/PDF. Подпишите: «Рисунок 2.1 — C4-модель ad-tech платформы». Шрифт — Times New Roman, размер 12, подрисуночный текст — курсив.

Источник: FTC pushes ad agencies into dropping brand safety rules (опубликовано 2026-04-15)