Lưu tin bất động sản yêu thích: Thiết kế Wishlist thế nào để khách dễ quay lại?

Khách hàng bất động sản hiếm khi quyết định sau khi chỉ xem một sản phẩm.

Họ thường mở nhiều căn, đối chiếu giá, xem lại vị trí, gửi cho người thân rồi quay lại sau vài giờ hoặc vài ngày. Nếu website không có chức năng lưu lại những lựa chọn đáng quan tâm, người dùng phải tự chụp màn hình, gửi link vào Zalo, lưu bookmark trình duyệt hoặc cố nhớ lại sản phẩm đã xem.

Đó là lúc tính năng Lưu tin / Yêu thích / Wishlist tạo ra giá trị.

Nhưng nút trái tim trên card chỉ là phần nhìn thấy. Một tính năng lưu tin tốt còn phải giải quyết:

Save → Persist → Review → Compare → Return → Convert.

Người dùng lưu được ngay, danh sách không bị mất, có thể xem lại dễ dàng, nhận biết sản phẩm đã thay đổi và tiếp tục sang hành động như so sánh, chat hoặc đặt lịch.

Bài viết này Bdsweb đi sâu vào cách triển khai tính năng Wishlist cho một website bất động sản có nhiều sản phẩm và hành trình ra quyết định dài.

1. Lưu tin là micro-conversion, chưa nên coi ngay là lead

Khi người dùng bấm “Lưu”, họ đã thể hiện mức quan tâm cao hơn việc chỉ lướt qua một card. Nhưng hành động đó vẫn chưa chứng minh họ muốn được sales gọi điện.

Do đó nên xem Save là một micro-conversion.

Nó giúp website nhận biết sản phẩm nào được quan tâm và tạo điều kiện để khách quay lại. Chỉ khi người dùng tiếp tục thực hiện những hành động mạnh hơn như gửi form, nhắn Zalo hoặc đặt lịch thì website mới có cơ sở rõ hơn để chuyển sang quy trình lead.

Phân biệt này rất quan trọng để tránh biến một tính năng UX thành một hệ thống sales quá aggressive.

2. Nút “Lưu tin” phải xuất hiện đúng nơi người dùng ra quyết định

Hai vị trí quan trọng nhất là card trên trang danh sách và trang chi tiết sản phẩm.

Trên card, biểu tượng trái tim hoặc bookmark nên dễ nhìn nhưng không cạnh tranh với giá, ảnh và CTA chính. Người dùng phải có thể lưu ngay mà không cần mở trang chi tiết.

Trên trang chi tiết, nút lưu nên nằm gần khu vực các hành động như gọi điện, chat hoặc chia sẻ.

Microcopy có thể rất ngắn:

Lưu để xem lại

hoặc:

Thêm vào Yêu thích.

Điểm quan trọng là trạng thái phải rõ:

Chưa lưu → Đã lưu.

Nếu người dùng bấm nhưng không có phản hồi, họ dễ bấm lại hoặc không biết thao tác đã thành công chưa.

3. Có nên bắt đăng nhập trước khi cho lưu tin?

Trong phần lớn website BĐS có traffic công khai, bắt đăng nhập ngay lần Save đầu tiên tạo thêm ma sát không cần thiết.

Một mô hình hợp lý hơn là cho phép anonymous save trước.

Lưu ẩn danh

Website lưu ID sản phẩm trên trình duyệt bằng cơ chế phù hợp như local storage hoặc cookie.

Ưu điểm là thao tác rất nhanh: người dùng bấm một lần và sản phẩm được lưu.

Nhược điểm là dữ liệu thường chỉ tồn tại trên trình duyệt hoặc thiết bị đó. Nếu người dùng xóa dữ liệu trình duyệt, đổi máy hoặc chuyển trình duyệt, Wishlist có thể không còn.

Lưu bằng tài khoản

Khi người dùng đăng nhập, danh sách có thể được lưu trong database theo user ID.

Nhờ đó họ có thể mở lại Wishlist trên nhiều thiết bị.

Vì vậy cách triển khai thực tế thường là:

Save trước → mời đăng nhập sau nếu muốn đồng bộ lâu dài.

4. Khi người dùng đăng nhập, cần hợp nhất danh sách ẩn danh với tài khoản

Đây là chi tiết nhỏ nhưng ảnh hưởng lớn tới trải nghiệm.

Giả sử khách chưa đăng nhập và đã lưu 4 sản phẩm. Sau đó họ đăng nhập để đồng bộ. Nếu hệ thống tải Wishlist của tài khoản và làm mất 4 sản phẩm vừa lưu, trải nghiệm sẽ rất khó hiểu.

Tốt hơn là thực hiện merge:

Anonymous Favorites
        +
Account Favorites
        ↓
Merge + Deduplicate
        ↓
Saved to Account

Nếu một listing đã tồn tại trong cả hai danh sách, chỉ giữ một bản.

Sau khi đồng bộ thành công, dữ liệu tạm trên trình duyệt có thể được làm sạch theo thiết kế của hệ thống.

5. Trang Yêu thích phải là một workspace, không chỉ là danh sách link

Nếu khách đã dành thời gian chọn ra 5–10 sản phẩm, trang Wishlist nên giúp họ tiếp tục quá trình đánh giá.

Mỗi card nên hiển thị những dữ liệu đủ để nhận diện nhanh:

Ảnh → Giá → Diện tích → Khu vực → Trạng thái.

Người dùng cũng nên có thể xóa khỏi danh sách ngay tại đây.

Nếu số lượng sản phẩm đủ lớn, có thể bổ sung sắp xếp theo giá, ngày lưu hoặc ngày cập nhật.

Quan trọng hơn, trang này nên tạo đường đi tiếp:

Xem chi tiết → So sánh → Nhắn hỏi → Đặt lịch.

6. Wishlist và tính năng So sánh phục vụ hai nhu cầu khác nhau

Lưu tin có nghĩa:

“Tôi muốn giữ sản phẩm này để xem lại.”

So sánh có nghĩa:

“Tôi muốn đặt một vài sản phẩm cạnh nhau để ra quyết định.”

Không nên biến hai chức năng thành một.

Khách có thể lưu 15 sản phẩm nhưng chỉ muốn so sánh 2–3 lựa chọn cuối cùng.

Do đó một flow tự nhiên là:

Browse → Save nhiều sản phẩm → mở Wishlist → chọn vài sản phẩm → Compare.

Cách thiết kế bảng so sánh có thể xem riêng tại tính năng so sánh sản phẩm BĐS.

7. Tin đã bán, đã thuê hoặc hết hạn không nên biến mất âm thầm

Đây là một trong những vấn đề quan trọng nhất của Wishlist BĐS.

Khách có thể lưu một căn vào thứ Hai nhưng tới thứ Sáu sản phẩm đã được bán.

Nếu website xóa sản phẩm khỏi Wishlist mà không giải thích, khách có thể nghĩ tính năng lưu tin bị lỗi.

Tốt hơn là giữ một trạng thái rõ:

Đã bán · Đã cho thuê · Hết hạn · Tạm ngừng giao dịch.

Sau đó cung cấp bước tiếp theo:

Xem BĐS tương tự đang còn hàng.

Đây là nơi tính năng Wishlist có thể kết nối trực tiếp với module gợi ý bất động sản tương tự.

8. Khi giá thay đổi, Wishlist có thể giúp khách nhận ra điều đó

Một lợi ích của việc lưu sản phẩm là người dùng có một “mốc tham chiếu” để quay lại.

Nếu giá của listing thay đổi từ thời điểm Save, trang Yêu thích có thể hiển thị:

Giá đã cập nhật

hoặc nếu hệ thống lưu được lịch sử:

3,2 tỷ → 3,05 tỷ.

Tuy nhiên cần phân biệt hai việc:

Hiển thị thay đổi trong Wishlist

và:

chủ động gửi thông báo cho người dùng.

Việc khách Save một listing không mặc nhiên có nghĩa họ đồng ý nhận email hoặc tin nhắn mỗi khi giá thay đổi.

9. Notification phải là lựa chọn riêng, không tự động đi kèm Save

Nếu muốn gửi cảnh báo khi giá giảm, trạng thái thay đổi hoặc có sản phẩm tương tự mới, website nên cho người dùng chủ động bật tính năng tương ứng.

Ví dụ:

☑ Báo cho tôi khi giá thay đổi.

hoặc:

Nhận thông báo khi có căn tương tự.

Điều này làm rõ kỳ vọng và tách chức năng Wishlist khỏi marketing automation.

Với nhu cầu theo dõi nguồn hàng mới, nên chuyển sang Saved Search & Product Alert, nơi người dùng chủ động lưu tiêu chí và đăng ký nhận thông báo.

10. Chia sẻ danh sách yêu thích có giá trị đặc biệt trong BĐS

Quyết định mua nhà thường liên quan nhiều người trong gia đình.

Thay vì khách gửi từng URL riêng lẻ, website có thể cho phép chia sẻ một shortlist.

Ví dụ:

5 căn tôi đang cân nhắc → Tạo link → gửi cho vợ/chồng/người thân.

Người nhận mở link và xem đúng tập sản phẩm.

Tuy nhiên cần quyết định link này chứa dữ liệu gì.

Nếu chỉ là danh sách các listing công khai, việc chia sẻ khá đơn giản. Nếu Wishlist chứa ghi chú riêng hoặc thông tin người dùng, không nên mặc định đưa toàn bộ vào một URL công khai.

11. Ghi chú riêng có thể nâng Wishlist thành công cụ ra quyết định

Ở những website hướng tới người mua nghiêm túc, có thể cho phép khách ghi chú:

“Ban công đẹp nhưng hơi xa trường.”

“Ưu tiên xem cuối tuần.”

“Giá phù hợp nhất trong 4 căn.”

Những ghi chú này giúp người dùng nhớ tại sao mình đã lưu sản phẩm.

Tuy nhiên note là dữ liệu cá nhân của người dùng. Nếu triển khai, cần xác định rõ quyền riêng tư và không nên tự động chuyển ghi chú sang sales hoặc CRM nếu người dùng không kỳ vọng điều đó.

12. Mobile UX cần ưu tiên thao tác một chạm

Tính năng Save thường được sử dụng khi người dùng đang lướt nhanh nhiều card, đặc biệt trên điện thoại.

Vì vậy icon cần đủ lớn để chạm, tránh đặt sát các nút khác như mở ảnh hoặc menu hành động.

Sau khi lưu, có thể hiển thị toast ngắn:

Đã lưu vào Yêu thích · Xem danh sách

Nếu phù hợp, có thể cho phép Undo ngay trong toast.

Không nên mở một popup lớn chỉ để thông báo “Đã lưu thành công”, vì người dùng đang muốn tiếp tục duyệt danh sách.

Trang Favorites cũng cần dùng thumbnail phù hợp thay vì tải ảnh gốc, đặc biệt nếu một người đã lưu nhiều listing.

Nguyên tắc này nên phối hợp với thiết kế website BĐS theo mobile-first.

13. Kiến trúc dữ liệu Favorites nên đơn giản nhưng đủ để mở rộng

Ở mức cơ bản, một record lưu tin bằng tài khoản có thể chỉ cần:

favorite_id
user_id
listing_id
created_at

Nếu cần mở rộng:

folder_id
note
notification_preference
source_context

Không nên copy toàn bộ thông tin listing vào bảng Favorites.

Thông thường chỉ cần tham chiếu bằng listing_id, còn giá, trạng thái và hình ảnh được lấy từ dữ liệu sản phẩm hiện tại.

Cách này đảm bảo khi listing thay đổi, Wishlist phản ánh dữ liệu mới thay vì giữ một bản sao lỗi thời.

14. Favorite ID và quyền truy cập phải được kiểm tra ở backend

Nếu Wishlist yêu cầu đăng nhập, server phải đảm bảo user A không thể sửa hoặc xem danh sách riêng của user B bằng cách thay ID trong URL hoặc request.

Ví dụ endpoint:

DELETE /favorites/582

không nên chỉ kiểm tra rằng người gọi đã đăng nhập.

Nó còn phải kiểm tra:

favorite_id 582 có thực sự thuộc user hiện tại hay không.

Đây là nguyên tắc authorization cơ bản với dữ liệu theo tài khoản.

Tương tự, một link chia sẻ công khai nên sử dụng token chia sẻ riêng thay vì làm lộ ID hoặc đường dẫn quản trị của người dùng.

15. Không nên đẩy mọi sự kiện Save vào CRM

Save là tín hiệu hành vi hữu ích nhưng nếu một khách lưu 12 sản phẩm và CRM tạo 12 lead hoặc 12 activity cần sales xử lý, dữ liệu sẽ nhanh chóng bị nhiễu.

Có thể dùng Favorite như một tín hiệu trong analytics hoặc lead scoring.

Ví dụ:

View nhiều → Save một số sản phẩm → Compare → quay lại Wishlist → gửi form.

Chuỗi này cho thấy intent rõ hơn một lần Save riêng lẻ.

Chỉ khi người dùng đã có contact identity và đạt một điều kiện đủ mạnh, doanh nghiệp mới cân nhắc đưa context như “đã lưu 3 căn tại Hà Đông” sang CRM.

Mục tiêu là giúp sales hiểu nhu cầu, không phải sao chép toàn bộ clickstream vào hồ sơ khách hàng.

16. Tracking cần đo cả Save và hành vi sau khi Save

Nếu chỉ đo số lần bấm trái tim, doanh nghiệp chưa biết Wishlist có thực sự hữu ích hay không.

Một funnel đầy đủ hơn là:

Listing View → Save → Favorites View → Detail Revisit → Compare/Chat/Form → Lead.

KPI	Ý nghĩa
Save Rate	Sản phẩm có đủ hấp dẫn để được shortlist?
Unsave Rate	Người dùng có loại bỏ nhiều sản phẩm sau khi xem kỹ?
Favorites Return Rate	Wishlist có kéo người dùng quay lại không?
Revisit Detail Rate	Sản phẩm đã lưu có được xem lại?
Compare from Favorites	Wishlist có hỗ trợ shortlist không?
Lead after Favorite	Nhóm đã lưu có đi tiếp tới conversion không?

Các số liệu này nên được xem trong hệ thống CRO và đo lường website BĐS thay vì đánh giá Save như một KPI đứng riêng.

17. Save Rate thấp chưa chắc do nút trái tim quá nhỏ

Nếu ít người Save, nguyên nhân có thể nằm ở UX nhưng cũng có thể nằm ở chất lượng inventory.

Ví dụ người dùng lọc 2–3 tỷ nhưng website chủ yếu hiển thị căn trên 4 tỷ. Họ không Save đơn giản vì kết quả không phù hợp.

Ngược lại, nếu người dùng xem rất nhiều trang chi tiết nhưng gần như không ai biết website có Wishlist, vị trí nút có thể là vấn đề.

Do đó cần đọc Save Rate cùng:

filter usage → detail views → product relevance → mobile behavior.

Không nên A/B test màu trái tim trước khi biết vấn đề thực sự nằm ở đâu.

Những lỗi phổ biến khi triển khai tính năng Yêu thích

Lỗi đầu tiên là bắt đăng ký tài khoản ngay lần Save đầu tiên, khiến một micro-action trở thành một form đăng ký.

Lỗi thứ hai là lưu bằng local storage nhưng không giải thích rằng danh sách không đồng bộ đa thiết bị.

Lỗi thứ ba là tin đã hết hàng biến mất hoàn toàn khiến khách tưởng website làm mất dữ liệu.

Lỗi thứ tư là Save đồng nghĩa tự động đăng ký email/Zalo marketing.

Lỗi thứ năm là mỗi lần Save đều tạo một lead CRM.

Lỗi thứ sáu là Favorites chỉ là một trang danh sách, không có compare, CTA hay trạng thái cập nhật.

Và cuối cùng là hệ thống không có tracking nên doanh nghiệp biết có nút trái tim nhưng không biết nó có tạo hành vi quay lại hay conversion hay không.

Checklist nghiệm thu tính năng lưu tin BĐS

• [ ] Có nút Save trên card và trang chi tiết;
• [ ] Trạng thái chưa lưu/đã lưu rõ ràng;
• [ ] Người dùng có thể Save ẩn danh nếu mô hình phù hợp;
• [ ] Có giải pháp đồng bộ khi đăng nhập;
• [ ] Anonymous Favorites được merge với account Favorites;
• [ ] Trang Yêu thích tải nhanh và dễ xóa sản phẩm;
• [ ] Tin hết hạn/đã bán có trạng thái rõ thay vì biến mất;
• [ ] Có đường dẫn sang sản phẩm tương tự;
• [ ] Compare được tách khỏi Save nhưng có thể kết nối từ Wishlist;
• [ ] Notification chỉ bật khi người dùng lựa chọn;
• [ ] Chia sẻ Wishlist không làm lộ dữ liệu riêng;
• [ ] Backend kiểm tra ownership của dữ liệu Favorites;
• [ ] Không tạo CRM lead cho mọi sự kiện Save;
• [ ] Tracking được Save → Favorites → Revisit → Conversion;
• [ ] Mobile thao tác một chạm và không che CTA quan trọng.

Câu hỏi thường gặp

Có nên bắt đăng nhập mới cho lưu tin?

Không nhất thiết. Cho phép lưu tạm trên trình duyệt thường giảm ma sát. Tài khoản phù hợp hơn khi người dùng muốn lưu lâu dài hoặc đồng bộ trên nhiều thiết bị.

Dùng cookie hay local storage để lưu Favorites tốt hơn?

Tùy kiến trúc và nhu cầu. Cả hai đều phù hợp với lưu tạm phía trình duyệt trong những trường hợp nhất định. Quan trọng là hiểu chúng không thay thế database nếu cần đồng bộ đa thiết bị hoặc lưu lâu dài.

Người dùng lưu tin có được coi là lead không?

Không nên mặc định. Save là tín hiệu intent hoặc micro-conversion. Lead nên được xác định bằng tiêu chí riêng như gửi form, chat, gọi điện hoặc hành vi đủ điều kiện theo quy trình của doanh nghiệp.

Có nên gửi email khi tin đã lưu giảm giá?

Có thể nếu người dùng chủ động đăng ký loại thông báo đó và hệ thống có dữ liệu giá đủ tin cậy. Không nên suy diễn hành động Save thành consent nhận mọi thông báo marketing.

Tin đã bán có nên xóa khỏi Wishlist?

Thông thường nên giữ trạng thái trong một khoảng phù hợp để khách hiểu điều gì đã xảy ra, sau đó gợi ý sản phẩm tương tự. Xóa âm thầm thường tạo trải nghiệm khó hiểu.

Có nên cho khách lưu không giới hạn sản phẩm?

Có thể, nhưng nếu danh sách quá lớn cần bổ sung sắp xếp hoặc cách tổ chức. Với website chuyên sâu hơn, có thể cho người dùng tạo nhiều danh sách hoặc thư mục theo nhu cầu.

Wishlist có nên được index trên Google không?

Trang Favorites cá nhân hoặc danh sách tạo động cho từng người dùng thường không có mục tiêu SEO và không nên trở thành landing indexable. Đây chủ yếu là tính năng tài khoản/UX.

Lưu tin và Saved Search khác nhau thế nào?

Lưu tin ghi nhớ một sản phẩm cụ thể đã tồn tại. Saved Search ghi nhớ một tập điều kiện như khu vực, giá và diện tích để tìm những sản phẩm hiện tại hoặc tương lai phù hợp.

Kết luận

Tính năng lưu tin bất động sản không chỉ là một icon trái tim trên card.

Một Wishlist tốt cần kết nối được:

Save → Persist → Review → Compare → Return → Convert.

Save phải ít ma sát. Persist đảm bảo lựa chọn không mất khi người dùng cần xem lại. Review giúp theo dõi giá và trạng thái hiện tại. Compare hỗ trợ rút gọn shortlist. Return đưa người dùng quay lại đúng lựa chọn. Và Convert xảy ra khi họ chủ động chat, gửi form hoặc đặt lịch.

Điểm quan trọng nhất là không biến Save thành một lời đồng ý marketing hoặc một lead nóng. Hãy dùng nó đúng vai trò: một tín hiệu cho thấy người dùng đang xây shortlist và một công cụ giúp họ tiếp tục quá trình ra quyết định.

Khi Wishlist được kết hợp với module so sánh BĐS, gợi ý sản phẩm tương tự và Product Alert theo nhu cầu, website sẽ hỗ trợ được toàn bộ giai đoạn shortlist thay vì chỉ cố đưa người dùng vào form càng sớm càng tốt.