E-commerce promotion activities operation analysis

Have you ever encountered an e-commerce platform company calling you for a follow-up call? Sometimes they even offer a series of discounts. In fact, e-commerce platform companies often take a series of operational activities to achieve new user conversion or repeat visits and repurchases from old customers.

1. Activity Form

The activities can be summarized into three types: one is direct discount or full discount with coupons, one is cash back or coupons, and the third is purchasing goods at a low price.

1. The first type, as the name suggests, is activities like the red envelopes issued by Taobao or the 30 yuan discount for purchases over 200 yuan on Double Eleven. If you meet certain activity rules, you can directly deduct part of the amount when you pay.
2. The second type is activities like Pinduoduo's group buying, bargaining, or Xiaomi Youpin's instant rebate for orders, where a certain amount of money is spent on the purchase and certain operating activity rules are met, and then the user will be given cash or red envelopes.
3. The main ways to buy goods at a low price are to directly reduce the amount of a single item or to directly reduce the amount of added items, which can increase user conversion or average order value respectively.

2. Product design and module analysis

Figure 1 Operational activity product module analysis diagram

Operational activities are generally divided into front-end page display and back-end system support. To facilitate understanding, the mind map is also divided into front-end and back-end:

• The front end mainly focuses on the user's path, so the pages involved need to be split in detail. For example, general activities will have separate activity pages, and the personal center will have corresponding coupons or amount descriptions. In addition, it also involves user guidance on the main path, such as activity information on the product details page, discount guidance on the order payment page, and discount options on the payment page. In addition, there are also basic data points to facilitate data analysis of future activities.
• The backend mainly cooperates with operational activities, and the transaction systems involved need to be compatible with the preferential information or other content of this activity, such as the rules for allocating red envelopes for multiple items in an order. In addition, there is information compatibility with the financial system, after-sales, customer service, and CRB system. In addition, because the red envelopes in e-commerce activities are often real money discounts, we will also pay attention to the wool party and set up corresponding anti-wooling rules.

This article mainly conducts further analysis from the back-end system.

3. Activity Configuration

When creating an activity, a series of configurations are required, as well as product selection for the activity. Products for events are generally selected by calculating the discount amount ratio and the actual profit of the product. If the activity gives too much discount and the product cannot achieve profitability, then the product should be kicked out of the activity pool. It can be seen that activity configuration involves several modules: activity management, product management, and activity product pool management.

Activity management should involve configuring the activity switches and activity rules for operations. For example, what kind of people is the activity aimed at? Is the activity restricted by region, channel, or time? Will the activity return red envelopes or cash? What form and denomination of red envelopes will be returned? Activity management controls and displays a series of activities. If the platform has many forms of activities and the configuration of each activity is not universal. The secondary modules can be further subdivided to manage different forms of activities.

Product management is the display of all products that can participate in the event. Including the product's SPU, SKU, product price, required attributes, merchant name, inventory, etc. In addition, it is necessary to display the log of inventory changes of goods.

The activity product pool, that is, the available product pool corresponding to each activity, can configure multiple product pools, but only one can be in use. If the activity has independent inventory, it also needs to be set up, that is, other activities cannot use the inventory of this part of the goods.

Finally, generally speaking, e-commerce promotion activities are inseparable from the rules of various operational activities. Clarify the elements, rules and configurations of each activity and integrate them into modular content. On the one hand, this can meet the scalability of the product, and on the other hand, it can avoid the need to re-release the front-end version after modifying the rules.

Figure 2 Functional module diagram of operation activity system

4. Trading System

Every activity will inevitably involve changes or compatibility of the trading system. The key to the trading system lies in the order type, order status, order amount, and order discount.

Prerequisite: The order system of our preset platform has been widely used and has become an order middle-office service. Therefore, when there are new activities, we generally do not modify the existing logic of the order.

Order type: If it is incompatible with the existing order logic, then in order not to modify the general rules, you can consider encapsulating the existing order, or write an independent activity order separately, and then use the activity order to correspond to the ordinary order. For example, buy an order and get a product for free. For the convenience of record keeping, a separate activity sheet can be made to record the eligibility for participating in the giveaway activity and the status of the gifted merchandise sheet. Use activity sheets to package and associate regular orders with free product orders. Design activity sheets individually.

Order status: It is best not to modify the status of an order casually, so if there is a new business activity, we consider the state machine of the activity order. Consider the following moments separately: order creation (order placed and awaiting payment), order payment successful, order payment cancellation, order in production, order shipment, order receipt, order closure, order refund, and the activity order statuses corresponding to different order statuses. When creating an order, check the activity rules to see if it can be created successfully. When paying for an order, consider whether the business can use various existing coupons, etc. When canceling a payment, will it be automatically canceled if it times out or do I have to cancel it proactively? After an order is refunded, how are the various discounts returned? Can the ordered items be returned individually (gifts are not refundable? How to prevent freeloaders?).

Order amount: how to calculate the payment amount and allocate coupon discounts to each product and each order. How the discounts and amounts are returned to the user's account after a refund.

For example: a user’s red envelopes can be used in combination, but multiple items are purchased. Before the refund, the user had newly obtained red envelopes, and there were red envelopes in the account that had reached the expiration date. So when we consider returns, the return logic of red envelopes is:

Figure 3 Red Envelope Refund Logic Diagram

In addition, you can also choose to create a new red envelope according to the refund amount, which depends on the specific operating rules.

V. Others

In addition, when designing e-commerce promotional activities, it is also necessary to consider the necessary front-end embedding points to facilitate subsequent data analysis; the financial system must consider the compatibility of new order types and new discount methods; CRB must involve user recalls or event push, etc.; the customer service system must take into account the user's question scenarios and the information query list required by the customer service, etc.

VI. Conclusion

When a product is sorting out new ways of playing, it often involves a wide range of aspects. There will be upstream and downstream interactions between modules, and the back-end modules will also be related to the front-end. So there are a lot of details, and it is very important to synchronize good information with upstream and downstream frequently. If necessary, multiple internal audits can be conducted. In addition, attention should also be paid to communication with the technical team. During the meeting, the technical team of a certain module may only listen to the PRD presentation of the product they are directly connected to, but fail to hear the presentation of the related module. Technical communication and coordination of the product is required in advance.

Finally, after the system goes online, it is necessary to conduct timely training with the business side, track user feedback, and observe data to optimize and iterate the version.

Author: Take a Pulse

Source: Take the Pulse