必要なデータのみを使用

ユーザーのリスクを軽減する良い方法は、ユーザーのプライバシーに影響する、ユーザーに関する不要な機密データを保存しないことです。ビジネス目標を達成しながらこれを実現する方法は他にもあり、それぞれについて検討する価値はあります。次のような方法が考えられます。

何のためにデータが必要なのかを説明してください。
低い粒度でデータを収集する。
使用後にデータを削除する。
そもそも収集しない。

こうしたアプローチのいずれも、あなたが行っていることや、その理由にユーザーが納得感を持てるようにすることにつながり、デベロッパーとの関係構築に大きく寄与します。透明性は信頼の構築につながります。そして何より、信頼は独自のセールスポイントになり得ます。多くの人々は、ユーザーや顧客はデフォルトでそれらを信頼していると思っていますが、消費者は常に製品やサービスを評価しているため、実際には当てはまりません。ユーザーのデータややり取りが尊重されるよう信頼してユーザーとの関係を築くことができれば、プロジェクトやビジネスとして競争上の優位性を得ることができます。それは、ライバルが追いつけない、真の差別化要因です。

では、上記のアプローチを、効果が高い（ただし、ビジネスにも影響が大きい）ものから順に説明します。効果は低いものの、導入に支障の少ないものの順に説明します。

そもそも収集しない

ユーザーのデータを侵害しないようにする最も明白な方法は、データを収集しないことです。サービスを提供するには一部のデータ収集が必要になりますが、予想以上にデータ収集を回避できる場所はたくさんあります。たとえば、ログインせずに決済する場合を考えてみましょう。ユーザーがウェブアプリを使用して何かを購入する際に、アカウントの登録を求められる場合があります。これは、後のフルフィルメントのために個人情報を取得できるためです。たとえば、メーリングリストに追加したり、関心を持った顧客として事前に認定済みであったりします。しかし、お客様はこのことを認識し、好ましくありません。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 が述べているように、ユーザーが障害を乗り越えることなく離れられるようにすることで、「自由と信頼を育む」ことができます。学術研究では、これを裏付けて「取り消し可能性の原則」と名付けています。「このインターフェースでは、取り消しが可能な場合にはユーザーが付与した権限を簡単に取り消すことができるべきです。ユーザーはこのような同意を取り消せる必要があります。そのため、可能であれば、リソースにアクセスする権限を減らす必要があります。」（例については、Yee と Iacono をご覧ください）。

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

推奨事項

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

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

Clear-Site-Data のサポートを追加するには、ユーザーがログアウトしたとき（またはクライアントサイドのストレージを消去したいとき）に、ログアウトステータスを確認するページ（https://your-site/logout など）に HTTP ヘッダー Clear-Site-Data を送信します。このヘッダーには、次の値の一部またはすべてを指定できます。また、すべての値を "*" にすることもできます。

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>

ユーザーについて収集したすべての情報を基にこのプロセスを実施すると、社内プロセスやディスカッションにも役立ちます。先ほどは、「念のため」にデータを収集したいという誘惑について学びました。データを収集する理由を明確にすれば、そのことがはっきりとわかります。ユーザーが説明を気に入らないため、ユーザーデータを使用して行う処理を一般公開したくない場合、収集について再考する価値があることを示唆しています。これは、不快な説明が侵襲的（「1 時間ごとに訪問した場所を追跡するためにこれを使用します」）、範囲が広すぎる（「Google がこれを使用する目的はまだわかりませんが、何かを考える場合に備えて」）、回避的すぎる場合（「内部の非公開の目的で使用します」）が当てはまります。これは単なる道徳の問題ではありません。すでに説明したように、ユーザーはこのことをよく理解しており、何かを試すことは長期的なコミットメントの始まりではないとユーザーに期待しています。ユーザーエクスペリエンス設計では、登録をできるだけスムーズに簡単に行うことが一般的です。登録の初期段階では（当然のことながら）サービスに多額の投資を行っていないため、ユーザーがその意欲がほとんどない場合に、簡単に投資できるようにすることが重要です。再び離れることが簡単な場合、サービスのテストは無理に終わりません。前述したように、逆説的ですが、信頼を構築する最善の方法は、ユーザーが望まない場合にユーザーに信頼するよう要求しないことです。

データを共有しない、または最小限のデータしか共有しない正当な理由がある。信頼関係を築いた当初は、信頼する理由がないかもしれませんし、信頼する必要はありません。目標は、なぜそうすべきなのかを示すことです。

推奨事項

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

理由

ユーザーとの関係を築くには信頼が重要であり、信頼とはオープンさです。ユーザーに関するデータをできるだけ多く収集し、その用途を隠しているだけではないことを実証できれば、信頼を築くことができます。これは、慎重なライバル企業よりも競争上の優位性を得られる可能性があります。