Product sales over time
based, so returns land on the day they happened.
- Grain
- day x seller x marketplace x ASIN x SKU x row type
- Built from
- 4Raw tables
- 5Staging
- 1Core
- 1Analytics
- Reads from Amazon Selling Partner API
- fba_returns_reportmerchant_listings_reportorders_by_last_updated_date_reportreturns_by_return_date_report
- Ships as
- Weld and dbt SQL, open source on GitHub
1-- amazon_seller_product_sales_over_time - the sales equation at line grain, event
2-- based, so returns land on the day they happened.
3--
4-- Grain: day x seller x marketplace x ASIN x SKU x row type. Currency: the order's.
5-- Depends on: staging.amazon_seller.orders, .returns, .fba_returns, .listings
6--
7-- THIS IS THE MODEL THAT MAKES AMAZON DATA BEHAVE. Everything else in the connector
8-- is a current-state report; this one is an event log.
9--
10-- The mistake it exists to prevent: `SUM(item_price)` off the order report, grouped
11-- by purchase_date. It looks right, it ties to Amazon for a fresh month, and then
12-- it drifts - because a refund issued today reduces the day the order was PLACED.
13-- Last quarter's revenue changes after you have reported it, and nobody can explain
14-- why the same query returns two different answers a week apart.
15--
16-- The fix is to stop treating a sale and its reversal as one fact. A row here is a
17-- financial EVENT: an order line produces a SALE row on its purchase date, and if
18-- it comes back it produces a separate RETURN row on the return date. Signs are set
19-- so the two sum correctly with no special casing:
20--
21-- gross_sales positive on SALE, zero on RETURN
22-- discounts negative always
23-- returns zero on SALE, negative on RETURN
24-- net_sales gross_sales + discounts + returns <- plain addition
25--
26-- Row type is part of the grain, so a day where a SKU both sells and refunds
27-- produces two rows and each side stays independently auditable. Aggregate away the
28-- row type in BI.
29--
30-- RECONCILING TO core.amazon_seller.sales_over_time. Sum net_sales over the SALE
31-- rows for a closed month and you land within a fraction of a percent of Amazon's
32-- ordered_product_sales. It is not exact and it cannot be - see the README - so
33-- treat a consistent small gap as expected and a growing one as a bug.
34
35WITH sales AS (
36 SELECT
37 o.purchase_date AS date,
38 o.amazon_seller,
39 o.marketplace,
40 o.asin,This model and the 6 it depends on. Deploy them together; refs like {{staging.…}} resolve to the matching folders in Weld, and the dbt view uses source() and ref().
How it counts. And where it stops.
THIS IS THE MODEL THAT MAKES AMAZON DATA BEHAVE. Everything else in the connector is a current-state report; this one is an event log. The mistake it exists to prevent: `SUM(item_price)` off the order report, grouped by purchase_date. It looks right, it ties to Amazon for a fresh month, and then it drifts - because a refund issued today reduces the day the order was PLACED. Last quarter's revenue changes after you have reported it, and nobody can explain why the same query returns two different answers a week apart. The fix is to stop treating a sale and its reversal as one fact. A row here is a financial EVENT: an order line produces a SALE row on its purchase date, and if it comes back it produces a separate RETURN row on the return date. Signs are set so the two sum correctly with no special casing: gross_sales positive on SALE, zero on RETURN discounts negative always returns zero on SALE, negative on RETURN net_sales gross_sales + discounts + returns <- plain addition Row type is part of the grain, so a day where a SKU both sells and refunds produces two rows and each side stays independently auditable. Aggregate away the row type in BI. RECONCILING TO core.amazon_seller.sales_over_time.
Raw tables it reads
- raw.amazon_seller_central.fba_returns_report
- raw.amazon_seller_central.merchant_listings_report
- raw.amazon_seller_central.orders_by_last_updated_date_report
- raw.amazon_seller_central.returns_by_return_date_report
More Amazon Selling Partner API models
Put Amazon Selling Partner API in front
of your agents.
Connect Amazon Selling Partner API, deploy the models, and ask questions in Claude, Cursor or ChatGPT. Free for 14 days, no credit card.