アクセスは減ったのに売上は増えた。週次会議で広告担当者は需要の問題を疑い、運用担当者は改善だと判断する。同じ数字を見ていても、何が変わったのかを説明できているとは限りません。訪問、注文数量、販売1点あたりの売上を分けて確認すると、次に誰が何を調べるべきかが明確になります。
このガイドは、自社のAmazon販売・トラフィックを分析する出品者向けです。競合の売上推計ではなく、レポートの選び方、架空の2週間比較、再利用できる確認記録を扱います。参考資料の確認日は2026年9月10日です。実際の作業では、対象マーケットプレイスの項目定義、利用可能な表示、権限を確認してください。
結論:集計条件をそろえ、変化を説明し、次の確認を割り当てる
Amazonビジネスレポートを分析するときは、比較可能な2期間と商品範囲を先に固定します。セッション、注文数量、注文商品売上を組み合わせ、変化に寄与した商品を探します。観測した事実と未確認の仮説を分け、商品ページ・価格・広告を変更する前に、必要な証拠と確認担当者を決めてください。
有用な分析の基準は5つです。対象範囲が一致していること、入力が十分にそろっていること、分母が正しいこと、仮説を検証できること、次の作業に責任者がいることです。分子と分母が残っていない割合や、元のファイルを特定できない提案だけでは、判断を再現できません。
小規模な週次確認なら、エクスポートと検算済みの表計算で足りる場合があります。反復処理が安定してから自動化を検討し、例外の説明や担当者間の引き継ぎが課題になったらエージェント支援を評価します。目的は文章量ではなく、別の人が確認できる判断を作ることです。
業務上の質問に合うレポートを選ぶ
変化の時期と対象商品を別々に特定する
ダウンロード前に「同じ商品群の注文商品売上が、比較可能な2週間でなぜ減ったのか」と質問を具体化します。「アカウントを分析して」だけでは、全列を要約しても判断に結び付きません。日付別の表示は変化の時期を、商品別の表示は変化の場所を探すために使います。
Amazonの公式Sales and Trafficレポートスキーマは、日付集計とASIN集計を区別しています。日付にはDAY・WEEK・MONTH、商品にはPARENT・CHILD・SKUの集計レベルがあります。これはAPIレポートの定義であり、すべてのセラーセントラル画面に同じ操作項目があるという意味ではありません。Amazon公式レポートスキーマ。
複数日の商品別合計から、商品ごとの日別推移まで取得できると決めつけないでください。実際の行を識別する項目を確認します。必要な商品×日付の明細がなければ、対応するレポートを取得するか質問を絞ります。期間合計を任意に分割し、実測の日別データのように扱ってはいけません。
親ASINの全体像と子ASINの明細を混ぜて合計しない
商品ファミリー全体を見る質問では親の範囲が、色やサイズなど特定のバリエーションを調べる質問では子の明細が役立ちます。SKU単位の作業には、別途対応表が必要な場合があります。作業ファイルに集計レベルを残し、親の合計行を子の行に追加して再合計しないようにします。
商品の対応関係も保存してください。SKU表記やバリエーションの構成、分析グループが変わると、分類の変化を需要の増減と誤解する可能性があります。対応関係を照合できていない比較は暫定とし、異なる集合を同一商品の継続的な変化として説明しません。
売上レポートだけでは答えられない質問を分ける
販売とトラフィックは症状の発見に役立ちますが、その説明には広告、販売可能な状態、価格履歴、運用変更の記録が必要なことがあります。利益には原価や調整項目の別分析が必要です。売上エクスポートだけを、次回入金の予測や損益計算書に置き換えないでください。
指標を読むときに意味を変えない
次の表は、主要項目を読み違えないための整理です。画面上の日本語表記が異なる場合に備え、元の英語列名も残します。定義はAmazonの販売・トラフィック項目説明を参照し、計算時は実際の出力項目と対応させてください。
表を左右にスワイプすると、すべての列を確認できます。
| 指標 | 読み取る内容 | そのまま結論にしてはいけないこと |
|---|---|---|
| Sessions | レポートのセッション定義でまとめた訪問 | 商品別合計が店舗全体の重複排除済み人数である |
| Page views | 繰り返しを含むページ表示 | 広告インプレッションと同じである |
| Units ordered | 注文された数量 | 購入したユニーク人数である |
| Total order items | 数量とは区別される注文内の商品項目 | 数量や注文件数と交換して使える |
| Ordered product sales | 注文商品に対応する売上金額 | 純利益や次回の入金額である |
| Unit session percentage | セッションに対する注文数量の割合 | 購入した人の割合を厳密に示す |
| B2B専用項目 | Amazon Business購入者の範囲の指標 | その範囲を含む総計に再加算すべきである |
ユニットセッション率は分子と分母を残して計算する
通常の数量対セッションの計算は、注文数量÷セッション×100です。架空の例として、120点の注文と100セッションなら120%になります。分子がユニーク購入者数ではなく数量だからであり、訪問者の100%超が購入したという意味ではありません。
分母がゼロなら「算出不可」とし、もっともらしい率を埋めません。項目自体がない場合は「不明」です。欠損と、記録されたゼロでは対応が異なります。極端な率が現れたときは、結果だけを説明せず、元の数量とセッション、その対象範囲に戻って確認します。
行ごとの割合を単純平均しない
条件が一致し、重複なく合算できる2レコードを考えます。片方が100セッション・10点、もう片方が900セッション・9点なら、行の率は10%と1%です。単純平均は5.5%ですが、分子と分母を合計して計算すると19÷1,000で1.9%になります。
ただし、この計算は記録を正当に合算できることが前提です。商品範囲の重複、二重インポート、セッションの対象範囲の違いを解消するものではありません。「選択した記録の数量対セッション比」と表現し、店舗全体のユニーク訪問者の購入率だと自動的に言い換えないでください。
1点あたりの売上、表示価格、利益を区別する
同じ対象範囲で売上を数量で割ると、販売1点あたりの売上金額を記述できます。複数商品を含む場合、この値は商品構成の変化でも動きます。全商品を値上げした証拠にはならず、単独では原価についても分かりません。
「1点あたりの売上が増えた」は計算から示せますが、「価格戦略が利益を改善した」には追加の証拠が必要です。表現を区別すると、後から読む人も計算結果と経営上の因果判断を混同しにくくなります。
原因を探す前に比較条件をそろえる
マーケットプレイス、商品集合、曜日構成を固定する
同じマーケットプレイスと通貨を使います。長さが等しく、曜日構成を比較できる期間を選び、大きな販促や販売停止期間も記録してください。完全な7日間と途中の今週は、両方に「週」という名前が付いていても同じ条件ではありません。
商品範囲は、特定の親に現在属する全子ASIN、固定した子ASINリストなど、明示的に定めます。商品が加わったり外れたりした場合は、固定集合の変化と構成変更を分けて見せます。欠損商品を黙って除外し、残りを元と同じポートフォリオとして扱わないことが重要です。
エクスポートの版とデータの完成度を記録する
レポート名、期間、フィルター、集計レベル、ダウンロード時刻を保存し、原本と計算用ファイルを分けます。後日の取得で数値が変わったら、前回の判断を支える唯一の原本を上書きせず、版の差を確認してください。
すべてのAmazonレポートに一律の待機時間を設定しません。使用するデータ源の更新状態と十分性を確認します。直近期間がまだ変化するなら暫定とし、再確認日を設けます。小数点以下を増やしても、入力が未完成という問題は解決しません。
データ結合の前に重複と部分集合を調べる
マーケットプレイス、期間、商品レベル、商品識別子など、実際に1行を特定する項目からキーを定義します。価格や広告のデータを結合する前に、重複キーを確認してください。元ファイルが正しくても、多対多の結合で売上が何倍にもなる場合があります。
B2Bを扱う場合、企業購入者だけの列と全顧客を含む列を区別します。B2Bを含む総計にB2Bをもう一度足しません。専用比率の分母が未確認なら、その定義を保持します。見慣れた列名だからと通常の式で再計算しないでください。
計算例:セッションが20%減っても売上が5.6%増える
米国マーケットプレイスで固定した子ASIN集合について、完全な7日間を2期間比較すると仮定します。金額はすべて米ドルです。以下は考え方を示す架空の数値であり、OpenMaxの顧客実績やAmazonの基準値ではありません。
表を左右にスワイプすると、すべての列を確認できます。
| 指標 | 期間A | 期間B | 変化 |
|---|---|---|---|
| セッション | 1,000 | 800 | −20% |
| 注文数量 | 100 | 96 | −4% |
| 注文商品売上 | 2,000米ドル | 2,112米ドル | +5.6% |
| 数量÷セッション | 10% | 12% | +2ポイント |
| 売上÷数量 | 20米ドル | 22米ドル | +10% |
計算によって確認できた事実を先に書く
この集合ではセッションと数量が減りましたが、売上金額は増えています。セッションあたり数量と1点あたり売上が上昇しました。10%から12%への変化は2ポイント増、相対増加率では20%です。「転換率が2%改善」と曖昧にまとめると、意味が変わってしまいます。
入力の範囲が一致し分母がゼロでなければ、セッション×セッションあたり数量×1点あたり売上=売上という恒等式が成り立ちます。ここでは800×0.12×22米ドル=2,112米ドルです。数値の整合確認に使えますが、特定施策の効果を証明する因果モデルではありません。
複数の説明を区別するための証拠を探す
低価格商品の数量構成比が下がったのか、販促が終わったのか、同じ子ASINの実際の販売金額が変わったのかを調べます。販売可能な状態や、アクセス減少が特定の子に集中しているかも確認対象です。どの説明も、合計値以外の証拠を必要とします。
適切な次の作業は「商品担当者が対象子ASINの販売状況と価格履歴を照合し、分析担当者が売上変化への寄与を計算する」です。「値上げの成功が証明されたので、もう一度上げる」ではありません。後者は、まだ調べるべき仮説を結論に変えています。
不確実性を残した運用サマリーにする
たとえば「セッションと数量は減少した一方、売上は5.6%増加した。1点あたり売上の増加が数量減を上回った。価格と商品構成の影響はまだ切り分けていないため、支出変更前に子ASIN別の寄与と販促日程を確認する」と書けます。
アカウント全体を単に好調・不調と分類するより、引き継ぎに役立ちます。分かったこと、未解決のこと、判断を変え得る証拠が読み取れるからです。
6つの変化パターンから次の調査を選ぶ
セッション減少は対象商品と時期を絞る
広い範囲の変化か、一部への集中かを確認します。需要低下を決めつける前に、データの十分性、販売可能な状態、時期を調べます。広告配信などの記録は手掛かりになりますが、ビジネスレポートのセッションだけでは流入元を特定できません。すべての減少を自然検索順位の低下と結び付けないでください。
次の確認には対象集合と期間を付けます。同じ日付の販売状況と広告配信を照合し、どちらが説明に合うかを記録します。合わなければ未解決として残し、都合のよい理由を作りません。
セッションが横ばいでユニットセッション率が低下した
元の注文数量が変化したことと、訪問の対象範囲が比較可能なことを確認します。その後、出品条件、バリエーションの販売状況、商品ページの変更を調べます。流入構成の違いだけで全体の比率が動く場合もあり、すべての商品ページが悪化したとは限りません。
詳しい調査にはAmazonのコンバージョン率改善ガイドを使えます。ビジネスレポートは調べる場所を示すものであり、どの画像や文章を変更すれば改善するかを直接証明するものではありません。
数量が減ったのに売上が増えた
1点あたり売上の変化と商品構成を分けます。子ASINごとの数量と金額を確認し、複数商品の平均を全商品の価格として扱いません。必要な原価や調整項目がそろうまで、利益の判断は別の分析に残します。
在庫の動きや数量目標も重視するチームなら、その目標との関係も記録します。売上金額の増加が、すべての運用目標の達成を意味するわけではありません。
期間中に販売可能な状態や出品条件が変わった
具体的な日付と対象商品を調べます。現在の画面だけでは、先週ずっと購入できたことを証明できません。取得できる履歴を比較し、証拠のない時間帯を明示します。時期の一致は仮説を支えることがありますが、管理された因果検証とは別です。
商品ページの準備状況が疑われる場合は、Amazon商品ページ監査チェックリストへ進みます。報告上の現象、確認結果、承認された変更は分けて残してください。
親では安定していても一部の子が大きく動いた
増減が相殺され、合計では見えなくなる場合があります。子ごとの変化率に加えて、全体の金額・数量変化に対する絶対的な寄与も表示します。小さい基数の大幅変動より、主力商品の小幅減の方が運用上重要なこともあります。
この現象だけでバリエーションを統合・削除・再構成しません。最初の仕事は対応関係の照合と変化の特定であり、集計表から直接カタログ操作を決めることではありません。
欠損、修正、不整合が見つかった
影響する結論を保留し、フィルター、行キー、期間境界、結合後の件数変化を確認します。加工していない原本のサンプルへ戻って照合します。必要項目が得られない場合は、欠けた証拠と次の取得作業を明記した部分的なレビューを提出できます。
「この変化を説明する証拠が足りない」は有効な分析結果です。条件の合わない記録を使った流暢な説明は、不足データの代わりになりません。
広告・入金・利益の数字と照合する
広告売上にはアトリビューションの基準がある
Amazonは、広告コンバージョンを広告接触日へ反映し、適用されるルックバック期間の終了前は指標が未完成であると説明しています。対象商品や接触のルールもキャンペーン種類で異なります。同じ日付指定でも、比較する販売集合が一致するとは限りません。Amazon Ads公式アトリビューション解説。
比較前に、それぞれの日付基準、データの確定状況、商品範囲を記録します。広告掲載商品と帰属する全購入商品を同じと仮定しません。差異は照合すべき問題であり、直ちに片方のシステムの誤りを示すわけではありません。
単純な差し引きを自然流入売上と呼ばない
ビジネスレポート売上から広告帰属売上を引くと、日付基準や商品集合を混ぜる可能性があります。その残額は、自動的に測定済みのオーガニック売上にはなりません。必要な条件をそろえられない場合は、両方の数値を定義付きで別々に示します。
広告固有の調査にはAmazon PPC監査チェックリストを使います。支出管理やターゲティングの検証を、一般的な売上レビューの中だけで済ませないようにします。
注文商品売上を入金や利益に置き換えない
入金額と採算には、それぞれの記録と照合が必要です。手数料、返金、原価、計上時期を売上増加だけから推定しません。財務担当へ渡すときは期間、通貨、証拠を添え、運用サマリーが想定外の会計結論として再利用されないようにします。
証拠を残す週次レビューを実施する
別の担当者も繰り返せる順番にする
- 質問を1つ定め、マーケットプレイス、商品集合、比較期間を固定する。
- 原本を保存し、フィルター、集計レベル、取得時刻を記録する。
- 欠損、重複キー、通貨、結合を確認してから率を計算する。
- 絶対値、割合、商品別の寄与を比較し、重要な変化を特定する。
- 観測と仮説を分け、仮説を区別する証拠を指定する。
- 次の確認の担当者と期限を決め、結果を記録してから対応を判断する。
重要性は、チームの目的と実際の規模に合わせます。チェックリストの共通閾値をそのまま使うのではなく、閾値を設けるなら低数量商品や未完成データの扱いも記録します。除外された対象と理由が分かる状態にしてください。
12項目の確認記録を再利用する
質問:数量が減ったのに売上が増えた理由は何か
マーケットプレイス:米国、対象出品アカウントを指定
通貨:USD
期間:比較可能な完全な7日間を2期間
レポートと集計レベル:指定エクスポート、固定子ASIN集合
取得時刻:各原本の版ごとに記録
証拠の場所:ファイル、シート、行識別子
観測した変化:売上+5.6%、数量-4%、セッション-20%
計算:2,112 / 2,000 - 1、入力セルを保持
仮説と不足証拠:価格か商品構成か、子別記録を確認
担当者と次の確認:分析担当を指定、期限までに寄与を照合
結果と確認日:確認済み、修正、未解決のいずれか、証拠を添付
数値は架空例のものであり、初期設定の異常閾値ではありません。対象範囲を実際の比較へ置き換えます。元の計算を保持し、整った説明文だけが残る状態を避けてください。
調査を閉じるか、判断を修正する
次の確認で、証拠から実際に分かったことを記録します。最初の仮説が誤っていれば、修正とその理由を残します。変更を承認した場合は、分析結果とは別に変更範囲と決定者を記録します。調査完了と施策成功は異なる結果です。
手作業・標準機能・スクリプト・エージェントを選び分ける
手作業のエクスポートは小さく低頻度の質問に向く
1人で入力を確認できる規模なら、表計算が合理的です。原本を残し、式を明示し、サンプルを元データへ照合します。重要項目や比較可能な入力がなければ、関連する結論を保留します。手作業を選ぶこと自体は、自動化の失敗ではありません。
標準レポートはデータ源に近い初期確認に使う
別の処理基盤を作る前に、利用可能なフィルターや商品表示で変化を調べます。設定を記録し、別の担当者が再現できるようにします。標準機能だけではチームをまたぐ背景や必要な情報源を組み合わせられない場合があります。その不足を明示し、ダッシュボードがすべてを説明すると考えないでください。
スクリプトは定義の安定した反復処理に使う
入力構造を理解した後で、重複チェック、数値変換、計算を自動化します。手で検算したサンプルと一致するか確認してから広げます。想定外の通貨、識別子の欠損、列構成の変更はエラーや再確認へ回し、ゼロに変えて処理を続けないようにします。
取得と分析は別工程です。エクスポートを処理できるスクリプトがあっても、APIへのアクセスが承認済みとは限りません。データ源の変更で新しい処理が完了しなければ、日付付きの前回有効結果を保持し、新しい実行は未完了と明示します。古い値を最新値として見せません。
エージェント支援は説明と引き継ぎを検証しながら使う
承認された入力から、観測事項の要約や確認すべき質問の下書きを作る用途を検討できます。数値の記述には、原本位置か確定した計算への参照を求めます。人が根拠のない原因説明を除き、次の作業が証拠に合うか確認してください。
文章生成に重要な合計値を推測で再計算させず、分析依頼を価格・広告・在庫の変更へ広げません。全体の進め方はAmazon出品者のワークフロー自動化ガイドも参考になります。
OpenMaxをレビュー業務で検討する場合
計算が信頼できる状態になってから協働を評価する
OpenMaxは、人とエージェントの協働を製品の位置付けとしています。分析担当、商品担当、広告運用担当の間の引き継ぎが課題なら、出典付きの発見、担当者のいる次の確認、判断履歴を扱う作業方法を評価する余地があります。
ここで提案する流れは、承認された要約と参照情報から始まります。アシスタントが観測と未解決の質問を下書きし、担当者が計算を照合して次の確認を決めます。これは検討用の業務設計であり、標準のSeller Centralコネクターや完成済みAmazon分析アプリの存在を確認したものではありません。
業務データの利用前に具体的な構成と制約を確認する
入力処理、参照情報、アクセス制限、レビューの引き継ぎについて、必要な構成をOpenMaxチームに実演してもらいます。まず最小限のサンプルを使い、認証情報や不要な顧客単位の情報を含めません。本番利用前に、該当責任者がデータの取り扱いを確認します。
現在の方法より証拠や修正を残せるかを評価します。表の数行を長文にするだけなら、運用上の課題を解決できたとはいえません。滑らかな要約だけで、接続や実行の機能まであると推定しないでください。
簡単な方法で足りるなら、そのまま使う
毎週数行を1人が確認する業務なら、安定した表と明確な責任分担で十分な場合があります。未解決事項がチーム間を移動したり、会議後に消えたりするときに試行の意味が増します。ただし、必要な流れを実際の製品構成で扱えることが前提です。
FAQ:Amazonビジネスレポートの見方と分析
ビジネスレポートで最初に見るべきものは何ですか?
成果の前に、マーケットプレイス、通貨、期間、商品集合、集計レベルが比較可能か確認します。その後でセッション、数量、売上を組み合わせます。対象範囲の違いを業績変化と誤認して、存在しない問題の原因を探すことを防ぎます。
セッションとページビューは同じですか?
異なる指標です。選択したレポートの定義を使い、繰り返し表示とセッションを区別してください。ページビューを広告表示回数に、商品別セッション合計を店舗全体の重複排除済み人数に置き換えません。
ユニットセッション率はどう計算しますか?
通常の数量対セッションの指標は、注文数量をセッションで割り100を掛けます。両方の入力を残してください。ゼロ分母は算出不可で、特定セグメントの指標はその分母を確認する必要があります。
ユニットセッション率が100%を超えることはありますか?
数量はユニーク購入者数ではないため、数量対セッションの比率は100%を超え得ます。架空の120点÷100セッションは120%です。不自然な入力は調べますが、確率に適用される上限を超えたことだけで計算を否定しません。
セッションが減っているのに売上が増えるのはなぜですか?
算術上は、セッションあたり数量や1点あたり売上の増加が訪問減を上回る場合があります。商品構成、販売金額、販売可能な状態などを調べ、特定施策の効果と結論付ける前に区別します。売上増だけでは利益増を証明できません。
広告売上とビジネスレポート売上が一致しないのはなぜですか?
広告には接触日やルックバック期間などの帰属ルールがあり、比較先の期間基準や商品集合と異なる場合があります。日付、完成度、対象商品を確認してから照合します。差額を自動的にオーガニック売上と呼ばないでください。
親ASINと子ASINのどちらを分析すべきですか?
質問によって選びます。商品ファミリーの全体像と個別バリエーションの調査は目的が異なります。対応関係を残し、階層をまたいだ合算を避け、実際の出力に必要な時間明細があるか確認してください。
OpenMaxはAmazonアカウントを自動で分析できますか?
この記事は自動接続を確認したものではありません。実際の製品機能、承認された入力、チームの要件に照らして検証すべきレビュー設計を示しています。小さなサンプルで出典の追跡と人への引き継ぎを確認してから、広い構成を検討してください。
次の一歩:1回の確認を完了してから範囲を広げる
商品集合を1つ、比較期間を2つ選び、記録を埋めて計算を照合します。未解決の質問を1つ、具体的な担当者へ渡してください。最初の成功条件は、再現できる説明、または明確な証拠不足の記録です。即時の売上増加ではありません。
チームをまたぐ追跡が残った課題なら、OpenMaxにサンプル業務を相談できます。最小限の入力、必要な出力、レビュー範囲を用意し、実際の適合性を確認します。結果を再計算でき、誤りの修正方法を説明できてから対象を広げてください。

