Normalized Amazon Data

Amazon's SP-API returns data in 47 different formats across 20+ endpoints. Without normalization, you're drowning in inconsistent schemas, duplicate identifiers, and fee codes that mean different things in different reports. This guide explains what normalized Amazon data looks like and why it's the foundation for any serious analytics. The operators we see succeed here are the ones who built a habit around fee detail and contribution margin before this announcement, not after. The operators we see succeed here are the ones who built a habit around fee detail and contribution margin before this announcement, not after.

Every data team that builds Amazon integrations learns the same painful lesson: raw API data is nearly useless for analysis. Orders show one set of fees. Settlements show another. Financial events use codes that don't match either. The same product has three different identifiers depending on which endpoint you query via the Selling Partner API.

Normalized Amazon data solves this chaos. It transforms Amazon's messy outputs into a clean, consistent data model where every metric means the same thing across all your reports and dashboards. This is essential for accurate P&L analytics.

What Does "Normalized" Amazon Data Actually Mean?

Data normalization is the process of organizing data to reduce redundancy and improve consistency. According to IBM's data normalization guide, this typically involves structuring tables to eliminate data anomalies. For Amazon seller data specifically, normalization involves:

The Amazon Data Chaos Problem

To understand why normalization matters, you need to see what raw Amazon data actually looks like. Here's a sample of the inconsistencies you'll encounter when working with Seller Central reports:

This is just a glimpse. Amazon has 200+ distinct fee types, date fields that sometimes include timezone and sometimes don't, and amounts that are sometimes strings and sometimes numbers. Building reports on raw data is an exercise in frustration. Our guide on why Amazon numbers don't match Dives deeper into this problem.

What a Normalized Amazon Data Model Looks Like

A properly normalized data model transforms chaos into clarity. Here's an example of how key entities get structured, following Kimball dimensional modeling Best practices:

CREATE TABLE products (
  product_id          UUID PRIMARY KEY, asin                VARCHAR(10), seller_sku          VARCHAR(50), fnsku               VARCHAR(15), title               TEXT, brand               VARCHAR(100), category            VARCHAR(100), size_tier           VARCHAR(20), -- 'standard' or 'oversize'
  marketplace_id      VARCHAR(20), status              VARCHAR(20), -- 'active', 'inactive', 'stranded'
  created_at          TIMESTAMP WITH TIME ZONE, updated_at          TIMESTAMP WITH TIME ZONE
);

-- Every other table references product_id, not ASIN/SKU/FNSKU
-- Joins become trivial: orders.product_id = products.product_id

CREATE TABLE order_financials (
  order_id            VARCHAR(50) PRIMARY KEY, product_id          UUID REFERENCES products(product_id), order_date          DATE, -- All amounts in same currency (USD or seller's base)
  gross_revenue       DECIMAL(12,2), promotions          DECIMAL(12,2), net_revenue         DECIMAL(12,2), -- Fees normalized into logical categories
  referral_fee        DECIMAL(12,2), fba_fulfillment_fee DECIMAL(12,2), fba_storage_fee     DECIMAL(12,2), other_fees          DECIMAL(12,2), total_fees          DECIMAL(12,2), -- Pre-calculated metrics
  gross_profit        DECIMAL(12,2), margin_percent      DECIMAL(5,2), marketplace_id      VARCHAR(20), currency_code       VARCHAR(3)
);

With this structure, calculating P&L becomes a simple query instead of a complex reconciliation project. This is what powers Nova's winners and losers Analysis:

-- P&L by product: simple, fast, accurate
SELECT 
  p.seller_sku, p.title, SUM(of.net_revenue) as revenue, SUM(of.total_fees) as amazon_fees, SUM(of.gross_profit) as gross_profit, AVG(of.margin_percent) as avg_margin
FROM order_financials of
JOIN products p ON of.product_id = p.product_id
WHERE of.order_date BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY p.seller_sku, p.title
ORDER BY gross_profit DESC;

Fee Normalization: The 200+ Fee Type Problem

Amazon charges over 200 distinct fee types. Many are variations of the same thing. Others appear under different names in different reports. Normalization maps these into a manageable taxonomy that you can use for FBA fee reduction strategies:

Multi-Marketplace Normalization

Selling on multiple Amazon marketplaces multiplies the complexity. Each marketplace has different fee structures, currencies, and even field names. See our multi-marketplace analytics guide for deeper coverage:

For global sellers, normalization is non-negotiable. Without it, comparing UK and US performance requires manual spreadsheet work every time.

Benefits of Normalized Amazon Data

How to Get Normalized Amazon Data

You have three paths to normalized Amazon data. Each involves trade-offs:

For most teams, option 3 is the fastest path to value. You can always build custom layers on top of normalized data. But starting with clean data accelerates everything else. Nova's on-demand data delivery can get you started in days.

Frequently Asked Questions