개인 정보 보호 샌드박스 관련성 및 측정 API와 관련하여 자주 묻는 질문(FAQ)의 답변입니다.
Topics는 판매자 정의 잠재고객 (SDA)과 어떻게 다른가요?
Topics와 SDA는 상호 보완적인 유형의 정보를 제공하며 둘 다 게시자가 제어합니다. Google은 이 둘이 서로 경쟁한다고 생각하지 않습니다. 대신 둘 다 나란히 또는 서로 다른 컨텍스트에서 작동하여 구매 기회를 극대화합니다. 구매자는 프로그래매틱 방식으로 노출수를 평가할 때 많은 신호를 고려하고 사용하므로 Topics가 이러한 고려 사항 중 하나가 될 것으로 예상됩니다. 판매자는 지금까지 공개 마켓 경매에 잠재고객 세그먼트를 포함하지 않았으며 Topics가 사용될 가능성이 높습니다. 대신 판매자는 광고주, 대행사 또는 DSP와 체결한 거래에서 잠재고객을 프로그래매틱 구매에 사용할 수 있도록 했습니다. 이러한 경우 판매자와 구매자는 의도적으로 SDA에서 거래하고 있습니다. 이러한 경우에 Topics가 사용된다면 다음 중 하나 이상에 사용될 수 있습니다.
- Topics로 잠재고객 정의를 보완하는 영업 담당자
- 주제를 입찰가에 대한 신호로 사용하는 구매자
- Topics를 사용하여 SDA가 정확한지 확인
Protected Audience가 잠재고객 생성 권한을 Google에 맡기나요?
아니요. 사이트는 개인 정보 보호 샌드박스 내부와 외부에서 자체 잠재고객을 계속 구축할 수 있습니다. 사이트에서 개인 정보 보호 샌드박스 내에서 잠재고객을 구축할 때 사이트 소유자 또는 선택한 프록시는 잠재고객을 구축할 수 있는 사용자, 해당 잠재고객의 정의, 잠재고객이 업데이트되는 방식, 잠재고객의 입찰 방식, 잠재고객에서 사용자를 삭제할지 여부를 결정합니다.
Protected Audience는 게시자가 생성한 관심분야 그룹을 지원하나요?
예. Google은 게시자가 데이터 유출을 두려워하여 현재 잠재고객을 OpenRTB 기반 입찰에 참여하지 않도록 조심하는 것을 잘 알고 있습니다. 게시자는 Protected Audience에서 현재 입찰자에게 개별 게시자 사용자의 크로스 사이트 보기를 제공하지 않는 잠재고객을 구축할 수 있습니다. 게시자가 Protected Audience의 데이터 유출 감소 환경을 활용할 수 있는 방법을 계속 모색하게 되어 기쁩니다.
Protected Audience 입찰에서 광고 품질 규칙은 어떻게 적용되나요?
Protected Audience 입찰에서 광고 품질 규칙이 시행되는 방법에는
여러 가지가 있습니다. 각각은 현재 SSP에서 광고 품질 규칙을 적용하는 방식과 유사합니다. 한 가지 방법은 알 수 없는 광고 소재가 있는 입찰에서 광고 소재가 검사를 위해 대기열에 들어가도록 하는 것입니다. Google은 SSP가 이러한 사용 사례에 더 나은 지원을 원한다는 의견을 수렴했으며, SSP가 대역 외로 감사한 다음 키-값 서버에 정보를 저장할 수 있는 renderUrls의 피드를 만들 수 있는 메커니즘을 설계하고 있습니다. 광고 사전 등록을 요구할 수도 있습니다. 이전의 사례와 마찬가지로 광고 소재를 스캔하고 나면 결과를 키-값 서버에 연결할 수 있습니다. 그런 다음 나중에 구매자가 이 광고 소재로 입찰하면 (OpenRTB와 동일한 형식을 따르는 광고 소재 ID로 표시됨) 판매자의 점수 로직은 키-값 서버에서 조회를 실행하여 그에 따라 점수를 매기는 방법을 결정할 수 있습니다.
Protected Audience는 동영상 광고를 지원하나요?
예. VAST URL은 Protected Audience의 안팎으로 전달될 수 있습니다. VAST URL이 나오면 판매 측 기술은 구매자의 VAST URL을 플레이어로 전송하기 전에 어떻게 래핑할지 조정할 수 있습니다. 분리 프레임 (2026년 이전)으로 이전하고 사용자 개인 정보 보호 기능을 더욱 강화해야 한다는 요구사항보다 앞서 생태계가 동영상을 확실히 포함하는 디자인 논의에 참여할 것으로 예상됩니다.
Protected Audience는 네이티브 광고를 지원하나요?
예. JSON URL은 Protected Audience 안팎으로 전달될 수 있습니다. JSON URL이 출력되면 판매 측 기술은 최종 JSON이 렌더링 코드에 전달되기 전에 원하는 이벤트를 추가하는 방법을 조정할 수 있습니다. 사용자 개인 정보 보호 기능을 더욱 강화하기 위해 분리된 프레임 (2026년 이전)으로 이동해야 한다는 요구사항을 충족하기 전에 생태계에서 네이티브가 포함될 가능성이 높은 디자인 논의에 참여할 것으로 예상됩니다.
Protected Audience 광고 렌더링이 혁신을 방해하나요?
아니요. 지금까지 광고 렌더링은 항상 브라우저 기술에 의존해 왔습니다. 이 사실은 변하지 않습니다. 이 문제는 향후 Protected Audience와 함께 Fenced Frames를 사용해야 하는 계획에만 해당하는 문제일 수 있습니다. 이러한 계획을 '미래'로 내놓는 이유 중 하나는 Fenced Frames 기술이 광고 렌더링에 관한 생태계의 혁신과 차별화를 지원하기를 원하기 때문입니다. 이에 관심이 있는 개발자와 회사는 네이티브 광고 접근 방식을 지원하는 방법을 비롯하여 Fenced Frames의 방향에 대해 고민해야 할 때가 있습니다.
Protected Audience를 사용하면 현재 기존 입찰에서 존재하는 정교한 예산 소진 속도 및 입찰 가치 평가 방식을 사용할 수 있나요?
Protected Audience는 구매자가 캠페인 속도와 예산을 파악할 수 있는 실시간 옵션을 제공합니다. 인벤토리 관점에서 판매자는 구매자에게 페이지 및 그 밖의 모든 맥락에 대한 입찰 신호를 제공할 수 있습니다. 판매자가 문맥 입찰 요청을 전송하기로 선택하면 구매자는 이 메커니즘을 통해 인벤토리에 관해 알아본 다음 Protected Audience 입찰 생성에 사용할 수 있는 문맥 시그널 (perBuyerSignals를 통해)을 자체적으로 제공할 수 있습니다. 얼리 어답터들은 이미 머신러닝 시스템을 Protected Audience에 연결하고 있습니다. 이러한 시스템을 Protected Audience 환경의 입찰에 맞게 조정하는 데 시간이 걸릴 수 있다는 점을 이해하지만 조정이 가능하며 이미 수행되고 있다는 점에 유의해야 합니다.
OpenRTB 표준은 Protected Audience에서 작동하나요?
예. IAB Tech Lab에서는 많은 분들이 모인 대표 DSP 및 SSP 그룹을 통해 이 작업을 진행 중입니다. 앞으로는 Protected Audience 입찰 내에서 OpenRTB 프로토콜의 일부를 통신 표준으로 사용할 것으로 보이며, Google은 이미 이러한 방식으로 빌드하고 있는 얼리 어답터를 알고 있습니다.
Protected Audience를 사용하려면 회사에서 광고 게재를 위해 두 개의 별도 아키텍처를 유지해야 하나요?
아니요. Protected Audience에는 별도의 두 아키텍처를 유지할 필요가 없습니다. 아키텍처 선택은 여러분의 몫입니다. 지난 몇 년 동안 온라인 광고가 발전함에 따라 시스템의 복잡성도 함께 진화했습니다. 인터넷의 개인 정보 보호 수준을 낮추면 복잡도가 증가하고 작업이 필요합니다 광고 기술 회사는 두 개의 별도 아키텍처를 유지하거나 Protected Audience를 기존 입찰과 결합된 아키텍처로 빌드할 수 있습니다.
광고 기술 회사들이 Protected Audience를 지원하게 되면 기존 입찰은 어떻게 될까요?
문맥 입찰은 거래, 퍼스트 파티가 아닌 잠재고객 타겟팅 캠페인, 기타 여러 문맥 시나리오 등 여러 가지 이유로 여전히 관련성이 있을 것으로 예상됩니다. 또한 관심분야 그룹이 없거나 Protected Audience의 입찰가가 가격 하한선에 도달하지 못하거나 광고 품질 규칙을 준수하지 못하는 경우에도 계속해서 가치가 있습니다.
Protected Audience 입찰은 광고주와 게시자 간의 총 중개자 수 또는 특정 광고 기회의 중복을 줄이기 위한 생태계 공급 경로 최적화 (SPO)의 노력과 반대되나요?
아니요. 보호된 잠재고객에서 낙찰된 광고는 최대 2개의 판매자 항목 (예: 공급측 플랫폼 (SSP) 및 게시자 광고 서버)을 통과하며, 구매자가 게시자와의 직접 통합을 구축한 경우에는 극히 적은 수의 판매자 항목을 통과합니다.
여러 중개자를 사용하여 동일한 요청을 중복해서 사용할지는 여전히 게시자가 선택합니다. Protected Audience는 어느 쪽으로든 영향을 미치면 안 됩니다.
Protected Audience 입찰은 사이트 간 사용자 데이터가 유출되지 않도록 오늘날의 서버 간 실시간 시스템 외부에서 이루어집니다. 광고 요청이 중복된다고 말하는 사람들도 있습니다. 기술적으로 입증 가능한 개인 정보 보호를 확보하려면 몇 가지 절충점이 필요합니다. 그러나 장기적으로 보면 생태계가 기존의 서버 측 입찰 없이 Protected Audience를 사용하기로 결정할 수 있습니다. 이러한 선택을 통해 공급 경로를 더욱 최적화할 수 있습니다.
Protected Audience는 기존 트래픽 형태 인프라의 가치를 낮추나요?
아시다시피, 초당 쿼리 수와 관련하여 변경되는 점은 많은 SSP가 크로스 사이트 ID를 DSP에 요청을 전송할지 여부를 결정하는 기능으로 사용한다는 점입니다. 따라서 교차 사이트 ID가 줄어들면 기존 트래픽 형태 기법이 영향을 받습니다. 이는 게시자가 Protected Audience 입찰을 실행할지 여부에 상관없이 적용됩니다.
여러 SSP의 트래픽 형태를 살펴보고 캐싱 및 컨텍스트 기반 필터링을 비롯한 솔루션을 찾았습니다. 시간이 지남에 따라 개발자가 비공개 집계를 활용하여 DSP 입찰 환경설정을 더 잘 이해하고 그에 따라 필터링할 수 있을 것으로 예상됩니다.
궁극적으로는 교차 사이트 식별자를 중심으로 구축된 일부 기존 인프라는 더 이상 유용하지 않습니다.
Protected Audience 입찰로 인한 새로운 요청으로 인해 SSP 용량이 부족해지나요?
일부 SSP는 통합 관점에서 역량이 문제가 되거나 SSP 가치 제안에서 중요한 부분이 아니라는 이야기를 들었습니다. 입찰 프로세스에서 새로운 호출을 우려하는 SSP를 위해 Google은 이미 용량 문제와 관련하여 SSP를 지원하는 회사를 알고 있으며 Protected Audience를 지원하도록 해당 서비스를 확장하려고 합니다. 이러한 회사 중 하나와 연결되기를 원하는 경우 Google에 알려주세요.
브라우저에 경쟁 리소스가 있는 경우 Protected Audience에서 우선순위는 어떻게 처리되나요?
Protected Audience는 일반적으로 판매자가 입찰자가 소비할 수 있는 시간과 리소스를 결정할 수 있는 빌드 컨트롤과 구매자가 사용 가능한 리소스를 가장 잘 사용하는 방법을 결정할 수 있는 도구를 빌드하는 표준 패러다임을 따랐습니다. 이러한 제어 및 도구는 현재 제공되지만 구매자와 판매자가 이 기능을 채택하면 모든 이점을 누릴 수 있습니다. 또한 Chrome은 입찰 속도에 관한 다양한 인프라 개선을 위해 계속 노력하고 있습니다 (예: crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/31977197).
Protected Audience는 지연 시간 문제를 어떻게 해결하나요?
이전에는 Protected Audience가 도입되기 전에는 서버에서 발생한 실시간 입찰에서 판매자가 지연 시간을 억제하기 위해 구매자의 응답에 엄격한 시간 제한을 지정해야 했습니다. Google에서는 지연 시간 확인이라는 동일한 목표를 달성하기 위해 매우 유사한 다양한 판매자 지정 제한 시간 컨트롤 (perBuyerCumulativeTimeouts, perBuyerTimeouts, sellerTimeout 문서 참고)을 Protected Audience에 추가했습니다. 또한 이러한 컨트롤을 통해 입찰 참여자가 로직을 최적화하여 광고 기술 생태계와 고품질 사용자 환경을 지원하는 데 리소스가 가장 효율적으로 사용되도록 할 수 있습니다.
또한 Chrome은 입찰 속도에 관한 다양한 인프라 개선을 위해 계속 노력하고 있습니다 (예: crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Google은 이러한 지연 시간 노력의 두 부분(구매자와 판매자가 유용하게 활용할 수 있는 추가 도구와 Chrome 엔지니어가 조사해야 하는 관찰된 병목 현상에 관한 보고서)에 관한 의견을 요청합니다.
입찰 서비스 (B&A)가 존재할 때 온디바이스 Protected Audience를 구축하는 데 노력이 낭비되었나요?
아니요. 광고 기술 사용 사례에서는 기기 내로 충분합니다. 입찰 서비스는 광고 기술이 브라우저에서 허용하는 것보다 입찰가 계산 리소스에 더 많이 투자하려는 경우 선택적으로 사용할 수 있는 수평적 확장 솔루션입니다. 기기 내 개발은 좋은 투자입니다. 개발자가 나중에 입찰 서비스 환경에 참여하기로 결정하더라도 대부분의 작업을 재사용할 수 있기 때문입니다. 빌드된 파이프와 인프라는 대부분 비슷하게 작동합니다.
Protected Audience에 대한 클라우드 기반 TEE (신뢰할 수 있는 실행 환경) 요구사항으로 인해 비즈니스가 Google Cloud를 사용하게 되나요?
개인 정보 보호 샌드박스는 강력한 개인 정보 보호 및 보안을 제공하도록 API를 설계했으며, Google은 Google Cloud에 도움이 되는 설계 결정을 내리지 않았습니다. Google은 얼마나 많은 광고 기술 제공업체가 Amazon을 선택한다는 점을 알고 있기 때문에 클라우드 제공업체에 대한 Google의 지원은 AWS에서 시작되었습니다. 향후 AWS 및 Google Cloud 외에도 다른 클라우드 제공업체도 지원할 예정입니다. 다른 클라우드 제공업체에 대한 제안도 환영합니다. 지연 시간이 우려된다면 클라우드는 다른 클라우드 제공업체와의 거리를 단축하는 위치 옵션을 고객에게 제공합니다.
개인 정보 보호 샌드박스를 사용하면 비공개 클라우드 데이터 센터에서 TEE (신뢰할 수 있는 실행 환경)를 실행할 수 있나요?
감사 가능한 신뢰할 수 있는 실행 환경(TEE)은 Google의 개인 정보 보호 및 보안 모델의 일부입니다. Google은 엄격한 보안 조치로 인해 퍼블릭 클라우드 제공업체가 제공하는 TEE로 시작했습니다. 명확히 하자면, 가까운 시일 내에 신뢰할 수 있는 실행 환경을 사용해야 하는 API는 Attribution Reporting API 및 Private Aggregation API이며, 둘 다 입찰 설정에서 실시간으로 TEE를 호출하지 않습니다. Google은 퍼블릭 클라우드 기반 솔루션 이외의 옵션에 대한 지원을 지속적으로 모색하고 있습니다.
퍼블릭 클라우드에서 온프레미스 광고 기술 데이터 센터와 달리 신뢰할 수 있는 실행 환경을 실행하는 데 더 많은 비용이 들지 않을까요?
Google의 현재 TEE 개인 정보 보호 모델은 퍼블릭 클라우드 구현의 보안 관행의 이점을 누리고 있으며, 온프레미스에서 신뢰할 수 있는 실행 환경을 운영하는 것이 비용이 적게 든다는 가정에 의문을 제기합니다. 다음은 이러한 관행을 위한 몇 가지 비용 고려사항입니다.
퍼블릭 클라우드 제공업체는 보안 측면에서 매우 높은 기준을 갖춰야 합니다. 예를 들어 AWS는 보안 관행이 정립된 공신력 있는 클라우드 제공업체입니다. 특히 AWS Nitro에는 Nitro Enclaves가 엔클레이브에서 처리되는 데이터에 작업자가 액세스하는 것을 방지하고, 보호된 리소스 (예: 복호화 키)가 엔클레이브에서 실행되는 승인된 코드에만 사용 가능하도록 하기 위한 문서화된 보안 모델이 있습니다. 물리적 액세스도 고려해야 합니다. AWS는 Amazon 직원을 포함한 물리적 액세스 위험에 대한 완화 방법을 설계하고 구현했습니다. 기존 하드웨어 기반 TEE는 퍼블릭 클라우드가 의도한 모든 물리적 공격을 방어하지 못할 수 있습니다. 또한 Amazon은 최근 독립 연구 회사인 NCC Group과 협력하여 내부 직원의 액세스와 관련된 보안 청구에 중점을 둔 Nitro 설계를 검토했습니다. 공개 보고서는 AWS 설계가 이러한 주장을 충족함을 보여줍니다.
이러한 관행을 정립하고, 지원하고, 시간이 지남에 따라 개선하는 데는 비용이 들게 됩니다. 전 세계에 분산되어 널리 사용되는 퍼블릭 클라우드를 사용하면 이러한 비용이 광범위한 고객층에 분산됩니다.
개인 정보 보호 샌드박스가 청구를 변경하나요?
아니요. 광고 기술 회사와 기타 API 호출자는 페이지에서 특정 항목이 렌더링되었는지 여부와 가격이 얼마인지 계속 확인할 수 있습니다.
개인 정보 보호 샌드박스에서 최대 게재빈도를 설정할 수 있나요?
Protected Audience는 prevWinsMs 객체를 통해 동일한 관심분야 그룹 내에서 크로스 사이트 최대 게재빈도 설정을 지원합니다. Protected Audience 입찰 내 구매자의 generateBid() 함수는 동일한 브라우저의 이전 광고 노출 결과를 기반으로 입찰 전략을 알릴 수 있는 로직을 만들 수 있습니다.
Protected Audience 외부에서 최대 게재빈도 설정에 사용할 수 있는 몇 가지 솔루션이 있지만 이러한 솔루션은 광고 기술이 서드 파티 쿠키를 사용하는 크로스 사이트 기법에 완전히 매핑되지는 않습니다.
- 퍼스트 파티 쿠키: 광고 기술이 자체 퍼스트 파티 데이터를 사용하여 자체 사이트에서 최대 게재빈도를 설정할 수 있습니다.
- CHIP: 광고 기술은 파티션을 나눈 쿠키를 사용하여 사이트별 수준에서 최대 게재빈도를 관리할 수 있습니다.
- 공유 저장소
SelectURL(): 광고 기술이 입찰에서 낙찰된 후 광고 소재를 렌더링하기 전에 공유 저장소를 호출하여 크로스 사이트 데이터에 액세스하고 URL 선택 출력 게이트를 통해 빈도에 따라 올바른 광고 소재를 선택할 수 있습니다.
의미 있는 광고 기술 유틸리티를 제공하는 개인 정보 보호를 추구하지만 보호되지 않는 잠재고객 최대 게재빈도 설정 솔루션은 다음과 같은 이유로 어렵습니다.
- 현재 광고 기술 의견에 따르면 주파수 신호가 노이즈를 허용할 수 있는지 여부가 명확하지 않습니다.
- Google에서는 크로스 사이트 게재빈도 신호를 입찰 시간에 사용할 수 있어야 하고, 이를 위해서는 노이즈가 없는 크로스 사이트 신호를 모든 광고 입찰에 사용할 수 있어야 한다는 일관된 광고 기술 의견을 들었습니다. 이로 인해 사이트 전반의 사용자 활동에 관한 많은 양의 정보가 노출되어 개인 정보 보호 샌드박스의 개인 정보 보호 목표가 약화될 수 있습니다.
- Google은 지연 시간의 도입에 민감하며, 이 신호를 제공할 수 있는 기기 내 솔루션은 지연 시간을 유발하고 입찰 환경을 방해할 수 있습니다.
- 솔루션은 W3C 제안 프로세스를 거쳐야 하는 새로운 API여야 할 수 있습니다.
따라서 Protected Audience 외부에서 최대 게재빈도 솔루션을 빌드하는 것은 당장은 로드맵에 포함되어 있지 않지만 이 사용 사례를 해결할 수 있는 잠재적 방법에 관한 의견을 기다리고 있습니다.
개인 정보 보호 샌드박스가 적용되지 않는 사용 사례는 어떤가요?
개인 정보 보호 샌드박스 API는 개발자가 유연하게 조합 방법을 결정할 수 있는 개인 정보 보호 광고를 위한 핵심 구성요소를 제공합니다. 구성 요소 접근 방식을 통해 기업은 고객에게 가치를 제공하는 솔루션을 혁신하고 개발할 수 있습니다. 개인 정보 보호 샌드박스가 모든 사용 사례를 위한 엔드 투 엔드 솔루션이 되는 것은 아닙니다. 좋지 않은 결과가 될 것이라고 생각합니다. 대신 개발자와 비즈니스는 솔루션에 통합되는 개인 정보 보호 샌드박스 API를 비롯한 다양한 기술을 통해 계속해서 아이디어를 실현할 수 있습니다.