Review: The ups and downs of a marketing campaign

A marketing campaign, from planning to implementation, often goes through many steps and requires a certain amount of manpower and material resources. The author of this article reviews a marketing campaign he experienced and shares with us the process of the campaign and the pitfalls encountered in the process. He hopes that this will help everyone avoid detours in future marketing activities.

PV20w, maximum concurrency 2w, activity flow 4.2 million, and fan interactions exceeding one million. These are the data left by a marketing campaign. It may seem commonplace to you, but for me, it is the first time for a young lady to ride in a bridal sedan. I will not go into detail about the specific process, but I would like to share with you some of the pitfalls I encountered as a warning.

1. The project launch time is too tight

The activity was proposed directly by the company boss, and the time given was 1 month. It involved functional transformation of multiple existing products, numerous product rule verifications, and new b/c-end demands. The first step caused me, a product dog, to work overtime.

From the perspective at that time, I really had run out of ideas. I had written down all the aspects I could think of in the documents. However, after entering the development and going online, I kept discovering the problems that I had missed at the beginning. I shouldn't have done that. In the end, the testers raised a lot of questions about the product and raised some issues for me.

1. When planning new features, you should carefully describe the source, status, and switching rules between different states of each new field in the document (a very important step, you must think carefully);
2. For functional-level interactions, you need to confirm with the developer for completeness, including every button and the effect of the user’s operation. (Because I was busy, I just threw the document over and didn’t care about it. As a result, the developer had ambiguity in understanding the interaction and wasted a lot of time. Even if there is not enough time to make a complete interactive prototype, you still need to communicate with the developer about the details of the interaction.)

In summary, when writing a requirements document for a marketing campaign, it should be broad and comprehensive, involving the connection between multiple product lines and multiple systems, and the detail granularity should take into account every field, button and interaction.

2. Many business changes

The urgency of time led to a very funny phenomenon: I was perfecting the requirements, developing the code, and the business was updating the business rules. As a result, my requirement document was modified slightly every 2 days and significantly every 3 days. The most common phrase asked by developers was "changed again?". I was truly crossing the river by feeling the stones, which was very punk!

Of course, this is not a good thing, and it is not recommended for everyone to imitate it. In addition to the repeated jumps in business rules, at the product design level, it is still very "friendly" in putting forward other people's views and opinions (the kind that changes 2 versions of the interface in one day).

So this pit is big enough, and some solutions are proposed.

1. When the business/marketing department issues activity planning documents, as a technical product, it needs to read them word by word to identify problems. For ambiguous dates and quantities, there must be clear numerical measurements. The date needs to be accurate from the day to the second, and the quantity must be accurate to the maximum and minimum values.
2. If development is required when business rules are uncertain, let the business first determine the overall rules, starting from the big rules and then down to the small details, standardizing them step by step. Once they are finalized, development can also be implemented from the big framework to the details.
3. "Listen carefully, but don't do it. Dig deep into the needs behind it." You may have heard this before, but it is difficult to do. It requires strong authority and sufficient responsibility for the product. I ask myself if I have not achieved this yet.

3. Problems exposed after going online

After nearly 2 months of hard work, the product is finally ready for launch. Unexpectedly, we were so anxious and exhausted afterwards. The event was "very successful" and various data showed that the popularity of the event far exceeded expectations. However, we were not prepared for an event of this magnitude that far exceeded expectations.

1. The first serious problem after going online was overselling of promotional items

Let me briefly describe the previous order transaction design. After the user clicks to pay, the system generates an order and occupies a product quota. If the user does not make payment within 10 minutes, the order transaction will be closed and the quota will be released. I wonder if you gentlemen can see the problem here.

Due to the huge amount of concurrency, a problem occurred. The time it took for the database to process the order exceeded 10 minutes, that is, (the user paid the order, but the user's payment callback processing queued in the system for more than 10 minutes) the user paid.

However, we did not receive any payment message (the message was queued), so we sold the goods again. This cycle led to serious overselling. We sold 5,000 sets of the goods instead of 2,000 sets (the goods were basically sold at a loss).

This could be considered a major production accident. After reporting it to the boss, he said it was not a big problem and could be handled. So later the public relations department posted on Weibo that "due to everyone's strong desire to buy, the business department has increased the sale several times." This was a great way to handle it.

2. The second problem is that due to the large number of new users, problems with the account system have emerged

In our original account system, one piece of user data corresponds to a mobile phone number/email address + real-name user identity information. When a user uses a new mobile phone number, the system will register him as a new user.

Moreover, the user cannot verify his/her real name because the identity information has been bound to the old account, but the old account's mobile phone number is no longer useful. This is a dead end, and there are a series of problems such as users who previously registered with an email address being judged as new users after using a mobile phone number.

The core point is that the original account system design had a lot of problems, but there were no major problems when facing old users. However, when facing a large number of new users, the original design flaws were exposed.

Summary: When designing a trading system, you should consider perfection. In addition to the common logic of selling goods by paying with one hand and collecting money with the other, you also need to consider a series of problems caused by excessive system data volume under high concurrency, excessive callback requests, slow processing speed, and other abnormal trading logic.

Solution:

1. In the design of the trading system, the result of order payment should be based on the payment callback rather than the system time. That is, after you place an order, I judge whether the transaction is successful/invalid, and the transaction result should be determined based on the transaction callback. I won’t go into details about the transaction system under high concurrency, I will just introduce one method here;
2. The front end makes restrictions based on the system operation status. When the server is fully occupied or the database queue exceeds a certain number, the number of new accesses is restricted from the front end;
3. In the design of the account system, the core of the account system should still be based on people. However, there will definitely be situations where one person has multiple accounts. This may be a good thing for ordinary e-commerce companies, but it may not be the case for companies that have strict requirements on user data. I will have the opportunity to share my views on the construction of the member account system and the handling of exceptions in the future.

To sum up, the problems that exist as a product are:

1. The project's early requirements were not clear and detailed enough;
2. During the product development stage, the product rhythm is out of control and the product's phased time should be strictly controlled.

Everything has a first time. I believe that next time I encounter such a large-scale marketing campaign, I will be able to handle it with ease. This is the first article of a junior product dog, and I hope it will be useful to you.

Author: Shen Wansan

Source: Shen Wansan