Chỉ sử dụng dữ liệu cần thiết

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 mục đích bạn cần dữ liệu.
  • Thu thập dữ liệu ở độ chi tiết thấp hơn.
  • Xoá dữ liệu sau khi sử dụng.
  • Không thu thập thông tin ngay từ đầu.

Mỗi phương pháp trong số này có thể giúp người dùng cảm thấy thoải mái hơn với những việc bạn đang làm và lý do bạn làm. Điều này góp phần rất lớn đến 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, nơi họ tin tưởng bạn sẽ xử lý dữ liệu và hoạt động tương tác của bạn về khía cạnh này, công cụ này có thể mang lại lợi thế cạnh tranh cho bạn trong vai trò là một dự án hoặc doanh nghiệp: đó là điều mà các đối thủ của bạn có thể không phải là đ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 thông tin ở vị trí đầu tiên

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. Việc 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 việc thu thập dữ liệu hơn bạn nghĩ. Hãy xem xét một số ví dụ về quy trình thanh toán không cần đăng nhập. Khi người dùng sử dụng ứng dụng web của bạn để mua hàng, bạn có thể yêu cầu họ đăng ký một 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 đủ điều kiện trước thành khách hàng quan tâm, v.v. Tuy nhiên, khách hàng nhận ra nhưng 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 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 có thể hoàn tất giao dịch mua mà không cần đăng ký sẽ giúp cho người dùng nhiều lựa chọn hơn và điều đó cũng có nghĩa là bạn không có nhiều dữ liệu của họ để bảo vệ và bảo mật.

"Fuzz" dữ liệu của bạn

Tất nhiên, có lẽ bạn không thể tránh thu thập dữ liệu. Google cần 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 thông tin 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 hiểu rằng các quyết định được đưa ra ở dạng tổng hợp (ảnh hưởng đến nhiều người dùng cùng một lúc) sẽ được đưa ra về dữ liệu được tổng hợp (tức là về thuộc tính tập hợp 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 khán giả: họ thuộc nhóm tuổi nào, 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 chính xác độ tuổi của mỗi người dùng dịch vụ của bạn. 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 thế, nhưng việc sử dụng danh sách nhân khẩu học là hoàn toàn hợp lý 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 họ theo danh sách đó.

Ví dụ:

Vì vậy, nếu biết cách phân chia cơ sở người dùng theo các nhóm độ tuổi như "18-34", "35-49", "49-64" và "65 tuổi trở lên", thì bạn có thể yêu cầu người dùng chọn xem họ thuộc danh mục nào trong số đó. 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 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 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" để có dữ liệu chi tiết hơn chỉ mang tính suy đoán, "chỉ trong 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 xem 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ó nhiều phương pháp chi tiết hơn dựa trên thuật toán giúp giảm độ chi tiết của dữ liệu được thu thập. 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 và chúng đã được sử dụng hàng thập kỷ trong môi trường mạng xã hội khoa học khi thu thập dữ liệu có khả năng xâm phạm hoặc nhạy cảm, đồng thời vẫn đảm bảo tính bí mật cho 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 xác định được tỷ lệ người dùng trả lời không chính xác, thì bạn có thể đưa ra kết luận có ý nghĩa vẫn có thể được lấy từ dữ liệu đã thu thập, nhưng quyền riêng tư của người dùng cá nhân không bị xâm phạm vì dữ liệu mà họ thu thập có thể không chính xác. Trong trường hợp này, nếu 80% khán giả của bạn vẫn cho biết rằng họ thuộc độ tuổi từ 18 đến 34, thì bạn có thể tương đối tự tin rằng đây vẫn là thị phần lớn nhất, ngay cả khi 10% trong số đó đang cố ý đư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ể thay đổi theo chương trình, trong đó câu trả lời đúng luôn được hỏi nhưng phần mềm thay đổi một tỷ lệ phần trăm nhất định các câu trả lời trước khi truyền. Quá trình này và kết quả của nó cũng có thể được giải thích cho người dùng khi dữ liệu được thu thập: điều đó có nghĩa là người dùng không phải tin rằng bạn sẽ không lạm dụng do dữ liệu cá nhân không đáng tin cậy.

Một quy trình tương tự nhưng có liên quan nhiều 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 cách lưu trữ dữ liệu sao cho các thuộc tính tổng hợp của dữ liệu vẫn tồn tại, nhưng thậm chí không thể cho biết liệu một cá nhân cụ thể có cung cấp dữ liệu hay không hoặc liệu họ đã cung cấp dữ liệu nào. Giống như câu trả lời ngẫu nhiên, công nghệ này giúp bảo vệ và thể hiện ý định rõ ràng về phía bạn: bạn không thể sử dụng mã nếu bạn 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 nâng cao khả năng bảo mật trước các sự cố rò rỉ và rò rỉ dữ liệu, vì dữ liệu thu thập được giảm các mối nguy hại đối với quyền riêng tư của người dùng, ngay cả đối với bạn, đồng thời cũng sẽ giảm mức độ bị xâm phạm nếu dữ liệu bị rò rỉ. Tuy nhiên, hãy nhớ rằng nếu bạn đ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, sau đó sử dụng các kỹ thuật để tổng hợp dữ liệu đó), bạn vẫn cần bảo mật dữ liệu thô của người dùng và rồi xoá tài khoản đó sau khi xử lý, đồng thời phải có và tuân thủ các chính sách rõ ràng để xác nhận rằng bạn hiện không sử dụng tài khoản đó trước đó (hoặc nêu rõ mục đích sử dụng của bạn).

Lưu giữ: thu thập dữ liệu, rồi xoá dữ liệu đó khi sử dụng

Bạn nên nhớ rằng dữ liệu được thu thập có vòng đời; dữ liệu sẽ được thu thập, rồi dùng thông tin này để giúp bạn đưa ra các quyết định kinh doanh, và sau đó đến một lúc nào đó thì nội dung đó sẽ bị xoá. Đây lại 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 bạn theo dõi những nội dung họ đã xem và thời gian xem theo thứ tự để đưa ra dự đoán về lựa chọn ưu tiên của họ, đây là dữ liệu được cấp cho bạn cho một mục đích cụ thể-không phải như khoản tài trợ không giới hạn để nhà phát triển sử dụng khi họ thấy phù hợp. Khi dữ liệu đó không còn cần thiết cho mục đích đó nữa sau một phút, đôi khi sau nhiều năm-dữ liệu đó sẽ bị xoá.

Mỗi khi 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) và bạn nên cũng biết thời điểm và lý do bạn sẽ 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 hiệu quả để tạo dựng niềm tin trong mối quan hệ là thông báo rõ ràng cho người dùng về 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 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. Nielsen Nielsen Group cho biết rằng người dùng "cần có nhãn hiệu "khẩn cấp thoát" rời khỏi hành động không mong muốn mà không phải thực hiện quy trình mở rộng". 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 YeeIacono.)

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 của tính năng Xoá dữ liệu trang web là khi người dùng đăng xuất, nhưng thông tin này cũng có thể được dùng sau khi xảy ra sự cố bảo mật để đảm bảo rằng một tài khoản có thể bị xâm nhập 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.

Để 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 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 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 mục 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 ý 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 được gửi trên trang đăng xuất thực tế của bạn, nhưng trên một số tài nguyên khác, trang sẽ tải. Lý do là vì trên một máy tính chậm có bộ nhớ đệm lớn, thì trang sẽ chặn trong khi xoá bộ nhớ đệm và điều này cản trở 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 mục đích bạn cần dữ liệu

Tầm quan trọng của niềm tin vào mối quan hệ với dịch vụ của bạn đã được tuyên bố nhiều lần vì điều này làm tăng tuổi thọ 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ư của bạn hoặc khi đặt câu hỏi về tài khoản tạo, 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 thức 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. Thường xuyên dùng cho câu lệnh 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 người dùng nhấp vào trường này, người dùng sẽ thấy nội dung giải thích bật lên.

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 "chỉ trong trường hợp" là như thế nào. Khi bạn nêu rõ lý do của mình cho việc thu thập, có thể thấy rõ ràng rằng điều này đang xảy ra. Nếu bạn muốn viết ra công khai những gì mình muốn liên quan đến dữ liệu người dùng bởi vì những người dùng đó sẽ không thích nội dung giải thích, đây có thể là một dấu hiệu cho thấy bạn nên xem xét lại việc thu thập nó. Đ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. Người dùng thường phải thiết kế trải nghiệm người dùng để quá trình đăng ký trở nên suôn sẻ và dễ dàng nhất có thể, bởi 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à do đó, điều quan trọng là cho phép họ trở nên dễ đầu tư hơn khi họ chưa có xu hướng làm như vậy. Nếu dễ dàng rời đi, việc thử nghiệm dịch vụ sẽ chính xác là thử nghiệm chứ không phải là khởi đầu một cách vô tình cho 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 chia sẻ rất ít dữ liệu. Khi bắt đầu mối quan hệ của bạn với họ, họ có thể không có lý do để tin tưởng bạn và không nên tin tưởng bạn. Mục tiêu của bạn là chứng minh lý do các quảng cáo đó nên xuất hiện.

Nên

  • Quyết định tất cả dữ liệu bạn dự định thu thập lý do bạn muốn thu thập và 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á khỏi cơ sở dữ liệu máy chủ của bạn sau khi bạn 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

Vấn đề xây dựng mối quan hệ với người dùng là do lòng tin, còn lòng tin là về 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.