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

In e-commerce operations, refined operations are the key to improving efficiency and effectiveness. Starting from the three core dimensions of e-commerce operations, namely “people, goods, and venues”, this article discusses in depth how to achieve refined operations by building a venue decision engine.

E-commerce operation is a refined operation system based on different dimensions such as people, goods, and places. To explain it in one sentence, it means that in a certain scenario, for designated users and designated goods, designated business actions are executed and the corresponding business data is observed.

As mentioned in the previous article, e-commerce operation is a very large system, involving marketing systems, golden processes, promotion systems, etc. If each system maintains its own scenarios, channels, users, products and other strategy rules, then each system will be configured with its own logic, making daily maintenance difficult. Not only will the development cost be high, but the operational efficiency will also be very low.

Therefore, we need a universal field decision engine that contains all functions from the bottom layer to the application layer, including tags, rules, policies, instances, scenarios, policy trees and data, and supports the use of all e-commerce operation systems.

This article will describe how to build the field Juce engine from the following directory, divided into two articles.

1. Background

II. Explanation of Professional Title

3. System Framework

4. Business Process

5. Labeling system

6. Rule System

7. Strategy System

8. Scene Instance System

9. Strategy Tree

10. Frequently Asked Questions

1. Background

In daily operations, e-commerce businesses need to conduct refined operations and diversion tests for users to achieve the best operation results. For example, coupons are issued to certain users, and tests are conducted to determine which coupons have the best conversion effect for these users.

This process involves refined screening of user groups and precise experiments in user diversion.

The field decision-making system mainly achieves the following goals:

• Unified maintenance of scenarios, channels, users, product selection rules, etc. can not only complete the unified management of underlying data, but also realize unified maintenance and optimization of subsequent modules.
• Unified operation strategy management facilitates operations to quickly create and deploy strategies in the operation management system, and realize data recovery and observation.
• Unified R&D capability management, building a strategic operation system framework, abstracting each module and independently managing and maintaining it, making it convenient for R&D to uniformly handle various logics.
• Enhance scalability construction. If the business has external scenario expansion in the future, it can cover more external channels and support targeted operations.

Based on the above scenarios, the field decision system plans to support five-layer structures and corresponding capabilities: scenarios, instances, strategies, rules, and labels.

II. Explanation of Professional Title

3. System Framework

Let’s first look at the architecture design of the field decision system from a product perspective. It is divided into five layers:

1. Scene layer

The scenario layer refers to the scenarios that call the decision engine, including traffic scenarios, payment scenarios, promotion scenarios, etc. As long as there is a system that needs to be connected and used, it will be equivalent to a scenario party, connected to the field decision engine.

2. Instance layer

In terms of product, the instance layer refers to the specific instance of the change in the scenario, that is, the place where the real effect occurs. For example, in the promotion scenario, a specific promotion activity ID is an instance, which is a specific entity that the decision engine actually acts on. For another example, in the traffic scenario, a specific page ID or resource location ID is an instance, which is a specific entity that traffic distribution actually acts on.

3. Strategy layer

The strategy layer is to configure the effective decision strategy in this instance. A basic strategy is to perform what action under what rule. In other words, it consists of two parts: rules and decisions. Decisions are related to scenario instances. Different scenario instances can configure different decisions. For example, the decision of the traffic layer is what material to display, and the decision of the promotion scenario is the promotion discount strength.

4. Rules layer

The rule layer is part of the strategy layer described above, including user rules, product rules, custom rules, etc. Rules are mainly expressions composed of fields + operators. For example, user lifecycle = new user forms a new user rule.

5. Label layer

The label layer is the underlying capability that the upper rule layer strongly relies on. The rules are composed of labels. Labels are the root of the entire field decision-making system and the data source for all decisions. Consistent with the rules, labels include user labels, product labels, transparent labels, etc. The accuracy of label data determines the accuracy of the decision engine.

If we look at the architectural design of the field decision system from a research and development perspective, we need to mainly distinguish between the management side and the user side.

The management side needs to maintain the entry and data of business configuration, and the user side mainly needs to trigger interface calls for various user scenarios. When the interface is called, decisions are made in real time based on the data configured on the management side, and the decision results are returned to the user side.

The ER diagram of the field decision system deserves special attention, as it affects system interactions and applications.

Normally, a scenario can contain multiple instances, and one instance can be configured with multiple policies. A policy can be configured with a rule of the same type.

At the same time, one strategy can be configured with an AB experiment, and one AB experiment can contain multiple experimental groups, each of which must correspond to a specific decision content.

4. Business Process

1. Business development access scenario example

When a business scenario requires strategic operation, the scenario needs to be connected to the e-commerce field operation system.

For example, the payment strategy configuration in the payment scenario needs to screen the user population and support AB experiments. In this case, the business scenario "payment strategy configuration" needs to be connected to the field decision engine system to allow business personnel to select the scenario and create an operation strategy.

During access, R&D personnel create new scenarios in the system and maintain relevant parameters of the scenarios, such as the data indicators that need to be observed when conducting AB experiments in the scenario, the source of instance data, the source of decision data, whether certain types of rules are supported, whether AB experiments are supported, etc.

At the same time, you also need to add new instances. In addition to instance association scenarios and instance permission configuration, the most important thing is to obtain the instance ID for actual development use.

After the configuration is completed, R&D is required to develop scenarios and instances and implement them in the code.

2. Field system development and maintenance label

If business personnel need to use some tags, the field system R&D team will be responsible for adding them.

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.

3. Business personnel configuration rules

Business personnel can use the tags that have been effective in the field system to configure rules at will. Different rule types can be configured with different tag types. For example, when configuring user rules, only user tags can be selected.

In addition to selecting labels, you also need to select specific operators, such as equal to, not equal to, greater than, less than, contains, does not contain, etc.

Label + operator + label value constitutes an expression.

Different expressions can also be connected through operators such as "and" and "or" to achieve a combination effect.

After the rule configuration is complete, you can test whether the rule execution results meet expectations to determine whether your rule expression configuration is correct.

After the test is passed, it can be released online and officially take effect.

4. Business personnel apply configuration strategies

When business personnel configure policies, there are two scenarios: one is closed-loop configuration in the field decision system, and the other is embedded configuration in the application system.

When configuring the closed loop of the field decision system, you need to first select a specific scenario instance and add a new strategy to the instance. When configuring the strategy, you need to select the effective rules and choose whether to create an AB experiment. You can configure decision items for each branch to successfully create an operation strategy.

For example, a business person needs to perform strategic operations on the number of installments in the payment scenario and payment strategy configuration. In the field decision system, select the business scenario "Payment Strategy Configuration".

First select the "Low-risk users" rule, and then configure the AB experiment.

Select the control group with a diversion ratio of 50%

Select the experimental group, with a diversion ratio of 50%

Specific decisions are configured for each branch. For example, for the low-risk user control group, the corresponding number of installments is configured to be 3; for the low-risk user experimental group, the corresponding number of installments is configured to be 6.

In addition, there is another scenario, which is embedded configuration in the application system. Business personnel can directly select a rule in the current business system and complete a business configuration.

At this point, although the business personnel do not operate the configuration in the field decision system, from the perspective of the implementation framework, it is equivalent to creating a new configuration in the field decision system, including scenarios, instances, and policies. The policy includes the selected rules and specific decisions.

But no matter which configuration method is used, after the final policy configuration is completed, the instance needs to be released, and it can only be officially launched after the instance takes effect.

It is important to note here that it is not the release policy but the release instance.

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.

5. User-side execution process

When a business scenario is reached in the user-side process, it is necessary to first identify the corresponding scenario instance ID based on this specific business scenario, and determine whether there is an effective policy for the scenario instance ID in the field decision system. If so, execute the corresponding policy and output the policy execution result.

For example, when a user places an order and needs to determine the number of available installments, if there is an ongoing operation strategy for the payment strategy configuration in the field decision system, the business configuration of the strategy is read to determine whether the user hits the rules of the strategy and which AB experiment branch is hit, and the corresponding business decision content is executed.

5. Labeling system

1. Tag life cycle

A label, like a life, will go through a process from birth to death.

When a tag 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 tag has two versions, one draft version and one online version.

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

Therefore, once a tag 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 a tag goes online, if we find a problem with the tag, we can disable it.

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 tags have been used in rules, rules have been used in policies, and policies have been deployed in user processes. If tags are deleted rashly, the impact is difficult to assess and the risk is high.

Therefore, if you find that a tag has an error, you can disable the tag. Disabling a tag means that you can no longer use the tag when creating rules later. However, the rules that have already used the tag and are in effect can still use the tag to execute rule judgment and will not be affected. If you want to completely offline a tag, you can offline all the corresponding rules.

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

2. Tag Type

Tags need to be differentiated by type. On the one hand, different types of tags have different input parameter requirements. For example, for user tags, the decision input parameter must be uid; for product tags, the decision input parameter is skuid, that is, the input parameters and execution logic are different.

On the other hand, as the lowest-level data, labels can distinguish types based on labels, which is conducive to the inheritance of the type by subsequent upstream rules and policies, thereby achieving the unification of types in each link.

Of course, in order to facilitate system maintenance and business retrieval, we can also customize the secondary types of tags.

Common tag categories are as follows:

• User tags: Query by uid input parameter, which can be subdivided into user identity tags, user financial (risk) tags, user active tags, and user transaction tags
• Product tags: query by skuid, which can be subdivided into product, price, sales, brand, store, promotion, quality and other dimensions
• Order tag: query by orderid, mainly the tag of order dimension
• Custom tags: There is no restriction on the input parameter fields, that is, any field can be used as an input parameter to query what the tag value corresponding to the field is. Our common channels and terminal types all belong to this type of tags. However, there is a limitation when using custom tags. When configuring a strategy for a scene, the custom tags that can be used in the rules need to ensure that the scene will be transparently transmitted into the field system when the scene is connected to the field decision system. For example, if the scene wants to use the channel tag, then when the scene calls the field decision system, the channel field and field value must be passed in, otherwise the decision will not be made.

3. Tag source

There are generally multiple sources of label data. Taking user labels as an example, we usually support uploading a user package to form a user label, calling fields from other systems (such as big data T+1 batch run labels), labels generated through custom interfaces, and transparent labels through transparent fields.

Different tag sources mean different field data sources, which also means different field contents of specific tag configurations.

From this we can see that if the field is generated by a custom interface, the real-time performance is better, but the configuration is also more complex and professional. This is one of the reasons why the label needs to be configured by R&D.

It should be noted that for tags such as user packages and product packages, this means that the package must be batch-run every day and queries on the package are supported. This requires high resources, so there is generally an expiration date. If the expiration date has passed, the package will no longer be run to avoid wasting resources.

At the same time, if every request to query the tag value is to query the underlying interface or external system, it is easy to cause performance pressure. As long as the page traffic increases, it is very likely to crash other systems. Therefore, tags usually have a cache time, such as three minutes.

That is to say, if a user requests the tag value, a three-minute cache is built. Any request within three minutes will be directly returned from the cache, and the underlying data query will not be triggered. The cache will become invalid after three minutes, and the underlying data query will be triggered again when requested again.

4. Field Type

The field type mainly affects the capabilities of the rule expression. Different field types can support different rule operators. Common field types are as follows:

For example, if you only have numeric fields, you can select operators such as greater than and less than when creating a rule. If you select operators such as greater than for text fields, no judgment can be made.

If it is an enumeration type, you must fill in the field enumeration value when creating a tag. Only when the field enumeration value is filled in, you can drop down to select when filling in the field value when creating a rule.

If you are not sure about the enumeration value, you can only select the text type. When creating a rule and filling in the field value, you can only choose to enter the text value and match directly based on the text value.

5. Label testing

After the tag is created, it needs to pass the test before it can be put online. This is to ensure the accuracy of the tag configuration and avoid configuration errors going online, which may cause business personnel to mistakenly use the wrong tag when creating rules.

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

For example, for the user life cycle label, you need to input the uid and observe what the uid output value is. If it is a new user's uid, then the label output value needs to be "new user", which is in line with expectations. If it is "old user", it does not meet expectations.

Note that for custom tags, because the tag value is transparent, the input parameter is the same as the output parameter.

6. Label Application

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

As mentioned above, after a tag is disabled, the rules that have used the tag will not be automatically offline and need to be processed manually. So here you need to know what rules are associated with the tag so that you know what to process.

Therefore, knowing which rules a label is used in is helpful for subsequent inspection after label adjustment. If a label is changed, the scope of the affected rules can be confirmed, and the rules that need to be adjusted can be quickly adjusted.