Introduction As a user researcher, it is important to know more about our users and their preferences concerning our product. One way to do that is by conducting surveys. In order to gather user feedback from our global markets, we need to conduct a survey with a slightly different set of questions/translations for different countries, and then analyze the results and compare if there is any difference across countries concerning user needs.
While searching for “Spa and Wellness hotels in Berlin…” I land on trivago. Surprisingly the main images of the hotels exactly reflect the spa concept that I am searching for. It helped me better compare hotels on the list for finding my ideal accommodation for my vacation! This was the user experience we were looking for when we kicked off the Image Concepts project at trivago. The users with clear hotel search intent who are looking for a specific concept hotel before coming to trivago are redirected to the landing pages related to that particular topic.
tl;dr: continuously monitor your CDN and origin servers on layer 3 with tools like MTR. Layer 3 issues on external middleware can have a significant impact on layer 7 web performance. In a recent rollout of a new cloud service, we monitored the impact of this service on web performance, UX and business metrics. For all cloud regions and origin servers, we had Synthetic and Real User Monitoring for our site in place.
We have all seen the job ads that look for a “developer with at least 8 years of experience and a Computer Science degree”, a “JavaScript rockstar”, or somebody with “excellent command of technologies A, B, C, D, and E”. They are annoying in two ways. First, they are unrealistic. In today’s software developer job market, somebody fitting the above descriptions usually does not have to look for a job. Rather, the job has to find them.
Many of our data pipelines interact with external services. The availability of an external service can adversly affect the health our pipelines. This is how we handle it using AWS Step Functions
Tackling hard problems is like going on an adventure. Solving a technical challenge feels like finding a hidden treasure. Want to go treasure hunting with us?
View all current job openings
I’m happy to let you know that we are releasing trivago/babel-plugin-cloudinary to the open source community! Throughout this article I will explain to you the motivation behind this project and how it works in detail. At trivago, we use images to a large degree to enable our users to get a visual impression of the accommodations that they’re interested in. We all want to see beautiful and good quality pictures so we can have a better feeling about the place where we are going to.
Our data scientists and engineers love the challenges that their work presents to them on a daily basis and thrive in our agile environment where they can share their knowledge, learn from others, and work together to solve any problems that arise. We are always looking for ways to share the unique problem settings we encounter and to inspire a productive exchange on algorithm development and evaluation. That is why we have partnered with researchers from TU Wien, Politecnico di Milano, and Karlsruhe Institute of Technology to launch the RecSys Challenge 2019, the annual data science challenge of the ACM Recommender Systems conference.
When faced with the challenge to store, retrieve and process small or large amounts of data, structured query languages are typically not far away. These languages serve as a nice abstraction between the goal that is to be achieved and how it is actually done. The list of successful applications of this extra layer is long. MySQL users could switch from MyISAM to InnoDB or use new algorithms like Multi-Range-Read without a change to their application.
Hello from trivago’s performance & monitoring team. One important part of our job is to ship more than a terabyte of logs and system metrics per day, from various data sources into elasticsearch, several time series databases and other data sinks. We do so by reading most of the data from multiple Kafka clusters and processing them with nearly 100 Logstashes. Our clusters currently consists of ~30 machines running Debian 7 with bare-metal installations of the aforementioned services.