Krowd Personalization
Krowd's first personalized recommendation product, then the transaction intelligence behind its bank partnerships.
At Krowd I built the company's first end-to-end personalized restaurant recommendation product for London, from crawling 20K restaurants and 100K reviews to topic-modelled restaurant vectors, a preference-ranking engine, a FastAPI backend and React frontend on AWS. The same personalization principles later extended into next-purchase prediction and personalized offers over bank transaction data.
- Role
- SDE-1
- Timeline
- Jun 2019 — Apr 2021
- Company
- Krowd R&D India Pvt Ltd
- Cloud
- AWS
20K+
Restaurants
Collected and structured for London
100K+
Reviews processed
Through the NLP pipeline
180
Topic dimensions
Restaurant representation via MALLET
79%
Prediction accuracy
Next-transaction behaviour
~10%
AOV uplift
From personalized offers
4
Financial partners
DIB, Barclays, HSBC, Amex
01The problem
Generic restaurant search doesn't know what you care about.
Two people searching for Italian food in London want different things: one prioritises food quality, ambience and a premium experience, the other wants value for money, casual dining and good service. Cuisine and price filters cannot tell them apart, and restaurant metadata says nothing about how a place actually feels.
Krowd needed a tangible, demonstrable personalization product: something that understood restaurants from the language customers used about them, modelled what an individual cared about, and ranked places accordingly, with location and feedback in the loop.
Good personalization is not just a ranking model. It is a continuously evolving system combining data, context, behavioural signals, feedback and product delivery.
02My role
Every layer, explicitly.
No hand-waving about “contributed to”. These are the parts I designed, built and operated.
- Data collection
- Python and Scrapy crawling pipelines for ~20K restaurants and ~100K reviews.
- NLP pipeline
- Cleaning, normalisation, tokenisation, stop-words, phrase detection, bigrams, review aggregation and restaurant-level features.
- Recommendation modelling
- MALLET topic modelling to a 180-dimensional restaurant representation, preference profiles and ranking.
- Location & feedback
- Location-aware ranking and a feedback loop that updates each user's preference profile.
- Backend
- Recommendation and data services on Python, FastAPI and MongoDB.
- Frontend
- React application used to explore and demonstrate recommendations.
- Deployment
- Application deployed and operated on AWS.
- Transaction intelligence
- Next-purchase prediction with lag-based behavioural features and personalized offer matching.
03What it does
Acquire data, understand reviews, model people, rank, learn.
- 01Crawlrestaurants & reviews
- 02PreprocessNLP & bigrams
- 03Topic model180-dim vectors
- 04Profileuser preferences
- 05Rankwith location
- 06Learnfrom feedback
Restaurant & review crawling
Python and Scrapy pipelines that collected ~20,000 London restaurants and ~100,000 customer reviews to build Krowd's own restaurant intelligence dataset.
- Scrapy
- 20K restaurants
- 100K reviews
NLP preprocessing
Text cleaning and normalisation, tokenisation, stop-word processing, phrase detection, bigram generation, review aggregation and restaurant-level feature preparation.
Topic modelling
Reviews → preprocessing → bigrams → MALLET topic modelling → a 180-dimensional vector per restaurant capturing food quality, service, ambience, value, location, variety, style and occasion.
Personalization engine
User preferences represented in the same feature space, so restaurants are ranked by alignment with what that individual cares about.
Location-aware ranking
User preferences + restaurant characteristics + current location → ranked recommendations that are both relevant and practical.
Feedback loop
Recommend → observe feedback → update preferences → re-rank. The product learns each user's dining preferences over time.
- recommend
- feedback
- update
- re-rank
Full-stack demo product
FastAPI and MongoDB backend, React frontend, deployed on AWS. Used by the co-founder in sales, investor and partnership conversations as Krowd's first externally demonstrable personalization product.
Next-purchase prediction
Lag-based behavioural features over transaction sequences: recency, recurring patterns, category frequency, time since last purchase. ~79% accuracy for the evaluated use case.
Personalized offers
Transaction history → customer features → next-purchase prediction → offer matching → provider application. About 10% uplift in average order value.
04Architecture
From crawled reviews to a ranked list, served as a product.
A React application talks to FastAPI recommendation and data services. Behind them sit the Scrapy crawlers, the MALLET topic models that produce restaurant vectors, MongoDB for restaurant and application data, and, later, transaction datasets from financial partners.
Client
React recommendation app
Explore and demonstrate personalized, location-aware recommendations
API
FastAPI recommendation & data services
- Restaurant representations (180-dim)
- User preference profiles
- Preference × location ranking
- Feedback ingestion & profile updates
- Restaurant & review data APIs
- Next-purchase prediction service
- Offer matching
- Partner application delivery
Scrapy crawlers
20K restaurants · 100K reviews
MALLET
topic models → restaurant vectors
MongoDB
restaurant & application data
AWS
application deployment
Transaction data
bank & publisher partners
- Python
- Scrapy
- MALLET
- Topic modelling
- Feature engineering
- FastAPI
- MongoDB
- React
- AWS
05Skills used
Everything the build touched, by layer.
ML & NLP
- Topic modelling (MALLET)
- Recommendation systems
- Personalization
- Feature engineering
- Lag features
- Text preprocessing
Data engineering
- Scrapy
- Web crawling
- Review processing
- Bigrams
- Dataset construction
Backend
- Python
- FastAPI
- MongoDB
- REST APIs
Frontend
- React
- Recommendation UX
- Demo workflows
Infrastructure
- AWS
- Deployment
- Data pipelines
Applied ML
- Restaurant recommendations
- Location-aware ranking
- User preference modelling
- Feedback loops
- Next-purchase prediction
- Offer matching
06Hard problems
Where the engineering actually lived.
- 01
Turning 100K reviews into something a model can use
Raw review text needed cleaning, normalisation, tokenisation, stop-word handling, phrase detection and bigrams before aggregation to restaurant level. Getting this pipeline right mattered more to the final quality than any single modelling choice.
- 02
Finding a restaurant representation that actually discriminates
Repeated experiments across preprocessing strategies, topic counts and configurations landed on 180 topics: rich enough to capture ambience, value, service and occasion, stable enough to compare restaurants meaningfully.
- 03
Personal and practical at once
Preference alignment alone surfaces great places across the whole city. Folding current location into the ranking kept results relevant to the person and usable in the moment.
- 04
Learning from feedback without retraining
Feedback on suggestions updates the user's preference profile directly, so the next ranking adapts immediately. Personalization became a loop rather than a one-time query.
- 05
Predicting the next purchase from sequences
Transaction data from bank and publisher partners only became useful once modelled as behaviour over time. Lag-based features over purchase history reached ~79% accuracy and drove offer matching that lifted AOV by about 10%.
07Engineering decisions
Why it is built this way.
Why model restaurants from reviews instead of their metadata?
Cuisine, price band and category describe a listing, not an experience. The aspects people repeatedly discuss in reviews, such as service, ambience, value and occasion, are what actually drive a choice. Learning restaurant representations from that language let the engine compare places on the dimensions users care about.
Why MALLET topic modelling, and why 180 dimensions?
Topic modelling turns a pile of free-text reviews into a stable vector per restaurant without hand-labelling. MALLET gave fast, configurable LDA to iterate on. The 180-topic configuration came out of repeated experiments with preprocessing, topic counts and model settings; it was the point where the dimensions were specific enough to separate restaurants yet still interpretable.
Why put users in the same feature space as restaurants?
Representing a user's preferences against the same 180 dimensions turns personalization into a ranking problem: score each restaurant by how closely its learned characteristics align with the profile. It also made the feedback loop simple, since a reaction to a recommendation is just an update to that profile.
Why add location as a ranking signal rather than a filter?
A hard radius filter throws away a great match that is slightly further away. Combining preference alignment with proximity in the ranking kept recommendations personally relevant and practically useful at the same time.
Why FastAPI and MongoDB for the product?
The modelling was in Python, so FastAPI kept the recommendation services in the same language with typed, fast endpoints for the React frontend. MongoDB fit the restaurant and application documents, which varied in shape and changed as crawling added fields.
Why lag features for next-purchase prediction?
Treating transactions independently loses the signal. Lag-based features over the sequence, such as time since last purchase, category frequency and recent patterns, capture behaviour rather than isolated events. That is what let the model reach roughly 79% accuracy on next-transaction behaviour and feed an offer-matching step that moved AOV by about 10%.
08What I'd tell another builder
Represent the experience, not the listing.
The language customers use carries more signal about a restaurant than its category ever will.
Personalization is a loop.
Recommend, observe, update, re-rank. A system that cannot learn from its own suggestions stops being personal quickly.
Ship the model as a product.
The demo app, not the notebook, is what carried Krowd's technology into sales, investor and partnership conversations.
09Ownership
Crawling to NLP to modelling to APIs to frontend to deployment: the complete problem, end to end.
- Scrapy data collection
- NLP preprocessing
- MALLET topic modelling
- Preference ranking
- Location-aware ranking
- Feedback loop
- FastAPI backend
- React frontend
- AWS deployment
- Next-purchase prediction
- Personalized offers
Contribution
- Web crawling
- NLP preprocessing
- Topic modelling
- Recommendation engine
- Location-aware ranking
- Feedback personalization
- FastAPI backend
- React frontend
- AWS deployment
- Next-purchase prediction
Built at Krowd
Want this kind of ownership on your team?