How to Build an Amazon Review Dataset for Sentiment Analysis

Building a usable Amazon review dataset requires more than pulling raw text off product pages. For sentiment analysis to produce reliable results, the underlying dataset needs a consistent schema, clean and deduplicated records, accurate sentiment labels, and a data collection process that respects platform terms and applicable regulations. For data analysts, developers, researchers, and ecommerce teams, getting this foundation right has a direct impact on model quality later in the pipeline.

This guide walks through how to structure an Amazon customer review dataset from the ground up, covering schema design, the fields worth capturing, common cleaning and deduplication issues, sentiment labeling approaches, and responsible data handling practices.

Why Dataset Structure Matters for Sentiment Analysis

A sentiment analysis dataset is only as useful as the consistency of the data feeding into it. Inconsistent field formats, duplicate entries, missing metadata, or unclear sentiment labels can all introduce noise that degrades model performance, regardless of how sophisticated the downstream analysis is.

Before collecting a single review, it helps to define the dataset's schema and intended use case. A dataset built for basic positive/negative sentiment classification has different requirements than one intended for aspect-based sentiment analysis, where sentiment is tied to specific product features rather than the review as a whole. Deciding this upfront shapes which fields are worth capturing and how much preprocessing will be needed later.

Designing the Review Dataset Schema

A well-structured Amazon reviews dataset typically includes both the review content itself and supporting metadata that provides context for analysis.

Core fields to include in the schema:

• Review ID — a unique identifier for each review, used for deduplication and tracking

• Product ID (ASIN) — links the review to a specific product

• Review title — the short headline text, if separate from the review body

• Review body — the full text content of the review

• Star rating — the numeric rating associated with the review, commonly 1 to 5

• Review date — the date the review was posted, useful for time-based analysis

• Verified purchase status — whether the review is tagged as a verified purchase

• Helpful votes — the number of users who marked the review as helpful, if available

• Reviewer identifier — an anonymized or hashed identifier, not personal account information

• Product category — the category or subcategory the product belongs to, useful for cross-category comparison

Depending on the intended use case, additional fields may be worth capturing, such as product price at the time of review, product variation (size, color), or the number of images attached to the review.

Deciding on this schema before collection begins prevents having to retroactively restructure a large dataset once inconsistencies are discovered partway through.

Building the Product Review Dataset Collection Process

Amazon review data collection should follow a structured, repeatable process rather than an ad hoc approach, particularly when working at scale across multiple products or categories.

A typical collection workflow includes:

1. Define the scope. Identify which products, categories, or ASINs the dataset will cover, and set a clear boundary on the volume of reviews needed.

2. Establish the collection method. This may involve an API-based approach, such as an Amazon Review Scraper API, which can provide structured review data without needing to parse raw HTML manually.

3. Capture the full schema at the point of collection. Retrieving all relevant fields upfront, rather than the review text alone, avoids the need for a second collection pass later.

4. Log collection metadata. Recording when each batch of reviews was collected can help with reproducibility and identifying data drift over time.

5. Store raw data separately from processed data. Keeping an unmodified copy of the original collected data makes it possible to reprocess the dataset later if cleaning or labeling methods change.

For storage, JSON Lines (.jsonl) works well for raw collection, since each review can be appended as an independent record during an ongoing collection run. For the cleaned, processed dataset, Parquet is a common choice for larger datasets, since its columnar format loads efficiently into pandas or a similar analysis library for the cleaning, labeling, and modeling steps that follow.

Structuring the collection process this way makes the resulting dataset easier to audit, reproduce, and expand over time.

Cleaning the Dataset

Raw review data typically requires cleaning before it is usable for sentiment analysis. Common cleaning steps include:

• Removing HTML artifacts and formatting characters that may be present in raw scraped or extracted text

• Normalizing whitespace and encoding issues, particularly for datasets collected across different regions or languages

• Filtering out empty or extremely short reviews that provide little usable sentiment signal, such as reviews containing only a star rating with no text

• Standardizing date formats across the dataset, especially if data has been collected over multiple sessions or from multiple sources

• Handling non-English text appropriately, either by filtering it out, translating it, or maintaining it as a separate subset depending on the project's scope

Cleaning should be applied consistently and logged, so that the transformation from raw to cleaned data remains reproducible. In practice, most of this cleaning is handled with pandas for structural work (whitespace, encoding, date parsing) and a text-processing library such as spaCy or NLTK for language-level tasks like tokenization and language detection.

Deduplication

Duplicate reviews are a common issue in review datasets, particularly when data has been collected across multiple sessions or from overlapping product listings, such as variations of the same product.

Deduplication approaches typically include:

• Exact match deduplication, removing entries with identical review IDs

• Near-duplicate detection, identifying reviews with highly similar text that may have been collected twice due to pagination overlap or repeated collection runs

• Cross-listing deduplication, since the same review can sometimes appear across multiple related ASINs for product variations

Failing to deduplicate a dataset can artificially inflate the weight of certain opinions or sentiment patterns, which can skew analysis results, particularly in smaller datasets where a handful of duplicated reviews can meaningfully shift aggregate sentiment scores.

Assigning Sentiment Labels

Sentiment labeling is the step that connects raw review text to a usable sentiment analysis dataset. There are a few common approaches, each with different trade-offs.

Rating-based labeling uses the star rating as a proxy for sentiment, commonly mapping 1 to 2 stars as negative, 3 stars as neutral, and 4 to 5 stars as positive. This approach is fast and does not require manual annotation, but it can be imprecise, since review text does not always match the star rating in tone, particularly for 3-star reviews that may contain mixed sentiment.

Manual annotation involves human reviewers labeling a subset of reviews directly based on the text content. This tends to produce more accurate labels but is time-consuming and does not scale easily to large datasets without significant resources.

Model-assisted labeling uses an existing sentiment analysis model to generate initial labels, which can then be spot-checked or refined manually. This approach balances speed and accuracy but depends heavily on the quality of the model used for initial labeling.

For an NLP review dataset intended for training new models, a combination approach, using rating-based labels for the bulk of the data with a manually annotated validation subset, is a common and practical middle ground.

Handling Class Imbalance

Amazon reviews skew heavily positive. On most product categories, 4 and 5-star reviews make up the majority of the dataset, while 1 and 2-star reviews are comparatively rare. This is arguably the single most important practical issue for anyone building a sentiment dataset from Amazon review data, since a model trained on an unbalanced dataset without any correction will tend to predict positive sentiment by default and perform poorly on negative and neutral cases, the classes that are usually the most useful to detect accurately.

A few approaches help correct for this:

• Resampling, either oversampling the minority classes (negative and neutral reviews) or undersampling the majority class (positive reviews) so the training set has a more even class distribution. Libraries such as imbalanced-learn implement common resampling techniques, including SMOTE for generating synthetic minority examples from text embeddings.

• Class weighting, where the model's loss function is adjusted to penalize misclassifying minority classes more heavily, rather than changing the underlying dataset composition. This is a common option in libraries like scikit-learn and most deep learning frameworks.

• Stratified sampling during collection, deliberately collecting a higher proportion of lower-starred reviews where the platform and use case allow it, rather than correcting for imbalance only after the fact.

Whichever approach is used, it is worth reporting the original class distribution alongside any resampling or weighting applied, since this affects how model performance metrics should be interpreted, particularly accuracy, which can look misleadingly high on an imbalanced dataset even when the model performs poorly on minority classes.

Splitting the Dataset for Training and Evaluation

Once the dataset is cleaned, labeled, and reviewed for class balance, it needs to be split into training, validation, and test sets before it is used for model development.

A common starting point is a 70/15/15 or 80/10/10 split, with the exact proportions depending on total dataset size, smaller datasets generally need a larger validation and test proportion to produce a reliable performance estimate. A few points matter more than the exact ratio:

• Stratified splitting should be used so that each split preserves the same class distribution as the full dataset, rather than risking a test set with too few examples of a minority sentiment class. Scikit-learn's train_test_split function supports this directly with a stratify parameter.

• Product-level or reviewer-level splitting is worth considering for some use cases, keeping all reviews for a given product or reviewer within a single split, so the model is not evaluated on data that is too similar to what it saw during training.

• The test set should stay untouched until final evaluation, with all tuning and experimentation done against the training and validation sets only, to keep the final performance estimate honest.

Handling Aspect-Level Sentiment

For projects that require more granular sentiment analysis, such as understanding sentiment toward specific product features rather than the review as a whole, the dataset schema needs to support aspect-level tagging.

This typically involves identifying mentions of specific product aspects within the review text, such as "battery life," "comfort," or "build quality," and associating a sentiment value with each mentioned aspect rather than a single sentiment score for the entire review.

This level of detail requires more preprocessing but can produce significantly more useful insights, particularly for product teams trying to understand which specific features are driving positive or negative sentiment.

Responsible Data Handling

Building an Amazon review dataset also requires attention to responsible data handling practices, both from a compliance and an ethical standpoint.

Key considerations include:

• Respecting platform terms of service governing data collection methods, rate limits, and permitted use of collected data

• Avoiding collection or storage of personally identifiable reviewer information beyond what is necessary, and anonymizing or hashing reviewer identifiers where included

• Being transparent about data provenance when datasets are shared, published, or used in research, including how and when the data was collected

• Respecting rate limits and access controls when using an API-based collection method, to avoid excessive load on the source platform

• Reviewing applicable data protection regulations relevant to the jurisdiction of both the data source and the intended use of the dataset

Using a structured, API-based collection approach, such as an Amazon Review Scraper API designed for this purpose, can help ensure data is collected within defined access parameters rather than through unstructured scraping methods that may be harder to monitor for compliance.

Validating the Final Dataset

Before using the dataset for analysis or model training, it is worth running a final validation pass to confirm:

• The schema is consistent across all records, with no missing required fields

• Deduplication has been applied and verified

• Sentiment labels are present and follow a consistent labeling scheme

• Date ranges and product coverage match the intended scope defined at the start of the project

• A representative sample of the cleaned data has been manually spot-checked for quality

This final review step often catches issues that were not obvious during the collection or cleaning stages, particularly edge cases in specific product categories or review formats.

Final Thoughts

A reliable Amazon review dataset depends on decisions made well before any sentiment analysis begins. Defining a clear schema, following a structured and compliant collection process, applying consistent cleaning and deduplication, and choosing an appropriate sentiment labeling approach all contribute to a dataset that produces trustworthy results.

For data analysts, developers, researchers, and ecommerce teams working with Amazon review data, treating dataset construction as its own deliberate stage, rather than a quick preprocessing step before modeling, tends to produce more accurate and reproducible sentiment analysis outcomes.

Frequently Asked Questions

What fields should an Amazon review dataset include?

At minimum, a review ID, product ID, review text, star rating, review date, and verified purchase status. Additional fields like helpful votes and product category can support more detailed analysis.

How is sentiment usually labeled in a review dataset?

Common approaches include rating-based labeling using star ratings as a proxy, manual annotation by human reviewers, or model-assisted labeling using an existing sentiment model, often combined for balance between speed and accuracy.

Why is deduplication important for a review dataset?

Duplicate reviews can artificially inflate certain sentiment patterns and skew analysis results, particularly in smaller datasets where repeated entries carry disproportionate weight.

What does responsible data handling involve when collecting review data?

It involves respecting platform terms of service, avoiding unnecessary collection of personal reviewer information, being transparent about data provenance, and respecting rate limits when using API-based collection methods.

What is aspect-based sentiment analysis?

It is a more granular approach that associates sentiment with specific product features mentioned in a review, rather than assigning a single sentiment score to the review as a whole.