ブラックフライデーとサイバーマンデーセールが利益を失う第一の理由は、弱いオファーではありません。カートに正しい価格を表示して、チェックアウトで失敗する割引、または高速チェックアウト(Shop Pay、Apple Pay、Google Pay)で静かに失敗する割引です。トラフィックが最高潮に達しているときです。顧客は1つの合計を見ますが、チェックアウトは別の合計を請求し、マージンを失うか売上を失うかのいずれかです。修正は大きな割引ではありません。Shopifyのチェックアウトのサーバー側内で計算された割引、テストしたスケジューリング、ラッシュ前に、そしてライブキャンペーンを数秒で一時停止する能力です。
このプレイブックは、ピークロード下で割引アプリが失敗する理由、今週実行できるBFCM前チェックリスト、当日ランブック、そして物事が正確にどこで壊れるかを見ることができるように機能したBFCMウィークエンドタイムラインをカバーしています。
なぜBFCMセールはチェックアウトで利益を失うのですか?
カートページとチェックアウトが多くの割引セットアップでは2つの異なるシステムで2つの異なる方法で計算されるためです。
多くの割引アプリはブラウザの中でスタックされた合計を計算します。カートページのJavaScriptまたはテーマウィジェットを使用します。そのプレビューは完璧に見えます。その後、顧客がチェックアウトをクリックし、Shopifyのチェックアウト(テーマのJavaScriptを実行しない)は独自のルールで注文を再計算します。2つが異なるとき、顧客はカートで1つの数字と最終請求時に異なる数字を見ます。過小請求は静かにマージンを食い、過剰請求は売上を完全に殺します。BFCM では、その顧客に2番目のチャンスは得られません。
高速チェックアウトでさらに悪化します。Shop Pay、Apple Pay、Google Payは購入者がカートページをスキップし、Shopifyのチェックアウトに直接ジャンプできます。テーマに存在する割引ロジックはこれらの購入者に対して実行されないため、最も速く変換され、最も意図が高い買い物客に対して割引が静かに失敗します。これは稀なエッジケースではありません。Shopifyフォーラムとアプリレビューでは、「カートに表示されるがチェックアウトで適用されない」と「高速チェックアウトが割引をスキップした」は、商人が割引アプリについて報告する最も悪影響を与える2つの苦情であり、それらはBFCM中に急上昇します。なぜなら、それは高速チェックアウトとトラフィックの両方が増加する時期だからです。
BFCMで最も高額な失敗は、開始されたことがないセールではありません。これは機能しているように見えたセールで、数時間だれも気付く前に静かに間違った合計を請求していたセールです。
ピークロード下で割引アプリが失敗するのはなぜですか?
障害は無作為ではありません。これらは、静かな火曜日に耐え、その年の最も忙しい日に崩れる小数のアーキテクチャ上の近道に遡ります。
クライアント側の価格ハック
一部のアプリはブラウザで割引を計算し、JavaScriptで表示価格を書き換えます。カートは割引されているように見えますが、実際のチェックアウト合計はアプリではなくShopifyによって別々に計算されます。ピークロード時、スローモバイル接続時、または広告ブロッカーまたはプライバシー拡張機能がある場合、そのJavaScriptは実行に失敗し、ビジュアル価格は割引されたままになる可能性があります。顧客は売上価格を見て満額の価格を請求されるか、逆になります。ブラウザスクリプトが高速オフィス接続でのすべてのテストで「機能」したため、このクラスのバグは実際のデバイスの実際のトラフィックがヒットするまで見えません。
ドラフトオーダーチェックアウト
他のアプリはカートをドラフトオーダーを通じてルーティングして、カスタム価格を適用します。これは最新のShopifyツール化に先行する回避策です。ドラフトオーダーは通常のチェックアウトフローの外に位置します。彼らはネイティブ割引コードを破ることができ、注文分析を歪ませ、「カートに追加」から「注文配置」までの間に別の移動部分を追加します。「カートに追加」と「注文配置」の間のすべての追加システムは、トラフィックが増加したときに正確に失敗する別のものです。
一括ロードなし、ボタンなし
ピークトラフィックは、一度に行うべきだった要求ごとのタスクを公開します。しかし、静かな障害は運用上のものです。つまり、技術的なものではなく、停止することができないセール。マーチャントは繰り返し、実際に開始されなかったスケジュールされたキャンペーン、および全体を削除してその設定を失わずに一時停止できないライブキャンペーンを報告します。価格エラーが販売中に発見されたとき、1クリック一時停止と「削除してキャンペーンを再構築」の間の違いは、チーム全体が完全に人員配置されていない週末に数時間の過小請求注文になる可能性があります。
多くの年の商人の苦情からのスルーラインは一貫しています: ストアは欠落している機能によって破棄されません。彼らは信頼性、チェックアウト正確さ、および信頼に比べて破棄されます。BFCMではこれら3つが全体のゲームです。
画像プレースホルダー(画像1): 割引が破れるところ
推奨される視覚: 白い背景上のクリーン16:9図は、左から右に購入パスを追跡し、"カートページ," "チェックアウト," "高速チェックアウト(Shop Pay / Apple Pay / Google Pay)." というラベルの3つのノードを備えています。パスの上、赤い"テーマJavaScript"レイヤーはカートノードのみに触れ、赤いXマークがチェックアウトと高速チェックアウトの上に表示され、それが実行されないことを示しています。パスの下、緑の"サーバー側Function"レイヤーは3つのノードすべてに均等に広がっています。最小限のフラットベクトルスタイル、ブランドカラーバイオレットとゴールド、サンセリフラベル、写真なし。
負荷下で割引を信頼性の高いものにするものは何ですか?
1つの計算、1つの場所で実行、すべての買い手に対して、すべてのチェックアウト表面上で。
Shopify Functionsはこれのメカニズムです。Shopifyの開発者向けドキュメントによると、Shopify Functions "チェックアウトプロセス中にカスタムコードを実行して、Shopifyのバックエンドロジックをカスタマイズできます。" Discount Function APIの場合は、Shopifyによる、"このロジックをチェックアウトフローに統合し," ここで単一の関数は製品、注文、配送、3つの割引クラスすべてに一度に節約を適用できます。計算はShopifyのサーバーで、買い物客のブラウザではなく、チェックアウトパイプライン内で発生します。
それはBFCMで重要なプロパティです。割引はShopifyのチェックアウト内のサーバー側で計算されるため、購入者がカートページ、チェックアウトページ、または高速チェックアウト上にあるかどうかに関係なく、同じ計算が実行されます。これは高速チェックアウトが同じShopifyチェックアウトを通じてルーティングされるためです。静かにスキップできるテーマスクリプトはありません。カートプレビューと最終請求は同じ計算であるため、離れることはできません。Shopify Functionsはデザイン上純粋です。ネットワーク呼び出しを行ったり、サンドボックスの外に到達したりすることはできません。これにより、「第三者サービスがロード下でタイムアウトした」という失敗の全体的なカテゴリが排除されます。
信頼性ここはマーケティングヘッドラインで誰もが約束できるパーセンテージではありません。検証可能な詳細のセットを自分でテストできます:
- カートに表示される合計はチェックアウトで請求される合計と同一です。
- その合計はShop Pay、Apple Pay、Google Payで再び同一です。
- スケジューリングは真夜中にスイッチを反転させた誰かではなく、割引自体にサーバー側でShopifyによって適用されます。
- ライブキャンペーンを一時停止でき、一時停止は実際に迅速にストアフロント全体に有効になります。
これらの各個は、実際にそれを信頼するBFCMトラフィックを使用する前に、テスト注文で検証できます。それが信頼性第一のアプローチ全体のポイントです。希望せず、それが機能するかどうかを確認します。
BFCMの前のチェックリスト
BFCMの前の週間中にこれを実行してください。当日の晩ではなく。すべてのアイテムが存在して、静かな失敗を修正するのがまだ安いときにキャッチするためのものです。
1. ラッシュの前にすべてのキャンペーンをスケジュールします
BFCMウィーク前に正確な開始日時と終了日時を設定して、誰も交通ダッシュボードを見ながらキャンペーンをライブに手動で反転させることに依存しません。割引上のスケジューリングはShopify自身によって適用されます。discountAutomaticAppUpdate突然変異はstartsAtとendsAt割引ノード上に、Shopifyはその時刻にオンラインの誰もいなくてもスケジュール通りにアクティブ化および有効期限を切ります。ショップ独自のタイムゾーンを使用して、すべての開始時刻と終了時刻のAM/PMを二重確認してください。午前中の代わりに真夜中として意図したのに「12:00」に設定されたセールは、古典的な自己負傷のBFCM傷です。
たとえば、週末を通して層を実行している場合、早期アクセス15パーセント、次に主なイベントの25パーセント、2番目が最初のものが終わる正確な瞬間に開始するように背中合わせでスケジュールします。これにより、両方が一度に適用される可能性があるウィンドウまたは両方が適用されないウィンドウが削除されます。
2. 発火しないべき実際のカートを含むシミュレータでテストします
キャンペーンがライブになる前に、シミュレータを通じてサンプルカートを実行し、組み合わせた合計が予想したものと正確に同じであることを確認します。チェックアウトが実行される同じ計算。その後、みんながスキップする部分を行います。オファーの一部のみを取得するべきカートを構築し、他のカートが正しく外れていることを確認します。
静かな障害は両方の方法を切ります。発火しない割引はエラーを投げることはありません。発火するべきではない割引も決してエラーを投げません。幸せなパスカートのみをテストすることは、BFCMパーセンテージが既存のコードと誤ってスタックして注文を過小請求するケースについては何も伝えられません。発火するべきカートと発火しないべきカートをテストし、両方のチェックアウト要約を1行ずつ読んでください。
3. 高速チェックアウトを明示的に確認します
実際のテストカートをShop Payをすべて通じて取ります。その後、できれば、Apple PayとGoogle Payです。これはテーマベースの割引ロジックが自分自身を明かすところです。なぜなら、高速パスはそのロジックが存在するカートページをスキップするからです。サーバー側、Functions ベースの割引は、カートに表示されたのと同一の合計をここに表示します。ブラウザスクリプトに依存するものは、顧客がカート対チェックアウトの不一致をキャッチするところです。その後ではなく、その前に。
4. 1クリックで一時停止できることを確認してください
週末の前に、ライブキャンペーンを停止する方法を正確に知り、一時停止がページロード時のみではなくストアフロント全体に伝播することを確認してください。テストしたことがない一時停止は安全ネットではありません。discountAutomaticDeactivate突然変異はサーバー側で割引を無効化し、優れたアプリはそれを1つのトグルとして表示します。これにより、キャンペーンの設定が保存され、問題が修正されたら再開できます。圧力の下でキャンペーンを削除して再構築することは、5分の価格修正が2時間の停止に変わる方法です。
5. スタッキングと制限を確認してください
どのオファーが組み合わせることを意図しているかを確認し、Shopifyの上限を覚えて、機能できない販売促進を設計しません。割引は3つのクラス、製品、注文、配送でのみ組み合わせられ、Shopifyが最も高い値を保つクラス内では決して組み合わせられません。店舗ごとに最大25個の関数ベースの自動割引をアクティブ化でき、1つの製品割引はデフォルトでカート行ごとに適用され、チェックアウトは注文あたり最大5つの製品または注文コード、および1つの配送コードを受け入れます。BFCMオファーをこれらの制限内で計画して、再構築する時間があります。
画像プレースホルダー(画像2): BFCMの前のチェックリスト
推奨される視覚: 明るい背景上の16:9チェックリストカード図では、"BFCMの前の信頼性チェックリスト." というタイトルが付けられています。5行、各行チェックボックスと短いラベル付き: "キャンペーンを事前にスケジュール," "発火するべき、発火しないべきカートをシミュレート," "Shop Pay / Apple Pay / Google Payを確認," "1クリック一時停止を確認," "スタッキングと制限を確認." クリーンフラットデザイン、バイオレットチェックマークとゴールドアクセントヘッダー、太っ腹な白い空間、サンセリフ、写真なし。
BFCMの当日ランブック
事前作業は信頼性が得られるところです。当日ランブックは目的のために短いです。チェックリストを実行した場合、週末は退屈になるはずです。
- ドアが開く前に、標準チェックアウトとShop Payの両方を通じて実際のストアで1つの最終的なライブテスト注文を行い、合計が正確に一致することを確認してください。その後、キャンペーンだけを置いてください。彼らはスケジュール済み。スケジュールにそのタスクを実行させてください。
- 注文数だけでなく、注文合計を見てください、各層がライブになって最初の1時間。請求された合計がそのカートが生産すべきだったものと一致しない順序を探しています。最初の1時間のすべての合計が実際のトラフィックで正しい場合、それは正しいままになります。
- 何か間違っているように見える場合は、最初に一時停止し、2番目に診断します。1クリック一時停止を使用して、ストアフロント全体に数秒で伝播します。安全な移動は出血を即座に停止し、テストカートで問題を確認し、設定を修正し、再開することです。キャンペーンの構成は保存されたままなので、一時停止はオフになっているわかりません。
- 層が終わると、次のものがライブであることを確認しますそして前の割引が適用を停止しました。背中合わせのスケジューリングはこれを自動的に処理しますが、各ハンドオフでの10秒チェックは安い保険です。
- 変更ログを保持してください。タイムスタンプで各一時停止、再開、または編集をメモしてください。合計が後で外れているように見える場合、何が変更されたかを正確に知りたいです。
ランブックのゴールは、割引エンジンをサポーターすることではなく、BFCM中に売上の成長を見て過ごすことです。
働くBFCMウィークエンド: 信頼できるものは時間ごとに見えます
具体的な2層週末と信頼性第一のセットアップが各ステップでどのように動作するかを示しています。ストアは早期アクセス15パーセント、次に25パーセント主なイベント、プラス閾値を超える送料無料、すべてスケジュール済みで実行しています。
2つのことはこのタイムラインを混乱した代わりに落ち着かせます。最初に、割引の数学は同じ計算です。どこでも、木曜日のテスト注文は金曜日のトラフィックのための本当のドレスリハーサルです。第2に、12時20午前の恐怖は数時間の停止ではなく6分間の一時停止です。一時停止は1クリックで、キャンペーンを破棄しません。
ここでは失敗のバージョンと対比します。テーマスクリプト割引は、オフィスWiFiで大丈夫にテストして、金曜日の買い物客の塊でShop Payが静かにスキップし、キャンペーンを削除せずに一時停止することはできません。オファーは同じです。結果ではありません。
Stackable上でBFCM売上を実行してください
すべてのチェックアウトパスを手動で監査して、割引アプリが負荷の下で保持することを希望する代わりに、これは正確にStackable信頼性を解決するために構築されたものであり、誰も確認できないアップタイム数ではなく、検証可能な具体的に信頼性をコミットします。
- すべての割引はShopify Functionsを通じてShopifyのチェックアウト自体の内部で計算されます。クライアント側の価格の書き換えはなく、ドラフトオーダー回避策がないため、カート、チェックアウト、およびすべての高速チェックアウト、Shop Pay、Apple Pay、Google Payは1つのサーバー側計算から同一の合計を計算します。
- スケジュール済みセールは割引上のShopifyで適用される正確な時刻に開始および終了するため、真夜中に設定されたキャンペーンは誰もオンラインではなく真夜中に開始し、背中合わせの層は重複するウィンドウがなく手渡します。
- ライブキャンペーンを一時停止すると、1クリックで約60秒以内にストアフロント全体に伝播し、キャンペーンの設定は問題が修正された瞬間に再開できるように保存されたままになります。
- カートシミュレータは、ライブになる前にすべてのアクティブなオファーを通じてサンプルカートを実行し、正確な行ごとの合計を表示します。発火したオファーと発火しなかったオファーを含め、数秒で発火するべき、発火しないべきカートをテストできます。
- Stackableは製品価格を変更することはありません。割引はチェックアウト調整のみとしてのみ存在するため、キャンペーン中にアンインストールする場合は戻す必要はありません。
Stackableを無料でインストールして、カート、チェックアウト、Shop Payの金額が1円まで一致することをBFCM前に確認しましょう。usestackable.com/pricing 🚀
画像プレースホルダー(画像3): 1つの合計、どこでも
推奨される視覚: 3つのチェックアウト表面を並べて表示する16:9図。カートページ、標準チェックアウト、Shop Pay高速シートは、小さな緑色のチェックで同一の合計「$92.00」を表示します。単一のサーバーアイコン「Shopify Function」が下に位置し、3つの表面に3つの線を接続して、すべてのものに供給される1つの計算を示しています。フラットベクトルスタイル、ブランドカラーバイオレットとゴールド、クリーンでミニマル、写真なし。
注目すべき点
- BFCMセールが利益を失う最初の理由は、カートに表示されるが、チェックアウトで失敗する割引、またはShop Pay、Apple Pay、Google Payのような高速チェックアウトで静かに失敗する割引です。ピークロード。
- 障害はアーキテクチャ上のものです。クライアント側の価格ハック が静かに失敗し、ドラフトオーダー回避策が脆弱なステップを追加し、何か悪い場合に一時停止できない売上です。
- 信頼性は1つのサーバー側計算から来ます。Shopify Functionsは割引をShopifyのチェックアウト内で実行するため、カート、チェックアウト、高速チェックアウトはすべて同一の合計を生成します。
- ラッシュの前に作業を行ってください。すべてのキャンペーンを事前にスケジュールし、発火するべき、発火しないべきカートをシミュレートし、高速チェックアウトを確認し、1クリックで一時停止できることを確認してください。
- 誰も確認できないアップタイムパーセンテージではなく、テストできる検証可能な詳細(すべてのチェックアウト表面での同一の合計と迅速に実施する一時停止)で信頼性を判断してください。
- 当日ランブックは目的のために短いです。最終テスト注文、各層がライブになって最初の1時間の合計を見ます。一時停止して診断し、すべてのティアハンドオフを確認してください。
- アプリが実際の製品価格を書き換えることはありませんので、キャンペーン中にアンインストールする場合は戻す必要はありません。
関連記事
- BFCM信頼性プレイブック: 割引アプリが最高の理由と、それを防ぐ検証可能なコミットメント。
- スケジュール済みセールを一時停止できます: キャンペーンを時間通りに開始して、約60秒以内にストアフロント全体でライブセールを一時停止します。
- 割引スタッキング、正しく行われた: 3つのクラスごとの組み合わせスイッチ、カートとチェックアウトが同意するようにサーバー側で計算しました。
- Stackable価格設定: 計画、無料ティア、および各個が含まれるもの。
- Shopifyで割引スタッキングがどのように機能するか: ネイティブが最も高い割引のみを適用する理由、および正しく組み合わせる方法。
- Shopify Scripts の終了: 開発者なしで移行します: 次の大売上の前にルールベースの割引ロジックをFunctionsに移動します。
