為降低使用者的風險，建議您不要保留非必要的機密資料，以免侵犯他們的隱私權。 有許多方法可以幫助您在達到業務目標的同時，務必加以考量。 你可以採取以下做法：
- 說明您需要的資料。
- 以較低的精細程度收集資料。
- 使用舊資料後移除。
- 不要在一開始收集相關資料。
無論採取何種做法，使用者都能更安心地瞭解您的所做事和動機，進而有效拉近您與他們之間的距離。資訊公開不僅能建立信任感，也是你獨特的賣點。許多人認為，在預設情況下，使用者和客戶會信任他們，但消費者會持續評估產品和服務，可能不是這樣。如果您與使用者建立關係，讓他們相信您能夠處理個人資料，並相信您與對方互動，您或許就能為專案或企業帶來競爭優勢：競爭對手可能無法與競爭對手達成共識，這是真正的差異化優勢。
讓我們一起拆解上述做法，依序闡述採用最有效 (但對業務最具影響力) 到最有效、最不會造成乾擾的情形。
一開始不要收集密碼
如要避免使用者資料受到影響，最顯而易見的方式就是避免收集資料。服務在收集部分資料是提供服務的必要條件，但您還是可以在更多地方避免收集資料。比如「訪客結帳」。 當使用者使用您的網頁應用程式購物時，您可能需要要求他們註冊帳戶，因為您會先擷取個人資訊以供稍後執行：可以把他們加入郵寄清單、已預先具備資格，成為感興趣的客戶等等。但客戶知道這一點，而且不喜歡：2021 年，一項研究發現，有四分之一的放棄銷售交易中，有一項是因為網站要求使用者建立帳戶。如果您沒有要求帳戶，則較有可能留住這些客戶。 讓使用者不必註冊就能完成交易，能為使用者提供更好的選擇，也讓您擁有太多資料需要保護和保護。
「模糊」您的資料
當然，您可能無法完全避免收集資料。為提供服務及做出明智的業務決策 就必須收集資料。在建立信任關係的情況下，也有助於建立行銷溝通管道。 然而，您也必須瞭解，匯總的決策 (即一次影響許多多位使用者) 是與匯總資料 (亦即資料集體屬性有關) 的依據。
例如，有時您也可以瞭解目標對象的受眾特徵，例如他們所屬的年齡層、所在位置等。這可能會改變你宣傳的訊息或分享方式。但這並不表示您需要為服務的所有使用者收集確切的年齡。您通常會尋找趨勢和整體資產。如果希望觸及的決策受到多數目標對像是否在「18 到 34 歲主要客層」影響，那麼唯一需要詢問的是使用者是否屬於該客層。這會將值區收集為兩個「值區」：在該群組 (而非該群組中)。 在某些情況下，您可能需要取得更精細的資料，但最好能掌握用來做決策的客層清單，並要求使用者根據該清單進行分類。
範例
因此，如果能瞭解使用者族群分為「18-34 歲」、「35-49 歲」、「49-64 歲」和「65 歲以上」的使用者族群，您可以要求使用者選擇他們屬於哪個類別。您很可能會要求取得極為精細的個人化和個人化資料，然後將使用者分類，這樣就不必稍後再次詢問相同的問題。舉例來說，您可以詢問確切的年齡和出生日期，然後用它來產生一份「35-49」類別中有多少使用者的清單。但必須瞭解具體的結構：本課程已介紹過，會再次討論，要求提供精細的資料可能會讓使用者感到不舒服，並減少使用者對機構的信任，同時增加風險。
您也必須考量資料需求。有時，更精細的資料「需要」是推測或「不容錯過」的要求。例如，我們現在只需要將使用者歸入這四個年齡層，但日後我們可能會想縮小範圍，因此現在應該收集非常詳盡的資料，以便日後使用這個選項。建議您考量過去使用較精細資料的頻率，做為決策依據。如果要求的資料可能涉及侵入性相對於提供的服務，必然會降低使用者信任貴機構組織的程度。如果系統是基於「以個案方式」收集這些資料，您不可能只是為了取得改善業務決策而放棄信任，而放棄追究目標，僅是為了達成某些理論未來決策的可能性，同時也會遵循該資訊的安全要求。
還有更精細的演算法方法，能減少所收集資料的精細程度。隨機回應方法是指以可調整的不準確程度來收集資料，且在收集可能侵入性或機密資料時，在收集潛在侵入或機密資料時便已運用於社交科學數十年，同時仍能維護回應者的機密性。上述資料收集方法涉及擴增使用者的答案 (也就是說，「您的年齡如何」變成「您屬於下列哪個年齡層」)，其中隨機化的回應會讓一定比例的使用者產生答案。如果知道不當回應的使用者比例，系統仍然可以從收集到的資料中得出有意義的結果，但個別使用者的資料可能不正確，因此不會影響個別使用者的隱私權。在本例中，如果有 80% 的目標對象仍屬於 18 至 34 歲客層，您可以放心，即使有 10% 的觀眾是刻意提供不正確的答案，您依然可以放心，這仍是最大的比重。此外，您也可以透過程式修改錯誤程度，因為一律都要求正確答案，但軟體會在傳送前修改一定比例的答案。系統在收集資料時，也會向使用者說明這項程序及其結果：這表示使用者無需相信您不會濫用他們收集到的資料，因為個人資料並不可靠。
差異化隱私是相似但技術上涉及的程序。這會使用數學技術修改資料儲存空間，使資料的匯總屬性仍然存在，但無法判斷特定人士是否提供資料，或什麼時候提供任何資料。這和隨機回應一樣，不僅可以保護使用者的資料，還能明確展示使用者的意圖：如果沒有使用者的資料，則無法使用使用者資料。
上述和其他類似方法也能提升資料侵害和外洩的安全性，因為收集的資料可降低使用者隱私的風險，也能降低資料外洩時外洩的風險。 不過請注意，如果您在伺服器上採用差異化隱私技術 (讓使用者傳送未經匯總的資料給您，然後使用相關技術匯總資料)，您仍然需要保護原始使用者資料，然後在處理完成後刪除這些資料，並且應遵守並遵循明確的政策，確認您未在匯總前使用這些資料 (或清楚交代用途)。
保留：收集資料，然後在使用後將其移除
值得注意的是，收集的資料具有生命週期，系統會收集這些資料，用來協助您做出業務決策，到了特定時間點則應移除。這同樣也有利於權衡利弊：如果您詢問使用者的問題、儲存有關他們瀏覽的其他網站的資訊，或追蹤使用者為了預測自己的偏好而查看的內容和多久時間，而這些資料是基於特定目的而提供給您的開放式授權，讓開發人員能視情況使用。當我們不再需要這些資料時，一分鐘後 (有時數年後) 就會刪除這些資料。
每次收集使用者資訊時，您應瞭解這些資料的用途 (詳見下文)，您也應該瞭解停止保留這些資料的時機和原因。這可能是使用者選擇刪除活動、登出時、特定時間過後，或是在特定事件發生後。為建立關係建立信任關係，建議您向使用者清楚說明，如何控管有關自身資料的方式，包括盡可能單向選擇退出。他們如何刪除自己的資料？他們如何刪除帳戶？除了協助建立關係之外，建議您也儲存資料。在需要處理的時間較長，且使用者應能夠查看及移除您從他們身上或他們收集的資料。您的營運地區也可能有該地法規的法律規範。
您可以在這個領域定義明確的技術目標，協助使用者自行完成自助服務；如果使用者不需要取得權限就能選擇退出資料倉儲，那麼他們會更願意選擇加入，而且不需要任何支援資源。
瞭解輕鬆選擇「預設停用」的重要性不可忽視：「如要建立信任感及提升知名度，公司可以先同意社群合約，承諾在每個接觸點尊重目標對象，接著重視他們的需求並做出回應」，表明 IAPP。Nielsen Norman Group 表示使用者「需要明確標示的「緊急退出」，以免執行不必要的動作，而不需經過延長程序。大家都知道 訂閱比取消訂閱更容易不過，正如 Nielsen Norman 所說，讓使用者不必翻遍全盤就能走走，「可以獲得自由和自信」。學術研究支持上述內容，並將其命名為「撤銷原則」，並指出：「介面應能讓使用者在可行的情況下，輕鬆撤銷使用者已授予的權威單位。使用者應該要能夠撤銷這類同意，並盡可能減少存取資源的授權單位。」(如需範例，請參閱 Yee 和 Iacono)。
保留資料的時間長短以及要保留哪些資料的主題，不同機構和專案之間存在極大的差異，但仍有一些常見的準則需要考量。
正確做法
允許使用者刪除帳戶 (及任何相關資料) 以及定期 (例如登出時) 使用 Clear-Site-Data 標頭，在登出時清除暫時和本機儲存的資料。
在合理情況下，提供 Clear-Site-Data 標頭，以移除儲存在用戶端的部分或所有使用者資料 (無論是在 Cookie、localStorage、IndexedDB 或瀏覽器快取中)。Clear-Site-Data 最顯而易見的用途是在使用者登出時。但在安全性事件發生後，也能確保可能遭到入侵的帳戶不會保留儲存在用戶端的遭入侵資料追蹤記錄。
新增 Clear-Site-Data 支援功能時，必須在使用者登出 (或其他想要清除用戶端儲存空間的時候) 傳送 HTTP 標頭 Clear-Site-Data，並在確認登出狀態 (https://your-site/logout 或類似位置) 的頁面上傳送。這個標頭可以含有下列部分或全部的值，或是具有 "*" 的所有項目：
Clear-Site-Data: "cache", "cookies", "storage"
這些值分別會清除快取網頁 (和其他 HTTP 快取資源)、已儲存的 Cookie、localStorage 和 IndexedDB 等，您可能會看到其他選項 executionContexts 的參照，但許多瀏覽器不支援此選項。請注意，使用 Clear-Site-Data 標頭可能比自行刪除所有建立資源來得簡單，因為不需要在用戶端上執行 JavaScript 程式碼 (而且這是清除瀏覽器快取的唯一正式方式)，但是並非所有瀏覽器都支援。
使用注意事項：如要清除快取 (透過傳送 Clear-Site-Data: cache)，則 Clear-Site-Data 標頭不應傳送至實際的登出頁面，但在其他資源中會載入。這是因為如果電腦速度較慢，且快取較大，網頁就會在清除快取時封鎖，導致使用者無法瀏覽網頁。這項作業可能需要幾分鐘才能完成，進而讓使用者感到不悅。測試不太可能發生，但要測試也很困難，因此最好是謹記這一點。
說明您需要資料的
您的服務對使用者的服務建立信任度一再指出，是因為這能提升使用者的使用壽命。 同時也提供競爭優勢。有一種方法是公開瞭解程序，保持公開透明的做法，就是說明您需要的資料。您之前也學到，每收集一個東西時 都應知道該物件何時會刪除您必須知道為何需要這些資料、哪些特定問題需要資料才能找出答案，以及需要收集哪些決策。您知道為什麼需要使用者放棄這些資料後，我們就能向這些使用者說明這項做法，以贏得他們的信任。在隱私權政策或帳戶建立過程中，請說明您需要這個特定問題的答案、您會如何處理這些資料，以及移除資料的時機和方式。
以內嵌方式呈現時，這些說明會更加顯眼。網站上的其他政策如果夾在密集政策文件中，而當中的模糊說明看起來可能就像嘗試隱藏這些內容。註冊、結帳或申請表單可以說明除了收集資料之外，還會一併收集資料的原因。表單欄位通常都會有一個星號 (*) 來表示必填欄位；複雜的表單通常會提供資訊連結 (i) 來說明欄位的意義。建議你在說明中說明系統收集資料的原因。常見的詞組為表單欄位旁的「為什麼需要這項？」，使用者點選後就會看到彈出式說明。
部分 HTML 範例可能如下所示，而且 CSS 和 JavaScript 會隱藏 <aside>，並在使用者點選連結時顯示彈出式視窗。(請務必確認您為網站製作的表單支援無障礙功能！)
確切的安排方式取決於您的樣式和做法，但這裡的重點是直接把資料收集作業與說明原因直接建立關聯。但每個欄位不一定都要這麼做。沒有人需要說明為何您在註冊時必須選擇密碼。不過，每項針對個人和聯絡資訊的要求，請一併說明您打算如何使用，並讓使用者清楚瞭解到您是為了保護他們的資料而投入心力。
<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>
執行這項程序時，您收集的使用者相關資料也有助於內部流程及討論。 在稍早的例子中，您已瞭解到如何「以防萬一」收集資料會讓人不知所措。如果明確說明收集原因，就能很清楚判斷指標的發生。如果您沒有辦法公開表達您想運用使用者資料的行為，因為他們不喜歡說明，這可能表示值得重新考慮收集資料。這包括令人反感的解釋是否過於侵入性 (「我們會利用此方式追蹤每小時造訪的地點」)、過度過度使用 (「我們還沒有這個使用項目，但想要這麼做」) 或過於寬鬆的解釋 (「我們會進行內部未經揭露的目的」)。這不只是一個道德問題，人們也十分熟悉這點，如之前所述，並且使用者會期望嘗試各種不同的行為，並不是一個長期承諾的開端。為使註冊作業變得輕鬆流暢且易於註冊，這是設計非常順暢的一種方式，因為使用者在早期階段 (定義上) 沒有大量投資您的服務。因此，在他們對服務沒有把握的情況下，您必須讓使用者能夠更輕鬆地進行投資。因此，如果實驗很容易停止，就不必一直在進行實驗。和先前一樣，這是典型的，但真正的是，建立信任度最好的方式，不要在不想要使用者的意願的情況下要求他們對您取得信任。
使用者有充分的理由禁止分享資料，或他們只分享少量資料。與您的關係起初，對方可能沒有理由相信您，也不應該如此。請說明為何他們該這麼做。
正確做法
- 決定你要收集所有資料的原因，並決定這些資料的保留時間。
- 索取資料時，請向使用者說明您收集資料的原因。
- 使用完畢之後，請從伺服器資料庫中刪除該索引。
- 允許使用者刪除已建立的帳戶，並使用
Clear-Site-Data標頭清除儲存空間中儲存的資料。
原因
與使用者建立關係的關鍵在於建立信任感，而信任感則是開放性。如果能證明您不會盡可能收集最多使用者相關資料，並隱藏使用資料的用途，這樣有助於建立信任感，比起較不嚴格的競爭對手，這可讓您更具競爭優勢。