電子商取引マーケティングシステムの全プロセス計画

マーケティング システムは、インターネット電子商取引プラットフォームでの収益、コンバージョン、在庫調整、新規顧客の獲得、取引の促進などの向上に関与しています。しかし、社内の従業員が使用するエンタープライズ バックエンド ツールは、フロントエンド ツールほど入手しやすくなく、競合製品の分析も実行しにくいため、プラットフォームごとにシステム構築が異なります。

著者は、マーケティングシステムの構築方法、マーケティングツールの包括的な分析、マーケティングシステムのインテリジェンスに関する一連の記事を書く予定です。一方では、何らかのアウトプットが得られることを期待し、他方では、より多くの友人とコミュニケーションをとることを望んでいます。

この記事の内容は次のとおりです。

1. マーケティングシステムの概要
2. マーケティングシステム全プロセスモジュール分解
3. ToCとToBのマーケティングツールのデザインの違い

1. マーケティングシステムの概要

現在、インターネット プラットフォームで利用できるマーケティング手法は比較的成熟しています。C エンドでは、ユーザー側のパッケージングとプレゼンテーションの形式で変形や拡張が行われる可能性がありますが、B エンドでは、マーケティング システムの基礎となるロジック、外観の下の再利用可能なルールの抽象化、およびシステム間の相関関係にさらに注意を払う必要があります。

1. マーケティングツールの種類の概要

1) 型誘導

現在、インターネット上では約 13 種類のアクティビティがあり、使用シナリオに応じて次の 3 つのカテゴリに分類できます。

• 単一製品カテゴリのアクティビティ: 割引、即時割引、1 つ買うと 1 つ無料、特別オファー、フラッシュ セール。
• 購入を完了するためのアクティビティ: 段階的割引、段階的割引、段階的ギフト、N 個の商品で M 元、M 個の商品を購入して N 個の商品を無料で入手、M 番目の商品で N 割引、M 番目の商品で N 元。
• コミュニケーション活動：グループ購入

単一製品活動はコンバージョン率の向上に適しており、注文額を増やす活動は平均注文額の増加と関連売上の創出に適しており、コミュニケーション活動は新規顧客の誘致とオフサイト活動の実施に適しています。

2) クーポン券・紅包券に関する注意事項

ここで注意すべき点は、クーポンや紅包もマーケティングシステムに属しますが、活動ツールとは言えないということです。

違いは、アクティビティの本質は商品であり、クーポンと紅包の本質はユーザーの個人資産に相当し、決済時に控除ロジックとして存在することです。アクティビティ間には相互に排他的な関係がある可能性がありますが、クーポンと紅包はアクティビティに重ねることができます。

3) 比較的特殊な2つの活動形態

• 特別セール: 特別セールの取り扱い方法はプラットフォームによって異なります。一部のプラットフォームは基本的に割引/即時割引ですが、他のプラットフォームは「列」として定義されています。特別セールには実際にはさまざまなアクティビティ タイプが含まれ、アクティビティのパッケージ化の一形態です。
• プラットフォーム補助金: 個人的には、プラットフォームが注文数や売上数に基づいてマーチャントに費用の一部を負担させることを理解しています。このタイプの補助金は現在私の仕事には関係がないので、もしご存知の方がいらっしゃいましたら、情報を追加するのにご協力ください。

2. リソースポジションアクティビティ

一般的に、リソース位置アクティビティは「列」に似ています。これらの「列」は、ホームページ、ホームページ カルーセル、検索結果ページなど、プラットフォームがトラフィックを提供できる場所に表示され、1 つ以上のアクティビティ タイプを含めることができます。

一般的な「列」には、フラッシュ セール、グループ購入、ブランド セールなどがあります。プラットフォームによって、「列」のテーマとパッケージは異なります。列とアクティビティは、1 対 1、1 対多、または多対多の関係を形成できます。

JD.com のホームページを例にとると、「JD.com フラッシュセール」、「日替わりセール」、「ブランドフラッシュセール」などはすべて「列」として定義できますが、そのうち「ブランドフラッシュセール」は「列」の名前にすぎません。セカンダリページには、1 つ買うと 1 つ無料や割引など、さまざまなアクティビティ タイプを含めることもできます。

2. マーケティングシステムのプロセスモジュール全体の分解

モジュール化の本質は、「相違点を残しつつ共通点を探す」ことと、共通部分を抽象化することです。プラグインの組み立てを容易にし、新しいタイプのアクティビティを迅速に構築するには、共通部分を最小の粒度に分解するのが最適です。プラットフォーム活動の現在の形態について説明したので、マーケティング ツールに含まれるモジュールを詳しく見ていきましょう。

1. モジュール1: アクティビティの基本情報

アクティビティの基本情報には、共通フィールドがいくつかあります。また、さまざまなツールによってマッチングされるフィールド情報もいくつかあります。たとえば、注文マッチングカテゴリに必要な注文マッチングページです。システムが自動的に生成するか、ジャンプをカスタマイズするかを選択できます。特定の状況に応じてフィールドを追加できます。ここでは詳細には触れません。

2. モジュール 2: アクティビティ ルール テンプレート

アクティビティ ルール テンプレートは、本質的には「アクティビティ アクセス ルール テンプレート」であり、送信できる製品と販売者の範囲を制限することを目的としています。ルール テンプレートは、さまざまな段階でのさまざまなアクティビティのニーズを満たすように動的に設計する必要があります。

例えば、単価の高い商品はグループ購入には適していません。N個でM元は食品やアクセサリーに適しています。製品側の思考に重点を置くことに加えて、製品マネージャーは製品の特性にも注意を払う必要があり、これはマーケティングツールの設計に非常に役立ちます。

3. モジュール3: アクティビティ配分方法

アクティビティは手動で発行することも、システムで発行することもできます。違いは、ルールの一貫性が高いかどうか、アクティビティのリズムが固定されているかどうかにあります。

たとえば、強いリズムと時間の概念を持つフラッシュセール活動がある場合、企業が個々の時点で手動で注文を発行しなければならないとしたら、手間がかかり非効率的です。この場合、日や週などのさまざまな時間ディメンションに従って注文を自動的に発行するようにシステムを設定できます。

4. モジュール4: 製品の選択と提出

1) 製品選択テンプレート

アクティビティによって必要な情報が異なるため、提出時の製品選択テンプレートはアクティビティの種類に応じて処理する必要があることに注意してください。通常のアクティビティ価格、アクティビティ在庫、購入数量制限に加えて、即時割引額フィールド（単一の SKU に対して変更可能）などがあります。

2) 提出可能な製品と検証

製品の選択と送信は、アクティビティ ルール テンプレートに関連付ける必要があります。ルールは、製品を選択して送信する際の検証ロジックの一部です。ルールによって、製品が報告可能かどうか、およびアクティビティ テンプレートの要件を満たしているかどうかが判断されます。この手順により、ビジネスで製品を選択し、選択される可能性が高まります。

一般的な検証には、売り切れステータスを報告できるかどうか、イベント開始前に 2 回目の検証が必要かどうかなどの製品ステータスも含まれます。

5. モジュール 5: アクティビティ承認フロー

承認フローは、順方向プロセスと逆方向プロセスを考慮する必要があります。承認フローは時間ノードと密接に関連しており、レビュー ステータスに影響します。

1) 前進プロセス

参加する役割や進捗が一貫しているか、プラットフォーム活動に複数の部門が関与している場合は部門間の承認フローが独立しているか、期限内に申請が審査されない場合は自動的に却下されるかなどを考慮する必要があります。

2) 逆のプロセス

拒否結果と 2 回目の申請承認プロセスを考慮する必要があります。たとえば、「変更拒否」後、誰が操作権限を引き継ぐか、異なるアクティビティ情報に応じて 2 回目の申請プロセスを異なる方法で設計できるかどうかなどです。例えば、承認フローのフォワードプロセスが下図のようになっており、2 回目のレビューで製品が「修正のために差し戻される」場合、2 回目の提出プロセスではどのような製品設計を行うことができますか?活動の短いタイトルなど、情報が重要でない場合は、直接オプション 2 を選択してレビュー時間を節約し、レビュー効率を向上させることができます。在庫、価格などの場合は、必要に応じてオプション 1 を選択できます。では、「変更の返却」を「申請者」ではなく「最初のインスタンス」が直接変更できるとしたらどうでしょうか。データ フローの方向についてさらに検討することができます。

6. モジュール 6: マーケティング データ レポート

「ビジネス レポートの核となる価値は、事実を把握し、問題を発見し、原因を分析し、対策を立てることです。プロダクト マネージャーはビジネス担当者と協力して、完全な体系的な指標の構築に重点を置き、有用なレポートを設計する必要があります。問題を観察し分析する視点とアイデアがレポート設計の核であり、華やかなインタラクションは二次的なものにすぎません。」 - Yang Kun「B サイドを勝ち取る: プロダクト マネージャーのアップグレードへの道」

レポートデータは、事業計画、意思決定、活動分析に役立ちます。その適用範囲は、活動作成、活動中、活動後までをカバーしており、運用担当者にとって欠かせないツールです。

1) 客観的かつ正確な活動データを提供する

大まかに言えば、トラフィックデータとトランザクション量という2つの側面から計画を立てることができます。

1. トラフィック データ: 新規顧客数、アクティビティ、製品 UV など - トラフィック データはフロントエンド データの埋め込みポイントに注意する必要があります。
2. 取引データ: 販売量、販売数、有料ユーザー数、コンバージョン率、平均注文額など - 取引データでは、注文金額の正確性に注意する必要があります。

マーケティング システムでは、さまざまなアクティビティがさまざまなデータに焦点を当てます。たとえば、グループ購入アクティビティでは、グループ注文の数、グループ注文の数、グループ注文の数などにも焦点を当てる必要があります。

2) データ指標の変化を発見する

ここでは、データ結果を処理し、データ値をさらに比較し、データ曲線を観察する必要があります。月ごとの売上、昨日と先週との比較、時間プロパティを持つ他のデータフィールドなど、いくつかの比較分析値を全体データに追加して、データの変化をより直感的に感じることができます。

値の範囲を設定すると、データが異常に変動したときに早期警告が発行され、ビジネス チームがデータ変更の理由を分析しやすくなります。

データレポートは一般的に BI システムで表示されますが、オペレーションスタッフによる現場での観察と調整を容易にするために、アクティビティシステムでリアルタイムデータを同時に表示することを好みます。

7. モジュール 7: マーケティング システム権限システム

マーケティング システムには、多くの場合、クロスエンド (プラットフォーム エンド、マーチャント エンド)、複数のロール、複数の状態、および複数の操作が含まれるため、ロールと権限の設計には特別な厳密さが求められます。そうしないと、混乱が生じやすくなります。

プラットフォームによって設計方法が異なる場合があります。一部のプラットフォームでは、ロールに基づいて機能と操作可能な項目が決定されますが、他のプラットフォームでは、権限ポイントに基づいて機能と操作可能な項目が決定され、その後、異なるロールに権限ポイントが追加されます。これは、プラットフォームの権限システムによって決定されます。

この部分では、製品設計フェーズでステータス/ロール/権限の対応表を計画する必要があります。これは、技術開発だけでなく、機能のリリース後の権限構成にも使用されます。

次の表に示すように:

まず、システムではデフォルトですべてのロールに「詳細」権限が付与されます。

次に、ステータスと権限を組み合わせて、たとえば、CEO レビュー状態で「CEO レビュー」権限を持つ人物を見つけて、「レビューに進む」操作を表示します。

3. ToCとToBのマーケティングツールのデザインの違い

私はかつて、あるプロジェクトでToB 電子商取引アプリのマーケティングモジュールの製品設計を担当したことがあります。その際に、両者の設計にはいくつかの違いがあることに気づいたので、ここで簡単に紹介したいと思います。

まず、ToC 側と ToB 側の違いを見てみましょう。

表から、共同購入などの C エンドに適した活動は B エンドには適していないことがわかります。

そこで、ToBマーケティングモジュールの設計では、「地域別配送」や「エリアと価格のコントロール」など地域特性に合わせたコラムを計画し、物流の適時性をコントロールし、輸送費や梱包費を削減しました。

また、取引経路を短縮するために、Bサイド専用システムとページショッピングカートも作成しました。パーソナライズされたマーケティング戦略を実行し、店舗の主要カテゴリーとオフライン店舗の販売データに基づいて商品を推奨し、ユーザーに正確にリーチしてコンバージョンを向上させます。最終的に、良い結果を達成しました。

4. 最後に

マーケティングシステムは、フロントエンドの購買取引プロセスとバックエンドのサプライチェーンに密接に関連する巨大なシステムです。

同時に、CRM システム、受注システム、財務システムとの交差もあります。マーケティングシステムを 0-1 から計画する場合は、各システム間の相乗効果に注目する必要があります。ご興味があれば、今後の記事で共有します。

著者: 陳然

出典: オペレーター