This article provides an in-depth look at SKU management strategies in the User Growth Framework and shares real-world experiences to help you optimize your product portfolio and improve operational efficiency.
Please read the frame structure of the first few sheets first. Now let's move on to the SKU layer. Generally, non-self-operated e-commerce platforms, under the same leaf category, such as lipstick, there may be thousands to hundreds of thousands of products released by merchants, some teams are used to calling it detail, and some are called detail page (abbreviated dp), which I call it item.
Many teams mistakenly think that the item or the next layer of the item is the SKU, which is very wrong. This also led to a large number of follow-up problems. The reason is likely to be a bad review or a technical team using its own technical structure for a non-proprietary platform business. I don't know the basic definition of SKU.
Keep in mind that we're addressing two things:
- What the user needs, such as a lipstick in shade 19
- Which supplier provides the product/content that can best serve the customer
In the snack consumption scenario shown in the figure below, the solutions include puffed food, beverages, etc. Each compartment corresponds to a series of SKUs, which are then assigned to SKUs according to the recipe.
My frame of mind is as follows:
As a rule of thumb, it's not surprising that a common item can be posted by up to 20 merchants repeatedly. With the help of the power of the algorithm, it is possible to automatically aggregate 90%+ items, such as this lipstick with SKU = color number 19, there are 6 duplicate releases from different merchants. But the user needs solved are exactly the same.
In this way, many businesses do not do business logic, and directly rely on the ability of the algorithm team to optimize. It's like allowing users to bypass the model room and go directly to the warehouse to select goods. And this warehouse includes all industries and all businesses. The complexity of the problem faced by the algorithm team has increased by several dimensions, but the effect has been greatly reduced.
The scariest thing is the problem of traffic management. The traffic allocation strategy in the following figure can be regarded as a channel media or an algorithm strategy for its own traffic. Generally, we set a goal, postback/collect all user behavior process data, attribute to the goal, and get an optimal distribution direction. Updated on a regular basis, the update cycle is fixed. However, due to the dynamic changes in the service capabilities of items, the user experience is not necessarily optimal. Factors that vary include, but are not limited to:
- Stock
- The seller changes the price
- Changes to the platform's preferential policies
- The seller's operation is not online, and the buyer needs to consult before placing an order
For example, the first item in the figure below is selected by the strategy and prioritizes drainage, accounting for 85% of the total. As a merchant, after discovering a sudden increase in traffic, because the inventory is limited, it cannot be captured immediately, is the best strategy to increase the price immediately?
If this traffic strategy comes from the media, it is essentially handing over the traffic distribution power from oneself. Some businesses use the data structure of Google Shopping/Facebook Catalog for placement, and it is common for an item to cost more than $1,000 and be suddenly removed from the shelves. It can be said that 90% of the budget is unable to accumulate data. The bear breaks the stick, it's too apt.
What's even more terrifying is that the cycle of updates may be calculated on a weekly basis. Most platforms lack data at the finest granularity, but N items, the data used for decision-making are also divided into N parts, and the data is more diluted. No matter how good the algorithm is, it can't do good results.
Adopting my framework solves this problem. Because all items are clustered into SKUs in advance, the target of the diversion is the SKU, which solves the needs of users. The next layer of logic is to consider how to divide internally.
This article was originally published by @达太 on Everyone is a Product Manager. Reproduction without the permission of the author is prohibited
The title image is from Unsplash and is licensed under CC0
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services