Flight Price Alert

How we decreased user exit rate and increased conversion rate with Price Alert feature

Oct 21, 2022

Summary

Alibaba is the leading Travel and Hospitality company in Iran with 4M+ MAU, and the Flight vertical is the company's flagship product and cash cow. Our main objective at the time was to identify the “Why” behind the high exit rate on our search page and find solutions to increase the conversion rate. This finally resulted in designing a price alert feature that increased product retention by 30% YoY and conversion by 1.03% QoQ.

Execution time	Nov 2018 - Feb 2019 (4 months)
Researchers	Hamed Astaraki, Nayyereh Afzali
CRO	Mohsen Dehghan
PM	Arezou Ghane
Designer	Pooya Kamel

Problem Statement

Back in mid-2019, Analytics revealed a 90% exit rate of our returning customers on the search page of mobile. To understand the “Why” behind exits, we conducted in-depth interviews with our current users.

At that time, the main objective of the product was to increase the product's market share and to find new USPs. So converting these returning users was hot for us.

Assumptions

Initially, we developed some hypotheses:

• Due to users' shopping habits, users check the price on their mobile and make the purchase on their desktop
• Users do not trust mobile shopping
• Users check prices on mobile but purchase from other sites
• The search process is difficult

And we came up with a basic plan:

---

Research

Research Goals

1. Identify user personas
2. Identify existing problems on the Search page
3. Survey users to find features to attract new users and convert returning ones

Research plan

We started with gathering and reviewing all of the existing internal reports. we planned a research plan together with my researcher colleague.

Segmentation

Before recruiting users for interviews we first needed to sample users and to do it optimally we divided users into 5 categories based on their purchasing behavior in a quarter period:

1. Recent Buyer: Registered and purchased for the first time within the last 10 days
2. Normal Buyer: Purchased between 2-4 times within a quarter
3. Top Buyer: Purchased more than 10 times in the last quarter
4. Most Expensive Buyer: Purchase record with the highest basket value in the past quarter
5. Churned: Normal users in the past that haven't purchased in the last 6 months

Users Sampling

To reach the qualitative confidence level we decided to interview at least 5 people for each segment (3 mobile and 2 desktop users) and continue if we didn’t reach saturation. We finally sampled 100 users from the BI dataset for each segment to call and invite for an interview.

Discussion guide

We prepared a discussion guide with open and semi-structured questions and refined it with the team. We wanted to find out who is behind the purchase (main decision maker), what is the context of the user (circumstances), and how does the purchase happen (process)?

In-depth interview

We started calling and recruiting participants for the interview and setting appointments with them. We used Google Sheets for keeping the logs for the whole process.

We recorded the interviews for all participants for further implementation. After successfully interviewing 20 participants in 5 segments we reached enough saturation.

---

Synthesis

Qualitative Analysis

We started coding the implemented discussions to find patterns. After the qualitative analysis was done, we defined 9 micro-personas which merged into 4 main personas.

Persona Definition

Findings (TL;DR)

We gained new insights into travelers planning behavior:

Reasons behind purchasing flight tickets:

Most asked features:

Problem Restatement

After synthesizing the research findings we found out that:

Our price-sensitive users often visit the search page only to check the prices.

We also found out that even though they’re not champion users (with high Order Value or Basket Size) and not even high frequent buyers but they still make up the large volume of our returning users and thus one of the main reasons for the high exit rate (and low micro CR).

So we asked ourselves:

How might we make it effortless for these users to check price/availability?

After ideations workshops and using research findings we came upon two features with two different JTBDs:

1. Price view feature in date-picker so that users could see the cheapest prices of any day in a calendar before the search
2. Price alert feature so that users can get notified of price drops on a specific day they choose. (aiming for price-sensitive users)

---

Design

Iteration 1

The core value of the Alert feature was to give users the ability to set an alert for that specific route and date on the search page so that they get notified when a price drop happens in a certain amount of time without the need to come back to the search page.

Based on user story requirements, I started designing the Logic flow, and after finalizing it with the Tech team, I started ideating on the possible design solutions.

Ideations for Price Alert touchpoint in PLP:

After a Design Critiques session, I added some touch to the final design by coding a cute micro-animation in Codepen for the success state:

For tracking the feature’s performance we implemented tracking events. We provided users with some settings to customize their alert so could we gather data to automate the process later on.

Simultaneously the Marketing team launched an ATL campaign, to help us gain more visibility to gain more market share.

Iteration 2 (Addressing low success rates)

After launching version 1, we found out that the feature wasn’t working as supposed. Because due to short supply in the domestic market, there wasn’t much “price drop” happening actually. So we decided to notify users of any price changes (drop or rise) instead of just price drops.

We ultimately removed the "Drop Amount” field and instead of getting the amount from users, we developed a scheme to calculate the optimum level of raise/drop value dynamically based on prices in that specific route and day with the aim of increasing the Success rate of alerts (the chance of a user getting notified).

Additionally, to give users more control over the relevancy of alerts, we provided new useful settings like Preferred Airline and Departure Period:

To track the feature’s performance, we defined new KPIs: Adoption, Retention, and Conversion and I mapped them out in the customer's journey.

Iteration 3 (Addressing adoption and relevancy)

After rolling out version 2 and comparing it to the first one we found that the success rate of alerts increased but the adoption rate was halved from 44% to 21% and the CTR for options was only 10%.

Either it was because of extra options or because of the removal of the drop percentage option which could motivate users to set the alert in the first version.

In addition to usage metrics, we conducted 8 usability tests and we added an “unset” feature for the user to be able to remove the alert after setting it.

Based on usage metrics to increase the Adoption rate I came up with two main ideas:

1. Merging steps into one step and minimizing the options inputs
2. Removing the settings step (risk of decreased relevance)

We decided to A/B test between these two ideas and compare the Activation and Conversion rates of each.

I also redesigned the micro-animation to make it more simple, and finally, we tested these two designs:

Final Results

After successfully testing two variants, the Control group (with settings) was the winner with more Activation rates (relevant results for users).

The Exit rate of the PLP decreased by 50% and reduced unnecessary checking. And although the purpose of this feature was not to increase the conversion rate, ultimately after Iteration 3, conversion rates increased by 1% QoQ.

With 1000 DAU and an Average number of alerts set of 3 per user, people use this feature to check for prices or even plan their flight trips based on it.

---