toc製品操作（電子商取引マーケティングシステムの全プロセスを計画し、7つのモジュールを完了できます）

電子商取引マーケティングシステムの全プロセスを計画し、7つのモジュールで実行できます

編集者注：インターネット電子商取引プラットフォームではマーケティングシステムが非常に重要な役割を果たしており、各プラットフォームの電子商取引マーケティングシステムの構築には一定の違いがあります。この記事の著者は、マーケティング システムを構築する方法を詳しく説明し、マーケティング ツールの包括的な分析も提供します。みんなが積極的にコミュニケーションを取りながら、一緒に成長していけたらと思います。

マーケティング システムは、収益の増加、コンバージョン、在庫削減、新規顧客の誘致、インターネット電子商取引プラットフォームでの取引の促進を担います。しかし、社内の担当者が使用するエンタープライズバックエンドツールは、フロントエンドツールほど入手が容易ではなく、競合製品の分析に使用することもできないため、各プラットフォームのシステム構築には一定の違いが生じます。

著者は、マーケティング システムの構築方法、マーケティング ツールの包括的な分析、マーケティング システムのインテリジェンスに関する一連の記事を執筆する予定です。一方では、何かアウトプットをしたいと思っていますし、他方では、より多くの友人とコミュニケーションを取りたいと思っています。

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

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

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

1) 型誘導

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

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

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

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

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

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

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

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

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

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

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

モジュール性の本質は、「相違点を残しつつ共通点を探す」こと、そして共通部分を抽象化することです。プラグインの組み立てを容易にし、新しいタイプのアクティビティをすばやく構築するには、アクティビティを最小の粒度に分割するのが最適です。

プラットフォーム活動の現在の形態について説明したので、マーケティング ツールに含まれるモジュールを詳しく見ていきましょう。

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

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

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

アクティビティは手動またはシステムによって発行できます。違いは、ルールが非常に一貫しているかどうか、そして活動に固定のリズムがあるかどうかにあります。

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

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

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

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

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

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

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

1) 前進プロセス

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

2) 逆のプロセス

拒否結果と2回目の提出承認プロセスを考慮する必要があります。例えば、「修正拒否」後、誰が操作権限を引き継ぐのか、異なるアクティビティ情報に応じて2回目の提出プロセスを異なる方法で設計できるかどうかなどです。

例えば、承認フローのフォワードプロセスが下図のようになっており、2 回目のレビューで製品が「修正のために差し戻される」場合、2 回目の提出プロセスではどのような製品設計を行うことができますか?

オプション1: 再承認

オプション2: 承認のために申請書が返送された場所に直接戻る

アクティビティの短いタイトルなど、情報が重要でない場合は、オプション 2 を直接選択してレビュー時間を節約し、レビューの効率を向上させることができます。在庫、価格などの場合は、必要に応じてオプション 1 を選択できます。

では、「修正申告」が「申請者」ではなく「第一審」によって直接修正できるとしたらどうなるでしょうか?データフローの方向についてはさらに検討することができます。

レポート データは、ビジネス計画、意思決定、アクティビティ分析に役立ちます。適用範囲はアクティビティ作成、アクティビティ中、アクティビティ後までをカバーしており、運用担当者にとって欠かせないツールです。

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

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

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

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

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

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

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

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

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

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

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

次の表に示すように:

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

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

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

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

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

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

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

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

同時に、CRM システム、注文システム、財務システムとの交差点もあります。マーケティングシステムを0から1まで計画する場合は、各システム間の相乗効果に注意する必要があります。ご興味がございましたら、今後の記事でシェアさせていただきます。

この記事はもともと @宸然 によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです