SKAN 4 전환 실무: 창 3개를 어떤 순서로 켜나

SKAN 4로 옮기는 작업에서 가장 흔한 실수는 순서입니다. 창 세 개를 한꺼번에 설계하고, 캠페인은 안드로이드에서 쓰던 구조 그대로 옮기는 거죠. 그러면 데이터가 오긴 오는데 절반이 비어 있습니다.

SKAN 전반과 ATT의 관계는 iOS ATT·SKAN 측정 가이드에서 다뤘습니다. 이 글은 전환 순서에만 집중합니다.

창 세 개는 역할이 다릅니다

SKAN 4는 설치 후 02일·37일·8~35일 세 구간에서 조건에 따라 최대 세 포스트백을 줍니다. 그런데 세 창이 같은 정보를 주지 않아요.

여기서 바로 나오는 결론이 있습니다. 정밀한 설계는 첫 창에만 의미가 있습니다. 두 번째·세 번째 창에 세밀한 LTV 구간을 설계해봐야 세 칸으로 뭉개집니다.

순서 1 — 첫 창 스키마부터 확정

컨버전 밸류 설계는 첫 창에서 시작하세요. 이유는 되돌리기 비용입니다.

창 2·3이 세 단계라고 정보 가치가 작은 것은 아닙니다. 구매·구독이 늦게 발생한다면 초기 설계에 포함하세요. 반면 첫 창 매핑을 바꾸면 그 전후 데이터가 서로 다른 의미를 갖게 되고, 추세 비교가 통째로 끊깁니다.

그래서 첫 창은 "작고 판단 가능한" 스키마로 먼저 내보내는 편이 낫습니다. 64칸을 다 쓰려 하지 마세요. 읽을 수 있는 스키마가 모든 걸 담은 스키마를 이깁니다.

한 가지 더. 첫 창은 0~2일입니다. 평균 구매 시점이 5일이어도 일부 구매는 첫 창에 들어올 수 있으니 2일 안에 발생한 구매 비중을 확인하세요. 스키마를 정하기 전에 실제 전환 지연 분포를 먼저 보세요.

순서 2 — 캠페인 구조를 iOS 기준으로 다시 짜기

이 단계를 건너뛰면 앞의 설계가 다 무의미해집니다.

개인정보 임계(crowd anonymity) 때문인데요. 설치 볼륨이 작으면 애플이 돌려주는 정보를 줄입니다. 티어가 낮으면 fine 값도, 세분화된 소스 ID도 안 와요.

여기서 SKAN 특유의 역설이 나옵니다. 다른 채널에서는 캠페인을 잘게 쪼갤수록 분석이 좋아지는데, SKAN에서는 쪼갤수록 각 조각의 볼륨이 줄어 데이터가 오히려 거칠어집니다.

안드로이드 구조를 그대로 옮기면 iOS 데이터만 통째로 뭉개지는 일이 실제로 벌어집니다. iOS는 의도적으로 합쳐 볼륨을 만드세요. 잃는 건 캠페인 단위 통제이고 얻는 건 측정 자체입니다.

순서 3 — 창 2·3은 필요해진 뒤에

늦은 행동이 핵심이면 세 창을 처음부터 설계하세요. 초기 활성화만 먼저 검증하는 작업이라면 첫 창부터 단계적으로 적용할 수 있습니다. 데이터 가치와 구현 부담으로 순서를 정하세요.

순서를 지키면 각 단계에서 무엇이 잘못됐는지가 분리돼 보입니다. 한꺼번에 켜면 값이 안 올 때 스키마 문제인지 임계 문제인지 구분이 안 돼요.

오늘 해볼 것

1. 컨버전 밸류 매핑표를 꺼내 각 값의 실제 설치 볼륨을 세어 보세요. 빈 칸이 많으면 실제 행동 분포·누락·반환 조건을 확인하고 판단에 불필요한 구간 통합을 검토하세요.

2. iOS 캠페인 수를 세고, 각 캠페인의 일 평균 설치를 확인하세요. 설치 수만으로 공개되지 않은 임계값을 판정하지 마세요. 실제 반환 정보량과 운영 통제의 손실을 비교해 통합을 검토하세요.

이 방법의 한계

애플은 임계 기준값을 공개하지 않고 규칙도 버전마다 바뀝니다. 특정 숫자를 가정하고 설계하기보다, 구조를 바꾼 뒤 실제로 어떤 값이 오는지 확인하는 방식이 안전해요. 설계 전에 Apple의 SKAdNetwork 문서를 직접 확인하세요.

지원 버전과 일정은 매체·MMP 공지로 확인하세요. Apple은 SKAN·AdAttributionKit 상호 운용을 지원하며, 기존 스키마가 변경 없이 적용된다고 가정하지 말고 실제 API·반환 조건을 검증하세요.