【0 to 1】App simple construction community recommendation

This article takes the process of the author's team building a community module as an example to sort out the specific ideas of community recommendations.

Due to the needs of our own product business planning, we are currently building the [Community] module and preparing to open the entrance in the first-level menu bar. This seems to be a big deal; because students who are engaged in the Internet industry more or less know that the content community can be said to be an industry, and it is a relatively mature industry market.

For example, on a larger scale, there are independent community products such as Xiaohongshu and Zhihu, and on a smaller scale, there are Keep, NetEase Cloud Music, etc., which embed communities in APPs (we currently belong to this category).

Secondly, a "good" community cannot be established by a small team just by saying so. A mature community is inseparable from the supply and demand relationship, that is, content consumers and creators, as well as complex recommendation algorithms; and it is operated by a series of operating systems such as content review governance, growth levels, creator incentives, etc.

Unfortunately, our current team is not capable of doing any of the above, so I wanted to write this article to summarize how we think about it.

1. Thinking-Positive Recommendation

Because there is no one in my team who understands content operations and products; we just start working because the boss wants it! (It sounds like your company is like this, hahaha)

So as a [non-professional and unqualified] community product manager, when I was assigned to be responsible for the community module, I could only learn, think and design at the same time with awe; the central idea was to try to make it small but ensure it is (qualified) first, and then optimize and iterate based on practical experience after actual operation.

Before we begin, let's sort out the functional flow. As a product manager, you must remember that no matter what functional requirements you receive, you should first sort out the forward and reverse processes yourself, and then think about the key points of the design. Finally, when you output the prototype, you will be able to write brilliantly.

For example, the positive process of the community:

1) To whom should the content be recommended?

2) What content do you recommend?

3) What is the quantitative composition of the recommended content?

…

Who to recommend first: Here you can combine user tags with content tags to make related recommendations. For example, if a user shares an article that was tagged "entertainment" when it was created, then when you recommend it again, content with the "entertainment" tag will be recommended to the user.

There are many scenarios for tagging, which belongs to another major category. There are many articles on the Internet, so I won’t go into details here.

Secondly, what content to recommend: Content also comes in many forms. Here, product managers need to organize what content is produced in their own APP, such as UGC posts, internal operation posts, external PUGC invited for cooperation or transfer, KOL posts, or created topics, etc.

Our APP also has product consultation and Q&A, which are actually also content output. We try to include all of them. It does not mean that we have to recommend them to users in the community all at once, but we want to make them clear so that we can modify them at the right time. For example, I will randomly insert a product consultation and Q&A card in the community recommendation waterfall flow.

The final recommended quantity composition: Generally, when you pull up to refresh or pull down to load, 9 to 12 pieces of content are recommended; so how are these 12 pieces of content composed?

At least three situations need to be considered: one is strong recommendations from operations, such as articles recommended by operations, which must appear when entering the community for the first time; one is recommendations for popular articles and fresh articles (recently published); and one is tag-related recommendations;

Extended processing: We divide tag recommendations into two states: real-time browsing tags and historical browsing tags. This is used to distinguish recommendation results. For example, if you enter the community for the first time today and have not browsed any content, you will be recommended based on history; if you have browsed before, you will be recommended based on the current browsing results.

The above division is because we don’t understand the logic of the recommendation algorithm (we don’t have an algorithm engineer), but the overall idea is to ensure fairness. Any type of content has the opportunity to be exposed. It is impossible for all content to be recommended by tags or popular recommendations.

Let’s continue to analyze it: it is the problem of allocating the number of recommended content. The most crude solution is to allocate the number of recommended content. For example, 9 content is recommended at a time, 3 popular articles and 3 fresh articles are selected.

Another solution is to set a score for each content attribute, such as setting a score of high, medium and low for popular articles, and setting a score of high, medium and low for fresh articles according to the release time.

Then each level is assigned a default score, and finally recommendations are made based on the total score accumulated by the articles.

Extended processing: No matter which situation you are in, you have to consider that the content library is very large. For example, if there are 1,000 articles, it may take more than ten seconds for R&D to calculate the score of each article and then recommend 9 articles, but it only takes 2 seconds to load and refresh once. There will be problems in the middle, and you need to discuss with R&D whether to make a default initial recommendation library based on historical tags and update and replace the content in it at any time.

2. Thinking - Reverse Risk

The reverse process of the community:

1) What if there is not enough content?

2) How to verify whether the recommendation is good or bad?

3) How to recommend new users?

…..

First of all, what should we do if there is not enough content? As a community built from 0 to 1, without a large user base and incentive policies, content output is a big problem. Our initial content only has a few thousand articles, so we need to consider this consumption problem. If the initial content library has tens of thousands of articles, we may be able to transition for a while.

If capable, the product manager can raise risks during the meeting and work with the content team and leadership to ensure that a certain amount of content (whether self-produced, purchased, or posted by users) is produced regularly to ensure consumption;

Secondly, is it to verify whether the recommendation is good or not? Whether it is a content algorithm recommendation or a simple logic recommendation, the recommended result may not satisfy the user or yourself. Here, the product should be well anticipated. The R&D team with conditions can do AB testing, bucket testing, etc. to optimize. My current team cannot do this, so I will not play a role.

Finally, how do we recommend new users? I would like to talk about this separately because we consider the community atmosphere. We can recommend old users using the above recommendation logic, and it is also possible for new users to follow the same method.

However, the product manager needs to think about the overall quality of the current articles. First of all, can they make themselves feel the atmosphere of the community and the core of what the community wants to guide and express? If they are weak or unconfident, they can support operations to configure separate content for new users as the initial content for new users. This will guide new users to see the content I want them to see, and users may have stronger perception and understanding.

3. Legacy

The above is a rough idea of ​​what the community recommends. The specific details vary from product to product. Of course, it is undeniable that this is a very simple version. To be honest, this also depends on the company, project and team. Large teams have their own algorithm engineering, and small teams have their own logical processing.

In the process of organizing and learning, I cannot speak on the ideas and experiences of large modules such as community governance, creation incentives, recommendation intervention, and background review, but I have sorted out the following small thoughts. At the current stage of our community, they have not been fully implemented. I think it is worth thinking about when building the community. I list some of them and draw inferences from them;

Initial score: When the content is just published, a certain initial score can be assigned. This score can be calculated based on the weight value of the user account; for example, the comprehensive calculation of UGC, PUGC attributes, the number of fans of the user on the platform, and the activeness. Recommended score: The official operation can add positive and negative weights to high-quality content or junk content, and conduct certain manual intervention. Time decay: refers to the time decay function formula (Newton's law of cooling) from freshness to history after the article is published, so that the content gradually cools down.

The above-mentioned parts can initially transition from simple calculation formulas to complex formulas; however, since our company does not have a mature content production and research team, these have not yet been put into practice.

Distribution of high-quality content: Based on the recommendation logic - priority is given to people with a fixed range of interests - if the article continues to ferment, it will rise to the homepage according to its popularity - if the article continues to ferment at the homepage recommendation layer, it will enter the stage of manual intervention in operations, and control whether to boost or control the volume in the background.

Secondly, this involves different account weights, and different amounts of traffic may be distributed for verification; there is also a relatively fair traffic distribution mechanism, a distribution mechanism based on fan relationships and interest push, etc. We have not implemented this as our user base is not very large at present.

Content aggregation display: Content aggregation function, according to the different content division dimensions, put similar content on one page for display. Users can browse all similar content through a certain aggregation function. Common aggregation functions include sections, circles, channels, special topics, tags, etc. How to use them depends on the specific business form. Our article base is not very large, so this part is not implemented.

Content data filling: When the amount of user interaction data is insufficient, it is necessary to fill in some "fake" data to increase the popularity of the community and obtain positive feedback in a timely manner after users publish content.

For example, for reading and liking, the basic values ​​can be gradually increased within a certain range when publishing. The cost of filling comments is slightly higher, and a set of general comment libraries with sufficient volume need to be prepared to automatically fill in the content comment area after the content is published. Comments can be classified by scenario and correspond to different content tags. We have not yet implemented this part, but it is worth considering for the cold start community.

Author: Cat Xiaoli

Official account: Operation Growth (yunyingxq)