A competitor's new product is public on a marketplace before it is public anywhere else. Before the press release, before the ad campaign, before it reaches a retail panel, the listing exists. New-listing detection is therefore the earliest externally observable signal of a competitor's strategy — which formats they are betting on, which price bands, which platforms first, how wide they go.
Most teams do not have it, for a structural reason: a snapshot cannot find a launch. Crawl a category today and you get a complete list of what exists. Nothing in that list says which items are new. Newness is a property of the difference between two observations, not of any single one.
This piece covers how to build that difference reliably, how to avoid the four false positives that ruin launch feeds, and how far you can honestly go in measuring whether a launch worked. Our ecommerce data collection service runs the delta pipeline this post describes, with versioned scopes and pass-completeness metrics.
New-listing detection is a delta problem. It requires:
Point four is where most implementations fail. If a crawl missed a listing on Tuesday because a page timed out, and it appears on Wednesday, a naive difference calls it a launch. In a large category with normal collection variance, this produces enough noise to make the feed unusable, and the team stops opening it.
The fix is a lookback window plus an absence requirement. A listing is a launch candidate only if it was absent across a defined number of consecutive prior passes covering the same scope. Store first_seen_date, passes_absent_before_first_seen and scope_coverage_confidence. A listing appearing after one missed pass is then flagged low confidence; one absent for thirty passes is flagged high.
Record crawl completeness per pass too. If a pass covered 60% of the expected scope, everything "new" in the next pass is suspect. A pass_completeness metric is what makes the feed trustworthy.
Four things look like launches and are not. Each needs an explicit test.
A relist. The same product removed and re-added, usually with a new platform SKU ID. Common when sellers change, when a listing is corrected, or after a takedown. Test: match the candidate against your historical corpus on brand plus normalised title plus pack quantity, plus image or barcode-like identifiers where available. A high-confidence match to a listing last seen recently is a relist.
A rename. Same product, same identifier, title changed. Not a new listing at all, but it breaks title-based matching and appears as a launch in any downstream system keyed on title. Test: watch for title change on a stable platform_sku_id, and store a title history. Renames are often repositioning, so the history has value of its own.
A variant addition. A genuinely new listing, but for a new pack size, flavour or shade of an existing product. Whether that counts as a launch depends on your question, so the answer should be a field rather than a pipeline judgement. Test: match against the existing product family on brand plus product line, differing only on pack quantity or variant attribute.
A newly serviceable existing listing. The listing existed on the platform but was not visible in the pincodes you sample. You expanded the panel, or the platform expanded coverage, and it appeared. This is the quick-commerce-specific trap, and it generates large false-positive waves whenever a panel changes. Test: check whether the listing exists in your corpus for any other pincode, and whether that pincode's serviceability or panel membership changed in the same window.
| Candidate type | Distinguishing test | Classification |
|---|---|---|
| New product | No historical match on brand + normalised title + pack; new product line | new_product |
| New variant of existing line | Matches product family; differs on pack size or variant attribute | variant_extension |
| Relist | High-confidence match to listing last seen within lookback | relist |
| Rename | Title change on stable platform SKU ID | rename — not a launch |
| Newly serviceable | Exists in corpus for other pincodes; panel or serviceability changed | newly_serviceable |
| New seller on existing product | Matches product; seller identity differs | new_seller_listing |
Store the classification and the evidence. A launch feed where every record carries why it was classified that way is one a category team will trust; one that emits bare assertions is one they will stop opening. The relist test is a matching problem before it is a classification problem; our product matching for relist detection service is what makes it reliable.
You cannot find launches you never crawl. Coverage is the binding constraint, and three methods have different blind spots.
Category-tree traversal. Walk the platform's category nodes, paginate to depth, record everything. Systematic, reproducible, and it gives you the denominator share calculations need. Weakness: misses miscategorised or uncategorised products — and new listings are disproportionately likely to be exactly that, because a brand launching in a hurry files the product wherever is fastest.
Search-led discovery. Run a maintained query set — category terms, product-type terms, ingredient and benefit terms, brand names including brands you do not yet track. Finds products merchandised for search regardless of category placement, and finds new brands you had no reason to look for. Weakness: query-set-dependent by construction, noisy, no clean denominator.
Brand-storefront crawling. Walk each tracked brand's store page. The most complete view of a single brand's range, and typically the earliest detection, because brands populate their own storefront first. Weakness: only covers brands you already track — the exact blind spot for a new D2C entrant.
Run all three and reconcile into one candidate set. Record discovery_method per record and keep it after reconciliation, because the field is diagnostic. A competitor product found only via brand storefront and absent from category nodes has a categorisation weakness — a gap you can exploit, and a mistake to avoid making yourself.
For new-entrant detection, add a fourth input: periodic broad sweeps looking for brand names absent from your brand master. New brands enter your data as unmatched brand strings before anyone thinks to add them to a tracking list.
Cadence is a cost decision constrained by how fast the category moves and how perishable the signal is.
| Category characteristic | Suggested cadence | Reasoning |
|---|---|---|
| Fast launch cycles — beauty, D2C food, supplements | Daily | Launch volume is high, first-mover response window is short |
| Quick-commerce assortment | Daily, plus pincode rotation | Assortment changes per store; panel needs frequent re-observation |
| Seasonal windows | Daily during the window | A six-week season cannot be tracked weekly |
| Stable packaged categories | Weekly | Launch volume low; weekly is sufficient and much cheaper |
| Long-cycle categories — appliances, durables | Weekly or fortnightly | Launch cadence measured in quarters |
Two cadence disciplines matter more than the frequency itself.
Keep scope constant across passes. If pass one covered four category nodes and pass two covered six, the difference includes everything in the two new nodes. Version the scope and treat any change as a deliberate event with a baseline reset for the affected portion.
Rotate pincodes, but rotate a fixed panel. For quick commerce you cannot crawl every pincode daily. A fixed rotating panel gives full coverage over a known number of days, and the schedule is what makes first_seen_date interpretable. Unplanned rotation makes every launch date approximate by an unknown amount.
A launch record is a distinct entity from a daily observation. It is created once per detected launch and updated as evidence accumulates.
| Field | Type | Purpose |
|---|---|---|
| launch_id | string | Primary key for the launch entity |
| first_seen_date | date | Detection date, not necessarily platform live date |
| first_seen_timestamp | datetime | Precision where cadence is sub-daily |
| detection_confidence | enum (high, medium, low) | From absence history and pass completeness |
| passes_absent_before | integer | Evidence for the confidence rating |
| launch_class | enum (new_product, variant_extension, relist, rename, newly_serviceable, new_seller_listing) | The core classification |
| classification_evidence | text | Why it was classified this way; makes the feed auditable |
| discovery_method | enum (category_tree, search, brand_storefront, broad_sweep) | Coverage diagnostics |
| platform | string | Launch platform sequencing |
| first_seen_pincodes | array | Initial geographic footprint |
| platform_sku_id | string | Within-platform key |
| internal_product_id | string | Cross-platform matched identity |
| brand_raw, brand_normalised | string | Brand rollups |
| brand_is_new_to_corpus | boolean | New-entrant flag |
| product_line | string | Family grouping for variant classification |
| listing_title_at_launch | text | Baseline for rename detection |
| category_path_at_launch | text | Categorisation quality assessment |
| pack_quantity, pack_unit, pack_count | decimal, enum, integer | Normalisation inputs |
| unit_price_normalised, normalised_unit | decimal, enum | Comparable price positioning |
| mrp_at_launch, selling_price_at_launch | decimal | Launch price point |
| price_band_at_launch, band_version | string | Band from observed distribution |
| is_sponsored_at_launch | boolean | Whether visibility was purchased from day one |
| availability_status | enum (in_stock, out_of_stock, not_listed, not_serviceable) | Four states |
| review_count_t0, rating_t0 | integer, decimal | Baseline for accumulation tracking |
| search_rank_t0, query_text | integer, string | Baseline visibility |
| pincode_coverage_t0 | integer | Initial distribution width |
| scope_version, panel_version | string | Protects comparability |
Then run a launch cohort tracker: for each launch, record the same observable measures at defined intervals after detection — 7, 14, 30, 60, 90 days. Cohort framing is what makes launches comparable to each other rather than a list of anecdotes.
The caveat, up front: these are proxies. None of them is sales. No externally observable measure converts into units. Treat everything below as evidence about visibility, distribution and engagement — which is genuinely useful — and never as a volume estimate.
With that stated, four proxy families are usable.
Rank trajectory. Search rank against relevant queries, and browse position within category nodes, over the days after launch. A listing that moves toward the first screen and holds there has visibility. Separate sponsored from organic; a rank held entirely by ad spend tells you about budget. median organic search rank by days since launch, launch cohort.
Review accumulation rate. Reviews added per day since launch, against the category's typical rate for listings of similar age. The closest thing to a velocity signal available externally, and contaminated by solicitation, incentive programmes, platform policy and seeding. Use it for relative comparison within a cohort on one platform in one period. reviews added per day, days 1-90, by launch cohort. The review-side collection is covered in our ratings and reviews data service.
Availability and coverage expansion. Two distinguishable readings. Widening pincode coverage means the brand is pushing distribution. Stock-outs in covered pincodes mean demand exceeded allocation — or that allocation was thin. Together they are the strongest distribution signal available from outside. A launch that expands coverage and repeatedly runs out behaves like a success; one holding full availability across static coverage for ninety days does not.
Assortment persistence. Whether the listing still exists at 90 and 180 days, and whether the brand added variants to the line. Persistence and line extension indicate a launch was retained. A quiet withdrawal at day 60 is its own answer.
| Proxy | What it indicates | What it does not indicate | Main contamination |
|---|---|---|---|
| Organic rank trajectory | Visibility earned | Units sold | Sponsored placement mixed in |
| Review accumulation rate | Relative engagement | Volume | Solicitation, incentives, seeding |
| Pincode coverage expansion | Distribution push | Sell-through | Platform-side assortment decisions |
| Stock-outs in covered pincodes | Demand above allocation | Demand level | Thin allocation looks identical |
| 90/180-day persistence | Retention decision | Profitability | Long-tail listings persist cheaply |
Read them together. Any one alone is weak; the combination of expanding coverage, improving organic rank, above-cohort review accumulation and persistence past 90 days is a reasonable read that a launch is working. Say it in those terms.
Four uses that justify the build:
Competitive response within the window. A competitor launching in a price band you occupy, on a platform you both sell on, is something you can respond to in days rather than at the next quarterly review — provided the feed reaches a named owner on a defined cadence.
White-space validation. If you are considering a format, pack size or price band, the feed tells you who else moved there recently and how those launches perform on the proxies above. Cheaper than a concept test and available now. The analysis layer is described in our assortment and white-space analysis service.
New-entrant monitoring. D2C brands appear on marketplaces long before they appear in any category conversation. Tracking unmatched brand strings entering your corpus is the earliest warning available. count of new brands detected per month, category, platforms.
Platform sequencing. Which platform a brand launches on first, and how long until it appears on the others, reveals channel strategy and platform relationships — and tells you where to watch first next time.
The discipline that makes all four work: route the feed to a person, with a cadence, and a decision they are expected to make. A launch feed nobody reviews is an expense. One reviewed weekly against fixed questions is the fastest competitive input a category team has.
Actowiz Solutions runs new-listing detection across Indian marketplaces and quick-commerce platforms, combining category traversal, maintained query sets and brand storefront crawling with versioned scopes, pincode panels and pass-completeness metrics. Launch records carry classification evidence and cohort tracking fields, so relists, renames and newly serviceable listings are separated from genuine launches rather than pooled. Category-specific collection for the fastest launch cycles is covered in our beauty and personal care data and fashion and apparel data services, and the broader reporting layer in digital shelf analytics and web scraping services in India.
You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!
A: Newness is a property of the difference between observations, not of any single one. A single crawl lists what exists but cannot say what is new. Detection needs a recorded baseline, repeated passes over a constant scope, a difference operation, and a lookback rule requiring absence across several prior passes before a listing is called a launch.
A: Match the candidate against your historical corpus on brand, normalised title and pack quantity — a recent high-confidence match indicates a relist. For newly serviceable listings, check whether the same listing already exists in your data for other pincodes and whether that pincode's serviceability or panel membership changed. Store the classification and the evidence behind it.
A: Only through proxies, and they must be labelled as such. Organic rank trajectory, review accumulation rate against cohort norms, pincode coverage expansion, stock-outs in covered pincodes, and persistence at 90 and 180 days together give a defensible read on visibility and distribution. None of them converts into units sold.
Our web scraping expertise is relied on by 4,000+ global enterprises including Zomato, Tata Consumer, Subway, and Expedia — helping them turn web data into growth.
Watch how businesses like yours are using Actowiz data to drive growth.
From Zomato to Expedia — see why global leaders trust us with their data.
Backed by automation, data volume, and enterprise-grade scale — we help businesses from startups to Fortune 500s extract competitive insights across the USA, UK, UAE, and beyond.
We partner with agencies, system integrators, and technology platforms to deliver end-to-end solutions across the retail and digital shelf ecosystem.
Discover how new-SKU detection helps track D2C brand launches on marketplaces. Monitor product listings, launch trends, pricing, assortment changes, and competitor activity.
Explore Restaurant & Menu Data from RestaurantGuru UK to analyze restaurant listings, menus, pricing, ratings, and dining trends.
Compare Blinkit, Zepto, and Instamart across 10 Indian cities. Track product prices, stock availability, discounts, and quick commerce market trends.
Whether you're a startup or a Fortune 500 — we have the right plan for your data needs.