DEV Community: John Pham

A Lazada Review Dataset Can Have 30,325 Rows—and Still Cover Only One Seller

John Pham — Thu, 08 Oct 2026 11:58:58 +0000

A review dataset can be large enough to look convincing and still be too narrow for the question you want to answer.

While auditing a Lazada Philippines review export at Easy Data, we found 30,325 unique review IDs across 152 products—but only one seller. That makes it a useful example of why coverage needs to come before a sentiment dashboard.

This article shares aggregate audit results and a reproducible check. It does not publish reviewer identities, review text, or media links.

What the export actually contains

Check	Result
Review rows	30,325
Unique review IDs	30,325
Products	152
Sellers	1
Region	PH on every row
Missing review text, including the literal value null	385
Missing creation dates	60
Five-star reviews	29,966 (98.82%)

The nonmissing review creation dates run from November 13, 2018 to June 6, 2025. Those are review dates, not a verified collection schedule.

These figures describe this supplied export. They do not describe the whole Lazada marketplace, all Philippine shoppers, or all reviews for these products.

1. Keep IDs as text and check the population

Python's built-in CSV reader preserves identifiers as strings. This avoids accidentally rounding long IDs when importing them as floating-point numbers.

Run this against a local review export with the columns shown below. The script reads the file without changing it and prints counts rather than customer text.

import csv
from collections import Counter

path = "lazada_reviews.csv"
missing = {"", "null", "none", "nan"}

def is_missing(value):
    return (value or "").strip().lower() in missing

with open(path, encoding="utf-8-sig", newline="") as source:
    reader = csv.DictReader(source)
    required = {
        "review_id", "product_id", "seller_id", "region",
        "review", "creation_time", "rating"
    }
    absent = required - set(reader.fieldnames or [])
    if absent:
        raise ValueError(f"Missing columns: {sorted(absent)}")
    rows = list(reader)

review_ids = [r["review_id"] for r in rows
              if not is_missing(r["review_id"])]
print("rows:", len(rows))
print("unique review IDs:", len(set(review_ids)))
print("missing review IDs:", len(rows) - len(review_ids))
print("repeated review ID rows:", len(review_ids) - len(set(review_ids)))
print("products:", len({r["product_id"] for r in rows
                        if not is_missing(r["product_id"])}))
print("sellers:", len({r["seller_id"] for r in rows
                       if not is_missing(r["seller_id"])}))
print("regions:", dict(Counter(r["region"] for r in rows)))
print("missing text:", sum(is_missing(r["review"]) for r in rows))
print("missing dates:", sum(is_missing(r["creation_time"]) for r in rows))
print("ratings:", dict(Counter(r["rating"] for r in rows)))

For combined exports, keep the platform and region alongside every identifier. Do not assume an ID from Shopee identifies the same entity on Lazada. Repeated review IDs should be investigated before removal: they may be repeated captures with changed fields.

2. Separate a rating from a sentiment label

In this export, 98.82% of reviews have five stars. A model that always predicts five stars would therefore achieve 98.82% accuracy on this same distribution without reading any text.

That is a baseline warning, not evidence of a useful model. For rating prediction, inspect class counts and per-class precision and recall. For text sentiment, define an annotation method; stars are only a possible proxy and can disagree with the wording.

The 385 missing-text rows may still contribute to a rating distribution. They cannot contribute text evidence to a sentiment model. Keep those two denominators explicit.

3. Treat collection limits as an open question

We also found 43 products with exactly 300 reviews. That pattern is worth investigating for a possible collection limit. It does not prove a cap by itself.

Ask how pagination, sorting, date filters, and retry behavior worked before interpreting review counts as complete product coverage. A file that ends at a particular date also does not prove that all earlier reviews were collected.

With one seller in this sample, its average rating cannot support a claim that one marketplace has happier customers than another.

4. Publish a useful summary without exporting customer details

A public demonstration can use product-level review counts, star distributions, and clearly documented date coverage. Reviewer IDs, usernames, free text, and media URLs are unnecessary for that demonstration.

Inspect free text separately before any public release, and exclude signed media URLs or links carrying authorization parameters. Removing a username column alone is not a complete privacy review.

A dataset card should explain what readers can conclude

Document the platform, country, unit of observation, product and seller coverage, review-date range, collection method when known, missing values, and permitted uses. State unknowns explicitly.

For this export, the defensible description is a Lazada Philippines review sample covering 152 products from one seller, suitable for demonstrating review-data validation. Calling it a representative Philippine ecommerce sentiment dataset would overstate the evidence.

Disclosure: I work with Easy Data, which supplies ecommerce data. If you want a public starting point for product-data analysis, our free Shopee Thailand listing sample contains product listings; it is separate from the review export discussed here.

Before You Build a Shopee Dashboard: 5 Dataset Checks

John Pham — Wed, 07 Oct 2026 20:33:23 +0000

A CSV can load without errors and still produce a misleading dashboard. Marketplace data needs a few checks before the first chart—especially when listings contain multiple variants or sales counters with unclear reporting periods.

Here is a review process you can use for a Shopee dataset or adapt to another marketplace.

Disclosure: I work with Easy Data. The linked sample is published by our team.

1. Write down what one row means

Start with a short data contract: marketplace, country, collection date, currency, row identity and coverage limits. Keep it beside your analysis.

For a concrete practice source, our free Shopee Thailand dataset includes a public worksheet and CSV download. The documented sample contains 540 diaper listings from 151 shops, recorded on January 31, 2025, with 23 fields and prices in THB. It is a historical snapshot.

That scope belongs in a chart subtitle. Otherwise, a reader may mistake a small dated sample for a current view of an entire marketplace.

2. Check identity before removing duplicates

Preserve identifiers as text. For this sample, use shopId and itemId together as the listing key.

Count missing keys first. Then inspect repeated pairs. Do not automatically keep the first record: a repeated key might represent a conflicting value, a later observation, or an export problem. Each requires a different decision.

Keep an audit log with the original row count, rows excluded, exclusion reasons and final row count. Your cleaning process should be explainable after the dashboard is finished.

3. Compare equivalent offers

A listing may combine different sizes and pack quantities. Check price_min and price_max before interpreting its displayed price.

Consider this hypothetical example, not a finding from the sample:

Offer	Price	Pack quantity	Price per unit
A	100	20	5
B	180	60	3

Offer A has the lower pack price. Offer B has the lower unit price. Neither comparison is reliable if the pack quantity belongs to a different variant. Shipping and buyer-specific discounts can change the final comparison too.

4. Keep missing values visible

A blank brand is an unknown label, not proof that a product is unbranded. A zero reference price is not a valid denominator for a discount calculation.

For every field used in a chart, count blanks and invalid values. Put missing categories in a clearly named group rather than dropping them silently. State how many rows remain when you filter to valid prices.

5. Separate listing counters from transactions

A field named sold does not by itself establish a monthly sales measure. You need a documented reporting window and definition.

In this sample, the reporting windows for sold and historySold are not documented. Treat them as source counters. Multiplying a counter by the current listing price does not establish verified revenue.

A useful first deliverable

Before a sales dashboard, make a one-page quality report containing:

The sample scope and collection date.
Counts of rows, distinct listing keys and distinct shops.
Missing-value rates for the fields you plan to use.
Price and variant checks.
Every exclusion and its reason.

This article describes a workflow; it does not claim newly computed results. The linked sample documentation explains the source-specific checks and limitations.

What marketplace field has caused the most confusion in your own analysis?