Singular SDK による同意管理: 意思決定フレームワーク

フォローする
Avatar
Jared Ornstead
Updated

Singular SDK による同意管理: 意思決定フレームワーク

この記事では、Singular が提供するプライバシー制御と、当社の顧客基盤全体で見られる実装パターンを説明し、それらを 1 つの同意アーキテクチャに構成するためのフレームワークを示します。個々の制御はそれぞれの記事で説明されており、このページではそれらがどのように連携するかを説明します。

始める前に: 同意フローは貴社の法務およびプライバシーチームが管理し、各管轄区域でアプリにどの方針を適用するかを決定する責任があります。この記事は製品の動作のみを説明するものであり、法的助言ではありません。

すべての同意フローが行き着く 2 つの決定

Singular のプライバシー制御は、2 つの独立した決定を中心に構成されます。この 2 つを分けておくことで、1 つの同意プロンプトでコンプライアンスに準拠した実装が可能になります。

決定 1: トラッキング。 Singular はこのユーザーを認識するか? これは、SDK を初期化するかどうか、およびそのタイミングによって制御されます。初期化により、最初のセッションが送信され、インストールレコードが作成され、アトリビューション処理がトリガーされます。SDK が一度も初期化されない場合、Singular はそのデバイスについて何も受信しません。これは利用可能な最も厳格な制御です。

決定 2: 共有。 Singular がユーザーを認識している場合、そのデータを広告パートナーと共有してよいか? これは Limit Data Sharing (LDS) フラグで制御されます。LDS を使用すると、ファーストパーティ分析（セッション、リテンション、イベント、レポート）を維持しつつ、ポストバックでパートナーに流れる内容を制限できます。意味とパートナーの動作については Limit Data Sharing FAQ を参照してください。

同意フレームワークが測定同意と広告またはリターゲティング同意を区別する場合（EEA で一般的）、マッピングは直接的です。測定同意は初期化をゲートし、広告同意は LDS を設定します。一度解決された 1 つのプロンプトが両方のレバーを駆動します。

制限の緩いものから厳しいものへの制御一覧

制御 行うこと 行わないこと
limitDataSharing (config またはランタイム) ユーザーの共有設定を示します。パートナーのポストバック動作は、パートナーごとの設定に従います。 Singular のトラッキングを停止しません。パートナーレベルの制限が設定されていない限り、ポストバックを変更しません。
限定識別子モード SDK は IDFA または GAID を収集せず、代わりに IDFV または ASID を使用します。 非広告識別子のトラッキングや共有を停止しません。
stopAllTracking() すべての送信を直ちに、かつ永続的に停止し、resumeAllTracking() が呼び出されるまで継続します。 すでに送信されたインストールやイベントを取り消しません。初期化はすでにアトリビューションをトリガーしています。
初期化しない Singular はそのデバイスについて何も受信・処理しません。 これらのユーザーにはディファードディープリンクとアトリビューションを利用できません。
trackingOptIn() レガシー: 同意通知イベントを記録するだけです。 トラッキングやデータ処理に機能的な効果はありません。これを基に同意ロジックを構築しないでください。

3 つの同意フローモデル

  • オプトアウトをデフォルト（先に初期化）: SDK はアプリ起動時に初期化され、オンボーディング中に同意が提示され、拒否されると stopAllTracking() をトリガーするか LDS を true に設定します。これにより完全なアトリビューション精度と迅速な SAN ポストバックが得られます。ユーザーが回答する前にインストールの瞬間が捕捉されるため、このモデルには明示的な選択の前の収集を許容する法的方針が必要です。米国のオーディエンスで一般的です。
  • オプトインをデフォルト（先に同意）: ユーザーが明示的に同意するまで SDK は初期化されません。同意していないユーザーについては何も送信されません。GDPR オーディエンスで標準的です。決定を保持し、以降の起動時にはすべてのアプリエントリーポイントで直ちに初期化してください。
  • ハイブリッド（すぐに初期化し、初期化時に LDS を確定）: アプリ起動時に同意画面を解決し、その後 config オブジェクトに limitDataSharing をすでに設定した状態で初期化します。インストール以降のすべてのレコードがユーザーの宣言した状態を保持し、意図はあるが未適用という期間がありません。これは、起動時に同意を提示できるプライバシー重視の顧客に推奨するパターンです。

ほとんどのマルチリージョンアプリは、管轄区域または CMP によってランタイムに選択される複数のモデルを実行しています。

計画すべきタイミングの影響

  • 初期化が同じアプリセッション内で行われる場合、初期化を遅らせてもインストールは失われません。Android の install referrer がデバイスに保持され、アトリビューションリクエストが正常に完了します。
  • 初期化が長時間遅延すると（多段階の同意フロー、数日にわたる間隔）、SAN のマッチ率が低下します。初回起動時のゲートは、高速な単一画面に抑えてください。
  • SKAdNetwork ポストバックはインストール時に OS によって生成され、SDK の初期化タイミングの影響を受けません。
  • ディファードディープリンクは初期化とアトリビューションの解決を必要とします。厳格なオプトインモデルでは、ディファードディープリンクは同意したユーザーにのみ利用できます。
  • 初期化完了のコールバックはありません。カスタムのイベントシーケンスを構築する場合は、初期化時点の同意状態をスナップショットとして保存してください。
  • インストールレコードは、初期化時点で有効な LDS 値を固定します。以降の更新は後続のイベントにのみ適用され、すでに送信されたポストバックは取り消されません。法的方針が要求しない限り、未決定のユーザーを LDS true にデフォルト設定しないでください。先に同意を確定するか、ユーザーが回答するまで LDS を unset のままにしてください。

よくある落とし穴

  • 未設定の LDS は制限なしとして扱われます。 ユーザーを制限するつもりでも、まだフラグを設定していない連携は、Singular から見ると制限されていないユーザーです。
  • LDS true はそれ自体では何も変えません。 LDS ユーザーのポストバック動作は、パートナーごと、アプリごとにパートナー設定で定義されます（送信しない / PII なしで送信 / 通常どおり送信）。フラグを設定し、適用を構成してください。
  • ATT は同意フレームワークではありません。 ATT は IDFA の公開のみを管理します。ATT の拒否が LDS true も意味すべきかどうかは、貴社プライバシーチームのポリシー判断です。
  • GDPR の消去はオプトアウトではありません。 OpenDSR API は収集済みのデータを削除しますが、SDK が今後のイベントを送信するのを停止することはありません。同じユーザーフローで消去と stopAllTracking() を組み合わせて処理してください。

関連記事