【0から1】アプリ簡単構築コミュニティおすすめ

この記事では、著者のチームがコミュニティ モジュールを構築するプロセスを例として取り上げ、コミュニティの推奨事項の具体的なアイデアを整理します。

現在、自社製品の事業企画上の都合により、[コミュニティ]モジュールを構築し、第一階層のメニューバーに入り口を開設する準備をしております。これは大きな問題のようです。なぜなら、インターネット業界に携わっている学生なら、コンテンツコミュニティは産業とも言えるものであり、比較的成熟した産業市場であるということを多かれ少なかれ知っているからです。

例えば、規模が大きいものでは、小紅書や知乎などの独立したコミュニティ製品があり、規模が小さいものでは、アプリ内にコミュニティを埋め込んだKeepやNetEase Cloud Musicなどがあります（私たちは現在このカテゴリに属しています）。

第二に、「良い」コミュニティは、小さなチームがそう言うだけでは構築できません。成熟したコミュニティは、需要と供給の関係、つまりコンテンツの消費者と作成者、そして複雑な推奨アルゴリズムと切り離すことはできません。コンテンツレビューガバナンス、成長レベル、クリエイターインセンティブなどの一連のオペレーティングシステムによって運営されています。

残念ながら、現在の私たちのチームでは上記のいずれも実行できないため、この記事では私たちの考え方をまとめたいと思います。

1. ポジティブ思考の推奨

私のチームにはコンテンツの運用と製品を理解している人がいないからです。上司の指示があればすぐに仕事を始めるだけです！ （御社は順調に経営されているようですね、ハハハ）

そのため、[非専門家で資格のない] コミュニティ プロダクト マネージャーとして、コミュニティ モジュールの責任者に任命されたとき、私は畏敬の念を抱きながら、学び、考え、設計することしかできませんでした。中心的な考え方は、まずそれを小さくして（適格である）ことを確認し、実際の運用後の実践的な経験に基づいて最適化と反復を行うことでした。

始める前に、機能の流れを整理しましょう。プロダクトマネージャーとしては、どのような機能要件を受け取ったとしても、まずは順方向と逆方向のプロセスを自分で整理し、その後に設計の要点を考える必要があることを覚えておく必要があります。最後にプロトタイプを出力すると、見事に書けるようになります。

たとえば、コミュニティのポジティブなプロセス:

1) コンテンツは誰に推奨すべきでしょうか?

2) どのようなコンテンツをお勧めしますか?

3) 推奨コンテンツの量的構成はどのようなものですか?

…

最初に誰を推奨するか: ここでは、ユーザー タグとコンテンツ タグを組み合わせて、関連する推奨を作成できます。たとえば、作成時に「エンターテイメント」のタグが付けられた記事をユーザーが共有した場合、その記事を再度推奨すると、「エンターテイメント」タグが付いたコンテンツがユーザーに推奨されます。

タグ付けにはさまざまなシナリオがあり、これは別の主要なカテゴリに属します。インターネット上には多くの記事がありますので、ここでは詳細には触れません。

次に、どのようなコンテンツを推奨するか: コンテンツにもさまざまな形式があります。ここで、プロダクトマネージャーは、UGC 投稿、内部運営投稿、協力や移管のために招待された外部 PUGC、KOL 投稿、作成されたトピックなど、自社のアプリでどのようなコンテンツが制作されているかを整理する必要があります。

当社のアプリには、製品に関する相談やQ&Aもあり、これらも実際にはコンテンツ出力となっています。それらすべてを組み込むように努めます。コミュニティ内のユーザーに一度に推奨しなければならないという意味ではありませんが、適切なタイミングで修正できるように明確にしておきたいと考えています。たとえば、コミュニティ推奨ウォーターフォール フローに、製品に関する相談や Q&A カードをランダムに挿入します。

最終的な推奨量構成: 一般的に、上にプルアップして更新したり下にプルダウンして読み込む場合は、9 ～ 12 個のコンテンツが推奨されます。では、これら 12 個のコンテンツはどのように構成されているのでしょうか?

少なくとも 3 つの状況を考慮する必要があります。1 つは、コミュニティに初めて参加するときに表示する必要がある、運営側が推奨する記事などの運営側からの強力な推奨です。 1つは、人気のある記事と新鮮な記事（最近公開された記事）の推奨です。 1 つはタグ関連の推奨事項です。

拡張処理: タグの推奨を、リアルタイム閲覧タグと履歴閲覧タグの 2 つの状態に分けます。これは推奨結果を区別するために使用されます。たとえば、今日初めてコミュニティに参加し、まだコンテンツを閲覧していない場合は、履歴に基づいて推奨されます。以前に閲覧したことがある場合は、現在の閲覧結果に基づいて推奨されます。

上記の分割は、推奨アルゴリズムのロジックを理解していない（アルゴリズムエンジニアがいない）ためですが、全体的な考え方は公平性を確保することです。あらゆる種類のコンテンツが公開される機会があります。すべてのコンテンツをタグや人気のおすすめで推奨することは不可能です。

分析を続けましょう。これは推奨コンテンツの数を割り当てる問題です。最も大まかな解決策は、推奨コンテンツの数を割り当てることです。例えば、一度に 9 つのコンテンツが推奨され、人気のある記事 3 つと新しい記事 3 つが選択されます。

別の解決策としては、人気の記事には高、中、低のスコアを設定し、新着記事には公開時期に応じて高、中、低のスコアを設定するなど、コンテンツ属性ごとにスコアを設定することが挙げられます。

次に、各レベルにデフォルトのスコアが割り当てられ、最終的に記事によって蓄積された合計スコアに基づいて推奨事項が作成されます。

拡張処理: どのような状況であっても、コンテンツ ライブラリが非常に大きいことを考慮する必要があります。たとえば、記事が 1,000 件ある場合、R&D が各記事のスコアを計算して 9 件の記事を推奨するのに 10 秒以上かかることがありますが、1 回の読み込みと更新には 2 秒しかかかりません。途中で問題が発生するため、履歴タグに基づいてデフォルトの初期推奨ライブラリを作成し、その中のコンテンツをいつでも更新および置き換えるかどうかを R&D と話し合う必要があります。

2. 思考 - 逆リスク

コミュニティの逆プロセス:

1) コンテンツが足りない場合はどうなりますか?

2) 推奨事項が良いか悪いかを確認するにはどうすればよいでしょうか?

3) 新規ユーザーを推薦するにはどうすればいいですか?

……。

まず、コンテンツが足りない場合はどうなるでしょうか?大規模なユーザーベースとインセンティブポリシーがない、0 から 1 に構築されたコミュニティでは、コンテンツの出力が大きな問題となります。当社の初期コンテンツは数千の記事のみで構成されているため、この消費の問題を考慮する必要があります。初期のコンテンツ ライブラリに数万件の記事がある場合は、しばらくは移行できる可能性があります。

能力があれば、プロダクト マネージャーは会議中にリスクを提起し、コンテンツ チームおよびリーダーシップと連携して、一定量のコンテンツ (自社制作、購入、またはユーザーによる投稿) が定期的に制作され、確実に消費されるようにすることができます。

2 番目のステップは、推奨事項が適切かどうかを確認することです。コンテンツアルゴリズムによる推奨であれ、単純なロジックによる推奨であれ、推奨された結果が必ずしもユーザーやあなた自身を満足させるとは限りません。ここでは、製品は期待に応える必要があります。条件付き R&D チームは AB テスト、バケット テストなどを実行して最適化できます。現在のチームがこれを実行できないのであれば、私は貢献しません。

最後に、新規ユーザーにどのようにお勧めすればよいでしょうか?ここで別途これについて話す理由は、コミュニティの雰囲気を考慮するためです。上記の推奨ロジックを使用して古いユーザーを推奨できますが、新しいユーザーに対しても同じ方法に従うこともできます。

ただし、プロダクトマネージャーは、現在の記事の全体的な品質について考える必要があります。まず、コミュニティの雰囲気や、コミュニティが導きたいこと、表現したいことの核心を、自分たちで感じることができるでしょうか。自信がなかったり、弱い場合は、新規ユーザーの初期コンテンツとして、新規ユーザー向けの別のコンテンツを構成する操作をサポートできます。これにより、新しいユーザーが私が見たいコンテンツを見ることができるようになり、ユーザーの認識と理解が深まる可能性があります。

3. 遺産

上記はコミュニティが推奨している大まかな内容です。具体的な内容は製品によって異なります。もちろん、これは非常に単純なバージョンであることは否定できません。正直に言うと、これは会社、プロジェクト、チームによっても異なります。大規模なチームには独自のアルゴリズム エンジニアリングがあり、小規模なチームには独自の論理処理があります。

整理と学習の過程で、コミュニティガバナンス、作成インセンティブ、推奨介入、背景レビューなどの大きなモジュールのアイデアと経験について語ることはできませんが、次のような小さな考えを整理しました。私たちのコミュニティの現段階では、それらは完全には実装されていません。コミュニティを構築する際には考慮する価値があると思います。私はそれらのいくつかを列挙し、そこから推論を導き出します。

初期スコア: コンテンツがリリースされたばかりのときは、特定の初期スコアを割り当てることができます。このスコアは、ユーザー アカウントの重み値に基づいて計算できます。たとえば、UGC、PUGCの属性、プラットフォーム上のユーザーのファン、アクティブ度などを総合的に計算します。推奨ポイント: 公式オペレーターは、高品質のコンテンツやジャンク コンテンツに正または負の重みを追加し、特定の手動介入の影響を実行できます。時間減衰: 記事が公開された後、新鮮な状態から歴史的な状態までの時間減衰関数式 (ニュートンの冷却の法則) を指し、コンテンツが徐々に冷却されることを表します。

上記の部分は、最初は単純な計算式から複雑な式に移行できます。しかしながら、当社には成熟したコンテンツ制作・研究チームがないため、これらはまだ実践されていません。

良質なコンテンツの配信：推奨ロジックに基づいて、一定の興味範囲を持つ人々を優先します。記事が発酵し続けると、人気に応じてホームページに上がります。記事がホームページ推奨レイヤーで発酵し続けると、操作に手動で介入する段階に入り、バックグラウンドでボリュームをブーストするか制御するかを制御します。

第二に、これには異なるアカウントの重みが関係し、検証のために異なる量のトラフィックが分散される可能性があります。比較的公平なトラフィック分散メカニズム、ファンの関係や関心のプッシュに基づく分散メカニズムなどもあります。現時点ではユーザーベースがそれほど大きくないため、これを実装していません。

コンテンツ集約表示: コンテンツ集約機能は、異なるコンテンツ区分のディメンションに基づいて、類似のコンテンツを 1 ページに表示します。ユーザーは、特定の集約機能を通じて、すべての類似コンテンツを閲覧できます。一般的な集計機能には、セクション、サークル、チャネル、特別トピック、ラベルなどがあります。これらをどのように使用するかは、特定のビジネス モデルによって異なります。弊社の記事ベースはそれほど大きくないため、この部分は実装されていません。

コンテンツデータの入力: ユーザーインタラクションデータの量が不十分な場合、コミュニティの人気度を高め、ユーザーがコンテンツを公開した後、タイムリーに肯定的なフィードバックを得るために、いくつかの「偽の」データを入力する必要があります。

例えば、閲覧数やいいね数など、公開時に一定の範囲内で基本値を徐々に増やすことができます。コメントを入力するコストは若干高く、コンテンツが公開された後にコンテンツのコメントエリアに自動的に入力される、十分かつ一般的なコメントライブラリのセットを準備する必要があります。コメントは、さまざまなコンテンツ タグに対応するシナリオ別に分類できます。この部分はまだ実装されていませんが、コールド スタート コミュニティにとっては検討する価値があります。

著者: キャット・シャオリ

公式アカウント：Operation Growth（yunyingxq）