처음에는 popunder 빈도의 trade-off가 분명할 것이라 생각했다. 광고를 덜 보여 사용자 경험을 보호하거나, 더 자주 보여 수익을 늘리다가 어느 순간 참여도가 떨어지는 식이다. 실제 운영 환경에서는 관계가 그렇게 깔끔하지 않았다.
운영 중인 웹 애플리케이션 하나에서 빈도를 높인 뒤 참여도 데이터에 명확한 변화가 생길 것으로 예상했다. 하지만 집계 지표는 이전의 일별 변동 범위 안에서 비슷하게 움직였다. 좋은 날도 나쁜 날도 있었지만, 새 정책을 기점으로 시작된 뚜렷하고 지속적인 하락은 보이지 않았다.
최종적으로 유지한 설정은 다음과 같다.
초기 지연: 45초
성공한 popunder 이후 최소 cooldown: 4분같은 4분 구간에서 성공 event를 최대 1회로 제한하는 frequency window도 유지했다.
const policy = {
initialDelaySeconds: 45,
cooldownSeconds: 240,
windowSeconds: 240,
maxEventsPerWindow: 1,
};이는 특정 광고 사업자, SDK, 애플리케이션 또는 deployment와 무관한 설명용 pseudocode다. 중요한 것은 세부 구현보다 그 뒤의 정책이다.
실제로는 빈도에 관한 결정이 두 가지다
처음에는 “popunder 사이에 몇 분을 둬야 하는가?”라는 하나의 문제로 봤다. 하지만 이는 잘못된 abstraction이었다. 최소한 첫 광고 기회까지의 지연과 이후 광고 기회 사이의 최소 간격이라는 두 가지 결정이 있다.
이 두 순간은 다르다. 새 방문자는 아직 제품이 유용한지 판단하지 못했다. 이미 참여하고 있는 사용자는 어느 정도 판단을 마친 상태다. 그래서 첫 interruption은 이후보다 더 강하게 보호해야 한다고 생각했다.
처음 몇 초를 덜 공격적으로 monetization한 이유
초기 지연을 줄이면 더 많은 방문자가 빠르게 eligible 상태가 되고 잠재적 광고 event도 늘어난다. 기계적으로는 맞다. 하지만 그 논리는 monetization이 언제 발생하는지를 무시한다.
방문 직후 광고가 거의 즉시 발생하면 사이트에 대한 첫 평가의 일부가 된다. 먼저 제품을 이해하고 사용할 수 있는 중단 없는 시간이 주어지면, 같은 광고 메커니즘도 전혀 다른 맥락에서 경험된다.
원래는 더 짧은 지연을 사용했지만 이후 45초로 늘렸다. 여전히 비교적 빠르며 보수적인 설정을 의도한 것은 아니다. 방문 시작과 첫 monetization opportunity 사이에 간격을 둔 것이다. 이 45초를 잃어버린 광고 inventory가 아니라 제품이 가치를 증명하는 시간으로 보기 시작했다.
45초는 임계값이지 예약된 광고 시점이 아니다
지연이 끝나면 eligibility가 생길 뿐 00:45에 광고가 자동으로 나타나는 것은 아니다. 실제 event는 적절한 사용자 interaction에 달려 있다. 00:45에 eligible이 되고 다음 qualifying action이 01:03이라면 첫 popunder는 그때 발생할 수 있다.
Cooldown도 같다. 4분이라는 것은 이전 성공 event 후 4분이 지나기 전에는 다음 event가 eligible이 될 수 없다는 뜻이다. 4분마다 자동으로 광고가 뜬다는 뜻이 아니다. 따라서 설정된 값은 최소 간격이며 실제 간격은 더 길어질 수 있다.
반복 간격이 초기 지연보다 더 중요했다
첫 지연을 정한 뒤에는 repeat cadence가 더 중요한 변수가 됐다. 긴 cooldown은 광고 압박을 줄이지만, 많은 engaged user가 두 번째 기회에 도달하지 못할 수도 있다.
두 조건을 동시에 원했다. 계속 사용하는 사용자는 다음 monetization event를 만들 현실적인 기회가 있어야 하고, event 사이에는 의미 있는 중단 없는 사용 시간이 남아 있어야 했다.
최종적으로 4분을 유지했다. 초기 지연이 45초라면 이론상 가장 이른 eligibility 시점은 약 00:45, 04:45, 08:45, 12:45다. 실제 event는 qualifying interaction이 필요하기 때문에 더 늦게 발생할 수 있다.
4분이 단순한 impression 최대화와 달랐던 이유
Cooldown을 줄이면 이론적 기회는 늘어난다. 유일한 metric이 사용자당 광고 기회라면 짧을수록 명백히 유리하다. 하지만 제품은 사용자 가치가 유지되는 동안에만 광고 가치도 가진다.
추가 monetization
-
행동적 손상
=
순가치4분은 다음 popunder가 절대 발생할 수 없는 의미 있는 일반 사용 구간을 제공했다. 나에게는 “4분마다 1회”라는 표현보다 이 invariant가 더 중요했다.
한 번의 monetization event 이후에는 다음 event가 불가능한 몇 분의 시간이 보장된다.
참여도가 눈에 띄게 떨어질 것으로 예상했다
배포 전의 주요 가설은 광고 빈도를 높이면 analytics에서 명확한 전후 하락이 나타날 것이라는 것이었다. 실제로 그랬다면 정책을 완화할 강한 근거가 됐을 것이다.
하지만 aggregate engagement는 이전과 비슷하게 계속 변동했다. Frequency change 이후 새로운 낮은 baseline이나 지속적으로 약한 수치의 연속은 보이지 않았다. 충분히 크면 눈에 보일 것이라 예상했던 failure mode가 명확히 나타나지 않은 것이다.
실제로 주장할 수 있는 것
광고가 아무 영향도 없었다거나, 사용자가 불편해하지 않았다거나, retention이 완전히 동일했다거나, 이 설정이 전반적으로 최적이라고 말할 수는 없다. Aggregate average만으로는 그 어떤 것도 증명할 수 없다.
관찰 결과가 뒷받침하는 가장 강한 표현은 더 좁다.
빈도를 높인 뒤에도, 이전부터 있던 일반적인 변동을 넘어서는 명확하고 지속적인 집계 참여도 하락은 관찰하지 못했다.
이 표현은 더 작은 효과, 사용자 집단 간 차이, 하나의 평균에 가려지는 행동 변화를 모두 허용한다. 테스트한 것은 이 설정이 유지할 만큼 수용 가능한지였지, 보편적인 optimum을 찾았는지가 아니었다.
안정된 평균은 매우 다른 행동을 숨길 수 있다
Aggregate average가 거의 같더라도 실제 상황은 다양할 수 있다. 거의 모든 사람이 비슷하게 행동할 수도 있고, 일부는 더 빨리 이탈하는 반면 다른 집단은 더 오래 머무를 수도 있다. 작은 집단만 부정적으로 반응해 평균을 크게 움직이지 않을 수도 있고, 실제 부정 효과가 일상적인 변동보다 작을 수도 있다.
그래서 안정적인 평균은 유용한 경고 신호로 보지만 영향이 0이라는 증거로 보지는 않는다.
Engagement는 실제 방문 시간과 같은 개념이 아니다
Analytics engagement metric을 session의 정확한 평균 길이로 보지도 않았다. Active engagement는 analytics system의 정의에 따라 측정되며 tab이 열려 있는 경과 시간과 같지 않을 수 있다. 사용자는 focus를 바꾸고, 나중에 돌아오고, 단순한 “time on site” 모델을 왜곡하는 방식으로 움직인다.
따라서 “average engagement가 X이므로 다음 popunder는 X 이전에 발생해야 한다” 같은 공식으로 interval을 정하지 않았다. Metric을 방향성 지표로만 사용했다. 변경 이후 제품이 이전보다 실질적으로 약해 보였는가? 내가 본 aggregate level에서는 아니었다.
Cooldown과 frequency window는 관련 있지만 동일하지 않다
Implementation에는 240초 cooldown과, 240초 window 안에서 최대 1회의 성공 event라는 제약이 모두 있었다. 대부분 겹치지만 조금 다른 constraint를 표현한다.
Cooldown은 이전 event 이후 충분한 시간이 지나기 전에는 다음 event를 허용하지 말라는 뜻이다. Window는 정의된 기간 안에서 성공 event를 1회보다 많이 허용하지 말라는 뜻이다. Integration이 어느 한 mechanism을 다르게 해석하더라도 intended invariant가 명확하도록 두 가지를 모두 유지했다.
성공한 두 popunder 사이의 간격은 반드시 4분 이상이어야 한다.
Window당 1회는 방문당 1회를 뜻하지 않는다
maxEventsPerWindow = 1은 방문자가 사이트에 머무는 전체 시간 동안 광고가 1회뿐이라는 뜻이 아니다. Scope는 설정된 window이고, 그 window가 끝난 뒤 새 window가 시작될 수 있다. 또한 1은 user action 1회가 아니라 해당 기간 내 성공한 monetization event 1회를 뜻한다.
이제 frequency logic을 검토할 때는 세 가지를 묻는다. Counter가 무엇을 세는가? 무엇이 reset하는가? Reset window는 얼마나 긴가? 이 답 없이 1 같은 raw value는 거의 의미가 없다.
Policy를 provider-specific implementation과 분리했다
재사용 가능한 동작은 특정 vendor script, identifier, parameter name을 노출하지 않고도 표현할 수 있다.
function isEligible(state, now) {
if (!state.hasShownFirstEvent) {
return now - state.arrivalTime >= 45_000;
}
return now - state.lastEventTime >= 240_000;
}이는 설명용 pseudocode이지 production source code가 아니다. Provider, SDK, deployment architecture는 바뀐다. 더 오래 남는 것은 방문 초반을 보호하고, 실제 사용이 시작된 뒤 monetization을 허용하고, hard cooldown을 적용한 뒤에만 반복한다는 policy다.
Build 성공과 행동의 정확성은 다른 문제다
Typechecker, linter, production build는 많은 기술적 속성을 검증할 수 있지만 browser에서 광고 timeline이 제대로 동작하는지 증명하지는 못한다. 이 기능은 behavioral validation도 필요하다.
1. 깨끗한 browser state에서 연다.
2. 초기 지연 전에 interaction한다: popunder가 없어야 한다.
3. 초기 지연이 끝날 때까지 기다린다.
4. Eligible interaction을 한다: 첫 popunder가 발생할 수 있다.
5. Cooldown 종료 전 계속 interaction한다: 두 번째 popunder는 없어야 한다.
6. Cooldown이 끝날 때까지 기다린다.
7. 다시 interaction한다: 이제 다음 popunder가 발생할 수 있다.성공한 build와 성공한 behavioral test는 서로 다른 질문에 답한다. 둘 다 중요하다.
개별 placement보다 합산된 광고 경험이 중요하다
독립적인 두 광고 시스템이 각각은 합리적으로 보여도 합치면 공격적인 경험을 만들 수 있다. 예를 들어 각각 4분 제한을 가진 두 format이 번갈아 작동하면 00:45, 02:45, 04:45, 06:45쯤 interruption이 생길 수 있다.
이 경험에서 더 나은 규칙을 얻었다.
Frequency cap은 광고 script별이 아니라 사용자 경험 전체 기준으로 평가해야 한다.
사용자는 interruption의 총합을 경험할 뿐 어느 configuration이 만들었는지는 신경 쓰지 않는다. Production audit은 일정 시간 동안 한 사용자가 실제로 몇 번의 방해형 광고 event를 만날 수 있는지 물어야 한다.
Raw impression count는 잘못된 optimization target이다
Cooldown을 줄여 더 많은 기회를 만드는 것은 쉽다. 어려운 질문은 사용자의 총 경제적 가치를 줄이지 않으면서 추가 monetization을 얼마나 얻을 수 있느냐다.
방문당 광고 수가 더 적은 설정도 repeat usage를 더 잘 보존하면 장기적으로 더 많은 revenue를 낼 수 있다. 그래서 나는 impressions per visit보다 revenue per user over time을 더 중요하게 본다. 전자는 쉽게 최대화할 수 있지만 후자가 실제 business problem이다.
더 강한 실험은 하나의 aggregate graph를 넘어서야 한다
이번 production observation은 두려워했던 catastrophic outcome이 명확하게 발생하지 않았다는 점을 확인하기에는 충분했다. 하지만 모든 downstream effect를 규명하기에는 부족했다.
더 강한 experiment라면 unique user당 monetization revenue, visit당 revenue, user당 ad event, active engagement, 의미 있는 product interaction, returning-user rate, 시간에 따른 retention, 장기 user value를 함께 비교해야 한다.
양쪽을 모두 측정해야 한다. 광고 output만 보면 거의 필연적으로 광고가 많을수록 좋다는 결론이 나온다. Engagement만 보면 행동 비용이 거의 없는 의미 있는 revenue gain을 놓칠 수 있다.
Policy를 단순하게 유지한 이유
예외를 계속 추가할 이유는 찾지 못했다. Final logic은 간단했다. 45초 기다리고, 다음 eligible interaction에서 monetization하고, 4분 hard cooldown을 적용한 뒤 다음 eligible interaction에서 다시 monetization을 허용한다.
소수의 강한 invariant가 많은 obscure exception에 의존하는 policy보다 이해, 테스트, debug 모두 쉽다.
이 비대칭은 의도적이다
새 사용자와 engaged user를 다르게 취급한다. 새 방문자는 더 많은 보호를 받고, 계속 interaction하는 사용자는 시간이 지나며 더 많은 monetization opportunity를 만든다.
즉 광고 압박은 처음부터 최대가 아니라 입증된 engagement에 맞춰 커진다. 이 개념 변화가 실험의 가장 유용한 결과 중 하나였다.
이 사례에서 결론 내리지 않을 것
45초가 모든 곳에서 정답이라거나, 4분이 optimal interval이라거나, higher-frequency popunder가 engagement를 절대 해치지 않는다거나, stable average가 사용자에게 영향이 없다는 뜻이라고 말하지 않을 것이다. 한 production workload를 모든 웹 제품에 일반화하지도 않을 것이다.
제품마다 사용자, 기대, acquisition source, usage pattern, economics가 다르다. 이 결과의 가치는 보편 법칙을 증명해서가 아니라 구체적인 상황에 대한 관찰이라는 데 있다.
내 생각을 바꾼 부분
실험 전에는 광고 압박과 engagement의 관계가 거의 기계적이라고 봤다. 하나를 충분히 높이면 다른 하나가 눈에 띄게 떨어질 것이라 예상했다. 실제 production behavior는 훨씬 덜 깔끔했다.
빈도를 내가 보기에 비교적 높은 수준까지 올렸다. 사용자는 계속 interaction했고 aggregate engagement는 익숙한 일별 범위 안에 머물렀다. 비용이 0이라는 뜻은 아니다. 단지 내가 보던 metric에서 기대했던 분명한 signal을 만들 만큼 크지 않았다는 뜻이다.
“효과가 없다”와 “이 측정에서 명확한 효과가 보이지 않는다”는 다르다. Production system은 우리가 원하는 만큼 깨끗한 인과관계를 거의 보여주지 않는다.
지금의 기준
이제는 기술적으로 다음 popunder를 얼마나 자주 띄울 수 있는지 묻지 않는다. New user가 monetization 시작 전에 얼마나 중단 없는 product experience를 가져야 하는지, engaged user가 다음 event 전에 얼마나 uninterrupted usage를 가져야 하는지, 추가 광고가 총 user value를 늘리는지 아니면 단순히 impression counter만 늘리는지를 묻는다.
이 애플리케이션에서 유지한 값은 다음과 같다.
첫 eligibility 전 45초
성공 event 사이 최소 4분구체적인 숫자는 하나의 구현일 뿐이다. 다른 곳에서도 재사용하고 싶은 원칙은 더 넓다.
사용자 여정의 시작을 보호하고, 초기 호기심보다 실제로 확인된 engagement를 더 강하게 monetize하며, raw advertising volume이 아니라 사용자 단위 가치로 결과를 판단한다.