AppsFlyer 모바일 어트리뷰션과 쿠키 동의: 앱 퍼블리셔를 위한 2026년 통합 가이드
앱 개발자에게 모바일 측정은 웹 측정과는 근본적으로 다른 문제입니다. 웹 퍼블리셔가 걱정하는 쿠키는 네이티브 앱 내부에 존재하지 않지만, 이를 대체하는 식별자들 — IDFA, GAID, IDFV, 설치 ID, 해시된 이메일, IP 기반 기기 지문 — 은 동일한 법적 질문을 제기하며 동일한 규제 기관의 관할 하에 있습니다. 모바일 게임, 핀테크, 소비자 앱 분야에서 가장 널리 배포된 모바일 측정 파트너인 AppsFlyer는 이 파이프라인의 중심에 위치합니다. AppsFlyer의 SDK는 어트리뷰션 수준의 식별자를 수집하고, 서버는 이를 광고 네트워크 포스트백과 대조하며, 그 결과로 생성된 어트리뷰션은 모든 주요 채널의 사용자 획득 예산에 반영됩니다. 이 모든 처리는 적법한 근거 없이는 이루어질 수 없으며, GDPR과 ePrivacy 지침이 실제로 요구하는 적법한 근거는 동의입니다 — SDK가 초기화되기 전에 수집되고, 증거로 기록되며, 모든 다운스트림 연동에 전파되어야 합니다. 이 가이드에서는 AppsFlyer가 수집하는 항목, iOS, Android 및 모바일 웹에서 동의 관리 프레임워크와 통합하는 방법, 그리고 플랫폼 자체의 개인정보 보호 기능(Start SDK API, ATT 신호, 데이터 프라이버시 프레임워크)이 전체 구조에 어떻게 들어맞는지를 설명합니다.
AppsFlyer가 수집하는 항목
AppsFlyer SDK는 호스트 앱이 시작되자마자 세션을 초기화하며, 기본적으로 식별자 및 상황별 신호 묶음을 수집합니다: 기기 수준 광고 식별자(iOS의 IDFA, Android의 GAID), iOS의 벤더 범위 IDFV, 세션 간 유지되는 생성된 AppsFlyer 설치 ID, IP 주소(지역 IP 및 지문 방식의 확률적 매칭에 사용), 사용자 에이전트, 기기 모델, OS 버전, 통신사, 시간대가 이에 해당합니다. 설치 후 SDK는 설치 이벤트를 AppsFlyer 서버에 보고하며, 서버에서는 광고 네트워크가 전달한 클릭 데이터와 대조합니다. 이후 인앱 이벤트 — 구매, 등록 완료, 튜토리얼 완료, 커스텀 이벤트 — 는 동일한 SDK를 통해 발생하며 동일한 식별자 세트를 상속합니다.
규제 기관은 이것이 GDPR에 따른 개인정보 처리에 해당한다고 명확히 밝혔습니다. IDFA와 GAID는 영구적인 기기 수준 식별자이기 때문에 개인정보에 해당합니다. 이와 함께 실행되는 확률적 지문 매칭은 동의 없이 방어하기가 더욱 어렵습니다. 이는 정의상 사용자의 명시적 협조 없이 사용자를 식별하려는 시도이기 때문입니다. CNIL, 이탈리아 Garante, 스페인 AEPD 모두 동의 이전에 어트리뷰션 스택을 실행한 퍼블리셔를 대상으로 조사를 개시한 바 있습니다.
AppsFlyer 기본 개인정보 보호 제어
AppsFlyer는 의미 있는 수준의 네이티브 개인정보 보호 기능을 제공합니다. 이것이 실제 동의 프레임워크를 대체할 수는 없지만, CMP가 SDK 동작을 제어하는 데 사용하는 레버이므로 이를 이해하는 것이 필수적입니다.
Start SDK API
SDK는 구성은 되지만 start()가 명시적으로 호출될 때까지 데이터를 전송하지 않는 초기화 모드를 지원합니다. 이것이 동의 게이팅을 위한 가장 중요한 훅입니다 — 기본적으로 SDK는 앱 실행 시 자동으로 시작되는데, 이는 사전 동의가 필요한 모든 관할권에서 잘못된 동작입니다. 초기화 시 isStopped를 true로 설정하거나 지연 시작 API를 사용하고, 동의 신호가 기록된 후에만 start()를 호출하십시오.
Stop API
세션 도중 동의가 철회되면 stop()을 호출하여 이후 모든 전송을 중단합니다. 이미 전송된 데이터를 소급 삭제하지는 않습니다. 완전한 삭제를 위해서는 AppsFlyer의 프라이버시 포털을 통해 데이터 주체 삭제 요청을 제출해야 하며, 이는 수동 워크플로가 아닌 AppsFlyer API를 통해 자동화해야 하는 통합 작업입니다.
setSharingFilter
이 기능은 다운스트림 광고 네트워크 중 어디에 포스트백 데이터를 전달할지를 필터링합니다. 세분화된 파트너별 동의에 적합한 기능입니다 — 예를 들어, 일반적으로 어트리뷰션은 허용하되 사용자가 거부한 특정 네트워크로의 전달은 차단하는 경우에 사용합니다.
Apple App Tracking Transparency 통합
iOS에서 AppsFlyer는 ATT 인가 상태를 읽고 자동으로 동작을 조정합니다 — 사용자가 ATT를 거부한 경우 IDFA는 전송되지 않습니다. ATT는 GDPR 동의와 독립적이며, 많은 퍼블리셔가 이 둘을 혼동합니다. ATT는 단일 iOS 수준 신호를 제어하고, GDPR 동의는 그 외 모든 것을 제어합니다.
iOS에서의 통합
iOS에서의 신뢰할 수 있는 패턴은 AppsFlyer SDK를 설치하되 ATT와 인앱 동의 플로우가 모두 완료될 때까지 초기화를 지연시키는 것입니다. 최소 시퀀스는 다음과 같습니다: 앱이 실행되고, SDK가 isStopped = true로 구성되고, 인앱 동의 배너가 표시되고, 사용자가 관련 카테고리를 수락하면, SDK의 isStopped 플래그가 해제되고 start()가 호출됩니다. 앱에서 ATT도 필요한 경우(IDFA가 의미 있는 모든 사용자에게 해당), ATT 프롬프트는 인앱 배너와 함께 또는 이후에 표시됩니다. 모바일을 지원하는 대부분의 CMP는 동의 결정을 전달하는 콜백 기반 API를 갖추고 있으며, 해당 콜백이 start()를 호출하기에 적합한 위치입니다.
Android에서의 통합
Android 구현은 두 가지 차이점을 제외하면 iOS와 유사합니다. 첫째, ATT에 해당하는 것이 없습니다 — GAID는 사용자가 기기 수준의 "광고 ID 삭제" 설정을 실행하지 않는 한 사용 가능하며, 대부분의 사용자는 이를 실행하지 않습니다. 둘째, Android의 생명주기는 백그라운딩에 더 공격적이므로 SDK 초기화는 영구적으로 저장된 동의 상태에 연결되어야 합니다. 앱 실행 시 로컬 저장소에서 동의 상태를 읽고, 그에 따라 SDK를 구성하며, 앱이 백그라운드에 있는 동안 사용자가 선택을 변경했을 경우를 대비해 재개 시 다시 확인하십시오.
모바일 웹에서의 통합
AppsFlyer는 스마트 배너 및 OneLink 제품을 통해 모바일 웹에서도 운영됩니다. 이들은 본질적으로 브라우저에서 쿠키를 설정하고 AppsFlyer 서버를 호출하는 웹 측 분석 및 딥링크 도구입니다. 이들은 다른 모든 웹 추적 표면과 동일한 규칙을 따릅니다: CMP의 마케팅 카테고리 뒤에 게이팅하고, 동의가 부여되기 전에 스마트 배너 스크립트가 실행되지 않도록 하며, 이메일 또는 푸시 캠페인에서 OneLink가 트리거한 이벤트가 사용자의 동의 상태를 준수하도록 보장하십시오.
자주 발생하는 실수
AppsFlyer 배포 감사에서 네 가지 통합 실수가 반복적으로 나타납니다.
ATT를 GDPR 동의로 취급하기
ATT와 GDPR 동의는 범위가 다른 별개의 신호입니다. ATT를 수락한 사용자는 교차 앱 추적을 위한 IDFA 사용을 허가한 것이지, SDK가 수행하는 다른 모든 것을 허가한 것은 아닙니다. EU 및 UK 트래픽의 경우 두 신호가 모두 필요하며, 인앱 배너가 구속력 있는 신호이고 ATT는 그 위에 추가되는 iOS 전용 계층입니다.
SDK가 실행 시 초기화되도록 방치하기
이것이 가장 흔한 단일 결함입니다. 기본 통합은 start()를 즉시 호출하여 사용자가 동의 배너를 보기 전에 전체 식별자 페이로드와 함께 설치 이벤트를 발생시킵니다. 해결 방법은 간단합니다: 통합 시 isStopped = true로 구성하고 동의 콜백에서만 start()를 호출하십시오.
동의 철회 처리를 누락하기
사용자가 수락 후 나중에 철회하는 경우, SDK에 전송 중단을 알려야 합니다. stop() API를 사용하고 영구 저장된 동의 상태를 업데이트하여 다음 앱 실행 시 새로운 결정이 반영되도록 하십시오.
서버 간 포스트백을 무시하기
AppsFlyer는 서버 측 포스트백을 통해 연동된 다수의 광고 네트워크에 전환 이벤트를 전달합니다. 각 전달에는 개인정보가 포함되며 원래 이벤트의 동의 범위를 상속합니다. setSharingFilter를 사용하여 AppsFlyer 대시보드의 모든 파트너가 아닌, 사용자의 동의 선택에 해당하는 파트너에게만 전달되도록 하십시오.
감사 체크리스트
EU, UK 또는 캘리포니아 트래픽에 관련된 모든 AppsFlyer 배포에 대해 답해야 할 여섯 가지 구체적인 질문입니다.
- SDK가 동의를 기다리는가? EU에 위치한 테스트 기기에서 새로 설치할 때, 사용자가 배너를 수락하기 전에 AppsFlyer 엔드포인트에 어떤 요청도 전송되지 않는지 확인하십시오.
- ATT가 인앱 동의와 분리되어 있는가? 인앱 배너가 제어하는 동의 신호이고 ATT가 추가적인 iOS 전용 계층으로 취급되는지 확인하십시오.
- 파트너 전달이 동의 범위에 맞게 설정되어 있는가? setSharingFilter가 사용자가 허가하지 않은 파트너를 제외하도록 구성되어 있는지 확인하십시오.
- 동의 철회 시 SDK가 중단되는가? 동의 철회 시 stop() 호출이 작동하고 새로운 상태가 실행 간에 유지되는지 확인하십시오.
- 서버 포스트백이 감사되고 있는가? AppsFlyer 대시보드의 "구성된 연동" 목록이 배너에 공개된 마케팅 파트너와 정확히 일치하는지 확인하십시오.
- 데이터 삭제가 자동화되어 있는가? DSAR 요청이 수동 티켓이 아닌 AppsFlyer의 삭제 API를 트리거하는지 확인하십시오.
동의 우선 스택에서 AppsFlyer의 위치
모바일 어트리뷰션은 마케팅 스택에서 가장 식별자 집약적인 영역 중 하나이며, AppsFlyer의 SDK는 그중 가장 중요한 단일 연동입니다. 좋은 소식은 플랫폼이 동의 시행을 깔끔하고 검증 가능하게 만드는 데 필요한 기능들 — Start SDK, Stop, 공유 필터, 삭제 API — 을 제공한다는 것입니다. 퍼블리셔가 해야 할 일은 이러한 기능들을 구속력 있는 동의 결정을 소유하는 CMP에 연결하고, ATT를 대체가 아닌 보완 신호로 취급하며, 서버 측 파트너 전달이 배너가 기록한 동의 범위를 벗어나지 않도록 하는 것입니다. 올바르게 수행하면, 규제 기관을 만족시키면서도 사용자 획득 팀이 의존하는 설치 및 이벤트 데이터를 보존하는 어트리뷰션 스택을 구축할 수 있습니다.