必要なデータのみを使用

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

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

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

上記のアプローチを、最も効果が高い（ただしビジネスにも大きな効果がある）ものから最も低いものの順に並べましょう最も手間をかけずに実装できます

そもそも収集しない

ユーザーのセキュリティを損なわないよう、データを収集しないことです。サービスの提供しかし、データ収集を回避できる場所は思っているよりもたくさんあります。たとえば、ログインせずに決済する場合を考えてみましょう。ユーザーがウェブアプリを使用して商品を購入する際、アカウントの登録を必須にすることがあります。なぜなら、今後のフルフィルメントのために個人情報を取得している（メーリングリストに追加することが可能で、事前に適格と見なされている）といった条件ですところが、お客様はこれを認知して好まないと認識しています。 2021 年の調査によると販売放棄の 4 件に 1 件サイトでユーザーにアカウントの作成を要求した。アカウントが不要な場合、その顧客は維持される可能性が高くなります。登録せずに購入を完了できるようにすると、つまりユーザーのデータを十分に保護して保護できることを意味します

「ファズ」お客様のデータ

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

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

例

たとえば、ユーザーベースを「18 ～ 34 歳」、「35 ～ 49 歳」、「49 ～ 64 歳」、「65 歳以上」という 4 つの年齢層に分けることで、該当するカテゴリを選択するようユーザーに促すことができます。非常に詳細な分類して、ユーザー自身でユーザーを分類できます。これにより、同じ質問をする手間を省くことができます。後ほど詳しく説明します。たとえば、正確な年齢と生年月日をリクエストし、これを使用して多くのユーザーは「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>

ユーザーについて収集したすべての情報を基にこのプロセスを実施することも、内部プロセスやディスカッションに役立ちます。先ほど、万が一に備えてデータを収集したくなる場合があることを確認しました。理由を明確に示すこれは明らかです。望んでいることを公に書き出すことをためらっている場合説明に満足していないユーザーもいる可能性があります。これは、ユーザーデータの収集を再検討する価値があるできます。これは、不快な説明が過度に侵略的である場合（「お客様の訪問地を 1 時間ごとに追跡するために使用されます」など）にも当てはまります。範囲が広すぎる（「まだ何に使うかはわからないが、何か検討する際に参考にしてほしい」）、または回避しすぎている（「この情報を非公開の内部目的で使用させていただきます」）。これは、単なる道徳観念の問題ではなく、技術に精通していてすでに説明したように、ユーザーは何かを試すことは始まりではないと期待しています。長期的な取り組みになりますユーザーエクスペリエンスデザインでは、登録をできるだけスムーズにし、できるだけ簡単に行えるようにするのが一般的です。初期段階ではユーザーがサービスに（定義上）多額の投資を行っていないため、投資する意欲がほとんどない場合でも、簡単に投資できます。簡単に再開できるのであればサービスのテストはまさに実験的なものであり、長期的なコミットメントを望まない形で開始することではありません。先ほどと同様に、逆説的ですが、信頼を築く最善の方法は、ユーザーが自社を信頼してもらわなくてもよいことです。できます。

ユーザーがデータを共有しない、または共有するデータが少ないことには正当な理由があります。彼らとの関係を始める際に、彼らは信頼する理由がないかもしれませんし、そうすべきではありません。目標は、その理由を実証することです。

すべきこと

収集するすべてのデータについて、必要な理由と保存する期間を決めます。
データの収集を求める場合は、収集する理由をユーザーに説明します。
使用後はサーバーデータベースから削除してください。
Clear-Site-Data ヘッダーを使用して、ユーザーが自分で作成したアカウントを削除したり、ストレージから保存データを削除したりできるようにします。

理由

ユーザーとの関係を構築するには信頼が重要であり、信頼とはオープンであることです。もしそうではないことを証明できるならユーザーに関するデータをできるだけ多く収集し、その用途を隠すことが、信頼の構築につながります。慎重さに欠けるライバルに勝る競争上の優位性となります。