SDK를 시작할 클래스를 선택합니다.

SDK를 전역 애플리케이션 클래스 또는 액티비티 클래스에서 시작할지 여부를 선택합니다.

• 전역 애플리케이션 클래스에서 SDK 시작: 일반적으로 전역 애플리케이션 클래스/하위 클래스에서 SDK를 초기화하는 것이 좋은 데 왜냐하면. 앱 UI가 표시되기 전에 애플리케이션 클래스가 로드되고 초기화되기 때문입니다. 이렇게 하면 딥링킹을 포함한 모든 시나리오에서 SDK를 시작할 수 있습니다.
• 액티비티 클래스에서 SDK를 시작하여(지연된 시작) 사용자가 데이터 공유를 옵트인할 수 있도록 합니다. 사용자 동의를 얻으려면 액티비티 클래스에서 렌더링된 UI(사용자 인터페이스)가 필요하기 때문입니다.

옵트아웃/옵트인 시나리오 선택하기

GDPR 및 CCPA와 같은 개인 정보 보호 규정을 준수하는 방법으로 시작을 호출하는 방법을 설명하는 옵트아웃 시나리오를 선택합니다. 예를 들어 인스톨시 옵트아웃 시나리오, 일회성 옵트아웃 시나리오 또는 제3자와의 데이터 공유 금지 시나리오 중에서 선택합니다.

코드 샘플을 포함하여 사용 가능한 옵트아웃 시나리오에 대한 자세한 내용은 옵트인 및 옵트아웃 시나리오를 참조하십시오.

안드로이드 개발자 지침

• 개발자에게 다음 사항에 대한 결정을 알립니다.
  • 애플리케이션 또는 액티비티 중 어느 클라스에서 SDK를 시작합니까?
  • 어떤 옵트인/옵트아웃 시나리오를 사용합니까?
• 개발자에게 다음 참조 링크를 보냅니다.
  • 디퍼드 스타트를 수행하는 방법
  • 일반 옵트아웃 및 옵트인 시나리오
  • 옵트아웃 코드 샘플

앱스플라이어 ID는 새 앱을 인스톨할 때마다 자동으로 생성됩니다. 마케터는 아무런 액션도 필요하지 않습니다.

이 식별자를 사용하여 다음 액션을 수행할 수 있습니다.

• 서버 간 인앱 이벤트(server-to-server in-app events) 보내기.
• 백엔드 시스템의 사용자 기록을 앱스플라이어 ID와 맞추기.
• 로데이터 인앱 이벤트 리포트를 다운로드하고 appsflyer_id를 사용하여 사용자 동작 및 여정을 분석합니다.

앱스플라이어 SDK에서 고객 사용자 ID(CUID)를 설정해두면, BI 시스템의 고유 ID가 앱스플라이어 ID 및 기타 식별자 값과 상호 참조할 수 있습니다. CUID는 앱스플라이어 로데이터 리포트에서 이용할 수 있습니다. 또한, 포스트백 API에서 해당 ID를 확보하여 귀사 내부 ID와 상호 참조할 수 있습니다. 

CUID 구현을 위한 개발자 지침을 참조하십시오.

구글 플레이 인스톨 리퍼러

구글 플레이 인스톨 리퍼러 API는 어트리뷰션 정확도를 개선하고 인스톨 사기로부터 보호를 제공하며 구글 플레이에서 참조 데이터를 안전하게 검색할 수 있게 합니다(예를 들어, 앱이 처음 설치된 시점의 앱 버전). 

개발자에게 구글 플레이 인스톨 리퍼러 API를 추가하기 위한 지침을 제공하는 것이 좋습니다. 

GAID

SDK V4.8.0부터는 앱스플라이어가 이 기기 식별자를 자동으로 수집합니다.

앱스플라이어를 사용하면 Amazon, Opera, GetJar, Baidu 및 Huawei와 같은 써드파티 앱 스토어로부터의 인스톨을 어트리뷰트할 수 있습니다.이를 통해 구글 플레이 스토어를 사용할 수 없는 시장에서도 앱을 홍보하고 더 많은 잠재 고객에게 도달할 수 있습니다.

앱스플라이어는 타사 앱 스토어의 맥락에서 다음과 같은 어트리뷰션을 지원합니다.

• IMEI 또는 안드로이드 ID: SDK는 IMEI 또는 안드로이드 ID를 자동으로 수집하지 않습니다. 그러나 이러한 식별자를 수집해야 할 필요가 있는 경우(예: 중국 국내 시장의 앱) 개발자는 다음 수집 유형 중 하나를 구현할 수 있습니다.
  • 수동 수집: 앱은 ( setImeiData 또는 setAndroidIdData API를 사용하여) IMEI 또는 안드로이드 ID를 SDK로 전달합니다. SDK는 데이터를 앱스플라이어 서버로 전송합니다. 
  • 기기 ID 수집에 대한 옵트인: SDK가 IMEI 또는 안드로이드 ID를 수집하도록 강제합니다. 
• OAID: 써트 파티 안드로이드 앱 스토어의 인스톨을 어트리뷰트합니다. 자세한 내용은 OAID 구현 가이드를 참조하십시오.
• 인스톨 리퍼러: SDK는 Samsung Gallery 및 Huawei AppGallery의 리퍼럴 데이터에 대한 검색을 지원합니다.

배경

iOS 14.5부터, IDFA를 수집하려면 사용자의 동의가 필요합니다. 이는 실제로 IDFA 액세스를 앱 추적 투명성(ATT) 프레임워크가 통제한다는 의미입니다. 기기가 iOS 14 이상일 경우, SDK는 ATT 프레임워크를 사용하여 기기 IDFA 액세스 권한을 얻습니다. 

ATT에 대한 소개는 ATT 원칙을 참조하십시오.

IDFA를 이용하여 어트리뷰션을 할 경우, IDFA는 앱 최초 실행 시점에 전송되어야 합니다. 이를 위해, 앱스플라이어 SDK는 waitForATTUserAuthorization 유틸리티를 제공합니다. 

waitForATTUserAuthorization overview

waitForATTUserAuthorization을 통해 데이터를 앱스플라이어 서버로 보내기 전에 SDK가 ATT 상태를 지연하고 대기하는 기간을 구성할 수 있습니다.

사용자가 앱을 실행하는 시점에는 ATT 상태가 결정되지 않습니다. waitForATTUserAuthorization 시간 초과 기간에 SDK는 앱 실행 이벤트와 연속적인 인앱 이벤트 인메모리(in-memory)를 오프라인 이벤트가 기록되는 방식과 유사하게 순차적으로 기록합니다.

• 사용자가 ATT 프롬프트(IDFA 컬렉션)에 동의하는 경우:
  • SDK가 IDFA를 임시 저장된(cached) 이벤트에 추가합니다.
  • SDK가 (타임아웃을 기다리지 않고) 바로 구동되어 임시 저장된 이벤트를 IDFA와 함께 전송합니다.
• 사용자가 ATT 메시지를 거부하는 경우: SDK가 (타임아웃을 기다리지 않고) 바로 구동되어 임시 저장된 이벤트를 IDFA 없이 전송합니다.
• 타임아웃이 종료되고 ATT 상태가 notDetermined로 남아 있는 경우: IDFA가 없이 SDK가 시작되고 캐시한 이벤트를 발송합니다.

고려 사항 

• waitForATTUserAuthorization을 설정하지 않고 requestTrackingAuthorization을 호출하면 iOS 14 이상의 기기에 대한 IDFA 없이 실행 및 이벤트가 전송됩니다.
• 사용자가 타임아웃 중간에 앱을 백그라운드로 이동시키면,
  • 앱이 휴대폰 화면(foreground)에 표시될 때까지 타이머가 일시 중지됩니다.
  • 이벤트는 인-메모리에 캐시됩니다.
• 사용자가 앱을 종료하면 제한 시간 동안 종료됩니다.
  • 다음 앱 실행 시점에 타이머가 재시작합니다.
  • 캐시 이벤트가 손실됩니다.

ATT 메시지를 사용자정의할 수 있습니다. 요청의 목적을 명확히 설명하는 메시지는 사용자의 선택 비율을 높이는 데 도움이 될 수 있습니다.

메시지를 작성할 때 다음 사항을 고려하십시오.

• 앱이 사용자 동의를 요청하는 이유를 가장 잘 설명하는 표현을 사용합니다.
• 사용자에게 데이터 사용 방법을 알려줍니다. 사용자 프라이버시 및 데이터 사용에 대해 자세히 알아보십시오.

메시지가 완료되면 개발자에게 텍스트와 구현 지침을 제공합니다.

ATT 메시지의 일부 외부 예시를 참조하십시오.

SKAN은 iOS가 사용하는 클래스로, 앱 설치가 광고에 기인해서 발생했는지 검증합니다. 이 앱 설치 유효성 검증 프로세스에는 소스 앱과 광고 대상 앱이 있습니다. 

소스 앱은 광고 네트워크의 광고를 자신의 지면에 게재하여 광고 캠페인에 참여하는 앱입니다. 광고를 게재하도록 앱을 구성하는 작업은 앱스플라이어 SDK 범위 내에 없습니다. 광고 게재를 위한 작업은Apple 가이드를 따르십시오.

(앱스플라이어 SDK가 설치된) 광고주 앱에 대해서, 앱스플라이어의 SKAN 솔루션은 SKAN을 이용하여 어트리뷰션 포스트백을 제공하며 앱스플라이어는 데이터를 수집, 해석, 집약하고 동시에 개인정보를 보호합니다. 앱이 설치된 후 처음 실행되면, 앱스플라이어 플랫폼은 앱 광고주(마케터)가 설정한 상태에 따라 SDK에 SKAN 전환 값을 설정하는 방식을 지시합니다.

SKAN 솔루션 사용 방법:

• 마케터는 앱스플라이어에서 SKAN 측정을 설정해야 합니다. 개발자는 어떠한 작업도 수행할 필요가 없습니다.
• 앱스플라이어 SDK는 자동으로 필요한 SKAN API를 호출합니다.
• 앱스플라이어에 의존하여 SKAN 어트리뷰션을 사용할 때 다른 SDK에서 SKAN 호출을 사용하지 않도록 설정해야 합니다.
•  App Store에서 개발자나 마케터가 해야 할 작업이나 등록 절차는 없습니다. 

SKAN 어트리뷰션을 비활성화하려면 개발사에 SDK에서 비활성화하도록 지시합니다. 

어떤 인앱 이벤트로도 수익 값을 보낼 수 있습니다. 수익을 포함하려면 af_revenue 파라미터를 사용해야 합니다. 앱스플라이어가 대시보드와 로데이터 리포트에서 실제 수익으로 계산하는 유일한 이벤트 파라미터입니다. 더 알아보기.

개발사 지침은 수익 기록을 참조하십시오.

앱스플라이어의 SDK는 인앱 구매에 대해서 서버 확인 기능을 제공합니다. 구매 검증을 통과하면 앱스플라이어로 인앱 구매 이벤트가 자동 전송됩니다. 그러므로 이 이벤트를 따로 직접 전송하면 인앱 구매 내역이 중복되어 기록됩니다.

예를 들어, 여행, 게임 또는 전자상거래와 같은 수직별 권장되는 앱 이벤트 목록을 참조하십시오.

앱을 설치하지 않은 사용자의 경우 원링크는 장치 유형을 검색하여 올바른 대상(예를 들어, Google Play, Apple App Store, 타사 앱 스토어 또는 웹 페이지)으로 리디렉션합니다. 이것은 원링크 템플릿 설정에 기반합니다. 더 알아보기

앱을 설치한 사용자에 대해 원링크는 앱을 열어줍니다. 앱을 열 뿐만 아니라 앱 내의 특정 활동이나 페이지로 사용자를 딥링킹할 수도 있습니다. 이렇게 하려면 개발사가 통합 딥링킹(UDL)을 구현해야 합니다.

일러두기:

• UDL은 SDK V6.1 이상을 요구합니다.
• 딥링킹에 원링크를 이미 사용하고 있는 고객은 UDL 대신 레거시 방법을 사용하고 있을 수 있습니다.

딥링킹(Deep linking)과 디퍼드 딥링킹(Deferred Deep Linking) 설정에 대한 가이드를 참조하세요.

앱을 설치하지 않은 사용자의 경우 원링크는 장치 유형을 검색하여 올바른 대상인 Google Play, Apple App Store, 타사 앱 스토어 또는 웹 페이지로 리디렉션합니다. 사용자가 앱을 실행하면 디퍼드 딥링킹을 사용하여 앱 내의 특정 활동 또는 페이지로 리디렉션할 수 있습니다.

이를 위해서는 개발자가 확장된 디퍼드 딥링킹을 구현해야 합니다.

일러두기:

• UDL은 SDK V6.1 이상을 요구합니다.
• 디퍼드 딥링킹에 원링크를 이미 사용하고 있는 고객은 UDL 대신 레거시 방법을 사용하고 있을 수 있습니다.

딥링킹(Deep linking)과 디퍼드 딥링킹(Deferred Deep Linking) 설정에 대한 가이드를 참조하세요.