ECサイトが復旧した後に確認したいのは、障害中に売上がどれほど減ったかです。答えを出すには、サーバーログと売上実績の役割を分けます。ログで顧客影響の時間を確定し、実績で同じ曜日・同じ時間帯との差を見ます。
目次
この記事のまとめ#
- 403はリクエストの拒否、502はゲートウェイやプロキシが上流サーバーから不正な応答を受けた状態であり、コードだけでは購入不能の範囲を決められません
- CDN/WAF・オリジン・アプリのログで、顧客が購入経路を使えなかった時間を先に確定します
- 障害時の売上は、直近の全日平均ではなく、同じ曜日・同じ時間帯の実績と比べます
- 基準売上と障害時売上の差は、実損ではなく推定売上減少額です
- 復旧後に売上が基準を上回った場合は、障害中に買えなかった人が戻った分かもしれないため、ほかの売上と分けて確認します
1.エラーコードだけでは売上減少額は決まらない#
403と502は、どちらも「ページが開かない」と見えても意味が異なります。
RFC 9110では、403はサーバーがリクエストを理解したうえで実行を拒否した状態です[1]。Cloudflareは、オリジンの権限設定、WAF、IP拒否なども403の原因になり得ると説明しています[2]。意図したbot遮断も、購入者を巻き込んだ設定ミスも、ブラウザには403として現れます。
502は、ゲートウェイまたはプロキシが上流サーバーから不正な応答を受けた状態です[1]。Cloudflare側の問題か、オリジンサーバー側の問題かでも確認先が分かれます[3]。
コードから分かるのは、応答の種類までです。商品ページだけが対象だったのか、カートや決済も使えなかったのかは分かりません。特定の国・端末・IPだけが拒否された可能性も残ります。開始時刻、終了時刻、購入できなかった人数もコードには含まれません。
最初に確定するのは、次の3点です。
- 顧客が使う商品ページ・カート・決済のどこでエラーが出たか
- 最初に失敗応答が出た時刻と、正常応答へ戻った時刻はいつか
- 全リクエストか、一部の地域・端末・経路だけが対象か
Cloudflareを使っている場合は、Edge Status CodeとOrigin Status Codeを比較します。Cloudflareは、この2つを使ってエッジとオリジンのどちらでエラーが生じたかを調べる方法を案内しています[4]。アプリのログと決済のログも同じ時刻で確認します。
ここで顧客影響が確認できなければ、403や502の件数を売上減少へ置き換えません。管理画面やbotからのリクエストだけに返った応答なら、購入者への影響は別に確かめる必要があります。
一方、カートから決済までの経路が13時05分から14時20分まで使えなかったと確認できたなら、売上側で調べる時間が決まります。原因究明と金額の推定を、同じデータだけで済ませないことが出発点です。
2.同じ曜日・同じ時間帯から減少額を推定する#
比較対象は、障害日の前日や直近30日の全日平均ではありません。同じ曜日・同じ時間帯の売上です。日曜日の午後と平日の朝では、平常時から売上の水準が異なるためです。
ここでは、架空のECサイトPで日曜日の13時05分から14時20分まで購入経路に障害があったとします。RevenueScopeの時間帯は日本時間の4時間単位です。障害を含む12〜16時について、過去4回の日曜日を1日ずつ指定し、売上・セッション・RPSを確認します。
架空のECサイトPの12〜16時を過去の日曜日と比べた例
| 対象日 | 売上 | セッション | RPS |
|---|---|---|---|
| 4週前の日曜日 | 218,000円 | 800 | 273円 |
| 3週前の日曜日 | 231,000円 | 840 | 275円 |
| 2週前の日曜日 | 209,000円 | 770 | 271円 |
| 1週前の日曜日 | 242,000円 | 860 | 281円 |
| 基準（4日間の中央値） | 224,500円 | 820 | 274円 |
| 障害当日 | 84,000円 | 520 | 162円 |
※表は説明用に組み立てた架空のデータです。RevenueScopeのデモで表示されるサンプルデータ（日々更新）とは一致しません。
平均ではなく中央値を使うのは、セールや大型注文があった1日だけで基準が引き上がるのを避けるためです。比較日を増やす場合も、曜日、時間帯、セールの有無をそろえます。
この例の推定売上減少額は、次のように計算します。
224,500円（基準売上）−84,000円（障害当日）＝140,500円
14万500円は失注の確定額ではありません。12〜16時のうち、障害が続いたのは75分だけです。残りの時間に起きた需要の増減、広告配信、天候、在庫の影響も差額に含まれます。
売上だけでなく、セッションとRPSを同時に見る理由もここにあります。セッションは820から520へ減り、RPSは274円から162円へ下がっています。記録されたセッション数が減っただけでなく、1セッションあたりの売上も下がっています。
セッションだけが減りRPSが基準付近なら、流入側の減少を先に調べます。セッションが基準付近でRPSだけが下がるなら、カートや決済など購入経路の影響を優先します。両方が下がる場合は、障害範囲がサイトへの到達と購入経路の双方に及んだ可能性をログで確認します。
売上減少をKPIの順番で切り分ける方法は、原因がまだ分からない場面を扱っています。本記事では、ログで顧客影響時間が確定した後に対象を絞っています。
3.復旧後の売上の上振れを別に確認する#
障害中に買えなかった人が、全員そのまま離れるとは限りません。復旧後に戻って購入すれば、売上は失われたのではなく、後の時間帯へ移っています。
そこで、障害を含む12〜16時だけで計算を終えません。前後の時間帯も同じ曜日の基準と比較します。
架空のECサイトPでは、復旧後の16〜20時が基準の12万円に対して16万6,000円でした。基準を4万6,000円上回っています。ただし、この4万6,000円がすべて買い直しだとは確定できません。復旧後に始まった広告や、通常の注文増が含まれる可能性があります。
復旧後の上振れを差し引く場合と、差し引かない場合を別々に計算します。
- 上振れを差し引かない試算：14万500円
- 4万6,000円をすべて復旧後の購入とみなす試算：9万4,500円
この9万4,500円と14万500円は、損失額の上限・下限ではありません。復旧後の広告、在庫、価格変更などが動いていれば、実際の売上への影響はこの2つの金額より小さくなることも、大きくなることもあります。2つの試算を監視・冗長化・改修の費用と比べ、どこまで対策するかを検討します。
時間帯別の売上ピークは、平常時の売上水準を調べるために使います。障害時は、その売上水準を比較の基準にします。直近数日の売上減少とは異なり、集計の遅れではなく、ログで確認した顧客影響と時間帯を対応させます。
広告費の損失は、売上減少額と分けます。RevenueScopeの画面では時間帯別の広告費を確認できません。障害中に広告を止めるかは運用上の判断であり、媒体側の配信履歴を同じ時刻で確認します。
RevenueScopeの解決策
RevenueScopeは、日本時間の4時間単位で、セッション・売上・RPSを時間帯ごとに表示します。ログで障害時間を絞った後、その時刻を含む時間帯を過去の同じ曜日と比べます。
RPSは、1セッションあたりの売上です。障害当日と比較する日を同じ曜日で1日ずつ切り替えれば、基準を作る材料がそろいます。障害の検知と原因特定は、CDN/WAF・オリジン・アプリのログで行います。RevenueScopeは403や502を検知せず、障害の開始時刻も確定しません。
同じ「売上がゼロ」でも、購入は起きていて購入イベントだけが計測先へ届かない場合があります。その切り分けはGA4の売上が突然ゼロになったで扱いました。決済失敗がかご落ちを増やすケースはかご落ちが急増で扱っています。本記事は、顧客が購入経路を使えなかった時間を外部ログで確定できた場合に限ります。
ログで13時05分〜14時20分の影響を確定したら、RevenueScopeでは12〜16時の売上・セッション・RPSを確認します。障害件数を売上へ変換するのではなく、ログの時刻を含む12〜16時の売上実績を比較対象として固定します。
架空のECサイトPでは、障害を含む時間帯の売上が基準から約63%下がりました。復旧後の上振れをすべて買い直しと仮定した場合の試算額は9万4,500円です。次に判断するのは、同じ障害を防ぐ対策にいくらまでかけるかです。2つの試算に発生頻度を掛け合わせて、監視・冗長化・改修の予算と比較します。
FAQ#
よくある質問#
Q. 1時間あたりの平均売上に障害時間を掛ければよいですか？
A. 最初の概算には使えますが、確定額にはできません。ECの売上は曜日と時間帯で偏ります。まず同じ曜日・同じ時間帯を基準にし、障害が75分なら、4時間単位の試算をより細かいログや注文記録で補正します。
Q. 403が出たら、購入者は全員アクセスできなかったと判断できますか？
A. 判断できません。403はリクエストの拒否を示しますが、対象は全利用者とは限りません。WAF、IP拒否、オリジンの権限設定など、どの経路と範囲に出たかをログで確認します[1][2]。
Q. 復旧後に売上が増えた分は、すべて買い直しですか？
A. すべて買い直しとは判断できません。広告、在庫、通常の需要増も含まれます。上振れを全額差し引く試算と、差し引かない試算を別々に出します。
Q. 障害時間はどのログで確認しますか？
A. CDN/WAFで最初の失敗応答と正常復帰を確認し、オリジン・アプリ・決済のログを同じ時刻で突き合わせます。地域や端末など一部の経路だけに出た場合は、その範囲も記録します。
まとめ#
403や502が出た後、最初に売上レポートを開くのではありません。顧客が商品ページ・カート・決済を使えなかった時間を、外部ログで確定します。
対象時間が決まったら、同じ曜日・同じ時間帯の売上・セッション・RPSを確認します。基準売上と障害時売上の差は、実損ではなく推定売上減少額です。
最後に復旧後の時間帯を確認します。売上の上振れを差し引く試算と、差し引かない試算を分ければ、1つの金額を実損と断定せずに済みます。2つの試算と発生頻度を、障害対策の費用を検討する材料の1つにします。
どの広告が売上を生んでいるか、一目でわかる
月5,000セッションまで、AIアナリストもずっと無料。クレジットカード不要。最短5分で導入。
