Một cách hay để giảm thiểu rủi ro cho người dùng là không giữ dữ liệu nhạy cảm về họ mà bạn không cần đến vì điều này ảnh hưởng đến quyền riêng tư của họ. Có nhiều cách đáng ngạc nhiên để thực hiện điều này mà vẫn đạt được 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 lý do bạn cần dữ liệu.
- Thu thập dữ liệu ở mức độ chi tiết thấp hơn.
- Xoá dữ liệu sau khi sử dụng.
- Không thu thập dữ liệu đó ngay từ đầu.
Mỗi phương pháp trong số này đều có thể giúp người dùng cảm thấy thoải mái hơn với những gì bạn đang làm và lý do bạn làm như vậy. Điều này đóng góp rất lớn vào mối quan hệ của bạn với họ. Sự minh bạch tạo nên niềm tin và quan trọng là niềm tin có thể là một lợi điểm bán hàng duy nhất dành cho bạn. Nhiều người giả định rằng người dùng và khách hàng tin tưởng họ 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 phải là sự thật. Nếu bạn xây dựng mối quan hệ với người dùng để họ tin tưởng bạn xử lý dữ liệu và tương tác của họ một cách tôn trọng, thì điều này có thể mang lại lợi thế cạnh tranh cho bạn dưới dạng một dự án hoặc doanh nghiệp: đó là điều mà đối thủ của bạn có thể không làm được, một điểm khác biệt thực sự.
Hãy phân tích các phương pháp ở trên, theo thứ tự từ hiệu quả nhất (nhưng cũng có tác động lớn nhất đến doanh nghiệp của bạn) đến ít hiệu quả nhất nhưng ít gây gián đoạn nhất khi triển khai.
Không thu thập dữ liệu ngay từ đầu
Cách rõ ràng nhất để tránh gây ảnh hưởng đến quyền riêng tư của người dùng dữ liệu sẽ không được thu thập. 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 hơn bạn nghĩ mà bạn có thể tránh việc thu thập dữ liệu. Ví dụ: hãy xem xét hình thứ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 đơn hàng sau này: họ có thể được thêm vào danh sách gửi thư, họ đã được xác định trước là khách hàng quan tâm, v.v. Tuy nhiên, khách hàng nhận ra nhưng lại không thích: vào năm 2021, một nghiên cứu cho thấy cứ 4 lượt bán hàng bị bỏ qua thì có 1 người bị bỏ ngang là do trang web yêu cầu người dùng tạo một tài khoản. Nếu không yêu cầu khách hàng tạo tài khoản, bạn có nhiều khả năng giữ chân những khách hàng đó. Việc cho phép hoàn tất giao dịch mua mà không cần đăng ký sẽ mang đến cho người dùng nhiều lựa chọn hơn, đồng thời giúp bạn không phải bảo vệ và bảo mật nhiều dữ liệu của họ.
"Fuzz" dữ liệu của bạn
Tất nhiên, bạn không thể hoàn toàn không thu thập dữ liệu. Điều quan trọng là bạn phải thu thập dữ liệu để cung cấp dịch vụ và đảm bảo để đưa ra các quyết định kinh doanh hợp lý. Việc xây dựng nội dung truyền thông tiếp thị trong bối cảnh của một mối quan hệ tin cậy cũng có thể hữu ích. Tuy nhiên, bạn cũng cần nhận ra rằng các quyết định được đưa ra theo 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 theo 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, bạn nên nắm được thông tin nhân khẩu học của đối tượng: độ tuổi, 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. Tuy nhiên, đ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 tìm kiếm là xu hướng và thuộc tính tổng thể. Nếu quyết định mà bạn muốn bị ảnh hưởng bởi việc liệu hầu hết đối tượng của bạn có thuộc "đối tượng nhân khẩu học chính từ 18-34 tuổi" hay không, thì câu hỏi duy nhất bạn thực sự cần hỏi xem người dùng của bạn có thuộc nhóm nhân khẩu học đó hay không. Thao tác này sẽ thu thập các lượt chuyển đổi 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 hoàn toàn hợp lý khi lấy danh sách thông tin 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 mình theo danh sách đó.
Ví dụ:
Vì vậy, nếu cần biết cơ sở người dùng của bạn được phân chia như thế nào giữa các danh mục độ tuổi "18-34", "35-49", "49-64" và "65 trở lên", thì bạn có thể yêu cầu người dùng chọn danh mục mà họ thuộc về. Thường thì bạn nên yêu cầu cung cấp thông tin cực kỳ chi tiết, dữ liệu cá nhân và dữ liệu được cá nhân hoá, sau đó tự phân loại người dùng, vì điều này giúp tránh việc phải hỏi lại cùng một câu hỏi trong chi tiết hơn sau; ví dụ: yêu cầu tuổi và ngày sinh chính xác, sau đó sử dụng thông tin này để tạo danh sách của riêng bạn về cách nhiều người dùng nằm trong nhóm "35-49" danh mục. Nhưng điều quan trọng là phải nhận ra điều này trông như thế nào: vì khóa học này đã đề cập đến và sẽ đề cập lại một lần nữa, việc yêu cầu cấp dữ liệu chi tiết có thể khiến mọi người khó chịu và vì vậy 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 vẫn tăng thêm rủi ro.
Bạn cũng cần cân nhắc nhu cầu về dữ liệu. Đôi khi, "nhu cầu" về dữ liệu chi tiết hơn là suy đoán, một yêu cầu "phòng trường hợp". Có thể chúng ta chỉ cần phân loại người dùng thành 4 nhóm tuổi đó ngay bây giờ, nhưng trong tương lai, chúng ta có thể muốn hãy thu hẹp phạm vi đó và do đó chúng ta nên thu thập dữ liệu rất chi tiết ngay bây giờ để tiếp tục mở tuỳ chọn đó cho sau này. Có thể đáng để xem xét tần suất dữ liệu chi tiết hơn thực sự được sử dụng trước đây để đưa ra quyết định. Yêu cầu cung cấp dữ liệu được coi là xâm phạm có 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 tổ chức. Nếu dữ liệu đó được thu thập vì lý do "phòng trường hợp", thì có thể bạn không chỉ đang đánh đổi lòng tin của người dùng để giúp cải thiện các quyết định kinh doanh, nhưng đánh đổi nó chỉ đơn thuần vì có khả năng xảy ra một quyết định mang tính lý thuyết nào đó trong tương lai có thể không tồn tại, mà vẫn đảm bảo đáp ứng các yêu cầu về bảo mật đối với thông tin đó.
Ngoài ra, còn có các cách chi tiết hơn về thuật toán để giảm độ chi tiết của dữ liệu được thu thập. Phương pháp 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ác phương pháp này đã được sử dụng trong nhiều thập kỷ trong các ngành khoa học xã hội khi thu thập dữ liệu có thể 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. Chiến lược phát hành đĩa đơn phương pháp thu thập dữ liệu nêu trên bao gồm việc mở rộng câu trả lời của người dùng (vì vậy "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ệ nhất định người dùng nói dối về câu trả lời của họ. Nếu biết tỷ lệ người dùng trả lời không chính xác, thì bạn vẫn có thể rút ra kết luận có ý nghĩa từ dữ liệu đã thu thập, nhưng 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% khán giả vẫn cho biết họ thuộc nhóm nhân khẩu học từ 18 đến 34 tuổi, thì bạn có thể khá tự tin rằng đây vẫn là nhóm 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 đó câu trả lời chính xác luôn được yêu cầu nhưng phần mềm sẽ thay đổi một tỷ lệ phần trăm nhất định của câu trả lời 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 quy 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 phải tin rằng bạn sẽ không lạm dụng dữ liệu đã thu thập của họ, vì dữ liệu cá nhân là không đáng tin cậy.
Một quy trình tương tự nhưng phức tạp hơn về mặt kỹ thuật là sự riêng tư biệt lập. Phương pháp này sử dụng các kỹ thuật toán học để thay đổi bộ nhớ dữ liệu sao cho các thuộc tính tổng hợp của dữ liệu vẫn xuất hiện, nhưng bạn 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, hoặc nếu có thì đó là dữ liệu nào. Giống như câu trả lời ngẫu nhiên, tính năng này bảo vệ dữ liệu của người dùng ngay cả với bạn và thể hiện rõ ý định 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 đó.
Những phương pháp này và các phương pháp tương tự cũng giúp tăng cường bảo mật trước các sự cố rò rỉ và vi phạm dữ liệu, vì dữ liệu được thu thập sẽ giảm thiểu sự xâm phạm quyền riêng tư của người dùng, ngay cả đối với bạn, đồng thời 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 quyền riêng tư biệt lập trên máy chủ (tức là người dùng đang gửi cho bạn dữ liệu chưa tổng hợp, sau đó bạn sử dụng các kỹ thuật này để tổng hợp dữ liệu), 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ý. Ngoài ra, bạn phải 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 phải nêu rõ mục đích sử dụng dữ liệu đó).
Giữ lại: thu thập dữ liệu rồi xoá dữ liệu đó sau khi sử dụng
Bạn cần nhớ rằng dữ liệu được thu thập 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, sau đó, tại một thời điểm nào đó, dữ liệu đó sẽ bị xoá. Xin nhắc lại rằng đây là những sự đá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 theo dõi những nội dung mà họ đã xem và trong bao lâu để dự đoán về lựa chọn ưu tiên của họ, thì đây là dữ liệu được cấp cho bạn cho một mục đích cụ thể, chứ không phải là một khoản cấp phép mở để nhà phát triển sử dụng theo ý họ. Khi dữ liệu đó không còn cần thiết cho mục đích đó nữa (đôi khi sau một phút, đôi khi sau nhiều năm), bạn nên xoá dữ liệu đó.
Bất cứ khi nào thu thập thông tin về người dùng, bạn phải biết mình sẽ sử dụng dữ liệu đó cho mục đích gì (xem bên dưới) và bạn cũng phải biết thời điểm và lý do ngừng lưu giữ dữ liệu đó. Đây có thể là khi người dùng chọn xoá hoặc đăng nhập sau một khoảng thời gian cụ thể hay sau khi một sự kiện cụ thể diễn ra. Một cách tuyệt vời để xây dựng niềm tin trong mối quan hệ này là làm rõ cho người dùng cách họ có thể kiểm soát dữ liệu về mình, bao gồm cả việc chọn không tham gia một bên khi 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 như thế nào? Ngoài việc giúp xây dựng mối quan hệ đó, tốt nhất lưu trữ dữ liệu cho đến chừng nào bạn cần xử lý dữ liệu đó 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ề thời điểm này tại các lãnh thổ ở mà bạn vận hành.
Đây là phần bạn có thể xác định các mục tiêu kỹ thuật rõ ràng, giúp người dùng tự phục vụ; người dùng có thể chọn không tham gia kho dữ liệu của bạn mà không cần phải xin phép thì họ có thể cảm thấy thoải mái hơn rất nhiều khi chọn sử dụng và không sử dụng bất kỳ tài nguyên hỗ trợ nào để thực hiện việc này.
Điều quan trọng là phải hiểu được tầm quan trọng của chế độ chọn không chấp nhận dễ dàng và mặc định: "Để xây dựng niềm tin và sự công nhận, các công ty có thể bắt đầu bằng việc đồng ý với một hợp đồng xã hội, trong đó họ cam kết tôn trọng người xem ở 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 cho biết. The Nielsen Norman Group cho biết rằng người dùng "cần có một "lối thoát khẩn cấp" được đánh dấu rõ ràng để thoát 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 dễ đăng ký hơn là huỷ đăng ký. Nhưng, như Nielsen Nielsen cho biết, việc giúp người dùng có thể bỏ đi mà không phải 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 ủng hộ điều này và đặt tên cho nó là "nguyên tắc của khả năng 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 cấp chứng nhận mà người dùng đã cấp ở bất cứ đâu thu hồi được là có thể xảy ra. Người dùng phải rút lại được sự đồng ý đó, từ đó giảm bớt cơ quan có thẩm quyền truy cập vào tài nguyên của họ nếu có thể". (Xem ví dụ tại Yee và Iacono.)
Thời gian lưu giữ dữ liệu và loại dữ liệu cần lưu giữ là một chủ đề khác nhau rất nhiều 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 mà bạn có thể cân nhắc sử dụng.
Nên
Rất hữu ích ở đây 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à dữ liệu được lưu trữ cục bộ khi đăng xuất bằng tiêu đề Clear-Site-Data.
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ù trong cookie,
localStorage hoặc IndexedDB hoặc trong bộ nhớ đệm của trình duyệt), khi hợp lý. Trường hợp sử dụng rõ ràng nhất của Clear-Site-Data là khi người dùng đăng xuất, nhưng bạn cũng có thể sử dụng lệnh này sau các sự cố bảo mật để đảm bảo rằng tài khoản có thể bị xâm phạm không còn dấu vết nào của dữ liệu bị xâm phạm được lưu trữ trên máy khách.
Để hỗ trợ thêm cho Clear-Site-Data, bạn cần gửi tiêu đề HTTP Clear-Site-Data khi người dùng đăng xuất (hoặc tại
nhiều lần 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 HTTP khác được lưu vào bộ nhớ đệm), 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ợ tuỳ chọn này.
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ì cách này không yêu cầu mã JavaScript
chạy trên ứng dụng (và đó là cách chính thức duy nhất để xoá bộ nhớ đệm của trình duyệt), nhưng không phải trình duyệt nào cũng hỗ trợ.
Lưu ý về cách sử dụng: Nếu bạn đang xoá bộ nhớ đệm (bằng cách gửi Clear-Site-Data: cache), thì tiêu đề Clear-Site-Data không được gửi trên trang đăng xuất thực tế, mà phải gửi trên một số tài nguyên khác mà trang tải. Nguyên nhân là do trên một máy tính chậm hơn với bộ nhớ đệm lớn, trang sẽ bị chặn trong khi xoá bộ nhớ đệm và điều này ngăn việc điều hướng. Bạn có thể mất vài phút để thực hiện.
sẽ làm người dùng khó chịu. Điều này ít có khả năng xảy ra nhưng rất khó để thử nghiệm, do đó, tốt nhất bạn cần lưu ý đến điều này.
Giải thích lý do bạn cần dữ liệu
Chúng tôi đã nhiều lần nhấn mạnh 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, vì điều này giúp tăng thời gian sử dụng của người dùng. Điều 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 và để minh bạch, bạn nên giải thích mục đích của dữ liệu. Bạn đã biết rằng đối với mỗi dữ liệu đã thu thập, bạn nên biết khi nội dung đó bị xoá. Để làm được điều đó, bạn cần biết lý do mình muốn có dữ liệu này, câu hỏi cụ thể nào cần có dữ liệu để tìm 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, bạn đã hỏi bỏ cuộc, thì sẽ giúp xây dựng lòng tin bằng cách giải thích điều đó cho những người dùng đó. Trong chính sách quyền riêng tư 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, những việc bạn sẽ làm 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 được trình bày cùng dòng. An táng 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ư nỗ lực che giấu chúng. Biểu mẫu đăng ký, thanh toán hoặc yêu cầu có thể trình bày lý do nên thu thập dữ liệu cùng với việc 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 đó là trường bắt buộc; biểu mẫu phức tạp thường có đường liên kết thông tin (i) để giải thích ý nghĩa của trường này. Hãy cân nhắc việc thêm nội dung mô tả về lý do thu thập dữ liệu vào những nội dung giải thích này. Một cụm từ thường dùng cho việc này là "Tại sao chúng ta cần điều này?" bên cạnh một trường biểu mẫu. Khi nhấp vào trường này, một cửa sổ bật lên sẽ hiển thị nội dung giải thích.
Một số ví dụ về HTML có thể có dạng như sau, sau đó CSS và JavaScript sẽ đảm nhận việc ẩn <aside> và hiển thị dưới dạng cửa sổ bật lên khi
đường liên kết được nhấp vào. (Hãy nhớ xác nhận khả năng truy cập vào biểu mẫu mà bạn tạo cho trang web của mình!)
Cách bố trí chính xác phụ thuộc vào phong cách và phương pháp tiếp cận của bạn, nhưng điểm chính ở đây là liên kết trực tiếp hoạt động thu thập dữ liệu với
nội dung giải thích lý do dữ liệu đó được thu thập. Bạn không cần phải nhập thông tin này vào mọi trường. Không ai cần được giải thích lý do bạn yêu cầu họ
chọn một mật khẩu khi đăng ký. Tuy nhiên, việc trang trí mỗi yêu cầu bằng thông tin cá nhân và thông tin liên hệ theo cách bạn dự định sử dụng và lưu giữ thông tin đó có thể hữu ích
cho người dùng biết rõ rằng bạn quan tâm đến 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 xem xét mọi thông tin bạn thu thập được về một người dùng trong quy trình này cũng có thể giúp ích cho các quy trình và thảo luận nội bộ. Trước đó, bạn đã thấy việc thu thập dữ liệu "để phòng trường hợp" có thể gây ra sự cám dỗ. Khi bạn minh bạch về lý do thu thập dữ liệu, người dùng có thể dễ dàng nhận ra điều này. Nếu bạn không muốn công khai những việc bạn muốn làm với dữ liệu người dùng vì người dùng sẽ không thích nội dung giải thích đó, thì đây có thể là 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. Điều này áp dụng cho trường hợp lời giải thích gây khó chịu có quá xâm phạm hay không ("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 tính năng này cho mục đích gì nhưng chúng tôi muốn sử dụng trong trường hợp có ý tưởng sử dụng nó") hoặc quá lẩn tránh ("chúng tôi sẽ sử dụng thông tin này cho các mục đích nội bộ không được tiết lộ"). Đây không chỉ là câu hỏi về đạo đức; mọi người có đủ hiểu biết để nhận ra điều này, như đã mô tả, và người dùng đều kỳ vọng rằng việc thử nghiệm với một điều gì đó không phải là bước đầu của một cam kết lâu dài. Một nguyên tắc phổ biến trong thiết kế trải nghiệm người dùng là giúp quá trình đăng ký diễn ra dễ dàng và suôn sẻ nhất có thể, vì ở giai đoạn đầu, người dùng (theo định nghĩa) chưa đầ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ọ dễ dàng đầu tư nhiều hơn khi họ chưa có nhiều ý định làm như vậy. Nếu việc rời bỏ dịch vụ cũng dễ dàng như vậy, thì việc thử nghiệm dịch vụ sẽ trở thành một thử nghiệm thực sự chứ không phải là sự bắt đầu miễn cưỡng của một cam kết dài hạn bắt buộc. Như trước đây, nghịch lý nhưng đúng là cách tốt nhất để tạo dựng lòng tin là không yêu cầu người dùng tin bạn nếu họ làm vậy không muốn.
Mọi người có lý do chính đáng để không chia sẻ dữ liệu hoặc chỉ chia sẻ dữ liệu tối thiểu. Khi mới bắt đầu mối quan hệ với bạn, họ có thể không có lý do để tin tưởng bạn và cũng không cần phải tin tưởng bạn. Mục tiêu của bạn là chứng minh lý do họ nên.
Nên
- Quyết định lý do bạn muốn thu thập tất cả dữ liệu mà bạn dự định thu thập và thời gian bạn sẽ 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 lý do bạn thu thập dữ liệu.
- Hãy xoá 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á những tài khoản họ đã tạo và xoá dữ liệu lưu trữ khỏi bộ nhớ của họ qua tiêu đề
Clear-Site-Data.
Lý do
Mối quan hệ với người dùng được xây dựng dựa trên lòng tin, và lòng tin được xây dựng dựa trên sự cởi mở. Nếu bạn có thể chứng minh rằng mình không chỉ thu thập càng nhiều dữ liệu về người dùng càng tốt 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ể sẽ là lợi thế cạnh tranh cho bạn trước các đối thủ ít khắt khe hơn.