SKAN 4는 조건에 따라 최대 세 창의 포스트백을 반환하며, fine 값은 첫 창에서만 받을 수 있습니다. 그 값이 컨버전 밸류예요. iOS 측정에서 실제로 손이 가장 많이 가는 작업이 이 좁은 칸에 뭘 담을지 정하는 일입니다.
64칸이 생각보다 작습니다
정밀한 fine 값은 6비트, 즉 0~63의 64칸입니다. 처음 설계할 때는 넉넉해 보여요.
그런데 담고 싶은 걸 나열해 보면 금방 모자랍니다. 가입 여부(2) × 튜토리얼 완료(2) × 첫 구매(2) × 구매 금액 5구간 = 벌써 40칸입니다. 여기에 리텐션 신호 하나만 더 붙이면 넘어갑니다.
더 중요한 문제는 칸 수가 아니라 칸당 볼륨입니다. 64칸으로 쪼개면 하루 설치 500건짜리 캠페인의 각 칸에는 평균 8건이 들어갑니다. 실제 분포는 균등하지 않고 누락도 있으므로, 이 평균만으로 사용 가능 여부를 판정할 수는 없습니다.
지금 스키마, 64칸을 제대로 쓰고 있나요?
설계 원칙 하나: 판단이 갈리는 지점만 나눈다
"이 값이 달라지면 내가 다른 행동을 하는가?"를 기준으로 칸을 나누세요.
구매 금액을 5구간으로 나눴는데 어차피 상위 2구간만 보고 입찰을 조정한다면, 나머지 3구간은 칸만 먹고 판단에는 안 쓰이는 겁니다. 합치세요.
읽을 수 있는 스키마가 모든 걸 담은 스키마를 이깁니다. 이게 SKAN 설계의 핵심입니다.
흔한 실수 넷
측정 창 밖의 행동을 담는 것. 첫 창은 0~2일입니다. 평균 구매 시점이 5일이라도 일부 구매는 첫 창에 들어올 수 있습니다. 2일 안에 발생한 구매 비중을 확인하세요. 스키마를 정하기 전에 실제 전환 지연 분포를 먼저 보세요.
매출을 그대로 넣으려는 것. 금액은 연속값이라 구간으로 인코딩해야 합니다. 구간을 촘촘히 잡을수록 칸이 모자라니 상위 몇 개만 의미 있게 나누세요.
설계를 자주 바꾸는 것. 매핑을 바꾸면 그 전후 데이터가 서로 다른 의미를 갖게 됩니다. 바꿔야 한다면 변경 시점을 기록하고 이전 기간과 섞지 마세요.
창 2·3에 세밀한 설계를 하는 것. 두 번째·세 번째 창은 low·medium·high 세 단계뿐입니다. 여기 LTV 10구간을 설계해봐야 세 칸으로 뭉개집니다.
매체가 이 값을 어떻게 쓰는지 확인하세요
이게 설계를 진지하게 해야 하는 진짜 이유입니다. 컨버전 밸류는 보고와 최적화에 활용될 수 있습니다. 어떤 값이 실제 목표에 반영되는지는 매체·MMP 설정을 확인해야 합니다.
잘못된 신호를 주면 매체는 그 신호를 열심히 최적화합니다. 예를 들어 튜토리얼 완료를 최상위 값으로 두면 알고리즘은 튜토리얼을 잘 끝내는 유저를 데려옵니다. 그게 돈을 쓰는 유저와 다르면 CPA는 좋아지고 매출은 안 늘어요.
오늘 해볼 것
매핑표를 꺼내 각 값의 실제 설치 볼륨을 세어 보세요. 빈 칸이 많으면 실제 행동 분포·누락·반환 조건을 확인하고 판단에 불필요한 구간 통합을 검토하세요.
최상위 값에 무엇을 뒀는지 확인하고, 그 행동을 한 유저의 D30 매출이 실제로 높은지 대조해 보세요. 안 높다면 알고리즘에게 잘못된 목표를 주고 있는 겁니다.
이 방법의 한계
컨버전 밸류로 계산한 ROAS는 절대값으로 다루지 마세요. 매출을 좁은 값에 인코딩한 근사치이고, 측정 창을 넘어선 매출은 아예 안 잡힙니다. 캠페인별 누락·구간·성숙도가 다르면 상대 순위도 왜곡될 수 있습니다.
그리고 값이 안 온다고 스키마부터 의심하지 마세요. 개인정보 임계 아래로 내려가면 스키마가 완벽해도 fine 값이 오지 않습니다. 창별 반환 규칙은 Apple 문서에서 확인하세요.
전환 순서 전체는 SKAN 4 전환 실무에서 다룹니다.