Show Menu
トピック×

データフィードのトラブルシューティング

ここでは、一般的な問題に関する情報を提供します。

フィード保存中のエラー

データフィードファイル名がレポートスイート ID および日付で構成されています。同じ RSID および日付に設定された任意の 2 つのフィードは、同じファイル名になります。これらのフィードが同じ場所に配信されると、1 つのファイルがもう 1 つを上書きします。ファイルの上書きを防ぐには、既存のフィードを上書きする可能性があるフィードを同じ場所に作成しないようにします。
同じファイル名を持つ別のフィードが存在する場合にフィードを作成しようとすると、次のメッセージが表示されます。
このエラーが表示される場合は、次の対処方法を検討します。
  • 配信パスを変更する
  • 可能であれば日付を変更する
  • 可能であればレポートスイートを変更する

Amazon S3 データフィードの BucketOwnerFullControl 設定

Amazon S3 の一般的な使用例では、Amazon Web サービス(AWS)アカウント所有者がバケットを作成し、次にそのバケット内でオブジェクトを作成する権限を持つユーザーを作成し、そのユーザーに資格情報を付与します。この場合、ユーザーのオブジェクトは、同じアカウントに属し、アカウント所有者は暗黙的にそのオブジェクトのフルコントロール権(読み取り、削除など)を持ちます。これは、FTP の配信の仕組みと似ています。
AWS でも、完全に異なるユーザーアカウントに属するバケット内にオブジェクトを作成できます。例えば、2 人の AWS ユーザー(userA と userB)は同じ AWS アカウントに属しておらず、他のバケットにオブジェクトを作成したいとします。userA がバケットを作成すると(bucketA とします)、バケットの所有者でない userB に対して、bucketA でのオブジェクト作成を明示的に許可できます。これには、userA と userB が資格情報を交換する必要がないというメリットがあります。代わりに、userB は、userA にアカウント番号を提供し、userA は基本的に「userB に bucketA 内でオブジェクトを作成させる」ということを指示するバケットポリシーを作成します。
BucketOwnerFullControl は、他のバケットにオブジェクトを作成するためのクロスアカウント権限を付与します。userB が userA のバケットにオブジェクトをアップロードする場合、userB は依然としてそのオブジェクトを「所有」し、そしてデフォルトでは、userA は、たとえ userA が所有するバケットであっても、オブジェクトに対するいかなる権限も付与されません。つまり、オブジェクトは、親バケットから権限を継承しません。userB は依然としてオブジェクトの所有者なので、UserB が userA に明示的に権限を付与する必要があります。このクロスアカウントアップロードについて、AWS は、このバケット所有者(userA)によるこの ACL の使用を指定することで BucketOwnerFullControl ACL を提供し、オブジェクトが userB によって「所有」されていても、オブジェクトに対するフルアクセス権(読み取り、書き込み、削除など)が付与されます。

転送エラー

FTP 転送エラー(ログイン拒否、接続の切断、割り当て超過など)が発生した場合、アドビは自動接続およびデータ送信を最大 3 回まで試みます。それでもエラーが発生する場合、フィードは失敗とマークされ、電子メール通知が送信されます。
転送エラーの場合は、成功するまでジョブを再実行できます。

再送オプション

配信の問題を確認および修正したら、ジョブを再実行してファイルを取得します。

時間別データフィードに対する夏時間の影響

一部のタイムゾーンでは、夏時間(DST)の規定によって時刻の変更が 1 年に 2 回行われます。データフィードでは、レポートスイートが設定されているタイム ゾーンが考慮されます。レポートスイートのタイムゾーンで DST が利用されていない場合、ファイル配信はその他すべての日と同様、通常どおりに続行されます。レポートスイートのタイムゾーンで DST が利用されている場合、時刻調整が発生する時間(通常、午前 2 時)に合わせてファイル配信の変更が行われます。
標準時間(STD)から夏時間(DST)への移行時(夏時間への時計調整時)は、ユーザーの取得するファイル数が 23 個になります。DST への移行でスキップされた時間分は単純に省略されます。例えば、移行が午前 2 時に行われる場合、午前 1 時のファイルの取得に続いて、午前 3 時のファイルを取得することになります。STD での午前 2 時は DST では午前 3 時になるので、午前 2 時のファイルは存在しません。
DST から STD への移行(冬時間への時計調整時)時は、ユーザーの取得するファイル数は 24 個になります。ただし、実際には移行の時間に 2 時間分のデータが含まれることになります。例えば、移行が午前 2 時に行われる場合、午前 1 時のファイルは 1 時間遅れて取得され、そこには 2 時間分のデータが含まれています。含まれるデータは、DST での午前 1 時から STD での午前 2 時(DST の午前 3 時に該当)までのものです。次のファイルの開始時刻は STD での午前 2 時です。

ある期間のデータが存在しない

必要に応じて、特定の期間に収集されたデータがない場合にマニフェストファイルを配信するようにデータフィードを設定できます。このオプションを有効にしている場合は、次のようなマニフェストファイルを受け取ることになります。
Datafeed-Manifest-Version: 1.0
 Lookup-Files: 0
 Data-Files: 0
 Total-Records: 0

ドメインレポートのドメイン情報がない

一部の携帯電話会社(T-Mobile や O1 など)は、DNS 逆引き参照にドメイン情報を提供しなくなりました。そのため、そのデータはドメインレポートには使用できません。

データ処理の概要

時間別または日別のデータを処理する前に、データフィードはその時間枠(日または時間)内にデータ収集に入ったすべてのヒットがデータウェアハウスに書き出されるまで待機します。その後、データフィードはその時間枠内のタイムスタンプを持つデータを収集し、圧縮したうえで FTP 経由で送信します。時間別フィードの場合、ファイルは通常、その時間帯の終了後 15~30 分以内にデータウェアハウスに書き出されますが、設定時間はありません。その時間枠内のタイムスタンプを持つデータが存在しない場合は、同じ処理が次の時間枠で再試行されます。現在のデータフィード処理では、どのヒットがその時間帯に属しているかを確認するために date_time フィールドを使用します。このフィールドは、レポートスイートのタイムゾーンに基づいています。