オフライン・データ・マッチング

オフライン・データ・マッチングを使用して、Oracle Data Cloudプラットフォームでオフライン・データをアクティブ化できます。オフライン・マッチを使用すると、データ・ウェアハウス、顧客関係管理(CRM)データベースまたは電子メールベースのオフライン・ソリューションからのデータをOracle Data Cloudプラットフォームにオンボーディングできます。ユーザーのオフライン属性に基づいて、ユーザーをターゲット、最適化、分析およびモデル化できます。

オフライン・データ・マッチングを使用すると、次のことが可能になります。

  • ファーストパーティ・データ・セットの拡張: ユーザーのオフライン属性に基づいて、新しいファーストパーティ・カテゴリをタクソノミに追加します。
  • オフライン・データの迅速なアクティブ化: オフライン・ファイルのアップロード後24から48時間以内に、ユーザーのオフライン属性に基づいて、複数のメディア実行プラットフォームに渡ってユーザーをターゲット、最適化および分析できるようになります。
  • ルックアライクを使用したリーチの拡大: 組込みのアナリティクスおよびモデリングを使用して、パフォーマンス上位のオフライン・ユーザーのように行動する高価値ユーザーを見つけます。

EUデータをオンボーディングするデータ・プロバイダ。所在地が欧州連合(EU)であるユーザー・プロファイルのデータをオンボーディングするには、オラクル社の一般データ保護規則(GDPR)への利用許諾書に署名している必要があります。この契約を取得して署名するには、オラクル社のアカウント担当者にお問い合せください。

オフライン・オンボーディング

オフライン・データを収集するには:

  1. IDスワップを介して、プラットフォームにオンライン・マッチ・キーを送信します(たとえば、Webサイトへのログインに使用するハッシュ化された電子メール・アドレス)。
  2. 同じマッチ・キーとユーザーのオフライン属性を含むオフライン・ファイルを作成します
  3. オフライン・データを分類します
  4. オフライン・ファイルをプラットフォームに送信します
  5. オフライン・データ収集をモニタリングします

オフライン・ファイルを送信すると、プラットフォームにより、マッチ・キーおよび分類ルールを使用してユーザーのオフライン属性がプライベート・タクソノミのカテゴリにマッピングされます。オフライン・データはオンボーディングされ、24時間以内にアクティブ化の準備が整います。次の図は、オフライン・データがOracle Data Cloudプラットフォームに収集される仕組みを示しています。

オフライン・マッチ・ワークフローの図

オフライン・オンボーディングの最大化

可能なかぎり最大量のオフライン・データをオンボーディングするために、サードパーティ・マッチ・パートナによるオフライン・オンボーディングと、オンラインからオフラインへのマッチング・ソリューションであるMatch Multiplierを使用したOracle Data Cloudプラットフォームへの直接オンボーディングを実行することをお薦めします。

  • サードパーティ・マッチ・インテグレーション: Oracle Data Cloudプラットフォームには、サードパーティ・マッチ・パートナであるLiveRamp、i-BehaviorおよびNeustarとの直接インテグレーションがあります。サードパーティ・マッチ・パートナは、ご使用のオフライン・ファイルの一部分を照合できます。
  • 新しいサードパーティ・オフライン・マッチ・パートナ: Oracle Data CloudプラットフォームでIDスワップが構成されていないオフライン・マッチ・ベンダーを使用している場合は、オフライン・マッチ・ベンダーに、マッチ・キーをプラットフォームに送信することによる直接インテグレーションを実行してもらいます。
  • サードパーティ・マッチ・パートナ: IDスワップを設定していない場合は、マッチ・キーの送信のステップに従います。オフライン・ファイルをプラットフォームに送信して、プラットフォーム・クライアントのオフライン・データ・マッチングを完了します。
  • ファーストパーティ・マッチ・インテグレーション: Match Multiplierにより、サードパーティ・マッチ・パートナにより提供されるマッチに加えて、増分マッチが提供されます。

Oracle Data Cloudプラットフォームへのマッチ・キーの送信

マッチ・キーは、オンラインおよびオフライン空間の両方でユーザーを識別するために使用できる一意のユーザーID (UUID)です。

重要: 個人識別情報(PII)を、プラットフォームに送信したり、Oracle Data Cloudプラットフォームに保存したりしないでください。PIIから導出されるすべてのIDは、Oracle Data Cloudプラットフォームに送信する前に、ブラウザまたはご使用のサーバーでハッシュ化する必要があります。

マッチ・キーとして使用できるUUIDには、次のものがあります。

  • OracleハッシュID (oHash): Oracle Data Cloudコードを使用して未加工の個人識別情報(PII)から自動的に生成された、SHA-256でハッシュ化された電子メール・アドレスまたは電話番号
  • 暗号化されたハッシュUUID: 暗号化されているハッシュ化電子メール・アドレス、電話番号、実際の住所およびクライアント・アカウント番号
  • 暗号化されたOracle Data Cloud UUID (BKUUID): Oracle Data Cloudプラットフォームでユーザーを匿名的に一意に識別するために使用される、暗号化されたバージョンの16文字の英数字のID。サーバー・データ・トランスファー(SDT)を使用してデータを受信するためにプラットフォームとのIDスワップを行っている場合は、暗号化されたBKUUIDにアクセスできる場合があります。
  • IPアドレス: IPヘッダーからユーザーのIPアドレスを収集し、それをマッチ・キーとして送信します。

オンライン・マッチ・キーをプラットフォームに送信するには、サイトにOracle Data Cloudコア・タグまたはIDスワップ・タグ(1x1のイメージ・ピクセル)を配置する必要があります。プラットフォームでは、マッチ・キーを受信すると、それをOracle ID Graph (OIDG)内で互いにリンクされたユーザー・プロファイルのネットワークと同期します。OIDGは、すべてのOracle Data CloudカスタマのIDおよびユーザー属性を管理するために使用されます。

Oracle Data Cloudコア・タグは、プラットフォームとインテグレーションするための標準実装です。これには、マッチ・キーおよびユーザー属性をプラットフォームに送信するためのHTMLコードと組込みJavaScript関数が含まれています。これは、サイトに直接デプロイすることも、タグ管理システムにデプロイすることもできます。IDスワップ・タグは通常、ディスプレイ・メディアなどの、タグ・コールを実行するためにピクセルを必要とする環境で使用されます。

Oracle Data Cloudコア・タグまたはIDスワップ・タグをサイトにデプロイし、オフライン構成が完了すると、ソリューション・コンサルタントから、オフライン・ファイルをアップロードするためのSFTPディレクトリ、ユーザー名およびパスワードが提供されます。

オフライン・ファイルの作成

オフライン・データをOracle Data Cloudプラットフォームに送信するには、次のファイルを作成します。

  • オフライン・ファイル: マッチ・キーおよびオフライン・ユーザー属性が含まれます。対応するトリガー・ファイルをアップロードするに、このファイルを完全にアップロードする必要があります。
  • トリガー・ファイル: オフライン・ファイルの名前、サイズおよびSHA-256チェックサムが含まれます。オフライン・データの転送を検証するために使用されます。

オフライン・ファイルの作成

オフライン・ファイルは、DMPにオンボーディングするオフライン・ユーザー属性が含まれている、圧縮されたタブ区切り値(TSV)ファイルです。オフライン・ファイルの各行が一意のユーザーを表しています。ユーザーのマッチ・キーは個別の列に含まれています。別の列には、ユーザーのオフライン属性のキーと値のペアのパイプ区切りリストが含まれています。

重要: オフライン・ファイルでマッチ・キーを繰り返し指定しないでください。重複したマッチ・キーが存在した場合、前のマッチ・キー・インスタンスのオフライン・ユーザー属性がより新しいインスタンスで上書きされます。

キーは通常、CRMデータベース内のフィールドに対応する個別のユーザー属性(性別のbk111など)を表しています。異なるキーを使用して、異なるユーザー属性を表します。

キーの形式は、2文字の会社名の後に、3桁のカテゴリ識別子(年齢はBK112など)が付いたものである必要があります。

値は、判読可能な名前として表すことも、数値コードで表すこともできます。パイプ文字(|)はオフライン・ファイル内で値の間のデリミタとして使用されるため、値自体にパイプ文字を含めることはできません。

次のサンプル・オフライン・ファイルには、マッチ・キーおよびパイプ区切りのユーザー属性の、2つのタブ区切り列が5行示されています。

awytM3DD	bk112=25|bk111=M|bk115=2
3d5zYU7i	bk112=22|bk111=F|bk115=1
yE8Sy49V	bk112=36|bk111=F|bk115=1
6xkDV7yl	bk112=42|bk111=F|bk115=3
Dh77UNpg	bk112=37|bk111=M|bk115=2

IPアドレスベースのマッチングの使用

IPアドレスベースのマッチングは、デスクトップ、モバイルおよびコネクテッドTVなどの、多数のコネクテッド・デバイスに渡って使用できる、便利な汎用マッチ・キーを提供します。自宅またはオフィスのネットワーク内の複数のデバイスが、同じパブリックIPアドレスを使用してインターネットにアクセスしている場合、IPマッチングによって、複数のデバイスに渡って属性を照合し、ロケーション、環境および行動ベースの属性を導出できます。

IPベースのデータをオンボーディングするには、次のようにして追加のマッチ・キーを格納および処理する必要があります。

  • 収集: IPアドレスは、タグのヘッダーに自動的に渡されます。これは、サイトに追加のタグやコードを実装することなく収集できます。
  • ストレージおよびデータ・オンボーディング: 未加工のIPアドレスおよびphintを含むオフライン・ファイルをプラットフォームに送信できます。未加工のIPアドレスは、ファイルから読み取られ、エンコードされて、Oracle Data Cloudオフライン・データベースに格納されます。プラットフォームでは、タグ・コールを受信すると、IPヘッダーに渡されたIPアドレスがオフライン・データベース内のエンコードされたIPアドレスとマッチするかどうかを確認します。マッチがある場合は、オフライン・データがオンボーディングされ、ユーザーのOracle Data Cloud Cookie ID (BKUUID)およびIPアドレスにリンクされます。1人のユーザーに対して複数のIPアドレスが収集されている場合は、各IPに対して検索が実行されますが、最後に取得されたIPのみが照合されます。
  • 配信: Oracle Data Cloudプラットフォームでは、未加工のIPアドレスにリンクされているユーザー・データをメディア実行プラットフォームに配信できます。特定のBKUUIDに対し、最大で40個の最新のハッシュIPアドレスをリンクできます。
  • プライバシ: マッチング、格納および配信をサポートするプライバシが保護された実装を使用して、任意のIPアドレスを収集のために送信できます。オラクル社は、このデータをユーザーCookie内に格納する際には標準のデータ保持ポリシーに準拠し、このデータを受信するパートナがオラクル社の保持およびオプトアウト・ポリシーに従うことを合理的に確認しています。国際的には、IPアドレスがPIIとみなされることもあるため、クライアントによってはデータ配信への参加を希望しない場合があります。
  • レポート: inventory trendレポートを使用して、マッチしたインベントリを請求目的で確認できます。複数のマッチ・パートナを使用している場合は、カスタマ・サクセス・マネージャまたはソリューション・コンサルタントに連絡して、構成可能な特別な除外について話し合ってください。

IPアドレスをマッチ・キーとして使用するには、それらをオフライン・ファイルに追加します。以前にオフライン・ファイルをプラットフォームに送信している場合は、オフライン・ファイルでIPアドレスを渡すことをカスタマ・サクセス・マネージャまたはソリューション・コンサルタントに通知してください。システムがオフライン・ファイルでIPアドレスを検索するように、オラクル社がご使用のオフライン・オンボーディング構成を更新します。

IPアドレスおよび対応する属性を含むオフライン・ファイルを作成します。次のサンプル・オフライン・ファイルの内容には、IPアドレスとパイプ区切りのユーザー属性の2つのタブ区切りの列が示されています。

100.87.5.202	bk112=25|bk111=M|bk115=2
148.87.67.202	bk112=37|bk111=M|bk115=2

マッチ・キーとしてのoHashの使用

ユーザーの電子メール・アドレスおよび電話番号を、oHashと呼ばれる匿名のSHA-256ハッシュIDに変換して、それらをマッチ・キーとしてオフライン・ファイルに含めることができます。

UUIDを使用しているオフライン・ファイルを以前に送信しており、今回はマッチ・キーとしてoHashを使用する場合は、UUIDとoHashの両方を個別のフィールドに含めてください。

オフライン・ファイルでマッチ・キーとしてoHashを使用するには:

  1. オフライン・ファイルでoHashを渡すことと、SHA-256電子メール(e_id_s)またはSHA-256電話番号(p_id_s)のいずれのoHashを渡すかを、カスタマ・サクセス・マネージャまたはソリューション・コンサルタントに通知します。オフライン・ファイルに含めることができるoHashのタイプは1つのみです。システムがオフライン・ファイルでoHashを検索するように、オラクル社がご使用のオフライン・オンボーディング構成を更新します。
  2. Python、JavaまたはRubyのoHashサーバーサイド・コードの例を使用して、オフライン・ファイル・ソースの未加工の電子メール・アドレスまたは電話番号をSHA-256 oHashに変換します。
  3. oHashおよびオフライン・ユーザー属性を表すキーと値のペアのパイプ区切りリストを含むオフライン・ファイルを形式設定します。次の例は、マッチ・キーとしてoHashを使用するオフライン・ファイルの行を示しています。
    j3qfe13d964235c175626e16e3e4c3eb0de71a4d17cad39733dc5e65a585127c	bk112=25|bk111=M|bk115=2

オフライン・ファイルの形式

次の表は、オフライン・ファイルで必要となる、形式、名前、タイプおよびサイズを表示しています。

要件 説明
ファイル・コンテンツ awytM3DD bk112=25|bk111=M|bk115=2
3d5zYU7i bk112=22|bk111=F|bk115=1
オフライン・ファイルは、ユーザーごとに1行が含まれるプレーン・テキスト・ファイルであり、各行はLF改行文字で終了している必要があります。各行には、次のタブ区切りのフィールドが含まれている必要があります。
  • マッチ・キー: UUID、IPアドレスまたはoHash (最大40バイト)
  • オフライン属性: パイプ区切りのキーと値のペア
ファイル名 Partner_siteID_YYYY-MM-DD オフライン・ファイルには、パートナ名、コンテナのサイトIDおよび日付が含まれている必要があります。複数のファイルを送信する場合は、日付のかわりにタイムスタンプを使用します。
ファイル名にスペースを含めることはできません
サードパーティ・オフライン・マッチ・パートナは、ファイル名にクライアントの名前を含める必要があります。たとえば、partner_client_siteID_YYYY-MM-DDです。
最大行サイズ   256データ項目、32KB。
文字エンコーディング   UTF-8
ファイル・タイプ .bz2 (または.gz) ファイルはbzip2またはgzip圧縮を使用して圧縮する必要があり、.bz2または.gzのファイル拡張子を付けることができます。未圧縮のファイルは拒否され、ファイル共有から削除されます。
最小サイズ >50 MB 複数の小さいファイルを送信する予定の場合は、1つの大きいファイルに結合してください。たとえば、10個の20 MBのファイルを1つの200 MBに結合します。理想的なサイズは約1 GBです。データがそれのみである場合は50 MBでも許容されますが、100 MB以上をお薦めします。
最大サイズ ≤ 50 GB 最大ファイル・サイズは50 GBですが、大きいファイルを複数の小さいファイルに分割できます。

更新されたオフライン・ファイルの送信

更新されたオフライン・ファイルを継続的にOracle Data Cloudプラットフォームに送信して、新規ユーザーおよび既存ユーザーの新しいオフライン属性をオンボーディングできます。

重要: オフライン・ファイルの送信時には、すべての属性を含めてください。

既存ユーザーの新しいオフライン属性をオンボーディングするには、オフライン・ファイルでユーザーの既存のパイプ区切りの属性リストに新しい属性を追加します。プラットフォームに保存されている現在のオフライン・ユーザー属性は、新しいオフライン・ファイルに表示された属性で上書きされるため、オフライン・ファイルにはユーザーの既存のオフライン属性をすべて保持する必要があります。

トリガー・ファイルの作成

トリガー・ファイルでは、サイズ、名前、チェックサムおよびオプションでオフライン・ファイル内のレコード数を指定します。これは、オフライン・ファイル内のすべてのデータが破損することなく正常に転送されたことを検証するために使用されます。検証が成功した場合、プラットフォームによってオフライン・ファイルのオンボーディングが開始されます。検証が失敗した場合は、アカウント・マネージャから連絡があり、エラーについて説明されます。

対応するオフライン・データ・ファイルが完全にアップロードされるまでは、トリガー・ファイルをアップロードしないでください

トリガー・ファイルの形式

次の表は、トリガー・ファイルの必要な形式、名前、タイプおよびサイズを表示しています。

要件 説明
形式 FILE=partner_siteID_YYYY-MM-DD.gz

SIZE=367

SHA256SUM=a10edbbb8f28f8e98ee6b649ea2556f4

ファイルには、次の行区切りフィールドが含まれています。
  • FILE: アップロードされるオフライン・ファイルの名前。トリガー・ファイル名が、オフライン・ファイルと同じ名前に.triggerファイル拡張子が付加されたものである場合、この行はオプションです。オフライン・ファイルの名前がトリガー・ファイルと異なる場合、または複数のオフライン・ファイルをトリガーする場合(推奨)は、この行は必須です。
  • SIZE: (推奨)オフライン・ファイルのサイズ(バイト単位)。詳細は、オフライン・ファイル・サイズの計算を参照してください。
  • SHA256SUM: (推奨)オフライン・ファイルのチェックサム。チェックサム値は、ファイルの内容が変更されるたびに変更されます。転送中にファイルが破損するか、切り捨てられた場合、そのSHA-256チェックサムはマッチしなくなります。詳細は、オフライン・ファイルSHA-256チェックサムの計算を参照してください。

    MD5ハッシュもサポートされていますが、セキュリティ上の理由から、MD5を使用しないことをお薦めします。

Name PartnerName_SiteId_YYYY-MM-DD.gz.trigger (必須)トリガー・ファイルの名前はオフライン・ファイルと同じ名前に、.triggerファイル拡張子を付加したものである必要があります。ファイル名にスペースを含めることはできません。オフライン・ファイルと同じ名前を使用できない場合は、オプションで、FILE行を使用して異なるファイル名を指定できます(非推奨)。
タイプ プレーン・テキスト トリガー・ファイルは圧縮しないでください。

オフライン・ファイル・サイズの計算

ファイルのサイズをバイト単位で計算するツールを使用できます。オペレーティング・システムには、この目的のユーティリティがあります。たとえば、UNIXプラットフォームでは、コマンドラインで次のように入力できます。
$ ls -l fileName

このコマンドは、ファイルに関する情報(サイズなど)を返します。たとえば、次の情報が返された場合、ファイル・サイズは367バイトです。

-rw-rw-r-- 1 user user 367 Feb 6 16:00 a.gz,

オフライン・ファイルSHA-256チェックサムの計算

SHA-256に基づくツールを使用して、アップロードするオフライン・ファイルのチェックサムを計算できます。ほとんどのオペレーティング・システムには、この目的の組込みコマンド・ライン・ユーティリティが含まれています。たとえば、Linuxでは、コマンドラインで次のように入力できます。

$sha256sum fileName

オフライン・データの分類

Oracle Data Cloudプラットフォームにオフライン・ユーザー属性をインポートするには:

  1. プラットフォームに渡すキーと値の概要を示すデータ・マップを作成します
  2. オフライン・ファイルのユーザー属性をDMPのタクソノミにマッピングするカテゴリおよび分類ルールを作成します

データ・マップの作成

オフライン・ユーザー属性を編成し、分類プロセスを促進するためにデータ・マップを作成します。

データ・マップは、タクソノミでのオフライン・ユーザー属性の編成方法の概要を示します。またこれは、オフライン・データを収集するために必要なすべてのカテゴリおよび分類ルールを作成したことを確認するために使用できるチェックリストとしても機能します。Oracleのサービスを使用してオフライン・データを分類する場合は、データ・マップが必要で、次のことを行う必要があります。

  • オフライン・ファイルで使用する属性キーのセットを定義します。
  • 各属性キーに指定可能な値のセットを定義し、それらの値を判読可能なカテゴリ名に関連付けます。
  • 一連の属性キーの間に階層関係(ある場合)を定義します。

たとえば、ユーザーが購入の意思を示した自動車のメーカーおよびモデルを収集する自動車購入サイトを考えます。Makeノードのキーと値のペアの構文は、MA100=VALUEとなります。このノードのキーと値のペアは、次のようになります。

  • MA100=Honda
  • MA100=Acura
  • MA100=Toyota

Modelノードのキーと値のペアの構文は、MA110=[VALUE]となります。前述の例のMakeノードに基づき、Modelノードのキーと値のペアの例は次のようになります。

  • MA110=Accord
  • MA110=Civic
  • MA110=TL
  • MA110=TSX
  • MA110=Corolla
  • MA110=Camry

makeの値がエンコードされている場合(たとえば、Honda、Acura、Toyotaのかわりに23098、21409、57983を渡した場合)、プラットフォームでは、エンコードされた値に対応する判読可能なカテゴリ名が必要になります。たとえば、次の変換を使用できます。

  • MA100=23098 -> Honda
  • MA100=21409 -> Acura
  • MA100=57983 -> Toyota

このサイトには、次のデータ・マップを作成できます。

キー キーの解釈 カテゴリ名
MA100 Make Honda Honda
MA100 Make 21409 Acura
MA100 Make 57983 Toyota
MA110 Make>Model Accord Honda>Accord
MA110 Make>Model 89065 Honda>Civic
MA110 Make>Model TL Acura>TL
MA110 Make>Model TSX Acura>TSX
MA110 Make>Model Corolla Toyota>Corolla
MA110 Make>Model Camry Toyota>Camry

カテゴリと分類ルールの作成

カテゴリは、同じ属性(たとえば、スマートフォン・ユーザー)を持つユーザーのコレクションです。分類ルールは、オフライン・ファイルから抽出されたユーザー属性を、DMPタクソノミのカテゴリにマッピングします。
ユーザーが実店舗でスマートフォンを購入したとします。オフライン・ファイルには、このユーザーに対してpurchase=smartphoneという属性が含まれます。このオフライン属性は、Oracle Data Cloudプラットフォームにインポートされたとき、"purchase is smartphoneの場合、ユーザーをSmartphoneカテゴリに追加する"、という分類ルールを介して、タクソノミのPast Purchases > Smartphoneカテゴリにマッピングできます。

Oracle Data CloudプラットフォームのUIには、カテゴリとルールを作成するためのTaxonomy Managerが含まれています。または、カテゴリおよびルールAPIを使用して、カテゴリおよびルールをプログラマティックに作成することもできます。Oracle Data Cloudプラットフォームによってタクソノミが構築されるようにするには、カスタマ・サクセス・マネージャまたはソリューション・コンサルタントに連絡してください。

オフライン・ファイルのアップロード

オフライン・ファイルを作成し、プラットフォームによってオフライン・データが分類されたら、オフライン・ファイルおよび対応するトリガー・ファイルをOracle SFTPサーバーにアップロードできます。オラクル社によって提供されるSFTPディレクトリ、ユーザー名およびパスワードを使用して、オフライン・ファイルをアップロードします。

オフライン・ファイルをアップロードするには:

  1. Oracle Data Cloudがファイルの形式を確認し、必要な変更がある場合に示すことができるように、1,000レコード以上を含む小さいテスト・ファイルをアップロードします。サンプル・ファイルが承認されたら、完全なオフライン・ファイルをアップロードできます。
  2. オフライン・ファイル(または、分割された小さいオフライン・ファイルを作成する必要がある場合は、複数のファイル)をアップロードします。
  3. オフライン・ファイルのアップロードが完了したら、トリガー・ファイルをアップロードします。ファイルがプラットフォームのオフライン・マッチ・ルールベースの分類システムに送信され、アカウント・マネージャに通知されます。
  4. Oracle Data Cloudプラットフォームによって、オフライン・ファイルが検証され、データのオンボーディングが開始されます。オフライン・ファイルのマッチ・キー(IDスワップでプラットフォームに送信したものと同じキー)を使用して、ユーザーのオンライン・プロファイル(BKUUID)がそのオフライン属性にリンクされます。続けて、ユーザーのオフライン属性が、Oracle Data Cloudによって作成される分類ルールを使用して、プライベート・タクソノミのカテゴリにマッピングされます。オフライン・データは、24から48時間以内にアクティブ化の準備が整います。
  5. アカウント・アクティビティ・ジャーナルを使用して、オフライン・オンボーディングの進行状況をトラッキングします。これには、次のイベントが表示されます。
    ステップイベントジャーナル・メッセージ
    検証オフライン・ファイル確認ファイル名、ステータス、ファイル・サイズ、レコードの数およびチェックサムが表示されます。
    Offline File Message

    フィールドが欠落しているか、ファイルのサイズがトリガー・ファイルで指定されたサイズにマッチしないエラーに関するメッセージが表示されます。

    収集Ingest Startsファイル名が表示されます。
  6. 処理されたオフライン・ファイルはアーカイブされ、90日間保持されます。

オフライン・データ収集のモニタリング

プラットフォームによってオフライン・ファイルがオンボーディングされると、ユーザー・データがタクソノミのカテゴリに流入し始めるはずです。データが正しく収集および分類され、オフライン・ファイルによって予期される量のインベントリが生成されていることを確認するには:

  • インベントリが増加しているかどうかを確認します。Inventory Trendレポートを使用して、カテゴリ当たりのインベントリの量が毎日増え続けていることを確認します。
  • 30日間のインベントリを確認します。Oracle Data Cloudプラットフォームのオーディエンス・ビルダーを使用して、現在の構成に基づく、カテゴリ内の一意のユーザーの推定数を表示します。
  • カテゴリAPIを使用して、一意のユーザーのインベントリをプログラマティックに確認できます。