Meta Audience Network — In-House Bidding (Server-to-Server) 베타 enrollment 신청

안녕하세요. CNRS입니다. 현재 당사는 AdMob을 mediation으로 사용해 Audience Network demand에 연결되어 있으며, 매체사 직속 in-house bidding 트랙으로의 전환을 검토 중입니다. 자세한 운영 수치와 통합 일정은 회신 시 별도로 공유하겠습니다.

1. 신청 트랙

Meta for Developers 공식 문서 (in-house-mediation root, server-to-server, server-setup, integration, android-setup)에 명시된 트랙 중 Server-to-Server (S2S) + Audience Network Android SDK 본체 직접 통합 조합으로 신청합니다.

2. 매체사 운영 환경

항목내용
플랫폼Android only
현재 통합 경로AdMob mediation 경유 (Audience Network demand)
서버 스택Cloudflare Workers (TypeScript), OpenRTB 2.5 호환
tmax 운영 목표750 ms (p99 < 700 ms)
동의 관리 (CMP)AdMob UMP (IAB TCF v2 + Additional Consent v2)
트래픽 캐파 / 지역회신 시 NDA 후 별도 공유 / QPS·rate-limit 사전 협의 희망

3. 발급/활성화 요청 자격

  1. 당사 Business ID의 In-house bidding allow list 등재
  2. 당사 Audience Network App ID의 베타 enrollment 활성화 (imp.ext.platformid)
  3. Publisher ID 확인 (app.publisher.id)
  4. Placement ID 발급 — 발급 가능한 ad format에 따라 통합 범위 후속 결정 (banner / interstitial / rewarded / native)
  5. Facebook Security App 발급 절차 안내 — Security App ID (imp.ext.security_app_id) 및 App Secret (HMAC-SHA256 키)
  6. (필요시) NDA / 베타 약관 절차 안내

4. Spec 확인 요청 사항 (server-setup 문서에 명시되지 않은 부분)

Q1. bid endpoint 인증 방식
server-setup에는 요청 헤더로 Content-Type: application/json; charset=utf-8X-FB-Pool-Routing-Token: <user.buyeruid 값> 두 가지만 명시되어 있고, Authorization 헤더는 언급되지 않았습니다. 인증은 imp.ext.authentication_id = HMAC-SHA256(request_id, security_app_secret) 페이로드 필드만으로 충분한 것이 맞습니까? 별도 헤더 또는 mTLS 등이 요구된다면 안내 부탁드립니다.
Q2. Android Bidder Token 발급 권장 패턴
android-setup 문서는 BidderTokenProvider.getBidderToken(context) 직접 호출 + Volley HTTP POST + InterstitialAd.buildLoadAdConfig().withBid(payload) 패턴만 보여줍니다. 이 방식이 현재 Meta가 권장하는 Android 클라이언트 통합 패턴이 맞습니까? (Bidding Kit 3 어댑터 의존 없이)
Q3. Android Bidding Kit 3의 장기 지원 여부
BK3 overview 페이지는 iOS 지원 종료(2024 봄)만 명시하며, Android의 sunset 또는 장기 지원 여부에 대한 언급이 없습니다. 또한 BK3 setup / android-setup 페이지의 마지막 갱신일이 2021-11-03 입니다. Android BK3의 향후 로드맵을 안내해 주시면 의사결정에 도움이 됩니다.
Q4. GDPR — TC String 처리
당사는 AdMob UMP(IAB TCF v2 호환 CMP)로 동의를 수집하며, IABTCF_TCString 을 OpenRTB user.ext.consent 로, IABTCF_gdprAppliesregs.ext.gdpr 로 패스스루할 예정입니다. 공식 사실 확인: 이 경우 user.ext.consent (TC String) 단독으로는 Meta가 자신의 동의를 인식하지 못하는 것이 맞습니까? TC String만 보냈을 때 GDPR 적용 사용자에 대한 Meta의 처리 동작(no-bid / 비제한 광고 / 기타)을 안내 부탁드립니다.
Q5. GDPR — Additional Consent (AC) String 매핑 위치
Google의 AC v2 형식(2~89~dv. 등, SharedPreferences 키 IABTCF_AddtlConsent)을 Meta server-to-server bid request의 어느 OpenRTB ext 필드로 전달해야 합니까? server-setup 문서에서 GDPR/AC 처리 관련 명시를 찾지 못했습니다. 가능하다면 sample payload 한 줄(예: "user": { "ext": { "consent": "...", "consented_providers_settings": { ... } } }) 이나 정식 필드명을 공유 부탁드립니다.
Q6. UMP / CMP 측 추가 조치
당사가 사용하는 AdMob UMP에서 Meta (ATP ID 89)에 대한 Additional Consent providers 활성화만으로 Meta 측 동의 인정 흐름이 완성되는 것이 맞습니까? 또는 별도 publisher 측 설정(예: Meta Business Manager 내 동의 관련 설정)이 필요합니까?

5. 다음 단계 제안

  1. 당사 Business ID / Audience Network App ID 대응 가능한 partner manager 배정
  2. NDA(필요시) 후 정식 spec 문서 및 베타 enrollment 활성화
  3. Test mode (test=1) 통한 sandbox 검증 진행
  4. QPS / rate-limit 캐파 사전 협의 후 production roll-out

검토 부탁드리며, 답변이 필요한 항목은 Q1–Q6 으로 표시했습니다. 감사합니다.