Blog Folders

 

Introduction

The retailer in this story sold roughly 14,000 SKUs across five channels: their own D2C site, a marketplace storefront, two regional retail partners, and a quick-commerce app. Same products. Same brand. Five different prices — and nobody inside the company could tell you what those five prices were on any given morning without opening five browser tabs and taking notes.

That is not an unusual situation. It is the default one. Retail pricing did not become fragmented on purpose; it became fragmented because each channel was added at a different time, by a different team, with a different pricing owner, and the systems never got stitched together. The result is a familiar set of symptoms:

A customer screenshots your own product cheaper on a marketplace than on your D2C site and posts it.

A competitor drops price on your top-20 SKUs on a Thursday, and your category manager finds out the following Wednesday.

Your "everyday low price" hero SKU is quietly 12% above the market on the only channel where it actually sells volume.

Your promotional calendar collides with a partner's clearance, and you spend a month arguing about who cannibalised whom.

Every one of those is a data problem before it is a pricing problem. And every one of them is solvable with the same underlying system: Automated Cross-Channel Price Matching & Alerts.

This is how that retailer built it — the architecture, the matching layer that makes or breaks the whole thing, the rules engine, the alerting design, the sample data, the mistakes, and the numbers at the end. The program was implemented with data infrastructure from Actowiz Solutions, and the design below is the one that survived contact with reality.

Why Manual Price Checking Always Fails

Before the build, the retailer had a process. An analyst spent roughly six hours a week checking prices — about 120 SKUs across four competitors, recorded in a spreadsheet, circulated on Fridays.

Do the arithmetic and the problem is obvious. 120 SKUs out of 14,000 is 0.9% coverage. Checked once a week, in a category where competitors reprice several times a day. By the time the spreadsheet landed, most of it described a market that no longer existed.

But the deeper failure was not coverage or freshness. It was that the spreadsheet contained no decisions. It listed prices. It did not say which prices mattered, which were violations of policy, which threatened margin, or which required someone to do something before lunch. It generated work rather than removing it.

The three requirements that fell out of that realisation shaped everything afterwards:

Coverage must be complete, not sampled. Every SKU, every channel, every competitor that matters.

Freshness must match the market's repricing velocity, not the analyst's calendar.

The output must be a decision, not a dataset. If a human has to scan a table to find what changed, the system has failed.

The Architecture: Six Components

1. The SKU spine

Everything begins with a canonical internal product identity. Every product gets one master SKU, and every channel listing — your D2C page, your marketplace listing, your partner's listing, each competitor's equivalent product — is mapped to it.

This sounds trivial. It is the single hardest part of the project, and the reason most price-matching initiatives quietly die. Get it right and every downstream layer works. Get it wrong and you will spend eighteen months not trusting your own dashboards.

2. Collection

Multi-channel price data has to be collected from wherever it lives: your own channels, your partners' sites, marketplaces, and competitor storefronts and apps. Multi-Channel Price Data Tracking at 14,000 SKUs × 5 own channels × 6 competitors is a meaningful engineering commitment — roughly a million observations a day at hourly cadence on the top tier alone.

The retailer chose not to build this in-house. The maintenance burden of E-commerce price Data Scraping — layout changes, app updates, regional variants, anti-bot evolution, new channel onboarding — is continuous and never becomes a competitive advantage. They contracted the collection and normalization layer to Actowiz Solutions, delivered as a stable schema over API and webhook, and put their own engineers on the rules engine instead, which is where the actual differentiation lives.

3. Matching

Mapping your SKU to the equivalent competitor product. Not the same product — the equivalent one. This is where judgement enters the system, and it is covered in detail below.

4. The rules engine

Converting observed prices into policy verdicts: compliant, violation, opportunity, threat. Rules encode your commercial strategy, so they belong to you and not to a vendor.