# Client-side SDK FAQ (클라이언트 측 SDK FAQ)
# 클라이언트 측 SDK 트래킹 정책이란 무엇인가요?
네이티브 클라이언트 측 SDK (Unity, Unreal, Flutter 등 포함)의 데이터는 먼저 로컬 데이터베이스에 저장됩니다. 데이터 트래킹은 다음과 같은 상황에서 발생합니다:
- 앱이 백그라운드로 들어갈 때
- 30초마다 한 번씩 트래킹 (TA 백그라운드에서 설정 가능)
- 캐시된 데이터 수가 30개를 초과하면 트래킹을 발동 (TE에서 설정 가능)
- flush 인터페이스를 적극적으로 호출
미니 프로그램, 미니 게임 SDK 및 JavaScript SDK는 로컬 저장 없이 실시간으로 보고됩니다.
# 디바이스 ID의 값 로직은 무엇입니까?
네이티브 클라이언트 측 SDK(Unity, Unreal, Flutter 등 포함)의 디바이스 ID 값 로직은 다음과 같습니다:
- Android: 안드로이드 ID를 값으로 사용합니다.
안드로이드 8.0 이하 시스템에서는 안드로이드 ID가 고유한 기기 식별자입니다. 이는 재플래싱되거나 초기화된 후에만 변경됩니다. 모든 앱에 공유됩니다. 안드로이드 8.0 이상 버전의 시스템에서는 앱의 서명 키, 사용자 및 기기의 조합마다 고유한 ANDROID_ID 값이 있습니다. 따라서 같은 기기에서 서로 다른 서명 키를 가진 앱은 더 이상 같은 안드로이드 ID를 볼 수 없습니다(동일한 사용자에게도 적용됩니다). 특별한 조건: 사용자가 설치한 앱이 8.0 미만의 기기에 있었고, 나중에 앱을 삭제한 후 기기가 8.0으로 업그레이드된 후에 다시 설치된 경우, 안드로이드 ID는 달라집니다. 앱이 재설치되지 않는다면 안드로이드 ID는 변경되지 않습니다.
- iOS: 먼저 IDFV(Identifier for Vendor)를 획득합니다. IDFV를 획득하지 못한 경우 랜덤 UUID를 사용합니다. 첫 번째 기기 ID 값은 키 문자열에 저장되며, 이후에 IDFC가 변경되더라도 더 이상 변경되지 않습니다.
미니 프로그램, 미니 게임 및 자바스크립트 인터페이스는 유사한 기기 번호를 획득할 수 없으며, 기기 ID로 랜덤 ID가 사용됩니다. 사용자가 캐시를 삭제하면 기기 ID가 변경됩니다.
# 클라이언트 측 SDK에서 지원하는 가장 낮은 시스템 버전은 무엇입니까?
클라이언트 측 SDK에서 지원하는 가장 낮은 버전은 안드로이드 4.0 및 iOS 8.0입니다.
# 트래킹 문제를 어떻게 식별합니까?
일반적인 문제는 클라이언트 측 로그를 통해 신속하게 식별할 수 있습니다. 다양한 데이터 수집 가이드에서 클라이언트 측 로그를 활성화하는 방법을 설명했습니다.
안드로이드에서는 enableTrackLog API를 호출하여 클라이언트 측 로그를 활성화할 수 있습니다. ThinkingAnalytics를 통해 안드로이드 SDK의 로그를 필터링할 수 있습니다.
ThinkingAnalyticsSDK.enableTrackLog(true);
iOS에서는 setLogLevel을 호출하여 로그 출력을 활성화하고, THINKING을 통해 iOS SDK의 로그를 필터링할 수 있습니다.
[ThinkingAnalyticsSDK setLogLevel:TDLoggingLevelDebug]
After opening the logs, you can send the logs to our technical support engineer to help you identify the problem.
If you are not sure whether the receiver URL is correct, you can detect the accessibility of the receiver URL by inspecting the interface. Visit https://YOUR_RECEIVER_URL/health-check. If the page returns ok, it means the address of the receiving end is configured correctly.
Besides, with the functions of the tracking management module, you can also identify the problems related to data tracking swiftly.
로그를 활성화한 후, 기술 지원 엔지니어에게 로그를 전송하면 문제를 식별하는 데 도움을 받을 수 있습니다.
수신 URL의 정확성에 대해 확신이 서지 않는 경우, 해당 인터페이스를 통해 URL의 접근 가능성을 확인할 수 있습니다. https://YOUR_RECEIVER_URL/health-check 링크를 통해 접속해 보세요. 만약 페이지에서 'ok'라는 응답을 받으면, 수신 주소가 올바르게 설정되었다는 뜻입니다.
더불어, 트래킹 관리 모듈의 기능을 이용하면 데이터 트래킹 관련 문제를 빠르게 파악할 수 있습니다.
# Unity SDK를 통한 데이터 트래킹 시 주의사항은 무엇입니까?
- SDK는 Awake() 함수에서 초기화됩니다. 따라서 Awake() 내에서는 SDK 호출 과정을 실행할 수 없습니다.
- 모든 인터페이스는 기본적으로 메인 스레드에서만 호출되어야 합니다.
- 안드로이드 시스템의 컴포넌트 생명 주기를 통해 앱이 포어그라운드로 진입했는지 혹은 백그라운드로 이동했는지 파악할 수 있습니다. 하지만, Unity는 프로그램이 시작부터 SDK를 초기화할 것임을 보장하지 않습니다. 그래서 첫 번째 활성화 이벤트는 앱이 백그라운드로 처음 이동할 때만 확인할 수 있습니다. 현재, 앱이 처음으로 백그라운드로 이동할 때 상대적으로 늦은 시점에 추적되는 'ta_app_start' 이벤트를 추가하고 있습니다. 하지만 이벤트 시간인 #event_time은 정확하여, 이후의 분석에는 영향을 주지 않습니다
# Crash 이벤트의 내용은 무엇이며, 어떻게 추적하나요?
클라이언트 측 SDK는 일부 Crash로그 트래킹을 지원합니다. SDK 초기화 후 APP 크래시의 자동 트래킹을 활성화하는 것이 필요합니다. Crash이벤트에 해당하는 이벤트 이름은 'ta_app_crash'입니다.
Crash이벤트 트래킹이 트리거될 조건은 다음과 같습니다:
- 안드로이드 플랫폼: 가상 머신에서 이상이 포착되지 않음
- iOS 플랫폼:
- 유닉스 신호 이상에는 다음이 포함됩니다: SIGABRT, SIGILL, SIGSEGV, SIGFPE, SIGBUS
- NSException 이상
- Unity 엔진에서 C$ 이상의 트래킹