데이터 피드 FAQ

데이터 피드에 대한 FAQ

피드 이름이 고유해야 합니까?

데이터 피드 파일 이름은 보고서 세트 ID와 날짜로 이루어집니다. 동일한 RSID와 날짜에 대해 구성된 임의의 두 피드에 대한 파일 이름은 동일합니다. 해당 피드가 동일한 위치에 배달되는 경우, 한 파일이 다른 파일을 덮어쓰게 됩니다. 파일 덮어쓰기를 방지하기 위해, 동일한 위치에서 기존의 피드를 덮어쓸 가능성이 있는 피드는 만들 수 없습니다.

동일한 파일 이름이 존재하는 피드를 만들려고 하는 경우, 다음 메시지가 표시됩니다.

이 오류가 표시되는 경우 다음 해결 방법을 고려해 보십시오.

  • 배달 경로 변경
  • 가능할 경우 날짜 변경
  • 가능할 경우 보고서 세트 변경

데이터는 언제 처리됩니까?

시간별 또는 일별 데이터를 처리하기 전에 데이터 피드는 시간 (일 또는 시간) 내에 데이터 수집에 입력된 모든 히트가 Data Warehouse에 작성될 때까지 대기합니다. 이후 데이터 피드는 해당 기간에 맞는 타임스탬프를 포함한 데이터를 수집하여 압축하고 FTP를 통해 발송합니다. 시간별 피드의 경우 파일은 해당 시간 이후 15~30분 내에 Data Warehouse로 작성되지만 기간이 정해져 있지는 않습니다. 기간에 해당하는 타임스탬프를 가진 데이터가 없는 경우 다음 기간을 다시 시도하게 됩니다. 현재 데이터 피드 프로세스는 date_time 필드를 사용하여 어떤 히트가 시간에 속하는지 결정합니다. 이 필드는 보고서 세트의 시간대를 기반으로 합니다.

post_ 접두사가 있는 열과 post_ 접두사가 없는 열 간의 차이점은 무엇입니까?

post_ 접두어가 없는 열에는 데이터 수집으로 전송된 것과 동일한 데이터가 포함됩니다. post_ 접두어가 있는 열에는 처리 후 값이 포함됩니다. 값을 변경할 수 있는 예는 변수 지속성, 처리 규칙, VISTA 규칙, 통화 전환 또는 Adobe가 적용하는 서버측 논리입니다. 가능하면 열의 post_ 버전을 사용하는 것이 좋습니다.

열에 post_ 버전이 없다면 (예: visit_num) 이 열은 이후 열로 간주할 수 있습니다.

데이터 피드는 대소문자 구분을 어떻게 처리합니까?

Adobe Analytics에서는 대부분의 변수가 보고 목적으로 대소문자를 구분하지 않는 것으로 간주됩니다. 예를 들어 'snow', 'Snow', 'SNOW' 및 'sNow'는 모두 동일한 값으로 간주됩니다. 대소문자 구분은 데이터 피드에서 유지됩니다.

이후가 아닌 열과 이후 열 간에 동일한 값의 대소문자가 다르게 되어 있다면 (예: 이전 열에는 "snow", 이후 열에는 "Snow") 구현은 사이트 전체에서 대문자 값과 소문자 값을 모두 사용합니다. 이후 열에서 대소문자가 다른 값은 이전에 전달되어 가상 쿠키에 저장되어 있거나, 해당 보고서 세트에 대해 동일한 시간 동안 처리되었습니다.

보트는 데이터 피드에 포함된 Admin Console 보트 규칙으로 필터링됩니까?

데이터 피드는 Admin Console 보트 규칙으로 필터링된 보트를 포함하지 않습니다.

여러 개의 000 값이 event_list 또는 post_event_list 데이터 피드 열에 표시되는 이유는 무엇입니까?

일부 스프레드시트 편집기, 특히 Microsoft Excel은 큰 숫자를 자동으로 반올림합니다. event_list 열에는 쉼표로 구분된 숫자가 많이 포함되어있어 Excel에서 이 숫자를 큰 숫자로 처리하는 경우가 있습니다. 마지막 몇 자릿수를 000으로 반올림합니다.

Adobe는 Microsoft Excel에서 hit_data.tsv 파일을 자동으로 열지 않는 것을 권장합니다. 대신 Excel의 데이터 가져오기 대화 상자를 사용하고 모든 필드가 텍스트로 처리되는지 확인하십시오.

일부 통신사의 도메인 열에서 정보가 누락된 이유는 무엇입니까?

일부 이동통신사 (T-Mobile 및 O1 등)에서는 더 이상 역-DNS 조회용 도메인 정보를 제공하지 않습니다. 따라서 도메인 보고에 해당 데이터를 사용할 수 없습니다.

7일이 초과된 데이터에서 “시간별” 파일을 추출할 수 없는 이유는 무엇입니까?

데이터가 7일이 초과된 경우 1일 “시간별” 파일은 하나의 “일별” 파일로 결합됩니다.

예: 새 데이터 피드는 2021년 3월 9일에 생성되고 2021년 1월부터 3월 9일까지는 “시간별”로 전달됩니다. 단, 2021년 3월 2일 이전의 “시간별” 파일은 하나의 “일별” 파일로 결합됩니다. 생성일로부터 7일이 초과되지 않은 데이터에서만 “시간별” 파일을 추출할 수 있습니다. 이 경우 3월 2일부터 3월 9일까지 파일을 추출할 수 있습니다.

일광 절약 시간제가 시간별 데이터 피드에 미치는 영향은 무엇입니까?

특정 시간대의 경우 일광 절약 시간(DST) 정의로 인해 일년에 두 번 시간이 변경됩니다. 데이터 피드는 보고서 세트가 구성되는 시간대를 따릅니다. 보고서 세트의 시간대가 DST를 사용하지 않는 시간대인 경우 파일 배달은 다른 날처럼 정상적으로 계속됩니다. 보고서 세트의 시간대가 DST를 사용하는 시간대인 경우 시간 변경이 발생하는 시간(일반적으로 오전 2:00) 동안 파일 배달이 변경됩니다.

STD -> DST 시간 전환 시("Spring Forward") 고객은 23개의 파일만 수신합니다. DST 전환에서 건너뛴 시간은 생략됩니다. 예를 들어 오전 2시에 전환이 발생하면 1시간 동안 파일을 받고 3시 동안 파일을 가져옵니다. 2:00 STD가 3:00 DST가 되므로 2:00 파일이 없습니다.

DST -> STD 전환 시("Fall Back") 고객은 24개의 파일을 받습니다. 그러나 전환 시간에는 실제로 2시간 분량의 데이터가 포함됩니다. 예를 들어 오전 2:00에 전환이 발생하면 1:00에 대한 파일이 1시간 지연되지만 2시간 동안의 데이터가 포함됩니다. 1:00 DST에서 2:00 STD(3:00 DST일 수 있음)까지의 데이터를 포함합니다. 다음 파일은 2:00 STD에서 시작됩니다.

데이터가 수집되지 않으면 매니페스트 파일을 받게 됩니까?

특정 기간에 대해 수집된 데이터가 없으면 매니페스트 파일을 배달하도록 데이터 피드를 구성할 수도 있습니다. 이 옵션을 활성화하면 다음과 비슷한 매니페스트 파일을 받게 됩니다.

Datafeed-Manifest-Version: 1.0
 Lookup-Files: 0
 Data-Files: 0
 Total-Records: 0

Analytics는 FTP 전송 오류를 어떻게 처리합니까?

FTP 전송이 실패하는 경우(로그인 거부, 연결 손실, 할당량 부족 등), Adobe은 최대 3회의 개별 데이터를 자동으로 연결하고 전송합니다. 그래도 문제가 계속되면 피드가 실패된 것으로 표시되고 이메일 알림이 발송됩니다.

전송이 실패하면 작업이 완료될 때까지 작업을 다시 실행할 수 있습니다.

FTP 사이트에 데이터 피드를 표시할 때 문제가 발생하면 작업 문제 해결을 참조하십시오.

직장을 재등록하는 방법은 무엇입니까?

배달 문제를 확인/수정했으면 파일을 가져오는 작업을 다시 실행합니다.

Amazon S3 데이터 피드에 대한 BucketOwnerFullControl 설정이란 무엇입니까?

Amazon S3에 대한 일반적인 사용 사례는 AWS (Amazon 웹 서비스) 계정 소유자가 버킷을 만들고, 해당 버킷에 개체를 만들 권한이 있는 사용자를 만든 다음 해당 사용자에 대한 자격 증명을 제공하는 것입니다. 이 경우 사용자의 개체는 동일한 계정에 속하며 계정 소유자는 암시적으로 개체에 대한 모든 권한을 가집니다(읽기, 삭제 등). 이 프로세스는 FTP 배달 작동 방식과 유사합니다.

AWS를 사용하면 사용자가 다른 사용자 계정에 속한 버킷에 개체를 만들 수도 있습니다. 예를 들어 두 명의 AWS 사용자인 userA와 userB가 같은 AWS 계정에 속하지 않지만 다른 버킷에 개체를 만들려고 하는 경우 userA가 버킷 bucketA를 만들면 userB가 버킷을 소유하고 있지 않더라도 명시적으로 bucketA에 개체를 만들 수 있는 버킷 정책을 만들 수 있습니다. 이 정책은 userA 및 userB가 자격 증명을 교환하지 않아도 되기 때문에 유용합니다. 대신 userB는 userA에게 계정 번호를 제공하고, userA는 "userB가 bucketA에 개체를 만들 수 있도록 허용"하는 버킷 정책을 만듭니다.

BucketOwnerFullControl​은 다른 버킷에 개체를 만들 수 있는 교차 계정 권한을 제공합니다. userB가 userA의 버킷에 개체를 업로드하는 경우 userB는 여전히 해당 개체를 "소유"하며, userA가 버킷을 소유하더라도 기본적으로 userA에게 해당 개체에 대한 권한을 부여하지 않습니다. 이는 개체가 상위 버킷의 권한을 상속하지 않기 때문입니다. UserB는 여전히 개체 소유자이므로 userA에게 명시적으로 권한을 부여해야 합니다. 이 권한을 부여하려면 userB가 userB가 개체를 "소유"하고 있더라도 버킷 소유자(userA)에게 개체에 대한 모든 권한(읽기, 쓰기, 삭제 등)을 부여하도록 지정하는 BucketOwnerFullControl ACL을 사용하여 개체를 업로드해야 합니다.

이 페이지에서는

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now