포스트백 구조를 먼저 “운영 관점”으로 재정의하기
SKAN 4.0의 가장 큰 변화는 1회 포스트백이 아니라, 설치 이후 서로 다른 기간에 대해 최대 3개의 포스트백을 받을 수 있다는 점입니다. 일반적으로 Window 1(0–2일), Window 2(3–7일), Window 3(8–35일)로 나뉘며, 각 윈도우별로 별도 포스트백이 생성됩니다.
다만 “항상 3개가 온다”는 기대는 위험합니다. 애플의 crowd anonymity(프라이버시) 기준에 따라 포스트백이 포함하는 필드가 제한되거나(예: CV가 비어 있거나), 일부 포스트백 자체가 축소될 수 있다는 전제를 운영 설계에 넣어야 합니다.
포스트백에 담길 수 있는 신호의 현실
Window 1 포스트백만 fine conversion value(0–63)를 받을 수 있고, 추가 포스트백은 coarse conversion value 중심으로 설계하는 것이 기본입니다.
coarse conversion value는 low/medium/high(그리고 none) 같은 큰 버킷으로 제공되며, 집단 크기(프라이버시 티어)가 충분하지 않을 때 fine 대신 coarse(또는 null/none)가 오는 구조를 염두에 둬야 합니다.
또한 포스트백은 즉시 도착하지 않고, 윈도우 종료 이후 랜덤 지연이 붙습니다. 예를 들어 한 가이드에서는 “윈도우가 닫힌 뒤 24시간 이후 랜덤 타이머가 시작”된다고 설명합니다.
빠른 신호가 필요하면 lockWindow를 활용해 “윈도우 종료 전 송신”을 요청할 수 있는데, 애플 API 자체가 lockWindow로 조기 송신을 지정하도록 제공됩니다.
소스 식별자(캠페인 대체 필드) 설계 체크
SKAN 4에서는 기존 campaign-id 대신 hierarchical source identifier(= source identifier)가 도입되고, 프라이버시 티어에 따라 2·3·4자리 중 일부만 포스트백에 포함될 수 있습니다.
따라서 운영 팁은 단순합니다. “2자리만 와도 의사결정이 가능한 최소 설계”를 먼저 만들고, 3~4자리는 여유가 있을 때 지역/크리에이티브/플레이스먼트 같은 추가 차원을 얹는 방식이 안전합니다(2자리만 오는 날에도 리포트가 깨지지 않게).
코호트(윈도우) 설계: 리포팅 단위를 바꿔라
SKAN 4.0에서는 코호트를 “설치일 기준 + 윈도우 기준”으로 고정하는 편이 분석이 깔끔합니다. 즉 D0–2(초기 활성/온보딩), D3–7(가입 완료·트라이얼 전환·초기 결제), D8–35(지연 결제·고가치 전환)처럼 윈도우별로 ‘측정 가능한 행동’을 미리 합의합니다.
이때 반드시 포함해야 하는 운영 규칙은 2가지입니다. (1) 윈도우별 포스트백 도착 지연(랜덤 딜레이)을 감안해 “리포트 컷오프(예: install week + N일)”를 고정한다. (2) CV 또는 source identifier 일부가 마스킹(null/none/자리수 축소)되더라도 블렌디드 KPI(총매출/총가입/총구매)와 함께 봐서, 신호 손실이 곧 성과 하락으로 오인되지 않게 한다.
CV 설계 체크리스트: “Window 1은 촘촘히, Window 2·3은 크게”
의사결정부터 고정
CV는 데이터 수집용이 아니라 최적화/예산결정용입니다. Window 1의 fine CV는 ‘초기 가치 예측’을 위해 설계하고, Window 2·3의 coarse CV는 ‘중요한 딥퍼널 이벤트가 발생했는지’를 크게 나누는 것이 실전에서 강합니다.
Window 1: fine(0–63) 설계 원칙
초기 48시간 안에 의미 있는 분기를 만드는 이벤트만 넣습니다(예: 튜토리얼 완료, 회원가입, 결제수단 등록, 첫 결제/트라이얼 시작 등). 또한 SKAN 4에서는 conversion value가 과거처럼 “증가만 가능”에 고정되지 않고 증가/감소가 가능하다는 설명도 있어, 상태머신처럼 더 유연한 인코딩이 가능합니다(단, 윈도우 제약은 여전히 존재).
Window 1의 coarse(저·중·고)도 같이 설계
현실적으로 Window 1에서도 fine 대신 coarse가 올 수 있으므로, fine의 구간을 coarse의 3단계와 정합되게 맞추는 것이 중요합니다(예: fine 1–10=low, 11–30=medium, 31+=high처럼). 실제로 “postback 1의 fine/coarse를 정렬하라”는 실무 권고도 있습니다.
Window 2·3: coarse는 ‘하나의 질문’에 답하게
Window 2(3–7일)는 “활성 유저인가/가치 유저인가”를, Window 3(8–35일)는 “지연 결제/고가치 전환이 있었나” 같은 단일 목적에 맞춰 low/medium/high 정의를 단순화합니다. 어차피 이 구간은 coarse 중심으로 오기 때문에, 복잡한 이벤트 매핑을 넣을수록 해석이 흔들립니다.
마스킹 대응: null/none을 ‘실패’로 기록하지 말 것
CV가 비어 있거나 coarse가 none으로 오는 케이스는 성과가 없어서가 아니라 프라이버시 티어 때문에 데이터가 제한된 결과일 수 있습니다. 리포트에서 null/none 비중을 별도 모니터링하고(신호 품질 지표), 성과 해석은 블렌디드 KPI와 함께 보정하는 습관이 필요합니다.
카테고리 없음