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