SKAN 4로 옮기는 작업에서 가장 흔한 실수는 순서입니다. 창 세 개를 한꺼번에 설계하고, 캠페인은 안드로이드에서 쓰던 구조 그대로 옮기는 거죠. 그러면 데이터가 오긴 오는데 절반이 비어 있습니다.
SKAN 전반과 ATT의 관계는 iOS ATT·SKAN 측정 가이드에서 다뤘습니다. 이 글은 전환 순서에만 집중합니다.
창 세 개는 역할이 다릅니다
SKAN 4는 설치 후 02일·37일·8~35일 세 구간에서 각각 포스트백을 줍니다. 그런데 세 창이 같은 정보를 주지 않아요.
| 창 | 받을 수 있는 값 | 쓰임 |
|---|---|---|
| 0~2일 | fine(0~63) 또는 coarse | 활성화 품질 — 가입·튜토리얼·첫 구매 |
| 3~7일 | coarse만 (low·medium·high) | 초기 재방문·습관화 |
| 8~35일 | coarse만 (low·medium·high) | 장기 가치 구간 — 가장 늦게 도착 |
여기서 바로 나오는 결론이 있습니다. 정밀한 설계는 첫 창에만 의미가 있습니다. 두 번째·세 번째 창에 세밀한 LTV 구간을 설계해봐야 세 칸으로 뭉개집니다.
순서 1 — 첫 창 스키마부터 확정
컨버전 밸류 설계는 첫 창에서 시작하세요. 이유는 되돌리기 비용입니다.
창 2·3은 세 단계뿐이라 나중에 붙여도 잃는 게 적습니다. 반면 첫 창 매핑을 바꾸면 그 전후 데이터가 서로 다른 의미를 갖게 되고, 추세 비교가 통째로 끊깁니다.
그래서 첫 창은 "작고 판단 가능한" 스키마로 먼저 내보내는 편이 낫습니다. 64칸을 다 쓰려 하지 마세요. 읽을 수 있는 스키마가 모든 걸 담은 스키마를 이깁니다.
한 가지 더. 첫 창은 0~2일입니다. 평균 구매 전환이 5일 뒤에 일어나는 서비스라면 그 신호는 여기 안 잡혀요. 스키마를 정하기 전에 실제 전환 지연 분포를 먼저 보세요.
순서 2 — 캠페인 구조를 iOS 기준으로 다시 짜기
이 단계를 건너뛰면 앞의 설계가 다 무의미해집니다.
개인정보 임계(crowd anonymity) 때문인데요. 설치 볼륨이 작으면 애플이 돌려주는 정보를 줄입니다. 티어가 낮으면 fine 값도, 세분화된 소스 ID도 안 와요.
여기서 SKAN 특유의 역설이 나옵니다. 다른 채널에서는 캠페인을 잘게 쪼갤수록 분석이 좋아지는데, SKAN에서는 쪼갤수록 각 조각의 볼륨이 줄어 데이터가 오히려 거칠어집니다.
안드로이드 구조를 그대로 옮기면 iOS 데이터만 통째로 뭉개지는 일이 실제로 벌어집니다. iOS는 의도적으로 합쳐 볼륨을 만드세요. 잃는 건 캠페인 단위 통제이고 얻는 건 측정 자체입니다.
순서 3 — 창 2·3은 필요해진 뒤에
세 창을 처음부터 다 설계할 이유가 없습니다. 첫 창이 안정적으로 읽히기 시작하면, 그때 "어떤 늦은 행동이 좋은 코호트와 나쁜 코호트를 가르는가"를 보고 붙이세요.
순서를 지키면 각 단계에서 무엇이 잘못됐는지가 분리돼 보입니다. 한꺼번에 켜면 값이 안 올 때 스키마 문제인지 임계 문제인지 구분이 안 돼요.
오늘 해볼 것
하나. 컨버전 밸류 매핑표를 꺼내 각 값의 실제 설치 볼륨을 세어 보세요. 거의 안 들어오는 칸이 절반을 넘으면 스키마가 너무 잘게 쪼개져 있는 겁니다.
둘. iOS 캠페인 수를 세고, 각 캠페인의 일 평균 설치를 확인하세요. 대부분이 한 자릿수라면 지금 임계 아래에서 돌고 있을 가능성이 큽니다. 합쳤을 때 fine 값이 돌아오는지 확인해 보세요.
정직하게
애플은 임계 기준값을 공개하지 않고 규칙도 버전마다 바뀝니다. 특정 숫자를 가정하고 설계하기보다, 구조를 바꾼 뒤 실제로 어떤 값이 오는지 확인하는 방식이 안전해요. 설계 전에 Apple의 SKAdNetwork 문서를 직접 확인하세요.
그리고 SKAN 5를 지금 준비할 필요는 없습니다. 업계 표준은 여전히 SKAN 4이고 애플의 후속 방향은 AdAttributionKit입니다. 버전 대응보다 창별 스키마와 캠페인 구조를 정리해 두는 편이 어느 쪽으로 가든 그대로 쓰입니다.