This Implementation Guide explains how Fredhopper is most effectively implemented for holiday homes and packaged holiday sites with up to 4billion prices. For very small Travel setups with less than 50million prices you can follow also the Retail Implementation Guide.
Although travel sites offer comparable few hotels (normally up to 50,000) the number of prices goes into the billions covering all possible combinations of departure date, airport, #persons, boarding type, etc. Fredhopper's unique Relational Universe technology allows to store these prices in a very efficient way.
Requirements mapping
Fredhopper provides a very hardware efficient solution for Travel sites. Building this solution requires to make certain trade-offs between available functionality and required hardware resources.
This chapter gives a complete overview of supported and unsupported features when following the Travel Implementation Guide.
Supported functionalities
This section collects key use cases that are critical for Travel sites which can all be powered by a setup following the Travel Implementation Guide.
Navigation
- Show commercially most relevant price
- Never show unavailable hotels
- Sort on price in result sets with up to 200 hotels, e.g. show cheapest offer or commercially most relevant offer
- Search in all hotel attributes, e.g. search for Sunshine in Mallorca
- Facets on hotel attributes, available dates, available durations
- Sorting on hotel attributes, e.g. show commercially most relevant hotel (if it is independent of the price/time of year)
- Time period selection, e.g. 7 days between 1-Aug and 30-Sep
Merchandising
- Show the cheapest valid price per promoted hotel
- Text, image promos
- Filter products on hotel attributes, e.g. highlight regions on country landing pages
Integration
- Scales for big multi-country Travel sites with up to 4billion prices (ca. 15,000 hotels for packaged holidays or 50,000 properties for holiday homes)
- Build index over all availability data points
- Hold all price information
Unsupported functionalities
The following Fredhopper features are only available for other domains like Retail but not for Travel setups.
Navigation
- Sort on price in result sets with more than 200 hotels, e.g. show cheapest offer or commercially most relevant offer
- Filter on price, e.g. Hotels in Spain up to 500 EUR
- Price facet/sliders
- Facets with lowest prices, e.g. Spain from 299 EUR
- Display when the shown price is valid, e.g. 399 EUR if you go 07-Aug to 14-Aug
- Display additionally information about the price, e.g. 399 EUR - Special offer price!
- Show alternatives dates if initial is not available, e.g. User queries 01-Aug to 30-Sep -> show Hotel would be available 31-Jul
- Search for offer attributes, e.g. search for 2 weeks Sunshine in Mallorca
Merchandising
- Filter hotels on price attributes, e.g. show hotels < 1000 EUR
- Sort hotels on price attributes, e.g. show hotels with commercially most relevant price in Mallorca
- Up-sells on detail pages, e.g. price <+> 25%
- Show a different time period, e.g. if user looks for winter holidays we can not show See also our new Summer offers or Our last minute offers
- Show different duration, e.g. if the user looks for 7 days we can not up-sell Our special offers for a 10 days trip
- Use select static location feature
- Use Fredhopper templates, e.g. homepage vs. summary promotions
Integration
- Incremental updates for price or availability information
- Hold more than 50,000 hotels (limitation of list attributes for prices)
Hardware sizing
This section explains which machines are required to run Fredhopper for a Travel setup.
Hardware specification
Online machines: Fredhopper requires the following specification for its Query Servers:
- 2 x Dual Core CPU, 2.4+ GHz
- 8 GB RAM
- 20 GB minimum (e.g. 72 GB SATA disk)
- 2 x Gigabit network card
- OS: Linux kernel 2.6+ (glibc 2.3.5+), Windows Server 2008 R2 x64 or Solaris 10
Off-line machines: Fredhopper requires the following specification for Data Pre-processing, Indexing, Reporting, Business Manager and Previewing:
- 2 x Dual Core CPU, 2.4+ Ghz
- 12 GB RAM
- 72 GB minimum (e.g. 72 GB SATA disk - optionally mirrored for Reporting)
- 2 x Gigabit network card
- OS: Linux kernel 2.6+ (glibc 2.3.5+), Windows Server 2008 R2 x64 or Solaris 10
Typical machines are Dell PowerEdge SC1435 or HP ProLiant DL145G3
Production environment
The number of Online machines including one machine for fail-safeness depends purely on your peak page views per month (typically January/February or July). Additionally, Fredhopper requires one Off-line machine for Data Pre-processing, Indexing, Reporting, Business Manager and Previewing.
| Peak page views per month | Required #Online machines | Required #Off-line machines |
|---|---|---|
| 0-10m | 2 | 1 |
| 10-20m | 2 | 1 |
| 20-30m | 3 | 1 |
| 30-40m | 3 | 1 |
| 40-60m | 4 | 2 |
| 60-80m | 5 | 2 |
| 80-100m | 6 | 2 |
| 100-120m | 7 | 3 |
[Assumptions: 65% of page view lead to a Fredhopper request, Busiest day has 5% of traffic of peak month, Busiest hour has 11% of traffic of peak day]
The following graphic shows a production environment with 3 live servers:
Test environment
In the test environment one Offline machine can hold all Fredhopper components.
| Required #Online machines | Required #Off-line machines |
|---|---|
| 0 | 1 |
Data integration
Fredhopper data integrations are optimized to work hand in hand with your experts. Your data experts will extract all hotel and price information without bothering how Fredhopper will store the data. Fredhopper will take care of filling its engine in the most efficient fashion with the provided data.
Input format
This section describes the two CSV files that Fredhopper requires as data input from you.
Ensure for both CSV files:
|
Hotel information
The hotels have to be provided in a CSV file called hotels.csv separated by double tabs. Each row has to contain the following columns:
| Column | Description | Allowed values | Example |
|---|---|---|---|
| hotel_id (required) | Required to link the prices | a-z, A-Z, 0-9, _ | 123456 |
| locale (required) | Language/Country combination for which the texts apply | Valid Java Locale | en_US, fr_FR, de_DE, de_CH |
| name | Name of the hotel | Sunshine Hotel | |
| country | Country where the hotel is located | Spain | |
| region | Country where the hotel is located | Costa del Sol | |
| city | Country where the hotel is located | Cadiz | |
| description | Long description explaining the hotel | This nice hotel on the sunny beaches of Cadiz ... | |
| short_description | Short description giving short overview of the hotel; typically used for lister pages | Nice hotel on the beach. | |
| image | URL to a big image of the hotel | http://www.shop.com/img/sunshine.jpg | |
| thumb_image | URL to a small image of the hotel; typically used in the lister page | http://www.shop.com/img/sunshine_small.jpg | |
| features | What the hotel has to offer | multiple values | swimming pool, family friendly, pets allow, golf course |
| specials | Commercial specials | multiple values | new, bestseller |
| star_rating | Official quality rating in stars, e.g. by tourism board | Integer numbers | 1, 2, 3, 4, 5 |
| user_rating | Rating how much users like the hotel | Float | 3.7, 3.0, 4.5 |
| user_popularity | How many users were interested in the hotel; This can be absolute Sales numbers or a relative score. | Float | Absolute: 729, 37 Relative: 8.2, 2.7 |
You can keep a column empty if you do not have data for it.
For example:
| hotel_id | locale | name | country | region | city | description | ... |
|---|---|---|---|---|---|---|---|
| 1234 | en_GB | Sunshine hotel | Spain | Costa del Sol | Cadiz | This nice hotel on the sunny beaches of Cadiz. | ... |
| 1234 | de_DE | Sunshine Hotel | Spanien | Costa del Sol | Cadiz | Diese schoene Hotel an den sonnigen Straenden von Cadiz. | ... |
| 1235 | en_GB | L'Europe hotel | Italy | Roma | Roma | Beautiful hotel in the center of Roma. | ... |
If an attribute has more than one value (e.g. features or specials), please separate them by double semicolon ;;. For such cases in multi-Locale setups also provide a key for each entry like key=multi-lingual value, e.g.:
| hotel_id | locale | ... | features | ... |
|---|---|---|---|---|
| 1234 | en_GB | ... | parking=Parking lot;;pool=Swimming pool | ... |
| 1234 | de_DE | ... | parking=Parkplatz;;pool=Schwimmb | ... |
| To provide additional custom attributes follow the [Custom Attribute Guide]. |
The hotel file has to be sorted by hotel_id, locale (in that order).
Price information
The prices have to be provided in a CSV file called prices.csv separated by double tabs. Each row has to contain a hotel ID which links it with the hotel information and the country/language combination (Locale) for which the price applies. Although you can provide different prices, Fredhopper assumes for each offer the same availability across countries/languages, e.g. if an offer is available in the UK - it also has to be available in Germany. As additional columns the duration, date (YYYY-mm-DD) and price (without currency symbol have to be provided).
For example, the follow entry specifies that the Sunshine hotel can be booked from the 2008-10-01 for 7 days for 399 GBP (in the UK) or 499 EUR (in Germany):
| hotel_id | duration | date | locale | price |
|---|---|---|---|---|
| 1234 | 7 | 2008-10-01 | en_GB | 399 |
| 1234 | 7 | 2008-10-01 | de_DE | 499 |
The price file has to be sorted by hotel ID, duration, date and locale (in that order). The price file must only contain available prices that can be booked by your website users.
Data transformations
The Fredhopper Data Manager contains standard components to process your data feeds into Fredhopper XML optimized for Travel setups.
The following transformation creates the availability universe and prepares the price attributes for the hotel universe:
The following transformation creates the hotel universe adding price attributes to each hotel:
Page integration
Fredhopper will be integrated via SOAP in your front-end. This chapter explains what your front-end has to consider due to the special Fredhopper data modeling for Travel setups.
General
The departure dates are stored as low integers because it leads to a more efficient index structure. Therefore the front-end has to calculate for each date the days since day zero (1-Jan 2008), e.g.:
| Date | Date (integer) |
|---|---|
| 1-Jan 2008 | 1 |
| 2-Jan 2008 | 2 |
| 5-Jan 2008 | 5 |
| 31-Jan 2008 | 31 |
| 1-Feb 2008 | 32 |
The duration facet may contain values that are outside of the selected period. The front-end has to remove these, e.g. for 2008-10-01 to 2008-10-10 all facet values for more than 10 days must not been rendered by the front-end.
Query syntax
The front-end has to ensure that each query to Fredhopper provides information for availability filtering (2nd universe) and for the price extraction (Attribute Type Function). This has to be added for each navigation and free text search query.
All examples use these values:
- Start date: 1
- End date: 10
- Duration: 3
| Use case | Query |
|---|---|
| No start/end date or duration selected | /price(D,D,D) |
| Only start date selected (or only end date selected) - Should be ignored for performance reasons | /price(D,D,D) |
| Duration selected; start/end date not selected - Should be ignored for performance reasons | /price(D,D,D) |
| Start date and end date selected; duration not selected (default is always 7 days) | /price(1,10,7)/dates>{1;2;3;4}/duration=7 |
| Start date, end date and duration selected | /price(1,10,3)/dates>{1;2;3;4;5;6;7;8}/duration=3 |
This means that the date selection for availability is a OR query stating all dates between start date and end date - duration + 1 (e.g. 10-3+1=8).
Configuration
Fredhopper delivers a standard configuration optimized for Travel.
Deployment
After [installing your Fredhopper release], you have to deploy additionally the Fredhopper Travel attribute type function.
Standard deployment with daily batch re-index.
Testing
Test all points in the Functionalities chapter.
Comments
0 comments
Please sign in to leave a comment.