유닛별 프리퀀시 정책 기획서

버전	일자	변경 내용
v0.1	2026-07-24	최초 작성 — 배경/목적, 기존 vs 신규 방식, 타겟팅별 프리퀀시 기본값, 84개 유닛 랭크·차등 배분 원칙, 서빙 처리 로직 초안

01개요

기존 타겟팅 단위로 운영되던 프리퀀시 기능을 그대로 활용하여, 타겟팅에 종속된 유닛별로 프리퀀시를 분배해 운영한다.

02배경 및 목적

모비온 3.1에서는 프리퀀시(유저별 일 노출 상한)가 타겟팅 단위로만 존재하며, 광고 보고서 > 중복클릭 보고서 > 타겟팅별 중복클릭 현황 화면에서 확인 및 설정할 수 있다. 모비온 4.0에는 해당 설정 기능이 제공되지 않는다.

스마트 유닛 관리에서는 유닛을 타겟팅 × 시간등급 × 지면등급 조합으로 세분화하여 운영한다. 타겟팅은 사전에 고정되는 값이 아니라 노출 요청 시 유저에게 묻은 쿠키(세그먼트 정보)에 따라 결정되며, 하나의 타겟팅에 대해서는 지면등급 12단계 × 시간등급 7단계, 즉 84개 유닛으로 구성된다. 이하 본 문서에서는 이 84개 유닛을 타겟팅 유닛이라 한다.

프리퀀시 = AUID 기준으로 유저별 노출수를 제어하는 기능. 하나의 유닛이 특정 유저(AUID)에게 하루에 노출될 수 있는 최대 횟수를 의미하며, 타겟팅에 부여되는 속성이다. 신규 설계 대상은 "이 값을 84개 유닛에 어떻게 나눌 것인가" 및 "서빙 시 어떻게 체크할 것인가"이다.

03기존(3.1) vs 신규 방식

3.1 기존 방식

프리퀀시는 타겟팅별 AUID에 대해 고정값으로 존재 (예: 라스트클릭=10, 카트=9,999 등 타겟팅 유형별 33종) — 총량은 광고주 단위로 제어됨
유닛(지면×시간 조합) 단위의 세분화된 프리퀀시 개념 자체가 없었음

3.2 신규 방식 (스마트 유닛 관리)

타겟팅 고정 시 타겟팅 유닛(지면등급 1~12 × 시간등급 1~7, 84개)으로 세분화
타겟팅 단위 프리퀀시 기본값을 타겟팅 유닛에 랭크 기반으로 차등 배분
모비온 3.1에서 제공되던 (타겟팅 단위) 프리퀀시 수정 기능은, 유닛별 프리퀀시 기능이 제공되면 더 이상 제공하지 않음

04타겟팅별 프리퀀시 기본값 (3.1 기준 · 순위는 CPC 자동화 타겟팅 목록 순서)

아래는 모비온 3.1 타겟팅별 중복클릭(프리퀀시) 기본값이며, 타겟팅 유닛 차등 배분의 기준(총량)이 되는 값이다. 약어는 매칭 로직 상 사용되는 코드다.

프리퀀시 기본값은 타겟팅 유닛 기준 Max값으로 재산정할 예정이다.

순위	타겟팅	약어	프리퀀시
1	투데이카트	TC	15
2	위클리카트	WC	30
3	라스트클릭	LC	10
4	위클리가망고객	PU	20
5	투데이보완재	TP	30
6	헤비리인게이지먼트	HE	10
7	위클리보완재	WP	50
8	먼슬리보완재	SP	50
9	원타임리턴	HR	3
10	먼슬리카트	MC	150
11	하프보완재	HP	30
12	커스텀하이	CH	5
13	카트	CW	9,999
14	원타임본상품	HV	4
15	온사이트서치	OS	미정
16	휴면유저	RU	30
17	투데이리턴	TR	5
18	투데이본상품	TV	10
19	먼슬리가망고객	MU	20

순위	타겟팅	약어	프리퀀시
20	위클리본상품	WV	20
21	위클리리턴	WR	30
22	관심상품	RC	40
23	헤비유저	HU	20
24	먼슬리본상품	MV	100
25	본상품	SR	200
26	먼슬리리턴	FR	30
27	리턴	RM	9,999
28	리인게이지먼트미사용	RE	20
29	커스텀리타겟팅	CR	30
30	검색어	KL	40
31	헤비성향	HM	50
32	가망고객	BP	20
33	유저유사도	US	미정
34	성향	UM	999
35	카테고리	CM	무제한
36	오디언스	AU	무제한
37	베이스광고	AD	무제한

※ 온사이트서치(OS)·유저유사도(US)는 CPC 자동화 타겟팅 목록에는 있으나 기존 3.1 프리퀀시 기본값 목록에는 없어 값을 "미정"으로 표시했습니다.

05타겟팅 유닛 랭크 및 차등 배분 원칙

5.1 유닛 구성

유닛 = 타겟팅 × 지면등급(1~12등급) × 시간등급(1~7등급) 조합
타겟팅은 유저 쿠키(세그먼트) 매칭으로 결정되며, 하나의 타겟팅 기준으로는 지면등급×시간등급 조합인 84개 유닛(= 타겟팅 유닛)이 구성됨
타겟팅 유닛(84개) 구조는 광고그룹별로 존재하며, 광고그룹마다 각자의 84개 유닛 세트를 가짐
지면등급: 기존 지면 등급 체계에서 12등급까지 활용(스마트 유닛 관리에서는 NA등급을 7등급으로 취급)
시간등급: G1~G7 (전환율 기준)

5.2 타겟팅 유닛 서열

지면등급 × 시간등급 → 순서 산출 기준은 KPI별로 기정의된 유닛 서열을 그대로 적용

5.3 차등 배분 원칙 (1안 / 2안 — 결정 전, 병렬 검토)

1안분배형

타겟팅 프리퀀시 기본값을 총량으로 고정
84개 유닛이 랭크에 따라 이 총량을 나눠 가짐 (유닛 합계 = 타겟팅 기본값)
랭크가 낮아질수록 배분값도 감소
타겟팅 전체 노출 상한이 기존 정책과 동일하게 유지됨

2안차등 제한형 (독립 캡)

랭크1 = 타겟팅 프리퀀시 기본값(Max) 그대로 사용
랭크2 → 84로 갈수록 값이 작아지는 유닛별 독립 캡 (유닛 간 합계 제약 없음)
단, 해당 타겟팅에 대한 유저의 전체 누적 노출은 별도로 타겟팅 단위 총 상한(Max)을 넘지 않도록 체크 (6.2 참조)

이 총 상한(Max)은 광고주 기준 공유 풀이다 — 광고그룹별로 독립된 상한을 갖는 것이 아니라, 같은 광고주 산하 모든 광고그룹의 타겟팅 유닛이 하나의 상한을 함께 차감함
유닛은 타겟팅별로 최소 1회 이상의 프리퀀시가 확보되어야 하므로, 타겟팅별 프리퀀시 최소값·최대값 정책을 수립해야 함 — 구체적인 값은 연구팀과 별도 논의 예정 (7장 참조)

예시 — 랭크에 따라 값이 감소하는 형태 (개념도, 1안·2안 공통): 랭크1(최상) > 랭크20 > 랭크84(최하) 순으로 값이 작아짐
(구체적 수치·배분 함수는 채택 안(1안/2안)과 연구팀 산정 결과에 따라 달라짐, 7장 참조)

2안 적용 시 주의 케이스 — 유닛 자체 캡이 남아있어도 노출이 안 되는 경우가 발생할 수 있다.

예: 타겟팅 프리퀀시 기본값(Max) = 50, 랭크84 유닛의 독립 캡 = 10 (아직 0회 소진, 잔여 10 그대로)
→ 이 유저가 랭크1~83 사이 다른 유닛들을 통해 이미 누적 50회 노출을 받은 상태라면,
→ 랭크84 유닛은 자기 캡(10) 중 단 1회도 쓴 적이 없어도, 타겟팅 총 상한(Max=50)이 이미 소진되었으므로 노출 불가 → 패스백 (6.2 참조)

즉 2안에서는 "유닛 캡 > 0" 조건과 "타겟팅 누적 소진량 < Max" 조건을 모두 만족해야 노출이 발생한다 — 하위 랭크 유닛은 이론상 캡을 갖고 있어도, 상위 랭크 유닛들이 이미 타겟팅 총 상한을 다 써버리면 실질적으로 기회를 얻지 못할 수 있다.

06서빙 처리 로직

프리퀀시는 유닛을 "선택"하는 로직이 아니라, 이미 확정된 유닛에 대해 노출 가능 여부만 판단하는 게이트(Gate)로 동작한다.

6.1 처리 흐름

지면등급 확정노출 요청 발생 시, 기존 서빙/입찰 로직으로 지면 낙찰 → 지면등급 조회

타겟팅등급 확정유저 쿠키(세그먼트) 매칭 결과에 따른 타겟팅등급 조회

시간등급 확정현재 시각 기준 시간등급 조회

송출 시 조회 순서는 지면등급 → 타겟팅등급 → 시간등급 순으로 이루어진다 (동시 판단이 아닌 순차 조회).

유닛 확정확정된 타겟팅 × 지면등급 × 시간등급 조합 → 해당 타겟팅 유닛 중 1개 확정

프리퀀시 잔여량 확인확정된 유닛의 유저별 프리퀀시 잔여량을 실시간으로 DB 조회하여 노출 가능 여부를 판단 (2안 채택 시, 타겟팅 총 소진량(Max 대비)도 함께 조회)

유닛 잔여량 > 0 (2안: 타겟팅 총 소진량 < Max 조건 추가) → 노출 허용, 유닛 잔여량 −1 차감

유닛 잔여량 = 0 (2안: 또는 타겟팅 총 소진량 = Max) → 노출 불가 → 패스백(Passback), 대체 유닛 선택 로직 없음

프리퀀시 판단은 실시간 DB 조회 방식으로 이루어지며, 지면·타겟팅·시간등급을 모두 조회한 후행 작업으로 발생한다. 기존(3.1) 광고주 단위 제어는 이 조회들보다 앞단에서 이루어졌던 것과 대비된다 (7장 성능 리스크 참조).

6.2 패스백 처리

프리퀀시 소진 시 패스백 처리
(2안 채택 시) 해당 유닛의 잔여량이 남아있더라도, 타겟팅 단위 총 상한(Max)이 이미 소진된 상태라면 노출을 허용하지 않고 패스백 처리한다

6.3 리셋

유저별 유닛 프리퀀시 잔여량은 일 단위(자정 기준)로 초기화

07남은 확인 / 보완 필요 사항

연구팀

1안/2안 결정 및 배분 함수: 5.3의 분배형(1안) vs 차등 제한형(2안) 중 채택 방향 결정 필요. 어느 안이든 랭크 1(최상) → 84(최하)로 갈수록 프리퀀시 값이 어떤 형태로 감소해야 하는지(선형/지수/구간별 계단식 등) 산정 필요
기준 데이터: 타겟팅 유닛(지면등급×시간등급 조합) 각각의 실제 노출·전환 성과 데이터 확보 방안 — 특히 하위 랭크 유닛은 트래픽 표본이 적어 유의미한 산출이 가능한지 검증 필요
타겟팅별 최소값·최대값: 유닛별 최소 1회 이상의 프리퀀시 확보를 전제로, 타겟팅별 프리퀀시 최소값·최대값 정책을 연구팀과 논의하여 정할 예정

송출팀

성능 리스크 (송출팀 제기) — 유닛 단위 프리퀀시 도입 시, 기존에 지면/타겟팅/시간 조회보다 앞단에서 이루어지던 광고주 단위 체크가 이 조회들을 모두 마친 후행 작업으로 이동한다. 유저 × 광고그룹 × 타겟팅 유닛(84) 조합으로 조회 대상이 늘어나며, 스마트 유닛 관리 자체보다 큰 부하가 예상되고 모비온 서버 장애 가능성까지 제기됨.

실시간 DB 조회 기반 프리퀀시 판단 방식의 기술적 구현 가능 여부 확인 필요 (유닛 프리퀀시 잔여량 실시간 트래킹 인프라 구축 방안 포함 — 개발 리소스/일정)

개발 · 내부 검토

총량이 광고주 기준 공유 풀이므로, 같은 광고주 산하 여러 광고그룹이 동시에 같은 카운터를 차감하는 동시성 제어(concurrency control) 설계 필요
유닛 · 광고그룹 ON/OFF 시 캐시된 프리퀀시 잔여량/상태 처리 방안 (무효화 시점, 재생성 방식) 검토 필요
프리퀀시 최소값·최대값 수정 기능은 1차 개발 범위에서는 제공하지 않으나, 향후 해당 기능을 지원할 가능성을 염두에 두고 개발 필요

현재 모비온 송출 로직 — 프리퀀시

근거 코드: mobon-platform 저장소 (매체플랫폼-RTB) — com.mobon.utils.ImpressionLimitTracker / com.adgather.user.inclinations.cookieval.freq.ctr.*

한눈에 보는 비교표

구분	상세	코드명	체크 범위	한도 저장소	한도값은 누가 정하나	실행 시점	초과 시 동작	비고
프리퀀시①	광고주 단위 노출한도	ImpressionLimitTracker .isExhausted() / .consume()	광고주 전체 (분단위)	Ehcache(조회, 서버 로컬) + Redis(차감, 공유)	배치가 최근 7일 평균 노출수 기반 자동 계산 (ImpressionLimitBatch)	selAdinfo 필터체인의 가장 첫 줄	해당 광고주 전체 후보를 즉시 탈락(return null)	유저 쿠키가 아닌 서버(Redis) 기준 — 유저와 무관하게 광고주 전체에 걸리는 "상위 셔터". 리워드 지면에만 적용, 한도는 통계로 매일 자동 재계산
프리퀀시②-1	캠페인(사이트코드)별 클릭 한도	FreqSiteCodeClickCtr .isOver()	캠페인 단위	유저 쿠키	프로퍼티(고정값)	selAdinfo 통과 후, 바깥 루프 1번째	이 후보만 탈락(continue), 다음 후보로	같은 유저가 같은 캠페인을 이미 여러 번 클릭했는지만 봄. 다른 캠페인(같은 광고주라도)엔 영향 없음, 범위가 가장 좁음
프리퀀시②-2	광고주 클릭 한도	FreqAdverClickCtr .isOver()	광고주 단위 (클릭)	유저 쿠키	프로퍼티(고정값)	바깥 루프 2번째	이 후보만 탈락(continue)	같은 광고주의 여러 캠페인을 합산해서 클릭 수를 셈. ②-1보다 범위가 넓음(캠페인 → 광고주)
프리퀀시②-3	광고주 노출 한도	FreqAdverViewCtr .isOver() / .count()	광고주 단위 (노출)	유저 쿠키	프로퍼티(고정값)	바깥 루프 3번째	이 후보만 탈락(continue)	②-2와 대상 범위(광고주)는 같지만 클릭이 아니라 노출 횟수를 셈. 클릭 안 해도 자꾸 보이기만 해도 걸릴 수 있음
프리퀀시②-4	타겟팅 구분별 노출한도	FreqDefaultCtr.count() (= FreqShopsCtr.count() 류)	타겟팅 구분 단위 (AD/TC/UM 등)	유저 쿠키	프로퍼티 (TC_FREQUENCY, WC_FREQUENCY 등 구분별 개별 설정, 기본 15~150)	바깥 루프 4번째 (가장 나중)	종료태그 처리 + 쿠키 삭제, 이후 그 타겟팅 재노출 안됨	범위가 가장 넓음(광고주 무관, 타겟팅 종류 자체). ②-1~3을 다 통과한 후보만 여기까지 옴, 유일하게 "초과 시 쿠키 삭제"까지 하는 항목

핵심 차이 3가지

1. 저장소가 다르다 — Redis+로컬캐시 vs 쿠키

	프리퀀시①	프리퀀시②(1~4 전체)
저장 위치	서버 측 (Redis + Ehcache)	유저 브라우저 쿠키
유저가 쿠키를 지우면?	영향 없음 (서버가 카운트를 들고 있음)	카운트가 리셋됨
여러 서버 인스턴스 간 공유	Redis로 공유됨 (조회는 로컬이라 약간의 오차 허용)	공유 개념 없음 (유저별 쿠키라 애초에 유저 단위)

2. 한도값을 누가 정하냐가 다르다 — 배치 계산 vs 고정 프로퍼티

	프리퀀시①	프리퀀시②-4 (타겟팅 구분별)
한도 산정 방식	배치가 최근 7일 평균 노출수 + 수동설정값을 조합해 자동 계산 (ImpressionLimitResolver.resolveCap)	운영자가 프로퍼티에 직접 값 입력 (TC_FREQUENCY=15, WC_FREQUENCY=50 등)
변경 방법	배치가 매번 재계산 (통계 기반, 동적)	프로퍼티 값을 직접 수정해야 변경됨 (정적)

3. 체크 시점이 정반대다 — 맨 먼저 vs 맨 나중

selAdinfo() 필터체인 시작 └─ [맨 처음] 프리퀀시① — 광고주 전체를 미리 걷어냄 └─ (중복클릭, 간편유닛, 스마트유닛, 성별, 나이, 타겟팅선별, 디바이스 ... 등 나머지 필터) 필터체인 통과 → 바깥 루프 └─ [1번째] 프리퀀시②-1 (캠페인 클릭) └─ [2번째] 프리퀀시②-2 (광고주 클릭) └─ [3번째] 프리퀀시②-3 (광고주 노출) └─ [맨 나중] 프리퀀시②-4 (타겟팅 구분별) — 모든 필터를 다 통과한 후보에만 적용

한 줄 정리

프리퀀시① = "이 광고주, 지금 이 순간(1분) 너무 많이 나가고 있어서 일단 다 멈춰!" 라는 전체 셔터 역할
프리퀀시② = "이 유저한테 이 캠페인/이 광고주/이 타겟팅이 이미 충분히 보여줬으니 그만 보여줘" 라는 유저별 맞춤 제한 역할

①은 "광고주를 보호/제어하기 위한 서버 차원의 상한선", ②는 "한 유저에게 같은 광고가 지겹도록 나가지 않게 하는 유저 경험 관점의 제한"으로 이해하면 된다.

01개요

02배경 및 목적

03기존(3.1) vs 신규 방식

3.1 기존 방식

3.2 신규 방식 (스마트 유닛 관리)

04타겟팅별 프리퀀시 기본값 (3.1 기준 · 순위는 CPC 자동화 타겟팅 목록 순서)

05타겟팅 유닛 랭크 및 차등 배분 원칙

5.1 유닛 구성

5.2 타겟팅 유닛 서열

5.3 차등 배분 원칙 (1안 / 2안 — 결정 전, 병렬 검토)

1안분배형

2안차등 제한형 (독립 캡)

06서빙 처리 로직

6.1 처리 흐름

6.2 패스백 처리

6.3 리셋

07남은 확인 / 보완 필요 사항

프리퀀시 로직 플로우

현재 모비온 송출 로직 — 프리퀀시

한눈에 보는 비교표

핵심 차이 3가지

한 줄 정리