この度新たにamazon_retail_purchasesというサービス(テーブル名でもある）が登場した。これを使うと過去５年間の顧客別購買履歴を追いかけることができる。ただ例示されていた５年間の購買履歴をつかった分析Templateはあまりよくない〜つまり５年間という「尺 (lookback window)」の最初の購買を暗黙に「新規」と決めつけているきらいがあるからだ（実際そんな保証はどこにもない）。なので追加で必要な作業は「新規」 or 「既存」のロジック〜例えば「過去１年間購買がある・なし〜を全ての購買（purchase_id or 注文番号) へのフラグ立てこと。
Amazon Insightで使われていたconversion_all テーブルにはあらかじめこのNew_To_Brandフラグがつけられていたが、このamazon_retail_purchasesにはフラグがなく、作業そのものを自前で行う必要がある。ちなみにconversion_allは尺が12.5ヶ月しかないという別の欠点があったためLTVの計算にはやや限界があった（LTVは複数年を跨いで計算するところに一番意味があるから）。またconversion_allテーブルにはpurchase_id (注文番号)がなかったが、amazon_retail_purchasesにはpurchase_idがあるため同一注文が明確になったし、注文件数という新しい指標も計測可能になった。
自社全ブランドのユーザー別購買履歴が４年間とれることでInsightは飛躍的に向上する。つまりamazon_retail_purchases を使って、ランズエンド社で言うところのいわゆるFulton Report /顧客ロイヤリティセグメント別のCohort分析（下図)がAmazonの中で構築できることになったわけでその意味は大きい、アマゾンのAMC機能のなかで最も有効なサービスの一つも言える。特に販売単価が５千円以下の価格帯にある一般消費財でかつリピート購入がある商材（FMCG)の場合、Direct_To_Consumer (DTC)で利益確保がきわめて困難なことを考えれば、アマゾンへの出店はもっとも有力な選択肢と言える。かつてDTCでやっていたようなロイヤリティ・セグメント別に前年比較が週単位で可能になったわけで、どの顧客セグメントにポテンシャルがあるかどうかがわかり、conversion_allでは見えてなかった部分が大きく改善されることになる。週単位で前年比較ができるため、年度末の売上予測推定値は週次で更新されメーカーでよくありがちな商品分析では到底達成できないような予測精度が、顧客セグメントという新たな軸を加えることによって実現される。
図解のとおり最初の２カ年度を使ってセグメンテーションをするため、集計できるのは３年目以降になる。言い換えると５年尺のamazon_retail_purchasesを使う場合には同時に集計可能なのは最大３年間だが、キリのいいところでスタートできないため、同時に分析できるのはたいていは最大２年間となる。Weeklyで継続率 (Year-to-date)を集計するとセグメント別にある一定の継続率に収束する（経験値）、したがって年度末の売り上げ予測が高い精度で実現することになる。ちなみにamazon_retail_purchasesの利点としては、サービス開始日以前に遡って５年間尺のデータがすぐに使える点である。通常のAMCの場合にはサービス開始日以降のデータしか使えないので、データがたまるのを待つ必要があったが、amazon_retail_purchasesは例外のようである。
評価指標としては売上は以下に因数分解できる。
売上 = 潜在顧客数 x 継続率 x 注文件数/顧客数 x 個数/注文件数 x 売上/個数(=価格)
顧客セグメント別に週次でYoY (Year-Over-Year or 前年同週比)のトラッキングが可能になる。特に潜在顧客数は年度通して固定されているため、残りの分解された係数は前年同じ週の実績値と比較することで当年度の着地予測はかなり高い精度で可能になる。ここが顧客コホート (cohort) 分析の最大のメリットで、以下のようなチェックを週次で行うことができる。
🔸どのセグメントの継続率が前年同じ週に比べて良いか・悪いか
🔸 新規顧客は前年同じ週にくらべて高いか低いか
🔸 どのセグメントの価格が前年同じ週にくらべて高いか低いか
注意点がいくつかある。
１） 実際にこの分析を使うにあたってVendor Centralの売上レポートと差異検証したところ１年間での売上差異は0.1%程度におさまったため、中長期計画や売上予測などが実務には十分耐えられるレベル。ケーススタディ(introduction to amazon_retail_purchases)によれば、For Vendor Central accounts, the scope of data in Amazon Retail Purchases will match with what is shown in the Vendor Central “Reports > Retail Analytics > Sales > Distributor View = Manufacturing”とあり、ベンダーセントラルの売上レポートのお取引形態＝メーカー、つまり自社で直接Amazonへ納品した分にマッチすると記載がり、具体的にはOrdered Revenue /「注文分の売上」に相当する。(注意：「発送分」ではない）またベンダーセントラルと同レベルにするためにビジネスをフラグ (is_business_flag = FALSEの条件を適用する必要がある。以下、SQLのイメージ)
SELECT
arp.user_id,
arp.purchase_id,
CONVERT_TIME_ZONE_FROM_UTC(arp.purchase_date_utc, 'Asia/Tokyo') AS purchase_date_jst,
CAST(DATE_TRUNC('WEEK', CONVERT_TIME_ZONE_FROM_UTC(arp.purchase_date_utc, 'Asia/Tokyo')) AS TIMESTAMP) AS week_start_jst,
CAST(arp.purchase_units_sold AS DOUBLE) AS units_sold,
CAST(arp.unit_price AS DOUBLE) AS unit_price,
arp.asin
FROM amazon_retail_purchases arp
WHERE arp.user_id IS NOT NULL AND arp.is_business_flag = FALSE
AND CONVERT_TIME_ZONE_FROM_UTC(arp.purchase_date_utc, 'Asia/Tokyo')
BETWEEN DATE '2022-10-03' AND DATE '2025-09-28'２）この５年尺は常に最新日を起点に遡るため日々演算可能期間が１日づつずれていく構造にあること。そのため、例えばロイヤリティ・セグメント別にリピート率経年比較をしたい場合 (いわゆるFULTON Reportのような顧客Cohort分析の場合)には現実的にはレポート開始日からレポート終了日（つまり年度開始の初日から最終日までの１年間）まで共通して分析可能な期間は４年に縮まってしまう（計測開始の初年度はとくに）。いったん計測を開始すれば、計算結果だけをオフラインで保存していけば比較可能期間は順次増えていくだろうが、過去に遡っての再計算はできないためクエリの変更を伴う場合には５年以上遡れないという限界もある。
３）もう一つやっかいな問題がデータ量が膨大であると同時にAMC固有のセキュリティ規制（いわゆるクリーンルーム）があるため使用できるSQLが限定されていて、例えばユーザ一覧を出力することができず、CTEを使って１つのクエリーで一気にセグメント別の集計演算を終えなければいけない。実はクエリーを試行錯誤で改善していったら、かつて３００分以上かかっていた１ヶ月分のCohort演算が１年分まとめてもたったの１２分程度で終了できることができた(Chat GPTに感謝🥲）ので、SQL文を工夫次第で飛躍的に効率アップも可能と思われる。
Amazon Marketing Cloud Practitioner