(Исходный контент Ma Honeycomb Technology, общедоступный идентификатор: mfwtech)

введение

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

От «318 Big Promotion» в 2014 году до продолжающегося «Mafengwo Double 11 Global Travel Bee Festival» масштабная реклама туристического бизнеса электронной коммерции Mafengwo прошла через 5 лет, только для Double 11, Summer Holidays и Eleven Gold There. более 50 рекламных акций S-уровня в ключевых узлах, таких как выходные и конец года, и ежегодно проводятся сотни онлайн-мероприятий.

Фото: Mafengwo 11.11 Global Travel Bee Grab Festival

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

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

1. Архитектура маркетинговой платформы Mafengwo

1. Система маркетингового центра

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

В ответ на вышеуказанные проблемы основные возможности технической архитектуры маркетинговой системы Mafengwo включают:

• Создайте гибкую и эффективную модель развития событий

• Обеспечение высоконадежной и высокодоступной поддержки операций по событиям

• Обеспечение безопасной работы вашего бизнеса маркетинговых кампаний

Поэтому на основе метода «платформизация, компонентизация и модульность» мы проектируем архитектуру системы маркетинга следующим образом:

Общая маркетинговая система Mafengwo разделена на две части: B-end и C-end. Конец B в основном предназначен для продавцов, помогая им сообщать о крупных рекламных акциях и выборе продуктов на инвестиционной платформе Mafengwo; конец C в основном предназначен для пользователей Mafengwo, пользователи платформы могут совершать покупки продуктов для мероприятий, пиков и крупных рекламных акций. на странице бизнес-маркетинга, чтобы выиграть. Возьмите и другие конкретные маркетинговые мероприятия, чтобы участвовать во взаимодействии.

2. Маркетинговая платформа C-end

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

• Платформа для развития деятельности: Основная часть маркетинговой платформы также находится в центре внимания этой статьи. Он состоит из трех частей: слой построения страницы внешнего интерфейса «Куб», слой бизнес-логики «Bee Play Paradise» и уровень управления правилами вознаграждения «Призовой фонд».

• Платформа доставки: относится к доставке страниц маркетинговой деятельности, включая стратегии доставки, стратегии и механизмы работы и т. д.

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

• Маркетинговое приложение: включая рекламный маркетинг Mafengwo, бизнес-маркетинг, подарочную упаковку для новичков и т. д.

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

Во-вторых, реализация платформы развития деятельности

2.1 Гибкий и эффективный режим разработки

Как видно из рисунка выше, пул данных, состоящий из MySQL, ElasticSearch и Redis, обеспечивает поддержку активной платформы разработки внизу. Среди них MySQL является основным решением для хранения, которое используется для хранения данных конфигурации строительства объекта, данных о работе пользователя Beeplay Paradise и данных конфигурации призового фонда. ElasticSearch — это поисковая система, которая поддерживает процесс регистрации и проверки событий продавца на странице события. Redis имеет 2 цели: 1) одновременные блокировки для активных задач; 2) хранение данных о призах для призовых фондов; 3) ограничение тока и пиковое бритье.

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

2.1.1 Уровень системы

Кубик рубик

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

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

Пчелиная площадка

(1) Абстракция логических функций

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

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

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

• Во-первых, деятельность по развитию создает «рай».

• Мы разработаем каждое «мероприятие» в соответствии с различными «правилами», чтобы стимулировать интерес потенциальных «участников» или сформировать у них ожидания в отношении выигрышных наград.

• После входа в событие мы проверим «личность» участника и «условия», которые необходимо выполнить для этого события, чтобы определить, может ли он начать.

• В начале деятельности поведение, которое необходимо участнику для участия в деятельности, заключается в выполнении «задачи».

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

Эта модель аналогии была выведена в предыдущих рекламных мероприятиях, и результаты показывают, что она в основном универсальна, но выполнение задач может сопровождаться или не сопровождаться услугами вознаграждения, в зависимости от конкретных потребностей бизнеса. Например, в маркетинговой кампании по расщеплению красных конвертов необходимо сыпать красные конверты дождем.Пользователи могут нажимать на упавшие красные конверты, чтобы получить соответствующие награды в красных конвертах. Тогда действие «получение» можно рассматривать как задание в действии; еще одно требование состоит в том, что каждый раз, когда пользователь успешно приглашает друга, он может получить награду в красном конверте приглашения в центре задач, тогда мы можем собрать красное приглашение конверт в центре задач Также рассматривается как задача.

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

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

(2) Техническая реализация

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

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

Представьте реализацию нескольких ключевых модулей.

• модуль запроса данных

Модуль запроса данных определяет правила параметров запроса, согласованные между клиентом и сервером:

request:
       -
        field:  deviceId
        rule: required  #必填项校验
        method: post
        message:  deviceId参数错误
       -
        field:  sex
        rule: in:[0,1] #范围校验
        method: post
        message: 性别范围错误
       -
        field:  phone
        rule:   regex:/^1[3456789]\d{9}$/ #正则校验
        method: post
        message: 手机号格式错误

(i) поле - ключ входящего параметра (ii) правило - правило для проверки этого параметра, пока мы внедрили некоторые общие правила:
(iii) требуемый - обязательные параметры

• in: Убедитесь, что переданные параметры должны находиться в указанном диапазоне

• регулярное выражение: проверка регулярного выражения

• min, max: минимальная и максимальная длина пользовательского правила

• целое число: должно быть числом

• метод: определить методы запроса GET, POST

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

• модуль конфигурации параметров

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

params:
    stockRedPacket:
     amount: 1
     stock: 3
     stockKey:  limit_key
     stockField: limit_key_90
     timeWindow:
       beginTime: "2019-11-06 00:00:00"
       endTime: "2019-11-10 23:59:

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

(i) stockRedPacket настраивает бизнес-логику фиксированного запаса и фиксированного количества красных пакетов, установленных действием.

• сумма сумма

• склад

• Поля, используемые stockKey и stockField для блокировки

(ii) timeWindow определяет время начала и окончания действия для задачи.

• модуль валидатора

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

validator:
   - MCommon_Validator_TimeWindowValidator
   - MCommon_Validator_AuthValidator
   - MCommon_Validator_LockValidator

• Здесь используется проверка активного времени TimeWindowValidator, и сообщение об ошибке возвращается, если оно не находится в активном времени.

• Проверка входа в систему AuthValidator, вы должны войти в систему, чтобы принять участие в мероприятии, и внешний интерфейс перейдет на страницу входа, оценив код состояния ошибки.

• Одновременная блокировка LockValidator, чтобы избежать многократного выполнения одной и той же операции пользователем.

• Выньте все валидаторы и вызовите их последовательно через отражение.Если один из валидаторов выйдет из строя, будет возвращено сообщение об ошибке, чтобы прекратить нисходящее выполнение.

• Исполнительный модуль

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

command: MSign_Command
afterCommand: MSign_Command_After

Executor делится на pre-command и post-afterCommand:

• Если вам нужно выполнить модуль вознаграждения, сначала выполните предварительную команду, затем выполните логику вознаграждения и, наконец, выполните post-afterCommand и, наконец, верните результат.

• Если награды нет, сначала выполните предварительную команду, а затем выполните команду post-afterCommand.

• Модуль вознаграждения

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

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

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

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

• Купон: напрямую подключитесь к дисконтному центру Mafengwo, нужно только настроить серийный номер купона и номер канала, купон можно отправить на купон карты пользователя.

призовой фонд

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

(1) Основные функции

К основным функциональным пунктам призового фонда относятся:

• Создайте призовые фонды: создайте один или несколько призовых фондов для каждого события.

• Установите призы: распределите призы поровну в одном призовом фонде.

• Пользовательская лотерея: пользователи разыгрывают лотерею в едином призовом фонде, поддерживают лотерею по вероятности, а также поддерживают распределение и сбор призов.

• Статистика выигрышей: включая количество выданных призов, количество полученных и оставшееся количество

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

(2) Дизайн схемы

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

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

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

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

(3) Реализовать алгоритм

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

2. Создайте призовой фонд: Установите призовой фонд для каждой группы призов, создайте структуру данных zset в Redis, возьмите каждый приз в качестве участника (Member) и используйте метку времени в качестве счета (score).
3. Размещение призов:использоватьZADD 奖池 出奖时间戳 1 份奖品синтаксис, чтобы выложить выигрыш в Redis.

4. Удачный розыгрыш: Используйте метод сортировки Sorted Set, проверяйте первый приз после каждой сортировки и сравнивайте размер текущей временной метки и временной метки приза. Если текущее время позже или равно времени розыгрыша, используйтеZREMПриказ о выдаче призов, иначе нет.

Схематическая диаграмма выглядит следующим образом:

2.1.2 Унификация системы

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

(1) Награды, полученные одним и тем же пользователем при участии в разных мероприятиях, не зависят друг от друга, и путаницы не будет.

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

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

2.2 Доступность и надежность

Модуль seckill — самый высокий пик большого рекламного трафика. В сочетании с реальной деловой ситуацией мы также выполнили обработку ограничения тока и пикового сглаживания для этого сценария.

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

отсечение пикаНекоторые примеры объединены.

Взяв в качестве примера сценарий уничтожения членов Gold Card за считанные секунды, мы сначала будем использовать RabbitMQ для обработки мгновенных пиков трафика, затем плавно обработаем все запросы и заранее запишем токен, соответствующий количеству инвентаря, в кэш Redis (здесь мы нацеливаемся разные пользователи. Введен механизм токенов, чтобы гарантировать, что наши молниеносные сделки гарантированы с точки зрения своевременности и наличия запасов). Пользователи будут последовательно получать токены, соответствующие rPop в Redis во время всплеска, чтобы избежать перепроданного инвентаря; после того, как пользователи получат токены, они могут пойти в кассу, чтобы разместить заказ, чтобы активировать членство в Gold Card, что может избежать трафика при размещении заказов на в то же время.

С развитием бизнеса и технологий неопределенность системы и оценка трафика усложняются. Мы также постоянно изучаем передовой опыт отрасли, чтобы лучше повышать доступность и надежность системы. В настоящее время мы изучаем и активно продвигаем «адаптивную» технологию ограничения тока на основе Noah, чтобы осуществлять целевое управление ограничением тока в соответствии с различной производительностью сервера и текущими условиями трафика. Я считаю, что в последующих оптимизациях мы добьемся большего успеха.

2.3 Контроль рисков

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

Процесс реализации доступности, надежности и контроля рисков показан на следующем рисунке:

3. Ближайшее планирование

1. Улучшить систему мониторинга

В настоящее время мониторинг данных в активной эксплуатации в основном опирается на статистику и вывод групп данных. Работа онлайн-активностей не может быть показана в режиме реального времени и всесторонне через системы «Bee Play Paradise» и «Journey Pool».

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

2. Трансформация сервиса

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

резюме

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

Авторы этой статьи: Лю Юаньюнь, Рен Хао и Тан Жунбо из Центра исследований и разработок и маркетинга Ma Honeycomb E-commerce.