Một cách hữu ích để giảm thiểu rủi ro cho người dùng là không giữ lại những dữ liệu nhạy cảm về họ nếu bạn không cần những dữ liệu đó ảnh hưởng đến quyền riêng tư của họ. Có vô số cách đáng ngạc nhiên để làm việc này trong khi vẫn đáp ứng mục tiêu kinh doanh của bạn và bạn nên cân nhắc từng cách. Bạn có thể:
- Giải thích mục đích của dữ liệu.
- Thu thập dữ liệu ở độ chi tiết thấp hơn.
- Xoá dữ liệu đã sử dụng.
- Không thu thập dữ liệu ngay từ đầu.
Mỗi cách tiếp cận trong số này có thể giúp người dùng cảm thấy thoải mái hơn với việc bạn đang làm cũng như lý do bạn làm, đồng thời điều này góp phần đáng kể vào mối quan hệ giữa bạn và họ. Sự minh bạch sẽ tạo nên lòng tin. Quan trọng là lòng tin có thể là một lợi điểm bán hàng dành riêng cho bạn. Nhiều người cho rằng người dùng và khách hàng tin tưởng các sản phẩm và dịch vụ theo mặc định nhưng người tiêu dùng liên tục đánh giá các sản phẩm và dịch vụ và điều này có thể không đúng. Nếu bạn xây dựng mối quan hệ với người dùng mà họ tin tưởng để bạn xử lý dữ liệu và hoạt động tương tác của họ, thì điều đó có thể mang lại lợi thế cạnh tranh cho bạn với tư cách là một dự án hoặc doanh nghiệp: đó là thứ mà đối thủ của bạn có thể không sánh được, là một điểm khác biệt thực sự.
Hãy khám phá các phương pháp trên, theo thứ tự hiệu quả nhất (nhưng cũng gây ảnh hưởng nhiều nhất đến doanh nghiệp của bạn) cho đến cách triển khai kém hiệu quả nhất nhưng ít gây phiền toái nhất.
Đừng thu thập thông tin ngay từ đầu
Cách rõ ràng nhất để tránh ảnh hưởng đến dữ liệu của người dùng là không thu thập dữ liệu đó. Một số hoạt động thu thập dữ liệu là cần thiết để cung cấp dịch vụ, nhưng có nhiều nơi bạn có thể tránh thu thập dữ liệu hơn bạn nghĩ. Ví dụ: hãy xem xét việc thanh toán không cần đăng nhập. Khi người dùng mua hàng bằng ứng dụng web của bạn, bạn có thể yêu cầu họ đăng ký tài khoản, vì sau đó bạn đã thu thập thông tin cá nhân để thực hiện sau này: họ có thể được thêm vào danh sách gửi thư, họ đã đủ điều kiện trước tiên với tư cách là khách hàng quan tâm, v.v. Tuy nhiên, khách hàng nhận ra và không thích điều này: vào năm 2021, một nghiên cứu cho thấy 1/4 giao dịch bán hàng bị bỏ dở là do trang web yêu cầu người dùng tạo tài khoản. Nếu không cần tài khoản, bạn có nhiều khả năng giữ chân những khách hàng đó hơn. Việc cho phép hoàn tất giao dịch mua mà không cần đăng ký mang lại cho người dùng những lựa chọn tốt hơn và cũng có nghĩa là bạn không có nhiều dữ liệu của họ để bảo vệ và an toàn.
"Làm mờ" dữ liệu
Tất nhiên, việc tránh thu thập dữ liệu hoàn toàn có thể không phải là lựa chọn. Điều quan trọng là phải thu thập dữ liệu để cung cấp dịch vụ và đưa ra các quyết định kinh doanh hợp lý. Việc xây dựng nội dung tiếp thị trong bối cảnh đang xây dựng mối quan hệ đáng tin cậy cũng có thể hữu ích. Tuy nhiên, bạn cũng cần phải nhận ra rằng các quyết định được đưa ra ở dạng tổng hợp (tức là ảnh hưởng đến nhiều người dùng cùng một lúc) được đưa ra về dữ liệu ở dạng tổng hợp (tức là về các thuộc tính tập thể của dữ liệu).
Ví dụ: đôi khi sẽ rất hữu ích khi nắm được thông tin nhân khẩu học của đối tượng: nhóm tuổi của họ, vị trí, v.v. Điều này có thể thay đổi thông điệp hoặc cách tiếp cận của bạn. Nhưng điều này không có nghĩa là bạn cần thu thập độ tuổi chính xác của mọi người dùng dịch vụ. Những gì bạn thường xem là các xu hướng và tài sản tổng thể. Nếu quyết định mà bạn muốn tiếp cận bị ảnh hưởng bởi việc hầu hết đối tượng của bạn có thuộc "nhóm nhân khẩu học quan trọng từ 18 đến 34 tuổi" hay không, thì câu hỏi duy nhất mà bạn thực sự cần đặt ra là liệu người dùng của bạn có thuộc nhóm nhân khẩu học đó hay không. Cách thức này tập hợp chúng thành hai "nhóm": trong nhóm đó chứ không phải trong nhóm đó. Có thể có những trường hợp bạn cần dữ liệu chi tiết hơn, nhưng bạn nên lấy danh sách nhân khẩu học mà bạn sử dụng để đưa ra quyết định và yêu cầu người dùng tự phân loại theo danh sách đó.
Ví dụ:
Vì vậy, nếu bạn cần biết cách phân chia cơ sở người dùng của mình giữa các danh mục "18-34", "35-49", "49-64" và "65 tuổi trở lên", bạn có thể yêu cầu người dùng chọn họ thuộc những danh mục nào trong số đó. Bạn nên yêu cầu dữ liệu cực kỳ chi tiết, cá nhân và được cá nhân hoá, sau đó tự phân loại người dùng, vì điều này sẽ tránh phải hỏi lại một câu hỏi chi tiết hơn về sau; ví dụ: hỏi độ tuổi và ngày sinh chính xác, sau đó sử dụng thông tin này để tạo danh sách riêng của bạn về số lượng người dùng trong danh mục "35-49". Tuy nhiên, điều quan trọng là phải nhận thức được vấn đề này: vì khoá học đã được đề cập và sẽ đề cập lại, nên việc yêu cầu cấp dữ liệu chi tiết có thể khiến mọi người không thoải mái, từ đó làm giảm niềm tin của người dùng đối với tổ chức của bạn, đồng thời có thể tăng rủi ro.
Bạn cũng nên xem xét nhu cầu về dữ liệu của mình. Đôi khi, "nhu cầu" đối với dữ liệu chi tiết hơn chỉ mang tính suy đoán và là yêu cầu "chỉ trong trường hợp". Có thể chúng ta chỉ cần phân loại người dùng vào 4 nhóm tuổi đó ngay bây giờ, nhưng trong tương lai, chúng ta có thể thu hẹp phạm vi đó và do đó, chúng ta nên thu thập dữ liệu thật chi tiết ngay bây giờ để duy trì lựa chọn đó cho sau này. Bạn nên xem xét tần suất dữ liệu chi tiết hơn đã thực sự được dùng trước đây để định hướng cho các quyết định. Việc yêu cầu dữ liệu bị coi là xâm phạm liên quan đến dịch vụ được cung cấp nhất thiết sẽ làm giảm mức độ tin tưởng của người dùng đối với tổ chức của bạn. Nếu dữ liệu đó được thu thập vì lý do "chỉ trong trường hợp cần thiết", thì bạn không chỉ đánh đổi lòng tin của người dùng để có được các quyết định kinh doanh được cải thiện mà chỉ đơn thuần đánh đổi để có thể một quyết định về mặt lý thuyết nào đó trong tương lai có thể sẽ không tồn tại, trong khi vẫn đáp ứng các yêu cầu về bảo mật cho thông tin đó.
Ngoài ra, còn có những cách chi tiết hơn bằng thuật toán để giảm mức độ chi tiết của dữ liệu được thu thập. Các phương thức phản hồi ngẫu nhiên có nghĩa là dữ liệu được thu thập với mức độ không chính xác có thể điều chỉnh được và đã được sử dụng trong nhiều thập kỷ trong khoa học xã hội khi thu thập dữ liệu có khả năng xâm phạm hoặc nhạy cảm trong khi vẫn duy trì tính bảo mật của người trả lời. Phương pháp thu thập dữ liệu trên bao gồm việc mở rộng câu trả lời của người dùng (tức là "bạn bao nhiêu tuổi" trở thành "bạn thuộc nhóm tuổi nào sau đây"), trong đó câu trả lời ngẫu nhiên liên quan đến việc có một tỷ lệ người dùng nhất định nói dối về câu trả lời của họ. Nếu xác định được tỷ lệ người dùng trả lời không chính xác, thì kết luận có ý nghĩa vẫn có thể được rút ra từ dữ liệu đã thu thập. Tuy nhiên, quyền riêng tư của từng người dùng sẽ không bị xâm phạm vì dữ liệu được thu thập có thể không chính xác. Trong trường hợp này, nếu 80% đối tượng của bạn vẫn cho rằng họ thuộc nhóm nhân khẩu học 18-34, thì bạn có thể tương đối tự tin rằng đây vẫn là tỷ lệ lớn nhất, ngay cả khi 10% trong số đó cố tình đưa ra câu trả lời không chính xác. Mức độ không chính xác cũng có thể được thay đổi theo phương thức lập trình, trong đó, hệ thống luôn yêu cầu câu trả lời chính xác nhưng phần mềm sẽ thay đổi một tỷ lệ câu trả lời nhất định trước khi truyền. Bạn cũng có thể giải thích cho người dùng về quy trình này và hậu quả của quá trình này khi thu thập dữ liệu. Điều này có nghĩa là người dùng không cần phải tin tưởng rằng bạn sẽ không lạm dụng dữ liệu đã thu thập của họ, vì từng dữ liệu không đáng tin cậy.
Một quy trình tương tự nhưng tốn nhiều kỹ thuật hơn là quy trình sự riêng tư biệt lập. Phương thức này sử dụng các kỹ thuật toán học để thay đổi cách lưu trữ dữ liệu để các thuộc tính tổng hợp của dữ liệu vẫn hiện diện, nhưng thậm chí không thể biết liệu một cá nhân cụ thể có cung cấp dữ liệu hay không hay họ đã cung cấp dữ liệu nào. Giống như phản hồi ngẫu nhiên, phương thức này bảo vệ dữ liệu của người dùng ngay cả đối với bạn và thể hiện ý định rõ ràng của bạn: bạn không thể sử dụng dữ liệu của người dùng nếu không có dữ liệu đó.
Các phương pháp này và các phương pháp tương tự cũng giúp tăng cường mức độ bảo mật trước các sự cố rò rỉ và rò rỉ dữ liệu, vì dữ liệu được thu thập ít ảnh hưởng đến quyền riêng tư của người dùng (ngay cả với bạn) và cũng sẽ giảm mức độ xâm phạm nếu dữ liệu bị rò rỉ. Tuy nhiên, hãy nhớ rằng nếu đang áp dụng các kỹ thuật sự riêng tư biệt lập trên máy chủ (để người dùng gửi cho bạn dữ liệu chưa tổng hợp rồi bạn sử dụng các kỹ thuật để tổng hợp dữ liệu), thì bạn vẫn cần bảo mật dữ liệu người dùng thô đó rồi xoá dữ liệu đó sau khi xử lý, đồng thời nên có và tuân thủ các chính sách rõ ràng để xác nhận rằng bạn không sử dụng dữ liệu trước khi tổng hợp (hoặc bạn phải rõ ràng về mục đích sử dụng).
Lưu giữ: thu thập dữ liệu rồi xoá dữ liệu sau khi sử dụng
Điều hữu ích bạn cần nhớ là dữ liệu được thu thập đều có vòng đời; dữ liệu được thu thập, được dùng để giúp bạn đưa ra quyết định kinh doanh và sau đó, vào một thời điểm nào đó, dữ liệu này sẽ bị xoá. Một lần nữa, đây là những yếu tố đánh đổi: khi bạn đặt câu hỏi cho người dùng hoặc lưu trữ thông tin về các trang web khác mà họ đã truy cập, hoặc bạn theo dõi nội dung họ đã xem và thời gian dự đoán để đưa ra dự đoán về sở thích của họ, đây là dữ liệu được cấp cho bạn cho một mục đích cụ thể chứ không phải như một khoản tiền mở để nhà phát triển sử dụng khi họ thấy phù hợp. Khi không còn cần đến dữ liệu đó cho mục đích đó, dữ liệu đó sẽ bị xoá sau một phút hoặc sau nhiều năm.
Bất cứ khi nào thu thập thông tin về người dùng, bạn nên biết mình sẽ sử dụng dữ liệu đó cho mục đích gì (xem bên dưới), đồng thời, bạn cũng phải biết khi nào và tại sao mình sẽ ngừng lưu giữ dữ liệu đó. Đây có thể là khi người dùng chọn xoá sự kiện hoặc khi họ đăng xuất, sau một khoảng thời gian cụ thể hoặc sau khi một sự kiện cụ thể diễn ra. Một cách hiệu quả để tạo dựng niềm tin trong mối quan hệ là giúp người dùng hiểu rõ cách họ có thể kiểm soát dữ liệu về họ, bao gồm cả việc đơn phương chọn không tham gia nếu có thể. Họ xoá dữ liệu của mình bằng cách nào? Họ xoá tài khoản của mình bằng cách nào? Ngoài việc giúp xây dựng mối quan hệ đó, tốt nhất bạn nên lưu trữ dữ liệu trong thời gian cần thiết phải xử lý và không lâu hơn, đồng thời phải có cách để người dùng xem và xoá dữ liệu mà bạn thu thập từ họ hoặc thay mặt họ. Thậm chí, có thể có luật về điểm này tại các lãnh thổ mà bạn hoạt động.
Đây là lĩnh vực mà bạn có thể xác định mục tiêu rõ ràng về mặt kỹ thuật để giúp người dùng tự phục vụ; nếu người dùng có thể chọn không sử dụng kho dữ liệu của bạn mà không phải xin phép, thì họ sẽ cảm thấy thoải mái hơn nhiều khi chọn tham gia và không cần bất kỳ tài nguyên hỗ trợ nào để làm như vậy.
Điều quan trọng là phải nhận thức được tầm quan trọng của việc chọn không tham gia theo cách dễ dàng và mặc định: "Để tạo dựng lòng tin và sự ghi nhận, các công ty có thể bắt đầu bằng cách đồng ý với một hợp đồng xã hội, trong đó họ cam kết tôn trọng đối tượng của mình ở mọi điểm tiếp xúc, lắng nghe nhu cầu của họ và phản hồi cho phù hợp", IAPP có nêu rõ. The Nielsen Norman Group rằng người dùng "cần được đánh dấu rõ ràng là "thoát khẩn cấp" để rời khỏi hành động không mong muốn mà không phải trải qua một quy trình kéo dài". Mọi người đều biết rằng đăng ký sẽ dễ dàng hơn là huỷ đăng ký. Tuy nhiên, như Nielsen Norman cho biết, việc giúp người dùng có thể rời đi mà không phải nhảy qua những chiếc vòng, "thúc đẩy cảm giác tự do và tự tin". Các nghiên cứu học thuật đã chứng minh điều này và đặt tên cho vấn đề này là "nguyên tắc thu hồi", nêu rõ: "Giao diện phải cho phép người dùng dễ dàng thu hồi các cơ quan chức năng mà người dùng đã cấp ở bất cứ khi nào có thể thu hồi. Người dùng phải thu hồi được sự đồng ý đó và do đó giảm số lượng quyền truy cập vào tài nguyên của họ nếu có thể." (Xem ví dụ về Yee và Iacono.)
Khoảng thời gian lưu giữ dữ liệu và loại dữ liệu cần lưu giữ là một chủ đề có sự khác biệt rất lớn giữa các tổ chức và giữa các dự án, nhưng có một số nguyên tắc chung cần cân nhắc.
Nên
Sẽ hữu ích khi cho phép người dùng xoá tài khoản (và mọi dữ liệu liên quan nếu có thể) và thường xuyên (ví dụ: khi đăng xuất) xoá dữ liệu tạm thời và được lưu trữ cục bộ khi đăng xuất bằng tiêu đề Xoá dữ liệu trang web.
Cung cấp tiêu đề Clear-Site-Data để xoá một số hoặc tất cả dữ liệu người dùng đã được lưu trữ phía máy khách (cho dù là trong cookie, localStorage hay IndexedDB hoặc trong bộ nhớ đệm của trình duyệt), khi phù hợp. Trường hợp sử dụng rõ ràng của tính năng Xoá dữ liệu trang web là khi người dùng đăng xuất. Tuy nhiên, bạn cũng có thể sử dụng dữ liệu này sau sự cố bảo mật để đảm bảo rằng tài khoản có khả năng bị xâm phạm không có dấu vết còn lại của dữ liệu bị xâm phạm được lưu trữ trên máy khách.
Việc thêm tính năng hỗ trợ cho Clear-Site-Data bao gồm việc gửi tiêu đề HTTP Clear-Site-Data, khi người dùng đăng xuất (hoặc vào những thời điểm khác khi bạn muốn xoá bộ nhớ phía máy khách), trên trang xác nhận trạng thái đăng xuất (https://your-site/logout hoặc tương tự). Tiêu đề này có thể có một số hoặc tất cả các giá trị sau đây hoặc "*" cho tất cả:
Clear-Site-Data: "cache", "cookies", "storage"
Các giá trị này lần lượt xoá các trang được lưu vào bộ nhớ đệm (và các tài nguyên khác được lưu vào bộ nhớ đệm của HTTP), cookie được lưu trữ, localStorage và IndexedDB và các giá trị tương tự.
Bạn có thể thấy nội dung tham chiếu đến một tuỳ chọn khác là executionContexts, nhưng nhiều trình duyệt không hỗ trợ lựa chọn này.
Xin lưu ý rằng việc sử dụng tiêu đề Clear-Site-Data có thể sẽ dễ dàng hơn so với việc tự xoá từng tài nguyên đã tạo, vì tiêu đề này không yêu cầu chạy mã JavaScript trên ứng dụng (và đây là cách chính thức duy nhất để xoá bộ nhớ đệm của trình duyệt), nhưng không được tất cả trình duyệt hỗ trợ.
Lưu ý về cách sử dụng: Nếu bạn xoá bộ nhớ đệm (bằng cách gửi Clear-Site-Data: cache), thì tiêu đề Clear-Site-Data sẽ không được gửi trên trang đăng xuất thực tế của bạn mà sẽ tải trên một số tài nguyên khác. Nguyên nhân là do trên một máy tính chậm hơn có bộ nhớ đệm lớn, trang sẽ chặn trong khi xoá bộ nhớ đệm và điều này ngăn cản hoạt động điều hướng. Việc này có thể mất vài phút và sẽ gây khó chịu cho người dùng. Điều này ít có khả năng xảy ra nhưng rất khó kiểm thử, do đó, tốt nhất bạn nên lưu ý điều này.
Giải thích lý do bạn cần dữ liệu
Tầm quan trọng của niềm tin trong mối quan hệ giữa người dùng với dịch vụ của bạn đã được nhiều lần nêu ra vì điều này giúp kéo dài tuổi thọ của người dùng. Việc này cũng mang lại lợi thế cạnh tranh. Một cách để tăng mức độ tin cậy đó là minh bạch về các quy trình của bạn. Một cách hay để minh bạch là giải thích bạn muốn dữ liệu cho mục đích gì. Bạn đã biết trước đó rằng đối với mỗi dữ liệu được thu thập, bạn sẽ biết khi nào dữ liệu đó sẽ bị xoá. Để biết được điều đó, bạn cần biết lý do bạn cần dữ liệu này, những câu hỏi cụ thể nào cần có dữ liệu để tìm ra câu trả lời và quyết định nào sẽ được hướng dẫn bằng cách thu thập dữ liệu. Sau khi biết lý do bạn cần dữ liệu này mà bạn đã yêu cầu người dùng từ bỏ, bạn sẽ tạo dựng được niềm tin bằng cách giải thích điều đó với những người dùng đó. Trong chính sách quyền riêng tư của bạn hoặc khi đặt câu hỏi về việc tạo tài khoản, hãy mô tả lý do bạn cần câu trả lời cho câu hỏi cụ thể này, bạn sẽ làm gì với dữ liệu đó, cũng như thời điểm và cách xoá dữ liệu.
Những nội dung giải thích này sẽ dễ thấy hơn khi trình bày cùng dòng. Việc che giấu các nội dung giải thích trong một tài liệu chính sách dày đặc ở nơi khác trên trang web có thể giống như một nỗ lực nhằm ẩn những nội dung đó. Biểu mẫu đăng ký, thanh toán hoặc yêu cầu có thể trình bày lý do cần thu thập dữ liệu cùng với chính quá trình thu thập. Thông thường, một trường biểu mẫu có thể có dấu hoa thị (*) để cho biết rằng một trường là bắt buộc; các biểu mẫu phức tạp thường có một đường liên kết thông tin (i) để giải thích ý nghĩa của trường đó. Hãy cân nhắc thêm nội dung mô tả về lý do dữ liệu được thu thập vào những phần giải thích này. Cụm từ thường dùng cho vấn đề này là "Tại sao chúng tôi cần điều này?" bên cạnh một trường trên biểu mẫu. Khi người dùng nhấp vào trường này, trường này sẽ hiển thị lời giải thích bật lên.
Một số HTML mẫu có thể có dạng như sau, sau đó CSS và JavaScript sẽ đảm nhiệm việc ẩn <aside> và hiển thị dưới dạng cửa sổ bật lên khi người dùng nhấp vào đường liên kết. (Hãy nhớ xác nhận khả năng truy cập của biểu mẫu mà bạn tạo cho trang web của mình!)
Cách bố trí chính xác tuỳ thuộc vào kiểu và phương pháp của bạn, nhưng điểm chính ở đây là liên kết trực tiếp việc thu thập dữ liệu với phần giải thích lý do tại sao dữ liệu đó được thu thập. Điều này không cần thiết cho mọi trường. Không ai cần giải thích lý do bạn yêu cầu họ
chọn mật khẩu khi đăng ký. Tuy nhiên, việc trình bày rõ từng yêu cầu cung cấp thông tin cá nhân và thông tin liên hệ sao cho phù hợp với cách bạn dự định sử dụng và lưu giữ thông tin đó có thể giúp
người dùng hiểu rõ rằng bạn đã đầu tư vào việc bảo vệ dữ liệu của họ.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
Việc thực hiện quy trình này cùng với mọi thông tin thu thập được về người dùng cũng có thể giúp ích cho các quy trình và cuộc thảo luận nội bộ. Trước đó, bạn đã thấy rằng mọi người có thể bị cám dỗ thu thập dữ liệu "trong trường hợp cần đến". Khi bạn minh bạch về lý do thu thập, có thể khá rõ ràng là điều này đang xảy ra. Nếu miễn cưỡng phải viết ra công khai những gì bạn muốn làm với dữ liệu người dùng vì những người dùng đó không thích nội dung giải thích, thì đây có thể là một dấu hiệu cho thấy bạn nên cân nhắc lại việc thu thập dữ liệu này. Điều này có thể áp dụng cho dù nội dung giải thích gây khó chịu đó là quá xâm phạm ("chúng tôi sẽ sử dụng thông tin này để theo dõi nơi bạn truy cập hằng giờ"), quá rộng ("chúng tôi chưa biết sẽ sử dụng giải thích này cho mục đích gì nhưng chúng tôi muốn sử dụng trong trường hợp chúng tôi nghĩ ra điều gì đó vì lý do đó") hay quá né tránh ("chúng tôi sẽ sử dụng giải thích này cho mục đích nội bộ chưa công bố"). Đây không chỉ đơn giản là câu hỏi về đạo đức; mọi người đủ hiểu biết để nhận ra điều này, như đã mô tả và người dùng kỳ vọng rằng việc thử nghiệm điều gì đó không phải là khởi đầu của một cam kết lâu dài. Việc thiết kế trải nghiệm người dùng là dễ dàng và dễ dàng nhất có thể, vì ở giai đoạn đầu, người dùng (theo định nghĩa) không đầu tư nhiều vào dịch vụ của bạn. Vì vậy, điều quan trọng là cho phép họ đầu tư dễ dàng hơn khi họ vẫn chưa có khuynh hướng làm như vậy. Nếu rời đi một lần nữa, thì việc thử nghiệm với dịch vụ sẽ trở thành thử nghiệm chính xác chứ không phải là bắt đầu một cách ép buộc Như trước đây, thật là nghịch lý nhưng khi nói rằng cách tốt nhất để xây dựng niềm tin là không bắt buộc người dùng tin tưởng bạn nếu họ không muốn.
Mọi người có lý do chính đáng để không chia sẻ dữ liệu hoặc chia sẻ ít dữ liệu. Khi bạn bắt đầu mối quan hệ với họ, có thể họ không có lý do để tin tưởng bạn và không nhất thiết phải tin tưởng bạn. Mục tiêu của bạn là giải thích lý do chúng nên có.
Nên
- Quyết định tất cả dữ liệu bạn dự định thu thập vì lý do bạn muốn thu thập và khoảng thời gian lưu giữ dữ liệu đó.
- Khi bạn yêu cầu dữ liệu đó, hãy giải thích cho người dùng về lý do bạn thu thập dữ liệu.
- Xoá dữ liệu đó khỏi cơ sở dữ liệu máy chủ của bạn sau khi sử dụng.
- Cho phép người dùng xoá tài khoản mà họ đã tạo và xoá dữ liệu được lưu trữ khỏi bộ nhớ thông qua tiêu đề
Clear-Site-Data.
Lý do
Xây dựng mối quan hệ với người dùng là để xây dựng lòng tin, còn lòng tin chính là sự cởi mở. Nếu có thể chứng minh rằng bạn không chỉ thu thập nhiều dữ liệu nhất có thể về người dùng và che giấu việc sử dụng dữ liệu đó, thì điều đó sẽ giúp tạo dựng lòng tin. Điều này có thể mang lại lợi thế cạnh tranh cho bạn so với những đối thủ ít kỹ lưỡng hơn.