Data Stack for an Omnichannel DTC Brand

Online orders now sit next to an ERP, wholesale accounts, and retailer data. Finance, operations, and planning need one model that covers every place the product is sold.

The short answer

An omnichannel brand needs one model across online, wholesale, and retail sales, built on an ERP such as NetSuite, wholesale through Faire or direct accounts, and retailer or POS data. Brands with standard omnichannel needs should look hard at Daasity before a build. A build adds a product master that maps every retailer's item code, and keeps sell-in and sell-through as separate metrics.

Sound familiar?

  • NetSuite or another ERP holds wholesale orders and costs.
  • Retailers send sell-through data as portal exports or files.
  • Several brands or regions share one team.
  • Planning happens in spreadsheets copied from reports.

Why it happens

Retailer data does not share your IDs
Retailer data rarely uses your product IDs or customer IDs, and it arrives on the retailer's calendar. Without a product master, the same item shows up under several codes.
Many sources have no connector
ERP and back-office systems are covered by broad connector catalogs, but retailer portals, EDI files, and wholesale spreadsheets often are not.
Sell-in and sell-through get mixed
Your shipments to a retailer and the retailer's sales to customers are different numbers. Reported as one, they hide inventory sitting on retailer shelves.

How we fix it

  1. 1

    Load the ERP and the files nobody connects

    Use Fivetran for ERP and back-office sources, plus custom code for retailer portals, EDI files, and wholesale spreadsheets. Land everything in Snowflake or BigQuery, or wherever a packaged product already writes.

  2. 2

    Build the product master and separate metrics

    Model in dbt, or extend Daasity's models if your rules are close to standard. Map every retailer item code to one product, and keep sell-in and sell-through as separate metrics.

  3. 3

    Share definitions with BI, planning, and AI tools

    Start with a dictionary, then encode it as Snowflake semantic views if BI and AI tools both read metrics, or a shared Power BI model in a Microsoft shop. Sigma input tables let planners type forecasts next to actuals.

What you end up with

  • A product master that maps each retailer's item code
  • Sell-in and sell-through as separate metrics
  • One sales model across online, wholesale, and retail
  • Plans entered next to actuals in Sigma input tables

Common questions

Should we buy Daasity or build our own warehouse?

Look hard at Daasity first if your omnichannel needs are standard. It offers prebuilt omnichannel models in Snowflake or BigQuery with retail and syndicated data connectors. A build fits better when your models need rules specific to you, or you want to choose the BI tool.

How do we load retailer data that has no connector?

With custom code that reads the portal exports, EDI files, or spreadsheets on a schedule. Most brands end up with two or three ingestion answers across their stack, chosen source by source.

What is the difference between sell-in and sell-through?

Sell-in is what you ship to retailers. Sell-through is what retailers sell to their customers. Keep them as separate metrics, because the gap between them is inventory still on retailer shelves.

Should our semantic layer be Snowflake semantic views or a BI model?

Use Snowflake semantic views if both BI and AI tools will read your metrics. Use a shared Power BI model if you are a Microsoft shop and Power BI is the main reader. Either way, write the dictionary first.

When should we sync audiences back to marketing tools?

Last, after the customer view is trusted. Hightouch or Census can push warehouse audiences to Klaviyo and ad platforms, but syncing before one person is one customer makes targeting misfire.

Bring the numbers that don't add up

We'll trace them to the source with you and say where we'd start. No pitch deck.

Book a Call