データ収集アプリのパートナになる
データ収集は、システムのデータを分類して、Oracle Data Cloudプラットフォームのカテゴリにオンボーディングするプロセスです。このドキュメントでは、プラットフォームWebサービスを使用したデータ収集の概要を説明します。ユーザー・インタフェースの使用などの手順の詳細は、データ収集を参照してください。
EUデータ。所在地が欧州連合(EU)であるユーザー・プロファイルのデータをオンボーディングするには、オラクル社の一般データ保護規則(GDPR)への利用許諾書に署名している必要があります。この契約を取得して署名するには、オラクル社のアカウント担当者にお問い合せください。
プラットフォームAPIに対する一連のコールによって、データをプログラマティックに収集します。具体的には、APIコールを実行して、データを分類するためのサイト、カテゴリおよびルールを作成します。追加のAPIコールで、カテゴリをクライアントのタクソノミにホワイトリスト登録し、データをオンボーディングします。
たとえば、Supertronxというクライアントが、自社のスマートフォン購入者のすべてのデータをシステムからDMPにインポートすることを希望しているとします。まず、Supertronxのデータを一意に識別するサイトID (48419)を生成します。このサイトIDは、そのデータをオンボーディングする後続のすべてのユーザー・データAPIコールで渡します。次に、スマートフォン購入者のカテゴリを作成します(カテゴリID 341150)。このカテゴリをクライアントのタクソノミにホワイトリスト登録します。最後に、購入品目がスマートフォンで、かつサイトIDが48419である場合に、ユーザーをSmartphone Purchasersカテゴリに追加するというルールを作成します。このルールの、購入品目がスマートフォンであるという条件は、phintと呼ばれるキーと値のペアとして指定されます。このphintがサイトIDとともにユーザー・データAPIに渡されると、ユーザーがSupertronxのタクソノミのSmartphone Purchasersカテゴリに分類されます。
次のイメージは、ユーザー・データをタクソノミにオンボーディングするために、サイト、カテゴリ、ルール、ホワイトリスト登録およびユーザー・データAPIがどのように使用されるかを示しています。
重要: ユーザー・データAPIに渡すIDは、Oracle Data Cloud Cookie ID、パートナID (電子メール・ハッシュ、アカウントIDハッシュ、Cookie IDまたは別の識別子)またはMobile Advertising ID (MAID)にリンクしている場合があります。パートナIDを渡す場合は、IDスワップによってパートナIDがユーザーのOracle Data Cloud Cookieと同期されている必要があります。
MAIDにリンクされているデータをオンボーディングする場合は、データが、Oracle Data Cloud Cookieへのリンクが要求されない別のGoogle AdIDおよびApple IDFAプライマリID領域に保存されるため、IDスワップは必要ありません。
次の表は、システムのデータをOracle Data Cloudプラットフォームにインポートするために使用されるAPIを表示し、その概要を示しています。APIは、コールする順序で表示されています。
| ステップ | API | 説明 | 1回/繰り返し | コールする時期 |
|---|---|---|---|---|
| 1 | コンテナ | クライアント・データの一意の識別子(サイトID)を生成します。サイトIDは、ルールおよびユーザー・データAPIコールに必要です。 | クライアントごとに1回 | クライアントがBlueKaiインテグレーションを使用するシグナルを示したとき。 |
| 2 | カテゴリ | 特定の属性または行動を共有するユーザーを含むバケットを作成します。 | 繰り返し | クライアントがDMPで分類するユーザーのセグメントを特定したとき。 |
| 3 | タクソノミ権限付与 | カテゴリをクライアントのタクソノミに追加します。 | 繰り返し | 新しいカテゴリを作成する都度。 |
| 4 | ルール | システムの生データをカテゴリにマッピングするルールを作成します。 | 繰り返し | 新しいカテゴリを作成する都度。 |
| 5 | ユーザー・データ | Cookie ID、電子メール・ハッシュまたはモバイル・デバイスIDに対して、データをオンボーディングします。ユーザー当たり1つのコール、秒当たり最大1,000コールがサポートされます。 | 繰り返し | クライアントが、選択したセグメントをDMPにオンボーディングすることを確定したとき。 |
| 5a | バルク | 個別のユーザー・データAPIコールをまとめます。このステップはオプションですが、お薦めします。 | 繰り返し | 個別のユーザー・データAPIコールをまとめた後。 |
Oracle Data Cloud APIコールを実行するには、パートナIDとWebサービス・キーが必要です。IDとキーの取得の詳細は、APIキーの取得を参照してください。
重要: すべてのOracle Data Cloud APIコールは、暗号化データを次の要素を含む文字列バイト配列に生成し、結果の文字列にWebサービス秘密キーで署名することにより、リクエスト署名(bksig)を介して認証される必要があります。
HTTP_METHOD + URI_PATH + QUERY_ARG_VALUES + POST_DATA
詳細は、APIコールの認証を参照してください。
コンテナAPI
BlueKaiコンテナWebサービス(services.bluekai.com/Services/WS/sites)を使用して、サイトIDを作成します。サイトIDによって、クライアントのデータを分類、オンボーディングおよび管理するための一意のネームスペースが定義されます。サイトIDを使用することで、異なるクライアントのデータが異なるのカテゴリに確実に分類されます。
コンテナPOSTリクエストはクライアントの名前と自社のアプリ・パートナIDを取得し、クライアントのデータの管理に使用されるサイトIDを返します。このサイトIDを後続のルールおよびユーザー・データAPIコールに含めます。
APIリファレンス: コンテナAPI
コンテナAPIを使用してサイトIDを作成するには:
- クライアント名およびパートナIDを指定して、POSTリクエストを実行します。リクエストの構文および例は、次のとおりです。
{
"name": {"ClientName"},
"data_transfer_limit": 0,
"partner_id": {yourPartnerId},
"analytics_only": "false",
"transaction_scope": "self",
"blocked_countries":["NL"]
}{
"name": "Supertronx - Data Ingest",
"data_transfer_limit": 0,
"partner_id": 1690,
"analytics_only": "false",
"transaction_scope": "self",
"blocked_countries":["NL"]
}次の例に示すように、APIがサイトIDを返します。
{
"desktop_site": {
"labels": null,
"notes": "",
"name": "Supertronx - Data Ingest",
"id": 58038,
"type": 0,
"allowed_buyers": [],
"private_data": "true",
"partner": {
"name": "Your App Partner Name",
"id": 1690
}, "created_at": "2017-06-17 12:18:14-0500",
"updated_at": "2017-06-17 12:18:14-0500",
"blocked_countries": [
"NL"
],
"redirect_domains": [],
"data_transfer_boost_enabled": "false",
"data_transfer_boost_interval": null,
"transaction_scope": "self",
"analytics_only": "false",
"data_transfer_limit": 0,
"group_id": 48419
}
}
カテゴリAPI
カテゴリAPI (taxonomy.bluekai.com/taxonomy/categories)を使用して、特定の行動を共有するか、同じ属性を持つすべてのユーザーを含むグループを作成します。たとえば、電子メールを開き、オファーをクリックして製品を参照し、カートに製品を追加したか、品目を購入したユーザーのカテゴリを作成できます。つまり、カテゴリは特定のシステム内のデータ項目を表します。ルールAPIをカテゴリAPIとともに使用して、システムのユーザー属性をカテゴリにマッピングします。
APIリファレンス: カテゴリAPI
カテゴリの編成のベスト・プラクティス
クライアントのカテゴリを作成するときには、クライアントがシステムからエクスポートされたデータを簡単に見つけることができ、同じ場所でデータをグループ化する論理的な階層にカテゴリを構造化する必要があります。たとえば、次に示すような階層を作成できます。
カテゴリAPIを使用したカテゴリの作成
クライアント・カテゴリ階層を作成するには、シートのルート・ノードのIDを取得し、クライアントのナビゲーションのみのノードを作成して、ユーザーの特定のカテゴリを作成します。
重要: カテゴリAPIとルールAPIの両方で、作成または更新されるカテゴリおよびルールを含む.txtファイルと.tsvファイルのアップロードがサポートされます。これにより、カタログのカスタマ・データを選択し、ファイルに移植して、移植したファイルをOracle Data Cloudプラットフォームにプログラマティックにアップロードできます。バルク・アップロードの詳細は、(アップロードによる)一括でのカテゴリの追加および編集およびルールのバルク・アップロードを参照してください。
カテゴリAPIを使用してクライアント・カテゴリ階層を作成するには:
- GETコールを実行して、シートのプライベート・ルート・ノードのカテゴリIDを取得します。作成したすべてのカテゴリは、このノードに保存されます。次のパラメータを設定します。
partner.id。パートナIDに設定します。view。OWNERに設定します。q。このパラメータには、URLでエンコードされたPrivateを含む名前を含めます(q=name%20co%20%22Private%22)。
次に、GETリクエストの例を示します。
taxonomy.bluekai.com/taxonomy/categories?partner.id=1690&view=OWNER&q=name%20co%20%22Private%22&bkuid=a33a152dba41b82d16fccd7e87d7d0df243d8625&bksig=WXpqovlKLUL%2BbuYo37Pq9EU%2BPml0IBS6Eqg%2BhJJShp4%3D
POSTレスポンスには、プライベート・ルート・ノードのカテゴリIDが含まれます(次の例では280095)。このカテゴリIDを後続のPOSTリクエストの
parentCategoryパラメータに使用します。{ "items": [ { "id": 280095, "name": "Your Partner Name - Private", "parentCategory": { "id": 344 }, "partner": { "id": 1690 }, ... } ] } - POSTコールを実行して、クライアントのナビゲーションのみのカテゴリを作成します。このカテゴリは、システムからエクスポートされたクライアントのデータがすべて含まれるフォルダとして機能します。
partner.id。パートナIDに設定します。name。クライアント名またはシステムの別の一意の識別子に設定します。parentCategory。前のGETコールによって返されたプライベート・ルート・ノードのカテゴリID (この例では280095)に設定します。isForNavigationOnlyFlag。trueに設定します。isMutuallyExclusiveChildrenFlag(オプション)このノードで作成したカテゴリを相互排他的にする場合は、trueに設定します。相互排他的とは、ユーザーが一度に1つの子カテゴリにのみ分類されることを意味します。ユーザーのプロファイルには、最近タグ付けされたカテゴリのみが保存されます。ユーザーが1つの子カテゴリに分類された場合は、他の子カテゴリから削除されます。たとえば、ユーザーの性別を分類するには、相互排他的に設定された親カテゴリGenderを作成した後、その下に子カテゴリMaleおよびFemaleを作成できます。
次に、POSTリクエストの例を示します。
{
"partner": {"id": 1690},
"name": "Supertronx",
"parentCategory": {"id": 280095},
"isIncludeForAnalyticsFlag": true,
"isForNavigationOnlyFlag": true,
"isMutuallyExclusiveChildrenFlag": false
}APIによってナビゲーション・ノートが作成され、そのカテゴリID (次に示す例では1208763)が返されます。
{
"id": 1208764,
"name": "Supertronx",
"parentCategory": {"id": 280095},
"partner": {"id": 1690},
....
"isForNavigationOnlyFlag": true,
"isIncludeForAnalyticsFlag": false,
"isMutuallyExclusiveChildrenFlag": false,
...
"pathFromRoot": {
"ids": [
344,
280095,
1208763
],
"names": [
"ROOT",
"Your Partner Name - Private",
"Supertronx"
]
},
"status": "active",
"links": []
} - システム内のユーザーの特定のセグメントを表すカテゴリを作成します。各カテゴリの次のパラメータを設定します。カテゴリに明瞭で簡潔な名前を指定し、ステップ2で
parentCategoryフィールドでのPOSTコールから取得したナビゲーションのみのノードのカテゴリID (この例では1208764)を渡します。partner.id。パートナIDに設定します。name。カテゴリを特定する明瞭で簡潔な名前に設定します。parentCategory。ステップ2で返されたナビゲーション・ノードのカテゴリIDに設定します(この例では1208764)。
次の例では、ナビゲーションのみのノードの下に2つのカテゴリSmartphone PurchasersおよびVideo Game System Purchaserを作成しています。
[ { "partner": {"id": 1690}, "name": "Smartphone Purchasers", "parentCategory": {"id": 1208763}, "isIncludeForAnalyticsFlag": true, "isForNavigationOnlyFlag": false, "isMutuallyExclusiveChildrenFlag": false }, { "partner": {"id": 1690}, "name": "Video Game Purchasers", "parentCategory": {"id": 1208763}, "isIncludeForAnalyticsFlag": true, "isForNavigationOnlyFlag": false, "isMutuallyExclusiveChildrenFlag": false } ]POSTレスポンスには、作成したカテゴリのカテゴリID (次の例では1211430および1211431)とその他の情報が含められます。
{ "items": [ { "httpStatusCode": 201, "item": { "id": 1211430, "name": "Smartphone Purchasers", "parentCategory": {"id": 1208763}, "partner": {"id": 1690}, "vertical": {"name": "Your Partner Name" }, ... "isIncludeForAnalyticsFlag": true, "isMutuallyExclusiveChildrenFlag": false, "isExplicitPriceFloorFlag": false, "namespaceId": 1, ... "pathFromRoot": { "ids": [ 344, 280095, 1208763, 1211430 ], "names": [ "ROOT", "Private", "Supertronx", "Smartphone Purchasers" ] }, "status": "active", "links": [] } }, { "httpStatusCode": 201, "item": { "id": 1211431, "name": "Video Game Purchasers", "parentCategory": {"id": 1208763}, "partner": {"id": 1690}, "vertical": {"name": "Your Partner Name" }, ... "isForNavigationOnlyFlag": false, "isIncludeForAnalyticsFlag": true, "isMutuallyExclusiveChildrenFlag": false, ... "pathFromRoot": { "ids": [ 344, 280095, 1208763, 1211431 ], "names": [ "ROOT", "Private", "Supertronx", "Video Game Purchasers" ] }, "status": "active", "links": [] } } ], "size": 2 }
タクソノミ権限付与API
タクソノミ権限付与API (taxonomy.bluekai.com/taxonomy/partnerPermissions)を使用して、アプリ・パートナ・シートからのカテゴリをクライアントのタクソノミにホワイトリスト登録します。これにより、クライアントは、その他のカテゴリと同様、タクソノミ・ツリーからホワイトリスト登録されたカテゴリを表示および選択できます。
重要: タクソノミ権限付与APIコールを実行する前に、Oracle Data Cloudのインテグレーション・サポート・スペシャリストが、カテゴリ/オーディエンスの受信者として、クライアントをシートに追加する必要があります。その後、クライアントのパートナIDを受信します。インテグレーション設定の一部としてクライアントがシステムUIにパートナIDを入力するようにして、このIDを取得することもできます。
APIリファレンス: タクソノミ・パートナ権限API
クライアントのタクソノミにカテゴリをホワイトリスト登録する手順は、次のとおりです
- カテゴリをホワイトリスト登録するPOSTリクエストを実行します。次のパラメータを設定します。
-
partner.id。パートナIDを設定します。 -
buyer.id。クライアントのパートナIDを設定します。 whitelist_categories。ホワイトリスト登録されるカテゴリIDのカンマ区切りリストを含めます。これには、ナビゲーション・ノード・カテゴリとその子カテゴリが含まれている必要があります。-
permissionType。modelingTargetingAndAnalyticsを設定します。 - 複数のOracle Data Cloudパートナ・シートがある場合は、
pid問合せ文字列パラメータでパートナIDを渡す必要もあります。
次に、POSTリクエストの構文を示します。
{
"partner": {"id":yourPartnerId},
"buyer": [{"id":clientParnerId}],
"whitelistCategories": [categoryId 1, categoryId 2, categoryId n],
"permissionType": "modelingTargetingAndAnalytics"
}次に、POSTリクエストの例を示します。
{
"partner": {"id":1690},
"buyer": [{"id":4021}],
"whitelistCategories": [1208764, 1208765],
"permissionType": "modelingTargetingAndAnalytics"
}POSTレスポンスには、ホワイトリスト登録ID (次の例では27789)が含まれます。このIDを使用して、PUTリクエストを介してクライアントに対して追加のカテゴリをホワイトリスト登録したり、タクソノミからカテゴリを削除できます。詳細は、ホワイトリスト登録後のクライアント・タクソノミの変更を参照してください。
[ { "id": 27789, "partner": { "id": 1690, "name": "Your Partner Seat" }, "buyer": [ { "id": 4021, "name": "Supertronx" } ], "whitelistCategories": [ 1208764, 1208765 ], "permissionType": "modelingTargetingAndAnalytics", "createdAt": "2018-03-07T10:08:50-06:00", "updatedAt": "2018-03-07T10:08:50-06:00" } ] -
ホワイトリスト登録後のクライアント・タクソノミの変更
クライアントに対して追加のカテゴリをホワイトリスト登録したり、タクソノミからカテゴリを削除する必要がある場合は、追加または削除されるカテゴリを指定したPUTリクエストを実行できます。問合せ文字列で、元のホワイトリスト登録中にPOSTレスポンスから受信したホワイトリスト登録IDを渡します。本文で、元のPOSTリクエストと同じ一連のパラメータを渡します。ただし、ホワイトリスト登録されるカテゴリの新しいリストでは、削除するカテゴリを除外し、保持または追加するカテゴリを含める必要があります。以前にホワイトリスト登録したカテゴリを除外すると、そのカテゴリはクライアントのタクソノミから削除されます。
ルールAPI
ルールAPI (services.bluekai.com/rest/taxonomyRuleChains)を使用して、カテゴリに追加されるユーザーを決定する一連の条件を作成します。次の条件を指定します。
- is、contains、starts-with、ends-withなどのルール演算子。
- システム内のユーザー属性を表すキーと値のペアであるphint。phintキーでは、英数文字とアンダースコア(a-z、0-9および_)のみがサポートされ、大/小文字は区別されません。キーにスペースを含めないでください。phint値では、すべてのLatin-1文字とUTF-8文字(英数文字と特殊文字)がサポートされます。値の大/小文字は区別されません。
- クライアントをデータ所有者として識別するクライアントのサイトID。
- 条件を満たした場合にユーザーが分類されるカテゴリID。
重要: ルールがOracle Data Cloudピクセル・サーバー全体に伝播するには、30分ほどかかります。新しいルールを作成した後に30分以上待機してから、ルールに含まれているphintを使用してユーザー・データAPIをコールします。
APIリファレンス: ルールAPI
ルールを追加するには:
partner.id問合せ文字列パラメータにパートナIDを指定する、ルールAPIに対するPOSTリクエストを実行します次の例は、問合せ文字列にパートナIDが含まれたルールAPIコールを示しています。
services.bluekai.com/rest/taxonomyRuleChains?partner.id=1690&bkuid=a33a152dba41b82d16fccd7e87d7d0df243d8625&bksig=v85cOJxPFQCWQp%2BeFWsj1rwmHTPe9OOFw%2BUj3KmjTJE%3D
- リクエストの本文で、次のパラメータを設定します。
taxonomyRuleOperator: 使用されるルール演算子のIDを入力します。ルール演算子は、次のいずれかの値にできます。- 1 (==) is: ユーザー・データAPIコールで渡されたphint値がルールの値と完全にマッチする必要があります。
- 3 (_*) starts-with: phint値がルールの値で開始される必要があります。
- 4 (*_ ) ends-with: 渡されるphint値がルールの値で終了する必要があります。
- 5 -(*_*) contains: phint値がルールの値に含まれている必要があります。
taxonomyRuleOperatorParams: 値パラメータのphintキーおよび値の名前を入力します(yourKeyおよびyourValue)。keyまたはvalue1パラメータ名を変更しないでください。categories: ルールが適用されるカテゴリIDを入力します。sites: コンテナAPIを使用して生成したクライアントのサイトIDを入力します。
{ "rules": [ { "taxonomyRuleOperator": { "id": 1 }, "taxonomyRuleOperatorParams": [ { "name": "key", "value": "purchase" }, { "name": "value1", "value": "smartphone" } ] } ], "categories": [ { "id": 1211430 } ], "sites": [ { "id": 58038 }], "partners": [] }APIレスポンスには、次の例に示すようにルールのIDおよびその他の情報が含まれます。
{ "id": 37514815, "rules": [ { "id": 39898800, "operatorExpression": "purchase=smartphone", "taxonomyRuleOperator": { "id": 1, "name": "==", "formula": "{{key}}={{value1}}", "description": "is ", "createdAt": "2016-04-05T21:22:11-05:00", "updatedAt": "2016-04-05T21:22:11-05:00", "status": "active" }, "taxonomyRuleOperatorParams": [ { "name": "key", "value": "purchase" }, { "name": "value1", "value": "smartphone" } ] } ], "categories": [ { "id": 1211430, "name": "Smartphone Purchasers" } ], "ruleChainMetaData": [], "classificationGroups": [], "sites": [ { "id": 58038, "name": "Supertronx" } ], "partners": [], "createdAt": "2018-03-07T13:51:08-06:00", "updatedAt": "2018-03-07T13:51:08-06:00", "status": "active" }
URLベースのルールの作成
WebページのURLのパスまたは問合せ文字列を評価するルールを作成して、カテゴリをWebページおよびリファラにリンクできます。この機能を使用するには、taxonomyRuleOperatorParamsパラメータのyourKeyを次のいずれかに設定してルールAPIをコールし、ルールを追加します。
- __bk_l。WebページのURLのパスまたは問合せ文字列を評価します。この設定を使用すると、カテゴリをWebページにリンクできます。
- __bk_pr。顧客がクリックし、Webページに送られたURLのパスまたは問合せ文字列を評価します。BlueKai CoreTagによって、WebページのリファラURLが自動的に抽出されます。この設定を使用すると、カテゴリをリファラにリンクできます。
ユーザー・データAPI
ユーザー・データAPI (api.tags.bluekai.com)を使用して、ユーザー・データをカテゴリにオンボーディングします。ユーザー・データAPIはユーザー当たり1コールを取得し、秒当たり1,000コールをサポートします。オンボーディングするユーザー・データの量が多いため、バルクAPIを使用して、ユーザー・データAPIコールをバッチ処理することをお薦めします。詳細は、バルクAPIを参照してください。
ユーザー・データAPIをコールする場合は、ユーザーのIDを指定します。次の表は、APIコールに含めることができるユーザーIDを表示し、その説明を示しています。
| IDタイプ | APIパラメータ | 説明 |
|---|---|---|
| BlueKai Cookie ID (BKUUID) | bkuid
|
サーバー・データ・トランスファー(SDT)またはJSONリターン・タグを介して受信した、難読化されたOracle Data Cloud Cookie ID。 |
| パートナID (PUUID) | puserid
|
Oracle Data Cloud Cookie IDにID同期されている電子メール・ハッシュ、アカウントIDハッシュ、Cookie IDまたはその他の識別子。Oracle Data Cloud Cookie IDとのIDの同期の詳細は、IDスワップを参照してください。 |
| MAID (ADIDまたはIDFA) |
|
GoogleまたはAppleデバイスID。MAIDにリンクされているオンボーディング済データは、プライマリID領域に格納されます。Oracle Data Cloud Cookieへのリンクは必要ありませんが、データは、MAIDにリンクされているデータを受け入れるプラットフォームにのみ配信されます。IDFAまたはADIDを渡すには、ccodeフィールドをユーザーのデータが取得された2文字のISO 3166-1 alpha-2国コードに設定し、create_profileフラグを1に設定する必要もあります。これにより、IDスペースの新しいユーザー・プロファイルをプロファイル・ストアに追加できます。プロファイルがすでに存在する場合、phintフィールドで渡すユーザー属性のみが、ユーザーのプロファイルに追加されます。 |
APIリファレンス: ユーザー・データAPI
APIツール:
ユーザー・データをオンボーディングするには:
- ユーザー・データAPIに対するGETリクエストを実行します。URIパスにクライアントのサイトIDを含め、次のパラメータを設定します。
- Oracle Data Cloud Cookie ID (
BKUID)、パートナID (PUUID)またはMAID (IDFAまたはADID)としてのユーザーID。 - ユーザーIDにMAIDを指定した場合:
ccodeをユーザーのデータが取得された国の2文字のコードに設定します。 - ユーザーIDにMAIDを指定した場合、
create_profileフラグを1に設定します。 phintの場合は、purchase=smartphoneなどのキーと値のペアを含めます。
次の例は、PUUIDにリンクされているデータに対するGETリクエストを示しています。
api.tags.bluekai.com/getdata/58038/v1.2?puserid=g3G991WRxNkbKGT6&phint=purchase=smartphone&bkuid=a33a152dba41b82d16fccd7e87d7d0df243d8625&bksig=wN9TzTedbuPXtw0YSaAus2t4LAteWJMakxuAihgfk48%3D
次の例は、MAID (この場合はADID)にリンクされているデータに対するGETリクエストを示しています。
api.tags.bluekai.com/getdata/58038/v1.2?adid=38400000-8cf0-11bd&phint=purchase=smartphone&ccode=US&create_profile=1&bkuid=a33a152dba41b82d16fccd7e87d7d0df243d8625&bksig=wN9TzTedbuPXtw0YSaAus2t4LAteWJMakxuAihgfk48%3D
ユーザー・プロファイルが見つかったか、作成された場合、ユーザー・データAPIは200コードを返します。ユーザーがOracle Data Cloud CookieにID同期されていない場合は、404 User Not Foundエラーを返します。
- Oracle Data Cloud Cookie ID (
バルクAPI
バルクAPIを使用すると、大量のユーザー・データをプログラマティックにオンボーディングできます。このAPIを使用すると、1つのHTTPS POSTリクエストの本文で、ユーザー・データAPIに対する多数のコールをバッチ処理できます。バルクAPIによって、レイテンシが削減され、ユーザー・データAPIに対する大量の個別コールと比較してスループットが最大化されます。
バルクAPIを使用するには、Oracle Data Cloudパートナ・マネージャに連絡してリクエストしてください。リクエストに、1日当たりのサブリクエストの最大数と任意のカスタム要件を含めます。パートナ・マネージャが、バルクAPIコールを実行するためのWebサービス・キーを有効化します。
APIリファレンス: バルクAPI
ユーザー・データのバッチをオンボーディングするには:
- POSTリクエストのヘッダーで、バルクAPIコールに対するPOSTリクエストを実行するには、次のパラメータを設定します。
ApiKey: BlueKai Webサービス・キーに設定します。Accept: application/jsonに設定します。Content-Type: application/jsonに設定します。
- URIパスにメソッド署名を含めます。この署名はリクエスト全体に基づいて計算されます。個別のユーザー・データAPIコールの署名を計算する必要はありません。
次に、URIパスの例を示します。
https://bulkapi.bluekai.com/2/api?bksig=signature次に、署名計算の例を示します。
#!/usr/bin/python import os import sys import getopt import hashlib import hmac import base64 def usage(): print "\nUsage: " + sys.argv[0] + "-k <secret-key> [-f <post-file> | -p <post-data>] \n" def main(argv=sys.argv): try: opts,args = getopt.getopt(argv, 'k:f:p:') except getopt.GetoptError: usage() sys.exit(2) key = "" data = "" for opt,arg in opts: if opt in ('-k'): key = arg elif opt in ('-f'): try: data = open(arg, 'r').read() except: print "Failed to read file: " + arg sys.exit(2) elif opt in ('-p'): data = arg else: usage() sys.exit(2) if key == "" or data == "": usage() sys.exit(2) h = hmac.new(key, data, hashlib.sha256) s = base64.standard_b64encode(h.digest()) print " key: " + key print " data: " + data print "digest: " + h.hexdigest() print "result: " + s if __name__ == "__main__": main(sys.argv[1:]) - 本文で
Scatterオブジェクトの個別のユーザー・データAPIコール(サブリクエスト)を渡します。次に、リクエスト本文の例を示します。
{ "ResponseType": "Detail", "Method": "POST", "ResponseCallbackUrl": "http://example.com/uri", "Scatter": [{ "Method": "POST", "URIPath": "/getdata/58038/v1.2?puserid=j4r951sRxl25KqT6&phint=purchase=smartphone", "RequestID": "001" }, { "Method": "POST", "URIPath": "/getdata/58038/v1.2?puserid=g3G991WRxNkbKGT6&phint=purchase=smartphone", "RequestID": "002" }, . . . ] }
データ・オンボーディングのモニタリング
ユーザー・データがカテゴリに正常にオンボーディングされるかどうかをモニターするには、DMPでInventory Trendレポートを生成します。Inventory Trendレポートでは、新規ユーザーとすべての一意のユーザーの両方について、1日間隔で、過去の毎日のインベントリが表示されて、ビジュアル化されます。レポートは前日のインベントリ・データで毎日更新され(GMTの午後12時頃)、サンプリングされません。詳細は、Inventory Trendレポートを参照してください。
インテグレーションの検証
インテグレーションが完了した後に、Oracle Data Cloudインテグレーション・サポート・スペシャリストにシステム内のデモ・シートを提供する必要があります。サポート・スペシャリストは、インテグレーションをエンドツーエンドでテストして、適切に機能することを確認し、トラブルシューティング・サポートも提供できます。
ドキュメント
インテグレーションが検証された後、Oracle Data Cloudインテグレーション・サポート・スペシャリストに、クライアントがプラットフォーム間でデータをオンボーディングする方法についてのスクリーン・ショットを含む使用説明書を提供する必要があります。この要件が満たされるまで、インテグレーションが有効にならない場合があります。