I’d first understand how we’re measuring revenue, identify which users are affected, and trace their booking journey. Once I locate the change, I’d test whether it explains the revenue decline before recommending a fix.
1. Clarify the product and scope
Airbnb connects guests looking for accommodation with hosts offering places to stay. For this case, I’ll focus on revenue from homestay bookings, excluding other offerings.
I’d clarify whether the decline affects particular property categories, such as apartments, farms, or tiny homes, or homestays overall. The case puts all homestay bookings in scope.
I’d also distinguish Airbnb’s revenue from the total amount guests spend on accommodation. A fall in booking value and a fall in platform revenue can have different explanations.
2. Define the metric and validate the decline
I’d ask whether the dashboard measures revenue associated with new bookings or revenue recognised under the company’s accounting rules. Booking, payment, and revenue recognition don’t necessarily happen at the same time.
For diagnosis, I’d use this simplified relationship:
Booking-related platform revenue ≈ Number of bookings × Average booking value × Effective fee rate
I’d separately account for cancellations, refunds, adjustments, and recognition timing. This helps me distinguish between fewer bookings, cheaper bookings, and lower revenue earned per booking.
Before investigating user behaviour, I’d check:
Whether the revenue definition or attribution rules changed.
Whether reporting pipelines and dashboards are working correctly.
Whether financial records support the reported decline.
Whether the comparison accounts for weekdays, holidays, and normal booking seasonality.
Whether customer support has seen a corresponding increase in complaints.
The case tells us the metric definition and reporting pipeline are unchanged. The decline began suddenly within the past 15 days, is concentrated on Android phones, and appears across regions and demographics.
I’d still ask how large the decline is. That would help determine urgency and whether the suspected issue is large enough to explain it.
3. Use the affected segment to prioritise the investigation
The Android concentration is the strongest early clue.
An economic slowdown could reduce travel demand, but I’d usually expect some effect across other platforms too. An Android-specific product change is a closer match to the pattern we’re seeing.
I’d compare revenue, booking volume, average booking value, and conversion across:
Android, iOS, and web.
Android app versions and rollout cohorts.
New and returning guests.
Property categories and booking values.
Regions and trip dates.
I’d also check whether Android users are completing bookings on another device. A shift from Android to web could lower attributed Android revenue without an equivalent loss for Airbnb overall.
The case confirms that a new Android interface was recently released. Pricing and business strategy have remained unchanged. That makes the redesign my first investigation priority.
4. Trace the booking journey
I’d map the journey as:
Open the app → Sign in → Enter destination, dates, and guests → Browse listings → Review a property → Checkout → Confirm booking
At each stage, I’d compare behaviour before and after the release, using unaffected users as a reference where possible.
Stage | What I’d investigate | Evidence from the case |
|---|---|---|
App access | Installation failures, crashes, app size, distribution issues | No reported change |
Sign-in | Login failures or added friction | No reported change |
Search and listings | Search success, listing information, filters, abandonment | Prices and discounts were removed from listing cards |
Property details | Information, availability, progression to checkout | No reported change |
Checkout and payment | Errors, payment success, booking confirmation | No reported change |
I’d also review experiment assignments, feature flags, marketing changes, and other releases that could overlap with the redesign.
The removal of prices and discounts is a meaningful discovery. Guests can no longer compare affordability directly from the results page. They may need to open several properties before finding something within budget.
My hypothesis would be:
Removing price information increased the effort and uncertainty involved in comparing properties, reducing booking conversion and revenue.
I’d keep price visibility and discount visibility distinct. Knowing whether a stay fits my budget is a basic decision need. Seeing a discount may influence perceived value, but its contribution needs separate evidence.
5. Validate the explanation
The timing and affected platform support the hypothesis, but I’d want behavioural evidence too.
I’d check whether users exposed to the redesign show:
More exits from search results.
More back-and-forth between listings and property pages.
Longer time to select a suitable property.
Lower progression to checkout and booking confirmation.
More complaints about finding or comparing prices.
A higher listing click rate would not necessarily mean improvement. Users might be opening more properties simply because prices are hidden.
I’d compare the redesigned experience with the previous version, accounting for differences in users and rollout timing. If the change is clearly harmful, I’d restore price visibility promptly and measure recovery rather than prolong exposure just to complete an experiment.
6. Assess external factors and customer behaviour
I’d still check alternative explanations, including competitor promotions, new entrants, alternative accommodation options, regulations, negative publicity, strikes, political disruption, weather, and broader service outages.
I’d also investigate whether work routines, household income, or spending priorities have changed travel demand.
In this scenario, competitors have not shown a similar decline, and no major regulatory, political, or operational disruption has been identified. However, the interviewer mentions a financial scandal involving a bank with international exposure.
I’d treat that as a possible contributing factor, not an established second root cause.
To assess it, I’d look for lower booking intent, reduced budgets, shorter stays, or increased cancellations in exposed markets. I’d also check whether comparable iOS and web users show the same pattern.
The economic event could make guests more price-sensitive, potentially increasing the harm from hiding prices. But it does not, by itself, explain why the decline is concentrated on Android.
7. Recommend a targeted response
My immediate recommendation would be to restore clear price information on Android listing cards, along with accurate discount information where applicable.
I’d verify that the displayed price basis is understandable and consistent with the selected dates, guest count, and checkout experience. Restoring a number that later changes unexpectedly would create another source of friction.
In the longer term, I’d:
Test listing designs around guests’ ability to compare suitable stays.
Use staged releases with booking-conversion and revenue checks.
Monitor the full booking journey rather than optimise listing clicks alone.
Research affordability needs if the economic hypothesis gains support.
I wouldn’t start with blanket discounts. They could reduce revenue per booking while leaving the comparison problem unresolved.
8. Measure whether the fix works
I’d track recovery in Android booking conversion and booking-related platform revenue, with recognised revenue monitored on the appropriate timeline.
Supporting metrics would include:
Search-to-booking conversion.
Search abandonment and time to choose a property.
Checkout completion.
Average booking value and effective fee rate.
Price-related support contacts.
I’d also monitor cancellations, refunds, payment failures, and cross-device booking shifts. A short-term increase in bookings would be less useful if those bookings were later cancelled.
My leading diagnosis is that the Android redesign reduced price transparency and made comparison harder. The economic event remains a secondary hypothesis. I’d restore the missing information first, then use the recovery data to understand how much of the decline it explains.

