menu
Is this helpful?

# Preparations before Data Ingestion (데이터 연동 준비)

# 데이터 전송 준비

여기서는 데이터 전송을 실시하기 전에 이해해야 할 데이터 규칙에 대해 설명합니다.

필수 정보에서는 데이터 전송 시 준비해야 할 시스템 파라미터에 대해 설명합니다.

TE(ThinkingEngine)는 풀 엔드에서의 데이터 전송 스키마를 제공하고 있습니다.

일반적으로, TE로의 데이터 전송에는 3단계가 있습니다.

  1. 비즈니스 니즈에 기반하여 데이터 수집 계획을 정리 (필요에 따라, 저희 분석가가 서포트할 수 있습니다).
  2. 엔지니어에 의해 데이터 수집 계획에 기반한 구현을 수행
  3. 데이터 전송의 정확성을 검증

또한, 데이터 전송 전에, TE의 기본적 이해가 중요합니다.

이 문서에서는, 데이터 전송에 필요한 지식에 대한 개요를 설명합니다.

이 문서를 보실 대상자는, 비즈니스 측 담당자, 엔지니어 측 담당자, 검증 테스트 담당자 등, TE를 사용할 가능성이 있는 모든 분들이 대상입니다.

# 1. 개요

TE는 풀 엔드에서의 데이터 전송 스키마를 제공하고 있습니다. 주요 데이터 전송 방법은 다음과 같습니다.

  • 클라이언트 SDK
    • 서버와 통신하지 않고, 디바이스 정보나 유저 행위에 관한 정보를 비교적 쉽게 수집합니다
  • 서버 SDK
    • 서버와 통신하고, 더 정확한 유저 행위에 관한 정보를 수집합니다
  • 데이터 임포트 툴
    • 더 일반적인 데이터 수집 스키마인 LogBus를 사용한 서버 SDK 등이 사용됩니다
    • 보통은 과거 데이터의 임포트에 사용됩니다

일반적인 앱이나 웹 개발 환경에 맞추어, TE는 다음의 SDK를 제공하고 있습니다.

  • React Native SDK
  • Flutter SDK
  • 오리지널 SDK
    • Android SDK
    • iOS SDK
  • 서드파티 프레임워크
    • Flutter
    • Reactive Native
  • H5 개발
    • JavaScript SDK
    • H5와 네이티브 SDK 오픈 솔루션

작은 게임 개발을 위해, 우리는 제공합니다:

  • 주류 게임 엔진 지원: Cocos Creator

모바일 게임 개발을 위해, 우리는 제공합니다:

  • Unity SDK

서버 단에서의 수집 시나리오에서는, 서버 SDK와 LogBus의 병행을 권장합니다. 이 방식은, 데이터 수집 도구의 안정성, 실시간성, 효율성에서 가장 우수합니다.

다른 히스토리 데이터를 새로 가지고 오거나 추가해야 하는 경우, DataX를 사용하는 것을 고려할 수 있습니다. 그러나, LogBus와는 달리,DataX는 실시간으로 지속적인 프로그램이 아니며, 새로운 데이터의 생성을 모니터링하고 실시간으로 인입할 수 없습니다. 따라서 데이터의 실시간성을 보장할 수 없습니다. DataX의 장점은, 비교적 간단한 작업으로 여러 데이터 소스에서의 데이터 전송을 지원할 수 있다는 것입니다.

또한, Filebeat와 Logstash를 사용하여 히스토리 데이터를 수집하고, 로그 데이터를 TE에 심는 경우는, Filebeat + Logstash를 참조하십시오.

데이터 수집 방법을 설계할 때는, 사업 상황에 따라 앱의 기술 아키텍처와 비즈니스 필요에 적합한 방법을 선택하는 것이 바람직합니다. 수집 방법에 대한 질문은, TE의 담당자에게 문의하십시오.

# 2. 기본 지식

# 2.1 TE 데이터 모델

데이터 전송 전에, 먼저 TE의 데이터 테이블을 이해해야 합니다.

데이터 수집 방법의 설계는, 비즈니스 목표에 따라, 수집해야 할 유저 행위 데이터 등을 결정하는 과정입니다. 예를 들어, 유저의 결제 상황을 분석하고 싶은 경우에는, 수집해야 할 것은 사용자의 결제 행위 데이터입니다. 이러한 유저 행위는 5W1H로 분류할 수 있습니다.

사용자 행위 데이터는, TE에서 유저 데이터와 이벤트 데이터로 구성되며, 각각 유저 테이블과 이벤트 테이블에 저장됩니다. 유저 데이터는, 주로 자주 변하지 않는 사용자의 상태나 속성이 기술됩니다. 반면 이벤트 데이터는, 특정 행동 이벤트와 관련된 정보가 기술됩니다.

따라서, 데이터 수집 방법을 검토할 때에는, 유저 데이터와 이벤트 데이터를 TE에 알리는 타이밍이나 트리거를 결정해야 합니다. 각각의 세부 사항은 유저 식별 규칙을 참조해 주세요.

모든 데이터 전송 가이드에서는, 유저 데이터와 이벤트 데이터를 각각 접근하는 방법을 설명하고 있습니다.

# 2.2 유저 식별 규칙

유저 데이터와 이벤트 데이터는, 각각이 어떤 유저에 속하는지를 지정해야 합니다. 계정 시스템이 없는 앱의 경우에는, 디바이스 관련 ID를 사용하여 유저를 식별합니다. 반면 계정 시스템이 있는 앱의 경우에는, 유저가 여러 디바이스에서 단일 계정을 사용하여 데이터를 생성하는 경우가 있습니다. 이러한 경우에 분석에서는, 여러 디바이스를 가로질러 유저 데이터를 분석하는 것이 바람직하며, 디바이스 관련 ID를 사용하는 것은 부적절합니다.

위의 2가지 시나리오에 대응하기 위해, 데이터 전송에서는 2가지 유저 ID를 조합하여 유저를 식별하고 있습니다.- 게스트 ID (#distinct_id)

  • 클라이언트 측에서 랜덤한 게스트 ID를 생성하여 유저를 식별합니다.
  • 계정 ID (#account_id)
    • 유저가 로그인할 때 계정 ID를 임의로 설정할 수 있습니다. 계정 ID를 사용하면 여러 디바이스의 데이터를 연결할 수 있습니다.

TE에 저장되는 데이터에는 게스트 ID 또는 계정 ID 중 하나를 포함해야 합니다. 클라이언트 SDK에서는 기본적으로 게스트 ID를 랜덤으로 생성합니다. 로그인을 호출하여 계정 ID를 설정하고, 계정 ID가 설정되면 모든 데이터에서 어느 ID도 보고됩니다. 서버 레벨에서는 적어도 하나의 ID를 보고해야 합니다.

또한 TE에서는 유저를 식별하는 유니크한 ID인 TE 유저 ID (#user_id field)가 설정됩니다. 데이터가 보고되면, 유저 식별 규칙에 따라 새로운 ID가 설정되거나 기존의 ID가 연결됩니다.

유저 식별 규칙은 매우 중요합니다. 위의 ID가 제대로 설정되지 않으면, 데이터가 잘못된 유저와 연결되어 분석 효과에 영향을 미칩니다. 데이터 전송 전에 규칙을 잘 이해하고, 데이터 수집 시에도 유저 식별에 관한 설정을 완료해야 합니다.

# 2.3 데이터 규칙

데이터 전송 방법에 관계없이, 데이터 전송 시에는 통일된 데이터 규칙에 의해 제한됩니다. 데이터 규칙에서는 데이터 형식과 각각의 제한에 대해 설명합니다.

SDK를 통해 데이터에 접근하는 경우에는, 해당 인터페이스를 호출함으로써, SDK는 접근에 필요한 데이터 형식으로 데이터를 정리합니다. 데이터 임포트 도구나 Restful API를 사용하여 데이터를 전송하는 경우에는, 데이터 규칙의 설명에 따라 데이터를 정리해야 합니다.또한 데이터 형식에 대해서는, 이름 바꾸기 규칙과 속성 값의 데이터 타입에 특별히 주의를 기울여야 합니다.

  • 이름 바꾸기 규칙
    • 이벤트 이름이나 속성 이름에는 문자, 숫자, 밑줄만 포함할 수 있습니다. 또한 50 문자를 초과할 수 없습니다

참고: 속성 이름에서는 대문자와 소문자가 구분되지 않습니다. 반면 이벤트 이름과 속성 값에서는 대문자와 소문자가 구분됩니다.

  • 속성 값의 데이터 타입
데이터 타입 샘플 비고 데이터 타입
Numerical value 123,1.23 데이터 상한： -9E15 to 9E15 Number
Text "ABC", "Tokyo" 데이터 상한：2KB String
Time "2019-01-01 00:00:00","2019-01-01 00:00:00.000" "Yyyy-MM-dd HH: mm: ss. SSS " or "yyyy-MM-dd HH: mm: ss" 날짜를 원할 경우: "yyyy-MM-dd 00:00:00" String
Boolean true,false - Boolean
List ["a","1","true"] 리스트의 요소는 문자열로 인식됩니다. Array(String)
개체 {hero_name: "Liu Bei", hero_level: 22, hero_equipment: ["Male and Female Double Sword", "Lu"], hero_if_support: False} 개체의 Key는 고유한 데이터 타입을 가집니다. 그 설명은 일반적인 속성 을 참조하십시오. 개체 내의 Key의 상한은 100개입니다. 개체
개체 그룹 [{hero_name: "Liu Bei", hero_level: 22, hero_equipment: ["Male and Female Double Sword", "Lu"], hero_if_support: False}, {hero_name: "Liu Bei", hero_level: 22, hero_equipment: ["Male and Female Double Sword", "Lu"], hero_if_support: False}] 개체 그룹의 Key는 고유한 데이터 타입을 가집니다. 그 설명은 일반적인 속성 을 참조하십시오. 개체 그룹 내의 Key의 상한은 500개입니다. Array(개체)

참고: TE에서는, 속성 값의 데이터 타입은 처음으로 받은 속성 값의 데이터 타입에 따라 결정됩니다. 값의 데이터 타입이 데이터 내의 어떤 속성과 사전에 결정된 데이터 타입이 일치하지 않는 경우, 해당 속성을 폐기해야 합니다.

TE에는 #으로 시작하는 속성 이름이 있으며, 이러한 속성은 사전 설정 속성이며, 특별한 설정을 필요로 하지 않고, SDK는 기본적으로 수집하고 있습니다. 자세한 내용은 Preset attribites and system fields를 참조하십시오.

데이터 형식이나 데이터 타입이 올바르게 설정되어 있지 않은 경우, 데이터를 저장할 수 없음에 주의하십시오. 따라서, 데이터 전송 시 또는 데이터 검증 시에는 Data Reporting Management 모듈을 사용하여 데이터의 정확성을 확인하고 관리해야 합니다.

# 3. 필수 정보

엔지니어에 의해 공식적으로 데이터 전송이 이루어지기 전에, 다음의 정보가 준비되어 있는지 확인하십시오.

  1. Project APP ID
  • TE에서 프로젝트를 생성하면, 프로젝트마다 APP ID가 생성됩니다. 프로젝트 관리 화면에서 확인할 수 있습니다.
  1. 데이터 수신 끝 주소
  • SaaS 버전을 사용하는 경우, 'https://ta-receiver.thinkingdata.io'입니다
  • 프라이빗 구축의 경우, 프라이빗 클러스터(또는 액세스 포인트)에 도메인 이름을 연결하고, SSL 인증서를 발행해야 합니다
  1. 데이터 수신 끝 주소 확인 방법
  2. 아래 URL에 접속하고, OK가 표시되는지 확인하십시오
  3. https://YOUR_RECEIVER_URL/health-check
  4. 데이터 수집 정리- 데이터 수집 방법
  • 클라이언트 SDK, 서버 SDK, 데이터 수집 도구 또는 여러 방법의 조합을 명확히 해주세요
  • 데이터 전송할 데이터의 내용과 트리거 타이밍

데이터 전송 전에 이해해야 할 문서 읽기가 완료되었습니다. 이제, 선택한 데이터 수집 방법에 기반하여, 해당하는 엑세스 가이드를 참조하면서, 데이터 전송을 시작해주세요.