Lọc nhanh theo khoảng giá và diện tích trên website BĐS: Thiết kế sao để tìm đúng và nhanh?

Trong hàng loạt tiêu chí tìm kiếm bất động sản, giá và diện tích thường là hai điều kiện giúp người dùng loại bỏ nhanh nhất những sản phẩm không phù hợp.

Một khách có ngân sách khoảng 3 tỷ đồng có thể linh hoạt về hướng nhà hoặc nội thất, nhưng khó dành thời gian xem một danh sách chủ yếu gồm sản phẩm 7–10 tỷ. Tương tự, người cần căn hộ cho gia đình bốn người sẽ ít quan tâm những căn có diện tích quá nhỏ dù vị trí hấp dẫn.

Vì vậy, bộ lọc giá và diện tích không nên được xem như hai dropdown bổ sung trên trang danh sách. Đây là một phần quan trọng của hành trình:

Nhu cầu → Thu hẹp lựa chọn → Xem sản phẩm phù hợp → So sánh → Liên hệ.

Bộ lọc làm tốt giúp người dùng giảm hàng trăm sản phẩm xuống một tập nhỏ có khả năng phù hợp. Bộ lọc làm sai lại nguy hiểm hơn không có bộ lọc, bởi người dùng có thể nghĩ website không có sản phẩm trong khi nguyên nhân thực tế là dữ liệu hoặc logic lọc không chính xác.

Bài viết này Bdsweb đi sâu riêng vào cách triển khai bộ lọc giá và diện tích cho website bất động sản, từ UX, dữ liệu, backend tới SEO và tracking.

Điểm khó nhất của lọc giá và diện tích không nằm ở giao diện

Nhìn từ frontend, chức năng khá đơn giản: người dùng chọn mức giá, diện tích rồi website trả về danh sách phù hợp.

Nhưng để một thao tác đơn giản đó hoạt động đúng, phía sau cần thống nhất rất nhiều vấn đề.

“Giá 3 tỷ” được lưu dưới dạng số hay chuỗi? Một dự án ghi “từ 2,8 tỷ” được lọc thế nào? “Giá thỏa thuận” có xuất hiện khi khách đặt trần 5 tỷ không? Diện tích đang nói tới diện tích đất, diện tích xây dựng hay diện tích sử dụng? Một sản phẩm có khoảng diện tích 55–72 m² sẽ được xử lý thế nào nếu người dùng lọc 60–70 m²?

Nếu những câu hỏi này chưa được giải quyết ở tầng dữ liệu, slider đẹp đến đâu cũng không làm bộ lọc chính xác hơn.

1. Trước tiên phải xác định “giá” đang có nghĩa gì

Website BĐS có thể chứa nhiều cách biểu diễn giá.

Với sản phẩm bán, người dùng thường quan tâm tổng giá. Với một số loại hình, họ lại muốn so giá trên mỗi mét vuông. Với sản phẩm cho thuê, đơn vị có thể là triệu đồng/tháng. Một dự án chưa mở bán chính thức có thể chỉ công bố “giá dự kiến từ...”.

Những khái niệm này không nên bị đưa vào cùng một field rồi xử lý bằng cách đọc chuỗi text.

Ví dụ, phía quản trị có thể hiển thị:

3,2 tỷ

nhưng dữ liệu phục vụ lọc nên có dạng số nhất quán, chẳng hạn giá trị theo VND. Frontend chịu trách nhiệm chuyển số đó thành định dạng dễ đọc.

Nhờ vậy cùng một dữ liệu có thể phục vụ filter, sort, API hoặc tính giá trên m² mà không phải phân tích lại chuỗi “3 tỷ 200 triệu”.

2. Không nên lưu “3 tỷ”, “3000 triệu” và “3.000.000.000” như ba kiểu dữ liệu khác nhau

Đây là nguyên nhân phổ biến khiến bộ lọc cho kết quả sai.

Nếu giá được nhập tự do dưới dạng text, mỗi editor có thể dùng một cách viết. Khi đó backend phải cố gắng đoán ý nghĩa của dữ liệu trước khi so sánh.

Cách ổn định hơn là:

Lưu giá ở một đơn vị chuẩn → hiển thị theo đơn vị thân thiện với người dùng.

Ví dụ hệ thống lưu số nguyên theo VND, nhưng giao diện tự động hiển thị:

800000000   → 800 triệu
2500000000  → 2,5 tỷ
12000000000 → 12 tỷ

Quy tắc hiển thị và quy tắc lọc vì vậy được tách khỏi nhau.

3. “Giá thỏa thuận” phải có trạng thái riêng

Không nên biến “giá thỏa thuận” thành số 0 để thuận tiện lưu database.

Nếu làm vậy, khi khách lọc dưới 1 tỷ, những sản phẩm chưa công bố giá có thể vô tình xuất hiện ở đầu danh sách như thể chúng có giá bằng 0.

Tốt hơn là hệ thống có một trạng thái rõ, ví dụ:

price_status = fixed
price_status = from
price_status = range
price_status = negotiable

và các field số tương ứng chỉ được sử dụng khi có giá trị thực.

Trên frontend, sản phẩm “giá thỏa thuận” có thể được xử lý theo chính sách riêng thay vì bị ép vào một khoảng giá không chính xác.

4. Sản phẩm có “giá từ” cần quy tắc lọc rõ ràng

Giả sử một dự án được quảng bá:

Giá từ 2,8 tỷ.

Nếu người dùng lọc 2–3 tỷ, dự án có nên xuất hiện?

Có thể có, nếu 2,8 tỷ thực sự đại diện cho một sản phẩm còn khả dụng trong khoảng đó.

Nhưng nếu mức “từ 2,8 tỷ” chỉ là giá lịch sử hoặc một căn đã bán hết, kết quả sẽ gây hiểu nhầm.

Do đó vấn đề không chỉ là kỹ thuật. Dữ liệu giá còn cần quy trình cập nhật.

Website sàn hoặc dự án có biến động giá mạnh nên xác định nguồn dữ liệu và thời điểm cập nhật để filter không biến thành nơi hiển thị mức giá đã lỗi thời.

5. Nếu một sản phẩm có khoảng giá, cần xác định logic giao nhau

Giả sử dự án có các căn trong khoảng:

3–5 tỷ.

Người dùng tìm:

4–6 tỷ.

Hai khoảng có phần giao nhau nên dự án có thể được coi là phù hợp.

Ở tầng logic, một quy tắc thường gặp là kiểm tra hai khoảng có giao nhau hay không:

listing_min_price <= filter_max_price
AND
listing_max_price >= filter_min_price

Nhưng nếu website đang lọc từng căn riêng lẻ thay vì dự án, việc lưu một khoảng giá cấp dự án có thể không còn cần thiết.

Đây là lý do phải xác định đối tượng đang được lọc: dự án, căn hộ, tin đăng hay sản phẩm cụ thể.

6. “Diện tích” cũng không phải một field đơn giản

Với căn hộ, diện tích có thể là diện tích thông thủy hoặc tim tường. Với nhà phố có thể có diện tích đất và tổng diện tích sàn. Với đất nền lại chủ yếu quan tâm diện tích lô đất.

Nếu website gom tất cả thành một field area, người dùng có thể nhìn thấy các số tưởng như tương đương nhưng thực tế đo hai khái niệm khác nhau.

Vì vậy data model nên xác định rõ loại diện tích đang sử dụng.

Ví dụ:

land_area
usable_area
floor_area
unit_area

Không phải website nào cũng cần đủ bốn field. Chỉ nên lưu những thuộc tính thực sự có ý nghĩa với loại sản phẩm đang quản lý.

7. Bộ lọc diện tích phải nhất quán với loại hình

Một preset “dưới 50 m²” rất có ý nghĩa với căn hộ nhưng có thể gần như vô dụng với biệt thự hoặc đất nền.

Do đó preset không nên được thiết kế một lần rồi áp cho mọi loại hình.

Khi người dùng chuyển từ “Căn hộ” sang “Đất nền”, hệ thống có thể thay các khoảng diện tích dựa trên inventory hoặc phân khúc thực tế.

Đây là ví dụ cho việc filter phụ thuộc lẫn nhau, một chủ đề được mở rộng hơn trong bộ lọc tìm kiếm nâng cao cho website BĐS.

Preset hay nhập Min–Max: không nên bắt người dùng chọn một trong hai

Hai cách này phục vụ hai nhóm nhu cầu khác nhau.

Preset tối ưu cho tốc độ. Người dùng có thể chạm một lần vào “2–3 tỷ” hoặc “70–90 m²” và xem kết quả ngay.

Min–Max lại hữu ích với khách đã biết khá chính xác ngân sách hoặc diện tích mong muốn, chẳng hạn 2,7–3,4 tỷ hoặc 62–75 m².

Vì vậy giao diện hiệu quả thường không cần lựa chọn tuyệt đối giữa preset và custom range.

Có thể dùng:

Preset cho thao tác nhanh → Min–Max trong phần tùy chỉnh chi tiết.

Range slider có đẹp nhưng không phải lúc nào cũng dễ dùng

Slider tạo cảm giác trực quan trên desktop, nhưng có một số hạn chế.

Trên màn hình nhỏ, việc kéo chính xác hai handle khá khó. Với giá trải dài từ vài trăm triệu tới hàng chục tỷ, một slider tuyến tính còn khiến người dùng khó chọn những giá trị thấp.

Slider cũng cần xử lý accessibility bằng bàn phím và trình đọc màn hình nếu muốn trải nghiệm đầy đủ.

Do đó không nên dùng slider chỉ vì nó trông hiện đại.

Trong nhiều trường hợp, hai input:

Giá từ → Giá đến

kết hợp preset nhanh lại dễ sử dụng hơn.

Preset nên sinh từ thị trường của chính website

Các khoảng:

Dưới 2 tỷ → 2–3 tỷ → 3–5 tỷ → trên 5 tỷ

có thể phù hợp ở một website nhưng rất kém ở website khác.

Nếu phần lớn inventory nằm ở 8–20 tỷ, việc dành ba preset đầu cho dưới 5 tỷ sẽ khiến nhiều lựa chọn gần như luôn trả về 0 kết quả.

Do đó preset nên được thiết kế từ ít nhất hai nguồn:

phân bố sản phẩm thực tế + hành vi tìm kiếm của người dùng.

Khi đã có dữ liệu tracking, đội vận hành có thể quan sát các khoảng được chọn nhiều nhất rồi điều chỉnh giao diện.

Không cần chia các khoảng đều nhau

Bộ lọc không phải biểu đồ toán học nên các mức giá không bắt buộc phải cách nhau đúng 1 tỷ hay diện tích phải tăng đều 20 m².

Khoảng nên phản ánh cách người mua nghĩ về ngân sách.

Ví dụ một thị trường có lượng sản phẩm lớn quanh 2–3 tỷ và 3–5 tỷ thì đây có thể là hai preset hợp lý dù độ rộng khác nhau.

Tương tự diện tích căn hộ có thể tập trung quanh các nhóm gắn với 1PN, 2PN và 3PN thay vì chia đều theo mỗi 10 m².

Không nên hard-code preset mãi mãi

Thị trường và inventory thay đổi theo thời gian.

Nếu preset được viết cứng trong source code, mỗi lần thay đổi đội marketing phải gọi developer.

Với website có nhu cầu vận hành thường xuyên, có thể cho phép admin quản lý các preset hoặc sinh chúng theo cấu hình.

Tuy nhiên cũng không nên tự động thay đổi quá thường xuyên, bởi người dùng quay lại có thể khó hình thành thói quen nếu giao diện liên tục khác đi.

UX desktop: đưa giá và diện tích lên lớp lọc nhanh khi chúng thực sự quan trọng

Trang listing không nên hiển thị ngay 15 điều kiện lọc với mức độ ưu tiên ngang nhau.

Nếu dữ liệu hành vi cho thấy giá và diện tích được sử dụng thường xuyên, hai tiêu chí này có thể nằm ở lớp lọc nhanh cùng khu vực hoặc loại hình.

Những thuộc tính ít dùng hơn như hướng, nội thất, pháp lý hoặc số WC có thể nằm trong “Lọc thêm”.

Cách tổ chức này giảm cognitive load và giúp người dùng đạt kết quả đầu tiên nhanh hơn.

UX mobile: ưu tiên chip + drawer thay vì một form dài

Trên mobile, diện tích hiển thị bị giới hạn nên bộ lọc thường phù hợp với mô hình drawer hoặc bottom sheet.

Bên ngoài drawer có thể hiển thị một số chip đang hoạt động, chẳng hạn:

2–3 tỷ ×
70–90 m² ×
Hà Đông ×

Nhờ vậy người dùng biết ngay danh sách hiện đang chịu ảnh hưởng bởi những điều kiện nào.

Bên trong drawer, nút Áp dụng nên dễ tiếp cận và có thể hiển thị số kết quả dự kiến nếu backend đáp ứng được.

Nút Xóa lọc cũng cần rõ, bởi việc người dùng không biết cách trở lại danh sách đầy đủ là một lỗi UX rất phổ biến.

Các nguyên tắc mobile tổng thể có thể xem tại tối ưu website bất động sản trên mobile.

Có nên cập nhật kết quả ngay mỗi khi người dùng kéo slider?

Không phải lúc nào cũng nên.

Nếu mỗi pixel di chuyển của slider tạo một request mới, server có thể nhận rất nhiều truy vấn gần như vô nghĩa.

Có thể sử dụng debounce hoặc chỉ chạy truy vấn sau khi người dùng dừng thao tác. Trên mobile, một nút “Xem 28 kết quả” sau khi chọn xong thường tạo trải nghiệm ổn định hơn.

Điều quan trọng là người dùng cảm nhận hệ thống phản hồi nhanh mà backend không bị gọi quá mức.

Số kết quả dự kiến giúp người dùng tránh chọn quá hẹp

Ví dụ trước khi áp dụng, drawer hiển thị:

28 bất động sản phù hợp.

Nếu khách kéo diện tích xuống một khoảng rất hẹp và con số trở thành 0, họ có thể điều chỉnh ngay thay vì đóng drawer rồi gặp một trang trống.

Đây là một cách phòng zero-result ngay trong quá trình lọc.

Tuy nhiên việc tính số lượng theo thời gian thực cũng tạo query. Với dataset lớn, backend cần được tối ưu để tính count hiệu quả.

Không có một thứ tự lọc cố định phù hợp cho mọi người

Bài cũ ưu tiên thứ tự:

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

Đây có thể là một mặc định hợp lý, nhưng không nên coi là quy tắc bắt buộc.

Có khách đã xác định khu vực. Có khách lại chỉ biết “ngân sách 3 tỷ” và sẵn sàng xem nhiều khu vực. Một nhà đầu tư có thể bắt đầu bằng loại hình rồi mới chọn vị trí.

Thiết kế tốt cho phép người dùng lọc theo thứ tự tự nhiên của họ, đồng thời sử dụng filter phụ thuộc khi thật sự cần, chẳng hạn danh sách phường chỉ xuất hiện sau khi đã có quận.

Kết quả sau lọc cần giải thích điều kiện đang áp dụng

Nếu người dùng thấy 17 kết quả nhưng không nhớ mình vừa lọc gì, họ khó hiểu tại sao các sản phẩm khác biến mất.

Trang danh sách nên hiển thị trạng thái lọc bằng chip hoặc phần tóm tắt:

Hà Nội · Căn hộ · 2–3 tỷ · 60–80 m²

Mỗi điều kiện nên có thể xóa riêng.

Điều này đặc biệt quan trọng khi người dùng quay lại danh sách từ một trang chi tiết.

Giữ trạng thái bộ lọc khi người dùng quay lại

Một trải nghiệm gây khó chịu là:

Lọc 5 tiêu chí → mở một sản phẩm → bấm Back → mất toàn bộ bộ lọc.

Website nên giữ trạng thái bằng URL, history state hoặc cơ chế phù hợp với kiến trúc frontend.

Nhờ đó người dùng tiếp tục so sánh sản phẩm thay vì phải thiết lập lại từ đầu.

Đây là một chi tiết nhỏ nhưng ảnh hưởng lớn tới website có hành vi duyệt nhiều listing.

URL bộ lọc cần được thiết kế cho cả UX lẫn SEO

Việc lưu trạng thái bằng URL rất hữu ích, ví dụ:

?price_min=2000000000&price_max=3000000000&area_min=60

Nhưng nếu mọi kết hợp giá và diện tích đều tạo một URL có thể crawl/index, website có thể sinh ra rất nhiều trang gần như giống nhau.

Ví dụ chỉ riêng 20 mức giá × 20 khoảng diện tích × hàng chục khu vực đã có thể tạo hàng nghìn tổ hợp.

Do đó cần phân biệt:

URL phục vụ trạng thái lọc

với:

Landing SEO được chủ động index.

Các trang lọc đáng index nên được quyết định theo nhu cầu tìm kiếm và giá trị nội dung, không phải vì hệ thống có thể sinh URL.

Không nên dùng canonical như cách duy nhất để “dọn” mọi URL filter

SEO faceted navigation cần một chính sách tổng thể về crawl, index và internal linking.

Có URL cần index vì đại diện cho một nhu cầu tìm kiếm hữu ích. Có URL chỉ dùng trong phiên lọc và không nên trở thành landing SEO.

Do đó quy tắc phải được xác định ngay từ kiến trúc bộ lọc.

Phần này được trình bày rộng hơn trong hướng dẫn thiết lập bộ lọc BĐS nâng cao.

Zero-result không nên chỉ hiện “Không tìm thấy sản phẩm”

Trang không có kết quả là lúc website biết khá nhiều về nhu cầu của người dùng.

Thay vì kết thúc hành trình, hệ thống có thể giải thích tiêu chí nào đang quá hẹp và đưa ra lựa chọn gần nhất.

Ví dụ:

Không có căn 70–80 m² trong khoảng 2–2,5 tỷ tại khu vực này.

Sau đó website có thể cho phép:

Bỏ riêng diện tích → tăng trần giá → xem khu vực lân cận → nhận thông báo khi có sản phẩm phù hợp.

Điều quan trọng là gợi ý phải dựa vào inventory thực tế, không nên mặc định luôn nới ±10% hoặc ±15% cho mọi thị trường.

“Gần tiêu chí” cần có logic minh bạch

Nếu website đề xuất sản phẩm tương tự, cần xác định mức độ tương tự dựa vào đâu.

Ví dụ một sản phẩm vượt ngân sách 2% nhưng đúng khu vực và diện tích có thể gần nhu cầu hơn sản phẩm đúng giá nhưng cách xa 20 km.

Hệ thống nâng cao có thể chấm điểm match dựa trên nhiều thuộc tính. Website nhỏ hơn có thể chỉ dùng một quy tắc đơn giản như giữ khu vực rồi nới một tiêu chí.

Không cần AI để xử lý zero-result tốt. Quan trọng là thứ tự nới điều kiện phản ánh intent của người dùng.

Filter nhanh cần truy vấn nhanh

Một bộ lọc UX tốt nhưng mỗi lần áp dụng mất 4–5 giây vẫn tạo trải nghiệm kém.

Ở tầng database, các field dùng thường xuyên cho filtering nên được lưu dưới dạng phù hợp với so sánh số và được đánh index theo workload thực tế.

Tuy nhiên không nên tạo index một cách máy móc cho mọi cột. Mỗi index cũng có chi phí lưu trữ và ảnh hưởng tới thao tác ghi.

Với dataset lớn, cần xem query plan, tần suất truy vấn và tổ hợp filter thực tế trước khi quyết định index đơn hay composite index.

Không nên lọc bằng cách tìm chuỗi trong nội dung HTML

Nếu giá và diện tích chỉ nằm trong phần mô tả:

Giá bán khoảng 3 tỷ, diện tích 72m²

thì việc filter chính xác và nhanh trở nên khó khăn.

Thuộc tính phục vụ lọc nên tồn tại dưới dạng dữ liệu có cấu trúc.

Nội dung HTML dùng để trình bày, không nên trở thành database nghiệp vụ.

Đây cũng là nguyên tắc quan trọng trong quản lý dữ liệu và nội dung website BĐS.

Lọc bán và cho thuê cần tách bối cảnh giá

Một website có cả mua bán và cho thuê không nên đưa giá 15 triệu/tháng và 3 tỷ vào cùng một range.

Loại giao dịch nên được xác định trước hoặc trở thành một filter cấp cao để hệ thống biết cách diễn giải giá.

Sau khi người dùng chọn “Cho thuê”, preset có thể chuyển sang:

Dưới 10 triệu/tháng → 10–20 triệu/tháng → 20–30 triệu/tháng...

Khi chọn “Mua bán”, bộ giá chuyển sang triệu/tỷ.

Điều này vừa dễ hiểu cho người dùng vừa đơn giản hóa logic dữ liệu.

Có nên cho lọc theo giá/m²?

Có thể, nhưng chỉ khi dữ liệu đủ sạch và người dùng thực sự có nhu cầu.

Giá/m² hữu ích khi so sánh những sản phẩm có diện tích khác nhau, đặc biệt với căn hộ hoặc đất.

Tuy nhiên nếu một số listing dùng diện tích đất, số khác dùng diện tích sử dụng, phép tính sẽ thiếu nhất quán.

Do đó trước khi thêm filter này, cần xác định rõ:

giá/m² đang lấy giá nào chia cho loại diện tích nào.

Sắp xếp kết quả sau lọc cũng quan trọng như chính bộ lọc

Sau khi lọc còn 50 sản phẩm, người dùng vẫn cần biết nên xem cái nào trước.

Các lựa chọn như:

Phù hợp nhất · Giá thấp đến cao · Giá cao đến thấp · Diện tích lớn nhất · Mới nhất

có thể hỗ trợ bước tiếp theo.

Nếu có thuật toán “Phù hợp nhất”, website nên có logic có thể giải thích thay vì sắp xếp tùy ý.

Đồng bộ list và map khi website có bản đồ

Nếu website hiển thị cả danh sách và bản đồ, hai phần phải phản ánh cùng một filter state.

Khi người dùng chọn 3–5 tỷ và 70–90 m², những pin không phù hợp không nên vẫn xuất hiện trên bản đồ.

Tương tự khi người dùng di chuyển vùng bản đồ và chọn “Tìm trong khu vực này”, filter địa lý cần được đồng bộ lại với listing.

Nếu list và map cho hai tập kết quả khác nhau, người dùng sẽ nhanh chóng mất niềm tin vào dữ liệu.

Tracking bộ lọc nên đo hành vi ra quyết định

Chỉ ghi event filter_click chưa cung cấp nhiều giá trị.

Nên biết người dùng đang lọc tiêu chí nào và kết quả tiếp theo ra sao.

Một funnel hữu ích có thể là:

Listing View → Filter Applied → Results Returned → Detail View → CTA → Lead.

Trong đó có thể theo dõi thêm:

Metric	Câu hỏi
Filter Usage Rate	Có bao nhiêu phiên dùng bộ lọc?
Preset Usage	Khoảng giá/diện tích nào được dùng nhiều?
Zero-result Rate	Người dùng thường chọn điều kiện quá hẹp ở đâu?
Result-to-Detail CTR	Kết quả sau lọc có đủ phù hợp để khách mở xem?
Lead after Filter	Nhóm dùng filter có tạo hành động kinh doanh không?

Những dữ liệu này có thể đưa vào quy trình CRO và tối ưu marketing website BĐS để tiếp tục điều chỉnh preset và thứ tự filter.

Zero-result rate cao không phải lúc nào cũng là lỗi UX

Nếu khách thường xuyên lọc 2 tỷ ở một khu vực mà inventory thực tế đều trên 5 tỷ, zero-result phản ánh khoảng cách giữa nhu cầu thị trường và nguồn hàng.

Đó là thông tin kinh doanh hữu ích.

Ngược lại, nếu inventory có nhiều sản phẩm phù hợp nhưng zero-result vẫn cao, cần kiểm tra data quality hoặc logic filter.

Do đó metric phải được phân tích cùng dữ liệu nguồn, không nên chỉ nhìn tỷ lệ rồi cố giảm bằng mọi giá.

Filter có thể trở thành tín hiệu intent cho lead scoring

Một người chỉ xem homepage cung cấp ít tín hiệu về nhu cầu.

Một người liên tục chọn:

Hà Đông → Căn hộ → 2–3 tỷ → 60–75 m²

đã cho website một bức tranh rõ hơn về mục tiêu.

Nếu sau đó người này bấm “Nhận bảng giá”, hệ thống có thể gửi cùng filter context sang CRM để sales không phải hỏi lại toàn bộ nhu cầu từ đầu.

Điều này biến bộ lọc từ một công cụ UX thành một nguồn dữ liệu hỗ trợ sales.

Đừng gửi toàn bộ lịch sử lọc vào CRM một cách thiếu kiểm soát

Không phải mọi click đều có giá trị với sales.

Nếu một phiên thử 20 bộ lọc khác nhau, đẩy từng thao tác thành 20 ghi chú sẽ làm CRM rất nhiễu.

Có thể chỉ lưu:

bộ lọc cuối cùng trước conversion

hoặc:

nhóm nhu cầu được tổng hợp từ hành vi đủ rõ.

Mục tiêu là cung cấp context, không phải sao chép toàn bộ analytics vào CRM.

Những lỗi phổ biến khi triển khai lọc giá và diện tích

Lỗi đầu tiên là thiết kế giao diện trước khi chuẩn hóa dữ liệu. Khi database chứa cả số và text, developer phải thêm nhiều ngoại lệ nhưng kết quả vẫn khó tin cậy.

Lỗi thứ hai là dùng một bộ preset cho mọi khu vực và loại hình. Điều này làm nhiều khoảng gần như không có sản phẩm hoặc quá rộng để hữu ích.

Lỗi thứ ba là mỗi thay đổi slider đều reload toàn trang, khiến mobile chậm và mất vị trí cuộn.

Lỗi thứ tư là không giữ filter khi khách quay lại từ trang chi tiết.

Lỗi thứ năm là cho phép mọi tổ hợp filter trở thành URL indexable, tạo một lượng lớn trang mỏng hoặc trùng lặp.

Và lỗi cuối cùng là chỉ đo số lần dùng filter mà không kiểm tra liệu người dùng sau lọc có xem sản phẩm và tạo lead hay không.

Quy trình triển khai module giá và diện tích

Thay vì bắt đầu bằng slider, quy trình nên đi từ dữ liệu.

Bước 1 – Xác định đối tượng: đang lọc dự án, listing hay căn cụ thể.

Bước 2 – Chuẩn hóa dữ liệu: giá, loại giá, loại diện tích và đơn vị.

Bước 3 – Phân tích inventory: xem dữ liệu tập trung ở những khoảng nào.

Bước 4 – Thiết kế preset: dựa trên nhu cầu người dùng và inventory.

Bước 5 – Thiết kế UX: desktop, mobile, trạng thái active và zero-result.

Bước 6 – Tối ưu backend: query, index, cache và count.

Bước 7 – Xác định SEO policy: URL nào chỉ phục vụ filter, URL nào có thể là landing.

Bước 8 – Tracking: đo usage, zero-result, detail view và lead.

Bước 9 – Tối ưu định kỳ: điều chỉnh preset và logic theo dữ liệu thật.

Checklist nghiệm thu bộ lọc giá và diện tích

• [ ] Giá được lưu dưới dạng dữ liệu số chuẩn;
• [ ] “Giá thỏa thuận”, “giá từ” và khoảng giá có trạng thái riêng;
• [ ] Đã xác định rõ loại diện tích dùng để lọc;
• [ ] Preset thay đổi hợp lý theo loại hình/giao dịch nếu cần;
• [ ] Có cách nhập Min–Max cho người dùng cần chính xác;
• [ ] Slider nếu dùng phải dễ thao tác trên mobile;
• [ ] Các filter đang áp dụng được hiển thị rõ;
• [ ] Có thể xóa từng filter và xóa toàn bộ;
• [ ] Trạng thái được giữ khi quay lại danh sách;
• [ ] Zero-result có phương án nới điều kiện hợp lý;
• [ ] Query không reload hoặc gọi backend quá mức;
• [ ] Dataset lớn đã kiểm tra hiệu năng filter;
• [ ] List và map đồng bộ nếu có bản đồ;
• [ ] URL filter có quy tắc crawl/index rõ;
• [ ] Tracking được Filter → Result → Detail → Lead.

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

Nên dùng dropdown, chip hay slider để lọc giá?

Không có một lựa chọn tốt nhất cho mọi website. Chip/preset phù hợp cho thao tác nhanh, Min–Max phù hợp với nhu cầu chính xác, còn slider hữu ích khi range không quá rộng và trải nghiệm kéo đủ tốt. Có thể kết hợp nhiều cách nhưng không nên làm giao diện quá phức tạp.

Nên đặt bao nhiêu khoảng giá?

Không nên lấy một con số cố định. Số preset phụ thuộc distribution của inventory, kích thước màn hình và cách khách hàng phân nhóm ngân sách. Thường chỉ nên hiển thị những mức có ý nghĩa rõ, còn giá trị chi tiết để trong Min–Max.

Có nên cho người dùng nhập trực tiếp giá?

Có nếu website có khách hàng biết rõ ngân sách. Input nên hỗ trợ định dạng số thân thiện nhưng backend vẫn phải nhận dữ liệu số chuẩn để lọc.

“Giá thỏa thuận” có nên xuất hiện khi lọc theo giá?

Phụ thuộc chính sách sản phẩm. Không nên coi nó là giá 0 hoặc tự ý đưa vào mọi khoảng. Website có thể tách thành một lựa chọn riêng hoặc chỉ hiển thị khi người dùng không đặt điều kiện giá.

Diện tích căn hộ nên dùng thông thủy hay tim tường?

Website cần chọn một quy ước nhất quán hoặc ghi rõ loại diện tích đang dùng. Không nên trộn hai loại mà không chú thích vì người dùng sẽ so sánh những con số không tương đương.

Có nên tự động chạy filter ngay khi chọn điều kiện?

Có thể trên desktop hoặc dataset nhỏ nếu phản hồi đủ nhanh. Với mobile hoặc filter nhiều điều kiện, nút “Áp dụng/Xem kết quả” thường dễ kiểm soát hơn và giảm request không cần thiết.

Mỗi tổ hợp giá và diện tích có nên có URL riêng?

Có thể có URL để giữ trạng thái hoặc chia sẻ, nhưng không có nghĩa tất cả các URL đó nên được index. SEO policy cần phân biệt faceted URL và landing page có nhu cầu tìm kiếm thực.

Zero-result nhiều có phải bộ lọc thiết kế kém?

Không nhất thiết. Nó có thể phản ánh nguồn hàng không khớp nhu cầu. Cần kiểm tra inventory, data quality và hành vi người dùng trước khi kết luận.

Có nên gửi thông tin filter sang CRM?

Nên nếu filter thể hiện nhu cầu rõ và khách đã chuyển đổi. Thường chỉ cần gửi context quan trọng như khu vực, khoảng giá, diện tích và loại hình thay vì toàn bộ lịch sử thao tác.

Kết luận

Bộ lọc giá và diện tích tưởng như là một chức năng frontend đơn giản nhưng thực tế đi qua gần như toàn bộ hệ thống:

Data → UX → Query → State → SEO → Tracking → CRM.

Nếu dữ liệu không chuẩn, kết quả sai. Nếu UX rối, người dùng không sử dụng. Nếu query chậm, trải nghiệm bị gián đoạn. Nếu URL filter không được kiểm soát, SEO có thể phát sinh hàng loạt trang không cần thiết. Và nếu không tracking, doanh nghiệp không biết preset nào thực sự phù hợp với khách hàng.

Điểm quan trọng nhất là không xây bộ lọc dựa trên cảm tính. Khoảng giá và diện tích nên phản ánh inventory thực tế + nhu cầu thực tế của người dùng, sau đó tiếp tục được điều chỉnh dựa trên dữ liệu sử dụng.

Nếu website cần mở rộng từ hai tiêu chí này sang khu vực, loại hình, pháp lý, tiến độ và nhiều điều kiện phụ thuộc, hãy chuyển sang hướng dẫn thiết lập bộ lọc tìm kiếm nâng cao cho dự án BĐS. Còn nếu đang xây hệ thống tìm kiếm tổng thể, có thể kết hợp thêm tính năng tìm kiếm thông minh trên website BĐS để người dùng có cả search và filter trong cùng một hành trình.