製品運用: 製品の成長戦略をどのように開発するか?

グロースハックの概念が中国に導入されてから、皆さんの共同の努力により、今ではインターネット業界でよく知られるようになりました。私もいくつかの記事を執筆するなど、グロースハックに関わることができて幸運でした。このため、新しい友達からよく次のような質問を受けます。

1. 製品の成長をどのように計画しますか? どこから始めるべきでしょうか?
2. チームが弱すぎて、ハッカーの成長モデルやコンセプトを実装するのが難しいですか?
3. 記事を読んで、あなたから学びました。どのようにして成長を遂げたのですか？

等

実は、私がグロースハックを学んだ経路は、他の皆さんと同じです。1つは教師が書いた専門書、もう1つはオンラインでの事例分析と共有です。

グロースハッキングに関する教師向けの本によってこの概念は普及しており、私が繰り返す必要はありません。業界によって経験によって成長の仕方は異なります。最適なものを選んで読み、勉強し、基本的かつ体系的な概念を確立することが重要です。

成長の概念とモデルを理解した後、本は理論的な知識であり、機械的に適用すべきではないことを理解する必要があります。業界、会社のリソース、チームの規模はすべて異なります。物事を単純化し、柔軟に理解して適用する必要があります。

インターネット上のグロースハッキングに関するコンテンツは、おおまかに次の 3 つのカテゴリに分けられます。

1. 優れた製品成長事例を分解し、簡潔なプロセスとロジックを共有します。
2. 独自の製品成長経験を共有し、具体的な成長数値を添付します。
3. グロースハッキングの概念と方法論を共有し、アプリケーションとアイデアを普及させます。

独自のコンテンツ ライブラリを継続的に充実させるために、他の製品の成長戦略や事例を学ぶことをお勧めします。しかし、これを弁証法的に見る必要があります。共有者は、外部データとプロセスのスクリーンショットを通じてケースを単純化して要約するだけです。

優れた製品であっても、一気に市場のトップに躍り出ることはできません。失敗と成功の歴史の歯車が、1 年 365 日、製品を押しつぶします。成功事例を見ても、なぜそれを自社製品に応用できないのでしょうか？それは、模倣したり吸収したりできない未知の要素がたくさんあるからです。

私たちは他人の驚異的な成長の数字にしばしば衝撃を受け、それが私たちのドーパミンを刺激し、他の人は成長への道に熟達していると思い込ませますが、私たちは1つのことしか知らず、もう1つのことを知らないため、成長を弄ぶことができません。しかし、記事を開いてみると、製品自体は規模が大きく、成長の原動力となっているのは、APPから公式アカウント、公式アカウントからミニプログラム、さまざまなプロモーションリソース、予算の活性化の往復であり、実際には可能ですが、会社の予算とトラフィックは少し小さいです。

新規ユーザーと自社のチャネルを介した自社のユーザーの間にどの程度の重複があるか、またリテンションと支払いの ROI データのパフォーマンスが妥当かどうかなどについて推測し、考えることを学ぶ必要がありますが、ほとんどの記事ではこれについて触れられていません。

グロースハックの概念と方法論を理解することは基本的かつ必須ですが、ほとんどの記事は書籍からモデルをコピーし、AARRR モデルに従って成長を説明する傾向があります。これは正しいのですが、製品の内部成長として理解できます。成長は内部成長と外部成長に分けられます。前回の記事では、「成長の根底にある考え方を解体する：製品の内部成長と外部成長の二重エンジンを構築する」について説明しました。私たちは特定の思考や理解の形に固く縛られるべきではありません。成長を促進できるあらゆる方法は、保存し、モデル化する価値があります。

例えば、記事では触れられていない成長分野が実際にある：製品マトリックスの成長

例：母子用品。私たちは、-1-1歳、1-3歳、3-6歳などの公式アカウントのマトリックスを通じて母親にサービスを提供します。公式アカウントのコンテンツは細かく分類されて運営されていますが、目的は主力商品のサービスを提供することにあります。

たとえば、私の家族の工具製品。コア機能は、プレイヤーの特定のニーズを満たすだけです。ユーザーからのフィードバックと調査を通じて、スクリーンショット、画面録画、ダウンロードの高速化、友達作り、割引情報などの小さな市場セグメントに製品マトリックスを拡張し、主流のユーザーをカバーできます。主力製品のボリュームアップも目的であり、小型製品の開発コストは高くありません。

話を元に戻すと、成長を合理的に見ると、誇張された概念や数字によって神格化されたり混乱したりすることはありません。成長は私たちの日々の仕事の中に存在し、実際に成長を探求し研究する方法や手法は数多くあります。成長思考を真剣に学習実践に取り入れる限り、ほとんどの人は外部の声に影響を受けます。共有や事例が多すぎてすべてを読むことすらできないので、製品の本質について考える時間などあるでしょうか。

以下に、私自身の製品の成長の例を紹介します。データはケースデモンストレーションのみを目的としており、皆さんの参考になれば幸いです。

1. 北極星の目標を設定し、成長モデルを解体する

当時、私が手がけていたプロダクトのDAUはある段階で5,000くらいで、休日になると3,000くらい増えるという状況でした。しかし、新規登録者数の増加が続くなか、デイリーアクティブユーザー数は大きく増加しておらず、総ユーザー数の3～5％程度で安定しており、月間アクティブユーザー数に至っては20～30％と、ツール業界の一般的な水準となっています。

したがって、段階的な目標の最初のステップとして、製品の 1 日あたりのアクティブ ユーザー数を 3,000 に増やします。では、1 日あたりのアクティブ ユーザー数を増やすにはどうすればよいでしょうか?

まずデータを分解してみましょう:

1. 1日あたりのアクティブユーザー数 = 新規アクティブユーザー数 + 既存アクティブユーザー数
2. 新しく追加されたアクティブユーザー = その日に新しく追加されたユーザー - 新しく追加された未登録ユーザー = 新しく登録された非アクティブユーザー
3. アクティブな古いユーザーの数 = 翌日のアクティブなユーザーの数 + 5 日連続のアクティブなユーザーの数 + 2 週間連続のアクティブなユーザーの数など。

このステップに到達したら、どのポイントを突破するのが最も簡単かを考え、テストして検証する必要があります。

1. 既存ユーザー:ユーザー属性と背景データに基づくと、既存ユーザーは製品に対してある程度の認知度があり、固定された行動習慣を身に付けています。活動の頻度と期間は安定しており、急速な躍進にはつながりません。
2. 新規ユーザー:新規登録したがアクティブでないユーザー。登録を完了しているということは、製品についてある程度理解しており、登録後の新鮮度が高い期間にあることを意味します。しかし、その日にコア機能を起動しなかったのはなぜでしょうか。コンテンツに興味がない、アクセス機能を見つけていない、始めるためのハードルが高いなどの理由でしょうか。このリンク内のユーザーは一定の割合を占めており、アクティブなコンバージョン直径ステップが最も短いため、テストと最適化を行うことができます。

2. チームストーミングと計画の策定

目標と最適化ポイントを設定した後、このステップでは、問題に突入し、仮説的な解決策をリストアップし、最終的な実装計画を設定する必要があります。チームが突入する前に、一定の割合の時間を市場調査と収集に割り当てる必要があります。出勤記録やサインインなど、日常の活動を増やすためのよく知られた方法に加えて、学ぶ価値のある他の製品や新しい遊び方はありますか? これらは会議で取り上げる必要があります。

市場調査の収集には、インターネット上で共有事例を検索する方法と、大手メーカーの有名なアプリを直接ダウンロードして体験する方法の 2 種類があります。

私は通常、次の理由から 2 番目のアプローチを使用します。

1. 大企業には豊富なリソースと最新のゲームプレイやイノベーションがあります。互いに遊びながら学ぶという方法もありますが、新製品はできるだけ早く更新され、自社製品に統合されるため、検索時間のコストが比較的削減されます。たとえば、早起きしてチェックインしてボーナスプールをシェアするなどです。現在、JD Finance、Weibo、Qutoutiao にインストールした製品はすべてオンラインで使用中です。
2. イベントデザインとコピーライティングの重要なポイントは学ぶ価値があります。リソースとチームの要因により、大企業はUIデザインとコピーライティングパッケージのレイアウトと美観が優れているため、参考にすることができます。第二に、より優れたデザインを学ぶことで、審美眼やコピーライティングのデザイン能力もある程度向上します。
3. プロセスのステップを体験し、ロジックを整理します。 APP のアクティビティ機能を直接ダウンロードして体験すると、より直感的で詳細な体験が得られ、各変換ノードのアクティビティ手順と重要な要素を整理するのに役立ちます。

経験を積んだ後、実行可能な計画をいくつか整理しました。計画の実装を確定するには、製品リソースやチームメンバーのスケジュールなどの要素を考慮する必要があります。分析は次のとおりです。

1. 毎日のログイン機能は、ユーザーにさまざまな報酬を与える必要があります。現在、この製品にはメンバーシップ システムのみがあり、ポイントやモールのゲームプレイはなく、小道具は単一で適切ではありません。
2. チェックインと報酬の共有機能は、ボーナスプールの設立が必要であり、ユーザーは一定の金額を支払う必要があります。開発コストが高く、製品の商業的なクローズドループが悪いため、適していません。
3. 読書は自由な時間を与えてくれます（NetEase Reading APP）。ユーザーは週に70分読書し、週末には2日間読書時間を得られます。製品自体には会員制があり、開発にはH5ページが1つだけ必要で、現在の製品とチームの状況に適しています。

ソリューション設計の考慮事項:データの分析と計算により、週ごとおよび月ごとのアクティブ ユーザー頻度と、各アクティブ セッションの平均継続時間を取得できます。平均値の低い方を週 5 時間に設定し、土曜日に 2 日間活動するようにします。

長期的な視点で見ると、アクティビティを最初に構築するときに高い参加基準を設定することは容易ではなく、アクティビティの新鮮さやユーザーの関心に影響を与えることに留意する必要があります。次に、新しいアクティビティがほとんどのユーザーに浸透し、ユーザーがそのアクティビティに気付いたら、次のサイクルではアクティビティを改善したり、しきい値を上げたりします。ユーザーはすでにその手順に関する知識と習熟度を持っているため、再度強調する必要はありません。代わりに、ユーザー グループ内でカスタマー サービスとして行動し、他のユーザーを教育することができます。

アクティビティの 3 つの要素、つまりシンプルさ、タイムリーさ、広範囲な適用範囲を念頭に置いてください。

アクティビティプロセスの手順:登録ユーザー向けのポップアッププッシュを追加 - アクティビティページには累積アクティブ時間がリアルタイムで表示されます - デフォルトの参加、条件を満たしている場合は土曜日に受け取ることができます。

3. データの最大化を最適化するためのデータファネルダッシュボードを構築する

実装計画のプロセス手順が整理された後、チームは進行状況のスケジュールを開始します:プロトタイプの制作 - UI 設計 - フロントエンドとバックエンドの開発 - テストのフォローアップ - オンラインリリース - データ追跡。

データ ファネル ダッシュボードは 2 つの部分に分かれています。

1. 毎日の新規登録ユーザー数 - アクティビティプッシュ数 - アクティビティクリック数 - 同じ日に機能をトリガーしたユーザー数（データ汚染を避けるために、ユーザーがアクティビティをプッシュしてから 30 分以内にトリガー動作があるかどうかに細分化できます） - 翌日に機能をトリガーしたユーザー数。
2. アクティビティに参加したユーザーの数 - 条件を満たしたユーザーの数（5 時間は細分化できます） - 報酬を受け取ったユーザーの数 - 翌週に再度参加するユーザーの数。

現在のスケジュールは、プロトタイプと UI デザインに 1 週​​間、フロントエンドとバックエンドの開発に 1 週​​間、オンライン テスト データに 1 週​​間、アクティビティの最適化に 2 週間です。終日作業が必要な設計およびフロントエンドとバックエンドの開発担当者に加えて、後続のデータ追跡とデバッグはフォローアップする担当者を配置することで実行できます。

アクティビティがオンラインになった後、アクティビティの人気期間（3～5日）があるため、アクティビティは2週間追跡されます。この段階では、アクティビティは初期露出段階にあり、ユーザーは参加することに新鮮さと熱意を感じ、全体的な汚染データに影響を与える可能性があります。通常、このタイプのアクティビティでは、データ サイクルを延長し、観察テストを実施する必要があります。

4. すべてのアクティビティがオンラインで開始され、操作テンプレートライブラリに追加されます。

アクティビティを開始してから2週間目は理想の状態には達せず、毎日の参加者数やアクティビティ報酬を受け取った人数は比較的安定しており、コンバージョン率は高くありませんでした。調査の結果、プッシュの強度と範囲の低さ、リマインダーの仕組みが不完全であるなどの要因により、ユーザーは理解が浅く、請求を忘れ、2 週目には奨励やリマインダーが提供されないことが判明しました。その後、プッシュの仕組み全体が最適化されました。

私がこのように言う理由は、どんなに経験豊富なベテランでも、アクティビティの設計からプロセス計画、オンライン操作まで、すべての面で完璧な結果を達成することは不可能であり、すべてにおいてデータフィードバックの最適化による継続的なデバッグが必要であることを説明するためです。したがって、ケースを過度に宣伝するのではなく、最善を尽くしてください。

1 か月後、アクティビティは設定された目標を達成しました。この時点で、アクティビティをすべてのユーザーにオンラインでプッシュし、アクティビティ テンプレートをプロジェクト ケース ライブラリに追加してバックアップし、後でレビューや学習に使用できます。

その後の最適化プロセスでは、アクティビティも反復的に設計され、ゲーミフィケーションが追加されました。これについては前回の記事で簡単に触れたので、ここでは詳しく説明しません。内部的に成長する活動の機能も、製品の反復とユーザーカバレッジに合わせてアップグレードされます（ユーザーベースの増加に伴い、ユーザー属性も向上します）。

要約する

ハッカーの成長は2つの部分で説明されます。一方では、新しい遊び方や概念を追求し、教義に過度に納得してはいけません。すべてのものには、表現されたものと表現されていないものの2つの側面があります。合理的に考え、弁証法的に見なければなりません。他方では、実践こそが学習を検証する最良の方法です。セット全体をコピーしたり、成長モデルのプロセスを固めたり、チームの考え方を固定したりする必要はありません。独自の製品リソースとチームの力に基づいて、アプリケーションを簡素化し、柔軟に拡張する必要があります。

オペレーション部門の同僚全員の作業計画はよくわかりませんが、すべての記事、すべてのビデオ、すべてのコンバージョンの改善が、製品の成長を促進していると思います。

成長についての神話は必要ありません。まずは目の前の仕事から始めて、自分の成長の軌跡を記録しましょう〜

著者:マオ・リー

著者:マオ・リー