Predicting Product Prices for the Amazon ML Hackathon

Data science competitions are often less about finding the most complex algorithm and more about finding the right way to look at the data. Recently, our team (Basement) participated in the Amazon ML Challenge 2025. The playing field was massive — 82,478 teams registered, all competing to solve a critical e-commerce problem: Smart Product Pricing.

It was a marathon of feature engineering and model tuning. When the dust settled, we secured a rank of 1123, placing us in the top percentile of the competition with a SMAPE score of 0.4993.

Here is the story of how we approached the problem, what we built, and what we learned along the way.

The Challenge: Reading Between the Lines

The task sounded simple on paper: Predict the price of a product based on its catalog description.

However, anyone who has worked with real-world e-commerce data knows it is rarely “clean.” The data was a heterogeneous mix of descriptions — some detailed, some sparse, and some downright messy. We didn’t have structured columns like “Weight” or “Brand” handed to us; we had to extract them from raw text.

Our goal was to build a model that could read a description like “Premium Organic Green Tea, 250g pack” and understand that “Premium” implies a higher cost, “Green Tea” sets the category, and “250g” dictates the quantity.

Our Approach: The Hybrid Strategy

We realized early on that a single technique wouldn’t cut it. Deep Learning models (like BERT) are great at understanding context but are computationally expensive and slow to train. Traditional regression models are fast but struggle with unstructured text.

We decided to meet in the middle with a Hybrid Approach. We combined the speed of LightGBM (a gradient boosting framework) with Natural Language Processing (NLP) techniques.

1. Turning Words into Numbers (TF-IDF):
First, we had to make the text readable for the machine. We used a technique called TF-IDF (Term Frequency-Inverse Document Frequency).
Think of this as a way to assign a “uniqueness score” to words. Common words like “the” or “and” get a low score, while specific descriptors like “organic,” “wireless,” or “leather” get high scores. This allowed our model to pick up on the adjectives that actually drive price differences.

2. The “IPQ” Breakthrough:
During our analysis, we noticed a pattern: longer descriptions often correlated with higher prices. But more importantly, the numbers inside the text mattered.
We engineered a feature we called IPQ (Item Pack Quantity). By extracting the first numeric value found in the description (e.g., the “500” in “500ml”), we gave the model a rough idea of the product’s size or magnitude. A 5kg bag of rice costs more than a 1kg bag, and this simple extraction helped the model “see” that difference.

3. The Brand Effect:
In retail, the brand is king. We identified that the first word of a catalog entry was usually the brand name.
We used a technique called Target Encoding. Essentially, we calculated the average price for every brand in our training set and fed that average back into the model as a feature. This allowed the model to learn that “Brand A” usually sells budget items, while “Brand B” sells luxury goods, without needing to understand the marketing history of those companies.

Results and Retrospection

Our final submission achieved a SMAPE (Symmetric Mean Absolute Percentage Error) score of 0.4993. Out of over 82,000 teams, landing at rank 1123 was a testament to the robustness of our feature engineering.

What We Did Well

• Feature Engineering over Complexity: Instead of throwing a massive neural network at the problem, we focused on extracting meaningful signals (like Brand and Quantity) from the noise.

• Hybrid Modeling: Combining text embeddings with structured numeric data gave us the best of both worlds.

What We Could Improve

• Better Embeddings: While TF-IDF is fast, it misses context. “Apple” the fruit and “Apple” the tech company look the same to TF-IDF. Using a transformer model like BERT or RoBERTa could have captured these nuances better.

• Image Data: If the dataset allowed, incorporating product images would have been a game-changer. A picture is worth a thousand words, especially in pricing.

Final Thoughts

Participating in the Amazon ML Challenge was a crash course in handling real-world ambiguity. We learned that in Data Science, creativity in feature engineering often beats raw computing power.