Amazon, Flipkart and Myntra Bestsellers: A Daily Data Feed for E-Commerce Aggregator Apps

Introduction

Bestseller lists are the most-used and least-understood dataset in Indian e-commerce. An aggregator app builds a "trending now" feed from them. A brand reports a rank improvement as a sales win. Both read an ordinal signal as if it were a volume.

Rank is genuinely useful. It is the closest public demand signal these platforms expose, and it updates fast enough to catch real movement. But it tells you ordering, not magnitude, and each platform computes it differently.

If you are building a feed others will make decisions on, the reading rules matter as much as the collection.

What rank represents on each platform

The three platforms differ in ways that affect comparability.

Three consequences for anyone building a feed.

Rank is scoped to a category. A rank of 3 means third within that specific node. Comparing ranks across nodes without normalising by node size is the most common error in aggregator feeds.

Merchandising influences the surface. On Myntra especially, what appears high on a category page reflects merchandising as well as demand. Treat these lists as what the platform is promoting and what is selling, combined.

Refresh rates differ. Amazon moves fastest. Collecting all three on one schedule and presenting them as of a single timestamp implies an equivalence that does not exist.

Rank, share of search and listing count are three signals

Teams routinely blend these. They answer different questions.

A brand can hold high listing count and weak rank — broad assortment, thin demand. It can hold strong rank on two SKUs and near-zero share of search — dependent on category browse, invisible to searchers. Both findings disappear if you merge the three into one index.

Keep them as separate columns. If a stakeholder wants one number, build the composite in the reporting layer where its weights stay visible, never in the collection layer where they become invisible assumptions.

Collection design

Four decisions define the dataset.

Category tree traversal. Snapshot the tree first, as its own versioned dataset. Platforms reorganise categories, and a hard-coded path that starts returning a different node looks exactly like a demand shift. Store category_tree_version on every observation.

Depth. Decide your read depth per node and hold it fixed. Read top 50 one day and top 100 the next, and every aggregate moves for reasons unrelated to the market.

Node selection. Leaf nodes carry the useful signal. Parent-node lists are dominated by a few high-volume sub-categories. Track leaves, roll up in reporting.

Cadence. Daily minimum for rank, in fixed collection windows.

The last row is easy to miss. A jump from rank 40 to rank 4 usually has a price change behind it. Without price on the same record, your feed shows a mystery.

Fixed windows are not optional for rank. Amazon's lists refresh through the day, so a 6 a.m. reading and a 6 p.m. reading are different measurements — and the gap between them masquerades as a trend.

The field schema

One row per item per node per platform per run.

Two fields carry outsized weight.

is_sponsored — if sponsored placements leak into a bestseller feed, you are publishing advertising as demand. Capture it and exclude it from rank series.

rank_depth_collected — an aggregate over top 50 is not comparable to one over top 100. Storing depth on the row lets you always restrict a comparison to a common depth.

How aggregator apps consume it

Three patterns cover most implementations.

Trending feeds. The valuable signal is rank change plus new entry, not rank itself. An item entering a node's top 20 for the first time is more interesting than one that has been rank 3 for eight months. Build the feed on rank_delta and first_seen_in_node_at.

Category landing pages. Populate from durable rank — items with high days_in_node — rather than today's snapshot. Returning users expect continuity, not a feed that reshuffles hourly.

Recommendation seeds. Rank is a reasonable cold-start prior when you have no behavioural data. Replace it as engagement data accumulates; it is a starting point, not a ranking function.

Decide early whether your app shows one platform's rank or a blended view. A blended view needs solid cross-platform matching, or users see the same product twice with different ranks and stop trusting the feed.

Rank is ordinal, not volumetric

This deserves stating plainly, because it is where the expensive mistakes happen.

Rank 200 to 100 and rank 3 to 2 are not comparable improvements. The distance between adjacent ranks is not constant, and it compresses sharply at the top.

What rank data cannot do:

• Convert to units sold. Any conversion needs a per-category calibration set from actual sales data, and it decays.
• Support comparisons across categories without normalising by node size.
• Show a demand change proportional to the rank change.

What it can do:

• Track direction and persistence within a node over time.
• Detect entries and exits, which are unambiguous events.
• Compare a brand's rank profile against competitors in the same node on the same day.
• Correlate rank movement with observed price and availability on the same records.

If a stakeholder needs volume, say the dataset does not contain volume. Rank distribution and rank-change frequency by category node is what the data supports. A modelled units estimate presented as observation is the fastest way to lose credibility.

Deduplication and cross-platform matching

For a single-platform feed, the platform ID is your key — the same ID in multiple nodes is one product in several nodes, not several products.

Cross-platform is the real work. The same product carries an ASIN, an FSN and a Myntra style ID, with three different titles and three different image sets.

Fashion is harder than the rest. Colour names and size systems differ across platforms, and the same style may be listed under different names. For Myntra, plan on more human review in the matching loop.

Score, then use two thresholds — auto-accept, review, discard — and store every decision with its signal breakdown. Publish the review-queue size as a quality metric. A feed that admits its matching uncertainty is more usable than one that claims none.

Actowiz Solutions delivers daily bestseller, rank and share-of-search feeds across Amazon India, Flipkart and Myntra, with fixed collection windows, sponsored placements flagged, and cross-platform matching scored per record.

We ship observed fields with depth and run-health metadata, so your feed's aggregates stay comparable over time.

Frequently Asked Questions

Can bestseller rank be converted into units sold?

Not from public data alone. Rank is ordinal, and the gap between adjacent positions is neither constant nor comparable across categories. Any conversion requires a calibration set from actual sales data for that specific category, and it degrades over time.

How often should bestseller data be collected?

Daily at minimum, in a fixed collection window. Amazon's lists refresh through the day, so readings taken at different hours are different measurements. Fixed windows keep the series comparable; price should be collected on the same records to explain rank moves.

What is the difference between bestseller rank and share of search?

Rank orders items by sales or popularity within one category node. Share of search measures how often a brand appears in results for tracked queries. A brand can rank well through category browse while being nearly invisible in search, so the two should be reported as separate signals.

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!