Marketing Campaign Process Guide

As for the development process of building marketing activities : the initial marketing activities are usually "customized". An activity is written for one demand and one scenario. Gradually, there are more and more repetitive activities, and people begin to borrow the idea of ​​templates, making several sets of activities and changing the skin each time. However, each skin change limits the gameplay routines, which easily leads to user fatigue and the effect begins to decline.

At this time, the demand of the activity has become to flexibly connect the existing gameplay based on the existing template idea, and continuously add new gameplay, so we began to precipitate one standard "gameplay" after another, such as tasks, sign-ins, lotteries, voting, answering questions, assistance, group formation, rankings, etc., and then every time there is a new activity, we only need to manually develop and connect them.

The entire series of gameplay can be solved through customized development or through R&D configuration. Ultimately, it can be completely separated from R&D and operation configuration. This article will describe the process orchestration problem of user participation process or gameplay series in marketing activities.

1. Analysis of the current situation

As mentioned earlier, after we have accumulated the commonly used gameplay, we have obtained various forms of gameplay such as raffles, quizzes, tasks, sign-ins, etc. During use, usually an action of gameplay A is associated with an action of gameplay B in a certain scenario. For example, the user gets a chance to draw a lottery when participating in the quiz for the first time, and the user gets cash when completing the task, etc.

If pure R&D development is used for customized associations, the relationships faced each time are relatively complex. In terms of magnitude, they are basically: m*n*s (output events, input actions, scenarios). Even if there is sedimentation each time, the interactive relationship between gameplay is basically overly complex and difficult to maintain. Therefore, we need a "bus" tool to centrally manage these interactions and reduce complexity.

2. Overall design ideas

For these volatile and complex logics, the most intuitive idea is to separate business decision logic from code decision logic. In the scenario of activity choreography, business logic is the association and decision-making relationship between gameplay events, and code association is the acceptance and calling of various events.

1. Event-driven design

Therefore, it is necessary to standardize the input and output of the gameplay, and then have a place to configure associations for these events. For the business decision logic between the associations, you only need to refer to the decision engine. After the entire abstraction is completed, the cost of activity concatenation has been reduced from m*n*s to m+n, and it directly enters the R&D configuration association stage, with costs reduced by at least 80%, and provides an entry point for function development for subsequent operations that can be directly manually configured.

At this point, everyone should have discovered that it is essentially a business event bus. If you have read the definition of the SOA event interaction bus, the idea is essentially the same, but we do not need such a strong definition as SOA. Not only will there be relevant descriptions in SOA architecture design, but if you are familiar with microservice architecture, event-driven architecture, and DDD design ideas, there will also be a lot of descriptions of event bus design.

The business event bus here is nothing more than based on these ideas, localized processing according to active business scenarios, adding some dynamic decision-making and configuration association capabilities.

2. Context Sharing Problem

After decoupling various gameplays and then associating them through the business event bus, each gameplay basically forms an information island, which only cares about changes within itself, which is actually not conducive to the activity logic. The prize collection for the lucky draw opportunity added by high-threshold tasks is often of higher value. Different groups (team members with different identities) face different reward values. In many cases, it is necessary to rely on the contextual information of user participation. If you want to break the information island, there are usually two ways of dealing with it:

1) Make rewards for gameplay that requires context a basic capability that perceives the context of all gameplay. Rewards exist as a microkernel that is directly called by each gameplay with context.

2) Further abstract these context-aware applications and further separate the business rules. Only the business rules (rule engine) are aware of the context information. The context of other gameplays is just an ordinary key-value for a gameplay, and is specifically used in the expression that holds the business rules.

Overall, both ideas are essentially acceptable and applicable to different stages of system development. If there are relatively more activities, the first one is sufficient; if there are more complex activities, the second one is relatively suitable.

Overall comparison:

• The first type: The implementation is relatively simple and the requirements for gameplay are relatively low. However, if an operation involves multiple gameplay contexts at the same time, it is relatively difficult to handle. And if the operations that require context become more numerous and related, the architecture will gradually degenerate into manual strong association.
• The second type: The implementation is relatively complex and has high requirements for the configurability of the gameplay, but it has good scalability and is easier to handle complex activities.

3. Context Design

The design of the context is relatively simple. It can be roughly understood as a get route distribution. You can understand it as a dataSource with business characteristics. You can find the context information of user participation we need based on a key.

The specific implementation scheme can be a centralized storage to store the activity context, or a logical centralized storage to act as a proxy to inject the method activity context through the gameplay.

Context + Dynamic Decision Orchestration = Activity Orchestration Engine

3. Performance Guarantee

Since it is necessary to process the event flow of one or several businesses, the business event bus is a "system node" with relatively high performance requirements. It is necessary to ensure its excellent performance as much as possible. Here is the overall optimization process of the event bus (according to the old routine, first optimize the points, then optimize the "quantity" in the distributed scenario). Let's look at the results first:

1. Less & Faster IO

When using the event bus, network IO should be avoided as much as possible. First, the event bus calls should be localized. Second, the event bus calls for external events should be localized as much as possible and only serve as a logical module.

If the current architecture does not allow or support the entire activity to be packaged together for deployment due to factors such as scalability and availability, IO is inevitable. In a word, use epoll as much as possible. As a business development, these things can be left to the infrastructure to handle.

2. Faster storage

Hard-coded > Memory > Local Disk > Network IO. The relationship between regular events is directly stored in memory (DB can be preloaded into the process), and the strongly associated event configuration is directly hard-coded (hard-coded configuration problems can use some expressions) to avoid network IO and disk IO.

3. Reasonable optimization of distributed quantity

For optimization of throughput such as asynchronous event processing and micro-batch processing, just take the optimization ideas of mq such as kafka, I believe everyone will know how to do it. In scenarios like this, don't reinvent the wheel, it is enough to use kafka to achieve asynchrony.

Balance consistency and availability. As mentioned earlier, use the fastest storage possible. In a distributed scenario, if you can accept inconsistency among multiple nodes, you can use this approach. If the consistency requirement is relatively high, you can use a single-point redis to store the association relationship. If the reliability requirement is very high, you can take a step back and use MySQL.

Generally speaking, the event bus does not have any significant business hotspots, and horizontal expansion can basically solve all volume problems. What matters is that you pay attention to the single point in the business and do a good job of resource isolation.

4. Data consistency guarantee

The event bus is not a strong business entity, but a purely fictional concept. We only need to ensure that the process of using the event bus can be guaranteed.

For the scenario of distributed transactions, this depends on the implementation of distributed transactions. If it is a TCC class, it is sufficient to ensure that the event can participate in the transaction normally. For distributed transactions that rely on transactional messages, the "event call maintenance" of the event bus can be replaced and encapsulated on the transaction message queue.

For processing scenarios without distributed transactions, make the most of idempotent retries and do a good job of event processing. By the way, idempotent retries around the "event bus" are a good processing idea.

4. Existing wheels

Open the search engine and search for business event bus. Alibaba Cloud and Tencent Cloud have similar solutions, but they target relatively fewer business scenarios. This thing is not complicated and one person can basically develop and launch it in two weeks. The most important thing is the localization of the corresponding idea. If you encounter similar scenarios in your actual work, just make a comprehensive assessment of the cost and implement it.