월 2,000만 원을 메타·구글 앱 설치 캠페인에 쏟아붓고 있는데, 어트리뷰션 대시보드에 잡히는 설치 건수가 실제 앱스토어 다운로드의 절반도 안 되는 상황. 이 괴리를 처음 마주한 마케터라면 "픽셀이 깨졌나?", "SDK 버전 문제인가?" 를 먼저 의심합니다.
하지만 2026년 현재 원인은 더 구조적입니다. iOS의 ATT(앱 추적 투명성) 정책과 안드로이드 프라이버시 샌드박스의 본격 상용화로 기기 식별자 자체가 광고 매체사에 전달되지 않기 때문입니다. 픽셀이 아무리 멀쩡해도, 기기 ID가 없으면 어트리뷰션 체인이 끊깁니다.
이 시점에서 많은 스타트업이 Adjust, AppsFlyer 같은 MMP 솔루션을 들여다봅니다. 기능은 검증됐지만 월 수백만 원의 라이선스 비용이 부담입니다. 시리즈 A 이전 단계라면 더욱 그렇습니다.
이 글은 MMP 없이도 sGTM 하이브리드 포스트백으로 기여도를 복구할 수 있는 아키텍처와 구축 순서를 실무 관점에서 공개합니다.
기존 방식은 앱 또는 브라우저(클라이언트)가 광고 매체사 서버로 직접 이벤트를 쏘는 구조입니다. 이 경로에는 세 가지 장벽이 생겼습니다.
00000000-0000-0000-0000-000000000000으로 마스킹됩니다. 동의율은 플랫폼·앱 카테고리에 따라 다르지만, 평균적으로 절반 이상의 iOS 사용자가 추적을 거부합니다.결국 "SDK를 잘 심었는가"의 문제가 아니라, 데이터가 매체사에 도달하는 경로 자체가 막혀 있는 구조적 문제입니다.
MMP는 이 문제를 SKAdNetwork(SKAN) 집계, 확률적 매칭 등으로 보완합니다. 하지만 스타트업 입장에서 두 가지 트레이드오프가 있습니다.
| 항목 | MMP 솔루션 | sGTM 하이브리드 포스트백 |
|---|---|---|
| 초기 비용 | 월 수백만 원 라이선스 | GCP 프리 티어 또는 Stape.io 소액 |
| 자사 DB 연동 | 제한적 (벤더 종속) | 자유로운 BigQuery·자사 DB 연동 |
| 데이터 소유권 | 벤더 플랫폼 내 | 자사 서버 완전 통제 |
| 구축 난이도 | 낮음 (SDK 설치 중심) | 중간 (개발·마케팅 협업 필요) |
초기 트래픽이 적고 인하우스 개발 리소스가 있다면, sGTM 기반 자체 구축이 비용 대비 훨씬 효율적입니다.
[사용자 광고 클릭]
→ 웹 랜딩페이지 (gclid / fbclid 캡처)
→ 앱 설치 / 실행
→ Firebase SDK → sGTM 서버 컨테이너 (자사 도메인)
→ 1자 데이터 매핑 (클릭 ID + 해시 이메일)
→ S2S 포스트백 → Meta CAPI / Google Ads API / TikTok Event API포인트는 사용자 기기를 거치지 않는다는 것입니다. 기기 식별자 없이도, 클릭 ID와 1자 데이터를 서버에서 매핑해 매체사에 전달하기 때문에 ATT·GAID 제한의 영향을 받지 않습니다.
순수 서버사이드만 사용하면 실시간 앱 이벤트 수집이 어렵습니다. 이 구조는 앱 내 Firebase SDK(클라이언트)와 sGTM 서버를 병행합니다. Firebase SDK가 이벤트를 sGTM 엔드포인트로 직접 전송하고, sGTM이 이를 가공해 매체사 API로 쏘는 방식입니다. 클라이언트의 이벤트 수집력과 서버의 데이터 통제력을 동시에 확보하는 구조입니다.
GTM 계정에서 서버(Server) 컨테이너를 신규 생성합니다. 호스팅은 Google Cloud Run 또는 Stape.io를 권장합니다.
가장 중요한 작업은 자사 도메인 하위 도메인을 sGTM 전용으로 매핑하는 것입니다.
sst.yourstartup.com → DNS CNAME을 sGTM 서버 주소로 설정퍼스트 파티 도메인 매핑 없이 sGTM을 구축하면, 기본 제공 도메인(
*.a.run.app)이 광고 차단기에 의해 필터링됩니다. 이 단계를 건너뛰면 절반의 효과도 못 냅니다.
앱이 Firebase SDK 이벤트를 구글 기본 서버가 아닌 자사 sGTM 엔드포인트로 전송하도록 설정합니다.
Info.plist): GOOGLE_ANALYTICS_SGTM_UPLOAD_ENABLED 키를 true로 설정하고, 커스텀 URL 스키마에 sst.yourstartup.com 엔드포인트를 지정합니다.AndroidManifest.xml): GA4 sGTM 업로드 관련 메타데이터를 추가해 데이터 스트림 엔드포인트를 sGTM 맞춤 주소로 교체합니다.이 단계에서 iOS 개발자와 안드로이드 개발자가 각각 1~2시간 작업이 필요합니다. 배포 전 스테이징 환경에서 DebugView로 이벤트 수신 여부를 반드시 확인하세요.
sGTM 컨테이너 내 Clients 메뉴에서 GA4(App) 클라이언트를 활성화합니다. 이 클라이언트가 Firebase SDK에서 전송된 first_open, app_update, 인앱 구매 등의 페이로드를 파싱해 sGTM 이벤트 데이터 형식으로 변환합니다.
실무에서 자주 하는 실수: 클라이언트 경로(Path)를 앱과 웹 컨테이너가 충돌하지 않도록 분리해야 합니다. 웹 GA4 클라이언트와 앱 GA4 클라이언트의 수신 경로가 겹치면 이벤트가 잘못 파싱됩니다.
이 단계가 하이브리드 포스트백의 핵심입니다.
gclid(구글 클릭 ID), fbclid(메타 클릭 ID)를 서버단 세션 스토리지 또는 자사 DB에 저장합니다.client_id 또는 자체 생성한 세션 UUID를 활용합니다.클릭 ID 유효 기간에 주의하세요. gclid는 발행 후 90일, fbclid는 28일 이내에 매칭이 이루어져야 어트리뷰션이 성립합니다.
sGTM 템플릿 갤러리에서 각 매체사 태그를 설치합니다.
Meta Conversions API 태그: Step 4에서 해싱한 이메일·전화번호 + fbclid를 매핑Google Ads Conversions 태그: gclid + 전환 가치 설정TikTok Event API 태그: TikTok 클릭 ID(ttclid) + 해시 데이터트리거는 Step 3의 클라이언트가 수신한 앱 이벤트(first_open, purchase 등)로 설정합니다. 배포 후 각 매체사 이벤트 매니저에서 테스트 이벤트 코드를 활용해 수신 여부를 확인하는 것이 필수입니다.
하이브리드 구조에서는 동일한 이벤트가 앱 SDK(클라이언트)와 sGTM(서버) 두 경로에서 동시에 발행될 수 있습니다. 매체사 대시보드에서 전환이 2배로 잡히는 왜곡이 생깁니다.
해결책: 이벤트 발행 시 고유한 event_id 를 생성해 두 경로 모두에 동일한 값을 포함시킵니다. Meta CAPI와 Google Ads는 동일한 event_id를 감지하면 자동으로 중복 제거합니다. 이 로직 없이 배포하면 성과가 부풀려져 최적화 알고리즘이 잘못된 신호를 학습합니다.
사용자가 마케팅 추적에 동의하지 않은 경우, 해당 사용자의 데이터를 포스트백에 포함시키면 개인정보보호법 위반 리스크가 생깁니다.
ad_storage: denied 여부)를 체크하는 조건을 추가합니다.이 선택은 팀 상황에 따라 달라집니다.
sGTM 하이브리드가 맞는 경우:
MMP가 여전히 유효한 경우:
두 방식은 배타적이지 않습니다. MMP를 유지하면서 sGTM을 병행 구축해 데이터 정합성을 교차 검증하는 방식도 실무에서 쓰입니다.
Q1. sGTM을 구축해도 iOS 동의 거부 사용자의 전환은 완전히 복구되나요?
A. 완전 복구는 불가능합니다. 동의 거부 사용자는 기기 ID가 마스킹되어 결정론적 매칭이 안 됩니다. 다만 gclid·fbclid 같은 클릭 ID와 해시 이메일을 통한 확률적 매칭으로 일부 복구가 가능하며, Google 동의 모드 v2 연동 시 모델링된 전환 데이터로 성과 손실을 보완할 수 있습니다.
Q2. Firebase SDK 없이 자체 앱 이벤트 시스템을 쓰는 경우에도 적용 가능한가요? A. 가능합니다. sGTM은 커스텀 클라이언트를 직접 작성할 수 있어, 자체 이벤트 스키마를 sGTM이 수신하도록 설계할 수 있습니다. 다만 개발 공수가 추가로 필요합니다.
Q3. 이 구조에서 개인정보보호법(PIPA) 위반 리스크는 없나요? A. 이메일·전화번호 등 PII를 서버에서 SHA-256 해싱 후 전달하고, 동의 모드 연동으로 미동의 사용자 데이터를 필터링하면 법적 리스크를 최소화할 수 있습니다. 단, 개인정보 처리방침에 서버사이드 트래킹 관련 고지를 추가하는 것이 권장됩니다.
Q4. 구축 후 성과 개선을 확인하려면 어떤 지표를 봐야 하나요? A. 매체사 이벤트 매니저에서 이벤트 매칭 품질 점수(EMQ)를 확인하세요. Meta CAPI 기준 7점 이상이면 양호한 매칭 상태입니다. 구축 전후 어트리뷰션 전환 수와 CPA 변화를 2~4주 단위로 비교하는 것이 가장 직관적인 성과 검증 방법입니다.
Q5. sGTM 구축에 걸리는 기간은 얼마나 되나요? A. 개발자와 마케터가 협업하는 경우, 단일 매체사(메타 또는 구글) 기준 2~3주 내 구축이 가능합니다. 복수 매체사 연동과 자사 DB 매핑까지 포함하면 4~6주를 예상하는 것이 현실적입니다.
프라이버시 규제 강화는 되돌릴 수 없는 방향입니다. 매체사 픽셀과 SDK에 의존하던 시대는 끝났고, 데이터가 자사 서버를 경유하는 구조를 갖추지 않으면 광고비를 쓸수록 기여도 공백이 커집니다.
sGTM 하이브리드 포스트백은 MMP 라이선스 없이도 이 문제를 구조적으로 해결하는 현실적인 대안입니다. 단, 올바른 설계 없이 구축하면 이벤트 중복, 동의 위반, 데이터 왜곡이라는 더 큰 문제가 생깁니다.
에이달(ADALL)은 sGTM 서버 컨테이너 구축부터 매체사별 S2S 포스트백 연동, 자사 DB 매핑까지 전 과정을 함께 설계합니다. 현재 트래킹 구조의 유실 구간이 어디인지 진단이 필요하시다면, 아래로 문의해 주세요.
에이달(ADALL) 📞 02-2664-8631 📧 master@adall.co.kr 🏢 서울특별시 강서구 방화대로31길 2, 5~6층
광고비 낭비를 막는 첫걸음은 데이터가 어디서 끊기는지 아는 것입니다. 프로젝트 문의로 현재 트래킹 구조를 함께 점검해보세요.
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기