Airbnb Mobile Web Outpacing the App: Diagnose the Causes and Design In-Product Fixes

You own the product for Airbnb's native mobile app (iOS and Android). A data point shows that more people reach Airbnb through the mobile website than through the app. Explain why that might be happening, then describe what you would change inside the product to shift the balance. Where a screen helps make your point, sketch a low-fidelity mockup; a rough wireframe drawn in text is fine. ### Clarifying Questions - Does the data point count unique users only, or does it also show which surface produces more searches, bookings and repeat bookings? - Does the gap look the same for guests and hosts, for iOS and Android, and across countries? - What does Airbnb gain when a phone visitor moves to the app: higher booking conversion, push notifications, more repeat trips, or something else? - Is the goal to raise the app's share of all phone users, or to move high-intent and repeat travelers into the app while the mobile site keeps serving first-time visitors? ### Part 1 — Explain the gap Lay out the plausible reasons more people use Airbnb in a phone browser than in the app. Separate causes that follow naturally from how people shop for travel from causes that point to a fixable product problem, and say what data you would pull to tell them apart. ```hint Where visits begin Think about how a first visit to a listing usually starts, and how many times a year a typical guest actually books a stay. ``` #### What This Part Should Cover - Causes grouped into natural shopping behavior, fixable product or technical issues, and measurement artifacts. - Whether the gap is a problem at all, judged by bookings and repeat use rather than raw user counts. - A segmentation plan that confirms or rules out each cause. ### Part 2 — Shift users toward the app Propose in-product changes that move the right users from the mobile site into the app, prioritize them, and sketch the key screens as low-fidelity mockups. Explain how you would measure whether the changes worked without hurting overall bookings. ```hint Follow one trip Walk through a guest's journey from the first search to the day they check in. At which steps does the app offer something a browser tab cannot? ``` #### What This Part Should Cover - Changes on the mobile site, in the handoff into the app, and inside the app itself. - A prioritization by expected impact and effort, ending in a first release. - Mockups that show where and when the user meets each change. - Success metrics with guardrails, and how the changes would be tested. ### What a Strong Answer Covers - A deliberate choice of which mobile web users should move to the app and which should not. - Diagnosis before solutions, with each proposed change tied to a cause from Part 1. - Respect for the mobile site's role in search traffic and first-time bookings, with no tactics that trade bookings for installs. - Measurement on the combined web and app funnel, not on app downloads alone. ### Follow-up Questions - An install banner doubled app downloads, but total bookings across web and app fell slightly. What happened, and what would you do? - Shared listing links open in a messaging app's built-in browser even for people who have the Airbnb app installed. How would you fix that experience? - Would you ever make a feature available only in the app? Which one, and what is the risk?