Many Loopon chains use a data warehouse ("DW") to report Loopon data together with data not available within Loopon. There are a few things to keep in mind and some recommendations doing so.
Loopon API
The Loopon API will allow your organization to fetch results from Loopon.
Results are provided on a hotel by hotel level and then for each evaluation. Hence if you want to fetch all results from all hotels in a chain you will first access the list of hotels your chain has access to, then go through all hotels fetching data for each evaluation.
Common pitfalls
Survey data can be updated - Since additional responses or updates can be made to a survey they do not work like credit card transactions. You MUST check that an updated post in Loopon is not turned into a duplicate on your end by a UPSERT or DELETE+INSERT based on the AnswerDocumentId. Answers will be updated commonly within the first days of a survey being collected.
Reporting dates - In Loopon the checkout-date is used for reporting. If you use any other dates, such as created or changed your results will not look like they do in Loopon.
Grouping of units
Since Loopon provides data on a hotel by hotel level you can build any types of groupings you want in your DW. If you want to use regional, brand, size or other groupings for the reports - that will work. Any aggregations of those hotels will be in the DW and is not subject to any changes made in Loopon.
Since aggregates in Loopon such as brand or region are not connected in any way to the DW, the groupings might be different.
Access to hotels
You will get access to all hotels in your chain whilst they are part of your chain. New hotels will automatically be part of the API once they are added to your organization within Loopon.
Hotels that leave your chain will automatically be removed from your access.
This access to data is not different from how the Loopon application works.
Consequences
If you update your DW on a daily basis and for the last few days only, new hotels will be added with their latest data to your DW. If the hotel was already part of Loopon prior to being part of your chain and has historical data this method will not add historical data to your DW. If a hotel leaves your chain then you will no longer get data for that hotel as per the day they have left your chain.
Reloading historical data from the Loopon API however will provide you with historical data based on your current hotels.
-
- If you reload your DW with historical data, such as from a few years ago and any hotels have left the chain. You will NOT get access to their data.
- If any hotels have joined the chain and already had historical data with Loopon prior to joining your chain. You WILL have access to that data.
One way of working to avoid loading unwanted historical data is by making sure you are not loading data from evaluationIds that have not been in use by your chain. That way you will not get data that was part of a unit prior to it joining your chain.
Access to historical data for units that have left your chain is not possible, so you will need to avoid reloading historical data for units that are no longer part of your chain.
Comparing data to Loopon
Loopon reports are pro forma. You compare trends and history as per the organization you have today including any history of units that have joined you recently.
- If your DW reports data for hotels that have left you chain, then you will need to filter those out when comparing data to Loopon.
- Loopon will display historical data for all hotels that are currently in your chain. If the DW does not load the historical data for hotels that have recently joined your chain, then this will cause differences.
- Loopon reports data on an evaluation to evaluation level and if the DW does not require users to select what evaluation they want to see data from, then they might need to switch evaluations within Loopon and "sum up the results" to get the same numbers that are in the DW.
Recognizing questions between units and evaluations
The same kind of survey question might be written a little bit different between your brands or hotels. Because of this Loopon uses SemanticIds that allows your system to recognize questions not by their text but by the type of question.
Example: The NPS question will have SemanticId: 0. Questions with the same SemanticId will be comparable no matter what hotel is the source, what evaluation or how the question text is written.
Review data
You can collect review data from the Loopon API. Review data are collected from many different sources and these sources both have different questions, scales and comment fields.
Loopon provides a normalized main score for the review and common comment field that is a manner that works well for most sources.
Reviews from connected sources such as your units having connected Loopon to Facebook, Google Reviews, Booking.com etc. will be quite trustworthy.
All other sources are collected directly from the OTA/Review through scraping their site. This method is a cat and mouse game where some sources try to stop review collection by changing their sites, providing false reviews for scrapers etc. Whilst Loopon does a good job of removing that kind of data from the application, any such false data might have already been collected by the DW. OTA/Review sites also remove reviews on their website if they include foul language or in other ways do not follow their policies.
If you are collecting review data from Loopon through the API:
- You should have means to easily reload review data from Loopon to clean out reviews that are removed or had incorrect information provided from the source.
- Review data can sometimes be delayed due to changes made on the review sites/OTAs.
We would recommend collecting review data separately from evaluation/survey data since you will likely not want to reload these sources in the same manner.