Ten thousand words of practical information on the essentials of e-commerce refined operations - field decision engine (Part 2)

In the refined operation of e-commerce, the field decision engine is a key tool for achieving precise marketing and efficient operation. As the second article in the 10,000-word series of essential information for refined operation of e-commerce, this article deeply disassembles the core modules of the field decision engine and the solutions to common problems for your reference.

The previous article described the system architecture, business process and label module design of the e-commerce refined operation tool, the field decision engine. This article continues to disassemble and describe the rule system, strategy system, instance system, strategy tree and common problems.

6. Rule System

1. Rule life cycle

Rules, like labels, have a life cycle.

When a rule is created, it is in draft state. When it passes the test and is released online, it becomes effective. However, when it is released online, the rule has two versions, a draft version and an online version.

In order to standardize the version management of rules, if subsequent rules need to be edited, the draft version is edited, and then tested and released online, and the online version is updated, and so on. This can also ensure that the editing process of the rules will not affect the online execution.

Therefore, once a rule is published and launched, two versions will be generated: a draft version and an online version. Each edit is to edit the draft version, and each run is to execute the online version.

After the rules are online, if we find problems with the rules, we can disable the rules.

Why disable instead of delete?

First of all, based on system security considerations, we basically do not use high-risk operations such as deletion. Even if we delete, it is only a logical deletion, not a physical deletion.

Secondly, some rules have been used in policies, and policies have been deployed in user processes. If the rules are deleted rashly, the impact is difficult to assess and the risk is high.

Therefore, if you find an error in a rule, you can disable the rule. Disabling a rule means that you can no longer use the rule when you create a policy later. However, if the rule has already been used and the policy is in effect, you can still use the rule to execute judgments and it will not be affected. If you want to completely offline the rule, you can offline all the corresponding policies.

If there is a disable, there is an enable. Enable means that the rule is available and you can choose to use it when creating a policy.

2. Rule Type

Corresponding to the tag type, the rule also has a rule type.

Different types of rules have different input requirements when making decisions. For example, user rules make decisions based on uid, while product rules make decisions based on skuid, that is, there are differences in input parameters and decisions.

Rule types correspond to tag types one by one

User rules: You can select user tags for configuration and make decisions based on uid
Product rules: You can select product tags for configuration and make decisions based on skuid
Order rules: You can select order tags for configuration and make decisions based on orderid
Custom rules: You can select custom tags for configuration and configure decision rules based on transparent tag fields

When configuring a rule, you are actually configuring an expression: label + operator + value.

For example, the user's age is greater than 29. The user's age is the label, the operator is greater than, and the value is 29. The decision logic is to extract the real user age label value through uid. For example, there is a user 1, whose age is 30. If 30 is greater than 29, true is returned, otherwise false is returned.

Therefore, when configuring a rule, you must first select the tag you want to use. Different types of rules support the selection of different types of tags. For example, user rules can only select user tags.

After selecting the label, you can determine the field type, such as enumeration, text, numeric, etc. The field type determines the optional operators and value input interactions, for example, enumerations can choose to contain/not contain, text can choose to be equal to/not equal to, and numeric values can choose greater than/less than.

Therefore, the next step is to select the operator and enter the corresponding value.

However, in some scenarios, the expression of the rule is more complex and needs to be composed of multiple expressions. This combination also needs operators to connect. The most common operators are and and or. and means that both expression 1 and expression 2 must be satisfied. or means that either expression 1 or expression 2 can be satisfied.

We all learned basic logical expressions in junior high and high school math. The opposite of A and B is not A or not B, which means you can choose (label 1 contains a) and (label 2 contains b). If you want to take the opposite, you can configure (label 1 does not contain a) or (label 2 does not contain b).

Therefore, and and or can solve more than 99% of daily multi-expression relationship configurations.

3. Rule Testing

After the rule is created, it also needs to be tested before it can be put online. This is to ensure the accuracy of the rule configuration and avoid configuration errors that lead to business personnel misusing the wrong rules when creating policies. In addition, the rule creation permission is open to business personnel, and all business personnel can create rules, so the risk is higher.

The test is mainly to input the input parameters and observe whether the output parameters meet expectations.

For example, for the rule that the user's age is greater than 29, you need to input uid and observe the output value of the rule. The output values of the rule are only yes and no. Suppose a user's age is 30, then the output value of the rule needs to be "yes", which is in line with expectations. If it is "no", it does not meet expectations.

Note that for custom rules, because the label value is transparently transmitted, the input parameter is the custom label selected by the rule.

At the same time, as mentioned above, once the rules are released and launched, all business personnel can use the rules to configure policies, which is a high risk. In order to avoid this risk, we can also perform permission control at the rule level.

If it is a public rule, then after the user creates it, all business personnel can choose to configure the policy; but if it is a private rule, then after the user creates it, it can only be used when the user configures the policy himself.

We only need to control the configuration permissions of public rules, which can effectively reduce the impact of rule configuration errors that are widely used.

4. Application of Rules

For a rule, once it is created and released, it can be selected and used by any policy. From the perspective of the rule, it needs to know which instance policy uses it.

As mentioned above, after a rule is disabled, the policy that has used the rule will not be automatically offline and needs to be processed manually. So here you need to know what instance the rule is associated with so that you know what to process.

Therefore, knowing which policies the rules are used in is helpful for checking after the rules are adjusted. If the rules are changed, the affected policy range can be confirmed, and the policies that need to be adjusted can be adjusted quickly.

7. Strategy System

1. Policy life cycle

Policies, like tags and rules, have a life cycle.

When a strategy is created, it is in draft state, and after saving, a draft version is generated. At this point, the strategy can be gradually pushed online.

However, in order to better verify the accuracy of policy execution, the policy also distinguishes between pre-release versions and grayscale versions, corresponding to the pre-release environment and grayscale environment respectively.

When a policy is released to a pre-release version, you can experience it in a pre-release environment to verify the accuracy of the policy.

Finally, the strategy is released online, and an online version is available. In this process, a total of draft versions, pre-release versions, grayscale versions, and online versions are produced.

In order to standardize the version management of the strategy, if the strategy needs to be edited later, the draft version is edited, and then released to pre-release, released to grayscale, released online, overwriting the updated version, and so on. This can also ensure that the strategy will not affect the online execution during the editing and release process.

After a policy is published and launched, it is in the enabled state. If you need to take a policy offline, you can directly disable it, which is equivalent to making the policy invalid in all environments.

It should be noted that one thing that makes strategies different from rules and labels is that strategies have an expiration date. Because labels and rules exist and are used for a long time, there is no need to set an expiration date. Strategies, on the other hand, are phased. You may want to operate in this way in January and market in that way in February. Therefore, strategies must have an expiration date.

If the policy is within the validity period, it is in the online state, and you can also directly operate offline and disable it. However, once the policy is over the validity period, it is automatically offline and disabled, and you can no longer operate online.

2. Policy Configuration

The configuration of the policy includes validity period, selection rules, and decision content.

Simply put, when creating a policy, you need to fill in basic information first, including the policy name, policy validity period, etc.

Next, you need to select rules, including user rules, product rules, etc. The rule types that can be selected here depend on the rule types supported by the scenario instance. You cannot just choose and support them randomly. If the scenario instance wants to support this rule type, it must have corresponding input parameters when it is connected to the field decision engine. For example, when a scenario wants to configure a strategy, it can select product rules, but there is no product SKUid input parameter for decision making, which is definitely not possible.

After selecting the rules, you need to fill in the final decision content. Different scenario instances have different decision contents. For example, the decision content of the promotion scenario may be a specific promotional discount, and the decision content of the installment payment scenario may be a list range of installment numbers.

If this strategy still needs to be tested, then access to AB experimental capabilities is required.

After configuring the basic rules and decision content, in order to conduct AB testing, you need to configure an AB experiment, including the validity period of the experiment, the ratio of the control group and the experimental group, and the corresponding decision content of the control group and the experimental group.

The configurable decision content items and scopes for the control group and experimental group are consistent with the decision content items and scopes of the strategy itself.

This is also equivalent to a double backup. If there is a problem with the experiment, the strategy can still output basic decision content. If the experiment is executed normally, it can output the group hit by the user - control group/a certain experimental group, and the corresponding decision item content.

When the experiment validity period ends, the experiment will end automatically, the experiment will no longer be executed when the strategy is executed, and the backup decision content in the strategy will be automatically output.

If you want to end the experiment early during the validity period of the policy, you can also manually close the experiment or create a new experiment. However, the experiment acts on the policy, that is, the release of the experiment is integrated with the policy. If the experiment is updated, the policy needs to be released synchronously to take effect.

3. Strategy execution logic

The execution logic of the tag is to input the parameter and return the value corresponding to the tag.
The execution logic of the rule is to input parameters and return yes or no, that is, whether the rule is hit or not.
The execution logic of the strategy is to input parameters and return specific decision content.

That is to say, in this scenario instance, the strategy will return the decision content based on the rule decision results, such as uid, skuid, orderid, and transparent fields required for input parameters.

Then there will be a situation. If there are multiple strategies in a scenario instance, after entering the parameters, based on rule judgment, multiple strategies are matched and decision contents are output. What should be done?

There are three common processing methods: taking the union, taking the intersection, and outputting by priority.

Take the union: Take the union of multiple policy decision contents, that is, merge them all and output them together.
Intersection: Take the intersection of multiple policy decision contents, that is, the content in each policy decision content will be output. This method can easily lead to the situation where the intersection is empty and the decision content output is empty.
Output by priority: Sort by the priority of the strategy itself, and output the decision content corresponding to the first hit strategy according to the priority. In other words, the execution result of the strategy with the highest priority shall prevail.

For the field decision-making system, the configuration of the decision output capability can be supported in the scene instance configuration. Different scene instances will have different demands. This can reduce the processing cost of the access party.

Of course, there is another way. The field decision returns all results to the access party in order, and each access party makes its own decision on the final output result.

8. Scene Instance System

1. Scenario access type

If a business scenario wants to use the capabilities of the field decision engine, it must be connected to the field decision system.

In terms of system interaction, there are two access methods: one is the closed loop of the field decision system, and the other is to embed the field decision system in the business system.

The closed loop of the field decision system means that users select scenarios, instances, create policies, select rules, select decisions, publish instances, and put them online to take effect in the field decision system.

This set of processes is a forward process designed based on the field decision system. Users will be aware of each layer of the system and each step of execution during configuration. From the perspective of users' understanding of the field decision logic, the cost is low, but the operating cost is high.

At the same time, this solution allows business parties to directly use the field decision system as their own management cost without having to maintain their own management system operating procedures, which can also save development costs.

Embedding the field decision system in the business system means that the user does not need to be aware of the field decision system. He may complete his own business configuration in his own business system, such as the traffic delivery system or the promotion system, and only select one user rule or product rule to indicate that the business activity is only effective for designated users and products.

This set of processes is designed from the perspective of the business system. Users are basically unaware of how the field decision system works during configuration. From the perspective of users understanding the field decision logic, the cost is high, but the operating cost is low. In many scenarios, it is actually difficult and unnecessary for business personnel to understand the field decision system. From their perspective, it is just a promotional offer that only takes effect for new users and that's it. In this scenario, the embedded access method is more effective and saves a lot of understanding and operating costs.

Of course, the embedded access method will not change in essence. It is just equivalent to creating the scene and instance by default or in real time through the interface when the scene is accessed. When the business selection rules are saved and take effect, it is equivalent to automatically creating the policy and executing the release process. The framework and underlying logic behind it remain unchanged.

But this will also lead to another problem. If each system has its own embedded system, it will be difficult to develop and access the business system; for the field decision-making system, it will be extremely difficult to maintain if there are subsequent updates.

Therefore, the field decision system can be output in the form of standardized components. If a business system wants to use the field decision capability, it needs to pass key parameters into the component and then select rules, decision content, etc. according to the same operation process. In this way, if there are subsequent updates, all components can be updated uniformly, which is more efficient.

2. Instance version management

As mentioned above, when users publish policies, they actually need to publish instances.

Why publish instance?

We believe that instances are the smallest unit of code execution, which means that these strategies are the result of making decisions in this place. If each strategy can be modified and released at will, it means that data is constantly being updated and overwritten in the same place, which may cause conflicts.

Therefore, this problem can be solved by publishing instances. In the same place, only one version can be edited at the same time, and the next version can be opened only after a version is released. This version management is safer and is also conducive to timely rollback when problems occur.

There are four versions for instance releases: draft, pre-release, grayscale, and online.

That is to say, every change to the instance, including adding a new policy, deactivating a policy, editing a policy, etc., as long as it may have an impact on the instance decision, we consider it an instance change and will change the information in the draft version.

After the draft version is updated, it needs to be released to the pre-release version, the gray version, and then the online version. Release and execute in sequence to ensure that the data of each version is updated in an orderly manner.

If the current version is in use by a user, then others can only wait for the user to publish it, or for the user to undo the edit, restore it to its original state, and release it to other users. For example, user A adds a new policy, saves it, and publishes the instance to the pre-release version. At this time, user B wants to add a new policy, but he cannot do so. He can only wait for user A to publish his version online, or undo the version and restore it to the original version.

With strict version control, one of the biggest benefits is that you can roll back at any time. If a user finds a problem with the version just released, they can view the historical versions and select a historical version to quickly roll back, which is equivalent to creating a new version and overwriting the content with a historical version before releasing it. This rollback process is extremely efficient and can minimize risks.

3. Example test

The above article mentioned label testing and rule testing, but did not mention strategy testing. It is not that strategy testing is impossible, but instance testing is more cost-effective.

From the instance version management, we can know that the instance is the smallest unit of code execution. We configure the policy, not to test the execution effect of a single policy, because the answer can be roughly known through rule testing. Instead, we want to test how my area will be displayed after adding this policy.

This instance may have multiple policies, which involves the policy execution logic; this scenario instance may have many input parameters, including uid, skuid, different transparent fields, etc.

Therefore, only through instance testing can we obtain the most accurate simulation of user-side execution effects.

When testing an instance, you need to fill in the fields required by the scenario instance in the input parameter, such as uid and skuid. The instance will then return the execution result, that is, output the final strength decision value, which may be the decision value finally output based on the strategy execution logic after hitting multiple strategies.

9. Strategy Tree Upgrade

1. Solve the pain points

From the above system architecture, we can see that the current perspective is triggered from the scene all the way to the final decision.

Although this logic is easy to understand, there are two problems:

The operation is relatively complicated. If you need to execute policies for the same user in different scenarios, you need to go to different scenario instances to operate, which increases the operation cost.
Difficult to abstract. From the current structure, it is difficult to quickly see what refined strategies have been implemented for the same user type.

Therefore, we need to abstract the entire strategy from another dimension, such as the user dimension or the product dimension, to form a strategy tree.

On the one hand, this strategy tree can quickly improve efficiency. For example, you can choose the users you want to operate and quickly configure the strategies you want to execute in different scenarios. This can significantly improve operational efficiency. On the other hand, this is more in line with the boss's thinking. Generally speaking, the boss would definitely like to see what strategies you have implemented for a certain type of user and what strategies you have implemented for another type of user, rather than starting from the perspective of system functions. Such strategies are also more conducive to accumulation and precipitation.

2. Tree structure

In the current system structure, scenarios, instances, policies, rules, labels, and decisions are all complete, but a new carrier is needed to connect them together again, and this new carrier is the tree.

Therefore, the focus is on building a tree structure.

Similar to the tree above, operations are based on new e-commerce users. First, users are divided into three layers: high-quality, ordinary, and growth users according to their value. Then, male and female users are divided according to gender to further refine operations.

It is not difficult to see that the different nodes of a tree, from the root node to the leaf node at the bottom, are connected to form a complete rule. Taking the leftmost branch as an example, its meaning is {user life cycle = new e-commerce user and user value = high-quality user and user gender = male user}

Therefore, for a tree, the first thing is the tree's own ID, name, and status.

Secondly, a tree can have multiple nodes, and different tree nodes also have their IDs, names, and states.

Each node corresponds to a rule. Child nodes can also inherit the rules of parent nodes and form a rule set by connecting them.

3. Tree configuration process

The configuration logic of the tree is to build the tree by creating nodes and then configure the strategy on each node.

The logic of creating a node is to select user rules. Different nodes are defined by different user rules. Nodes at different levels have an inheritance relationship, that is, the rules of the leaf nodes at the next level will inherit the rules of the leaf nodes at the previous level.

After all tree nodes are created, you can configure policies on each node. When configuring policies, you do not need to select rules because the nodes have already defined rules. You only need to select the scenario, instance, and corresponding decision content.

4. Tree execution process

There are two ways to understand the execution process of a tree.

One is the same as the previous field decision system execution process, which reads the strategy, judges the rules, and determines the decision content according to the corresponding scenario instance. Because for the strategy tree, as mentioned above, it is essentially the connection of rules. From a single rule to multiple rules connected by "and", it is still a rule. Therefore, the entire system has not changed, and the execution logic will naturally not change.

Of course, there is another way to understand it, which is to understand it from the perspective of the tree. When a user comes in, first determine the user rules, then through the root node, determine which tree the user hits, then determine which leaf nodes the user hits layer by layer, and finally execute the policies of all the nodes hit. This is to start from the perspective of the tree and understand the execution logic positively.

10. Frequently Asked Questions

1. What is the difference between user rules and user packages?

In the business process, the most frequently asked question is: Can I use the rules of the field decision system to circle a user group and send them text messages?

I have tried to explain it to the business staff many times, but it always seems difficult to explain thoroughly.

Therefore, I later tried to explain it in a different concept, which is - screening and selection.

Screening is like a funnel. When a user comes, see if he can pass through it. If he is not passed through, he is screened out. All you have is a funnel without anything specific in it.

Circle selection is more like a sheepfold. There are many sheep in it, and each sheep has its own ID. You can pull this batch of sheep to produce milk. For example, I pulled 83 sheep to produce milk today. You have specific things in a sheepfold, and you can take specific actions on them.

Therefore, the rule engine in the field decision system is like the logic of screening, and the rules are the funnel. For each user who comes, I can only tell him whether he hits the rules (whether he is screened), but I don’t know how many users there are in this funnel, because the funnel itself is not a container and does not hold "users".

If you want to select these 300,000 users to send SMS marketing, this is the selection logic. You select and batch run a 300,000 user package based on certain rules. This package is a container, which contains 300,000 "users". Now that you have a specific object, you can take specific actions on these 300,000 users, such as sending SMS marketing.

User rules are screening, have no specific objects, and are only used for decision-making;

User packages are circled, have specific targets, and are used for marketing.

This is the biggest difference between user rules and user packages.

Of course, they can have the same tag capability as a basis. User packages are formed by assembling rule expressions through tags and then batching the expressions to form a package. Generally, it takes time to batch run user packages, so there must be an update time, and it cannot be done in real time. User rules can make decisions in real time.

2. Why do we need to publish instances for policies to take effect?

When users publish policies, they actually need to publish instances. Why publish instances?

There are four versions for instance releases: draft, pre-release, grayscale, and online.

3. Why do labels need to be developed and created?

Why are tags added by R&D rather than created by business personnel themselves?

One is the professionalism of tags. Many tags require professional configuration items. For example, tags created through interfaces need to be configured with interface names, method names, tag cache time, etc. These are very professional contents. Even if business personnel handle it, they still need to find R&D to obtain relevant information. It is better for R&D to add it directly, which is more effective.

One is the importance of labels. Labels are the most basic and core capability of the field decision-making system. If the label is wrong, the rule will be wrong and the decision will be wrong, which is a very serious problem. Therefore, the accuracy of labels is the primary guarantee of the field decision-making system. R&D will configure and test the labels to maximize the accuracy of the labels, and they will be delivered to the business for use after confirmation that there are no problems.

The conventional tag maintenance logic is that the business raises requirements, R&D adds and tests, and then releases it online. If there are problems after going online, R&D can also disable or modify it.

4. How to control the authority of the field decision-making system

Through the above introduction, it is easy to feel that the field decision-making system is a very important central system, just like the human brain, responsible for processing various decisions. Therefore, the system must have perfect permission control to prevent the brain from being "invaded" and causing decision-making accidents.

At every layer of the field decision-making system, scenarios, instances, policies, rules, and labels all require strict permission control.

In addition, policies, rules, and labels can be controlled by authorized personnel. That is, when creating a policy, you can fill in the personnel who have the right to modify the policy, and the personnel can also handle it later. After all, work involves handovers, cooperation, and other scenarios, and sometimes other colleagues are needed to help fill in the gaps.

Of course, the system also needs a super administrator role in case of emergency. For example, when a colleague is on vacation or resigns, and no one has the authority to operate the existing policies, rules, and tags, the super administrator can play a role.

<<: Pinduoduo practical case: How did I achieve monthly sales of 500,000 in 30 days without a price advantage?

>>: Draw your "ideal customer" in 3 steps: a guide for efficient customer acquisition for B2B companies