電子商取引プロモーション活動運用分析

電子商取引プラットフォーム企業からフォローアップの電話がかかってきたことはありませんか? ときには一連の割引を提供することもあります。実際、電子商取引プラットフォーム企業は、新規ユーザーの獲得や、既存の顧客のリピート訪問や再購入を実現するために、一連の運用活動を行うことがよくあります。

1. 活動形態

この活動は、直接割引またはクーポンによる全額割引、キャッシュバックまたはクーポン、そして低価格での商品購入の 3 つのタイプにまとめることができます。

1. 1つ目のタイプは、その名の通り、タオバオが発行する紅包や、ダブルイレブンでの200元以上の購入に対する30元の割引などの活動です。特定の活動ルールを満たしていれば、支払い時に金額の一部を直接控除できます。
2. 2 つ目のタイプは、Pinduoduo の共同購入、交渉、または Xiaomi Youpin の注文に対する即時リベートなどのアクティビティで、購入に一定の金額を費やし、特定の運営アクティビティ ルールを満たすと、ユーザーに現金または紅包が提供されます。
3. 商品を安く購入する主な方法は、単品商品の数量を直接減らすか、追加商品の数量を直接減らすことです。これにより、それぞれユーザーのコンバージョンまたは平均注文額を増やすことができます。

2. 製品設計とモジュール分析

図1 業務活動製品モジュール分析図

業務活動は、一般的にフロントエンドのページ表示とバックエンドのシステムサポートに分けられます。理解を容易にするために、マインドマップもフロントエンドとバックエンドに分けられています。

• フロントエンドは主にユーザーの動線に焦点を当てているため、関連するページを細かく分割する必要があります。たとえば、一般的なアクティビティには個別のアクティビティページがあり、個人センターには対応するクーポンや金額の説明があります。また、商品詳細ページのアクティビティ情報、注文支払いページの割引ガイダンス、支払いページの割引オプションなど、メインパス上のユーザーガイダンスも含まれます。さらに、将来の活動のデータ分析を容易にするための基本的なデータポイントもあります。
• バックエンドは主に運用アクティビティと連携し、関連するトランザクション システムは、注文内の複数のアイテムに紅包を割り当てるルールなど、このアクティビティの優待情報やその他のコンテンツと互換性がある必要があります。さらに、金融システム、アフターサービス、カスタマーサービス、CRBシステムとの情報互換性もあります。また、電子商取引活動における紅包は実際の現金割引であることが多いため、私たちも毛糸党に注目し、対応する毛糸禁止規則を制定します。

この記事では主にバックエンドシステムからのさらなる分析を行います。

3. アクティビティの設定

アクティビティを作成するときは、アクティビティの製品選択だけでなく、一連の構成も必要になります。イベント用の商品は、一般的に割引額の比率と商品の実際の利益を計算して選定されます。アクティビティで割引が大きすぎて製品が収益性を達成できない場合は、製品をアクティビティ プールから除外する必要があります。アクティビティ構成には、アクティビティ管理、製品管理、アクティビティ製品プール管理など、複数のモジュールが含まれていることがわかります。

アクティビティ管理には、操作のアクティビティ スイッチとアクティビティ ルールの構成が含まれます。例えば、どのような人を対象にした活動なのか、地域や経路、時間などに制限がある活動なのか、お返しするものは紅包なのか現金なのか、どのような形でどのような額の紅包が返ってくるのかなどです。アクティビティ管理は、一連のアクティビティを制御および表示します。プラットフォームに多くの形式のアクティビティがあり、各アクティビティの構成が汎用的でない場合。セカンダリ モジュールをさらに細分化して、さまざまな形式のアクティビティを管理できます。

商品管理とは、イベントに参加できるすべての商品を展示することです。商品の SPU、SKU、商品価格、必須属性、販売者名、在庫などが含まれます。また、商品の在庫変動のログを表示する必要があります。

アクティビティ製品プール、つまり各アクティビティに対応する使用可能な製品プールは、複数の製品プールを構成できますが、使用できるのは 1 つだけです。アクティビティに独立した在庫がある場合は、それも設定する必要があります。つまり、他のアクティビティでは商品のこの部分の在庫を使用できません。

最後に、一般的に言えば、電子商取引のプロモーション活動は、さまざまな運用活動のルールと切り離せないものです。各アクティビティの要素、ルール、構成を明確にし、それらをモジュール コンテンツに統合します。これにより、一方では製品のスケーラビリティを満たすことができ、他方では、ルールを変更した後にフロントエンド バージョンを再リリースする必要がなくなります。

図2 運用活動システムの機能モジュール図

4. 取引システム

あらゆる活動には、必然的に取引システムの変更や互換性が伴います。取引システムの鍵となるのは、注文タイプ、注文ステータス、注文金額、注文割引です。

前提条件：当社のプリセットプラットフォームの注文システムは広く利用されており、注文ミドルオフィスサービスとなっています。したがって、新しいアクティビティがある場合、通常は注文の既存のロジックを変更しません。

注文タイプ: 既存の注文ロジックと互換性がない場合は、一般的なルールを変更しないように、既存の注文をカプセル化することを検討するか、独立したアクティビティ注文を別途記述し、そのアクティビティ注文を使用して通常の注文に対応させることができます。たとえば、注文を購入すると製品が無料で手に入ります。記録保存の便宜上、プレゼント活動への参加資格と贈呈された商品シートのステータスを記録するための別の活動シートを作成できます。アクティビティ シートを使用して、通常の注文をパッケージ化し、無料製品注文と関連付けます。アクティビティシートを個別に設計します。

注文ステータス: 注文のステータスを気軽に変更しない方がよいため、新しいビジネス アクティビティがある場合は、アクティビティ オーダーのステート マシンを検討します。注文の作成 (注文が行われ、支払い待ち)、注文の支払いが成功した、注文の支払いがキャンセルされた、注文が生産中、注文が出荷された、注文が受領された、注文がクローズされた、注文が返金された、およびさまざまな注文ステータスに対応するアクティビティ注文ステータスを個別に検討します。注文を作成するときは、アクティビティ ルールをチェックして、正常に作成できるかどうかを確認します。注文の支払い時に、その企業が既存の各種クーポンなどを使用できるかどうかを検討します。支払いをキャンセルする場合、タイムアウトすると自動的にキャンセルされますか、それとも事前にキャンセルする必要がありますか?注文の払い戻し後、各種割引はどのように返金されますか? 注文した商品を個別に返品できますか (ギフトは返金されませんか? フリーライダーを防ぐにはどうすればよいですか?)。

注文金額: 支払い金額を計算し、各商品と各注文にクーポン割引を割り当てる方法。払い戻し後に割引と金額がユーザーのアカウントに返金される方法。

たとえば、ユーザーの赤い封筒は組み合わせて使用​​できますが、複数のアイテムが購入されます。返金前にユーザーは新たに紅包を入手しており、アカウント内に有効期限が切れた紅包が存在していた。したがって、返品について考えると、赤い封筒の返品ロジックは次のようになります。

図3 赤い封筒の払い戻しロジック図

さらに、具体的な運用ルールに応じて、払い戻し金額に応じて新しい赤い封筒を作成することもできます。

V. その他

さらに、電子商取引のプロモーション活動を設計する際には、その後のデータ分析を容易にするために必要なフロントエンドの埋め込みポイントも考慮する必要があります。金融システムでは、新しい注文タイプと新しい割引方法の互換性を考慮する必要があります。CRB では、ユーザーのリコールやイベント プッシュなどを考慮する必要があります。カスタマー サービス システムでは、ユーザーの質問シナリオやカスタマー サービスに必要な情報クエリ リストなどを考慮する必要があります。

VI. 結論

製品が新しい遊び方を整理する場合、多くの場合、幅広い側面が関係します。モジュール間には上流と下流の相互作用があり、バックエンド モジュールもフロントエンドに関連します。細かいことがたくさんあり、上流と下流で良い情報を頻繁に同期させることが非常に重要です。必要に応じて、複数回の内部監査を実施することもできます。また、技術チームとのコミュニケーションにも注意を払う必要があります。会議中、特定のモジュールの技術チームは、直接関係する製品のPRDプレゼンテーションのみを聞き、関連するモジュールのプレゼンテーションを聞き逃す可能性があります。事前に製品の技術的なコミュニケーションと調整が必要です。

最後に、システムがオンラインになった後は、ビジネス側とのタイムリーなトレーニングを実施し、ユーザーのフィードバックを追跡し、データを観察してバージョンを最適化および反復する必要があります。

著者: Take a Pulse

出典: Take the Pulse