データフィードに関する FAQ

データフィードに関するよくある質問（FAQ）です。

フィード名は一意にする必要がありますか。 unique

Adobe Analyticsでは、データフィードファイルの上書きを防ぐことはできません。

データフィードファイルが上書きされるのを防ぐために、同じ場所に送信されるすべてのデータフィードファイルに一意のファイル名を付けることをお勧めします。

データフィードファイル名は、次のデータフィード特性で構成されています。

同じ RSID および日付に対して設定された任意の 2 つのフィードは、同じファイル名になります。 これらのフィードが同じ場所に配信されると、1 つのファイルがもう 1 つを上書きします。

ファイルの上書きを防ぐには、次の回避策を考慮します。

データはいつ処理されますか。 processed

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

post_ 接頭辞のある列と post_ 接頭辞のない列の違いは何ですか。 post

post_ 接頭辞のない列には、データ収集に送信されたデータと完全に同じデータが含まれます。処理後の値は、post_ 接頭辞の付いた列に格納されます。値を変更できる例としては、変数の持続性、処理ルール、VISTA ルール、通貨換算、その他のサーバー側ロジックが挙げられます。可能な限り、列の post_ バージョンを使用することをお勧めします。

post_ バージョンの区別のない列（visit_num など）は、post 列と見なすことができます。

データフィードで大文字と小文字の区別を扱う方法 case

Adobe Analytics では、ほとんどの変数は、レポートの目的で、大文字と小文字が区別されません。例えば、「snow」、「Snow」、「SNOW」、「sNow」はすべて同じ値と見なされます。大文字と小文字の区別は、データフィードで保持されます。

非 post 列と post 列の間に、値が同じで大文字と小文字が異なるバージョンがある場合（例えば、pre 列に「snow」、post 列に「Snow」）、サイトをまたいで大文字と小文字の両方の値が使用されます。post 列内のバージョンは、以前に渡されて仮想 cookie に保存されている値か、同時期にそのレポートスイート用に処理された値です。

ボットは管理コンソールのボットルールによってフィルタリングされ、データフィードに含まれますか。 bots

データフィードには、Admin Console ボットルールでフィルタリングされたボットは含まれません。

event_list または post_event_list データフィード列に複数の 000 値が表示されるのはなぜですか。 values

一部のスプレッドシートエディター（特に Microsoft Excel など）では、大きな数値が自動的に丸められます。event_list 列には、カンマで区切られた多数の数字が含まれているので、Excel で大きな数字として処理されることがあります。最後の数桁を 000 に丸めます。

Adobe では、Microsoft Excel で hit_data.tsv ファイルを自動的に開かないことをお勧めします。代わりに、Excel のデータのインポートダイアログボックスを使用し、すべてのフィールドがテキストとして扱われていることを確認してください。

hitid_high、hitid_low、visid_high、visid_low などの列は、ヒットまたは訪問ごとに必ず一意になりますか？ hitid

ほとんどの場合、hitid_high と hitid_low を連結することで、ヒットを一意に識別します。同じ概念が、訪問の visid_high と visid_low の連結に適用されます。ただし、処理の異常値によって 2 つのヒットが同じヒット ID を共有することはほとんどありません。 アドビでは、すべてのヒットが一意であることに依存する柔軟性のないデータフィードワークフローは作成しないことをお勧めします。

一部の通信事業者のドメイン列に情報が表示されないのはなぜですか。 domain

一部のモバイルキャリア（T-Mobile や O1 など）では、DNS 逆引きルックアップ用のドメイン情報を提供しなくなりました。 したがって、そのデータはドメインレポートには使用できません。

古い日付の時間別ファイルを確実に抽出できないのはなぜですか？ hourly

ストレージと処理を最適化するために、Adobeでは、時間別の書き出しを定期的に毎日のファイルに統合しています。 これらの統合の実行方法とタイミングにより、10 日を超える日付の 1 時間ごとの出力を予測することはできません。 特定の日付について、ある時間単位のファイルと、他の時間単位のファイルを統合した日別ファイルの混在を確認できます。 毎日のファイルに統合されるデータは、通常、時間 00 に割り当てられます。これらの時間が直接要求されると、他の時間は空白のままになります。

10 日を超えるバックフィルの場合、Adobeでは、完全で予測可能な結果を得るために、毎日の精度を使用することを強くお勧めします。 古い日付の時間単位の精度をリクエストする必要がある場合は、統合された時間単位データが見つからないよう、常に時間 00 をリクエストに含めます。

時間別データフィードへの夏時間の影響は何ですか。 dst

一部のタイムゾーンでは、夏時間（DST）の規定によって時刻の変更が 1 年に 2 回行われます。データフィードでは、レポートスイートが設定されているタイム ゾーンが考慮されます。レポートスイートのタイムゾーンで DST が利用されていない場合、ファイル配信はその他すべての日と同様、通常どおりに続行されます。レポートスイートのタイムゾーンで DST が利用されている場合、時刻調整が発生する時間（通常、午前 2:00）に合わせてファイル配信の変更がおこなわれます。

標準時間（STD）から夏時間（DST）への移行時（夏時間への時計調整時）は、23 個のファイルを取得します。 DST への移行でスキップされた時間分は省略されます。例えば、移行が午前 2 時におこなわれる場合、:001 時間用のファイルと 3:00 時間用のファイルが得られます。 :00 のファイルは存在しません。これは、STD の 2:00 では DST の 3:00 になるからです。

DST から STD への移行時（フォールバック時）は、24 個のファイルを取得します。 ただし、実際には移行の時間に 2 時間分のデータが含まれることになります。例えば、移行が午前 2:00 に行われる場合、1:00 のファイルは 1 時間遅延しますが、2 時間分のデータが含まれています。 含まれるデータは、DST が 1:00 から STD が 2:00 （DST が 3:00）までのものです。 次のファイルは STD:002 から始まります。

Analytics は FTP 転送エラーをどのように処理しますか。 ftp-failure

FTP 転送が失敗した場合（ログイン拒否、接続の切断、割り当て不足エラー、その他の問題が原因）、Adobe は自動的に接続を試み、データを最大 3 回送信しようとします。それでもエラーが発生する場合、フィードは失敗とマークされ、電子メール通知が送信されます。

転送が失敗した場合は、正常に実行されるまでジョブを再実行できます。

FTP サイトにデータフィードを表示する際に問題が発生した場合は、 データフィードのトラブルシューティング を参照してください。

ジョブを再送する方法を教えてください。 resend

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

Amazon S3 データフィードの BucketOwnerFullControl 設定とは何ですか。 BucketOwnerFullControl

BucketOwnerFullControl は、他のバケットにオブジェクトを作成するためのクロスアカウント権限を付与します。

Amazon S3 の一般的な使用例では、Amazon Web サービス（AWS）アカウント所有者がバケットを作成し、次にそのバケット内でオブジェクトを作成する権限を持つユーザーを作成し、そのユーザーに資格情報を付与します。この場合、ユーザーのオブジェクトは、同じアカウントに属し、アカウント所有者は黙示的にそのオブジェクトのフルコントロール権（読み取り、削除など）を持ちます。この処理は、FTP の配信の仕組みと似ています。

AWS でも、異なるユーザーアカウントに属するバケット内にオブジェクトを作成できます。例えば、2 人の AWS ユーザー（userA と userB）が同じ AWS アカウントに属しておらず、他のバケットにオブジェクトを作成したいとします。userA が「bucketA」というバケットを作成すると、バケットの所有者でない userB に対して、bucketA でのオブジェクト作成を明示的に許可するバケット ポリシーを作成できます。このポリシーには、userA と userB が資格情報を交換する必要がないというメリットがあります。代わりに、userB は、userA にアカウント番号を提供し、userA は基本的に「userB に bucketA 内でオブジェクトを作成させる」ということを指示するバケットポリシーを作成します。

ただし、オブジェクトは親バケットから権限を継承しません。userB が userA のバケットにオブジェクトをアップロードする場合、userB は依然としてそのオブジェクトを「所有」します。userA はバケットを所有していますが、デフォルトでは、そのオブジェクトに対するいかなる権限も付与されていません。UserB は依然としてオブジェクトの所有者なので、userB が userA に明示的に権限を付与する必要があります。この権限を付与するには、userB は、BucketOwnerFullControl ACL を使用してオブジェクトをアップロードする必要があります。この ACL は、オブジェクトが userB によって「所有」されている場合でも、バケットの所有者（userA）にオブジェクトに対する完全な権限（読み取り、書き込み、削除など）を付与します。