The background,

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

Promotion system after the splitting of the early is only responsible for the maintenance of the marketing activities play, in the promotion of the most important valuation business still left in the main business in the mall, and due to the historical construction problems, mall core transaction link zhongshang detail page, shopping cart, order these three pieces of logic about valuation are separate independent maintenance, no unified, Obviously with the increase of promotional offers or gameplay changes, the amount of repeated business development mall side will significantly increase.

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

Original valuation business

2.1 Pricing Service Scenarios

The original pricing business involved in the mall is mainly a detailed page, shopping cart, order confirmation, order submission these several business scenarios.

If every discount that affects the final selling price is called the pricing factor, the pricing factors that affect the selling price in the preceding scenarios can be classified into three categories:

  • Preferential activities (single product discount, order discount)

  • Coupons (coupons, vouchers)

  • Virtual deduction (Points, new bonus)

The relationship between each pricing scenario and the pricing factor is as follows:

2.2 Original pricing model

There is a certain priority relationship among the pricing factors in the specific pricing business, as shown in the figure below, which also illustrates the original pricing business model to a certain extent:

3. Promotion pricing model

3.1 Layered Model

Pricing ability to promotion system from zero to build foundation for system stability and expansibility must have a certain security, and it is for promotion system of valuation model is put forward certain requirements, the basis of general valuation model is best can have certain practical experience verified, so we used the traditional electricity proven valuation model: hierarchical valuation.

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

Here to be sure, every level of discount calculation, the threshold condition for some preferential whether meet the need to rely on the original price, on by default is dependent on a hierarchy of preferential prices after the calculation, the commodities level discount calculation relies on the original price, discount store level depends on the commercial grade preferential prices after the calculation, Platform-level discounts rely on store-level discounts calculated after the price.

Stacking rules specify:

Normal superposition means that two discounts can be enjoyed at the same time. The default value is superposition for discounts of different levels, but not for discounts of the same level. For example, under normal circumstances, only one coupon of various types can be used.

However, in some scenarios, the business will specify the same level of discount can be superimposed, and the scenarios specified for superimposed use will also be divided into ordinary superimposed and parallel superimposed, for example: Order discounts and coupons a superposition of the two type is belong to the ordinary superposition (coupons threshold meets after judgment depends on the order preferential price), coupons and vouchers are parallel superposition (coupons and vouchers whether meet the judgment depends on the threshold of the preferential price after the preamble of the two).

Discounts at the same level are classified into: Required/selected, Superimposed (parallel superimposed/Ordinary superimposed)/ Non-superimposed.

3.2 New pricing model

3.3 Core pricing process

3.3.1 main process

It can be known from the above pricing model that the sequence of preferential price calculation is as follows: Commodity level (CalcItem), store level (CalcShop), platform level (CalcGroup), and possible business interrupt (CalcInterrupt) are added for some special business scenarios, resulting in the coarsest grained invoicing process as shown in the figure below.

Then how does the calculation of the three levels of discount price come true internally? After business abstraction, these three levels of computing can be turned into a general computing preference logic, only the preference level is distinguished.

3.3.2 General process

Through business abstraction, common logic for three levels of preferential computing is found:

  • Get Current Level PromotionGetter for the Current Level

  • Filter PromotionGetter

  • Get Promotion

  • Filter Promotion

  • Calculate discounts through the Calc Engine

  • Filter CalcResult

Therefore, the general pricing process is as follows:

There are several relatively flexible business-specific filtering logic in the common invoicing process, and you can learn more about the implementation in the detailed process below.

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 discussing the source of the page, you can only use the commodity level offer finder, and a special offer can only be enjoyed by a special channel.

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

Of course, the different dimension filters shown in the figure are only a part of the current business, such as by terminal, payment method, external business party and so on, which can be very flexible when implemented.

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

In the figure above, some customized filters are listed, and the customized filters will be automatically registered in the unified preferential service filter factory. In the preceding pricing process, when relevant filters are needed, matching filters can be automatically obtained from the filter factory with relevant context parameters.

3.3.4 Complete the whole process

The previous series of processes for a combination of assembly, you can get the full valuation of the complete flow chart, as follows:

From this complete flowchart, you can see a common stable core pricing process and a custom filter that supports business variability, ensuring core stability while retaining flexible scalability.

4. System core design

One node in the general pricing execution process is the “Calc Engine”, also known as the pricing Engine, which is the core underlying ability in the whole pricing logic to determine whether each discount can be enjoyed by users.

4.1 Unified discount model

Due to valuation center at the time of construction, has been around for each preferential activities, independent of the system to promote the coupons and vouchers, legacy in the master station not migration of preferential, so want to use compatible with so many preferential type, inevitably requires the establishment of a unified preferential model, and in the process of construction should be to transform the existing preferential model adaptation to the unified model.

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

4.2 Discount Template

1) when making promotional pricing, each concrete preferential discount will correspond to a unique template, each preferential template is essentially a JSON string, only the JSON string is by following a special logical rules of meta information data transformation, and the meta information to explain the execution was denominated in engine, whether is return Boolean type identification through.

2) There are several kinds of basic metadata data:

**AndMeta(and) ** corresponds to the “and” relation in the logical relation, indicating that the meta information contained in the sub-meta information interpretation execution returns true.

**OrMeta(or) ** corresponds to the “or” relation in the logical relation, indicating that any child meta information contained in the meta information of this type is true if it is returned by the interpretation execution;

**NotMeta(not) ** Corresponds to the “not” relation in the logical relation, indicating that the child meta information contained in the meta information of this type is interpreted as false and the current meta information is true.

ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta(conditional) ConditionalMeta

** A ComplexMeta that serves as a universal carrier for all templates. It contains two important elements: conditon and Action. Subsequent actions are executed only when conditions are met. Both condition and action can be complex combinations of the various meta-information described above.

3) Template meta-information relationship:

4) Sample discount 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"}}}]Copy the code

4.3 Pricing Engine

The pricing engine is essentially the interpretation and execution of the corresponding discount template, and carries out the 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 {
        returnexecuteIMeta(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);
}

Copy the code

Five, the summary

Through the description of the content of the previous several chapters, we basically put vivo mall promotion system construction pricing center of the key ideas elaborated. After the construction of the valuation center, only stood at the core of the whole promotion system, but this is just a beginning, the mall around promotional pricing center to still have other the contents of the construction, such as the entire mall marketing price ability matrix, the price monitoring, mall a time machine, etc., and the content we later have the opportunity to also can output related articles in succession, Communicate and learn with others.

Author: Wei Fuping, Vivo Internet Server Team