Amazonの売上集計を自動化したい。SP-APIで何ができ、何を準備する？

「昨日の売上」を、誰と同じ数字にするか

説明用の例として、複数ストアの前日の販売額を毎朝共有する業務を考えます。営業は受注時点の金額を見たい一方、経理は出荷や返品、調整を含めて確認したいかもしれません。どちらも売上という名前でも、対象の状態と時点が違えば数字は一致しません。自動化の前に、報告を使う人と基準を揃える必要があります。

対象ストア、期間、通貨、日付のタイムゾーン、返品の計上方法を一つずつ確認します。既存の帳票と比べるなら、同じ条件でサンプルを作ります。違いが出たときに取得漏れと決めつけず、集計対象や確定時点を調べられるようにします。注文数と注文明細数も別の指標なので、何を一件と数えるかまで共有しておくと、後の報告が分かりやすくなります。

表が収まらない場合は横にスクロールできます。

開発前に、データを使う許可を準備する

SP-APIでは、販売事業者がアプリへデータを扱う許可を与えます。Amazonの公式資料は、一組織が使う非公開アプリと、複数の販売事業者が使う公開アプリで認可方法を分けています。自社内の集計と、顧客企業へ提供するサービスでは、利用者管理や再認可の仕組みも変わります。まずどちらの用途かを開発会社へ伝えます。

社内ではアカウントの管理者と、申請や認可を操作できる人を確認します。必要な操作の権限が得られるかも、開始前の調査事項です。個人情報を扱う制限対象の操作にはRDTなどの条件があるため、対象APIと版ごとに確認します。日次の販売集計に氏名や住所が不要なら、取得対象へ増やさない案を選べます。

参考：Amazon：Authorize Applications ／ Amazon：Tokens API

レポートは、依頼してすぐ完成するとは限らない

Reports APIでは、作成を依頼し、その進行状態を確認してからデータを取り込む工程があります。作成依頼が受け付けられたことと、社内の集計が完成したことは違います。販売事業者、対象期間、レポート種別、受け取ったIDを記録し、実行が途中で止まっても、既存の依頼を追って続きから処理できるようにします。

完了状態も一種類ではありません。公式資料にはDONE、CANCELLED、FATALがあり、CANCELLEDには返すデータがない場合の自動取消と明示的な取消が含まれます。取消をすべてゼロ件として扱うと、取得できなかった情報を売上なしと報告するおそれがあります。ファイルの取得と取り込みまで終わった段階を、業務上の完了として区別することが必要です。

参考：Amazon：Request a report ／ Amazon：Verify that report processing is complete

朝の締め切りに間に合わせるには、待つ時間も測る

一度にたくさん呼び出せば速く終わるとは限りません。SP-APIは操作やアカウントとアプリの組み合わせなどによって制限が変わり、制限値を示すヘッダーも常に返るわけではありません。件数だけでなく、一覧、詳細、ページ送り、再試行が何回必要かを見ます。処理を増やしても制限は回避できないため、取得方法と優先順の工夫が必要です。

試験は普段の一日分に加え、停止後に過去分を取り戻す場面でも行います。過去分の取得が当日の報告を妨げないよう、別の優先度で扱う案があります。AmazonはSandboxで本番のレート制限そのものを検証できないと説明しています。呼び出し形式やエラー処理の試験と、許可された本番範囲で時間や取得量を確認する試験を分けて計画します。

参考：Amazon：Usage Plans and Rate Limits

取れていないストアを、売上ゼロにしない

先ほどの説明用の例で、一つのストアだけレポートが間に合わなかったとします。合計額だけを投稿すると、見る人には全ストアの数字が揃っているように見えます。取得済みの範囲と未取得のストアを示し、暫定の報告として共有するか、全件揃うまで待つかを決めます。前日の数値を流用する場合も、対象日が違うことを明示しなければ判断を誤ります。

遅れた分を取り込む際は、同じ期間のデータを単純に追加しないようにします。事業者、ストア、対象期間、集計の種類を一組にし、訂正版として差し替えるか版を残します。元データの取得時刻と集計規則も残せば、後日の返品や調整で値が変わった理由を調べられます。報告済みの内容を訂正するときに、誰へ知らせるかまで業務側で決めておきます。

開発会社には、接続できることより数字を説明できることを求める

最初の相談では、使っている帳票、必要な項目、報告の締め切り、対象ストアを共有します。APIと権限の調査で取得できる条件を確認し、それから本開発を見積もる進め方もあります。費用には認可の準備、集計規則、過去分の再取得、保留の表示、引き継ぎまで何を含むかを揃えます。申請の待ち時間と開発の作業時間も分けて考えます。

Amazonはレポートへ項目や値が追加されることがあると案内しています。知らない列が増えた場合と、必要な列が欠けた場合を同じ扱いにせず、確認が必要なデータは保留します。納品時には、対象期間だけ取り直す、認可が失効する、取得が遅れる場面を担当者と試しましょう。「この数字はどこから来たか」に答えられれば、日々の報告にも訂正にも使える連携になります。

参考：Amazon：Reports API

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □売上の意味と比較する帳票を揃える。確認状況・メモ：
• □ストア・期間・通貨・日付の基準を確かめる。確認状況・メモ：
• □用途が自社専用か他社向けかを伝える。確認状況・メモ：
• □認可や申請を操作できる担当者を決める。確認状況・メモ：
• □作成待ち・取消・異常・取得済みを分ける。確認状況・メモ：
• □遅れた期間を取り直しても重複集計しないか試す。確認状況・メモ：
• □認可更新とレポート仕様変更の確認担当を決める。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Authorize ApplicationsAmazon
• Tokens APIAmazon
• Usage Plans and Rate LimitsAmazon
• Request a reportAmazon
• Verify that report processing is completeAmazon
• Reports APIAmazon