Bộ lọc tìm kiếm nâng cao BĐS: Thiết kế thế nào để khách tìm đúng sản phẩm nhanh hơn?

Khi một website bất động sản chỉ có vài dự án, người dùng có thể duyệt từng trang để tìm lựa chọn phù hợp. Nhưng khi inventory tăng lên hàng trăm hoặc hàng nghìn sản phẩm, cách duyệt thủ công nhanh chóng trở nên không hiệu quả.

Lúc này, bộ lọc không chỉ là một nhóm dropdown trên đầu danh sách. Nó trở thành một hệ thống giúp chuyển nhu cầu của khách hàng thành truy vấn dữ liệu:

Nhu cầu → Tiêu chí → Filter State → Query → Kết quả → Hành động.

Một bộ lọc tốt phải giải quyết đồng thời bốn vấn đề:

lọc đúng nhu cầu, lọc đúng dữ liệu, thao tác nhanh và không tạo ra một hệ thống URL SEO mất kiểm soát.

Bài viết này Bdsweb tập trung vào kiến trúc tổng thể của bộ lọc nâng cao cho một website bất động sản có nhiều dự án hoặc listing. Những filter chuyên biệt như loại hình, giá và diện tích sẽ được tách sang các bài chuyên sâu riêng.

1. Bộ lọc nâng cao khác bộ lọc cơ bản ở đâu?

Bộ lọc cơ bản thường chỉ có vài tiêu chí độc lập:

Khu vực · Loại hình · Giá.

Bộ lọc nâng cao phức tạp hơn vì các tiêu chí có thể phụ thuộc nhau, thay đổi theo loại sản phẩm và cần giữ trạng thái trong suốt hành trình duyệt.

Ví dụ:

Tỉnh/TP → Quận/Huyện → Phường/Xã

hoặc:

Căn hộ → hiện số phòng ngủ

Đất nền → hiện loại đất, mặt tiền hoặc đường vào.

Ngoài ra, một hệ thống nâng cao còn phải xử lý:

zero-result, sorting, URL state, Back button, mobile drawer, list–map sync, hiệu năng và crawl/index.

Vì vậy độ “nâng cao” không nằm ở số lượng filter, mà ở khả năng phối hợp các filter thành một trải nghiệm nhất quán.

2. Bắt đầu từ Search Intent, không bắt đầu từ danh sách field trong database

Một sai lầm phổ biến là database đang có 30 thuộc tính thì giao diện cũng đưa cả 30 thuộc tính ra bộ lọc.

Người dùng không tìm kiếm theo cách database được thiết kế.

Họ thường bắt đầu bằng những giới hạn thực tế:

Nhu cầu	Nhóm filter phù hợp
Tôi muốn sống ở đâu?	Khu vực, dự án, bán kính
Tôi mua loại BĐS nào?	Loại hình
Tôi có bao nhiêu tiền?	Giá, giá/m²
Tôi cần không gian thế nào?	Diện tích, phòng ngủ, công năng
Tôi muốn mua ở giai đoạn nào?	Mở bán, đang xây, đã bàn giao
Tôi cần kiểm tra điều gì?	Pháp lý, chủ đầu tư, trạng thái thông tin

Những tiêu chí ít được sử dụng có thể được đưa vào phần “Lọc nâng cao” thay vì chiếm vị trí ngang hàng với các filter quan trọng.

3. Taxonomy và dữ liệu chuẩn là điều kiện tiên quyết

Frontend không thể sửa một database nhập liệu thiếu nhất quán.

Nếu cùng một loại hình được lưu dưới các giá trị:

Căn hộ
Chung cư
Căn hộ chung cư
Apartment

thì filter rất dễ bỏ sót hoặc trả về kết quả sai.

Tương tự, giá và diện tích cần lưu ở dạng số phù hợp để có thể query range. Không nên chỉ lưu:

"khoảng 3 tỷ"
"65m2"
"từ 2.5 - 3 tỷ"

như chuỗi text rồi kỳ vọng bộ lọc numeric hoạt động chính xác.

Trước khi xây UI nên chuẩn hóa:

taxonomy → kiểu dữ liệu → đơn vị → trạng thái → giá trị null/unknown.

Phần quản trị này cần kết nối trực tiếp với quy trình quản lý dữ liệu website BĐS.

4. Các nhóm filter chính nên được tổ chức thành facet

Thay vì xem từng dropdown là một chức năng riêng, có thể tổ chức bộ lọc thành các facet.

Vị trí

Tỉnh/TP, quận/huyện, phường/xã, dự án hoặc khu vực con nếu dữ liệu đủ chuẩn.

Loại hình

Căn hộ, nhà phố, biệt thự, đất nền, shophouse hoặc những nhóm thật sự tồn tại trong inventory.

Giá và diện tích

Range, preset hoặc min–max tùy đặc điểm dữ liệu.

Công năng

Phòng ngủ, WC, tầng, hướng hoặc những thuộc tính liên quan từng loại sản phẩm.

Trạng thái

Sắp mở bán, đang mở bán, đang xây, đã bàn giao hoặc trạng thái inventory phù hợp với mô hình website.

Pháp lý và chủ đầu tư

Chỉ sử dụng những thuộc tính đã được chuẩn hóa và có ý nghĩa với người dùng.

Nhóm loại hình nên được triển khai sâu hơn theo taxonomy loại hình bất động sản, còn giá–diện tích nên dùng logic riêng tại module lọc giá và diện tích.

5. Filter dependency giúp giao diện chỉ hiện những tiêu chí có ý nghĩa

Không phải mọi filter đều nên xuất hiện cùng lúc.

Khi người dùng chọn:

Tỉnh Hà Nội

thì danh sách quận/huyện nên chỉ hiển thị đơn vị thuộc Hà Nội.

Khi chọn:

Căn hộ

website có thể ưu tiên số phòng ngủ.

Khi chuyển sang:

Đất nền

field phòng ngủ có thể biến mất và được thay bằng những thuộc tính phù hợp hơn.

Logic có thể hình dung:

Filter A
   ↓
Available values of Filter B
   ↓
Available values of Filter C

Điều quan trọng là dependency phải bắt nguồn từ dữ liệu, không phải chỉ ẩn/hiện field ở frontend trong khi backend vẫn trả kết quả không tương thích.

6. Không nên ép người dùng lọc theo một thứ tự duy nhất

Có người bắt đầu từ khu vực:

Hà Đông → Căn hộ → 3 tỷ.

Người khác lại bắt đầu từ ngân sách:

Dưới 3 tỷ → Căn hộ → xem khu vực nào còn phù hợp.

Do đó không nên bắt buộc mọi khách phải đi qua một funnel:

Khu vực → Loại hình → Giá → Diện tích.

Chỉ những dependency thực sự tồn tại mới cần áp thứ tự, ví dụ quận phải thuộc tỉnh hoặc phường phải thuộc quận.

Còn lại, người dùng nên có khả năng lọc theo trình tự phù hợp với cách họ suy nghĩ.

7. Desktop và mobile cần hai cách trình bày khác nhau

Trên desktop, filter có thể được chia thành ba lớp dễ scan:

Vị trí + loại hình

Giá + diện tích

Tiến độ + pháp lý + tiện ích.

Các tiêu chí ít dùng có thể được thu vào “Thêm bộ lọc”.

Trên mobile, việc hiển thị toàn bộ filter ngay trên trang thường chiếm quá nhiều không gian. Một drawer hoặc bottom sheet sẽ phù hợp hơn.

Thanh chính có thể chỉ hiển thị:

Lọc (4) · Sắp xếp

Khi mở drawer, người dùng thấy đầy đủ tiêu chí và một CTA:

Xem 128 kết quả

nếu hệ thống có khả năng tính count đủ nhanh.

Nút Xóa lọc cũng cần rõ ràng, thay vì buộc người dùng bỏ từng điều kiện.

8. Filter State phải được giữ khi người dùng xem chi tiết rồi quay lại

Một hành trình rất phổ biến là:

Lọc → mở căn A → xem → Back → mở căn B.

Nếu Back khiến website quay về danh sách mặc định, người dùng phải thiết lập lại toàn bộ điều kiện.

Do đó filter state nên được phản ánh bằng URL, history state hoặc cơ chế phù hợp với kiến trúc ứng dụng.

Ví dụ:

?district=ha-dong
&type=apartment
&price_max=3000000000
&bedrooms=2

Khi người dùng quay lại, hệ thống cần khôi phục:

filter + sorting + pagination/scroll state

ở mức phù hợp với trải nghiệm.

9. Kết quả dự kiến giúp người dùng tránh lọc tới một ngõ cụt

Nếu query đủ nhanh, mỗi nhóm filter có thể hiển thị số kết quả tương ứng.

Ví dụ:

2PN (128)
3PN (54)
Penthouse (3)

Nhờ đó khách biết lựa chọn nào có nhiều inventory trước khi áp dụng.

Tuy nhiên việc tính facet count trên một database lớn có thể tốn tài nguyên.

Không nên triển khai chỉ vì giao diện của đối thủ có. Cần đánh giá khả năng query, cache và quy mô inventory trước.

Nếu count làm filter phản hồi chậm rõ rệt, trải nghiệm không còn đáng để đánh đổi.

10. Zero-result phải giúp người dùng sửa truy vấn, không kết thúc hành trình

Kết quả bằng 0 là một trạng thái UX quan trọng.

Ví dụ người dùng chọn:

Quận A + căn hộ 3PN + dưới 2 tỷ + đã bàn giao.

Website không nên chỉ hiển thị:

“Không tìm thấy kết quả.”

Hệ thống có thể phân tích điều kiện hiện tại và đưa ra những lựa chọn rõ ràng:

Bỏ trạng thái đã bàn giao

Mở rộng giá

Xem khu vực lân cận

Xem sản phẩm tương tự

hoặc:

Nhận thông báo khi có sản phẩm phù hợp.

Nếu người dùng muốn theo dõi nhu cầu này lâu hơn, flow có thể chuyển sang Saved Search và Product Alert.

11. Sorting là lớp thứ hai sau filtering

Filter trả lời:

“Những sản phẩm nào phù hợp?”

Sorting trả lời:

“Trong tập phù hợp đó, tôi nên xem cái nào trước?”

Một số cách sắp xếp có thể gồm:

Mới cập nhật

Giá thấp → cao

Giá cao → thấp

Diện tích

hoặc một ranking “Phù hợp” nếu website có logic rõ ràng.

Nếu dùng “Phù hợp nhất”, cần biết hệ thống đang đánh giá dựa trên gì.

Không nên âm thầm đẩy listing tài trợ lên đầu rồi trình bày như kết quả phù hợp nhất nếu điều đó có thể làm sai kỳ vọng người dùng.

12. List, Map và Filter phải dùng cùng một nguồn trạng thái

Nếu website có bản đồ, khi người dùng áp filter thì map và danh sách phải hiển thị cùng một tập kết quả.

Kiến trúc có thể là:

Filter State
     ↓
Search Query
     ↓
Result Set
   ↙       ↘
List       Map

Không nên để map query riêng theo logic khác khiến người dùng nhìn thấy 30 listing trong danh sách nhưng 46 pin trên bản đồ.

Khi người dùng kéo map và chọn “Tìm trong khu vực này”, viewport chỉ nên trở thành thêm một điều kiện của cùng query.

Phần tương tác không gian có thể xem sâu hơn tại bản đồ tương tác cho website BĐS.

13. Hiệu năng của filter phải được thiết kế từ backend

Một UI đẹp không cứu được một query mất nhiều giây mới trả kết quả.

Với database lớn, cần xem lại cách lưu và truy vấn các trường thường xuyên được lọc.

Ví dụ:

location_id · property_type · transaction_type · price · area · status.

Các trường trọng yếu cần được thiết kế để truy vấn hiệu quả theo kiến trúc database cụ thể.

Ở frontend, có thể tránh gọi request cho mỗi thao tác nhỏ bằng:

Apply button

hoặc:

debounce

tùy loại filter.

Ví dụ checkbox loại hình có thể cập nhật nhanh, nhưng input giá đang gõ không nên gửi request ở từng phím nếu không cần thiết.

Caching cũng có thể hữu ích cho những query phổ biến, nhưng không nên cache cứng dữ liệu inventory thay đổi nhanh mà không có invalidation phù hợp.

14. Faceted SEO: Filter State và Landing SEO là hai khái niệm khác nhau

Một bộ lọc nâng cao có thể sinh ra rất nhiều tổ hợp:

/can-ho?district=A
/can-ho?district=A&price=2-3
/can-ho?district=A&price=2-3&bedrooms=2
...

Không nên mặc định mọi URL đều trở thành trang cần Google index.

Cần phân biệt:

Filter URL: phục vụ trạng thái tìm kiếm của người dùng.

SEO Landing: URL được tạo có chủ đích để đáp ứng một search intent thực.

Ví dụ “Căn hộ Hà Đông” có thể có nhu cầu tìm kiếm đủ rõ để phát triển thành landing riêng.

Ngược lại tổ hợp:

Căn hộ Hà Đông + 2PN + 63–71m² + hướng Đông + hồ bơi

có thể chỉ nên tồn tại như trạng thái filter.

Việc xử lý crawl, index, canonical hay noindex phải dựa trên kiến trúc URL cụ thể; không nên dùng canonical như một công thức mặc định cho mọi tổ hợp.

Chiến lược này cần phối hợp với SEO tổng thể website bất động sản.

15. Tracking phải cho biết người dùng đang tìm gì và mắc kẹt ở đâu

Analytics của bộ lọc không nên chỉ ghi “filter_clicked”.

Cần biết filter nào, giá trị gì và hành vi tiếp theo.

Một funnel có thể là:

Search/Listing View → Filter Open → Filter Apply → Result View → Detail View → Save/Compare/CTA → Lead.

KPI	Câu hỏi cần trả lời
Filter Usage Rate	Bao nhiêu người cần lọc?
Top Facets	Tiêu chí nào quan trọng nhất?
Zero-result Rate	Nhóm nhu cầu nào thường không có hàng?
Filter → Detail CTR	Kết quả sau lọc có phù hợp không?
Filter Changes	Khách có phải sửa điều kiện quá nhiều?
Filter → Lead	Nhóm nhu cầu nào đi tới conversion?

Dữ liệu filter còn có thể được đối chiếu với CRM để biết những nhu cầu được tìm nhiều có thực sự tạo lead chất lượng hay không.

Không nên tự động đẩy từng lần đổi filter vào CRM. Analytics giữ clickstream; CRM chỉ nên nhận context hữu ích khi người dùng thực sự trở thành lead.

16. Checklist nghiệm thu, lỗi thường gặp và FAQ

Một bộ lọc nâng cao có thể nghiệm thu theo checklist sau:

• [ ] Taxonomy khu vực và loại hình đã chuẩn hóa;
• [ ] Giá và diện tích được lưu dạng dữ liệu có thể query;
• [ ] Filter chính được chọn theo Search Intent;
• [ ] Filter phụ chỉ xuất hiện khi thực sự có giá trị;
• [ ] Dependency tỉnh–quận–phường hoạt động đúng;
• [ ] Filter theo loại hình thay đổi thuộc tính liên quan nếu cần;
• [ ] Người dùng có thể lọc theo nhiều thứ tự khác nhau;
• [ ] Desktop và mobile có bố cục riêng phù hợp;
• [ ] Mobile có Apply và Clear rõ ràng;
• [ ] Filter state được giữ khi quay lại;
• [ ] Zero-result có phương án nới điều kiện;
• [ ] Sorting không mâu thuẫn với filter;
• [ ] List và Map dùng chung result state;
• [ ] Query được tối ưu cho các trường sử dụng nhiều;
• [ ] URL filter có chính sách crawl/index rõ;
• [ ] Tracking được Filter → Result → Detail → Lead.

Có nên đưa càng nhiều filter càng tốt?

Không. Filter chỉ nên tồn tại nếu dữ liệu đủ chuẩn và tiêu chí thực sự giúp người dùng thu hẹp lựa chọn. Quá nhiều lựa chọn có thể tăng tải nhận thức mà không cải thiện kết quả.

Bộ lọc có nên tự chạy ngay mỗi khi người dùng thay đổi điều kiện?

Tùy loại filter và hiệu năng hệ thống. Desktop có thể cập nhật nhanh với một số lựa chọn; mobile thường phù hợp hơn với drawer và nút Apply. Input numeric nên tránh request liên tục nếu không cần thiết.

Có nên lưu filter của người dùng?

Nên giữ state trong phiên để Back không làm mất kết quả. Nếu người dùng muốn theo dõi nhu cầu trong thời gian dài, có thể cung cấp Saved Search riêng thay vì tự động lưu mọi truy vấn.

Có nên tạo landing SEO cho mọi combination filter?

Không. Chỉ nên phát triển landing cho những combination có Search Intent thực, inventory đủ và nội dung riêng có giá trị. Phần còn lại có thể chỉ phục vụ UX.

Zero-result có nên tự động bỏ bớt điều kiện?

Không nên âm thầm thay đổi truy vấn. Hệ thống có thể đề xuất “Bỏ điều kiện X” hoặc “Mở rộng giá”, nhưng người dùng nên biết và chủ động lựa chọn.

Giá và diện tích nên dùng slider hay preset?

Không có một UI tốt nhất cho mọi website. Preset nhanh và dễ dùng; min–max linh hoạt; slider trực quan nhưng cần thiết kế tốt trên mobile. Phần này nên dựa trên dữ liệu thị trường và được xử lý riêng trong module numeric filtering.

Filter có phải là tín hiệu lead intent không?

Có thể là một tín hiệu hành vi. Một phiên dùng nhiều filter, xem nhiều sản phẩm và bấm CTA có thể thể hiện intent cao hơn pageview đơn lẻ. Nhưng một lần chọn filter chưa nên được coi là lead.

Khác biệt giữa Search và Filter là gì?

Search thường bắt đầu từ từ khóa hoặc entity người dùng nhập, còn filter thu hẹp một tập dữ liệu bằng các thuộc tính có cấu trúc. Hai chức năng nên bổ trợ nhau. Có thể xem riêng tính năng tìm kiếm thông minh cho website BĐS.

Kết luận

Một bộ lọc BĐS nâng cao không được đánh giá bằng số dropdown mà website có.

Giá trị của nó nằm ở khả năng biến nhu cầu thành một tập kết quả đúng và dễ tiếp tục hành động.

Kiến trúc có thể tóm tắt:

Data → Facets → Dependencies → State → Query → Results → SEO → Measurement.

Data phải chuẩn. Facets phải phản ánh nhu cầu thật. Dependencies chỉ hiển thị những lựa chọn có nghĩa. State giữ lại hành trình tìm kiếm. Query phải đủ nhanh. Results cần xử lý cả sorting và zero-result. SEO phân biệt filter động với landing có chủ đích. Và Measurement cho biết khách đang tìm gì, không tìm thấy gì và nhóm nhu cầu nào đi tới lead.

Khi kiến trúc tổng thể này ổn định, website mới nên tối ưu sâu từng facet như lọc theo loại hình, lọc theo giá–diện tích và khám phá kết quả trên bản đồ. Như vậy mỗi module có vai trò riêng nhưng cùng dùng một hệ thống dữ liệu và Search State thống nhất.