Bài 81 – Thu thập số điện thoại và dữ liệu khách hàng trong Marketing BĐS số cần lưu ý gì? thuộc series Marketing BĐS số. Bài được thiết kế theo hướng quản trị thực hành: biến các nguyên tắc pháp lý, dữ liệu và đạo đức thành quy trình, bằng chứng và điểm kiểm soát có thể áp dụng trong chiến dịch.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Nội dung được biên soạn cho mục đích giảng dạy Marketing BĐS số, không phải ý kiến pháp lý cho một hồ sơ cụ thể. Các yêu cầu pháp lý được trình bày theo khung pháp luật đang có hiệu lực tại thời điểm biên soạn; khi triển khai thực tế cần đối chiếu văn bản hiện hành, vai trò của các bên và tình huống cụ thể.
Ranh giới chuyên đề: Bài thuộc phần dữ liệu cá nhân, pháp lý và đạo đức số. Nội dung giúp nhận diện rủi ro và thiết kế kiểm soát trong Marketing BĐS số; không thay thế tư vấn pháp lý cho tình huống cụ thể. Kỹ thuật bảo mật/API/SQL thuộc Tin học BĐS.
1. Số điện thoại là dữ liệu cá nhân cơ bản theo Nghị định 356/2025/NĐ-CP; vì vậy một form chỉ xin tên và số điện thoại vẫn là hoạt động xử lý dữ liệu cá nhân chứ không phải dữ liệu vô danh
Số điện thoại là dữ liệu cá nhân cơ bản theo Nghị định 356/2025/NĐ-CP; vì vậy một form chỉ xin tên và số điện thoại vẫn là hoạt động xử lý dữ liệu cá nhân chứ không phải dữ liệu vô danh.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
2. Marketing nên bắt đầu từ mục đích: cần dữ liệu nào để gửi tài liệu, tư vấn, đặt lịch, phân loại nhu cầu hoặc thực hiện một hoạt động đã thông báo; không nên thu dữ liệu chỉ vì CRM có sẵn nhiều trường
Marketing nên bắt đầu từ mục đích: cần dữ liệu nào để gửi tài liệu, tư vấn, đặt lịch, phân loại nhu cầu hoặc thực hiện một hoạt động đã thông báo; không nên thu dữ liệu chỉ vì CRM có sẵn nhiều trường.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
3. Nguyên tắc tối thiểu hóa giúp giảm rủi ro: giai đoạn nhận bảng giá thường không cần CCCD, thông tin tài chính chi tiết hay dữ liệu nhạy cảm nếu chưa có lý do nghiệp vụ/pháp lý phù hợp
Nguyên tắc tối thiểu hóa giúp giảm rủi ro: giai đoạn nhận bảng giá thường không cần CCCD, thông tin tài chính chi tiết hay dữ liệu nhạy cảm nếu chưa có lý do nghiệp vụ/pháp lý phù hợp.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
| Câu hỏi | Thiết kế cần chốt | Bằng chứng |
|---|---|---|
| Mục đích? | Purpose/use case | Register |
| Nguồn? | Source-of-truth | Evidence |
| Ai? | Owner/access | RACI/log |
| Điều kiện? | Rule/consent/claim scope | Version |
| Kiểm soát? | Approval/monitoring | Audit trail |
4. Thông báo về xử lý dữ liệu cần đủ rõ để khách biết loại dữ liệu, mục đích, bên xử lý/kiểm soát liên quan, quyền của mình và cách liên hệ khi có yêu cầu
Thông báo về xử lý dữ liệu cần đủ rõ để khách biết loại dữ liệu, mục đích, bên xử lý/kiểm soát liên quan, quyền của mình và cách liên hệ khi có yêu cầu.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
5. Sự đồng ý chỉ là một căn cứ/quy tắc quan trọng trong khung pháp luật; khi dựa trên đồng ý, cần bảo đảm tính tự nguyện, rõ ràng, cụ thể và có thể kiểm chứng
Sự đồng ý chỉ là một căn cứ/quy tắc quan trọng trong khung pháp luật; khi dựa trên đồng ý, cần bảo đảm tính tự nguyện, rõ ràng, cụ thể và có thể kiểm chứng.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
6. Form, landing page, chatbot, instant form, sự kiện offline và môi giới nhập tay đều phải được xem trong cùng data flow; rủi ro thường phát sinh khi dữ liệu được chuyển qua nhiều hệ thống mà không còn dấu vết mục đích
Form, landing page, chatbot, instant form, sự kiện offline và môi giới nhập tay đều phải được xem trong cùng data flow; rủi ro thường phát sinh khi dữ liệu được chuyển qua nhiều hệ thống mà không còn dấu vết mục đích.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
7. Retention cần được xác định theo mục đích và yêu cầu pháp luật/nghiệp vụ; giữ dữ liệu marketing vô thời hạn chỉ vì 'có thể dùng sau' làm tăng rủi ro và chi phí quản trị
Retention cần được xác định theo mục đích và yêu cầu pháp luật/nghiệp vụ; giữ dữ liệu marketing vô thời hạn chỉ vì 'có thể dùng sau' làm tăng rủi ro và chi phí quản trị.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
8. Quy trình tốt phải cho phép thực hiện các yêu cầu của chủ thể dữ liệu, kiểm soát quyền truy cập, ghi log, xử lý sự cố và dừng các workflow marketing khi dữ liệu không còn được phép sử dụng
Quy trình tốt phải cho phép thực hiện các yêu cầu của chủ thể dữ liệu, kiểm soát quyền truy cập, ghi log, xử lý sự cố và dừng các workflow marketing khi dữ liệu không còn được phép sử dụng.
Khi áp dụng, cần đặt câu hỏi ở cấp hệ thống: thông tin đến từ đâu, ai có quyền dùng, mục đích nào được phép, phiên bản nào đang chạy, bằng chứng nào hỗ trợ claim, điều kiện nào phải dừng và dữ liệu downstream nào chứng minh chiến dịch thực sự tạo giá trị.
Ma trận trọng tâm
| Lớp | Câu hỏi | Kiểm soát |
|---|---|---|
| Purpose | Thu để làm gì? | Purpose statement |
| Minimize | Có thực sự cần? | Field review |
| Notice | Khách biết gì? | Privacy notice |
| Consent | Có cần/đủ bằng chứng? | Consent record |
| Access | Ai xem? | RBAC |
| Retention | Giữ bao lâu? | Schedule |
| Rights | Khách yêu cầu thế nào? | Request workflow |
Khung pháp lý dữ liệu cá nhân đang áp dụng
Tại thời điểm biên soạn, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP đã có hiệu lực từ ngày 01/01/2026. Nghị định 356 xác định số điện thoại thuộc dữ liệu cá nhân cơ bản. Điều 9 của Luật 91/2025/QH15 quy định sự đồng ý phải dựa trên sự tự nguyện và biết rõ thông tin về loại dữ liệu, mục đích, bên kiểm soát/kiểm soát và xử lý cùng các quyền, nghĩa vụ; sự đồng ý phải rõ ràng, cụ thể, có thể kiểm chứng và theo từng mục đích.
Đối với Marketing BĐS số, ý nghĩa thực hành là không thể coi việc có số điện thoại trong file là mặc nhiên có quyền dùng cho mọi chiến dịch. Data governance phải trả lời được nguồn, mục đích, phạm vi, trạng thái đồng ý hoặc căn cứ xử lý phù hợp, quyền truy cập và vòng đời dữ liệu.
Tình huống giả lập phục vụ giảng dạy
Landing page dự án yêu cầu họ tên, số điện thoại, CCCD, nơi ở, mức thu nhập và tình trạng hôn nhân chỉ để tải brochure. Hãy phân loại dữ liệu nào thực sự cần, dữ liệu nào nên bỏ hoặc trì hoãn và data flow cần thông báo ra sao.
Sinh viên phải nhận diện rủi ro, dữ liệu/bằng chứng còn thiếu, người chịu trách nhiệm, control trước khi chạy và cách theo dõi sau khi chạy. Với case performance, phải tách lỗi media, website, data, CRM và Sales thay vì đổ lỗi cho một bộ phận.
Data Collection Blueprint
Một hệ thống quản trị tốt cần biến nguyên tắc thành artefact có thể kiểm tra: register, rule, owner, version, evidence, alert và decision record. Không nên dựa vào trí nhớ cá nhân hoặc trao đổi rời rạc trong nhóm chat. Khi có khiếu nại, audit hoặc hiệu quả đi xuống, tổ chức phải truy được ai quyết định, dựa trên dữ liệu nào và phiên bản nào đã chạy.
| Thành phần | Câu hỏi kiểm soát | Artefact |
|---|---|---|
| Definition | Khái niệm được hiểu thế nào? | Data/claim dictionary |
| Source | Thông tin từ đâu? | Evidence/source register |
| Owner | Ai chịu trách nhiệm? | RACI |
| Version | Phiên bản nào? | Version history |
| Approval | Ai duyệt? | Approval log |
| Monitoring | Theo dõi gì? | Dashboard/alerts |
| Incident | Nếu sai thì sao? | Playbook |
Pre-mortem: giả định chiến dịch đã thất bại
Trước khi xuất bản, nhóm nên giả định sau 30 ngày chiến dịch gây khiếu nại, dữ liệu bị dùng sai hoặc Sales nói lead rất kém. Sau đó liệt kê các nguyên nhân có thể: claim cũ, consent mơ hồ, form quá rộng, audience lệch, automation không suppress, source mất, affiliate gian lận hoặc AI tạo nội dung sai. Pre-mortem giúp đặt kiểm soát trước khi hậu quả xảy ra.
| Rủi ro | Early signal | Preventive control | Recovery |
|---|---|---|---|
| Claim lỗi thời | Update mismatch | Expiry date | Pause/update |
| Consent gap | Unknown status | Consent record | Suppress/re-consent |
| Data leak | Bulk export | Access alert | Revoke/investigate |
| Lead fraud | Invalid rate↑ | Validation | Block source |
| AI error | Fact mismatch | Human gate | Withdraw/correct |
| Funnel leak | Stage drop | Monitoring | Experiment/fix |
Decision Record
Mỗi quyết định rủi ro cao nên ghi mục tiêu, dữ liệu, giả định, bằng chứng, người duyệt, thời điểm, phạm vi, guardrail và ngày review. Decision Record đặc biệt hữu ích với claim pháp lý/giá, thay đổi consent, chia sẻ database, mở affiliate mới, bật auto-publish AI hoặc thay scoring/routing.
Ma trận mức độ rủi ro
| Mức | Ví dụ | Xử lý |
|---|---|---|
| Thấp | Copy/format không chứa claim nhạy cảm | Review thường |
| Vừa | Form, nurture, personalization | Owner + test |
| Cao | Giá, pháp lý, scarcity, customer data export | Approval + evidence |
| Rất cao | Leak, fraud lớn, claim sai diện rộng | Pause/escalate/incident |
Checklist áp dụng
- Xác định mục tiêu và phạm vi chiến dịch.
- Kiểm source-of-truth cho dữ liệu và claim.
- Kiểm data fields/mục đích/consent hoặc căn cứ phù hợp.
- Kiểm quyền truy cập và bên thứ ba.
- Kiểm giá/inventory/pháp lý/tiến độ và ngày cập nhật.
- Kiểm AI/visual provenance và disclosure.
- Kiểm tracking/CRM/SLA/suppression.
- Đặt severity và người sign-off.
- Theo dõi complaints, data health và downstream quality.
- Có rollback/incident plan.
Những sai lầm cần tránh
- Có số điện thoại rồi cho rằng được dùng cho mọi mục đích.
- Một checkbox gộp nhiều mục đích.
- Gửi database vào nhóm chat vì tiện.
- Dùng giá mồi hoặc scarcity không có nguồn.
- Dùng từ tuyệt đối mà không có evidence.
- Cho AI tự bịa hoặc tự publish claim.
- Tin CPL thấp mà bỏ contactability/SQL.
- Chỉ đọc platform dashboard khi nghi gian lận.
- Không có expiry date cho price/inventory claim.
- Không lưu bằng chứng và người phê duyệt.
Bài tập thực hành
- Audit một form thu lead BĐS.
- Thiết kế consent record theo từng mục đích.
- Thiết kế RBAC cho Marketing–Sales–Agency.
- Viết lại một mẫu quảng cáo giá mồi.
- Lập evidence pack cho 5 claim.
- Thiết kế AI pre-publish gate.
- Thiết kế fraud investigation checklist.
- Lập go/no-go board cho một campaign.
- Chẩn đoán case traffic cao ít lead.
- Chẩn đoán case CPL thấp quality kém.
Câu hỏi tự kiểm tra
- Dữ liệu này được thu để làm gì?
- Khách có thể hiểu khác với thông điệp không?
- Claim có nguồn, điều kiện và thời điểm không?
- Ai có quyền truy cập/xuất dữ liệu?
- AI đang hỗ trợ hay đang quyết định thay người?
- Nếu có khiếu nại, tôi truy được bằng chứng không?
Ghi nhớ trong 30 giây
- Số điện thoại là dữ liệu cá nhân cơ bản theo Nghị định 356/2025/NĐ-CP; vì vậy một form chỉ xin tên và số điện thoại vẫn là hoạt động xử lý dữ liệu cá nhân chứ không phải dữ liệu vô danh.
- Marketing nên bắt đầu từ mục đích: cần dữ liệu nào để gửi tài liệu, tư vấn, đặt lịch, phân loại nhu cầu hoặc thực hiện một hoạt động đã thông báo; không nên thu dữ liệu chỉ vì CRM có sẵn nhiều trường.
- Thông báo về xử lý dữ liệu cần đủ rõ để khách biết loại dữ liệu, mục đích, bên xử lý/kiểm soát liên quan, quyền của mình và cách liên hệ khi có yêu cầu.
- Form, landing page, chatbot, instant form, sự kiện offline và môi giới nhập tay đều phải được xem trong cùng data flow; rủi ro thường phát sinh khi dữ liệu được chuyển qua nhiều hệ thống mà không còn dấu vết mục đích.
- Quy trình tốt phải cho phép thực hiện các yêu cầu của chủ thể dữ liệu, kiểm soát quyền truy cập, ghi log, xử lý sự cố và dừng các workflow marketing khi dữ liệu không còn được phép sử dụng.
Nguồn tham khảo
- Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, có hiệu lực từ 01/01/2026.
- Nghị định số 356/2025/NĐ-CP quy định chi tiết một số điều và biện pháp thi hành Luật Bảo vệ dữ liệu cá nhân, có hiệu lực từ 01/01/2026.
- Luật sửa đổi, bổ sung một số điều của Luật Quảng cáo số 75/2025/QH15, có hiệu lực từ 01/01/2026.
- Nghị định số 87/2026/NĐ-CP quy định xử phạt vi phạm hành chính trong lĩnh vực văn hóa và quảng cáo, có hiệu lực từ 15/05/2026.
- Luật Bảo vệ quyền lợi người tiêu dùng số 19/2023/QH15 và Nghị định số 55/2024/NĐ-CP.
- Luật Kinh doanh bất động sản số 29/2023/QH15 và các văn bản sửa đổi, hướng dẫn có liên quan.
- NIST AI Risk Management Framework – tham khảo quản trị rủi ro AI, không thay thế pháp luật Việt Nam.
Bài tiếp theo: “Sự đồng ý của khách hàng nên được hiểu và ghi nhận thế nào?”.