ads.txt와 sellers.json 교차 검증 5단계
- ads.txt의 광고 시스템 도메인과 계정 ID를 해당 시스템의 sellers.json에서 대조합니다.
- DIRECT·RESELLER는 게시자와 광고 시스템의 관계를, seller_type은 판매자 계정의 유형을 설명합니다.
- SupplyChain의 asi·sid와 complete 값을 함께 확인해 요청에 표시된 판매 경로를 살핍니다.
ads.txt와 sellers.json은 각각 게시자가 공개한 허용 판매자 정보와 광고 시스템이 공개한 판매자 계정 정보를 보여줍니다. ads.txt에서 광고 시스템 도메인과 계정 ID를 찾고, 해당 시스템의 sellers.json에서 같은 seller_id와 판매자 정보를 대조하세요. 입찰 요청에 SupplyChain Object가 있다면 그 안의 각 판매 노드도 확인합니다. 이 글은 웹 인벤토리를 중심으로 검증 순서와 판정 기준을 설명합니다.
두 파일이 보여주는 정보부터 구분하기
ads.txt는 게시자가 허용한 판매 계정을 공개합니다
ads.txt는 게시자가 자신의 광고 인벤토리를 판매할 권한이 있는 광고 시스템과 계정 정보를 공개하는 파일입니다. 웹사이트에서는 보통 사이트 루트의 /ads.txt에서 확인합니다. 각 행은 일반적으로 광고 시스템 도메인, 판매자 계정 ID, 관계 유형, 인증기관 ID 순서이며, 네 번째 인증기관 ID는 선택 항목입니다. 이 파일은 게시자가 공개한 허용 판매자 정보를 나타내지만, 개별 입찰 요청에 포함된 모든 중개 경로를 보여주지는 않습니다.
sellers.json은 광고 시스템이 공개한 판매자 계정 정보를 보여줍니다
광고 시스템은 자신의 도메인에 sellers.json을 게시해 판매자와 중개자 계정을 식별할 수 있게 합니다. seller_id는 계정 식별자이고, seller_type은 판매자 유형입니다. 유형 값은 규격에 따라 PUBLISHER, INTERMEDIARY, BOTH로 표기합니다. name과 domain은 공개되는 판매자 정보이며, is_confidential이 true이면 이 두 필드가 생략될 수 있습니다. 이름이나 도메인이 없다는 사실만으로 미승인이라고 결론 내리지 마세요.
| 확인 자료 | 핵심 필드 | 주요 질문 |
|---|---|---|
| 게시자 ads.txt | 광고 시스템 도메인, 계정 ID, 관계 유형 | 게시자가 이 계정을 허용했나? |
| 시스템 sellers.json | seller_id, seller_type, name, domain | 그 시스템에서 이 계정은 누구의 계정인가? |
| 입찰 요청 SupplyChain | asi, sid, complete | 요청에 어떤 판매 경로가 표시됐나? |
ads.txt와 sellers.json을 교차 검증하는 5단계
1단계: 검증할 인벤토리와 도메인을 정합니다
거래 대상이 웹사이트인지 앱인지 먼저 확인하세요. 웹은 해당 사이트의 ads.txt를 확인하고, 앱은 앱 스토어에 등록된 개발자 웹사이트와 그 도메인의 app-ads.txt를 확인하는 방식이 기준이 될 수 있습니다. 여러 도메인을 운영한다면 입찰 요청의 사이트 도메인과 실제 조회한 파일 URL을 기록하세요. 리디렉션이 발생하면 최종 도착 주소도 남깁니다.
2단계: ads.txt에서 광고 시스템과 계정 ID를 찾습니다
거래에 참여한다고 표시된 광고 시스템 도메인과 계정 ID가 함께 있는 행을 찾습니다. 예를 들면 exchange.example, 계정ID, RESELLER와 같은 형식입니다. 이 값은 설명용 예시이므로 실제 파트너에게 받은 값과 대조해야 합니다. 조회 시각, URL, 응답 상태, 파일 원문을 함께 기록하면 변경 여부를 추적하기 쉽습니다.
3단계: 해당 광고 시스템의 sellers.json에서 계정을 확인합니다
ads.txt 행에 적힌 광고 시스템 도메인의 /sellers.json을 조회한 뒤, seller_id가 ads.txt의 계정 ID와 정확히 일치하는 항목을 찾습니다. 철자 일부만 비슷한 계정이나 다른 시스템에서 발견한 같은 ID는 일치로 보지 마세요. 파일을 가져오지 못하거나 JSON을 읽을 수 없다면 그 상태를 기록하고, 곧바로 판매자 정보가 허위라고 단정하지 않습니다.
4단계: 관계 유형과 판매자 정보를 맥락에 맞춰 읽습니다
계정을 찾았다면 seller_type, name, domain, is_confidential을 확인합니다. ads.txt의 DIRECT와 RESELLER는 게시자와 광고 시스템 계정 사이의 권한 관계를 나타냅니다. sellers.json의 PUBLISHER, INTERMEDIARY, BOTH는 해당 광고 시스템이 공개한 계정의 판매자 유형을 설명합니다. 서로 다른 정보를 나타내므로 문자열을 일대일로 맞추지 마세요. 공개 정보가 계약 관계와 맞지 않는 것으로 보이면 사업자명 변경이나 계정 이전 여부를 계약 담당자 또는 플랫폼에 확인합니다.
5단계: SupplyChain Object의 각 노드를 대조합니다
구매자나 플랫폼 운영자는 입찰 요청의 schain.nodes를 확인합니다. 각 노드의 asi는 광고 시스템 도메인, sid는 그 시스템 안의 판매자 계정 ID입니다. 이를 해당 시스템의 ads.txt 및 sellers.json 정보와 대조하세요. 노드는 경로 순서대로 표시되며, 완전한 경로에서는 첫 노드가 인벤토리 소유자와 연결된 최초 시스템을, 마지막 노드가 입찰 요청을 보내는 시스템을 나타냅니다. complete가 1이면 인벤토리 소유자까지 이어지는 경로가 완전하다고 표시된 것이고, 0이면 경로가 불완전하다고 표시된 것입니다. 이 플래그와 공개 파일의 대조만으로 실제 거래 경로의 진실성까지 독립적으로 입증되는 것은 아닙니다.
핵심 판정: ads.txt의 광고 시스템 도메인과 계정 ID가 그 시스템의 sellers.json에 있는 seller_id와 일치하면 계정 수준의 교차 일치로 볼 수 있습니다. 이 결과만으로 실제 노출에 참여한 모든 중개 경로나 트래픽의 무결성까지 증명되는 것은 아닙니다.
결과는 일치·불일치·판정 보류로 나눕니다
- 일치: ads.txt의 광고 시스템 도메인과 계정 ID가 해당 시스템의 sellers.json에서 확인되고, 공개된 판매자 정보가 확인 가능한 거래 관계와 모순되지 않습니다.
- 불일치: 계정 ID가 해당 시스템의 sellers.json에 없거나, 계약상 판매 주체와 공개 정보가 명백히 다릅니다.
- 판정 보류: sellers.json 접근 실패, 정보 비공개, 파일 파싱 오류, 계정명 변경 미확인, 또는 불완전한 SupplyChain으로 결론을 낼 근거가 부족합니다.
불일치가 확인돼도 즉시 사기라고 단정하기보다 파일 갱신 지연, 계정 이전, 도메인 입력 오류, 오래된 리셀러 정보부터 확인하세요. 반대로 익숙한 회사 이름이 보인다는 이유만으로 승인된 판매 경로라고 판단해서도 안 됩니다. 계정 ID와 광고 시스템 도메인을 함께 확인하는 것이 기본입니다.
파일을 점검할 때 자주 생기는 오류
파일 위치와 앱 정보가 맞지 않는 경우
ads.txt를 루트가 아닌 하위 경로에 올리거나, 실제 인벤토리 도메인과 다른 파일을 확인하면 검증 결과가 어긋날 수 있습니다. 공개 URL에서 파일이 응답되는지 확인하고, 앱 인벤토리는 앱 스토어에 등록된 개발자 웹사이트에서 app-ads.txt를 찾을 수 있는지 확인하세요.
파트너 목록을 검토 없이 복사하는 경우
파트너가 제공한 행을 그대로 추가하면 계약이 끝난 뒤에도 판매 계정이 남거나 관계 유형이 현재 계약과 다를 수 있습니다. 사용 중인 SSP·광고 거래소·리셀러별 계정 ID와 관계를 확인하고, 종료된 파트너 행은 담당자와 확인해 정리하세요. ads.txt 1.1에는 소유 도메인과 관리 도메인 정보를 나타내는 OWNERDOMAIN, MANAGERDOMAIN 변수가 추가됐습니다. 복수 도메인이나 대행 구조를 운영한다면 관련 규격도 확인하세요.
- 파트너의 공식 온보딩 자료에서 광고 시스템 도메인과 계정 ID를 받습니다.
- 계약 관계를 확인해 ads.txt의 DIRECT 또는 RESELLER 표기가 맞는지 검토합니다.
- 파일을 공개한 뒤 ads.txt, sellers.json, 입찰 요청의 SupplyChain 정보를 대조합니다.
- 불일치 항목은 담당자에게 확인한 뒤 수정하고, 재조회 결과와 날짜를 기록합니다.
공식 규격과 확인 자료
ads.txt의 목적과 1.1의 소유·관리 도메인 변수는 IAB Tech Lab 안내에서 확인할 수 있습니다. sellers.json 및 SupplyChain Object의 역할과 필드 정의는 IAB Tech Lab 규격 문서를 참고하세요. Google Ad Manager 게시자는 한국어 고객센터에서 sellers.json의 판매자 유형과 비공개 필드 안내를 볼 수 있으며, ads.txt 가이드에서 파일 위치와 게시자 ID 확인 방법을 확인할 수 있습니다. 플랫폼마다 계정 정보와 적용 절차가 다를 수 있으므로 실제 값은 해당 플랫폼의 공식 안내와 계약 정보에 대조하세요.
자주 묻는 질문
Q. ads.txt에 있으면 승인된 판매자인가요?
게시자가 해당 계정을 허용한다고 공개한 것입니다. 계정이 광고 시스템의 sellers.json에 있는지, 입찰 요청에 표시된 판매 경로와도 일치하는지 확인해야 합니다.
Q. DIRECT와 sellers.json의 PUBLISHER는 같은 뜻인가요?
같은 필드가 아닙니다. DIRECT·RESELLER는 게시자와 광고 시스템 계정 사이의 권한 관계를 나타내고, seller_type은 sellers.json을 게시하는 시스템이 해당 계정을 어떤 판매자 유형으로 분류하는지 설명합니다. 표기 값을 일대일로 맞추지 말고 계약 및 계정 관계와 함께 판단하세요.
Q. sellers.json에 업체명이나 도메인이 없으면 미승인인가요?
그 사실만으로 미승인이라고 결론 내릴 수 없습니다. is_confidential이 true이면 name과 domain이 생략될 수 있습니다. 광고 시스템 도메인과 seller_id를 확인하고, 정보가 더 필요하면 파트너에게 문의하세요.
Q. 두 파일이 일치하면 광고 사기가 없다고 볼 수 있나요?
아닙니다. 파일 대조는 공개된 판매 권한과 계정 정보를 확인하는 데 도움을 줍니다. 트래픽 품질, 실제 노출의 진위, 요청에 표시되지 않은 중개 경로까지 보장하지는 않으므로 SupplyChain 정보와 별도의 트래픽 검증도 살펴야 합니다.
Q. 파일을 고친 뒤 반영 여부를 어떻게 확인하나요?
공개 URL을 다시 조회해 실제 응답 내용과 상태를 확인하고, 광고 플랫폼에서도 재검증된 시점을 확인하세요. 플랫폼별 크롤링 및 반영 주기는 다를 수 있습니다. Google AdSense의 ads.txt 문제 해결 안내에 따르면 변경 사항 반영에 며칠이 걸릴 수 있으며, 광고 요청량이 적으면 최대 한 달이 걸릴 수도 있습니다. 변경 전후 결과와 확인 날짜를 기록하세요.
