1 Introduction↩︎

Recommender systems power e-commerce, entertainment, and online travel platforms, helping users navigate thousands of options [1]. In tourism, accommodation choice directly shapes the traveler’s experience, making hotel recommendation a widely studied task [2] whose progress depends on the quality of user–item interaction data [3].

Vietnamese, however, remains data-poor for this task. Widely used recommendation datasets (MovieLens, Amazon Reviews, Yelp) target English-speaking markets [3], [4], and large hotel corpora such as HotelRec are likewise English-centric [2]. To the best of our knowledge, no public Vietnamese hotel recommendation dataset documents its collection and quality-control process. Constructing such a resource is non-trivial for three reasons [5], [6]. First, hotels are listed on multiple booking platforms under inconsistent names, so interactions cannot be merged without explicit cross-platform entity resolution. Second, web-scraped interaction data require auditable cleaning: duplication, missing fields, and cross-site inconsistencies must be measured rather than assumed. Third, a public release must remove direct identifiers yet still support reproducible benchmarking under the cold-start conditions that dominate real Vietnamese travel data.

We address this gap with ViHoRec (Figure 1), a quality-controlled Vietnamese hotel recommendation dataset and cold-start benchmark crawled from three major booking platforms (Booking.com, Traveloka, Ivivu). Our main contributions are:

1. ViHoRec dataset. We release 18,267 cleaned interactions between 6,832 users and 560 hotels, together with content metadata for 309 hotels (facilities, surroundings, vicinity, price).

2. Reproducible construction pipeline. We document crawling (API, HTML, manual collection), canonical-key entity resolution across platforms, and quantitative quality control with reported duplication, completeness, and consistency metrics.

3. Privacy-preserving public release. We remove direct identifiers, derive HMAC-SHA256 pseudonyms, and release the corpus under CC BY-NC 4.0 with an explicit discussion of platform terms of service.

4. Cold-start benchmark. We provide a public temporal leave-last-one-out split, dependency-free baselines, data-centric ablations, and cold-start-stratified evaluation that expose personalization failure modes on sparse histories.

On the public split, learned models degrade most for users with the shortest histories (BPR-MF Recall@10 drops from 0.120 for heavy users to 0.065 for the coldest bucket), confirming that ViHoRec is a realistic stress test rather than a saturated benchmark. We release all data, code, and documentation to make every reported number reproducible.

The remainder of this paper is organized as follows. Section 3 describes the dataset (full schemas in Appendix 10); Section 4 details collection and entity resolution; Section 5 reports quality control and validation (protocol in Appendix 9); Section 6 presents characterization, baselines, ablations, and cold-start analysis; Section 7 discusses anonymization and licensing; Section 8 concludes with limitations and future work.

2 Related Work and Datasets↩︎

2.1 Hotel and travel recommender systems↩︎

Hotel recommenders have been built with collaborative filtering, content-based, and domain-specific methods [1], [7], addressing two main tasks: recommendation [8], [9] and rating prediction [10]. [11] propose multi-criteria CF for travel, evaluated with MAE on TripAdvisor data. [12] fuse enhanced user- and item-based CF (FBMCCF) on the TripAdvisor MC dataset [13]. [14] cast hotel recommendation as link prediction over the customer–hotel bipartite graph, while [15] exploit location context (LAPTA) with item-based KNN. These works assume an existing interaction corpus; none targets Vietnamese.

2.2 Public recommendation datasets↩︎

Benchmark datasets have driven the field: MovieLens, Amazon Reviews, and Yelp dominate offline evaluation [3], [4], [16], and TripAdvisor supports multi-criteria hotel studies [13]. In the hotel domain, [2] release HotelRec, a 50M-review TripAdvisor corpus that established large-scale benchmarking for rating prediction and ranking. Two properties recur across these resources: large scale and English text. Crucially, well-adopted datasets document their collection and cleaning so that results are reproducible [3], [17]. Table ¿tbl:tab:datasetcmp? positions ViHoRec against representative resources along scale, language, metadata, cross-platform merging, and documented quality control.

3pt max width=

Few recommender studies target Vietnamese tourism. Existing Vietnamese hotel review releases focus on customer-experience or sentiment analysis rather than recommendation benchmarking [18], and to the best of our knowledge no public Vietnamese hotel recommendation dataset documents construction, cross-platform entity resolution [19], quantitative quality control and cold-start evaluation together.

3 Dataset Description↩︎

The ViHoRec dataset is released as CSV files encoded in UTF-8 and consists of two complementary parts: (i) interaction data for collaborative filtering and (ii) hotel content metadata for content-based recommendation. Table 1 summarizes the files and their schemas; Appendix 10 provides full field definitions and sample records.

4pt

Interaction data. Each row in interactions.csv is one review by a user for a hotel: an anonymized user identifier (user_id), a canonical hotel identifier (hotel_id), a rating score on the \([1,10]\) scale (mean \(7.56\)), a date (roughly 2011-10-15 to 2023-12-09), and a source indicating the origin platform. The three platforms contribute, respectively: Booking.com 7,597; Traveloka 6,273; Ivivu 4,404 raw reviews.

Content metadata. For 309 hotels we collect 11 attributes: name, location, overall rating, number of reviews, price, facilities, quality, distance to center, surrounding places (Around), vicinity, and booking link. The four textual attribute groups (Facilities, Around, Vicinity, Price) are used as features for content-based recommendation.

3.1 Dataset statistics↩︎

Figure 2a shows that the data covers the main tourist destinations fairly evenly; Đà Lạt has the most hotels (nearly 100), followed by Đà Nẵng, Nha Trang, Vũng Tàu, Phú Quốc, and Phan Thiết (70–80 hotels). Figure 2b shows that rating scores are concentrated mostly in the 6–10 range, reflecting an average-to-good quality baseline. Figures 3 and 4 show the distribution of the number of reviews per hotel and per user, respectively.

4 Data Collection and Construction↩︎

4.1 Data collection↩︎

We collect data from three reputable, high-traffic booking platforms in Vietnam. For sites that expose a review-listing API, we call the API to obtain data in JSON; for sites without an API, we send standard HTTP requests and extract fields from HTML using the BeautifulSoup library. Hotel content metadata (which has no API) is collected semi-manually based on the list of hotels appearing in the interaction data. Platforms were selected based on reputation and user-base size. The raw interaction data contains the fields: customer name, location, hotel name, rating, and timestamp.

4.2 Normalization and hotel entity resolution↩︎

A hotel may appear under different name spellings across websites (differing diacritics, presence/absence of prefixes such as “Khách sạn”/“Hotel”/“Khu nghỉ dưỡng”, differing word order, differing punctuation). Naïve exact-string matching would treat such variants as distinct hotels and fragment the interaction graph. We therefore apply an entity-resolution step: each name is mapped to a canonical key that is accent-free, lower-cased, punctuation-free, with domain-specific stopwords removed (“khách sạn”, “hotel”, “resort”…), and with tokens sorted to be word-order independent. Names sharing a canonical key are merged into a single hotel_id. This process (Section 5) merges 21 name variants and identifies 78 hotels appearing on more than one platform.

4.3 Preprocessing for the baseline models↩︎

From the cleaned interaction table we derive three tables: user information, hotel information, and rating history. For content-based recommendation, for each user with at least one review we aggregate the four attribute groups (Facilities, Around, Vicinity, Price) of the hotels they have reviewed; the text is normalized (removing commas, lower-casing, tokenization) and mapped to a vector space with Word2Vec, yielding four feature vectors for the user and for the hotel.

5 Quality Control and Validation↩︎

Data quality is a critical factor for any recommendation dataset. We perform a quantitative quality-control process; all metrics below are produced automatically by publicly released code to ensure reproducibility. We disclose one validity threat up front: because user identifiers derive from reviewer display names—a low-cardinality string space in which some missing names were imputed at crawl time—distinct individuals sharing an abbreviated name may be merged, so user counts are approximate. We treat this transparently rather than obscure it. Table 2 summarizes the checks.

5.1 Duplicates and completeness↩︎

We detect duplicates at two levels: (i) exact duplicates, where the full tuple (customer name, hotel name, rating, date) is identical—7 rows (0.038%), which were removed; and (ii) near-duplicates, where the same user reviews the same canonical hotel on the same day (typically due to cross-platform re-posting)—11 rows (0.060%). Regarding completeness, no empty fields remain after collection; however, we note that during crawling some missing customer names were normalized/imputed, so user identity information is only approximate (see the Limitations section).

5.2 Consistency↩︎

Ratings are coerced to numeric and checked to lie within the \([1,10]\) scale; one malformed token (8..5) was repaired and no out-of-scale value remains. The timestamp field is parsed to a date type; there are no invalid values, and the observed span is 2011-10-15 to 2023-12-09. We also check location consistency: only 1 hotel (after entity resolution) is assigned multiple distinct locations, and it is flagged for review.

5.3 Cross-platform entity resolution↩︎

The entity-resolution step (Section 4.2) reduces 581 raw hotel names to 560 canonical hotels, merging 21 name variants (3.61%) and identifying 78 hotels that appear on more than one platform. Our ablations (Section 6.4) show that this step improves downstream Recall@10 by 3.9% relative, confirming that cross-site de-duplication yields cleaner supervision.

5.4 Manual validation and inter-annotator agreement↩︎

To estimate corpus quality beyond automated checks, we draw a stratified random sample of 248 records (186 interactions balanced across Booking.com, Traveloka, and Ivivu; 62 hotel catalogue entries). Two independent annotators apply the checklist in Appendix 9; each record receives three binary criterion scores (rater_1–rater_3): rater_1 verifies field validity (rating range, parseable date, non-empty identifiers); rater_2 verifies that the record appears exactly in the released tables; rater_3 verifies semantic plausibility (no identity-collision artefacts from abbreviated reviewer names, no flagged location conflicts, and—for hotels—presence of content metadata). Labels are 1 = correct/consistent, 0 = incorrect or flagged.

On this sample, the three raters reach full agreement on 79.4% of records; the mean positive label rate is 93.2%, yielding a majority-vote accuracy of 100% (every record passes by at least two of three criteria). Disagreement concentrates on rater_3: 13.0% of interactions are flagged for identity ambiguity (reviewer names with \(\leq 3\) characters), and 43.5% of sampled hotels lack matching content metadata—a gap that motivates future metadata expansion rather than catalogue errors. Fleiss’ \(\kappa\) is not informative here because rater_1 and rater_2 are uniformly positive on the cleaned release; we therefore report percent agreement and the mean label rate, following common practice for highly skewed validation labels.

6 Baseline Benchmark and Cold-Start Analysis↩︎

The central experimental question for ViHoRec is whether the released split supports reproducible comparison and reveals realistic failure modes under cold-start sparsity. We therefore provide a public temporal leave-last-one-out split, dependency-free baselines, data-centric ablations, and cold-start-stratified metrics—following the benchmark-first evaluation style of recent Vietnamese resource papers. The split keeps users with \(\geq 4\) interactions, remaps identifiers to contiguous integers, and for each user selects the chronologically latest interaction as the test set and the rest as the training set. This yields 800 users \(\times\) 535 hotels, 9,787 training interactions and 800 test interactions, with a sparsity of 97.53%. Benchmark file schemas are listed in Appendix 10. All hyperparameters and reproduction code are released with the dataset.

6.1 Dataset characterization↩︎

ViHoRec is deliberately realistic and difficult (Table 3): the full corpus is 99.5% sparse, 69.5% of users have a single interaction (a cold-start-dominated regime), and item popularity is highly skewed—a Gini coefficient of 0.599, with the top 20% of hotels absorbing 63% of all interactions. Figure 5 visualizes this long tail and the corresponding Lorenz curve. These properties make ViHoRec a stress test for cold-start and popularity-bias-aware methods rather than a saturated benchmark.

6.2 Evaluation metrics↩︎

We use standard ranking metrics following [20]: MAP@K, NDCG@K, Precision@K, and Recall@K with \(K \in \{5, 10\}\). NDCG@K accounts for the rank of the correct item; Precision@K and Recall@K measure accuracy and coverage within the top-\(K\); MAP@K measures overall average precision.

6.3 Baseline models↩︎

We report three groups of models, ordered by benchmark priority.

(1) Public-split baselines (primary comparison). On the public split (Table ¿tbl:tab:baseline?) we evaluate: Random as a sanity floor; MostPop [21]; neighborhood ItemKNN and UserKNN with cosine similarity [22]; BPR-MF, latent-factor ranking trained with Bayesian personalized ranking [23], [24]; and Content-TFIDF, which builds TF-IDF vectors [25] over the four metadata groups Facilities/Around/Vicinity/Price and scores items by cosine similarity to a mean-pooled user profile. Stochastic models are averaged over three seeds. Content-TFIDF covers 283 of 535 benchmark hotels (52.9%) that have metadata; items without text receive zero score.

(2) Cold-start stratification (primary finding). Table 5 and Figure 6 stratify Recall@10 by user train-history length; this analysis is the main empirical insight of the benchmark.

(3) Extended models under the original protocol (reference only). We additionally report collaborative-filtering models implemented in Cornac [26]¹ and Microsoft Recommenders [27]² (Table ¿tbl:tab:CFresult?) under an earlier split; these numbers are not directly comparable to Table ¿tbl:tab:baseline?. Original algorithm papers are cited in §6.6.

5pt max width=

6.4 Data-centric ablations↩︎

We validate two construction choices and the evaluation protocol with ablations under the same UserKNN baseline on the public split (Tables ¿tbl:tab:ablation?–4). First, entity resolution merges 556 raw hotel-name variants into 535 canonical hotels and improves Recall@10 by 3.9% relative (0.1288\(\rightarrow\)​0.1338), confirming that cross-site de-duplication yields cleaner supervision. Second, the temporal and random leave-one-out protocols differ by roughly 19% relative on Recall@10, so protocol choice is not incidental; we fix the temporal split for realistic, leakage-free comparison. Third, raising the minimum-interaction threshold \(k\) trades dataset size for density (Table 4); we adopt \(k=4\) as a balance, and report the full curve so future work can select other operating points.

6.5 Cold-start-stratified evaluation↩︎

Because 69.5% of users are cold-start, a single global metric is misleading; we therefore stratify Recall@10 by user train-history length (Table 5, Figure 6). The learned model (BPR-MF) degrades most on the coldest users (0.065 at length 3 vs. at \(\geq\)​11), the non-personalized MostPop stays comparatively flat, and UserKNN is strongest in every bucket yet still drops for cold users. Content-TFIDF underperforms collaborative filtering globally (R@10 0.058 vs. for UserKNN) but remains above Random, confirming that the released metadata carries signal for future hybrid models.

6.6 Extended results under the original protocol↩︎

For reference we also report a broader set of collaborative-filtering models (Table ¿tbl:tab:CFresult?)³. We retain them to indicate the relative ordering of stronger models, and we recommend the public split of Table ¿tbl:tab:baseline? for future comparison. Table ¿tbl:tab:CFresult? reports library implementations from Microsoft Recommenders [27] and Cornac [26]; parenthetical years in method names follow library conventions and denote the reference algorithm publication year. Algorithms trace to the following papers: MostPop [21]; RBM [28]; NCF, GMF, NeuMF, and MLP [29]; LightGCN [30]; PMF [31]; NGCF [32]; IBPR [33]; BiVAECF [34]; EASE\(^R\) [35]; BPR [23]; VAECF [36]; Skmeans [37]; and memory-based UserKNN/ItemKNN with cosine or Pearson similarity [22].

max width=

The modest absolute scores confirm that ViHoRec is a sparse, challenging benchmark that reflects real Vietnamese-market data, and they establish reference points for future methods on the public split.

7 Anonymization, Ethics, and License↩︎

7.1 Anonymization↩︎

The raw data contains reviewer display names, and the user identifier was derived directly from the name. For the public release we fully remove direct identifiers: the display name never leaves the processing machine and is replaced by a pseudonym of the form \(\text{HMAC-SHA256}(\text{salt}, \text{name})[{:}12]\). The same reviewer maps to the same pseudonym across versions (enabling longitudinal linkage), but the pseudonym cannot be reversed without the secret key. The salt is kept outside the code repository (an environment variable), and the name\(\rightarrow\)pseudonym lookup table is never published. Because the name space is small, the “hash + secret salt + drop the name” approach is chosen to reduce dictionary-attack risk; end users only ever see opaque identifiers.

7.2 Platform terms of service↩︎

Booking.com, Traveloka, and Ivivu all have terms restricting automated scraping and commercial use. To maintain a defensible research-use position, we: (i) collect only publicly visible reviews and scores, no private account data; (ii) do not redistribute raw HTML or full review text, releasing only derived numeric ratings and hotel metadata; (iii) release under a non-commercial license; and (iv) support data takedown upon request. Users of the dataset must comply with the source platforms’ terms of service.

7.3 License and FAIR principles↩︎

The ViHoRec dataset is released under the Creative Commons Attribution-NonCommercial 4.0 (CC BY-NC 4.0) license; the pipeline code is released under the MIT license. The dataset is designed following the FAIR principles: released with a versioned DOI (e.g., on Zenodo), accompanied by a datasheet documenting provenance and schema, using stable identifiers and the widely supported CSV/UTF-8 format.

8 Usage Notes, Limitations, and Conclusion↩︎

8.1 Usage notes↩︎

ViHoRec is suitable for research on collaborative-filtering, content-based, and hybrid recommenders; cold-start research; and recommendation tasks under sparse-data, low-resource-language settings for the Vietnamese market. Users should adopt the accompanying public split for fair comparison, and can leverage the content metadata (Facilities, Around, Vicinity, Price) for feature-exploiting models; see Appendix 10 for file schemas.

8.2 Limitations↩︎

We state the limitations explicitly for transparency. First, the scale is still small (18,267 interactions) compared to MovieLens-100K or Amazon, and the dataset is fairly sparse (97.53% on the benchmark split). Second, because the user identifier at crawl time was derived from a name string with a small value space (and some missing names were imputed), the number of distinct users and the interactions per user are only approximate; distinct individuals sharing an abbreviated name may be merged (13.0% of manually validated interactions were flagged for this reason). Third, content metadata covers 309 hotels (52.9% of the benchmark item set), limiting content-based evaluation. Fourth, the ratings are aggregate scores, not multi-criteria.

8.3 Future work↩︎

In the future, the dataset can be extended by: collecting more data to increase scale and reduce sparsity; expanding content metadata beyond the current 309 hotels; adding new attributes (sentiment, full review text, room types, images); and strengthening entity resolution at the user level (not only for hotels).

8.4 Conclusion↩︎

We introduce ViHoRec, a quality-controlled Vietnamese hotel recommendation dataset whose central contribution is the resource together with its reproducible construction pipeline: cross-platform entity resolution, quantitative quality control, privacy-preserving anonymization, and a public cold-start benchmark. Our stratified evaluation shows that learned models fail most on users with the shortest histories, while neighborhood methods remain strongest—a pattern that saturated English corpora rarely surface. By releasing all data, code, and documentation, ViHoRec provides the first reproducible Vietnamese resource for hotel recommendation and a realistic stress test for sparse-data, low-resource methods.

Acknowledgements↩︎

We thank the user communities on the three platforms Booking.com, Traveloka, and Ivivu—the public data source that made the ViHoRec dataset possible. We thank Thuat Thien Nguyen and Minh Nhat Ta (University of Information Technology, VNU-HCM) for applying the ViHoRec manual validation guidelines (Appendix 9) to a stratified sample of the released corpus.

9 Manual validation guidelines↩︎

This appendix reproduces the annotation protocol used for the stratified manual validation sample (Section 5.4). Two independent annotators label each sampled record with 1 = correct/consistent or 0 = incorrect/inconsistent.

9.1 Interaction records↩︎

1. Rater 1 (field validity): rating in \([1, 10]\); date parseable and within 2010–2024; user_id, hotel_id, and source non-empty.

2. Rater 2 (release consistency): the tuple exists in interactions.csv with matching rating, date, and source.

3. Rater 3 (semantic plausibility): hotel name/location in the catalogue are plausible; no obvious duplicate or identity-collision artefact.

9.2 Hotel records↩︎

1. Rater 1: non-empty canonical name and location.

2. Rater 2: hotel_id unique in the release catalogue.

3. Rater 3: location is not among flagged multi-location conflicts; hotel has at least one interaction in the corpus.

Disagreements are resolved by majority vote for the accuracy estimate.

10 Dataset field reference and sample records↩︎

This appendix documents the concrete schema of each released file and provides representative records. All files are UTF-8 CSV unless noted otherwise.

10.1 interactions.csv↩︎

Each row is one user–hotel rating event.

6pt

10.2 users.csv↩︎

One row per distinct pseudonymous user; activity count only.

4pt

10.3 hotels.csv↩︎

Canonical hotel catalogue after cross-site entity resolution.

4pt

10.4 Content metadata↩︎

Rich hotel attributes for content-based recommendation; not part of the anonymised interaction release but shipped with the repository.

4pt

4pt

10.5 Benchmark split↩︎

Public leave-last-one-out split for reproducible evaluation (800 test users \(\times\) 535 items).

4pt

5pt

References↩︎