SnapJet Mobile app

/2026/

1. Background

/Full Case study: SnapJet Mobile app: Tối ưu Drop-off Rate từ Home đến Browser/

SnapJet là app tiện ích Android giúp người dùng tải video từ hầu hết các nền tảng mạng xã hội về máy để xem offline. Hiện tại đã có hơn 500,000 lượt tải trên Google Play và đang có khoảng trung bình 17,159 DAU (Daily active users) trong tháng vừa rồi (tháng 6 năm 2026).

Vấn đề khởi phát: Activation rate ở mức báo động — hơn 90% new user không hoàn thành được target action: tải thành công video đầu tiên trong phiên sử dụng đầu.
Sau khi phân tích hành trình First open → Home → Browser → Detect video thành công, team xác định 3 điểm drop-off lớn nhất trong hành trình Activation:

#	Chặng	Current PIC
1	First open → Home	Growth team (bài toán business liên quan tới Ads)
2	Home → Browser	Product team (case study này)
3	Browser → Detect video thành công	Tech team (ưu tiên xử lý bug trước)

Product team chủ động nhận xử lý chặng Home → Browser: đây là điểm duy nhất nằm hoàn toàn trong tầm kiểm soát của team thiết kế với chi phí thấp và không phụ thuộc team khác, đo lường được ngay, vậy nên được chọn làm quick action đầu tiên.

2. Design goals

Tăng tỉ lệ user đi được từ màn Home vào Browser thêm một biên độ đủ lớn để tạo tác động có ý nghĩa cho toàn bộ hành trình Activation phía sau.

Không đánh đổi các chỉ số guardrail: doanh thu ads, uninstall rate, trải nghiệm tổng thể.
Thiết kế giải pháp low-cost, triển khai nhanh, kiểm chứng được bằng A/B test trong thời gian ngắn.

3. Analyze the problems & identify opportunities

Làm sạch dữ liệu trước khi phân tích: xác định app_version đang rollout (1.0.8, ~20% user) và chốt khoảng thời gian dữ liệu ổn định (05–06/06) trước khi dựng funnel, để tránh nhiễu từ bản build cũ.

Funnel tổng quan cho thấy 3 nút thắt:

Chặng	Drop-off rate (%)
First open → Home	75,89%
Home → Browser	36,52%
Browser → Target action	98,68%

Đánh giá khả năng can thiệp từng chặng:

Browser → Target action (drop-off cao nhất): xác nhận là lỗi kỹ thuật detect video — thuộc phạm vi Tech team, Product chờ team dev fix bug rồi mới có thể quay lại cải tiến tiếp.
First open → Home: nguyên nhân chính là mật độ ads/paywall — vấn đề business, cần đàm phán trade-off doanh thu với team Growth Marketing trước khi đụng vào.
Home → Browser: không rào cản nào ngoài chính thiết kế màn Home → cơ hội duy nhất Product team có thể chủ động xử lý ngay.

Từ đây, team đào sâu vào chặng Home → Browser và hình thành 2 giả thuyết nguyên nhân, đi từ tổng thể màn hình vào tới chi tiết cụm input:

Giả thuyết 1 — Quá tải lựa chọn (Miller's Law, Hick's Law): màn Home phơi bày đồng thời URL field, nút Paste link, icon search và khối "Popular apps" (8 app). Quá nhiều lối vào song song khiến user mất nhiều thời gian ra quyết định hơn, và "Popular apps" thực chất là lối cụt vì các app này đang lỗi detect.
Giả thuyết 2 — Cụm input thiếu phân cấp (vi phạm Nielsen #1, #4, #6): với 3 elements URL field, Paste link, Icon search nằm sát nhau nhưng không rõ trình tự thao tác; icon search gây hiểu lầm là "tìm kiếm" trong khi chức năng thật hiện tại là "đi tiếp" sau khi user input URL.

4. Design Approach

Team tiếp cận theo hướng root-cause, từ ngoài vào trong: bắt đầu từ tổng thể bố cục màn Home, sau đó thu hẹp vào chính cụm thao tác cốt lõi (input URL). Mỗi giải pháp được thiết kế bám sát 1:1 vào một giả thuyết cụ thể, kèm câu hỏi kiểm chứng riêng — để khi ra kết quả A/B test, team biết chính xác giả thuyết nào đúng, giả thuyết nào sai, thay vì chỉ có một con số tổng.

Nguyên tắc chọn giải pháp: chi phí thấp, triển khai nhanh, đo được ngay — ưu tiên gói UI gọn nhẹ để đưa vào A/B test sớm, các hướng can thiệp sâu hơn (auto-detect clipboard, khôi phục phiên cho free user...) được xếp vào phase sau.

5. Solutions

Giả thuyết	Giải pháp	Nguyên lý UX
1/ Quá tải lựa chọn	Ẩn khối "Popular apps"	Giảm cognitive load, loại bỏ lối cụt gây nhiễu
2/ Thiếu phân cấp	Gộp "Paste link" vào ngay trong ô input, hiển thị kết quả tại chỗ	Visibility of System Status, Recognition rather than Recall
2/ Thiếu phân cấp	Đổi icon search thành button chữ "Search →"	Match Between System & Real World — làm rõ hành động dẫn tới đâu

Toàn bộ gói thay đổi được đóng gói thành một Variant so sánh trực tiếp với Baseline hiện tại, roll out qua 2 phiên bản app (1.0.8 vs 1.0.9), chia traffic 50/50, chạy trong 7 ngày với sample size ~18.000 user.

Chỉ số chính: tỉ lệ chuyển đổi Home → Browser, kèm breakdown theo từng access point (URL field, Paste link, Popular apps) để kiểm chứng riêng từng giả thuyết, cộng thêm chỉ số guardrail (uninstall rate, ad revenue).

6. Results & Impact

Kết quả A/B test (10–12/06/2026, 18.000 user, traffic 50/50):

Metric	Kỳ vọng	Thực tế
Drop-off Home → Browser	Giảm ~30%	Tăng 1,8% so với Baseline

✅ Cụm UI mới hoạt động đúng như kỳ vọng ở cấp độ chi tiết: drop-off tại "Paste link" giảm 8% (từ 57% → 49%).
⚠️ Nhưng việc ẩn "Popular apps" — chiếm 28% traffic vào Browser ở Baseline — làm co hẹp tổng traffic đầu vào, kéo chỉ số tổng thể xuống thấp hơn Baseline.

Kết luận: chưa Variant nào vượt trội hơn Baseline → quyết định không roll out, revert về Baseline.

Đề xuất tiếp theo: kết hợp phần UI hiệu quả (URL field/Paste link mới) với việc giữ lại "Popular apps" của Baseline, chạy một vòng A/B test mới để vừa giữ traffic vừa tối ưu trải nghiệm thao tác.

Bài học lớn nhất từ dự án: một redesign đúng về UX chi tiết (Paste link giảm 8% drop-off) vẫn có thể khiến chỉ số tổng thể tệ hơn, nếu bỏ qua vai trò của những thành phần "không đẹp về UX" nhưng đang mang traffic thật (Popular apps). Điều này dẫn team tới 2 nguyên tắc cho các dự án sau:

Screen Thinking → System Thinking: hành vi user là kết quả của cả hệ thống điều hướng, không riêng một màn hình.
Product Logic → User Logic: thiết kế cần bám theo cách người dùng thực sự hành xử, không phải theo sơ đồ sản phẩm lý tưởng.

/Full Case study: SnapJet Mobile app: Tối ưu Drop-off Rate từ Home đến Browser/