<div id="readability-page-1" class="page"><section>
                <p>Protected Audience API는 여러가지 면에서 프라이버시 샌드박스의 핵심입니다. 한 문장으로 정리하면, 이것이 단말기 식별자가 해왔던 역할을 대체하기 때문입니다. PAAPI의 내용이 어렵기 때문에 잘 다뤄지지 않습니다. 2024년 업데이트된 PAAPI를 함께 보겠습니다.</p><h2 id="%EC%97%85%EB%8D%B0%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A7%A5%EB%9D%BD">업데이트의 맥락</h2><p>FLEDGE 그리고 PAAPI의 제안을 여러번 보고 비로소 조금씩 이해하게 되었을때, 저는 도입이 쉽지 않을 거라고 봤습니다. 비용이 너무 크거든요. 비유를 하자면 이렇습니다. 각 매체사들을 영업용 자동자 운전자라고 해보죠.</p><ul><li>이미 성능 좋은 차량을 운전하면서 수익을 잘 내고 있습니다.</li><li>그런데 앞으론 그 차는 사용할 수 없고, 구글과 공동으로 설계한 차량만이 도로에서 허용된다고 하네요.</li><li>새로운 차량과 신호 시스템은 도면만 있고 각자 만들고 적응해야 해요. 그리고 그게 운전하는데 문제가 없는지 테스트와 수리도 자비로 해야하죠.</li><li>테스트 기간동은 이미 비싸게 장만했던 예전 차량과, 새로 만들고있는 차량 두대를 관리해야 해요.</li><li>그리고 구글이 데드라인을 정하면 예전 차량은 폐기처분 해야하죠.</li></ul><p>이게 애드 테크가 마주한 현실입니다. 여러분이 매체사를 소유하고 있다고 가정해보세요. 이거 순순히 하고 싶을까요? 현금성 투자, 인적자원과 리소스 분배, 이 외에도 관리가 어려운 리스크들도 있습니다. 그래서 <a href="https://digiday.com/media-buying/heres-what-the-trade-desk-actually-thinks-about-googles-privacy-sandbox/?ref=mongmori.com">구글이 테스트 비용을 지원</a>해 준적도 있다고 하지만, 결국 TTD의 Jeff Green은 <a href="https://www.linkedin.com/posts/jefftgreen_a-new-year-and-a-new-google-a-perspective-activity-7154142190779166722-K18r/?ref=mongmori.com">공개적으로 불만을 표시</a>하기도 했죠. 그 뒤엔 <a href="https://www.adexchanger.com/online-advertising/iab-tech-lab-says-the-chrome-privacy-sandbox-is-a-time-bomb-that-will-break-rtb/?ref=mongmori.com">IAB 차원에서 꽤 거칠게</a> 나오기도 했고요. 이런 점이 PAAPI에도 변화를 가져왔다고 생각합니다.</p><h2 id="paapi%EC%9D%98-%ED%95%98%EC%9D%B4%EB%A0%88%EB%B2%A8-%EC%97%AD%ED%95%A0">PAAPI의 하이레벨 역할</h2><p>마침 프라이버시 샌드박스 <a href="https://developers.google.com/privacy-sandbox/relevance?ref=mongmori.com">개발자 페이지</a>가 이렇게 바뀌었네요. 제가 길게 설명할 필요가 없어졌군요. 이제는 잘 이해를 못하시던 분들도 PAAPI가 무슨 역할을 하도록 고안되었는지 쉽게 알 수 있을 것 같습니다.</p><figure><img src="https://www.mongmori.com/content/images/2024/06/1717295963630.png" alt="Private Sandbox API types" loading="lazy" width="794" height="701" sizes="(min-width: 720px) 720px"></figure><p>여기에서 제가 확실히 하고 싶은건,</p><ul><li>PAAPI 없이는 리타겟팅 효율이 나오지 않아요, 'Topics API로 리타겟팅 한다'는 이야기는 이젠 그만</li><li>PAAPI 없이는 옥션이 제대로 되지 않아요, 왜 애드 테크 CEO와 협회가 들고 일어났는지 이제 이해가 되실거에요</li><li>다행인건 이 비딩 &amp; 옥션 프로세스의 더 많은 부분이 서버 사이드로 넘어오도록 업데이트가 되었다는 점이에요</li></ul><h2 id="paapi%EC%9D%98-%EC%A7%84%EC%A7%9C-%EC%97%AD%ED%95%A0">PAAPI의 진짜 역할</h2><p>앞에서 제가 PAAPI가 단말기 식별자를 대체한다고 했죠. 애드 태크에 오래 있었어도 이게 무슨 역할을 했는지, 그 핵심에 아직 도달하지 못했을 수 있습니다. 단말기 식별자는</p><blockquote>유저의 pLTV를 산출하기 위해 필요</blockquote><p>합니다. 우선 pLTV는 쉽게 말해서 이 유저가 얼마짜리 가치가 있는지 예측해본 수치입니다. 충분히 가치가 있는 유저라는 판단이 있어야 광고 노출의 대상으로 삼게 되겠죠. 그리고 이 광고가 비딩과 옥션을 거치는 것이라면, 얼마에 비딩해야 할지도 pLTV를 따라가게 됩니다. pLTV를 넘는 단가를 불러서는 안되니까요. pLTV 예측이 정확할수록 결과적으로 ROI가 좋아집니다. ROI가 좋아져야 매체도 광고주도 수익율이 올라가고요.</p><p>어떤 유저의 pLTV가 계산이 되려면 이 유저가 과거에 뭘 했는지에 대해 cross site &amp; cross app 환경의 데이터가 필요합니다. 이 데이터 어떻게 확보할까요? 확보한 데이터를 어떻게 하면 신뢰할 수 있을까요? 이 정도까지 알려드렸으니 이제 이해를 하실 수 있어야 합니다.</p><p>GAID가 있을때는 쉬웠습니다. 이게 universal key 였으니까요. 이제 이게 없어지니까, 훨씬 어렵고 제한이 있겠지만 식별자 기준으로 유저 데이터 수집해서 스토리지에 쌓아두지 말고 PAAPI 가지고 로컬 환경에서 하세요 라고 구글이 제안하고 있는 것입니다. 이 맥락에서 <a href="https://developers.google.com/privacy-sandbox/relevance/protected-audience/android?hl=ko&amp;ref=mongmori.com">PAAPI의 개요</a> 부분을 읽어보세요.</p><h2 id="%EA%B0%9C%EC%84%A0%EB%90%9C-%EA%B2%83">개선된 것</h2><p>프라이버시 샌드박스 팀이 모호하지 않고 분명하게 선언을 하고 있어서 구글의 이야기를 그대로 먼저 보면 좋겠습니다.</p><blockquote>The Bidding and Auction server allows a Protected Audience computation to take place in a trusted execution environment rather than running locally on device.</blockquote><p>핵심은 PA 연산을 이젠 로컬이 아닌 서버에서 하겠다는 말입니다. 이건 꽤 괜찮은 진전입니다. 애드 테크는 유저에게 광고를 실시간으로 보여줘야 하고 이를 위해 입찰과 낙찰과 광고 서빙이 실시간으로 이루어지는게 미덕이죠. 그러나 프라이버시 샌드박스는 이것이 대부분 로컬 단말기에 의존적이게 설계를 했었습니다. 유저 데이터를 보호하기 위해서겠죠.</p><p>그러나 로컬 단말기는 그 환경적 특성상 실시간 처리가 생명인 서비스를 위해 연산을 수행하기에 미덥지 못한 점이 있습니다. 그래서 시작부터 이 부분에서 구글과 생태계는 현실적인 갈등을 겪을 수 밖에 없었다고 봅니다.</p><p>그래도 이제 <a href="https://developers.google.com/privacy-sandbox/relevance/protected-audience/android/bidding-and-auction-services?hl=ko&amp;ref=mongmori.com">입찰 서비스</a> 문서를 보면 시작부터 이렇게 언급을 하고 있어요.</p><blockquote>In the <a href="https://developers.google.com/privacy-sandbox/relevance/protected-audience/android?ref=mongmori.com">initial Protected Audience proposal</a>, bidding and auction for remarketing ad demand is executed locally on device. This requirement can demand computation requirements that may be impractical to execute on devices with limited processing power, or may be too slow to select and render ads due to network latency.</blockquote><p>흐름도를 보면 단말에서 SSP 서버를 바로 호출할 수 있고, SSP도 비딩 리퀘스트를 각 네트워크로 보내게 됩니다. 이것에 대한 사후 처리를 로컬에서 하지 않고 각자 클라우드에 조성한 TEE에서 수행한 다음 SSP를 통해서 최종 응답을 단말로 내려주게 됩니다. 애초에 이렇게 복잡한 처리의 많은 부분을 로컬에서 하겠다는 것이 너무 이상적이었습니다.</p><figure><img src="https://media.licdn.com/dms/image/D5612AQE5djqyaU5qWg/article-inline_image-shrink_1500_2232/0/1717300559926?e=1723075200&amp;v=beta&amp;t=dnEWfoTqRvcJHb7AHs7by1Q13kcG6hKK-Lmw7XEus2M" alt="privacy sandbox 통합 문맥 및 Protected Audience 입찰 흐름을 보여주는 그림" loading="lazy" width="852" height="636"></figure><p>프라이버시 샌드박스 팀이 시장의 현실에 맞게 적극적으로 의견을 듣고 방법을 찾아가는 것이 매우 고무적이고 고마운 점입니다. SKAdNetwork의 지금까지의 모습과는 많이 다르죠.</p><h2 id="%EC%A0%95%EB%A6%AC">정리</h2><p>PAAPI는 단말기 식별자가 없어지는 환경에서도 pLTV를 산출하고 실시간 광고 입찰과 리타겟팅을 하는데 핵심이 되는 스펙입니다. 그리고 입찰 프로세스의 더 많은 부분이 서버 사이드로 넘어오는 것은 구글이 시장의 피드백을 듣고 시스템에 반영하는 훌륭한 선례라고 생각하며, 프라이버시 샌드박스가 조금 더 순조롭게 시작되는데 도움이 될 것입니다.</p>
            </section></div>

Mongmori

mongmori

Protected Audience API는 여러가지 면에서 프라이버시 샌드박스의 핵심입니다. 한 문장으로 정리하면, 이것이 단말기 식별자가 해왔던 역할을 대체하기 때문입니다. PAAPI의 내용이 어렵기 때문에 잘 다뤄지지 않습니다. 2024년 업데이트된 PAAPI를 함께 보겠습니다.
업데이트의 맥락
FLEDGE 그리고 PAAPI의 제안을 여러번 보고 비로소 조금씩 이해하게 되었을때, 저는 도입이 쉽지 않을 거라고 봤습니다. 비용이 너무 크거든요. 비유를 하자면 이렇습니다. 각 매체사들을 영업용 자동자 운전자라고 해보죠.
이미 성능 좋은 차량을 운전하면서 수익을 잘 내고 있습니다.
그런데 앞으론 그 차는 사용할 수 없고, 구글과 공동으로 설계한 차량만이 도로에서 허용된다고 하네요.
새로운 차량과 신호 시스템은 도면만 있고 각자 만들고 적응해야 해요. 그리고 그게 운전하는데 문제가 없는지 테스트와 수리도 자비로 해야하죠.
테스트 기간동은 이미 비싸게 장만했던 예전 차량과, 새로 만들고있는 차량 두대를 관리해야 해요.
그리고 구글이 데드라인을 정하면 예전 차량은 폐기처분 해야하죠.
이게 애드 테크가 마주한 현실입니다. 여러분이 매체사를 소유하고 있다고 가정해보세요. 이거 순순히 하고 싶을까요? 현금성 투자, 인적자원과 리소스 분배, 이 외에도 관리가 어려운 리스크들도 있습니다. 그래서 구글이 테스트 비용을 지원해 준적도 있다고 하지만, 결국 TTD의 Jeff Green은 공개적으로 불만을 표시하기도 했죠. 그 뒤엔 IAB 차원에서 꽤 거칠게 나오기도 했고요. 이런 점이 PAAPI에도 변화를 가져왔다고 생각합니다.
PAAPI의 하이레벨 역할
마침 프라이버시 샌드박스 개발자 페이지가 이렇게 바뀌었네요. 제가 길게 설명할 필요가 없어졌군요. 이제는 잘 이해를 못하시던 분들도 PAAPI가 무슨 역할을 하도록 고안되었는지 쉽게 알 수 있을 것 같습니다.
여기에서 제가 확실히 하고 싶은건,
PAAPI 없이는 리타겟팅 효율이 나오지 않아요, 'Topics API로 리타겟팅 한다'는 이야기는 이젠 그만
PAAPI 없이는 옥션이 제대로 되지 않아요, 왜 애드 테크 CEO와 협회가 들고 일어났는지 이제 이해가 되실거에요
다행인건 이 비딩 & 옥션 프로세스의 더 많은 부분이 서버 사이드로 넘어오도록 업데이트가 되었다는 점이에요
PAAPI의 진짜 역할
앞에서 제가 PAAPI가 단말기 식별자를 대체한다고 했죠. 애드 태크에 오래 있었어도 이게 무슨 역할을 했는지, 그 핵심에 아직 도달하지 못했을 수 있습니다. 단말기 식별자는
유저의 pLTV를 산출하기 위해 필요
합니다. 우선 pLTV는 쉽게 말해서 이 유저가 얼마짜리 가치가 있는지 예측해본 수치입니다. 충분히 가치가 있는 유저라는 판단이 있어야 광고 노출의 대상으로 삼게 되겠죠. 그리고 이 광고가 비딩과 옥션을 거치는 것이라면, 얼마에 비딩해야 할지도 pLTV를 따라가게 됩니다. pLTV를 넘는 단가를 불러서는 안되니까요. pLTV 예측이 정확할수록 결과적으로 ROI가 좋아집니다. ROI가 좋아져야 매체도 광고주도 수익율이 올라가고요.
어떤 유저의 pLTV가 계산이 되려면 이 유저가 과거에 뭘 했는지에 대해 cross site & cross app 환경의 데이터가 필요합니다. 이 데이터 어떻게 확보할까요? 확보한 데이터를 어떻게 하면 신뢰할 수 있을까요? 이 정도까지 알려드렸으니 이제 이해를 하실 수 있어야 합니다.
GAID가 있을때는 쉬웠습니다. 이게 universal key 였으니까요. 이제 이게 없어지니까, 훨씬 어렵고 제한이 있겠지만 식별자 기준으로 유저 데이터 수집해서 스토리지에 쌓아두지 말고 PAAPI 가지고 로컬 환경에서 하세요 라고 구글이 제안하고 있는 것입니다. 이 맥락에서 PAAPI의 개요 부분을 읽어보세요.
개선된 것
프라이버시 샌드박스 팀이 모호하지 않고 분명하게 선언을 하고 있어서 구글의 이야기를 그대로 먼저 보면 좋겠습니다.
The Bidding and Auction server allows a Protected Audience computation to take place in a trusted execution environment rather than running locally on device.
핵심은 PA 연산을 이젠 로컬이 아닌 서버에서 하겠다는 말입니다. 이건 꽤 괜찮은 진전입니다. 애드 테크는 유저에게 광고를 실시간으로 보여줘야 하고 이를 위해 입찰과 낙찰과 광고 서빙이 실시간으로 이루어지는게 미덕이죠. 그러나 프라이버시 샌드박스는 이것이 대부분 로컬 단말기에 의존적이게 설계를 했었습니다. 유저 데이터를 보호하기 위해서겠죠.
그러나 로컬 단말기는 그 환경적 특성상 실시간 처리가 생명인 서비스를 위해 연산을 수행하기에 미덥지 못한 점이 있습니다. 그래서 시작부터 이 부분에서 구글과 생태계는 현실적인 갈등을 겪을 수 밖에 없었다고 봅니다.
그래도 이제 입찰 서비스 문서를 보면 시작부터 이렇게 언급을 하고 있어요.
In the initial Protected Audience proposal, bidding and auction for remarketing ad demand is executed locally on device. This requirement can demand computation requirements that may be impractical to execute on devices with limited processing power, or may be too slow to select and render ads due to network latency.
흐름도를 보면 단말에서 SSP 서버를 바로 호출할 수 있고, SSP도 비딩 리퀘스트를 각 네트워크로 보내게 됩니다. 이것에 대한 사후 처리를 로컬에서 하지 않고 각자 클라우드에 조성한 TEE에서 수행한 다음 SSP를 통해서 최종 응답을 단말로 내려주게 됩니다. 애초에 이렇게 복잡한 처리의 많은 부분을 로컬에서 하겠다는 것이 너무 이상적이었습니다.
프라이버시 샌드박스 팀이 시장의 현실에 맞게 적극적으로 의견을 듣고 방법을 찾아가는 것이 매우 고무적이고 고마운 점입니다. SKAdNetwork의 지금까지의 모습과는 많이 다르죠.
정리
PAAPI는 단말기 식별자가 없어지는 환경에서도 pLTV를 산출하고 실시간 광고 입찰과 리타겟팅을 하는데 핵심이 되는 스펙입니다. 그리고 입찰 프로세스의 더 많은 부분이 서버 사이드로 넘어오는 것은 구글이 시장의 피드백을 듣고 시스템에 반영하는 훌륭한 선례라고 생각하며, 프라이버시 샌드박스가 조금 더 순조롭게 시작되는데 도움이 될 것입니다.

프라이버시 샌드박스에 대해 말하지 않는 것 - PAAPI

댓글