Dauren Moldabayev

Margin per SKU, after every fee

A warehouse, a data model and reporting for multi-channel ecommerce: your own site, Amazon and other marketplaces, with fees, advertising, product cost and logistics in one place. I build the whole chain, not the dashboard on top of someone else’s numbers.

For founders, COOs and finance leads of multi-channel brands and marketplace sellers.

The model node, magnified: one order fact, conformed dimensions, margin per SKU fact_orders dim_sku dim_date dim_channel dim_shipment dim_fee dim_ad margin per SKU
The model node, magnified: one order fact, conformed dimensions, margin per SKU. Figure, not client data.

If this sounds like your week

  • Amazon says you’re profitable. The bank account says otherwise, and nobody can see margin per SKU after fees, ads and shipping.
  • Every channel has its own report. Website, Amazon, the other marketplaces: the numbers don’t line up and nobody trusts the total.
  • You find out about out-of-stock when the listing dies, and about overstock when the warehouse bill arrives.
  • Ad spend in one place, sales in another, COGS in a spreadsheet. Nobody can tell you which products actually make money.
  • Fulfillment cost keeps creeping up and there’s no view of which routes or pickup points are driving it.
  • You want to know which handful of SKUs carry the business, and which ones to stop reordering.

What gets built

Sources
Marketplace seller reports and APIs, own-site orders and web analytics, advertising platforms, logistics and fulfillment data, procurement cost data.
marketplace and advertising APIs, REST APIs, Google Analytics, Google Ads
Warehouse
An analytical warehouse loaded through automated pipelines; PostgreSQL where you already run it.
Google BigQuery or ClickHouse, PostgreSQL, SQL
Data model
One model with a COGS structure (procurement, marketplace fees, logistics), SKU-level margin, inventory and turnover metrics (DIO, stock coverage, out-of-stock and overstock risk), ABC/XYZ classification, plan-versus-actual and period comparison.
DAX, Power Query (M), SQL, Git
Reporting
Dashboards for owners and operations teams, built for the daily decisions on pricing, assortment and advertising.
Power BI, Looker

Work I can describe

For a US ecommerce company selling through its own website, Amazon and other US marketplaces, I built the reporting layer on Google BigQuery as the core warehouse, with dashboards in Looker and Power BI. The work covered a full product cost structure (procurement, marketplace fees and logistics), profitability at SKU level with the cost drivers identified, plan-versus-actual, month-over-month and cumulative metrics, and analysis of shipment routes and allocation to the nearest fulfillment or pickup points to reduce delivery cost and lead time.

For a seller operating on third-party marketplaces, I built financial and operational analytics on ClickHouse and PostgreSQL feeding Power BI: SKU-level profitability including revenue, cost price, margin and advertising spend; ABC/XYZ analysis to find the revenue and profit drivers; inventory and turnover metrics (DIO, stock coverage, out-of-stock and overstock risk), with data integrated from marketplace APIs, databases and advertising platforms.

Clients are not named. US client reference available on request.

How we start

  1. I

    Discovery call

    The pricing, assortment and advertising decisions the reporting has to support, and where the data sits today.

  2. II

    Data audit

    Seller reports, ad accounts, order data and cost sheets: what is missing, what disagrees.

  3. III

    Model, reporting, handover

    Warehouse, COGS structure, SKU margin and inventory metrics agreed with you; then the dashboards; then documentation, scheduled refresh and monitoring so your team runs it.

Send the three reports that disagree.

Name the channel, the product and the two totals that never match. That is enough for a first call.

Email dauren.m@lief.devEmail Dauren

WhatsApp · Telegram