ChatGPT Ads Conversions API 정리 — 시각형 광고 테스트와 전환 측정 파이프라인

mini_knows·1일 전

AI 트렌드·이슈

목록 보기
122/123

안녕하세요, 미니지식공간입니다.

ChatGPT Ads가 측정 쪽을 크게 열었다. OpenAI는 2026년 10월 5일 시각형 광고 포맷 테스트와 함께 Conversions API·Pixel 기반 전환 측정 스택을 공식 문서로 공개했는데, 포맷 이야기보다 이 서버 사이드 이벤트 전송 규격이 개발자가 실제로 코드를 쓸 지점이다. 이 글은 공식 문서에 적힌 엔드포인트·이벤트 스키마·해시 규칙을 기준으로 정리한다.

TL;DR
1. 2026년 10월 5일 OpenAI가 이미지 생성 지면의 시각형 광고 포맷을 공개했다. 테스트는 같은 달 미국, 일부 광고주 한정이다.
2. 개발자가 붙일 지점은 Conversions API다. POST https://bzr.openai.com/v1/events?pid=<PIXEL-ID> 한 엔드포인트에 최대 1,000건의 이벤트를 배치로 보낸다.
3. 이벤트 타입은 13종으로 고정돼 있고, 사용자 식별자는 소문자 64자 hex SHA-256으로만 받는다. 중복 제거 키는 Pixel ID + event_name + id다.

1. 발표에 적힌 것

항목내용
발표일2026-10-05
주체OpenAI
공식 글'Building advertising for the way people use AI' / 광고 블로그 'More ways to measure ChatGPT Ads'
새 포맷이미지 중심 시각형 광고. 별도 제품명 없음, 상위 제품명은 ChatGPT Ads
노출 지면ChatGPT 이미지 생성 과정
테스트 범위2026년 10월 중, 미국, 일부 광고주 그룹
광고 표시라벨 명시, 생성 중인 이미지와 분리
도달 규모주간 12억 명 (OpenAI 자사 발표)

공식 발표 문구는 '이달 중 미국에서 일부 광고주 그룹과 함께 테스트를 시작한다'다. 발표일이 10월 5일이므로 2026년 10월 중이라는 의미이고, 구체적 시작 일자와 참여 광고주 명단은 공개 자료에 없다. 미국 외 지역 확대 계획과 일반 개방 시점도 기재가 없어 확인이 필요하다.

2. 측정 파트너 명단

역할별로 네 층이다. 자사 도구와 파트너 도구를 함께 지원해 광고주가 쓰던 시스템을 유지하게 한다는 설명이 붙었다.

역할파트너
전환 데이터 온보딩Hightouch, Tealium, LiveRamp
웹·앱 어트리뷰션AppsFlyer, Triple Whale, Adjust, DV Rockerbox, Northbeam, Branch, Singular, Kochava, Airbridge, Tenjin
풀퍼널·고급 측정Fospha, Measured, INCRMNTAL
인크리멘털리티(지역 실험)Haus, Measured, WorkMagic — OpenAI가 초기 단계로 명시
브랜드 선호도 조사Kantar, Cint — 초기 테스트 단계
브랜드 적합성 평가 파일럿DoubleVerify, Integral Ad Science — 실제 사용자 대화 비접근

3. 자격 증명과 엔드포인트

Conversions API는 서버에서만 호출하도록 문서에 명시돼 있다. 필요한 값은 두 개다. Pixel ID와 Conversions API 키이며, 둘 다 Ads Manager의 conversions 탭에서 발급한다. 승인된 API 파트너는 conversion-setup 엔드포인트로 발급을 자동화할 수 있다.

curl -X POST "https://bzr.openai.com/v1/events?pid=<PIXEL-ID>" \
  -H "Authorization: Bearer <API-KEY>" \
  -H "Content-Type: application/json" \
  --data '{
    "validate_only": false,
    "events": []
  }'

출처: https://developers.openai.com/ads/conversions-api (공식 문서의 'Send events' 절 원문 예제)

요청 레벨 파라미터는 네 개다. pid는 쿼리 파라미터로 필수, events는 본문 필수다. validate_only를 true로 두면 저장 없이 검증만 하고, integration_source는 배치를 보내는 통합 주체를 식별하는 안정적 문자열이다. integration_source는 1~64자 ASCII로 문자나 숫자로 시작해야 하고 소문자로 정규화되며, 문서는 이 값이 인증·인가에 영향을 주지 않는다고 못 박아 두었다.

배치 한도는 1,000건이고, 한 건이 실패하면 배치 전체가 실패한다. 재시도 로직을 짤 때 이 전부-또는-전무 동작을 전제로 해야 한다.

4. 이벤트 객체 필수 필드

{
  "id": "order_12345",
  "type": "order_created",
  "timestamp_ms": 1773892800000,
  "source_url": "https://shop.example.com/checkout/confirmation",
  "action_source": "web",
  "data": {
    "type": "contents",
    "amount": 2599,
    "currency": "USD",
    "contents": [
      {"id": "sku_123", "name": "Starter bundle", "content_type": "product", "quantity": 1}
    ]
  }
}

출처: https://developers.openai.com/ads/conversions-api ('Example event' 절 원문에서 user 블록을 생략한 형태)

필드 제약이 몇 가지 까다롭다. id는 빈 문자열이 아닌 문자열이어야 하고, 재시도나 중복 전송 때 같은 값을 재사용해야 한다. timestamp_ms는 Unix 밀리초 정수인데 최근 7일 이내여야 하고 미래로는 10분까지만 허용된다. 배치 적재가 지연되는 파이프라인이라면 7일 창을 넘기지 않도록 큐 보존 기간을 맞춰야 한다.

amount는 통화의 최소 단위 정수다. 문서 예시로 4200이 42.00달러를 뜻한다. amount를 넣으면 currency는 ISO 4217 세 글자로 필수가 된다. action_source는 web, mobile_app, offline, physical_store, phone_call, email, other 중 하나이며, web일 때는 source_url이 필수고 app_installed·app_opened일 때는 반드시 mobile_app이어야 한다.

5. 이벤트 타입 13종과 데이터 타입 매핑

type과 data.type은 짝이 맞아야 한다. 아래가 공식 문서의 지원 이벤트 표다.

이벤트 타입data.type
app_installedcustomer_action
app_openedcustomer_action
appointment_scheduledcustomer_action
lead_createdcustomer_action
registration_completedcustomer_action
checkout_startedcontents
contents_viewedcontents
items_addedcontents
order_createdcontents
page_viewedcontents
subscription_createdplan_enrollment
trial_startedplan_enrollment
customcustom

출처: https://developers.openai.com/ads/supported-events

주의할 점 두 가지다. app_installed와 app_opened는 Conversions API 전용이며 JavaScript Pixel로는 보낼 수 없다. 그리고 type이 custom일 때는 custom_event_name이 필수인데, 1~64자의 영문자·숫자·밑줄·하이픈만 쓸 수 있고 API가 소문자로 바꾸며 표준 이벤트 이름과 같은 값은 쓸 수 없다.

앱 라이프사이클 이벤트는 본문이 훨씬 단순하다.

{
  "id": "app_installed_123",
  "type": "app_installed",
  "timestamp_ms": 1773892800000,
  "action_source": "mobile_app",
  "data": { "type": "customer_action" }
}

출처: https://developers.openai.com/ads/conversions-api (문서 예제의 <TIMESTAMP_MS> 자리에 위 예제와 동일한 값을 넣은 형태)

6. 사용자 매칭과 해시 규칙

events[].user는 전부 선택 필드지만, 매칭률이 여기서 갈린다. 각 리스트는 유효한 고유값 중 앞의 세 개까지만 사용된다. 해시 필드는 phone_numbers_sha256, emails_sha256, external_ids_sha256, first_names_sha256, last_names_sha256이고, 원문 그대로 보내는 필드는 regions, postal_codes, cities, countries, ip_address, user_agent, android_advertising_id, obref다.

해시 값은 UTF-8 정규화 입력의 SHA-256을 소문자 64자 hex로 보내야 한다. 정규화 규칙이 필드마다 다른데, 이 부분을 잘못 구현하면 매칭이 조용히 실패하므로 문서 규칙을 그대로 옮긴다.

필드정규화 규칙
이메일앞뒤 공백 제거 + 소문자화
전화번호국가번호 유지, 공백·괄호·마침표·하이픈 제거, 선두 +와 선두 0 제거 후 8~15자리
이름·성소문자화, 공백과 ASCII 구두점 제거, 비ASCII 문자는 보존
external ID앞뒤 공백만 제거, 대소문자 보존

문서가 든 예시로 전화번호 +1 (415) 555-2671은 14155552671이 되고, 이름 O'Connor는 oconnor, José는 josé가 된다. 비ASCII를 지우지 않는다는 점이 다른 플랫폼 규격과 갈리는 지점이다.

광고 식별자는 android_advertising_id가 GAID만 UUID 형식으로 받고 IDFA는 지원하지 않는다. obref는 Pixel이 심는 __obref 1st party 쿠키 값을 해시 없이 그대로 넣는다. oppref는 OpenAI가 주는 불투명한 어트리뷰션 식별자인데, Pixel과 달리 Conversions API는 이 값을 자동으로 수집해 주지 않으므로 직접 받아서 변형 없이 전달해야 한다.

opt_out을 true로 두면 해당 이벤트를 향후 사용자 단위 개인화에서 제외한다. 문서는 현재 Conversions API 데이터를 사용자 단위 개인화에 쓰지 않으며, 만약 쓰게 되면 이 토글을 존중하겠다고 적어 두었다.

7. 중복 제거와 어트리뷰션 윈도

Pixel과 Conversions API를 함께 쓰는 구성이 일반적이고, 그러면 같은 전환이 두 번 들어온다. 중복 제거 키는 Pixel ID + event_name + id다. API 쪽 id를 Pixel의 event_id로 그대로 재사용하면 되고, 먼저 도착한 이벤트가 채택된다.

어트리뷰션은 웹 이벤트에서 클릭 기준이 우선이다. 여기에 가능한 경우 고정 1일 뷰스루 윈도가 더해지는데, 뷰스루는 캠페인 레벨 별도 지표로 리포팅되고 Conversions 지표에는 포함되지 않는다. 광고 블로그 쪽 설명으로는 광고주가 고르는 클릭 윈도와 선택적 1일 뷰스루 윈도가 리포팅에만 영향을 주고 캠페인 최적화에는 반영되지 않는다. OpenAI는 딥퍼널 목표로 최적화한 글로벌 캠페인 초기 분석에서 1일 뷰스루 전환의 52.7%가 매칭 노출 후 한 시간 안에 발생했다고 밝혔다. 이 수치는 OpenAI 자사 분석값이다.

전환 신호 품질을 가늠하는 Event Quality Score도 제공되는데, 점수 산출식과 구간별 기준은 공개 자료에 없어 확인이 필요하다.

8. 도입 전 점검 항목

  1. 노출 조건을 먼저 확인한다. 2026년 10월 5일 기준 헬프센터 문서는 광고가 Free·Go 요금제에만 노출되고 Plus·Pro·Business·Enterprise·Edu에는 없다고 적고 있다. 18세 미만 식별 계정과 임시 채팅에도 광고가 없고, EEA·스위스는 개인화 광고 초기 미제공이다.
  2. 이벤트 큐의 보존 기간을 timestamp_ms 7일 제약에 맞춘다. 재처리 배치가 7일을 넘기면 조용히 거부된다.
  3. 배치 실패 처리를 전부-또는-전무로 설계한다. 1,000건 중 한 건의 스키마 오류가 전체를 떨어뜨린다.
  4. 해시 정규화를 필드별로 분리해 구현하고 단위 테스트를 붙인다. 특히 비ASCII 보존 규칙과 전화번호 선두 0 제거를 놓치기 쉽다.
  5. validate_only: true로 스테이징 검증 경로를 먼저 만든다. 저장 없이 스키마만 확인할 수 있는 유일한 수단이다.
  6. 모델 단가와 마찬가지로 광고 쪽 과금 체계도 공개 자료에 없다. OpenAI의 토큰 단가 변동을 함께 보려면 gpt-6.1-sol 도입 점검 — 캐시 입력 절반, Astra 대비 5분의 1 단가 글을 참고할 만하다.

아직 공개되지 않은 항목도 적지 않다. 광고 단가·CPM·입찰 방식, 타게팅 메커니즘, 광고 로드 한도, 미국 외 지역 일정이 모두 발표에 없다. Negative Phrases의 '자격을 충족한 광고주' 기준도 정의가 공개돼 있지 않다.

자주 묻는 질문

기존 전환 측정 코드를 수정해야 하나?
Pixel과 Conversions API를 둘 다 쓰는 구성이라면 중복 제거를 위해 양쪽 ID를 맞추는 작업이 필요하다. API id를 Pixel event_id로 재사용하면 되고, 그 외 기존 전환 파이프라인의 스키마를 바꿀 필요는 문서에 적혀 있지 않다.

Conversions API를 클라이언트에서 호출해도 되나?
문서는 서버에서만 이벤트를 보내라고 명시한다. API 키가 Bearer 토큰으로 들어가므로 브라우저나 앱에 두면 안 된다.

새 시각형 광고를 지금 집행할 수 있나?
아직이다. 2026년 10월 중 미국에서 일부 광고주 그룹과 테스트를 시작한다고만 공개됐고, 참여 기준이나 일반 개방 시점은 발표에 없다. 광고 계정 가입만 ads.openai.com에서 가능하다.

마무리

포맷 추가는 테스트 단계이고, 지금 당장 코드를 쓸 지점은 Conversions API다. 엔드포인트 하나에 배치로 보내는 단순한 구조지만 7일 타임스탬프 창, 전부-또는-전무 배치, 필드별로 다른 해시 정규화가 실수를 부르는 지점이다. 과금 체계와 타게팅 메커니즘은 아직 공개되지 않았으니, 측정 파이프라인만 먼저 붙여 두고 나머지는 후속 발표를 기다리는 편이 합리적이다.

출처

본 글은 공개 자료를 바탕으로 정리했으며, 세부 내용·수치는 원 출처·공식 문서와 대조 확인을 권장합니다. 엔드포인트·필드 제약은 2026년 10월 5일 조회 시점의 공식 문서 기준이며, 문서에 변경 이력이 표기돼 있지 않아 이후 변경 여부는 직접 확인이 필요합니다.

profile
작지만 알아야 할 모든 것

0개의 댓글