Vivo Mall Pricing Center-Calmly deal with price calculations in complex scenarios

1. Background

With the continuous upgrading of the business structure of the vivo mall, the more complex and changeable marketing gameplay of the entire mall has been split into an independent promotion system.

In the initial stage, the separated promotion system was only responsible for the maintenance of the marketing activities. The most important pricing business in the promotion was still left in the main website business of the mall, and due to historical construction problems, the business details page and shopping cart in the mall’s core transaction link The three pieces of pricing logic for placing orders are maintained separately and independently, and there is no uniformity. Obviously, with the increase of promotional offers or changes in gameplay, the amount of repeated development of the mall side business will increase significantly.

Independence of the promotion system, pricing-related business capabilities should also be provided by the promotion system from the business boundary, so the promotion side needs to design promotion pricing-related capabilities from scratch.

2. Original pricing business

2.1 Pricing business scenarios

The mall's original pricing business was mainly related to the business details page, shopping cart, confirming the order, and submitting the order.

If each discount that affects the final selling price is called a pricing factor, then the pricing factors that have an impact on the selling price in the aforementioned scenarios fall into three categories:

• Preferential activities (single product discount, order discount)
• Coupons (coupons, vouchers)
• Virtual deduction (points, renewal incentives)

For each pricing scenario, the pricing factor has the following relationship:

2.2 The original pricing model

For the specific implementation of the pricing business, there is a certain priority relationship between the pricing factors. As shown in the figure below, it also explains the original pricing business model to a certain extent:

3. Promotional pricing model

3.1 Hierarchical model

The promotion system builds a basic pricing ability from scratch, and must have certain guarantees for the stability and scalability of the system, and this also puts forward certain requirements for the pricing model of the promotion system. The general basic pricing model is best to have A certain amount of practical experience has been verified, so we adopt the tried-and-tested pricing model of traditional e-commerce: hierarchical pricing.

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

What needs to be explained here is that during the calculation of each level of discount, whether the threshold conditions of some discounts are met needs to rely on the original price, default depends on the price of the previous level of discount calculation , that is, the commodity-level discount calculation depends on For the original price of the product, store-level discounts depend on the calculated price of the product-level discounts, and platform-level discounts rely on the calculated price of the store-level discounts.

Special instructions for superposition rules:

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

However, in some scenarios, the business will specify that the same level of discounts can be used in stacks. At the same time, the scenarios where the stacks are used will also be divided into ordinary stacks and parallel stacks. For example: order discounts and coupons. Superposition belongs to ordinary superposition (the judgment of whether the coupon threshold is met depends on the price after the order is discounted), and the superposition of coupons and vouchers is a parallel superposition (the judgment of whether the threshold of coupons and vouchers is met depends on both of them. The price after the pre-order discount).

The benefits of the same level are divided into different dimensions: required/checked, stackable (parallel stacking/normal stacking)/not stacking .

3.2 New pricing model

3.3 Core pricing process

3.3.1 Main process

From the aforementioned pricing model, it can be known that the order of calculating the discounted price is: commodity level (CalcItem), store level (CalcShop), platform level (CalcGroup), and according to some special business scenarios, the possible interruption of business logic is added (CalcInterrupt), so the most coarse-grained pricing process shown in the figure below can be obtained;

So how are these three levels of calculated preferential prices realized internally? After business abstraction, these three levels of calculation can be turned into a general calculation preferential logic, with only preferential levels distinguished.

3.3.2 General process

After business abstraction, three levels of general logic for preferential calculation are found:

• Get Current Level PromotionGetter (Get Current Level PromotionGetter)
• Filter PromotionGetter (Filter PromotionGetter)
• Get Promotion
• Filter Promotion
• Calculate the discount through the pricing engine (Calc Engine)
• Filter CalcResult

Therefore, we have the following general pricing process:

There are several relatively flexible business-related filtering logics in the general pricing process, and more implementations can be learned from the detailed process later.

3.3.3 Detailed process

The reason why there are several filtering nodes in the general pricing process is because there are some special filtering logics in the business. For example, when the business details page is sourced, only the product-level discount finder can be used, and a certain discount can only be special Channels to enjoy and so on.

Therefore, a general and extensible filtering mechanism needs to be abstracted to achieve 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 filters shown in the figure are only part of the current business, such as according to the terminal, payment method, external business party, etc., which can be very flexibly supported in specific implementation.

How to make the above filter? And how is it related to the business?

The above figure lists part of the business customized filter sequencer. After the customized filter is automatically registered in the unified preferential business filter factory, in the aforementioned pricing process, when you need to use the relevant filter, you only need to bring the relevant filter. Context parameters can automatically obtain matching filters from the filter factory.

3.3.4 Complete whole process

Assemble a combination of the previous series of processes, and you can get a complete flow chart of pricing, as follows:

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

Fourth, the core design of the system

One node in the general pricing execution process is the "Calc Engine", which is the pricing engine. This is the core and underlying capability in the entire pricing logic, which determines whether each discount can be enjoyed by the user.

4.1 Unified discount model

Since the pricing center was under construction, there were already various discounts in the promotion system, independent coupons and vouchers, and un-migrated discounts left on the main mall of the mall. Therefore, if you want to use so many types of discounts, you must A unified preferential model is established, and the existing preferential model needs to be adapted and converted to a unified model during the construction process.

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

4.2 Offer template

1) When performing promotion pricing, each specific discount corresponds to a unique discount template. Each discount template is essentially a JSON string, but these JSON strings are metadata data that follow certain special logic rules When these meta-information are interpreted and executed by the pricing engine, they all return the boolean type to identify whether the pass or not.

2) There are several kinds of basic metadata data:

**AndMeta(和)** corresponds to the "and" relationship in the logical relationship, which means that the sub-meta-information contained in this type of meta-information is interpreted and executed when it returns true to be true;

**OrMeta (or)** corresponds to the "or" relationship in the logical relationship, which means that any interpretation of the sub-meta-information contained in this type of meta-information is true if it returns true;

**NotMeta (非)** corresponds to the "not" relationship in the logical relationship, which means that the sub-meta information contained in the meta-information of 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 result of the interpretation of the execution based on the sub meta information contained in the meta information is used as the current meta Information execution result;

**ComplexMeta (combined meta-information)** This meta-information is used as a common carrier for all templates. The meta-information contains two important information conditon and action. The relationship between the two is that only after the conditions are met, will it be executed Subsequent actions, and both condition and action may be a complex combination of the aforementioned meta-information.

3) Template meta information relationship:

4) Examples of discount templates:

{
  "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"
      }
    ]
  }
}

4.3 Pricing Engine

The pricing engine is essentially the interpretation and execution of the corresponding discount template, and the relevant context is used to calculate the discount. 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);
}

V. Summary

Through the description of the content in the previous chapters, we have basically explained the key ideas of the vivo mall promotion system to build a design price center. After the pricing center is built, the core foundation of the entire promotion system is established, but this is only the beginning. The entire mall has other content to be built around the promotion pricing center, such as the entire mall’s marketing price capability matrix and price monitoring. , Shopping mall time machine, etc., and we will have the opportunity to output related articles in the follow-up to communicate and learn with you.

Author: vivo internet server team-Wei Fuping