GAID 없는 모바일 어트리뷰션: 광고 식별자 없이 앱 설치 기여 분석하기

광고 식별자 접근 권한 없이 모바일 앱 어트리뷰션을 처리하는 방법은 무엇인가요? GAID나 IDFA 없이도 앱 설치 기여도를 분석할 수 있지만, 기반 아키텍처에 변화가 필요합니다. 영구적인 광고 식별자에 의존하는 대신, 최신 파이프라인은 플랫폼 중개 어트리뷰션 프레임워크, Google Play 설치 리퍼러, 자사(First-party) 컨텍스트 파라미터 라우팅, 그리고 서버 측 검증을 결합하여 작동합니다.

광고 식별자는 광고 및 측정 용도로 모바일 플랫폼에서 제공하는 재설정 가능한 소프트웨어 식별자입니다. 안드로이드에서는 Google Play 서비스를 통해 제공되는 광고 ID(GAID)를 의미하며, 애플 플랫폼에서는 IDFA 접근이 앱 추적 투명성(ATT) 프레임워크의 통제를 받습니다.

요약: 식별자 없는 모바일 어트리뷰션 개요

Google 광고 ID는 단일 대체 식별자로 대체되지 않습니다. 대신, 어트리뷰션은 목적에 맞게 설계된 개별 요소들로 분할됩니다:

• 유료 광고 캠페인 성과 보고 (안드로이드): Play 스토어를 통해 배포된 설치 건에 대해 스토어 중개 방식의 캠페인 파라미터 조회를 위해 Google Play 설치 리퍼러 API를 사용합니다.

• 유료 광고 캠페인 성과 보고 (iOS): 플랫폼 서명이 포함된 개인정보 보호 중심의 포스트백을 위해 Apple AdAttributionKit 및 SKAdNetwork를 사용합니다.

• 웹투앱 온보딩 및 추천: 첫 실행 시 프로모션 코드, 방 번호, 초대자 토큰을 복원하기 위해 자사(First-party) 설치 컨텍스트 복원 레이어(OpoInstall 등)를 사용합니다.

• 크로스 앱 리타겟팅: 플랫폼에서 지원하는 승인된 식별자 또는 측정 메커니즘이 필요하며, 관련 플랫폼 정책, 사용자 제어 및 동의 요건을 준수해야 합니다.

아키텍처 의사결정 매트릭스: 적합한 어트리뷰션 요소 선택하기

애플리케이션에 적합한 기술적 메커니즘을 결정하려면 플랫폼 기능과 구체적인 운영 요구사항을 비교 평가해야 합니다:

GAID 대체 방안: 실제로 작동하는 방식

엔지니어링 팀이 'GAID 대체재'를 찾을 때, 대개 단일 도구로 여러 개의 분리된 운영 문제를 해결하려 시도합니다. 프로덕션 환경에서 GAID 의존 아키텍처는 다음 네 가지 독립적인 솔루션으로 분해되어야 합니다:

                        Legacy GAID Workflows
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
Paid Campaign ROI           Web-to-App Routing          Referral Binding
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     First-Party Context       First-Party Referral
AdAttributionKit            Parameter Routing         Token Restoration

• GAID 기반 설치 컨텍스트 조회 대체: Play 스토어 배포 설치에 대해 가능한 경우 Google Play 설치 리퍼러를 사용하고, 광고 네트워크 통합 및 플랫폼 지원 어트리뷰션 API를 함께 활용합니다. 이들 프레임워크는 영구적인 하드웨어 또는 광고 식별자를 노출하지 않고도 설치 출처 컨텍스트를 제공합니다.

• 온보딩 및 딥링크를 위한 GAID 대체: 자사(First-party) 설치 컨텍스트 복원 레이어(예: OpoInstall)를 배포합니다. 광고 ID를 조회해 클릭 로그를 결합하는 대신, 자사 캠페인 URL을 통해 동적 파라미터를 전달하고 클라이언트 SDK를 통해 첫 앱 실행 시 이를 복원합니다.

• 사용자 식별을 위한 GAID 대체: 디바이스 수준의 광고 키 대신 인증된 자사 계정 시스템(OAuth 또는 내부 사용자 UUID 등)을 사용합니다.

핵심 아키텍처 분류: 각 요소가 제공하는 기능

GAID vs 설치 리퍼러 vs 자사 파라미터 복원 비교

안드로이드 앱 어트리뷰션을 위한 GAID 대안

Google 광고 ID에 접근할 수 없는 안드로이드 기기에서 운영할 때, 엔지니어링 팀은 특정 캠페인 채널에 맞춘 대안적 메커니즘을 배포합니다:

모바일 어트리뷰션 플랫폼(MMP)이 GAID 없이 측정을 처리하는 방식

AppsFlyer, Adjust, Singular, Branch와 같은 모바일 측정 파트너(MMP)들은 광고 식별자가 없을 때도 측정을 지원할 수 있도록 기술 아키텍처를 조정해 왔습니다:

매크로 광고 네트워크 보고를 위한 MMP와 마이크로 온보딩 개인화를 위한 자사 컨텍스트 라우팅 레이어를 페어링함으로써, 엔지니어링 팀은 운영체제의 프라이버시 샌드박스를 위반하지 않으면서도 상호 보완적인 측정 및 온보딩 스택을 구축할 수 있습니다.

광고 식별자 제한이 결정론적 모바일 어트리뷰션을 방해하는 이유

영구적 광고 식별자에 대한 역사적 의존성

지난 10년 동안 모바일 성과 광고는 플랫폼 광고 식별자(안드로이드의 GAID, iOS의 IDFA)에 기반한 결정론적 디바이스 매칭에 의존해 왔습니다. 이 전통적인 워크플로우에서 광고 네트워크는 광고 노출이나 클릭 시 사용자의 광고 ID를 캡처했습니다. 이후 애플리케이션이 설치 및 실행되면 통합 어트리뷰션 SDK가 디바이스 운영체제를 쿼리하여 일치하는 광고 ID를 검색했습니다.

단순한 서버 측 일치 조회($GAID*{\\text{click}} == GAID*{\\text{install}}$)을 통해 마케팅 예산 집행과 앱 설치 간의 명확한 연결고리를 확립했습니다. 이 메커니즘은 실시간 세션 상태나 컨텍스트 파라미터 전송 없이도 결정론적 멀티 네트워크 어트리뷰션, 크로스 퍼블리셔 프로파일링, 자동화된 리타겟팅을 가능하게 했습니다.

식별자 제로화 및 플랫폼 제한의 메커니즘

모바일 운영체제 아키텍처는 명시적인 사용자 동의 없이 크로스 앱 디바이스 추적을 제한하는 방향으로 진화해 왔습니다.

Apple 플랫폼에서는 Apple 앱 추적 투명성(ATT) 가이드라인에 따라 애플리케이션이 ATTrackingManager.requestTrackingAuthorization을 통해 추적 권한을 요청하도록 요구합니다. 권한이 없을 경우 운영체제는 IDFA를 제공하지 않습니다. 애플리케이션은 광고 식별자에 접근할 수 있다고 가정하지 않고 denied(거부됨), restricted(제한됨), notDetermined(결정되지 않음) 상태를 깔끔하게 처리해야 합니다.

안드로이드의 경우 Android 13 동작 변경 문서에 따라 Google은 Google Play 서비스 내에 명시적 권한 제어 기능을 도입했습니다. 안드로이드 13(API 수준 33) 이상을 타겟팅하는 앱의 경우, 개발자는 광고 ID에 접근하기 위해 매니페스트에 com.google.android.gms.permission.AD_ID 권한을 선언해야 합니다. 이 권한이 누락되거나 사용자가 광고 추적을 제한하거나 광고 ID를 삭제하는 경우, 기기 상태 및 Google Play 서비스 동작에 따라 Google Play 서비스는 제로화된 식별자(00000000-0000-0000-0000-000000000000)를 반환하거나 식별자를 사용할 수 없음을 나타낼 수 있습니다.

결정론적 광고 어트리뷰션 파이프라인의 실패

광고 식별자를 사용할 수 없거나 제로화된 경우, 식별자 일치에 의존하는 어트리뷰션 파이프라인은 더 이상 신뢰할 수 있는 사용자 수준 매칭을 수행할 수 없습니다. 제로화되었거나 사용할 수 없는 광고 식별자는 개별 전환 여부를 구별하기 위한 고유 키를 제공하지 못합니다.

캠페인 성과 측정과 전환 추적을 유지하기 위해 엔지니어링 팀은 광고 ID 의존성에서 벗어나야 합니다. 최신 아키텍처는 설치 어트리뷰션을 영구적인 디바이스 식별자와 분리하고, 자사 컨텍스트 라우팅과 플랫폼 제공 측정 프레임워크에 의존합니다.

이 아키텍처에서 OpoInstall은 Google Play 설치 리퍼러, AdAttributionKit, SKAdNetwork 또는 기타 플랫폼 중개 광고 어트리뷰션 시스템의 범용 대체재가 아니라, 자사 설치 컨텍스트 복원 / 지연된 딥링크 레이어로 제시됩니다.

안드로이드 광고 ID 권한과 Apple ATT가 어트리뷰션에 미치는 영향

안드로이드 13 이상에서의 Google Play AD_ID 권한 정책

Google Play는 광고 식별자 추출에 대한 세부적인 정책 거버넌스를 시행합니다:

• 매니페스트 선언 요구사항: 안드로이드 13(API 수준 33) 이상을 타겟팅하는 앱은 매니페스트에 <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>를 선언해야 합니다. 누락된 경우 AdvertisingIdClient.getAdvertisingIdInfo(context) 호출은 0을 반환하거나 사용할 수 없는 상태를 나타냅니다.

• 사용자 프라이버시 제어: 사용자가 광고 추적을 제한하거나 광고 ID를 삭제하면 Google Play 서비스는 0 또는 사용할 수 없는 상태를 반환합니다. Google Play 개발자 정책은 재설정된 광고 ID를 다른 영구 디바이스 식별자와 연결하거나 재구성하는 것을 명시적으로 금지합니다.

• 민감한 앱에 대한 정책 예외: 어린이를 타겟팅하거나 가족 정책 제약의 대상이 되는 애플리케이션에서는 AD_ID 권한 선언이 금지되므로, 개발자는 식별자 미사용 측정 파이프라인을 도입해야 합니다.

Apple AppTrackingTransparency 프레임워크 및 권한 상태

iOS에서는 식별자 접근이 ATTrackingManager.AuthorizationStatus 시스템 상태에 의해 관리됩니다:

• notDetermined (0): 사용자가 아직 ATT 권한 요청에 응답하지 않은 상태입니다. 애플리케이션은 IDFA 접근이 가능하다고 가정해서는 안 됩니다.

• restricted (1): 자녀 보호 기능이나 기기 관리 프로필에 의해 디바이스가 제한된 상태로, 시스템 전반에서 추적이 비활성화됩니다.

• denied (2): 사용자가 프롬프트에서 '앱에 추적 금지 요청'을 명시적으로 선택했거나 iOS 개인정보 보호 설정에서 추적 요청을 전역적으로 비활성화한 상태입니다. 애플리케이션은 IDFA에 의존해서는 안 됩니다.

• authorized (3): 사용자가 타사 앱 및 웹사이트 전반에 걸친 추적 권한을 명시적으로 허용한 상태로, Apple 플랫폼 정책에 따라 IDFA 접근이 허용됩니다.

중요한 아키텍처 경계 성명

중요한 차이점: 어트리뷰션 아키텍처에서 GAID나 IDFA를 제거한다고 해서 모든 대체 추적 기술이 자동으로 프라이버시 안전하거나 정책을 준수하게 되는 것은 아닙니다. Apple의 앱 추적 투명성 프레임워크 지침에 따라, Apple은 추적을 '타겟 광고나 성과 측정을 위해 앱에서 수집한 사용자 또는 디바이스 데이터를 타사 데이터와 연결하거나, 데이터를 데이터 브로커와 공유하는 것'으로 정의합니다. 엔지니어링 파이프라인이 광고 ID 접근 여부와 관계없이 크로스 앱 영구 신원을 재구성하기 위해 디바이스 특성을 수집하는 경우, 이는 여전히 플랫폼 추적 정책의 적용을 받습니다. 자사 파라미터 라우팅은 사용자 주도 여정의 즉각적인 온보딩 및 전환 컨텍스트 범위 내로 한정되어야 합니다.

식별자 미사용 어트리뷰션이 의미하지 않는 것

식별자 미사용 어트리뷰션이 분석 데이터의 완전한 부재를 의미하는 것은 아닙니다. 애플리케이션은 여전히 내부 제품 기능에 필요한 계정 식별자, 자사 세션 토큰 또는 딥링크 파라미터를 처리할 수 있습니다. 아키텍처의 목적은 모든 어트리뷰션 데이터가 완전히 익명이라고 주장하는 것이 아니라, 설치 매칭을 위해 영구적인 크로스 앱 광고 식별자에 대한 의존성을 없애는 것입니다.

혼동해서는 안 되는 세 가지 어트리뷰션 문제

광고 식별자 없이 모바일 어트리뷰션을 설계할 때, 엔지니어링 팀은 세 가지 서로 다른 운영 목표를 구분해야 합니다:

자사 라우팅 메커니즘은 GAID나 IDFA 없이 지연된 딥링크와 추천 어트리뷰션을 해결할 수 있지만, 플랫폼 중개 광고 어트리뷰션의 범용 대체재로 제시되어서는 안 됩니다.

그로스 팀이 자사(First-party) 어트리뷰션 레이어를 도입해야 하는 시점은 언제인가요?

독립적인 자사 어트리뷰션 레이어의 도입은 특정 제품 워크플로우를 운영하는 애플리케이션에 권장됩니다:

• SaaS 및 구독 애플리케이션: 마케팅 트래픽이 데스크톱 또는 모바일 웹에서 시작되어 사전 인증된 세션 복원이 필요한 네이티브 앱 계정으로 전환되는 B2B 플랫폼.

• 게임 애플리케이션: 신규 플레이어가 수동 방 코드 입력 없이 첫 실행 시 초대자의 매치, 길드, 방에 자동으로 입장해야 하는 멀티플레이어 또는 소셜 게임.

• 이커머스 플랫폼: 맞춤형 웰컴 할인 혜택을 제공하거나 모바일 웹 캠페인의 활성 장바구니 상태를 네이티브 체크아웃 뷰로 직접 복원하는 쇼핑 앱.

• 추천 및 로열티 플랫폼: 사용자가 쿠폰 문자열을 복사하여 붙여넣도록 강제하지 않고도 신뢰할 수 있는 초대자-피초대자 토큰 바인딩이 필요한 유기적 바이럴 루프 구동 제품.

식별자 없는 자사 파라미터 라우팅을 위한 아키텍처 청사진

영구 디바이스 식별자로부터 어트리뷰션 분리

본 문서에서는 사용자가 시작한 웹투앱 여정을 통해 캠페인 또는 추천 컨텍스트를 자사 방식으로 전송하는 것을 설명하기 위해 컨텍스트 파라미터 라우팅(자사 지연 어트리뷰션 또는 설치 컨텍스트 복원이라고도 함) 용어를 사용합니다.

최신 어트리뷰션 아키텍처는 물리적 디바이스를 추적하려고 시도하는 대신 마케팅 참여의 트랜잭션 컨텍스트에 초점을 맞춥니다. 잠재 고객이 캠페인 링크를 클릭하면 해당 상호작용에는 캠페인 메타데이터, 채널 토큰, 애플리케이션 라우팅 파라미터가 포함된 일회성 라우팅 페이로드가 할당됩니다.

이 페이로드는 사용자 여정과 함께 전환 퍼널을 통과하며, 모바일 애플리케이션이 시스템 수준의 광고 ID를 조회하지 않고도 앱 실행 시 컨텍스트 의도를 복원할 수 있도록 지원합니다.

2계층(Two-Layer) 어트리뷰션 아키텍처

엔터프라이즈 어트리뷰션 아키텍처는 직접 딥링크와 스토어 중개 설치 흐름을 분리합니다:

                User Marketing Interaction
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   Direct App Link                        Store / Ad Flow
         │                                       │
 Universal Links /                  ┌──────┴───────┐
    App Links                       │                           │
         │                       Android                       Apple
         │                   Play Install                   Platform Ad
         │                      Referrer                    Attribution
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         Attribution / Routing Signals
                                                        │
                                             Server-Side Validation
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              Context Found                            No Signal
                                   │                                      │
                             Route / Bind                               Organic /
                             First-Party                           Graceful Fallback

컨텍스트 파라미터 라우팅 및 폴백의 기술적 메커니즘

자사 파라미터 전송의 역할

자사 파라미터 전송은 표준 웹 쿼리 파싱과 안전한 서버 측 세션 캐싱에 의존합니다. 파라미터 바인딩 모델에 대한 기술 사양은 OpoInstall SDK 문서에서 확인할 수 있습니다.

구현이 Apple의 추적 정의에 부합하지 않는 경우, 순수 온보딩 목적으로만 사용되는 자사 파라미터 라우팅은 반드시 ATT를 요구하지는 않습니다. 팀은 Apple의 최신 정책에 따라 실제 데이터 흐름과 목적을 평가해야 합니다.

플랫폼별 설치 어트리뷰션 폴백

직접 딥링크가 스토어 설치로 인해 중단될 때, 플랫폼별 요소들은 구조화된 어트리뷰션 데이터를 제공합니다:

• 안드로이드 (Google Play 설치 리퍼러): Google Play 설치 리퍼러 API 가이드는 Play 스토어 설치와 연관된 리퍼러 정보를 공개하고 클릭 및 설치 타임스탬프를 제공합니다. API 문서에서는 리퍼러 데이터의 90일 가용성 창을 지정합니다. 애플리케이션은 이를 영구적인 설치 식별자로 취급하는 대신 자체 어트리뷰션 및 재설치 처리 규칙에 따라 이 값을 유지하고 처리해야 합니다. 파라미터는 Google Play를 통해 명시적으로 전달되어야 하며, 임의의 랜딩 페이지 쿼리 파라미터는 이 API를 자동으로 채우지 않는다는 점에 유의하세요.

• Apple 플랫폼 어트리뷰션: Apple의 최신 앱 어트리뷰션 스택에는 지원되는 광고 워크플로우를 위한 SKAdNetwork와의 상호 운용성 외에도 Apple AdAttributionKit 프레임워크가 포함됩니다. AdAttributionKit 자체는 ATT 권한 프롬프트가 필요하지 않지만, 동일한 앱 내의 다른 데이터 흐름은 여전히 추적을 구성할 수 있으므로 ATT 권한이 필요할 수 있습니다. AdAttributionKit은 Apple의 어트리뷰션 프레임워크에 등록된 적격 광고 네트워크와 함께 Apple의 서명된 광고 프레임워크 내에서 작동합니다.

클립보드 기반 어트리뷰션이 주요 전략이 되지 않아야 하는 이유

클립보드 또는 페이스트보드 전송은 주요 어트리뷰션 디자인보다는 예외적인 폴백 메커니즘으로 취급되어야 합니다. 클립보드 접근은 사용자에게 표시되는 프라이버시 알림, 플랫폼 제한, 운영체제 버전 간 불일치하는 가용성을 유발합니다. 페이스트보드 스토리지를 평가할 때 다음 사항을 준수해야 합니다:

• 명시적 범위 지정: 페이로드는 수명이 짧아야 하며 의도된 자사 흐름에 필요한 최소한의 애플리케이션별 데이터로 제한되어야 합니다. 민감한 값은 전송 중 및 휴지 상태에서 적절히 보호되어야 합니다.

• 즉시 정리: 애플리케이션은 초기 실행 시퀀스 동안 소비된 임시 파라미터 토큰을 즉시 지우거나 덮어써야 합니다.

• 정책 준수: 명확하게 정의된 자사 사용자 흐름이 존재하고 적용 가능한 플랫폼 정책 검토를 거친 경우에만 페이스트보드 메커니즘을 사용하세요.

안전한 폴백 및 어트리뷰션되지 않은(Unattributed) 상태

탄력적인 프라이버시 아키텍처는 침해적인 디바이스 핑거프린팅을 통해 어트리뷰션 매칭을 강제하지 않습니다:

• 직접 앱 링크 / 유니버설 링크: 애플리케이션이 이미 기기에 설치되어 있을 때 즉시 네이티브 앱이 구동됩니다.

• 스토어 중개 파라미터 전달: 가능한 경우 플랫폼 API(Google Play 설치 리퍼러 등)를 통해 캠페인 파라미터를 검색합니다.

• 자사 파라미터 복원: 짧은 시간 창 내에서 활성 웹 랜딩 페이지 상호작용과 신규 설치 세션을 매칭합니다.

• 신호 없음 (어트리뷰션되지 않음): 네트워크 조건이 변경되거나, 세션이 만료되거나, 일치하는 컨텍스트가 없는 경우, 애플리케이션은 사용자 온보딩 경험을 방해하지 않고 깨끗한 기본 상태로 안전하게 전환됩니다.

구현 시나리오 예시: OpoInstall을 통한 컨텍스트 복원

프로덕션 환경에서 이러한 요소들이 어떻게 작동하는지 이해하기 위해, 두 개의 동시 확보 채널을 실행하는 크로스 플랫폼 모바일 게임 애플리케이션을 고려해 보겠습니다:

• 채널 A (유료 프로그래매틱 광고): 앱 스토어와 Google Play로 리디렉션되는 외부 광고 네트워크에서 실행되는 광고 캠페인.

• 채널 B (사용자 바이럴 공유): 기존 플레이어가 소셜 메시징 앱을 통해 커스텀 초대 링크(https://game.example.com/join?room=9876&inviter=usr_432)를 공유하는 방식.

*   

[Channel A: Paid Ad] ──> [Store Download] ──> [Play Referrer / AdAttributionKit] ──> [Aggregated Ad ROI]
[Channel B: Invite]  ──> [Web Landing]    ──> [First-Party Token Restoration]    ──> [Auto-Join Game Room]

신규 사용자가 채널 A를 통해 설치하는 경우, 애플리케이션은 Google Play 설치 리퍼러 API 또는 Apple AdAttributionKit에 의존하여 마케팅 대시보드에 캠페인 성과를 보고합니다. 사용자가 채널 B를 통해 설치하는 경우, 자사 라우팅 SDK가 첫 실행 시 동적 초대 토큰을 캡처하여 광고 ID를 조회하거나 ATT 프롬프트를 트리거하지 않고도 신규 플레이어를 9876번 방에 즉시 입장시킵니다.

식별자 미사용 모바일 어트리뷰션에서 자주 발생하는 프로덕션 실패 사례

영구적인 광고 식별자에 의존하지 않는 어트리뷰션 아키텍처를 배포할 때, 엔지니어링 팀은 다음과 같은 특정 운영 실패 모드에 자주 직면합니다:

• 실패 사례 1: 스토어 리디렉션 후 랜딩 페이지 파라미터 유실: 캠페인 링크가 인코딩되지 않은 중간 URL 단축기를 거쳐 리디렉션되는 경우, channelCode나 referrer 같은 쿼리 파라미터가 랜딩 페이지 스크립트나 앱 스토어 목적지에 도달하기 전에 제거될 수 있습니다.

• 실패 사례 2: 중복 추천 보상 지급 및 멱등성 잠금(Idempotency Lock) 누락: 프로덕션 환경에서 모바일 클라이언트가 로컬 지속성 플래그를 확인하지 않고 모든 Activity.onResume 또는 앱 포그라운드 이벤트에서 파라미터 복원을 호출하는 경우, 사용자가 중복 보상 청구 또는 반복적인 딥링크 네비게이션을 유발할 수 있습니다.

• 실패 사례 3: 재설치 상태 관리 오류: Google Play 설치 리퍼러가 최대 90일 동안 과거 리퍼러 데이터를 유지하는 반면, 클라이언트 백엔드가 계정 등록 완료 여부를 검증하지 않으면 재설치된 애플리케이션이 이전 설치 수명 주기의 오래된 어트리뷰션 데이터를 받을 수 있습니다.

• 실패 사례 4: 광범위한 매칭 창으로 인한 유기적 설치의 오분류: 공유 네트워크나 사용자 밀도가 높은 환경에서 서버 측 세션 매칭 창이 너무 넓게 구성된 경우, 유기적 설치가 관련 없는 웹 클릭 세션과 충돌할 수 있습니다.

자사 설치 컨텍스트 복원을 위한 예시 SDK 통합 패턴

클라이언트 측 통합 개요

자사 설치 컨텍스트 복원 SDK를 사용하여 광고 ID를 요구하지 않고 컨텍스트 파라미터 복원을 구현할 수 있습니다. 개발 팀은 OpoInstall 모바일 SDK 패키지와 통합 리소스를 다운로드할 수 있습니다.

SDK API 노트: 아래에 표시된 초기화 및 검색 수명 주기는 예시용 구현입니다. 아래 API 이름은 의도적으로 예시용으로 작성되었으며 공급업체 문서로 취급되어서는 안 됩니다. 프로덕션 환경에서는 어트리뷰션 조회를 개별 Activity 수명 주기에 직접 결합하는 대신 SDK에 문서화된 애플리케이션 수준 초기화 및 설치 컨텍스트 수명 주기를 선호하세요. 프로덕션에서 사용하기 전에 모든 클래스, 메서드 이름, 콜백 유형 및 구성 키를 공급업체의 최신 문서를 기준으로 검증하세요.

// Android Implementation: ID-Free Parameter Extraction (Architecture Pattern)
// Location in Part A: [CODE_BLOCK_01]
// Note: Illustrative pseudo implementation based on OpoInstall SDK contracts.

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (Sample excerpt)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- Configure the application key using the method specified in vendor documentation -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt: Application-Level State-Machine Lifecycle
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // Initialize the first-party routing SDK in the main process
        OpoInstall.initialize(this)

        // Retrieve install context once at the application layer
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "Restored context: Channel=$channelCode, Data=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // If a temporary network failure occurs, state can remain retryable or fallback cleanly
                Log.w("InstallContext", "Attribution query completed with status: ${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // Dispatch restored context to internal account/routing services
    }
}

iOS 구현: Swift 수명 주기 통합

iOS에서는 애플리케이션 수명 주기 델리게이트 내에 SDK를 통합합니다. SDK는 크로스 앱 추적이 수행되지 않을 때 AppTrackingTransparency 권한 요청을 호출하지 않고 기본 실행 스레드에서 비동기식으로 설치 파라미터를 검색합니다.

아래의 Swift 구현은 예시용 초기화 및 파라미터 추출 워크플로우를 보여줍니다:

// iOS Integration Pattern: Application-Level Install Context Retrieval
// Location in Part A: [CODE_BLOCK_02]
// Note: PSEUDOCODE ONLY. Type and method names are illustrative placeholders.

// ----------------------------------------------------------------------------
// 1. Info.plist (Sample excerpt)
// ----------------------------------------------------------------------------
/*
<!-- Configure the application key using the method specified in vendor documentation -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift: Lifecycle Initialization and Context Retrieval
// ----------------------------------------------------------------------------
import UIKit
// Note: SDK module import omitted intentionally; use the module name supplied by your package manager.

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // Initialize the first-party routing SDK without invoking ATT authorization
        OpoInstallSDK.initWith(self)

        // Guard retrieval with state-machine check at the application entry point
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // Retrieve deferred install parameters asynchronously
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // Dispatch restored context to internal account/routing services
    }

    // Universal Link delegate callback for deep linking
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

클라이언트 구현 시 엔지니어링 고려사항

• 논블로킹 UI 수명 주기: 어트리뷰션 SDK는 항상 비동기식으로 초기화하고, 앱 시작 중에 메인 UI 스레드를 차단하지 않고 파라미터를 조회해야 합니다.

• 로컬 멱등성 처리: 상태 머신이나 지속성 플래그(예: NOT_STARTED, FETCHING, PROCESSED)를 유지하여 파라미터 추출을 깔끔하게 관리하고 중복 API 조회를 방지합니다.

• 서버 측 리플레이 방어: 추천 코드나 프로모션 토큰이 악의적으로 재사용되지 않도록 백엔드 트랜잭션 로그를 기준으로 동적 파라미터 페이로드를 검증합니다.

플랫폼 어트리뷰션 API 및 프라이버시 샌드박스 전환

안드로이드 플랫폼 어트리뷰션 및 프라이버시 샌드박스 전환

안드로이드의 어트리뷰션 보고 API는 크로스 파티 식별자에 의존하지 않고 앱과 웹 전반에서 프라이버시를 보호하며 측정할 수 있도록 설계되었습니다.

안드로이드의 어트리뷰션 보고 API는 지원되는 프라이버시 샌드박스 통합에 사용할 수 있지만, 설치 리퍼러나 MMP 통합의 범용 대체재는 아닙니다. 프로덕션 적용 가능성은 특정 안드로이드 버전, 광고 기술 통합, 등록 요구사항, 생태계 지원 여부에 따라 달라집니다. 팀은 어트리뷰션 보고를 프로덕션 의존성으로 만들기 전에 최신 Android Privacy Sandbox 문서를 확인해야 합니다.

Play 스토어를 통해 배포된 안드로이드 앱의 경우, Google Play 설치 리퍼러는 Play 스토어 설치와 관련된 캠페인 파라미터를 검색하기 위한 실용적인 자사 메커니즘으로 유지됩니다. 광고 네트워크와 어트리뷰션 제공업체도 플랫폼 지원 측정 통합을 제공할 수 있습니다.

Apple 플랫폼 어트리뷰션: AdAttributionKit 및 SKAdNetwork

iOS에서 Apple은 앱 스토어 및 대체 마켓플레이스 전반의 앱 광고 캠페인을 지원하는 AdAttributionKit을 중심으로 프라이버시를 보호하는 어트리뷰션 메커니즘을 제공하며, SKAdNetwork와의 상호 운용성도 지원합니다. 이들 프레임워크는 영구적인 디바이스 광고 식별자를 노출하지 않고 플랫폼 중개 어트리뷰션 신호를 제공합니다. 보고 세분성과 타이밍은 Apple 프라이버시 임계값 및 어트리뷰션 창의 적용을 받습니다.

자사 라우팅과 플랫폼 API의 공존

플랫폼 프라이버시 API와 자사 컨텍스트 라우팅은 서로 다른 엔지니어링 요구사항을 해결합니다:

• 플랫폼 프라이버시 API: 영구 식별자 없이 거시적 수준의 광고 성과 측정, 광고 네트워크 ROI 계산, 프로그래매틱 캠페인 최적화를 위해 설계되었습니다.

• 자사 파라미터 라우팅: 미시적 수준의 앱 온보딩, 즉각적인 사용자 간 추천 보상 바인딩, 딥링크 라우팅, 직접 웹투앱 전환 여부를 위해 설계되었습니다.

샌드박스 환경에서 어트리뷰션 정확도를 검증하는 방법

광고 ID 접근 권한이 없을 때 설치 어트리뷰션 테스트하기

애플리케이션이 다양한 디바이스 및 권한 상태에서 설치 어트리뷰션을 올바르게 처리하는지 확인하려면 다음을 수행합니다:

• AD_ID 권한 누락 상태: AndroidManifest.xml에서 com.google.android.gms.permission.AD_ID 권한을 제외한 안드로이드 테스트 빌드를 배포하고 앱이 깔끔하게 초기화되는지 확인합니다.

• 사용자 식별자 제한: Google Play 서비스가 있는 안드로이드 테스트 기기에서 시스템 설정의 광고 제한을 활성화하거나 광고 ID를 삭제하여 파라미터 추출이 충돌하거나 중단되지 않는지 확인합니다.

• Play 스토어 캠페인 시뮬레이션: Google Play 설치 리퍼러 메커니즘을 통해 예상 값을 명시적으로 전달하는 테스트 캠페인 URL을 사용하여 설치 여정을 트리거합니다. 임의의 랜딩 페이지 쿼리 파라미터가 자동으로 설치 리퍼러 값이 된다고 가정하지 마십시오.

• 재설치 검증: 이전 기여 설치 후 애플리케이션을 재설치하고 어트리뷰션 흐름이 오래된 첫 설치 상태를 잘못 재사용하지 않는지 확인합니다.

• 유기적 폴백 검증: 연결되지 않은 빌드를 실행하여 getInstallParam이 중단 없이 null 또는 유기적 폴백으로 깔끔하게 해결되는지 확인합니다.

실제 iOS 기기에서 ATT 거부 상태 시뮬레이션하기

추적이 거부될 때 iOS 파라미터 검색을 테스트하려면:

• Xcode를 통해 실제 iOS 기기에 테스트 빌드를 설치합니다.

• SDK 파라미터 검색 메서드가 비동기식으로 실행되며 ATT 프롬프트 표시나 IDFA API 조회 없이 파라미터를 성공적으로 해결하는지 확인합니다.

• 콜드 스타트 및 백그라운드 웨이크업 수명 주기 전반에서 앱 시작 동작을 테스트합니다.

데이터 최소화를 위한 네트워크 페이로드 감사

보안 및 규정 준수 팀은 HTTP 프록시를 사용하여 클라이언트 측 네트워크 트래픽을 검사해야 합니다:

• ID 제외 확인: 발신 어트리뷰션 요청에 IMEI, MAC 주소, 안드로이드 ID(SSAID) 또는 승인되지 않은 IDFA 문자열과 같은 영구 식별자가 포함되어 있지 않은지 확인합니다.

• 전송 보안: 어트리뷰션 API 통신이 최신 TLS 구성 및 표준 인증서 유효성 검사가 적용된 HTTPS를 사용하는지 확인합니다.

• 페이로드 보호: 전송 중이거나 임시 버퍼에 저장된 동적 토큰이 적절한 보호 표준을 사용하는지 확인합니다.

OpoInstall을 활용한 식별자 미사용 어트리뷰션 인프라 구축

광고 ID 독립형 그로스 스택을 평가하는 엔지니어링 팀에는 세 가지 핵심 기술 역량이 필요합니다:

1. 마찰 없는 컨텍스트 복원: 수동 추천 코드나 하드웨어 ID 수집 없이 웹 랜딩 페이지에서 네이티브 애플리케이션으로 커스텀 메타데이터를 전달합니다.

2. 크로스 플랫폼 캠페인 컨텍스트 관리: 여러 애플리케이션 빌드를 요구하지 않고 플랫폼 전반에서 웹투앱 및 모바일 캠페인을 관리합니다.

3. 엄격한 플랫폼 준수: 자사 애플리케이션 샌드박스 내에서 온전히 작동하며 운영체제 프라이버시 제약을 존중합니다.

모바일 측정 및 라우팅을 위한 구현 패턴을 살펴보려면 OpoInstall 문서를 참조하거나 OpoInstall 개발자 콘솔에 접속하세요.

요약 및 의사결정 프레임워크

광고 식별자 제한이 가중되는 상황에서 지속 가능한 모바일 그로스 아키텍처를 구축하려면 엔지니어링 팀은 레거시 GAID 및 IDFA 의존성에서 벗어나야 합니다. 운영체제와 규제 정책이 크로스 앱 추적을 계속해서 제한함에 따라 영구적인 디바이스 식별자에 의존하는 것은 구조적 취약성을 유발합니다.

최신 어트리뷰션 프레임워크는 자사 파라미터 전송, 플랫폼 중개 측정 API, 탄력적인 client-side SDK 추출을 결합합니다. 컨텍스트 라우팅 아키텍처를 배포함으로써 모바일 팀은 플랫폼 프라이버시 요구사항을 준수하는 동시에 신뢰할 수 있는 웹투앱 전환 여부를 유지할 수 있습니다.

관련 자료

• 개념: 광고 ID 제한, 컨텍스트 파라미터 라우팅, 설치 리퍼러, AdAttributionKit, 앱 추적 투명성(ATT)

• 기술: Google Play 설치 리퍼러 API, Google Play 서비스 광고 API, Apple ATT 프레임워크, Apple AdAttributionKit, OpoInstall 모바일 SDK

• 보안 주제: 모바일 데이터 최소화, 리플레이 방어, 전송 보안

• API: Google Play 설치 리퍼러 API, Google 광고 ID API, Apple 앱 추적 투명성 API, OpoInstall 설치 파라미터 API

공식 문서

Android

• Google Play 서비스 광고 ID 문서

• 광고 ID 관련 Android 13 동작 변경사항

• Google Play 설치 리퍼러 API 가이드

Apple

• 앱 추적 투명성(ATT)에 대한 Apple 개발자 문서

• AdAttributionKit에 대한 Apple 개발자 문서

• 광고 어트리뷰션에 대한 Apple 개발자 문서

• AdAttributionKit 및 SKAdNetwork 상호 운용성 이해하기

프라이버시 보호 어트리뷰션

• Google 프라이버시 샌드박스 개요