데이터 피드 FAQ

데이터 피드에 대한 FAQ.

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

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

동일한 파일 이름이 존재하는 피드를 만들려고 하는 경우, 오류 메시지가 표시됩니다. 다음과 같은 해결 방법을 고려해 보아야 합니다.

데이터가 언제 처리됩니까? processed

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

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

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

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

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

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

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

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

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

여러 개의 000 값이 event_list 또는 post_event_list 데이터 피드 열에 표시되는 이유는 무엇입니까? 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의 연결에도 동일한 개념이 적용됩니다. 그러나 예외 항목을 처리로 인해 두 개의 히트가 동일한 히트 ID를 공유하는 경우는 거의 없습니다. Adobe는 고유한 모든 히트에 전적으로 의존하는 데이터 피드 워크플로를 만들지 않는 것을 권장합니다.

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

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

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

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

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

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

특정 시간대의 경우 일광 절약 시간제(DST)로 인해 일년에 두 번 시간이 변경됩니다. 데이터 피드는 보고서 세트가 구성되는 시간대를 따릅니다. 보고서 세트의 시간대가 DST를 사용하지 않는 시간대인 경우 파일 배달은 다른 날과 마찬가지로 정상적으로 이루어집니다. 보고서 세트의 시간대가 DST를 사용하는 시간대인 경우 시간 변경이 이루어지는 시간 (보통 오전 2시) 동안 파일 배달이 변경됩니다.

STD -> DST 시간 전환 시 (“Spring Forward”) 고객은 23개의 파일만 받습니다. DST 전환에서 건너뛴 시간은 생략됩니다. 예를 들어 오전 2시에 전환되면 1시에 대한 파일을 받은 후 3시에 대한 파일을 받습니다. 2:00 STD가 3:00 DST가 되므로 2시 파일은 없습니다.

DST -> STD 전환 시 (“Fall Back”) 고객은 24개의 파일을 받습니다. 하지만 전환 시간에는 실제로 2시간 분량의 데이터가 포함됩니다. 예를 들어 오전 2시에 전환이 이루어진 경우 1시에 대한 파일이 한 시간 동안 지연되면서 두 시간 분량의 데이터가 포함됩니다. 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에 대한 일반적인 사용 사례는 AWS (Amazon 웹 서비스) 계정 소유자가 버킷을 만들고, 해당 버킷에 오브젝트를 만들 권한이 있는 사용자를 만든 다음 해당 사용자에 대한 자격 증명을 제공하는 것입니다. 이 경우 사용자의 오브젝트는 같은 계정에 속하며, 계정 소유자에게 암시적으로 오브젝트에 대한 모든 권한(읽기, 삭제 등)이 있습니다. 이 프로세스는 FTP 전송 작동 방식과 유사합니다.

또한 사용자는 AWS를 사용하여 다른 사용자 계정에 속하는 버킷에 오브젝트를 만들 수 있습니다. 예를 들어 두 명의 AWS 사용자인 userA와 userB가 같은 AWS 계정에 속하지 않지만 다른 버킷에 오브젝트를 만들려고 한다고 가정해 보겠습니다. userA가 “bucketA”라는 버킷을 만들면 userB가 버킷을 소유하지 않은 경우에도 명시적으로 bucketA에 오브젝트를 만들 수 있는 버킷 정책을 만들 수 있습니다. 이 정책은 userA와 userB가 자격 증명을 교환할 필요가 없기 때문에 유용할 수 있습니다. 대신 userB는 userA에게 계정 번호를 제공하고, userA는 "userB가 bucketA에 오브젝트를 만들 수 있도록 허용"하는 버킷 정책을 만듭니다.

그러나 오브젝트는 상위 버킷에서 권한을 상속하지 않습니다. 따라서 userB가 userA의 버킷에 오브젝트를 업로드하는 경우에도 userB는 여전히 해당 오브젝트를 "소유"하며, userA가 버킷을 소유한다 하더라도 기본적으로 userA에게 해당 오브젝트에 대한 권한이 부여되지 않습니다. UserB는 여전히 오브젝트 소유자이므로 userA에게 명시적으로 권한을 부여해야 합니다. 이 권한을 부여하려면 userB는 오브젝트를 userB가 “소유”하고 있더라도 버킷 소유자(userA)에게 오브젝트에 대한 모든 권한(읽기, 쓰기, 삭제 등)이 부여되도록 지정하는 BucketOwnerFullControl ACL을 사용하여 오브젝트를 업로드해야 합니다.