소개

금융 서비스 광고 규제가 있는 국가에서 Meta는 광고주에게 신원과 금융 라이선스를 인증하도록 요구할 수 있습니다. 규제 기관은 Meta에 금융 라이선스 데이터 세트를 제공하며, Meta는 광고주가 제출한 라이선스를 검증하는 데 해당 데이터 세트를 사용합니다. 이 문서에서는 규제 기관이 라이선스 데이터를 Meta와 안전하게 공유하는 방법과 통합을 위한 기술 사양을 설명합니다.

개요

이 통합은 다음과 같이 작동합니다.

1. Meta에서 SFTP 자격 증명 제공 - Meta는 규제 기관의 확인된 이메일 주소로 로그인 정보를 보냅니다.
2. 규제 기관에서 2개의 파일 업로드 - config.json(메타데이터)과 CSV 파일(라이선스 데이터)이 Meta의 보안 SFTP 서버에 업로드됩니다. 파일 업로드 지침을 참조하세요.
3. Meta에서 데이터 수집 - 파일은 주기적으로 처리됩니다.
4. 규제 기관에서 주기적으로 업로드 - 규제 기관은 매주 정기적으로 업데이트 파일을 업로드해야 합니다.

config.json은 무엇인가요?

config.json 파일은 처리에 필요한 메타데이터를 포함하는 매니페스트입니다. 이 파일은 모든 업로드에 포함되어야 합니다.

필드

예시

{
  "version": "v1",
  "load_type": "full",
  "mode": "ingestion",
  "support_email_addresses": [
    "support@domain.com",
    "support2@domain.com"
  ]
}

라이선스 데이터(CSV)

라이선스 데이터는 CSV 파일로 제공됩니다. 파일의 이름은 원하는 대로 지정할 수 있습니다. 읽어들이는 유형은 두 가지입니다.

• 전체 로드 - 모든 라이선스 데이터의 전체 세트를 포함합니다.
• 증분 로드 - 마지막 업로드 이후의 변경 사항(델타)만 포함합니다.

일반 규칙

• 열 헤더는 첫 번째 행에 위치해야 합니다.
• 모든 열 헤더는 고유해야 합니다.
• 모든 필수 열이 있어야 합니다.
• 각 행에는 고유한 Credential_Id가 있어야 합니다.
• 행 수준의 오류가 있더라도 전체 파일을 차단하지 않습니다. 유효한 행은 계속해서 수집합니다. 예를 들어, 100,000개 행 중 50개 행에 오류가 있는 경우 나머지 99,950개 행은 정상적으로 처리합니다.

전체 로드 스키마(V1)

Meta 광고 플랫폼에서 사칭, 사기, 악용을 방지하기 위해서는 연결 확인이 필수적입니다. 이를 위해 업로드된 금융 라이선스 데이터에서 각 라이선스에 대해 전화번호, 이메일 주소, 웹사이트 URL 중 하나 이상을 제공해야 합니다. 그러면 해당 광고주가 인증 주체에 연결된 라이선스를 사용하고 있는지를 확인할 수 있습니다.

증분 스키마(V1)

증분 스키마는 전체 로드 스키마와 동일한 열에 필수 열 하나를 추가하여 사용합니다.

작업 규칙

• UPSERT - 새로운 라이선스를 추가하거나 기존 라이선스를 업데이트합니다. 전체 로드 스키마와 동일한 필수/선택 사항 필드 규칙을 따릅니다.
• DELETE - 라이선스를 삭제합니다. Credential_Id 필드만 필수이며, 나머지 필드는 선택 사항입니다.

증분 로드 시나리오의 예시

초기 데이터 세트에는 A, B, C라는 세 가지 라이선스가 포함되어 있습니다.

그 이후에는 다음과 같이 변경됩니다.

• 라이선스 B가 업데이트됩니다.
• 라이선스 C가 삭제됩니다.
• 라이선스 D가 추가됩니다.

증분 CSV에는 다음이 포함됩니다.

라이선스 A는 변경 사항이 없으므로 포함되지 않습니다.

마지막으로 수집된 데이터 세트의 타임스탬프는 SFTP의 ingestion_history/ 폴더를 통해 확인할 수 있습니다(아래 참조).

SFTP 업로드 및 수집 프로세스

업로드 방법

1. Meta에서 제공한 자격 증명을 사용하여 SFTP 서버에 로그인합니다.
2. config.json과 CSV 데이터 파일 모두 기본 디렉터리에 업로드합니다.
3. 처리될 때까지 기다립니다. 파일은 config.json에서 validation 모드를 사용하여 하루에 여러 번 검증할 수 있지만, 데이터는 하루에 한 번만 수집할 수 있습니다.

업로드 후 진행 과정

• 처리가 끝나면 두 파일 모두 config.json에 설정된 모드에 따라 validation_history/ 또는 ingestion_history/ 디렉터리로 자동으로 옮겨집니다. 업로드된 CSV 파일에 필수 값 누락, 잘못된 값 등과 같은 행 수준의 오류가 포함된 경우 해당 오류를 자세히 설명하는 별도의 CSV 파일이 생성됩니다. 수집을 수행하기 전에 validation 모드를 사용하여 파일이 올바르게 처리되는지 확인합니다.
• 실행할 때마다 기록 디렉터리에서 사용된 정확한 파일을 포함하는 타임스탬프 폴더(예: 2026-03-11T12-23-56Z/)가 생성됩니다.
• 파일이 여전히 (ingestion_history/ 또는 validation_history/가 아닌) 기본 디렉터리에 있는 경우 아직 처리되지 않은 것입니다.
• 보관: SFTP 서버는 30일 동안만 파일을 보관합니다.

예: 수집 전후

다음은 ingestion 모드의 data1.csv 및 config.json을 포함한, 2026년 3월 11일 자 새로운 수집 전후의 파일 구조를 보여줍니다.

수집 전

config.json
data1.csv
ingestion_history/
  └── 2026-03-06T04-20-17Z/
       ├── config.json
       ├── license_data.csv
       ├── csv_errors.csv
validation_history/
  └── 2026-03-11T05-18-14Z/
       ├── config.json
       ├── data1.csv
       ├── csv_errors.csv
  └── 2026-03-06T01-15-24Z/
       ├── config.json
       ├── license_data.csv
       ├── csv_errors.csv

수집 후

ingestion_history/
  └── 2026-03-11T12-23-56Z/
       ├── config.json
       ├── data1.csv
  └── 2026-03-06T04-20-17Z/
       ├── config.json
       ├── license_data.csv
       ├── csv_errors.csv
validation_history/
  └── 2026-03-11T05-18-14Z/
       ├── config.json
       ├── data1.csv
       ├── csv_errors.csv
  └── 2026-03-06T01-15-24Z/
       ├── config.json
       ├── license_data.csv
       ├── csv_errors.csv

다른 수집을 트리거하려면 기본 디렉터리에 새 파일을 다시 업로드하세요.

중요 참고 사항

• 처리 시간: 데이터가 수집된 후 Meta 시스템에 표시되기까지 최대 1일이 걸릴 수 있습니다.