With the continuous upgrading of the business structure of vivo mall, the more complex and changeable marketing methods of the whole mall have been split into an independent promotion system.

In the initial stage, the split promotion system is only responsible for the maintenance of the playing method of marketing activities. The most important pricing business in the promotion is still left in the main station business of the mall. Due to historical construction problems, the pricing logic of the business details page, shopping cart and order in the core transaction link of the mall is maintained separately and not unified, Obviously, with the increase of promotions or changes in playing methods, the amount of repeated business development on the mall side will increase significantly.

The promotion system is independent, and the pricing related business capabilities should also be provided by the promotion system from the business boundary. Therefore, the promotion side needs to design the promotion pricing related capabilities from scratch.

2, Original pricing business

2.1 pricing business scenario

The original pricing business of the mall mainly involved the business scenarios of business details page, shopping cart, order confirmation and order submission.

If each discount affecting the final selling price is called a pricing factor, the pricing factors affecting the selling price in the above scenarios are divided into three categories:

• Preferential activities (single product discount, order discount)

• Coupons (coupons, vouchers)

• Virtual deduction (points, renewal incentives)

Each pricing scenario has the following relationship with pricing factors:

2.2 original pricing model

For the specific pricing business, there is a certain priority relationship between the pricing factors. The synthesis is shown in the figure below, which also explains the original pricing business model to a certain extent:

3, Promotion pricing model

3.1 layered model

To build the basic pricing capability of the promotion system from zero, there must be a certain guarantee for the stability and scalability of the system, which puts forward certain requirements for the pricing model of the promotion system. The general basic pricing model should preferably have been verified by some practical experience. Therefore, we adopt the traditional e-commerce's proven pricing model: layered pricing.

The so-called layered pricing refers to the three levels of concessions involved in traditional e-commerce: commodity level, store level and platform level. Under normal circumstances, different levels of concessions can be superimposed by default, and the same level of concessions are mutually exclusive by default.

It should be noted here that when calculating the discount of each level, whether the threshold conditions of some discounts are met or not depends on the original price. By default, it depends on the price after the discount calculation of the previous level, that is, the commodity level discount calculation depends on the original price of the commodity, and the store level discount depends on the price after the commodity level discount calculation, Platform level discount depends on the price calculated by store level discount.

Special instructions for stacking rules:

Normal discount superposition means that two discounts can be enjoyed at the same time. For different levels of discounts, they are superimposed by default. For the same level of discounts, they are not superimposed by default. For example, under normal circumstances, only one coupon of various types can be used under the coupon.

However, in some scenarios, the business will specify that the discounts at the same level can be superimposed. At the same time, the scenarios specifying superimposed use will also be divided into ordinary superimposition and parallel superimposition, For example, the superposition of order discount and coupon belongs to ordinary superposition (the judgment of whether the coupon threshold is met depends on the price after the order discount), and the superposition of coupon and voucher belongs to parallel superposition (the judgment of whether the threshold of coupon and voucher is met depends on the price after the previous discount).

Preferences at the same level are divided into: required / checked, stackable (parallel overlay / normal overlay) / non stackable according to different dimensions.

3.2 new pricing model

3.3 core pricing process

3.3. 1 main process

From the above pricing model, we can know that the order of calculating the preferential price is: commodity level (CalcItem), store level (CalcShop) and platform level (CalcGroup). In addition, according to some special business scenarios, possible interrupt business logic (CalcInterrupt) is added, so the coarsest pricing process shown in the figure below can be obtained

How are these three levels of preferential price calculation realized internally? After business abstraction, the calculation of these three levels can become a general calculation preference logic, with only the distinction of preference levels.

3.3. 2 general process

After business abstraction, we found the common logic of three levels of discount calculation:

• Get the discount query of the current level

  (Get Current Level PromotionGetter)

• Filter discount query

  (Filter PromotionGetter)

• Get Promotion

• Filter Promotion

• Calculate discount through pricing engine (Calc Engine)

• Filter CalcResult

Therefore, we come to the following general pricing process:

There are several relatively flexible business-related filtering logic in the general pricing process. You can learn more about the implementation from the following detailed process.

3.3. 3. Detailed process

The reason why there are several filtering nodes in the general pricing process is that there are some special filtering logic in the business. For example, when the source of the business details page, you can only use the commodity grade discount query, and a discount can only be enjoyed through special channels.

Therefore, a general extensible filtering mechanism needs to be abstracted to realize business requirements. Therefore, some chain filters will be customized according to different dimensions. The execution process is shown in the following figure:

Of course, the different dimension amount filters shown in the figure are only part of the current business, such as terminal, payment method, external business party, etc. These can be flexibly supported in specific implementation.

How is the above filter formulated? And how does it relate to the business?

Some business customized filter sequencers are listed in the figure above. After customizing the filter, it will be automatically registered in the unified preferential business filter factory. In the above pricing process, when relevant filters are needed, only relevant context parameters can be brought to automatically obtain matching filters from the filter factory.

3.3. 4. Complete whole process

A complete flow chart of pricing can be obtained by combining and assembling the previous series of processes, as follows:

From this complete flow chart, we can see a general and stable core pricing process and a customized filter that supports changeable business, which not only ensures the stability of the core, but also retains flexible expansion.

4, System core design

In the general pricing execution process, one node is the "Calc Engine", that is, the pricing engine, which is the core and bottom capability in the whole pricing logic. It determines whether each discount can be enjoyed by users.

4.1 unified preferential model

Since the shopping mall has the first mock exam, the independent coupons and vouchers, and the unmigrated concessions left at the mall's main point when the pricing center is being built, it is necessary to establish a unified preferential model to accommodate all the preferential types. In the process of construction, the existing preferential models should be adapted to the unified model.

Some key information in the unified preference model includes: preference id, preference type, preference template id, start and end time, preference parameters and some extension parameters.

4.2 discount template

1) During promotion pricing, each specific offer will correspond to a unique offer template. Each offer template is essentially a JSON string, but these JSON strings are transformed from meta information data following certain special logic rules. When interpreted and executed by the pricing engine, these meta information will return Boolean type identification to indicate whether they pass.

2) There are several basic meta information data:

Andmeta (and)

The "and" relationship in the corresponding logical relationship indicates that the sub meta information contained in the meta information of this type returns true when interpreted and executed;

Ormeta (or)

The "or" relationship in the corresponding logical relationship indicates the sub meta information contained in the meta information of this type. If any interpretation returns true, it is true;

Notmeta (non)

The "not" relationship in the corresponding logical relationship indicates that the sub meta information contained in the meta information in this type is interpreted as false and the current meta information is true;

Conditionalmeta (condition)

If the condition parameter does not exist or the Boolean value specified by the parameter obtained from the context is not true, the current meta information returns true. Otherwise, the execution result is interpreted according to the sub meta information contained in the meta information as the execution result of the current meta information;

Complexmeta (composite meta information)

As the general carrier of all templates, the meta information contains two important information condition and action. The relationship between the two is that subsequent actions will not be executed until the condition conditions are met, and both condition and action may be a complex combination of various meta information mentioned above.

3) Template meta information relationship:

4) Example of offer template:

{  "type": "COMPLEX",  "condition": {    "type": "AND",    "metas": [      {        "type": "CONDITIONAL",        "metas": [          {            "type": "CONDITION",            "metaCode": "terminalCheckCondition"          }        ],        "param": "needTerminalCheck"      },      {        "type": "CONDITION",        "metaCode": "amountOverCondition"      }    ]  },  "action": {    "type": "AND",    "metas": [      {        "type": "ACTION",        "metaCode": "cutPriceAction"      },      {        "type": "ACTION",        "metaCode": "freezeCouponAction"      }    ]  }}

(slide view)

4.3 pricing engine

The pricing engine is essentially the interpretation and execution of the corresponding discount template, and performs discount calculation in accordance with the relevant context. The key codes are as follows:

private boolean executeMeta(Meta meta, EngineContext context) {    if (meta instanceof AndMeta) {        return executeAndMeta((AndMeta)meta, context);    } else if (meta instanceof OrMeta) {        return executeOrMeta((OrMeta) meta, context);    } else if (meta instanceof NotMeta) {        return executeNotMeta((NotMeta)meta, context);    } else if (meta instanceof ComplexMeta) {        return executeComplexMeta((ComplexMeta)meta, context);    } else if (meta instanceof ConditionalMeta) {        return executeConditionalMeta((ConditionalMeta)meta, context);    } else {        return executeIMeta(meta, context);    }} ...... private boolean executeComplexMeta(ComplexMeta complexMeta, EngineContext context) {    Meta condition = complexMeta.getCondition();    Meta action = complexMeta.getAction();    return executeMeta(condition, context) && executeMeta(action, context);} private boolean executeConditionalMeta(ConditionalMeta conditionalMeta, EngineContext context) {    PromotionContext promotionContext = context.getPromotionContext();    if (promotionContext == null || promotionContext.getParameters() == null) {        return true;    }     String conditionParam = conditionalMeta.getParameter();    String sNeedProcess = promotionContext.getParameters().get(conditionParam);    if (sNeedProcess == null) {        return true;    }     boolean needProcess = Boolean.parseBoolean(sNeedProcess);    if (needProcess) {        return executeMeta(conditionalMeta.getMetas().get(0), context);    } else {        return true;    }} private boolean executeIMeta(Meta meta, EngineContext context) {    IMeta iMeta = MetaFactory.get(meta.getMetaDef().getMetaCode());    if (iMeta == null) {        throw new CalcException("meta not found, metaCode=" + meta.getMetaDef().getMetaCode());    }     return iMeta.execute(context);}

(slide view)

5, Summary

Through the description of the contents in the previous chapters, we have basically expounded the key ideas of building a pricing center for the promotion system of vivo mall. After the construction of the pricing center, the core foundation of the whole promotion system will be established, but this is only the beginning. The whole mall still has other contents to be built around the promotion pricing center, such as the marketing price capability matrix, price monitoring, mall time machine, etc. of the whole mall, and we will output relevant articles in the future, Communicate and study with everyone.