Реклама, дополнительные услуги и комиссионные — три наиболее распространенных метода получения прибыли интернет-компаниями. Среди этих трех классиков реклама занимает наибольшую долю рынка и является едва ли не самым важным каналом дохода для большинства интернет-платформ.Важность бизнеса очевидна.

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

Я в рекламном бизнесе с прошлого года, и вот уже почти год. В этой статье я объединим мой личный опыт и в то же время обращусь к отличным случаям в отрасли, чтобы объяснить план архитектурной практики рекламной системы и надеюсь, что каждый может что-то получить. Содержание включает в себя следующие 3 части:

Введение в рекламный бизнес
Технические проблемы, с которыми столкнулись
Подробное объяснение архитектуры рекламной системы

01 Введение в рекламный бизнес

Реклама вездесуща. WeChat, Douyin, Station B, Baidu, Taobao и т. д. — эти приложения, занимающие у пользователей больше всего времени, — повсюду видят тень рекламы.

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

1.1 В основе рекламного бизнеса лежит баланс

Почему ключевым моментом рекламного бизнеса является «баланс»? Это можно понять из стандартного определения рекламы.

Реклама определяется как средства, с помощью которых рекламодатели распространяют информацию о товарах или услугах среди пользователей через интернет-платформы на платной основе. Это определение включаетРекламодатели, платформы, пользователи3 субъекта, но интересы и заботы этих 3 субъектов различны.

Рекламодатели: Сосредоточьтесь на рентабельности инвестиций, могут ли траты денег принести ожидаемую пользу.
Платформа：Имейте трафик, обратите внимание на то, можно ли максимизировать доход
Пользователь: Обратите внимание на опыт, достаточно ли точна реклама? Влияет ли это на использование обычных функций?

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

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

1.2 Распознать сущность рекламы по формуле декомпозиции дохода

Рекламный бизнес развивался десятилетиями, и существует множество способов расчета платы за рекламу, наиболее распространенными из которых являются следующие:

CPT: Биллинг по времени, эксклюзивное местонахождение пакета времени пакета
CPM: Оплата за тысячу показов.
CPC: Оплата за клик
CPA: выставление счетов на основе поведения (например, загрузка, регистрация и т. д.)

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

Как видно из приведенного выше рисунка, поскольку CPA представляет собой окончательный эффект конверсии, которого хотят рекламодатели, рекламодателям наиболее выгодно рассчитываться в соответствии с CPA, но это наиболее неблагоприятно для платформы. Эволюция методов расчета до сегодняшнего дня на самом деле является своего рода балансом, поэтому CPM и CPC вблизи точки баланса являются наиболее распространенными методами расчета.

Взяв в качестве примера цену за клик, доход можно разложить по следующей формуле:

Среди них PV представляет собой количество посещений системы, PVR и ASN представляют скорость заполнения объявления, CTR представляет собой рейтинг кликов по объявлению, а ACP представляет собой среднюю цену клика по объявлению.

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

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

1.3 Основной бизнес-процесс рекламы

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

Для интернет-платформ на начальном этапе обычно используется "Самоуправляемая рекламная сеть аукциона«Для реализации монетизации бизнеса необходимо простое понимание: это использование собственного трафика платформы и самостоятельно разработанных рекламодателей для достижения замкнутого цикла бизнеса. Рекламная архитектура, описанная в этой статье, в основном нацелена на эту форму бизнеса, и ее основной бизнес-процесс показан на рисунке ниже.

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

Вышеупомянутое является основным процессом рекламного бизнеса. С дальнейшим увеличением трафика платформы и масштабов рекламодателей он имеет тенденцию постепенно развиваться от «самоуправляемой сети торгов» к «аффилированной рекламе и торгам в режиме реального времени в режиме реального времени». в Alimama и Tencent Broadcasting.Diantong, огромный двигатель Toutiao, в это время сложность бизнеса и техническая архитектура перейдут на более высокий уровень.Эта статья не будет расширять ее, и я поделюсь ею с вами позже.

02 Возникшие технические проблемы

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

1. Высокий параллелизм: рекламный движок подключен к трафику C-стороны, а объем запросов большой (в Pingfeng часто десятки тысяч запросов в секунду), требующий ответа в реальном времени, а результат должен быть возвращен в течение десятков миллисекунд.

2. Сложная бизнес-логика: запрос рекламы включает в себя сложные бизнес-процессы, такие как многоканальный отзыв, оценка модели алгоритма, ранжирование торгов и т. д., со многими стратегиями и длинными ссылками на выполнение.

3. Высокие требования к стабильности: рекламная система напрямую связана с доходом, а базовые системы, такие как рекламный движок и биллинговая платформа, предъявляют высокие требования к стабильности, а удобство использования должно соответствовать как минимум трем девяткам.

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

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

03 Подробное объяснение архитектуры рекламной системы

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

Выше приведена структурная схема текущей рекламной системы нашей компании.Эта структура подходит для начального этапа рекламного бизнеса.Она направлена на "самостоятельную торговую сеть и внутренний трафик" и не предполагает партнерской рекламы.

Далее описывается каждая подсистема:

Система доставки рекламы: Основные функции, которые могут использовать рекламодатели, включают продление членства, управление библиотекой рекламы, настройку условий продвижения, настройку рекламных ставок и проверку результатов доставки.
Фон рекламной операции: Он используется для работы продукта платформы.Основные функции включают управление рекламным пространством, управление рекламной стратегией и различные операционные инструменты.
Платформа поиска рекламы: выполнение большого количества одновременных запросов со стороны C и отвечает за отсеивание нескольких или десятков рекламных объявлений из огромной библиотеки объявлений. Требования к работе в реальном времени высоки. Эта платформа обычно состоит из нескольких микросервисов.
Экспериментальная платформа AB: Стабилизатор рекламного бизнеса, любая корректировка рекламной стратегии может быть проведена с помощью экспериментов в градациях серого через эту платформу, чтобы наблюдать за изменениями показателей доходов.
Рекламная биллинговая платформа: Для C-стороны, отвечающей за отчисления в реальном времени, напрямую связанные с доходом и высокой доступностью.
Центр управления учетными записями: Финансовая система в рекламном бизнесе, которая управляет бизнесом, связанным с суммой, включая пополнение, замораживание и вычет.
Платформа больших данных: шасси всей рекламной системы должно объединять различные разнородные источники данных, выполнять анализ данных и статистику в автономном режиме и в режиме реального времени, создавать бизнес-отчеты и создавать функции модели.

3.1 Хранение рекламных данных

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

Сценарии OLTP, включая рекламную библиотеку, творческую библиотеку, библиотеку членства, библиотеку рекламных продуктов, библиотеку рекламных стратегий и т. д., все хранятся в MySQL, а рекламная библиотека и творческая библиотека с большим объемом данных разделены на подбиблиотеки и таблицы в соответствии с к хэшу идентификатора рекламодателя .
Сценарии OLAP включают множество отчетов со многими измерениями агрегирования, а количество записей в одной таблице может достигать десятков миллиардов.Нижний уровень использует HDFS и HBase для хранения.
Данные индекса для сценариев поиска рекламы, включая прямой индекс и инвертированный индекс, хранятся с использованием Redis и ES.

Еще одна проблема, которую необходимо решить в хранилище, — это проблема синхронизации рекламных объявлений. После того, как реклама будет размещена, она сначала будет сохранена в базе данных MySQL, а затем реклама должна быть передана в поисковую систему в режиме реального времени для завершения обновления прямого индекса и инвертированного индекса.

Служба обновления индекса, есть несколько моментов, которые нужно объяснить:

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

3.2 Общий процесс платформы поиска рекламы

Платформа поиска рекламы отвечает за получение запросов трафика со стороны C, отфильтровывает наиболее подходящие первые N рекламных объявлений из массивной библиотеки объявлений и возвращает результаты в течение десятков миллисекунд.Это многоуровневый процесс проверки и сортировки.

Уровень отзыва фокусируется на модели алгоритма, а уровень поиска — на бизнесе. Снизу вверх вычислительная сложность увеличивается слой за слоем, а набор кандидатов уменьшается слой за слоем. (Примечание: существуют различия в некоторых подмодулях между рекламной сценой поиска и рекомендуемой рекламной сценой, но общий процесс в основном одинаков и не будет здесь подробно останавливаться)

Дизайн производительности находится в центре внимания поисковой платформы, обычно со следующими средствами:

Хорошо поработайте над многоуровневым сервисом, и каждый уровень можно расширить по горизонтали.
Кэш Redis используется для предотвращения прямого попадания большого количества одновременных запросов в базу данных.Кэш может быть разделен на несколько наборов в соответствии с бизнес-планированием.
Используйте многопоточность для распараллеливания некоторых подпроцессов, таких как логика многостороннего отзыва и логика оценки нескольких моделей.
Данные точки доступа кэшируются локально, например информация о конфигурации рекламного места и информация о конфигурации политики, которые можно предварительно загрузить локально при запуске службы, а затем регулярно синхронизировать.
Второстепенные процессы устанавливают тайм-ауты для объединения и деградации логики, например стратегии премиум-класса (отсутствие премиум-класса просто приносит меньше денег и не влияет на запоминаемость рекламы).
Логика, не связанная с основным процессом, выполняется асинхронно, например, кэширование информации о дедукции, кэширование результатов отзыва и т. д.
Упростите структуру результатов возврата RPC или объектов кэша Redis, удалите ненужные поля и уменьшите размер пакетов ввода-вывода.
Оптимизация сборщика мусора, включая настройки памяти кучи JVM, выбор сборщика мусора, оптимизацию частоты сборщика мусора и оптимизацию сборщика мусора по времени.

3.3 Техническое решение биллинговой платформы

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

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

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

Во-первых, весь процесс вывода обрабатывается асинхронно.После получения запроса на вывод в реальном времени система сначала кэширует информацию, используемую при выводе, в Redis, а затем отправляет сообщение MQ.После выполнения этих двух шагов вывод завершается. . . .

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

Чтобы повысить доступность, применяется схема понижения версии как для Redis, так и для ситуаций недоступности MQ. Когда Redis недоступен, переключитесь на TiKV для обеспечения устойчивости; при сбое доставки MQ перейдите на асинхронную обработку пула потоков.

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

3.4 Техническое решение для массива данных OLAP

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

слой исходных данных: Соответствует различным исходным данным, включая внешние и внутренние журналы, собранные в режиме реального времени в HDFS, и таблицы бизнес-данных MySQL, которые инкрементно или полностью синхронизируются.
Уровень хранилища данных: Содержит таблицы измерений и таблицы фактов, обычно таблицы данных после очистки исходных данных, такие как таблицы журналов поведения, таблицы продвижения и таблицы пользователей.
Уровень витрины данных: краткая сводная таблица данных, такая как таблица рекламных эффектов, полная таблица ссылок на поведение пользователей, таблица анализа групп пользователей и т. д.
Уровень приложения данных: таблицы данных, непосредственно используемые сценариями приложений верхнего уровня, включая различные отчеты о доходах, созданные с помощью многомерного анализа, функции модели алгоритма и портретные данные, созданные задачами Spark, и т. д.

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

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

Эта часть поддерживается отделом больших данных компании и использует техническое решение с открытым исходным кодом.Оффлайн-часть использует Kylin, а данные хранятся в HBase; часть в реальном времени использует Flink и Spark Streaming, а данные хранятся в Друид.

напиши в конце

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

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

Об авторе: Мастер 985, бывший инженер Amazon, ныне технический директор 58 Zhuanzhuan.

Добро пожаловать, чтобы обратить внимание на мой личный публичный аккаунт: карьерный рост айтишников, замечательная оригинальность постоянно!