必要なデータのみを使用

ユーザーのリスクを軽減する良い方法は、ユーザーのプライバシーに影響を及ぼす不要なセンシティブデータを保持しないようにすることです。ビジネス目標を達成しながらこれを実現する方法は驚くほど多く、それぞれを検討する価値があります。次の方法をお試しください。

何のためにデータが必要かを説明します。
粒度を下げてデータを収集する。
使用後にデータを削除します。
そもそも収集してはいけません。

こうしたアプローチのどれもが、ユーザーが何をするのか、なぜ何をしているのかについて、ユーザーがより不安なく理解するうえで役立ちます。これは、ユーザーに大きく貢献するものです。関係にあります透明性は信頼を築きます。信頼は、貴社の独自のセールスポイントにもなります。多くの人は、ユーザーや顧客がデフォルトで信頼していると想定していますが、消費者は常に商品やサービスを評価しているため、必ずしもそうとは限りません。ユーザーのデータややり取りを安心して処理できる関係を築いている場合プロジェクトやビジネスとして競争上の優位性をもたらすライバル企業や真の差別化要因になります

上記のアプローチについて、最も効果的（ビジネスへの影響も最も大きい）順から、最も効果的ではないが、実装に伴う中断が最も少ない順に説明します。

そもそも収集しない

ユーザーデータを漏洩させないための最も簡単な方法は、データを収集しないことです。サービスの提供しかし、データ収集を回避できる場所は思っているよりもたくさんあります。たとえば、ログインせずに決済する場合を考えてみましょう。ユーザーがウェブアプリを使用して何かを購入する際に、アカウント登録を必須にすることもできます。そうすれば、後でフルフィルメントに使用できる個人情報を収集できます。たとえば、メールリストに追加したり、興味のある顧客として事前認定したりできます。しかし、ユーザーはこのことを認識しており、好ましく思っていません。2021 年の調査では、4 件の放棄された販売のうち 1 件が、サイトがユーザーにアカウントの作成を求めたために発生したことが判明しています。アカウントを必要としない場合は、顧客の維持率が高まります。登録なしで購入を完了できるようにすると、ユーザーはより多くの選択肢を得ることができ、保護と安全を確保する必要があるデータも少なくなります。

データを「不確実にする」

もちろん、データを一切収集しないことも選択肢ではありません。サービスを提供したり、賢明なビジネス上の意思決定を下したりするために、データを収集することが重要です。また、信頼関係の文脈でマーケティングコミュニケーションを構築することも有効です。ただし、意思決定はまとめて行われる（つまり、多くのユーザーに同時に影響を与える）ことも理解することが重要です。集約されたデータ（つまり、データの集合的な特性）について。

たとえば、視聴者のユーザー属性（該当する年齢層、位置情報などがありますこれにより、メッセージやアプローチが変わる可能性があります。だからといって、完全なデータセットを年齢を指定できます多くの場合、トレンドと全体的なプロパティを探します。望ましい決定を下すにはリーチは、オーディエンスの大半が「18 ～ 34 歳の主要ユーザー層」に該当するかどうかによって左右されます。この場合、実際に必要なのはターゲットとなるのはユーザーがその属性に該当するかどうかですこれにより、これらは 2 つの「バケット」に収集されます。つまり、そのグループ内にあり、そのグループ内には集められていません。さらに詳細なデータが必要になる場合もありますが、ユーザー属性のリストを使用することは合理的です。そのリストを使って自身を分類するようユーザーに依頼することです

例

たとえば、ユーザーベースが「18～34 歳」、「35～49 歳」、「49～64 歳」、「65 歳以上」の年齢カテゴリにどのように分かれているかを知りたい場合は、ユーザーにどのカテゴリに該当するかを選択してもらいます。非常に詳細な分類して、ユーザー自身でユーザーを分類できます。これにより、同じ質問をする手間を省くことができます。後ほど詳しく説明します。たとえば、正確な年齢と生年月日をリクエストし、これを使用して多くのユーザーは「35 ～ 49 歳」あります。ただし、これがどのようになるかを理解することが重要です。このコースですでに説明し、繰り返しになりますが、詳細なレベルのデータを要求すると従業員が不快感を招き、組織に対するユーザーの信頼が低下します。リスクが高まります

また、データのニーズも考慮する必要があります。より詳細なデータの「必要性」が推測的である場合や、「万が一に備えて」の要件である場合もあります。現時点ではユーザーをこの 4 つの年齢層に分類するだけでよいが、将来的には後で詳細に絞り込んでおきます価値があるかもしれませんよりきめ細かいデータが過去にどれくらいの頻度で使われたかを考慮します。提供されるサービスに比べて侵入的と見なされるデータをリクエストすると、ユーザーが組織を信頼する度合いが低下します。データが「万が一」の理由で収集されている場合、ビジネス上の意思決定の改善のためにユーザーの信頼を失うだけでなく、存在しない可能性のある将来の理論的な意思決定の可能性のためにユーザーの信頼を失うことになり、その情報のセキュリティ要件も負うことになります。

収集するデータの粒度を下げるには、より詳細なアルゴリズム的方法もあります。ランダムなレスポンス方法調整可能な程度の不正確さでデータを収集することを意味し、科学的根拠を保ちながら、侵害の可能性があるデータや機密データを収集する上記のデータ収集方法では、ユーザーの回答の範囲を広げます（「年齢」を「次の年齢グループのいずれかに該当しますか」に変更します）。ランダム化された回答では、一定の割合のユーザーが回答を偽造します。不正解と回答するユーザーの割合が既知であれば、有意な結論は収集データから抽出することも可能だが、個々のユーザーのプライバシーは侵害されない。間違いです。この場合も、視聴者の 80% が 18 ～ 34 歳のユーザー層に当てはまると回答した場合、回答者の 10% が意図的に間違った回答をしたとしても、これが依然として最大のシェアであると確信している人の割合。不正確さの程度はプログラムで変更することもできます。この場合、正解は常に求められますが、ソフトウェアは送信前に回答の一定割合を変更します。このプロセスとその結果は、データを収集する際にユーザーに説明することもできます。つまり、個々のデータは信頼できないため、収集したデータを不正使用しないという信頼をユーザーに求める必要はありません。

技術的に複雑なプロセスは差分プライバシーです。数学的手法を使用してデータストレージを変更し、データの集約プロパティが引き続き存在するようにします。特定の個人がデータを提供したのか、あるいはどのデータを提供したかさえわかりません。ランダム化された回答と同様に、これはユーザー自身に対してもユーザーデータを保護し、明確な意図を示します。つまり、ユーザーデータがなければ、そのデータを使用できないということです。

これらの手法や同様のアプローチでは、収集されたデータがにより、ユーザーのプライバシーに対する侵害（お客様自身を含む）を低減できるとともに、データが漏洩した場合の侵害のレベルも低減します。ただし、サーバーで差分プライバシーの手法を適用している場合（つまり、ユーザーがサーバーを未集計データを集計する手法でデータを集計するといった場合などです処理後に削除したり、明確なポリシーに従ったうえで、以前にそのリソースを使用していないことを確認する必要もあります。集約（または、その用途が明確）する必要があります。

保持: データを収集し、使用後に削除する

収集されたデータにはライフサイクルがあることを覚えておくと便利です。ビジネス上の意思決定に役立てるためある時点で削除する必要があります繰り返しになりますが、これらはトレードオフです。ユーザーに質問したり、ユーザーがアクセスした他のウェブサイトの情報を保存したり、ユーザーが閲覧した内容や閲覧時間をユーザーの嗜好について予測するためです。これは特定の目的のためではなく、自由にお使いいただけます。そのデータがその目的で不要になったら（1 分後の場合もあれば、何年後の場合もあります）、削除する必要があります。

ユーザーに関する情報を収集するときは、そのデータを何のために使用するかを把握する必要があります（下記を参照）。また、そのデータを保持しなくなるタイミングと理由も把握する必要があります。たとえば、ユーザーが削除を選択したとき、ログアウトしたとき、特定の期間が経過したとき、特定のイベントが発生したときなどです。関係の信頼を築くには、ユーザーに関するデータをユーザー自身がどのように管理できるかを明確に示すことが効果的です。可能であれば、一方的なオプトアウトも含めて説明します。データを削除するにはどうすればよいですか？アカウントを削除するにはどうすればよいですか？こうした関係を構築するうえで、データを処理する必要がある期間のみ保存し、それ以上保存しないことがベストプラクティスです。また、ユーザーが自身から収集されたデータやユーザーに代わって収集されたデータを確認、削除できる方法も用意する必要があります。この点に関して、法律が制定される可能性もあります。必要があります。

これは、明確な技術目標を定義できる領域であり、ユーザーがセルフサービスで利用できます。ユーザーが許可を求めることなくデータウェアハウスをオプトアウトできる場合、ユーザーはオプトインすることをより快適に感じることができ、そのためのサポートリソースも必要ありません。

簡単にオプトアウトして、デフォルトでオプトアウトすることの重要性を認識することが重要です。「信頼と認識を築くために、企業はまず、あらゆるタッチポイントでオーディエンスを尊重するという社会的契約に合意します。ニーズを傾聴し、それに応じて対応します」と IAPP は述べています。 Nielsen Norman Group の見解によると、ユーザーは '緊急出口'長いプロセスを経ることなく不要なアクションを離れるという問題です登録は解除よりも簡単であることは誰もが知っています。しかし、Nielsen Norman が言うように、ユーザーが面倒な手続きをせずに離脱できるようにすると、「自由と自信を促進」できます。学術研究ではこれを裏付けるものとして、「生命の原理」と revocability」で、次のように述べています。「このインターフェースでは、ユーザーがどこででもユーザーが付与した権限を簡単に取り消すことができる必要があります。取り消すことが可能です。ユーザーがそのような同意を取り消せるため、リソースにアクセスする権限を減らすことができる必要があります。。」（例については、Yee と Iacono をご覧ください）。

データを保持する期間と保持するデータは、組織やプロジェクトによって大きく異なります。ただし、考慮すべき一般的なガイドラインがいくつかあります。

すべきこと

ここでは、ユーザーがアカウント（および関連データ（可能な場合））を削除できるようにし、Clear-Site-Data ヘッダーを使用して、ログアウト時にエフェメラルデータとローカルに保存されたデータを定期的に（ログアウト時など）削除できるようにすると便利です。

Clear-Site-Data ヘッダーを指定して、クライアントサイドに保存されているユーザーデータ（Cookie、localStorage、IndexedDB、ブラウザキャッシュなど）の一部またはすべてを削除します（合理的な場合）。Clear-Site-Data の明らかなユースケースは、ユーザーがログアウトする場面ですが、セキュリティインシデントの後で使用して、不正使用の可能性があるアカウントに、不正使用されたデータの痕跡がクライアントに残っていないことを確認することもできます。

Clear-Site-Data のサポートを追加するには、ユーザーがログアウトしたとき（または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）フィールドの意味を説明する。これらの説明に、データを収集した理由の説明を加えることを検討してください。よくある「Why do we need this?」というフレーズを使用しますクリックすると説明がポップアップ表示されます。

たとえば、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 ヘッダーを使用して、ユーザーが自分で作成したアカウントを削除したり、ストレージから保存データを削除したりできるようにします。

理由

ユーザーとの関係を構築するには信頼が重要であり、信頼とはオープンであることです。ユーザーに関するデータをできるだけ多く収集し、その用途を隠しているわけではないことを示すことができれば、信頼を築くことができます。これは、慎重さに欠ける競合他社に対する競争上の優位性になる可能性があります。