サーバー・データ・トランスファー(SDT)
サーバー・データ・トランスファー(SDT)は、Oracle Data Cloudプラットフォームから外部システムにユーザー・データを転送するためのサーバーサイドの配信方法です。ユーザーに対してIDスワップが実行された後、プラットフォームでは、ピクセルを発火しないで、そのユーザーのデータをサーバーサイドのプロファイル・ストアに配信できます。あるいは、ユーザー・データを毎時バッチ・ファイルまたは日次バッチ・ファイルに保存でき、そのファイルは、SFTPまたはAmazon S3バケットを介してダウンロードできます。
SDTは、Oracle Data Cloudの推奨データ・トランスファー・メカニズムとなり、次のメリットがあります。
- サイトで既知のユーザーのみを配信するため効率が高まります。
- ユーザー・データを転送するためにサイトの帯域幅が使用されません。
- オンライン、オフラインおよびモバイル・ソースからユーザー・データを提供します。
- ユーザー・データを非同期的にキューに配置または処理できます。
ノート: このドキュメントでは、キャンペーンについて説明します。キャンペーンはプラットフォームUIで明示的に作成されなくなりますが、引き続き自動的に作成され、データの配信および管理のために内部で使用されます。キャンペーンごとに一意のキャンペーンIDがあります。
前提条件
- OracleにSSH公開キー(公開キーのみ)を提供する必要があります。
- ユーザー・プロファイル・データは、サーバーへのリアルタイムPOSTリクエストを介して受信できます。または、SFTPサーバーからバッチ・ファイルをダウンロードできます。
- リアルタイムPOSTリクエストを介してデータを受信するには、サーバーサイドのプロファイル・ストアがあり、サーバーサイドでデータを受信できる必要があります。
- 使用するサーバーで、秒当たり500件以上のリクエストを処理できる必要があります。秒当たり6,000件のリクエストが推奨されます。
- 使用するサーバーで、秒当たり45 MB以上を処理できる必要があります。
- サーバーに送信されたJSON POSTリクエストを解析できる必要があります(バッチ・ファイルでユーザー・データを受信する場合は必要ありません)。
- Oracle Data CloudプラットフォームとのIDスワップが可能である必要があります。Oracle Data Cloudコア・タグ、イメージ・ピクセルまたはSDKを介して、サイトまたはモバイル・アプリからプラットフォームに一意のユーザーIDを渡すことができる必要があります。
- 所在地が欧州連合(EU)であるユーザー・プロファイルを受信する予定の場合は、オラクル社の一般データ保護規則(GDPR)使用権契約に署名している必要があります。この契約を取得して署名するには、オラクル社のアカウント担当者にお問い合せください。
- 開発者リソースが、SDTインテグレーションで使用できる状態になっている必要があります。
一般的ではありませんが、サーバーのホワイトリスト登録が必要な顧客所有のエンドポイントに、オラクル社がファイルを配信することがあります。SFTPサーバーをホワイトリスト登録する必要がある顧客については、OCIのフェニックスのデータ・センターのパブリックIP範囲をホワイトリスト登録することをお薦めします。
有効なアドレスのリストについては、https://docs.cloud.oracle.com/en-us/iaas/Content/General/Concepts/addressranges.htmを参照してください。
これにより、新しいサーバーに移行する場合、および現在のIPアドレスが変更される場合の将来の互換性が確保されます。現在、このIPアドレスから移行する予定はありませんが、将来の変更のために、その権利を留保しています。
OCIのフェニックスのデータ・センターのIP範囲全体をホワイトリスト登録できない場合は、sftp.bluekai.comをホワイトリスト登録できます。
129.146.213.6
このトピックの内容
IDスワップ・タグの作成およびデプロイ
IDスワップとは、外部サイトまたは外部システムとOracle Data Cloudの間で相互のユニークID(UUID)を交換し、紐付ける機能です。ユーザーがWebページを訪問するなどアクションを実行したタイミングでIDスワップを実行することができます。紐付けられたUUIDはOracle ID Graph内でリンクされたユーザー・プロファイルとして管理されます。この同期によって、次のシナリオでSDTを介してデータを受信できるようになります。
- デスクトップ・サイト: 使用する環境に応じて、Oracle Data Cloudコア・タグ(推奨)またはイメージ・ピクセルに対するコールを実行します。Oracle Data Cloudコア・タグには、UUIDとユーザー属性を送信するためのHTMLコードおよび組込みJavaScript関数が含まれ、サイトまたはタグ管理システムに直接デプロイできます。イメージ・ピクセルは、通常、表示メディアなど、タグ・コールを実行するためにピクセルが必要となる環境で使用されます。
- モバイル・サイトおよびモバイル・ハイブリッド・アプリ: モバイル・サイト用のOracle Data Cloudコア・タグをデプロイします。
- モバイル・アプリ(ネイティブおよびハイブリッド): Oracle Data Cloud AndroidおよびiOS SDKをアプリに実装します。
リアルタイムSDT
リアルタイムSDTエンドポイントを使用すると、ユーザーに関するデータがHTTP POSTまたはGETリクエストを介して収集されるときに、ユーザー・データを受信できます。ユーザー・データは、ご使用のネットワークまたはOracle Data CloudネットワークでIDが同期された後、サーバーに直接転送されます。
デフォルトでは、ユーザー・データは認証なしで送信されます。データは、選択したエンドポイントに、共通UUIDを含む特定のJSON形式で送信されます。
SDTリアルタイム実装では、POSTリクエストを使用する必要があります。これには、ユーザーごとに複数のカテゴリを含めることができ、レガシーGETリクエストのようなデータ長への制限はありません。
SDTリアルタイム・エンドポイントを使用するには:
- ユーザー・データを受信するようにサーバーを構成します。これには、サーバーに送信されるJSON POSTリクエストの解析方法の実装が含まれます。
- カスタマ・サクセス・マネージャまたはコンサルタントに連絡して、次の情報を伝えます。
- データ・トランスファーURL。Oracle Data Cloudプラットフォーム・バックエンド・サーバーにより、ユーザー・データをサーバーに送信するために使用されるURL。異なるIDタイプ(CookieまたはMobile Advertising ID (MAID))にリンクされているデータおよび異なる国や地域からのデータの受信方法に応じて、複数のURLを使用できます。
- サポートされるIDタイプ。異なるIDタイプに対して個別のエンドポイントを使用する場合は、エンドポイントに配信されるタイプを指定します。たとえば、個別のCookieおよびMAIDエンドポイントを使用できます。
- サポートされる国/地域。異なる国および地域に対して個別のエンドポイントを使用する場合は、エンドポイントに配信される国と地域を指定します。たとえば、米国(US)、ヨーロッパ、中東およびアフリカ(EMEA)、アジア太平洋(APAC)に対して個別のエンドポイントを使用できます。
SDTリアルタイム・データ・トランスファー・プロセス
データは、次の順序でサーバーに転送されます。
- Oracle Data Cloudプラットフォームによって、プラットフォームUUIDおよびキャンペーン・パラメータがサーバーに送信されます。
- データがエンドポイントによって正常に受信された場合、エンドポイントはHTTP 2xxレスポンス・コード(200、202または204)を返します。エンドポイントがHTTP 2xxを返した場合、データは受信されたと考えられます。
- サーバーによって、プラットフォームUUIDまたはご使用のUUIDが検索され、新しいデータ属性がユーザーに関連付けられ、HTTPレスポンス・コードが返されます。エンドポイントでSDTデータを処理できなかったか、受け入れられなかった場合、エンドポイントはHTTP 2xx以外のレスポンス・コードを返し、データへの課金を防ぎます。HTTP 2xx以外のレスポンス・コードが返されると、SDTシステムではデータを破棄し、後続の配信の調整を開始します。
重要: SDTエンドポイントに送信されるHTTPリクエストのデフォルト・タイムアウトは2秒です。
- プラットフォームではエンドポイントからエラーを受信すると、配信を試みたデータを破棄し、エンドポイントのエラー率のパーセンテージを更新します。このエラー率は、エンドポイントへの新規データ配信の調整を決定する計算で使用されます。調整の計算は、次のようになります。
配信率= (100 -エラー率) + 5
たとえば、エラー率が10%の場合、プラットフォームはデータ配信率を95%に調整します。エラー率はリアルタイムで更新されます。そのため、エンドポイントで障害が発生した場合、プラットフォームでは即時にデータ配信率を調整し、最小値である5%に下げます。
JSON POST形式
JSON形式のデータには、次の例に示すように、落札したキャンペーンのCategoryIDおよびTimestampを表示するCATEGORIES配列が含まれます。
{
"DeliveryTime": "Fri May 07 08:24:48 PDT 2016",
"DestinationId": 1,
"PixelCount": 1,
"Pixels": [{
"BkUuid": "6KMp1LAq99eQPyOu",
"BKClear": 1,
"CampaignId": yourCampaignID,
"Categories": [{
"Id": 5915,
"Utc": 1375750288
}, {
"Id": 5962,
"Utc": 1462609486
}],
"PartnerUuid": "YOUR_UUID",
"PixelUrl": " https://stags.bluekai.com/site/YOUR_SITE_ID?limit=0&account=AO+",
"UtcSeconds": 1462609486
}]
}
次の表は、HTTP POSTリクエストに含まれるJSON形式のデータのパラメータを示しています。
| フィールド | Type | 説明 |
|---|---|---|
| DeliveryTime | string | ユーザー・データが配信された時点のタイムスタンプ |
| DestinationID | integer | IDスワップ・タグに含まれていたサイトID |
| PixelCount | integer | リクエストで配信されたピクセルの数 |
| BkUuid | string | ユーザーの暗号化された一意のプラットフォームID |
| BKClear | integer | BKClear = 1の場合は、POSTレスポンスで受信されたカテゴリによって、ユーザーのプロファイル内の既存のカテゴリがすべて上書きされます。 このパラメータがレスポンスに含まれていない場合は、ユーザーのプロファイル内の既存のカテゴリにすべての新規カテゴリが追加されます。 |
| CampaignId | integer | 落札したキャンペーンのID |
| CategoryId | comma-delimited string | ユーザーが属するカテゴリID |
| PartnerUuid | string | このユーザーのユニークID (IDスワップでプラットフォームに返された場合) プラットフォームによってIDスワップがトリガーされたが、リダイレクトされなかったか、リダイレクトが失敗した場合、この値は不明になります。プラットフォームが不明なパートナUUIDを転送しないようにリクエストできます。この場合、IDが同期されているユーザーのみが転送されます。 |
| PixelUrl | string | SDT宛先にキャンペーンを関連付けるために使用されるIDスワップ・タグのURL すべての標準マクロが展開されます。使用可能なすべてのマクロのリストは、ピクセルURLマクロを参照してください。 |
| Primary ID | string | MAIDまたはプライベートIDの場合、IDのタイプと16進数。たとえば、idfa=6D92078A-8246-4BA4-AE5B-76104861E7DCです。 |
| Primary ID without Prefix | string | MAIDまたはプライベートIDの場合、16進数のみ。たとえば、6D92078A-8246-4BA4-AE5B-76104861E7DCです。 |
| Timestamp | string | 落札イベントが発生した時点のタイムスタンプ |
| UTCSeconds | integer |
カテゴリが最後にユーザーのプロファイルに追加された時刻 |
ノート: モバイルIDを受け入れると、マーケティング担当者および広告主に、モバイル・アプリ・ユーザーをそのオンラインでの行動に基づいてターゲットするための機能を提供できます。Oracle Data Cloudでは、Mobile Advertising ID (MAID)にリンクされたユーザー・データをあなたのプラットフォームに配信できます。このIDは、モバイル・アプリから導出される場合はデバイスIDとも呼ばれます。プラットフォームでは、IDFA、ハッシュ化されたIDFA、ハッシュ化されたAndroid ID、Google Advertising IDおよびハッシュ化されたGoogle Advertising IDにリンクされているユーザー・データを送信できます(ハッシュ化されたIDは、SHA-1またはMD5のいずれかの暗号化を使用して送信できます)。あなたのプラットフォームでMAIDを受信する方法の詳細は、こちらをクリックしてください。
新しいSFTPサーバーのIPアドレスのホワイトリスト登録
SDTが顧客所有のエンドポイントにファイルを配信するいくつかのケースでは、SFTPサーバーをホワイトリスト登録することが必要になる場合があります。SFTPサーバーをホワイトリスト登録する必要がある顧客については、Oracle Cloud Infrastructureのフェニックスのデータ・センター(us-phoenix-1)のパブリックIP範囲をホワイトリスト登録することをお薦めします。ホワイトリスト登録により、新しいサーバーに移行する場合、および現在のIPアドレスが変更される場合の将来の互換性が確保されます。
使用可能なIPアドレス範囲に関する現在の情報は、Oracle Cloud Infrastructureアドレス範囲を参照してください。
フェニックスのデータ・センターのIP範囲をホワイトリスト登録できないか、する意思がない場合は、sftp.bluekai.com: 129.146.213.6をホワイトリスト登録できます。現在、このIPアドレスから移行する予定はありませんが、将来の変更のために、その権利を留保しています。
SDTバッチ
SDTバッチ・エンドポイントを使用する場合、ユーザー・データは、プリファレンスに従って書式設定された、毎時バッチ・ファイルまたは日次バッチ・ファイルに保存されます。このバッチ・ファイルは、Oracle Data CloudサーバーまたはAmazon S3バケットからダウンロードし、システムにインポートします。データ・ストレージ容量に制限がある場合、またはサーバーにSDTを実装するためのリソースがない場合に、このオプションを選択します。
SDTバッチを使用してユーザー・データを受信するには:
- システムを構成して、バッチ・ファイルを自動的に受信できるようにします。
- SFTPを使用する場合は、Oracle Data CloudサーバーでSFTPアカウントにログインし、SFTPを介してファイルをダウンロードするための自動化された方法が必要になります。
- S3を使用する場合は、Amazon S3バケットからバッチ・ファイルをエクスポートするための自動化された方法が必要になります。
- S3を使用する場合は、この目的のためにS3ユーザーを作成し、バッチ・ファイルが格納されるバケットへの書込みアクセス権をそのユーザーに付与します。
- カスタマ・サクセス・マネージャまたはコンサルタントに連絡して、次の情報を伝えます。
サポートされるIDタイプ。異なるIDタイプに対して個別のバッチ・ファイルを使用する場合は、エンドポイントに配信されるタイプを指定します。たとえば、個別のCookieおよびMAIDファイルを使用できます。
サポートされる国/地域。異なる国および地域に対して個別のバッチ・ファイルを使用する場合は、ファイルに含める国と地域を指定します。たとえば、US、EMEAおよびAPAC用に個別のファイルを使用できます。
SSH公開キー :キーの公開側のみが必要です。
- SDTバッチ方法: SFTPまたはS3を選択します。SFTPを使用している場合は、Oracle Data CloudによりSFTPアカウントおよび資格証明が提供されます。
- S3証明書: S3を使用している場合は、バケット名、ユーザー・アクセス・キーおよび秘密キーをOracle Data Cloudに提供します。これらの資格証明を使用して、バッチ・ファイルがバケットにアップロードされます。
- バッチ頻度: バッチがバッチ処理される間隔(毎時または日次のいずれか)。
- バッチ・フィールドのデリミタ: バッチ・ファイルのフィールドを区切るために使用する文字。バッチ出力ファイルにはユーザー・レコードごとに1行が含まれ、各レコードのフィールドは1つのデリミタで区切られます。Categoriesフィールドなどの一部のフィールドには、内部的に、ファイルの解析に影響する可能性がある1つ以上のデリミタが含まれているため、タブ、スペースまたは縦棒のデリミタを使用することをお薦めします。コロン、カンマおよびセミコロンのセパレータもサポートされます。
- バッチ・フィールド: バッチ・ファイルに含める、サポートされている1つ以上のフィールドと、それらのフィールドの正確なリスト順を選択します。
サポートされるバッチ・フィールド
| フィールド | タイプ | 説明 |
|---|---|---|
| Campaign ID | integer | 落札したキャンペーンに割り当てられるユニークID |
| Categories | comma-delimited string | ユーザーが属するカテゴリID ノート: このフィールドをSDTバッチ・ファイルに含め、デリミタとしてカンマを使用する場合は、確実にファイルを解析できるように、このフィールドが表示されている最後のフィールドであることを確認してください。または、別のデリミタを使用して、フィールドを任意の順序で配置することもできます。 |
| Categories with Timestamps | object | カテゴリ、時間(カテゴリがユーザーのプロファイルに最後に追加された時間)および落札したキャンペーンに関連付けられているサイトのリスト。 ノート: このフィールドをSDTバッチ・ファイルに含め、デリミタとしてカンマ、セミコロンまたはコロンを使用する場合は、確実にファイルを解析できるように、このフィールドが表示されている最後のフィールドであることを確認してください。または、別のデリミタを使用して、フィールドを任意の順序で配置することもできます。 |
| IP address | string | ユーザーのブラウザのIPアドレス |
| Obfuscated Oracle Data Cloud UUID | string | ユーザーの暗号化された一意のOracle Data Cloud ID |
| Partner UUID | string | ユーザーのユニークID。 プラットフォームでIDスワップがトリガーされたが、リダイレクトされなかった場合、この値は不明になります。 |
| Pixel URL | string | キャンペーンをSDT宛先に関連付けるために使用される正規表現ピクセルのURL |
| Referrer | string | プラットフォームへのタグ・リクエストを生成したWebページのURL |
| Tag URI | string | tags.bluekai.comへのコールのURL (phintを含む) |
| Win Time | string | キャンペーンが落札した時間(ユーザーのアクティビティと同時)。このフィールドを使用して、データが配信された時間を判別できます。ファイル名のタイムスタンプは使用しないでください。 |
バッチ・ファイルの命名規則
| 頻度 | 書式 | 例 |
|---|---|---|
| 毎日 | foldername_YYYMMDD.log.gz | BlueKai_20170718.log.gz |
| 毎時 | foldername_YYYMMDDHH.log.gz | BlueKai_2017071814.log.gz |
ここで、foldernameにはSFTPの名前または場所と同じ名前を使用します。
ノート:
- 毎時バッチ・ファイルまたは日次バッチ・ファイルの配信に遅延がある場合、遅延したファイルに含まれるはずだったデータは次のファイルに含められます。
- データに関連する時刻または日付を把握するために、ファイル名のタイムスタンプを使用しないでください。「Win Time」フィールドを使用して、ユーザーがカテゴリに分類され、その結果、キャンペーンに適格とされ、そのユーザーのデータがファイルに書き込まれた時間を判別できます。
- (毎時ファイルのみ)夏時間が開始するときには、毎時バッチ・ファイルを重複して受け取ります。逆に、夏時間が終了するときには、毎時ファイルが1つスキップされます。
SDTバッチを使用して、ターゲット・オーディエンスのユーザーに対する広告ターゲッティングを送信するには:
- Oracle Data CloudサーバーでSFTPアカウントにログインし、バッチ・ファイルをダウンロードします。または、Amazon S3バケットからバッチ・ファイルをエクスポートします。
- システムにバッチ・ファイルをインポートし、ユーザー・データを処理します。
- My Oracle Support (MOS)に連絡して、ユーザー・データ受信および処理していることを確認します。
ユーザー・データの配信
あなたのプラットフォームにユーザー・データを配信するには:
- Oracle Data Cloudプラットフォームでは、IDスワップ・ピクセルのドメインをSDTエンドポイントに関連付ける、特別な正規表現ピクセルが作成されます。この関連付けにより、プラットフォームであなたをSDTパートナとして識別できるようになります。プラットフォームでは、SDTを開始するために、IDスワップ・ピクセルのURLパス内で定義されているパターン(サブドメインまたはパラメータ)を探し、照合します。プラットフォームは、通常、ピクセル内のサイトIDに基づいてマッチを識別します。
ノート: AudienceOnモバイル・パートナに対しては、Oracle Data Cloudはすべてのサードパーティ・データを継続的にパートナに転送するためのキャンペーンを設定します。プラットフォームでは、正規表現ピクセルを使用して、そのキャンペーンをデータ・トランスファーURLに関連付けます。
- クライアントによってオーディエンス・データが配信され、これにより自動的にSDTデータ配信が開始されます。正規表現ピクセルは、クライアントのキャンペーンに自動的にリンクされます。
- SDTリアルタイムを使用する場合は、HTTP POSTリクエストに含まれるJSON形式のデータまたはGETリクエストのURLのデータを解析して、広告ターゲッティングをユーザーに送信します。
SDTデータのマッピング
次のいずれかの方法を使用して、受信するSDTデータをあなたのプラットフォームのオーディエンス・セグメントオブジェクトにリンクします。
- オーディエンス収集: オーディエンス・オブジェクトを作成し、Oracle Data Cloudプラットフォームと実行プラットフォームの間でマッピングするための自動化された方法。Oracle Data Cloudプラットフォームでは、APIを介してプログラマティックにプラットフォーム内にオーディエンス・オブジェクトを作成し、APIが、プラットフォームでユーザーを格納およびターゲッティングするために使用されるオブジェクトを返します(このオブジェクトは、通常、ユーザー・オーディエンス、セグメントまたはリストと呼ばれます)。この自動マッピングが発生した後、SDTを介して受信するユーザーをオーディエンス・オブジェクトに追加できます。
- 管理マッピング。オーディエンス収集インテグレーションをサポートできない場合に推奨される代替マッピング方法。管理マッピングでは、リアルタイム電子メール通知およびマッピングUIを使用して、いつクライアントのデータをあなたのプラットフォームでマッピングする必要があるかを通知し、マッピングが完了すると自動的に配信を開始します。
- 手動マッピング: 次の手動の方法を使用できますが、これらは推奨されるマッピング・ソリューションではありません。
- キャンペーンレベルのマッピング: この手動の方法には、通常、クライアントがあなたのプラットフォームでオーディエンス/セグメント・オブジェクトを作成して名前を付け、そのオーディエンスに関連付けるキャンペーンIDを指定する過程が含まれます。
- オーディエンス共有(タクソノミAPI): このカテゴリレベルのマッピング方法では、クライアントがあなたとオーディエンスを共有するため、自分のシートからオーディエンスの名前と構成を取得できます。また、カテゴリAPIをコールし、
parentIdフィールドにカテゴリIDを渡したり、showReceivedAudienceCategoriesフラグを有効にして共有オーディエンスに含まれるカテゴリを返したり、fullpathフラグを有効にしてカテゴリのタクソノミのフルパスを返すことができます。 - オーディエンス共有(オーディエンスAPI): このカテゴリレベルのマッピング方法では、クライアントがあなたとオーディエンスを共有します。これにより、クライアントの名前とそのオーディエンスの名前を含む電子メール通知が生成されます。これを使用して、自分のOracle Data Cloudプラットフォーム・シートからオーディエンスの構成を取得できます。オーディエンスAPIをコールして、次のことを実行することもできます。
- クライアントから受け取ったオーディエンスの名前を
name_or_idフィールドに渡して、GETリスト・コールを行います。オーディエンスAPIから、オーディエンスIDが返されます。 - このオーディエンスIDを使用して、GET読取りコールを実行します。オーディエンスAPIレスポンスに、オーディエンス構成を含むセグメント・オブジェクトが含まれます。
- クライアントから受け取ったオーディエンスの名前を
- カテゴリのホワイトリスト登録: データ配信に含まれるカテゴリをホワイトリストに登録します。これにより、クライアントのカテゴリの名前およびIDを取得できます。
Oracle Data Cloudオプトアウト・ポリシー
オラクル社では、Oracle Data Cloudプラットフォームからサードパーティ・データを受信するすべてのパートナに、サードパーティの関心ベースの広告をオプトアウトしたユーザーのデータを削除することを義務付けています。Oracle Data Cloudからパートナに、オプトアウトしたユーザーのデバイス識別子およびブラウザ識別子のダウンロード可能なリストが提供されます。最近オプトアウトしたユーザーの識別子を含めるために、オプトアウト・リストは毎日更新しています。
パートナの要件
Oracle Data Cloudからサードパーティ・データを受信した場合は、オプトアウトしたユーザーのデバイス識別子およびブラウザ識別子をデータから削除する必要があります。これらの識別子を削除することで、オプトアウトしたユーザーが、Oracle Data Cloudによって提供されるデータに基づく広告に対してターゲットされることがなくなります。
処理するデータ・タイプに関連する識別子のダウンロード可能なリストへのリンクが提供されます。たとえば、IDスワップされたパートナベースのユーザーID、Oracle Data Cloud Cookie IDおよびMAIDを使用している場合、パートナID、Oracle Data Cloud Cookie IDおよびMAIDのリンクを受け取ります。
オプトアウト・リストは毎日更新されます。少なくとも週に1回は、Oracle Data Cloudオプトアウト・リストにアクセスまたはダウンロードして、データを削除する必要があります。週に1回の頻度であれば、オプトアウトしたユーザーのデータを適時に削除できます。
これが必要な理由
Oracle Data Cloudからサードパーティ・データを受信している場合、オプトアウトしたユーザーのデータを削除する契約上の義務があります。この要件により、一般データ保護規則(GDPR)やカリフォルニア州消費者プライバシ法(CCPA)などの、ローカルおよびグローバルなデータ・プライバシ規則に準拠できます。
また、Network Advertising Initiative (NAI)やDigital Advertising Alliance (DAA)などの業界団体は、ターゲット広告を受信しないことを選択したユーザーにオプトアウト・メカニズムを提供することをメンバーに義務付けています。
Oracle Data Cloudによるオプトアウト・フィードの生成および配信方法
Oracle Data Cloudは、次の表にリストされているソースから各データ・タイプのオプトアウトを収集します。オプトアウトされたブラウザおよびデバイスの識別子のリストを準備し、セキュアなURLを使用してアクセスする場所にテキスト・ファイルとして保存します。オプトアウト・ファイルの場所のURLは、アカウント・マネージャから提供されます。その場所からファイルをダウンロードして処理できます。配信エンドポイントごとに個別のURLを受け取ります。
オプトアウト・ファイルは毎日更新し、それぞれの場所にある以前のバージョンを上書きしています。新しいファイルには、以前のオプトアウトに、過去24時間に収集されたオプトアウト識別子の増分更新が追加されたものが含まれています。オラクル社では、IDタイプごとに個別のオプトアウト・リストを管理しています。
パートナIDのリストには、その特定のパートナの識別子のみが含まれます。他のデータ・タイプのリストには、オプトアウトしたすべてのユーザーの識別子が含まれます。自分のビジネスに関連するIDを抽出するプロセスを開発する必要があります。
次の表に、オプトアウト・ソース、データ保存期間および各データ・タイプに関するその他の情報を示します。
| データ・タイプ | ブラウザまたは モバイル |
カスタマイズ・リスト または汎用リスト |
オプトアウト・ソース | データ保存期間 | ファイル形式 |
|---|---|---|---|---|---|
| パートナベースの一意のユーザーID (PUUID) | ブラウザ | カスタマイズ |
|
90日、累積、ローリング | IDをリストする単一の列 |
| Oracle Data Cloud Cookie ID (BKUID) | ブラウザ | 汎用 | |||
| AddThis Cookie ID | |||||
| DLX Cookie ID | |||||
| MAID | モバイル | 汎用 |
|
10年、累積、ローリング | 2つの列: 1つはデバイスID用、もう1つはデバイス・タイプ用(IDFA、ADIDなど)。IDタイプのマッピングについては、続く内容を参照してください |
| SHA256でハッシュ化されたMAID | |||||
| 登録に基づくID (オフライン・データに一致するID) | オフライン | カスタマイズ |
|
無期限 |
IDをリストする単一の列 |
MAIDデバイス・タイプID
| デバイス・タイプID | ||||
|---|---|---|---|---|
| ID | 名前 | OS /コメント | 形式 | 例 |
| 0 | Cookie | Web Cookie | AddThis: ^[a-fA-F0-9]{16}$ | AddThis: 502db0b585437660 |
| BlueKai: ^[a-zA-Z0-9/+]{16}$ | BlueKai: /Ux999COlkGSqq5R | |||
| Datalogix: ^\\d+$ | Datalogix: 2015031014070046656263118542 | |||
| OUID: ^[a-fA-F0-9]{52}$ | OUID: 5ae9efdd0001099018436605758a0827e54d16983cdf002440c4 | |||
| 1 | IDFA | iOS | ^[a-fA-F0-9]{8}-([a-fA-F0-9]{4}-){3}[afA- F0-9]{12}$ | 5ee17182-f919-47c1-88f7-1099f570a2d1 |
| 2 | Android ID | 古いAndroidバージョン、あまり一般的でない | ^[a-zA-Z0-9]{15,16}$ | fdda1e69b3cbe38a |
| 4 | WiFi Macアドレス | 古く、使用されていない | ^([0-9A-Fa-f]{2}[:-]){5}([0-9A-Faf]{ 2})$ | 00:25:96:FF:FE:12:34:56 |
| 5 | IDFA (SHA1) | iOS | ^[a-fA-F0-9]{40}$ | f0693138f37dd6b3143bc1eb81035d27722c24e3 |
| 6 | IDFA (MD5) | iOS | ^[a-fA-F0-9]{32}$ | 19f94da668950112ce7bf1845d104e8b |
| 7 | Android ID (SHA1) | 古いAndroidバージョン、あまり一般的でない | ^[a-fA-F0-9]{40}$ | cf8045124d6746bbd0b59173d0ae701de33148f1 |
| 8 | Android ID (MD5) | 古いAndroidバージョン、あまり一般的でない | ^[a-fA-F0-9]{32}$ | dcc1f68b0632daeecf64eb323fe779e3 |
| 9 | AAID | Android | ^[a-fA-F0-9]{8}-([a-fA-F0-9]{4}-){3}[afA- F0-9]{12}$ | d543329a-1c97-4b90-84bb-588280dcfcc5 |
| 12 | AAID (SHA1) | Android | ^[a-fA-F0-9]{40}$ | f003e3b2c0713b2613b0c302e20ba99ee63fc275 |
| 13 | AAID (MD5) | Android | ^[a-fA-F0-9]{32}$ | 01b28632ef87e198fd9e926b40199208 |
| 20 | OpenUDID | 古いiOSバージョン、あまり一般的でない | ^[a-zA-Z0-9]{20}$ | 613b0c302e21f68b066b |
オプトアウト・プロセスのセキュリティ
Oracle Data Cloudでは、オプトアウト・リスト・ファイルはセキュアなAmazon S3バケットに格納されます。Oracle Data Cloudは、AWSの事前署名済URLを使用して、バケットの場所を外部で安全に共有します。これらのAWS S3事前署名済URLによって、ユーザー・リクエストがオプトアウト・リスト・ファイルにリダイレクトされます。
パートナに提供される最終的なエンドポイントURLには、ランダムな文字列の秘密キーを使用して安全にトークン化されたペイロード(そのパートナの属性に固有のS3パス)が含まれます。
よくある質問 (FAQ)
保守やその他のスケジュールされたダウンタイムのために、一定期間サーバーがオフラインになる場合はどうなりますか。
一定期間サーバーがダウンすることがわかっている場合は、その期間中、データ配信をアイドルに設定する必要があります。この問題に関して質問がある場合は、担当のクライアント・サービス・マネージャにお問い合せください。
SDTでもピクセルが必要なのはなぜですか。
Oracle Data Cloudプラットフォームでは、サーバー間のレスポンスをトリガーするための識別子としてピクセルURLを使用しています。プラットフォームでは、サーバーサイド・データ・トランスファーを開始するために、正規表現ピクセルを使用して購入者からの定義済パターンを探し、照合します。パターンは、ピクセルURLパスの任意の一部分(サブドメインまたはパラメータ)です。このサーバーサイド・データ・トランスファーをアクティブ化する方法を使用することで、プラットフォームでは、Oracleのシステム内で使用する現在のピクセル・トランスファー・ワークフローとまったく同じピクセルをあなたがクライアントに提供できるようにします。プラットフォームでは、定義されたSDT形式にマッチするピクセルを見つけた場合、自動的にSDTを使用します。
IDスワップ・ピクセルをiframe内に配置できますか。
はい。IDスワップ・ピクセルはiframe内でも機能します。
有効期限のデフォルト期間はありますか。
すべてのCookieは30日後に期限切れになる必要があります。ただし、可能な場合、常に、購入者が有効期限を広告キャンペーンのリーセンシと一致させることをお薦めします。たとえば、直近7日間以内に旅行するオーディエンスにリーチするためにTravelセグメントを使用する場合は、7日間を過ぎたらCookieを期限切れにする必要があります。
JSON POSTで受信する要素のうち、実際にデータ(CampaignId、CategoryId)を定義するものはどれですか。
データはCategoryIdによって表されます。ユーザーは複数のCategoryIdに所属することができ、JSON POSTには複数のCampaignIdが含まれている場合があります。Oracleのシステム内のキャンペーンは、オーディエンスをターゲットするために設定されたエンティティです。オーディエンスは複数のデータ・カテゴリで構成されます。したがって、1人のユーザーが1つ以上のキャンペーンに含まれている場合や、各キャンペーンに1つ以上のカテゴリIDが含まれている場合があります。
すべてのPOSTでユーザーのすべてのセグメントを再送信していますか。
いいえ。差分更新のみを送信しています。特定のユーザーについて、過去30日以内に転送されなかったデータのセグメントのみが送信されます。
データを複数のデータ・トランスファーURLに送信できますか。
プラットフォームからは、1つのエンドポイントにのみデータが送信されます。通常、JSON POST内で返されたキャンペーンIDまたはピクセルURL、あるいはその両方に基づき、必要に応じてデータを解析します。オラクル社では、キャンペーンごとに、特定のパラメータを「Pixel URL」に追加できます。
ユーザーが、Oracle Data Cloudプラットフォームによるトラッキングを停止することを希望した場合、どうなりますか。この情報は私たちにどのように伝えられますか。そのユーザーのデータを、当社のデータベースから削除する必要はありますか。
ユーザーがオプトアウトした場合、プラットフォームではそのユーザーに関するカテゴリレベルの情報をすべてプロファイル・ストアから削除し、サーバーサイドに格納される無視フラグを使用してオプトアウトを保持します。またプラットフォームでは、ユーザーのブラウザ・キャッシュにCookieとして、ユーザーのオプトアウト・ステータスを格納することもあります。プラットフォームを介してオプトアウトが伝播された後は、オプトアウト・ステータスを含む、そのユーザーに関する情報は伝送されなくなります。
Oracle Data Cloudではオプトアウトしたユーザーに関するフィードを毎日提供しているため、すでに配信されたユーザーをあなたのプラットフォームでのターゲッティングから削除できます。
技術サポート
SDTインテグレーションの設定中の技術サポートは、Oracle Data Cloudインテグレーション・サポート・エンジニア(ISE)によって提供されます。インテグレーションがアクティブ化された後は、ISEに連絡してサポートを要請できます。サードパーティ・データを受信する場合は、パートナ・マネージャが割り当てられるため、パートナ・マネージャに連絡してサポートを要請してください。