電子商取引のマーケティングプロモーション手法（経験：電子商取引プラットフォーム上でプロモーション活動をどのように実施するか？）

経験談：電子商取引プラットフォームでプロモーション活動を行うにはどうすればいいでしょうか？

電子商取引プラットフォームではさまざまなプロモーション活動が行われています。プロモーション活動の範囲の観点から、単一製品プロモーション、複数製品プロモーション、店舗プロモーション、プラットフォームプロモーションに分けられます。

商品の価格に影響を与えるかどうかという点では、次の 2 つのカテゴリに分けられます。

• 1 つは、商品の価格に影響を与える活動です。取引が完了した後、活動によって生成された割引は測定する必要があるコストであるため、価格に割り当てる必要があります。
• もう一方のタイプは商品価格に影響を与えません。

単一製品アクティビティには、 1 つ買うと 1 つ無料（単一商品を購入すると、元の商品が無料になる）、割引購入（複数購入で値下げ）、特別オファー（単一商品の値下げ）、フラッシュ セール（大幅な値下げ、期間限定）などがあります。店舗アクティビティには、全額割引、全額ギフト、店舗クーポンが含まれます。プラットフォームアクティビティには、プラットフォームクーポンが含まれます。

• 特別オファー/フラッシュセール:特別オファー/フラッシュセール活動は、単一製品の価格に基づいています。通常、人気商品には注文を引き付けるために特別オファーやフラッシュセールが設定されています。これは私が働いている医薬品電子商取引の分野では特に当てはまります。通常、販売者はより高い最低マッチング金額を設定し、最低マッチング金額に達しない注文は発送されません。したがって、この排水アイテムを購入するには、さらに商品を購入する必要があります。
• バイオフプロモーション:主に卸売のシナリオで使用されます。卸売業界では、一度にたくさん購入する顧客の方が、より安い価格を享受できる可能性が高くなります。この観点から、顧客はコストを節約するために、一度にこの製品をより多く購入する必要があります。
• 買うと 1 つ無料アクティビティ:買うと 1 つ無料とは、オリジナル製品を購入すると、オリジナル製品が無料で手に入ることを意味します。これは通常、比較的まれなケースであり、主に単価の低い卸売りで使用されます。 B2Bの場合、購入顧客は基本的に他の種類のギフトを必要としないからです。逆に、オリジナル製品を無料で入手できることは彼らにとって間違いなく有益であり、オリジナル製品もコストの考慮に含まれることになります。
• 完全割引アクティビティ:完全割引アクティビティには、幅広い適用シナリオがあります。高額商品の場合、全額割引キャンペーンを実施することで、商品のコンバージョン率を高めることができます。低価格商品の場合、主に店舗全体のコンバージョン率の向上や平均注文額の増加を目的として使用されます。
• 完全なギフトアクティビティ:完全なギフトアクティビティは完全な割引と同じです。単品アイテムのフルギフト、またはストアのフルギフトを設定できます。ゲームプレイはそれぞれのビジネスシナリオに関連しています。
• 店舗クーポン:店舗からクーポンが配布されます。割引方法は全額割引と全額割引に分かれます。主に店舗のコンバージョン率や平均注文額の向上に役立ちます。 Bエンドユーザーは各製品の粗利益にもっと注意を払うため、完全割引はB2Bに適しています。
• プラットフォーム クーポン:プラットフォームから送信されるプラットフォーム クーポンは、主にプラットフォームへのトラフィックを誘導し、プラットフォーム注文の成功率を高めるために使用されます。最大の効果は、顧客が最終的にプラットフォームのクーポンを使用すると、複数の店舗の売上を伸ばすことができることです。

プロモーション活動を次の側面から取り扱う方法は次のとおりです。

バックグラウンドでマーケティング活動を編集する場合、情報は主に活動定義、制限、製品範囲の 3 つのモジュールに分割されます。

1) アクティビティ定義には、アクティビティ名、アクティビティの説明、プロモーションルールが含まれます。

プロモーションルール:

• 特別オファー/フラッシュセールでは、元の価格を手動で設定する必要がある場合があることに注意してください（フロントエンドに表示されるときに製品の実際の価格が元の価格として直接使用されると、プロモーションが十分に強力ではないように見えるため）。
• 無料ギフトや割引、1 つ買うと 1 つ無料などのアクティビティには、多層的なプロモーション ルールを設定する必要があります。
• 全額割引活動とクーポンの場合、割引タイプが全額割引か全額ディスカウントかを考慮する必要があり、顧客が注文する際に意味が異なります。

2) アクティビティの説明には、アクティビティ時間、アクティビティ在庫、購入数量/数制限、完全割引が利用可能かどうかなどが含まれます。

アクティビティ インベントリ:主に単一製品アクティビティに使用されます。運営者がアクティビティを設定する場合、先着順でアクティビティに参加するために一定量の商品を受け取る傾向があります。これにより、全体的なコストも制御できます。アクティブ在庫の設定は在庫ロジックに影響します。これは在庫の特別トピックで詳しく説明します。

購入制限数量/回数:購入制限は 2 つの観点に分けられ、1 つは商品の購入を制限すること、もう 1 つは注文の購入を制限することです。

• 単一商品の購入制限がある場合、お客様は指定された数量のみ購入でき、数量を超えた場合はプロモーションの対象外となります。
• 注文に購入制限がある場合、顧客はアクティビティを楽しむ前に一定数の注文を行うことができます (通常、一定額以上の購入に対する割引に使用されます)。

全額割引プロモーションに参加するかどうか:これは、単価が低く、SKU が多い製品に適用されます。現時点で一般製品を特別販売する場合、各製品の粗利益を計算する問題が伴うため、これらの製品は全額割引プロモーションに参加できません。

また、クーポンには、発行されるクーポンの枚数、一人当たりのクーポンの上限枚数、クーポンの利用時間などを記載する必要があります。クーポンの発行と受け取りをセットで行なう場合は、オフライン配信としてクーポンを別途利用できるように、フロントエンドにクーポンを表示するかどうかも設定する必要があります。クーポンのデザインに関しては、一部のプラットフォームでは、最初にクーポンをデザインし、次にクーポンを使用するアクティビティを作成する傾向があります。さまざまなビジネス シナリオに応じて、さまざまなアプローチを検討できます。

3) 商品範囲：商品範囲に応じて、ストアの全商品、一部の商品（複数の商品）、カテゴリ、単一の商品を設定できます。

ストアアクティビティとプラットフォームアクティビティの場合のみ、すべてのストア製品、一部の製品 (複数の製品)、またはカテゴリを設定することを選択できます。単一製品アクティビティの場合は、対応する製品を選択するだけです。割引、店舗クーポン、プラットフォームクーポンの場合、オペレーターが特定の/特定の/店舗/カテゴリの商品をアクティビティから除外したくない場合は、アクティビティから商品を除外する機能を追加できます。

ストアクーポンやプラットフォームクーポンを使用する場合、顧客はすでに注文確認ページに到達しているため、イベントに参加していない商品をストアクーポンやプラットフォームクーポンに設定することは推奨されません。この際、クーポンの利用条件を満たしていないと判断された場合、お客様には金額の再計算をしていただくことになります。また、どの商品がクーポンの条件を満たしていないのかがわからなければ、顧客は何をすべきか分からず、イライラしてしまいます。

4) ギフト設定: 一部のアクティビティではギフト設定が必要です

ギフト処理には 2 つのソリューションがあります。

• 1つは、別のSKUを作成することです。ギフトは商品として棚に置かれ、注文が行われると自動的に商品リストに追加されます。これはビジネス状況に大きく依存します。 SKU が多い小型商品の場合、製品は自動的に同期されるため、現時点では ERP にギフト用の個別の SKU がない可能性があります。また、私が所属する医薬品ECプラットフォームでは、すべての店舗でプラットフォームの製品を販売しています。ギフトなど定義できない商品の場合、プラットフォームは専用の基本データベースを維持できません。
• もう 1 つの方法は、偽の SKU を作成し、ギフトの名前のみがフロントエンドに表示され、特別な商品詳細ページが表示されないことです。これはよりシンプルなアプローチです。しかし、ユーザーが贈り物の価値を正確に評価することは不可能です。さらに、ギフト ライブラリとギフト インベントリを別々に管理する必要があります (ギフト インベントリ ロジックについては、次のインベントリのトピックで説明します)。

5) 活動効果統計

通常、アクティビティが開催されるたびに、運営者はアクティビティに参加した人数を把握する必要があります。統計的次元は、活動の性質に応じて定義されます。単一製品のアクティビティの場合は、単一製品の購入数量と関連する注文数がカウントされます。完全割引またはクーポン活動の場合は、対応する注文数と平均注文額がカウントされます。

クーポンは、クーポンを受け取った人数とクーポンを使用した人数をカウントすることもできます。

アクティビティは相互に排他的となるように設計する必要があります。特に単一製品アクティビティは、単一製品に対して 1 つの特別オファーしか提供できないためです。

処理方法は2つあります。

• 1 つは、バックグラウンドでアクティビティを作成するときに処理し、製品を選択するときに、フロントエンド コントロールは相互に排他的なアクティビティに参加した製品を選択できないことです。
• もう 1 つは、バックグラウンドで制限のないアクティビティを作成することです。アクティビティが相互に排他的である場合、ユーザーはどの割引を享受するかを選択できます (大規模なプラットフォームに特に当てはまります)。

フロントエンド ページの情報表示は、主に次の 3 つのレベルに分かれています。

• 1 つは商品カードで、価格、アクティビティ ロゴ、元の価格が表示されます。
• 1つは商品の詳細で、イベント情報、クーポン収集の入り口、特別な商品のロゴなどを表示する必要があります。
• もう一つはショッピングカートです。ショッピングカートには、クーポン収集の入り口、完全割引の入り口、単品活動の価格などを表示する必要があります。完全割引活動に参加していない製品と単品活動、および購入制限を超える数量の表示には特に注意する必要があります。

その他のページには、特定の金額を超える購入に対する割引やギフトなど、複数の製品に適用されるアクティビティなどの特別なアクティビティ領域も含まれます。クーポン引き換えセンター: 利用可能なクーポンの表示。注文確認：店舗クーポンやプラットフォームクーポンなどのH5専用ページを使用しますが、この方法では限られた商品しか表示できません。

ショッピング カートの配置:ショッピング カート内のアイテムは、まずストア ディメンションに従ってグループ化され、次に同じアクティビティに参加しているアイテムがストア アクティビティ ディメンションに従ってグループ化され、最後に個々のアイテムがグループ化されます。

合計金額は、お支払い手続き中にショッピングカートと注文確認ページに表示されます。割り当て順に、単一製品アクティビティ、ストアアクティビティ、プラットフォームアクティビティです。店舗活動の割引はショッピングカートに表示されることが多く、クーポンの使用は注文確認ページに表示されることが多くなります。

さらに、1 つの商品には 1 つの価格しか表示できず、この価格はフロントエンド ページに直接表示されるため、この価格が販売価格として定義されている場合、このページの商品の価格は、販売価格 * 数量の合計 - 割引額の合計になります。

注文確認ページでは、各ストアの小計＝販売価格×数量－割引－ストア割引となり、合計決済金額はストアの小計の合計－プラットフォームクーポン割引となります。

価格共有の主な目的は、運用におけるコスト検証を容易にすることです。また、これは販売者との調整、特に返金の根拠としても使用できます（つまり、割引は各商品に均等に分配されます。これにより、一部の顧客は割引条件を満たすために最初に注文金額を集めてから返金する可能性がありますが、これはより透明性が高く、エクスペリエンスが向上します。プラットフォームがこの問題を回避するために、最初にクーポンを返却するなど、他の対策を講じると、顧客間の情報の非対称性につながります）。

価格割り当ての順序: 注文内の製品に表示される価格として、まず販売価格が使用されます。完全割引アクティビティがある場合、完全割引アクティビティに参加する製品は、完全割引額に応じて割り当てられます。店舗バウチャー活動がある場合、全店舗の商品は、全額割引配分後の金額に基づいて配分され続けます。同様に、プラットフォームバウチャーの配分は、ストアバウチャーの配分後の金額に基づいて行われます。

割り当てアルゴリズム:

価格をどのように割り当てても必ず誤差が生じるため、誤差を最小限に抑えるようにしてください。最も単純な方法で割り当てた金額 = 単価 * 割引金額 / 割引対象商品の合計金額 として切り捨てると、各項目ごとに誤差が生じます。この誤差が小数点以下 3 桁で定義されている場合、各製品の誤差は 0.01 以下になり、100 個の製品の誤差は 1.00 以下になります。

そうすると、エラーをできるだけ小さくするようにアルゴリズムを最適化することしかできなくなります。先ほどの分析で誤差が大きくなったのは、100 項目に誤差があるためです。この数を減らすだけで済みます。したがって、商品の寸法に応じて段階的に割引を分配する必要があります（1 つの商品を複数回購入することもできます）。最終的な誤差は、最終的に分配されるバッチ内の商品の数によって異なります。

各ステップで各商品に割り当てられる誤差 = 単価 * 割り当てられる割引 / 割り当てられる商品の合計金額。したがって、商品の割り当て順序を策定する際には、最終割り当てにおける商品の数が少ないほど良いことになります。商品の具体的な配分順序は事業状況によって異なります。

別の側面: 各製品に割り当てられたエラーの公平性を確保する必要があります。誤差が不均等に割り当てられると、実際に得られる割引が大きすぎたり小さすぎたりして、商品を返品する際に販売者や顧客の利益が損なわれる可能性があるため、アルゴリズムではこの点も考慮する必要があります。 （これはあまり意味がなく、扱いにくいです）

エラー処理:以前遭遇した最大の問題の 1 つは、エラー処理方法に問題があり、大規模な財務調整の問題が発生していたことです。以前のロジックでは、ストア割引によるエラーはすべてサブ注文に配置され、プラットフォーム クーポンによるエラーはすべて親注文に配置されていました。これを実行すると、払い戻しの際に購入者に過払いが発生する可能性があります (プラットフォーム クーポン割引が完全に配布されていないため、子注文金額が親注文金額よりも大きくなるため)。

しかし、私たちがお金を支払う際に、購入者に支払う金額が少なくなり、財務調整中にエラーを補う方法がなかったので、最終的にはプラットフォームバウチャーのエラーを、金額の大きいサプライヤーの名前に直接入れて、どうしてもバランスが取れるようにしました。

フロントエンドの注文であっても、バックエンドの注文であっても、商品は注文どおりに表示されなければなりません。そうしないと、購入者はギフトが展示されているかどうかわからず、サプライヤーはギフトがあるかどうかわからなくなります。この点は見逃されやすいです。

ギフト処理:前述のように、ギフトが ERP と直接同期される場合は、注文が同期されるときにギフトも同期される必要があります。ギフトが ERP と同期されていない場合は、注文が同期されたときにメモを通じて購入者にギフトを通知することしかできません。

注文のキャンセル/払い戻し:注文をキャンセルしたり、注文全体を払い戻す場合、該当する注文で使用されたクーポン、購入制限、購入回数をロールバックする必要があります。そうしないと、注文をキャンセルした後に再度購入すると、顧客に問題が生じます。

1. プロモーション活動により製品の価格が決まる
2. ERP同期推進活動

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

タイトル画像はCC0ライセンスに基づいてUnsplashから引用しています