Signal Engineering이란 무엇이고, ATT 이후 무엇을 고치는가

아마 이런 이유로 이 페이지에 오셨을 겁니다

이 중 어느 것도 미디어 바잉의 문제가 아닙니다. 모두 시그널의 문제이고, 대부분은 고칠 수 있습니다.

• Meta는 하나의 ROAS를 보고하고, RevenueCat은 그 절반을 보고하며, 재무팀은 둘 다 믿지 않는다. 둘은 결코 일치하지 않으며, 팀 안에서 그 이유를 설명할 수 있는 사람이 없다.
• 대부분의 캠페인에서 SKAN 전환 밸류가 비어서 돌아오는데 왜 그런지 아무도 모른다.
• Meta는 문제없이 스케일된다. 같은 크리에이티브인데 Google과 TikTok은 정체된다.
• 가치 최적화로 전환했더니 오히려 나빠졌다.
• 트라이얼 시작은 저렴한데 유료 전환이 전혀 따라오지 않는다.
• 앱 안에 SDK가 세 개 들어 있다. 어느 것이 전환 밸류를 소유하는지 아무도 말하지 못한다.

Signal Engineering이 고치는 것

제가 구축하는 순서대로 다섯 개의 레이어입니다.

• 이벤트 레이어. 고객님의 앱을 위한 하나의 정규 이벤트 체계를 만들어, Meta 표준 이벤트, Google 전환 이벤트, TikTok 이벤트, 그리고 고객님의 MMP에 명시적으로 매핑합니다. 트라이얼 시작, 첫 결제, 갱신, 해지, 환불. 각각에 밸류, 통화, ID를 부여합니다.
• 서버사이드 전송. 앱 이벤트를 위한 Meta의 Conversions API, TikTok의 Events API, Google의 앱 전환 설정을 고객님의 MMP나 Firebase를 통해 구독 백엔드와 연결해, 앱이 꺼져 있어도 갱신과 환불, 트라이얼 전환이 플랫폼에 도달하도록 만듭니다. 이벤트 ID로 중복을 제거해 두 번 집계되지 않습니다.
• iOS 전환 밸류 스키마. Apple이 돌려보내도록 허용하는 이 작은 값은, 트래킹을 거부한 유저에 대해 얻을 수 있는 유일한 설치 후 시그널입니다. 저는 이를 고객님의 퍼널과 볼륨에 맞춰 설계해서, 캠페인이 아무것도 반환받지 못하는 대신 Apple의 프라이버시 임계값을 통과하도록 만듭니다. 이 값의 소유권은 하나의 SDK에만 둡니다. 두 개의 SDK가 이 값을 쓰면 마지막 호출이 이기게 되는데, 지금은 대개 그게 실수로 벌어집니다.
• 입찰을 위한 밸류 시그널. 구매 밸류, 마진, 혹은 예측 LTV를 Meta를 포함한 모든 플랫폼에 보냅니다. 다만 그 값이 유저가 실제로 지불하는 금액과 상관관계가 있는지 확인한 뒤에만 그렇게 합니다. 잘못된 값은 알고리즘에게 엉뚱한 유저를 더 빠르게 사들이도록 가르치는 셈입니다.
• 대조 뷰. 플랫폼, MMP, RevenueCat, 스토어 지급액을 매달 하나의 표로 비교하고, 예상되는 차이를 미리 적어둡니다. 다음에 수치가 어긋날 때, 그것이 구조적인 차이인지 버그인지 5분 안에 판단할 수 있게 하기 위해서입니다.

ATT 이후 고칠 수 없는 것, 그리고 제가 이를 밝히는 이유

iOS 14.5 이후, App Tracking Transparency를 거부한 유저는 유저 단위로 어트리뷰션할 수 없습니다. Apple의 SKAdNetwork와 AdAttributionKit은 디바이스 식별자 없이 지연된 집계 포스트백만 반환하며, 볼륨이 낮은 캠페인에 대해서는 의도적으로 세부 정보를 감춥니다. 어떤 Conversions API 연동도, 어떤 MMP 기능도, 어떤 어트리뷰션 복구 툴도 이를 바꾸지 못합니다. Meta는 그런 이벤트를 Aggregated Event Measurement를 통해 처리하고, Google과 TikTok은 모델링으로 대체합니다.

그래서 저는 확정적인 어트리뷰션을 약속하지 않습니다. 제가 약속하는 것은, 고객님이 통제할 수 있는 시그널이 정확하다는 것, 플랫폼이 최적화를 위해 얻을 수 있는 최선의 입력값을 받는다는 것, 그리고 어떤 차이가 정상적인 것인지 알게 된다는 것입니다. 이 작업이 끝난 뒤에도 플랫폼 ROAS와 구독 매출은 여전히 일치하지 않을 것입니다. 다만 그 이유는 설명할 수 있는 것이 됩니다. 다른 벤더가 다르게 말한다면, 그 유저 ID가 어디서 오는지 물어보십시오.

iOS에서는 어떤 시스템이 무엇을 보고하는가

같은 iOS 캠페인의 설치와 전환을 다섯 개의 시스템이 각각 집계하며, 수치가 서로 다르다고 해서 어느 하나가 반드시 틀린 것은 아닙니다. 집계하는 대상도, 윈도우도, 지연도 다르기 때문입니다. 아래 표는 각 벤더의 공식 문서를 바탕으로 정리했고, 2026년 9월 29일에 확인했습니다.

Google의 iOS 수치를 맞추려면 고객님 쪽의 작업이 필요합니다. Integrated Conversion Measurement에 대해 Google이 제시하는 조건은 설치용 iOS 앱 캠페인이 활성 상태일 것, MMP의 first_open과 설치 후 이벤트를 Google Ads로 가져올 것, 이벤트 데이터를 활용한 기기 내 측정을 사용할 것, 그리고 최신 MMP SDK를 쓸 것입니다. 이벤트 데이터를 활용한 기기 내 측정에는 iOS 12 이상, 11.14.0 버전 이상의 Google Analytics for Firebase SDK, Google Ads에 연결된 애널리틱스 속성이 필요하며, Google은 EEA, 영국, 스위스 사용자에게는 이 기능이 비활성화된다고 밝히고 있습니다. 따라서 Google Ads, MMP, SKAN의 수치는 구조적으로 서로 다를 수밖에 없고, Google의 자체 안내도 ICM을 구현했다면 ICM 뷰를, 아니라면 Google Ads나 SKAN을 보라고 합니다. 연동 경로별 ICM 설정과 제가 Google Ads, MMP, SKAN을 대조하는 방법은 각각 별도의 글로 정리되어 있습니다.

정의와 무관한 차이도 있습니다. 제가 운영했던 한 Google 계정에서는 밸류가 없는 전환일 때 매출 이벤트가 0달러 대신 1달러를 보내고 있었고, 그 때문에 Google이 보고하는 ROAS가 전반적으로, 특히 iOS에서 크게 부풀려졌습니다. 제 입찰 전략 테스트의 바탕이 된 계정이며, 대조 뷰는 바로 이런 버그를 잡아내기 위해 존재합니다.

iOS의 Meta 캠페인에서 SKAN 4와 AdAttributionKit은 어떻게 작동하는가

무엇이 돌아올지는 Apple이 정합니다. 이긴 광고 하나당 최대 세 번의 지연된 포스트백이 오고, 각각에는 고객님의 앱이 기기에서 기록한 전환 밸류가 붙으며, 캠페인이 작을수록 세부 정보는 줄어듭니다. Meta는 iOS 앱 홍보 광고 세트마다 최적화 이벤트가 어느 쪽 대상인지에 따라 이 SKAdNetwork 어트리뷰션이나 Meta 자체의 Aggregated Event Measurement 중 하나를 사용합니다.

SKAN 4와 AdAttributionKit은 둘 다 세 개의 포스트백 윈도우를 반환하며, 세밀한 값을 실을 수 있는 것은 첫 번째뿐입니다. 캠페인 규모가 너무 작아 유저 집단을 보호할 수 없을 때는 Apple이 대략적인 값 혹은 값 없음으로 낮춰버립니다. 7일짜리 트라이얼의 첫 결제는 7일차나 8일차, 즉 두 번째나 세 번째 윈도우에 며칠 늦게 대략적인 값으로 들어옵니다. 그래서 이 스키마는 템플릿을 그대로 베끼는 대신 고객님의 퍼널과 볼륨에 맞춰 설계해야 하고, 지역과 크리에이티브 분할이 너무 많으면 모든 캠페인이 한꺼번에 임계값 아래로 떨어지는 것도 같은 이유입니다. 트라이얼 기간별로 어느 윈도우에 들어가는지, 누가 값을 기록하는지는 SKAN이 무료 트라이얼 이후의 결제를 측정할 수 있는지에 정리되어 있습니다.

Meta의 CAPI와 이벤트 매핑은 누가 고칠 수 있는가

앱 SDK와 MMP에서 구독 백엔드와 Events Manager까지, 이벤트 경로 전체를 책임지는 사람입니다. Meta의 시그널 버그는 대부분 이 중 두 곳이 만나는 지점에 있기 때문입니다. 리테이너에서는 그 사람이 저이며, SDK와 서버 작업에는 제 네트워크의 어트리뷰션 엔지니어가 함께하고, 고객님 쪽에는 변경 사항을 배포할 수 있는 개발자 한 명이 있으면 됩니다.

앱 이벤트를 위한 Conversions API는 SDK나 MMP가 디바이스에서 보내는 것과 같은 이벤트를 고객님의 서버에서 보내고, Meta는 이를 이벤트 ID로 중복 제거합니다. 이 API의 역할은 완전성과 밸류를 채우는 것입니다. 앱이 꺼져 있을 때 발생하는 갱신, 환불, 전환을 각각 밸류와 통화와 함께 보냅니다. 다만 트래킹을 거부한 유저의 어트리뷰션을 되살리지는 못하며, 그런 이벤트는 여전히 Aggregated Event Measurement를 거칩니다. 할 가치는 있지만, 우회책은 아닙니다. 이벤트가 Meta에 도착했는데도 AEM 대상이 아니라고 표시될 때 경로별로 확인할 내용은 트라이얼과 구매 이벤트가 Meta AEM 대상이 되지 않는 이유에 정리되어 있습니다.

pLTV와 가치 최적화

모델은 처음 하루 이틀의 행동으로 각 신규 유저의 밸류를 예측합니다. 이 값은 구매 밸류로 플랫폼에 전달되거나, iOS에서는 전환 밸류로 압축되어 전달됩니다. 그러면 플랫폼은 고밸류 예측과 비슷해 보이는 유저에게 입찰합니다. 어떤 이벤트와 어떤 입찰 방식이 어떤 앱에 맞는지는 Meta에 쓴 120만 달러의 지출을 바탕으로 정리했습니다.

Videa에서 이 레이어, 즉 맞춤 CAPI 구매 시그널과 입찰 속 예측 LTV가 D0 ROAS를 20%에서 주간 최고 43%로 끌어올린 바로 그것입니다. 60만 6천 달러짜리 테스트는 데이제로 밸류가 구매당 비용보다 D28 ROAS를 더 잘 예측한다는 것을 결론지었습니다.

어떤 이벤트에 최적화해야 하는가

계정을 더 깊은 이벤트로 옮기기 전에 제가 순서대로 확인하는 세 가지 질문입니다. 설치부터 시작하는 이벤트 단계 전체는 구독 앱은 어떤 이벤트에 최적화해야 하는가에 정리해두었습니다.

1. 고객님의 볼륨에서 유료 이벤트가 플랫폼의 학습 임계값을 넘나요? Meta의 기준은 마지막 주요 수정 이후 일주일 동안 광고 세트당 약 50건의 결과입니다. 넘지 못한다면 트라이얼 시작에 활성화 이벤트를 더해 최적화하십시오. 넘는다면 2번 질문으로 넘어가십시오.
2. 트라이얼 대비 유료 전환이 건강한가요? 그렇지 않다면 트라이얼 시작에 활성화 이벤트를 더한 상태를 유지하십시오. 옮기기 전에 두 조건이 모두 충족되어야 합니다. 건강하다면 구매로 옮기고 3번 질문으로 넘어가십시오.
3. 보내려는 값이 유저가 실제로 지불하는 금액과 상관관계가 있나요? 없다면 구매에 머무르십시오. 있다면 값을 보내십시오. 예측 LTV에는 세 가지가 더 필요합니다. 예측이 실제로 성숙한 코호트를 기준으로 보정되어 있어야 하고, 볼륨이 충분해야 하며, 어트리뷰션 윈도우가 닫히기 전에 플랫폼이 그 값을 받아야 합니다. 너무 일찍 켜면 엉뚱한 유저를 아주 확신에 차서 최적화하게 됩니다.

국가를 넘나들며 플랫폼 ROAS와 구독 매출을 대조하기

플랫폼은 어트리뷰션되거나 모델링된 전환을, 자체 윈도우 안에서, 총액 기준으로, 클릭 날짜에 맞춰 집계합니다. RevenueCat은 거래일 기준으로 환불을 제외하고 하나의 통화로 영수증을 집계합니다. 스토어 지급액은 수수료와 현지 세금을 제외하고 회계 일정에 따라 들어옵니다. 이것들은 구조적인 차이이고 예상된 것입니다. 한 달에서 다음 달로 넘어가며 차이의 크기가 달라진다면, 대개 그 뒤에 버그가 있습니다. 중복된 구매 이벤트, 통화 불일치, 한쪽 플랫폼에만 도달한 값 같은 것들입니다.

여러 국가에 걸친 ROAS에는 코호트 성숙도까지 더해집니다. 연간 결제가 많은 국가는 월간 결제 중심의 국가보다 7일차에는 더 나빠 보이고 90일차에는 더 좋아 보입니다. 그래서 저는 어느 국가에 예산을 배정할지 정하기 전에, 같은 경과일, 하나의 통화, 수수료 제외 기준으로 코호트를 비교합니다. 38만 3천 달러짜리 감사는 실제 계정에서 그것이 어떻게 보이는지 보여주며, ROAS가 의미를 가지려면 몇 건의 구매가 필요한지가 각 구간의 하한선을 정합니다.

이 작업이 진행되는 방식

Signal Engineering은 리테이너의 일부이며, 가장 먼저 진행됩니다. 진단은 Growth Audit에서 시작됩니다. 각 플랫폼이 현재 무엇을 받고 있는지, 무엇을 향해 최적화하고 있는지, 그리고 예상되는 편차를 적어둔 네 갈래 비교입니다. 진단 이후 일부 팀은 우선순위가 매겨진 목록을 바탕으로 직접 수정을 구현하며, 각 항목에는 엔지니어링 공수가 함께 추정되어 있습니다. 계정 운영을 저에게 맡기시는 경우도 있습니다. 둘 다 괜찮습니다.

SDK 작업과 고객님의 서버에서 돌아가는 모든 것에는 제 네트워크의 어트리뷰션 엔지니어를 데려옵니다. 레이어의 설계와 소유권은 제가 갖고, 엔지니어링 실무는 전문가의 손에 맡깁니다. 계약 기간 중 변경 사항을 배포할 수 있는 개발자 한 명, 그리고 Events Manager, MMP, RevenueCat 혹은 구독 백엔드, 광고 계정에 대한 읽기 권한이 필요합니다.

아직 리테이너 단계가 아니고 참여 없이 진단만 원하신다면, 유료 90분 세션에서 고객님의 세팅과 무엇을 어떤 순서로 고쳐야 할지를 다룹니다. 예약은 인트로 콜과 같은 캘린더를 통해 하시면 됩니다.

자주 묻는 질문