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

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

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

Adobe Analyticsでは、データフィードファイルの上書きを禁止しません。

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

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

同じRSIDと日付に設定されている2つのフィードはすべて、同じファイル名を持ちます。 これらのフィードが同じ場所に配信された場合、一方のファイルは他方のファイルを上書きします。

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

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

時間別または日別のデータを処理する前に、データフィードはその時間枠（日または時間）内にデータ収集に入ったすべてのヒットがデータウェアハウスに書き出されるまで待機します。 その後、データフィードはタイムスタンプがその期間内のデータを収集し、圧縮したうえで FTP 経由で送信します。 毎時間のフィードの場合、ファイルは通常、1時間後15～30分以内にデータウェアハウスに書き出されますが、期間は設定されていません。 タイムスタンプがタイムフレーム内にあるデータがない場合、プロセスは次のタイムフレームで再試行します。 現在のデータフィード処理では、どのヒットがその時間帯に属しているかを確認するために 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日を超える日付の時間別出力は予測できません。 特定の日付の場合、数時間の時間別ファイルと、他の時間の日別ファイルの統合を組み合わせて表示することができます。 日次ファイルに統合されたデータは、通常、時間00に割り当てられます。これは、それらの時間が直接要求されたときに、他の時間を空白のままにすることができます。

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

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

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

STD -> DSTの時間遷移（スプリング フォワード）を行うと、23個のファイルを受け取ります。 DST への移行でスキップされた時間分は省略されます。 例えば、移行が午前2時に発生した場合、1:00時間のファイルと3:00時間のファイルが取得されます。 2:00 ファイルはありません。2:00 STDで3:00 DSTになるからです。

DST -> STD トランジション（フォールバック）を行うと、24個のファイルが返されます。 ただし、実際には移行の時間に 2 時間分のデータが含まれることになります。 例えば、移行が午前2:00時に発生した場合、1:00のファイルは1時間遅れますが、データは2時間含まれます。 1:00 DSTから2:00 STD （3:00 DST）までのデータが含まれます。 次のファイルは2:00 STDから始まります。

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）にオブジェクトに対する完全な権限（読み取り、書き込み、削除など）を付与します。