Ecommerce tech stack: a reference stack for every store size

An ecommerce tech stack is the set of systems that runs an online store: the commerce platform and payments at the center, and around them the tools for product information (PIM), digital assets (DAM), site search, stock and orders (ERP or OMS), shipping, analytics, email, reviews and channel feeds. Each system should own one kind of record, and the stack works when every other system reads that record instead of keeping its own copy.

The short answer on what to buy: a store with one channel and a few hundred products needs a platform, payments, analytics, an email tool and a reviews app, and little else. A PIM earns its place when the catalog, the number of channels or the number of languages outgrows the platform admin. An ERP or OMS earns its place when stock, purchasing and finance span several locations or sales channels. Below are three reference stacks by store size, the data flows between the systems, and a buying order based on where the pain shows up first.

Eleven systems in an ecommerce stack and the record each one owns

Most stack guides list tool categories. The more useful question is which record each layer is the source of truth for, because that decides where an edit has to happen.

• Commerce platform (Shopify, WooCommerce, Magento, Lightspeed, CCV Shop): storefront, cart, checkout and the order as it is placed.
• Payments: the transaction, refunds and payouts.
• PIM (product information management): product content: titles, descriptions, attributes, categories, translations and channel-specific variants of all of those. See what a PIM is for the full definition.
• DAM (digital asset management): master images, videos, manuals and their rights and versions. Smaller stores keep assets in the PIM or platform; the PIM vs DAM guide covers when they split.
• Site search and merchandising: the search index, synonyms, ranking rules and boosted products. It reads product data and does not own it.
• ERP and OMS: stock levels, purchase orders, cost prices, invoices, and the routing of an order to a warehouse or store. The PIM vs ERP guide explains the boundary.
• Shipping and fulfillment: labels, carrier choice, tracking and returns, in a shipping app, a 3PL or the warehouse system. It reads the order and the product weight and dimensions.
• Analytics: events (views, add-to-carts, purchases) and the reports built on them, usually GA4 plus the platform's own reports.
• Email and SMS: consent, segments and the messages sent to customers.
• Reviews: ratings and review text written by customers, which feed product pages, structured data and shopping ads.
• Feeds and channel connectors: the version of each product that Google Shopping, Meta or a marketplace receives, mapped to that channel's attributes.

One source of truth per field: price, stock, content, consent

Disputes in a stack are almost always about one field claimed by two systems. Decide these owners on paper before you connect anything:

The cost of getting this wrong shows up with shoppers. In Salsify's 2025 consumer research, 54% of shoppers said they had dropped a purchase because of conflicting information. Conflicting information is what you get when a product description is edited in the store, the PIM and the feed tool, and each copy drifts.

How product, order and stock data move between systems

Draw the stack as flows, not boxes. Four flows cover most stores:

Product data: supplier to PIM to every channel

1. Supplier files, ERP item data or scraped manufacturer pages arrive in the PIM.
2. The PIM fills gaps (attributes, descriptions, translations), checks the record against each channel's rules and categorizes it.
3. The PIM pushes the record to the platform and generates channel feeds. Google's product data specification shows why the feed version differs from the store version: titles are capped at 150 characters, descriptions at 5,000, and fields like `gtin`, `brand`, `color` and `size` are required depending on product type and country.
4. Search, reviews and email tools read product data from the platform or a feed, never from a spreadsheet someone emailed.

Orders: checkout to fulfillment and back

1. The platform creates the order and takes payment.
2. The OMS or ERP picks it up, reserves stock and routes it to a warehouse.
3. Shipment status and tracking go back to the platform, which tells the customer.
4. Refunds start in the platform or OMS and post to the ERP for accounting.

Stock: one number, many displays

Stock leaves the ERP or warehouse system and goes to the platform and each marketplace on a schedule or on every change. The tighter the sync, the fewer oversells. Marketplaces punish cancellations harder than your own store does, so marketplace stock usually syncs more often or with a safety buffer.

Analytics: events to reports to a warehouse

The storefront sends events to GA4; the platform keeps the order record. Join them when you need margin or product-level analysis. A standard GA4 property can export up to 1 million events a day to BigQuery in the daily export, according to Google's documentation, which is enough for most mid-size stores before they need anything heavier. Our comparison of ecommerce analytics tools sorts the options by the job they do.

Reference stack 1: a starter store under 500 SKUs on one channel

Run everything you can inside the platform. Every extra tool is another login, another bill and another place where data can drift.

• Platform and payments: a hosted platform with built-in payments, such as Shopify with Shopify Payments, or WooCommerce with a payment plugin.
• Product data: the platform admin plus one clean CSV export as backup. A free PIM plan becomes worth it once you translate or sell on a second channel.
• Search: the platform's built-in search. Fix product data and synonyms before you pay for a separate search engine.
• Analytics: GA4 and Google Search Console, plus the platform's sales reports.
• Email: one email tool with an abandoned-cart flow and a welcome series.
• Shipping: the platform's own shipping labels or one shipping app with tracking and a returns page.
• Reviews: one reviews app that outputs review data on product pages; Google can show ratings from product structured data.
• Feeds: the platform's Google channel app.

What to skip at this stage: ERP, DAM, a separate search engine, headless front ends and middleware.

Reference stack 2: a growing brand with 500 to 10,000 SKUs and several channels

This is where the platform admin stops being a workable source of truth. Products now live in the store, on one or two marketplaces, in Google Shopping and maybe a second-language store, and each copy is edited separately unless something central owns them.

• PIM: the first major addition. One product record, enriched once, pushed to each channel with channel-specific titles and attributes.
• Feed management: inside the PIM or a dedicated feed tool, with per-channel rules for titles, categories and exclusions.
• Assets: a structured media library in the PIM, with images named and linked to SKUs. A separate DAM is rarely needed yet.
• Inventory: an inventory or light ERP tool once you sell from more than one stock location or channel.
• Search: a dedicated search app if the catalog has many attributes and filters.
• Analytics: GA4 plus order data joined at product level, so you can see revenue and margin per product and channel.
• Email and reviews: flows segmented by product category; reviews syndicated to Google.

Reference stack 3: a multi-country retailer or wholesaler with 10,000+ SKUs

At this size the stack has more systems than people who understand all of them, so integration design matters as much as tool choice.

• ERP: owns items, cost, stock, purchasing and finance. Item master data starts here, then the PIM adds content.
• OMS: routes orders across warehouses, stores and dropshippers, and handles split shipments and returns.
• PIM: content per language and per channel, classification standards for B2B (ETIM, GS1), and quality checks before anything is published.
• DAM: when brand, marketing and product teams share thousands of assets with usage rights.
• Search and merchandising: a dedicated engine with merchandising rules per market.
• Data warehouse: analytics, ERP and platform data joined in one place.
• Integration layer: middleware or an iPaaS for the flows that connect several systems.

Many stores in this bracket consider headless or composable front ends. Read what headless commerce is and composable commerce before committing: both increase the number of systems that need clean product data, they do not reduce it.

What to buy first: a sequence based on where the pain shows up

Buy in the order of the problem that costs you the most money today, not in the order a vendor's diagram suggests. A practical sequence for most growing stores:

The PIM sits in the middle of this list for a reason: search, feeds, email and reviews all read product data, so buying them before the product data is clean means configuring each one twice.

Native apps, middleware, APIs and scheduled files: four ways to connect systems

How systems talk matters as much as which systems you pick. There are four common patterns:

• Native connectors and apps: the fastest to set up and the easiest to break when one side changes. Check what fields they sync and in which direction.
• Scheduled file exchange: CSV or XML files on a schedule. Old-fashioned, easy to audit, and fine for stock and price updates that run hourly or daily.
• APIs: one system calls the other to read or write records. Most flexible; needs someone who can maintain the integration.
• Middleware or iPaaS: a separate layer that moves data between several systems and logs every run. Worth it once you have more than three or four flows.

For every connection, write down the direction, the fields, the trigger (schedule, change or manual) and what happens when a record fails. A unified commerce setup is mostly this table done carefully.

Seven stack choices that create duplicate product records

1. Editing descriptions in the store and in the PIM. The next PIM push overwrites the store edit, or the store edit never reaches the marketplace.
2. Feed tools that rewrite titles. Rules that fix titles in the feed do not flow back, so Google and your store show different products.
3. Two systems that both claim stock. The marketplace connector and the ERP both write stock to the platform, and the last one wins.
4. Image file names as the only link to a product. Rename a file and the product loses its image.
5. Analytics without order data. GA4 shows sessions and conversions but not margin or returns, so the best seller by revenue can be the worst by profit.
6. Buying search or recommendations before fixing attributes. The engine can only rank and filter on fields that exist.
7. Apps that each inject scripts. Ten apps adding scripts to every page slow the store; review page weight when you add a tool.

Running PIM, feeds and product analytics in WISEPIM

WISEPIM covers the PIM part of the stack and some of the feed and analytics work next to it. It imports a catalog, fills and fixes product data with AI (descriptions, attributes, translations and categories), checks records with Quality Guard rules, and pushes them to Shopify, WooCommerce, Magento 2, Lightspeed eCom, Ecwid, CCV Shop, Kaufland, PrestaShop, ShopWired and Google Merchant Center. Feed Hub generates channel feeds, the media library holds product images, and analytics combine Google Analytics 4 and Search Console data with orders imported from Shopify, WooCommerce, Magento 2, CCV Shop and Lightspeed.

It is not an ERP, an order management system, a site search engine, an email tool or a reviews platform, and it has no ERP connectors. For systems without a connector, the public API on the Pro plan lets your own integrations read and write products, and automations with schedule triggers run recurring imports and exports.