How does user operation build user tags?

Building user tags is actually a very simple task, which can be divided into three steps: collecting requirements, building a tag framework, and filling in data. This is a smooth logical chain.

The labeling system is no longer a "high-sounding" term in the enterprise. However, there are not many companies that really realize the value of user tags. For example, "Teens Talk About Sex" is described in a passage that couldn't be more appropriate:

“Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it.”

My sharing today mainly includes four aspects:

• Who in the enterprise is actually building a labeling system?
• The three steps of "label system construction"
• Problems gradually exposed after "mission accomplished"
• Three ways to break the impasse

1. Who in the enterprise is actually building a labeling system?

In an enterprise, various functional roles are more concerned about "whether labels can be used" but rarely care about "who should be the builder of the labels". In fact, the construction of most enterprise labels is ultimately completed by a supporting department of the enterprise , such as the technical department or the data department.

2. The three steps of "label system construction" that seem simple

At first glance, building user tags is a simple matter. Simply put, it is just like “putting an elephant into a refrigerator” in three steps: collecting requirements – building a labeling framework – filling in data . The details are introduced below.

The first step is “demand gathering”

When building an enterprise's labeling system, the support department will shoulder "all the needs of the entire company" , so the first step is to collect the needs of the entire company. The label requirements for markets, operations, products, and technologies vary greatly.

For example, marketing colleagues focus on the overall portrait of users and pay more attention to "results". For example, they want to understand "channel attributes" and know which channels will have better user conversion effects after being launched; operations colleagues hope to understand more accurate data, so as to build user groups and realize personalized recommendations for users, such as recommending a certain activity to "users who spend more than 1,000 yuan"; product colleagues focus on personalized page displays for thousands of people; technical colleagues pursue the convenience of retrieving data, and hope that all functional lines can put all data on one platform to form a unified user information management platform, instead of retrieving data from different business systems every time a new demand is developed...

Of course, this is just a microcosm of the diversity of internal corporate needs. In fact, because there are many parties who need labels in an enterprise, even if they are all product colleagues, their understanding and needs of labels vary greatly.

The second step is "abstraction"

Faced with the "dazzling array" of demands collected, "abstraction" is a necessary step to enable the labeling system to meet the needs of multiple business lines. It needs to be abstracted into a labeling framework , which is a huge challenge. Therefore, the initial framework of the labeling system of most companies is a very large system. The initial framework usually includes: demographic information, user profiles, business data sedimentation, business party tag information, policy calculation tags , etc.

Here I will focus on explaining the "strategy calculation tag". When we label users, we often do not rely on the information filled in by the users or the basic dimension information collected, but will include labels for strategy calculations. For example, we label users who "launch the APP but have not registered for seven days" as "high risk of churn". This is a defined strategy label.

The third step is to "fill data" in the label frame

The sources of data usually include: user input, behavioral data, business-end data, policy rules, external supplements , etc.

Among the sources of "behavioral data", user segmentation is a commonly used data analysis model, such as screening out the user group of "those who have watched more than five palace fighting dramas in half a year" and labeling this group as "palace fighting fans"; "external supplement" is not only a way of supplementing data by purchasing databases. For large enterprises and large groups, multiple business lines often involve continuous exchange and mutual supplementation of data.

3. Problems gradually exposed after “the mission is accomplished”

Overall, from collecting requirements - building a label framework - filling in data, this is a very smooth logical chain. Many companies can achieve this step, but does this mean that the job is done? In fact, during my visits to companies, I found that everyone has a variety of problems, the following ones are more typical.

1. Definition and explanation of tags

Usually, the tag system construction team defines a tag called "high-value users". Based on their differentiated needs for this group, each business line has different understandings and applications of "high-value users". The tag system construction team needs to spend a lot of time explaining the definition of the tag. However, after explaining it clearly to a business line colleague, they often find that it does not meet their actual needs...

2. Update and maintenance

Tags are constantly updated. There are certain intersections and dependencies between tags, and there is a certain logical relationship behind the system. However, the business side does not understand this and is often surprised: Why did yesterday's tag data not come out, and what came out was a null value... There are various concerns when applying it.

3. New requirements

"The classification of high, medium and low value users is too coarse. I want a label between medium and high..." There will be many similar requirements, and the label system construction team will be overscheduled.

For example. During a visit to a bank client, the client asked me, "How long does it take to develop a new label?" For us, creating a new label is a very simple matter. We just need to modify the rules and run it for a few minutes, and the data will come out. In fact, the entire process took the bank's client as long as one month, from proposing the idea of ​​user segmentation, to communicating with the data department and confirming the needs, and then scheduling the development.

Why so long? Customer explanation: As a backend support department, the data department cannot communicate directly with business colleagues in terms of discourse system. For example, the concept of "high loan potential" may be relatively unfamiliar to users of the data department. Therefore, during the communication process, both parties need to communicate about each field, value, calculation rules, etc. After clarification, they may need to schedule due to insufficient R&D resources...

4. Conflicting needs

The abstracted label framework meets the needs of all business lines in the enterprise . For example, users who have not registered within seven days after launching the APP are identified as "high-risk" users. However, some business lines believe that "users who did not place an order on the same day are high-risk users." Therefore, the label system construction team is advised to modify the label, but modifying the label will affect the use of the label by other business lines.

5. Data Output

For example, the operations team will make personalized recommendations based on user groups, and the push system also requires some labels, which will cause certain complexity.

Based on the above problems, the label system construction team has been under pressure from various business lines. Although the label system was completed with great effort, it was reported internally that it was not usable.

4. Three ways to break the impasse

In the past ten years, I have been working on C-side product design and operation management, and I also have some B-side experience. My work involves labeling systems. In view of the above situation, I consider three feasible ways to break through:

1. Abandon the general framework and infer label requirements based on business scenarios

As mentioned earlier, the demands for labels by products, operations, and products vary greatly. At the same time, the demands of different operations teams also vary greatly. The comprehensive label framework is actually built from the user's perspective, but the real user of the label is the business side, so it should be implemented from a business perspective.

Therefore, the best way to deal with this is to abandon the top-level user abstract perspective, and cluster the labels according to the demands and actual application scenarios of each business line or department and provide them to the corresponding departments.

Taking the consumer operations of a certain live broadcast platform as an example, its consumer operations are divided into two categories: big R users and ordinary users. The annual consumption of big R users ranges from tens of thousands to millions, while the annual consumption of ordinary users ranges from hundreds to thousands of yuan. The operation team has completely different operational ideas for the two groups of people, so the demands for labels are also different: for big R users, the platform will provide one-to-one services for this group, so the operator needs to understand the detailed data of the big R, such as the objects of their interaction, the types of anchors they follow, etc.; while ordinary users are usually operated by user grouping. Therefore, it is impossible for us to cover the entire operation team with the same set of labels. This method of inferring label requirements based on business scenarios can be more closely aligned with business scenarios and improve usability.

2. Self-service label generation to solve efficiency and communication costs

It mainly manifests itself in three aspects.

(1) Self-service label generation can minimize communication costs. As mentioned earlier, each business line has a different understanding of the definition of labels, which requires the label system construction team to spend a lot of time communicating. If the business side can define the rules themselves, this will definitely be the way with the lowest communication cost.

(2) Self-service label generation and repeatable rules can reduce the accumulation of invalid labels. Business is constantly evolving, and if the rules remain unchanged it will be difficult to keep up with the changing pace of business. I once visited an e-commerce company. They found that the conversion rate of the "mother and baby customer group" defined half a year ago had been decreasing. Therefore, they revised and redefined the "mother and baby customer group" rules according to the actual situation and named it "mother and baby customer group (new)". At this time, the previous rules were invalid and would continue to occupy computing resources... If the rules can be repeatedly modified, this type of invalid labels will disappear in large numbers.

(3) Release the manpower of the data team and unleash the imagination of the business team. The data team should spend more energy on the entire data platform or new business model of the enterprise, rather than dealing with label demands and label maintenance of each business line. Automated label generation can greatly save manpower and unleash the team's imagination.

For example. There is an online fitness APP that has made in-depth application of the Sensors tag system. The entire process from tag creation to push action completion takes no more than half an hour, which means that they can evaluate the effectiveness of a push activity within half an hour. They once told me an interesting story: the company launched a lumbar repair course for white-collar workers. After screening out user groups based on user segmentation, it was found that the effect was not good. Then, in-depth research revealed that the characteristics of the group that is easy to stick to this course are: people with a higher BMI index. The team then created a new operating plan and ultimately achieved better results.

We can see from this case that once business personnel can quickly access and create tags, this will give them a lot of room for business imagination and allow more high-quality operational scenarios to be implemented.

3. Effective tag management mechanism

An effective label management mechanism is mainly reflected in the following aspects.

(1) Rule and metadata maintenance: Tag-related rules and metadata should be exposed to users as much as possible, so that users can clearly know the tag rules, who created the tag, who maintains the tag, and the update frequency of the tag when using the tag. This is not the case with no rules at all, or with the rules being stored in a word document within the tag construction team.

(2) Scheduling mechanism and information synchronization: There are some connections between tags, and the chain between tags is broken. Is there a scheduling mechanism or information synchronization mechanism to ensure that everyone's work is not affected?

(3) Efficient and unified output interface: All business information and user data information are aggregated together, with a unified output interface, changing the previous situation where different interfaces needed to be developed for different business systems.

We review the three ways to break the deadlock, which essentially solve the problems of value, means, and sustainability : reverse the requirements based on business scenarios, let the business side use it as the ultimate goal, so that the value of the label system can be realized; self-service label generation, it solves the problem of what means we use to realize value; an effective label management mechanism means whether a label system can operate sustainably in an enterprise.

In short, the most important thing for an enterprise is whether a labeling system can be used in business and cover a wider range of needs, rather than a large and comprehensive framework.

Related reading:

1. User operation: new funnel model for conversion analysis!

2. User operation: How to use B-side operation thinking to increase user growth?

3. Product operation: How to use data analysis to drive product user growth?

4. APP user growth: One model solves 90% of growth problems!

5.How to increase users? Take Pinduoduo and Xiaohongshu as examples

6. Triggering user growth: Is user operation just about attracting new users?

7. User operation: What else can you do to attract new users without fission users?

8. User operation: how can financial products awaken dormant users?

9. User operation: How to make use of private domain traffic?

Author: Zhang Tao

Source: Sensors Data