.svg)
퍼스널 모빌리티 서비스(킥보드, 전동자전거, 전동스쿠터)를 운영한다면, 사용자 행동 데이터를 효과적으로 수집하고 분석하는 것이 필수적입니다. 이 글에서는 트래킹 정책(로그 설계)의 개념부터, 이벤트·유저 데이터 정의, 데이터 저장 방식, 로깅 프로세스, 실무 적용 팁까지 퍼스널 모빌리티 기업이 데이터 기반 의사결정을 내릴 수 있도록 도와주는 방법을 정리했습니다.
📊 고객을 사로잡는 비밀, 리텐션 분석으로 밝혀내세요!
성공적인 비즈니스는 단순히 많은 고객을 유입시키는 것이 아니라, 고객이 꾸준히 머물고 재참여하도록 만드는 것에 달려있습니다. 이를 실현하는 가장 강력한 무기가 바로 리텐션 분석입니다. 여러분을 위한 최적의 가이드, ‘리텐션 분석 A to Z 플레이북’을 지금 만나보세요!
🎮 게임 업계에 특화된 전략, 다양한 산업에 적용 가능한 인사이트!
이 플레이북은 게임 데이터 분석에 최적화된 전략을 제시함과 동시에, 다른 산업에서도 활용 가능한 리텐션 분석 노하우를 담고 있습니다. 고객의 행동 패턴을 정확하게 파악하고, 이를 바탕으로 데이터 기반의 의사결정을 내리는 방법을 배워보세요.
🔍 플레이북의 핵심 내용
• 리텐션 데이터가 비즈니스 성공에 중요한 이유
• 데이터 분석 사례 및 실전 팁
• 비즈니스 로직 기반의 리텐션 분석 전략
• 데이터를 다룰 때 놓치기 쉬운 핵심 포인트
지금 바로 다운로드하여, 고객을 사로잡는 리텐션 분석 전략을 시작하세요!
퍼스널 모빌리티 기업이 데이터를 효과적으로 수집하고 활용하는 방법
트래킹 정책이란, 사용자의 행동 데이터를 일관성 있게 수집하고 관리하는 기준과 체계를 설계하는 것을 의미합니다.
퍼스널 모빌리티 서비스에서 사용자가 앱을 실행하고, 킥보드를 대여하고, 주행한 후 반납하고 결제하는 과정을 데이터로 기록할 때,
🚲 어떤 이벤트를 수집할 것인지,
📍 이벤트에 어떤 속성을 포함할 것인지,
🔗 데이터가 어떻게 저장되고 활용될 것인지
이 모든 것을 미리 정의하고 체계적으로 관리해야 합니다.
즉, 트래킹 정책이란 ‘데이터 수집의 표준을 정하고 이를 일관되게 운영하는 것’입니다.
1️⃣ 데이터 수집 기준을 정리하여 중복 및 누락 방지
2️⃣ 데이터 분석을 쉽게 만들어 운영 효율성을 높임
3️⃣ 마케팅, 개발, 운영팀이 같은 기준으로 데이터를 활용 가능
4️⃣ 법적 요구사항을 준수하고 사용자 데이터를 안전하게 관리
🚀 "사용자의 행동 데이터를 일관되게 수집하고 관리하기 위한 기준과 체계를 설계하는 것"
퍼스널 모빌리티 서비스에서 데이터를 효과적으로 활용하려면,
🚲 어떤 데이터를 수집할지, 어떻게 저장할지, 어떤 기준으로 관리할지를 미리 정의해야 합니다.
이러한 체계가 없으면,
📍 필요한 데이터가 아예 수집되지 않거나
📍 중복·누락·불완전한 데이터로 인해 분석과 의사결정이 어려워질 수 있습니다.
🚀 트래킹 정책을 설계하는 이유는, 단순히 데이터를 쌓는 것이 아니라 ‘올바르게’ 수집하고 ‘일관되게’ 관리하기 위해서입니다.
퍼스널 모빌리티 서비스는 하드웨어(킥보드, 전동 자전거 등)와 소프트웨어(앱, 서버) 간의 데이터를 정교하게 관리해야 비용을 절감할 수 있습니다.
트래킹 정책이 없으면, 운영 데이터를 체계적으로 수집할 수 없어 최적화가 어렵습니다.
💡 예제 1) 킥보드 배치 최적화
❌ 트래킹 정책이 없으면 → "rental_start"와 "rental_end" 데이터가 정리되지 않아 어느 지역에서 수요가 많은지 알기 어려움
✅ 트래킹 정책이 있으면 → 유동 인구가 많은 지역과 반납이 많은 지역을 분석하여 최적의 배치 가능
💡 예제 2) 배터리 소모 패턴 분석을 통한 유지보수 최적화
❌ 배터리 데이터가 일관되지 않으면 → 배터리 교체 시점을 예측하지 못해 운영 비용 증가
✅ "scooter_battery_level" 데이터를 정기적으로 기록하면 → 배터리 소모 패턴을 분석하여 충전·교체 주기 최적화
🚲 사용자가 서비스를 얼마나 편리하게 이용할 수 있는지는 트래킹 정책과 직결됩니다.
🚨 트래킹 정책이 없으면, 유저 행동 데이터를 제대로 수집할 수 없어 불편한 지점을 개선하기 어렵습니다.
💡 예제 3) 불편한 반납 위치 자동 추천
❌ "rental_end" 데이터가 체계적으로 정리되지 않으면 → 사용자가 자주 반납하는 위치를 파악하기 어려움
✅ "rental_end" + "location" 데이터를 활용하면 → 주요 반납 위치를 추천하여 반납 편의성 증가
💡 예제 4) 주행 중 앱 종료 시 데이터 유실 방지
❌ "ride_event" 데이터를 저장하는 기준이 명확하지 않으면 → 앱이 강제 종료될 경우 주행 데이터 손실 발생
✅ 주기적으로 "ride_event"를 저장하도록 설계하면 → 앱이 꺼져도 데이터 유지 가능
퍼스널 모빌리티 서비스에서는 대여료, 정액권, 프로모션 등 다양한 수익 모델이 존재합니다.
🚲 트래킹 정책이 없으면, 매출을 극대화할 수 있는 데이터를 확보하기 어렵습니다.
💡 예제 5) 결제 실패율 감소
❌ "payment_failed" 데이터를 수집하는 기준이 없으면 → 어떤 결제 수단에서 오류가 많이 발생하는지 파악 불가능
✅ "payment_failed" + "payment_method" 데이터를 분석하면 → 결제 실패율이 높은 결제 수단을 개선 가능
💡 예제 6) 맞춤형 프로모션 제공
❌ "total_rentals" 데이터를 일관되게 관리하지 않으면 → 누가 VIP 고객인지 파악 어려움
✅ "total_rentals", "total_spent" 데이터를 체계적으로 관리하면 → VIP 고객에게 추가 할인 혜택 제공 가능
🚲 퍼스널 모빌리티 서비스에서 안전성 확보는 필수적이며, 트래킹 정책이 이를 가능하게 합니다.
🚨 트래킹 정책이 없으면, 사고 발생 시 원인을 정확히 파악하기 어렵습니다.
💡 예제 7) 사고 위험 구역 분석
❌ "accident_report" 데이터가 위치 정보와 함께 저장되지 않으면 → 사고 다발 지역을 분석할 수 없음
✅ "accident_report" + "location" 데이터를 수집하면 → 사고 발생이 잦은 구역에 주행 경고 제공 가능
💡 예제 8) 이상 주행 감지
❌ "speed" 데이터를 실시간으로 기록하지 않으면 → 사용자가 제한 속도를 초과하는지 알 수 없음
✅ "speed" + "ride_event" 데이터를 주기적으로 저장하면 → 과속 경고 및 속도 제한 기능 적용 가능
🚲 퍼스널 모빌리티 서비스에서 트래킹 정책을 설계하는 이유는 단순한 데이터 수집이 아니라,
데이터를 ‘정확하고 일관되게’ 관리하여 운영 최적화, 사용자 경험 개선, 매출 증대, 안전 강화 가능하게 하기 위해서입니다.
퍼스널 모빌리티 서비스에서 사용자의 행동을 정확하게 기록하고 분석하려면
🚲 트래킹 정책을 체계적으로 설계해야 합니다.
트래킹 정책이 없거나 제대로 설계되지 않으면,
📍 중복 데이터, 누락된 데이터, 일관성 없는 데이터가 발생하여 분석과 운영이 어려워질 수 있습니다.
🚀 트래킹 정책을 수립할 때 반드시 알아야 할 기본 개념과 원칙을 정리합니다.
🚲 데이터 로그(Data Log)는 특정 이벤트가 발생할 때 기록되는 데이터입니다.
퍼스널 모빌리티 서비스에서는 킥보드 대여, 반납, 주행, 결제 등 다양한 이벤트를 로그로 기록해야 합니다.
💡 예: "킥보드 대여 시작" 로그 데이터
.png)
이런 데이터가 쌓이면,
📍 어떤 지역에서 대여가 많이 발생하는지 분석 가능
📍 유저별 주행 습관을 파악해 맞춤 서비스 제공 가능
📍 네트워크 상태를 분석해 앱 사용 중단 문제 개선 가능
사용자가 앱을 사용하면서 발생시키는 특정 행동을 의미
예: "app_launch", "rental_start", "rental_end", "payment_completed"
이벤트가 발생할 때 함께 저장해야 하는 추가 정보
예: "user_id", "vehicle_id", "location", "battery_level", "speed"
이벤트가 언제 발생했는지 기록하는 데이터
예: "timestamp": "2024-02-06T14:32:00Z"
모든 이벤트에 공통적으로 포함되는 속성으로, 데이터의 일관성을 유지
예:"device_os", "app_version", "network_type", "location"
💡 예제: "킥보드 대여 시작" 이벤트 로그
.png)
📍 이런 데이터가 정확히 기록되어야, 운영 최적화·사용자 분석·비즈니스 성과 분석이 가능합니다.
🚨 "rental_start" 이벤트에서는 "vehicle_id"가 저장되지만, "rental_end" 이벤트에서는 "scooter_id"로 기록된다면? → 데이터가 불일치하여 분석 불가능
✅ 모든 이벤트에서 동일한 속성명과 데이터 구조를 유지
🚨 "payment_completed" 이벤트가 결제 성공과 동시에 여러 번 기록되면? → 사용자의 실제 결제 내역보다 많은 결제 데이터가 저장됨
✅ 각 이벤트가 중복 수집되지 않도록 설계하고, 불필요한 이벤트는 최소화
🚨 "ride_event"에서 "location"을 1초 단위로 저장하면? → 불필요한 데이터 증가로 저장 비용 증가 및 분석 속도 저하
✅ 주요 데이터만 기록하고, 필요할 때만 수집하는 방식 적용 (예: 10초 간격으로 위치 기록)
🚨 "수집할 수 있으니까 다 수집한다?" → 데이터가 많아도 활용 방법이 없으면 무용지물
✅ 각 이벤트가 어떤 비즈니스 목표와 연결되는지 명확히 정의
🚲 퍼스널 모빌리티 서비스에서는 다양한 이벤트가 발생합니다.
트래킹 정책을 수립할 때, 이벤트 유형별로 데이터를 체계적으로 정리하는 것이 중요합니다.
사용자의 특정 행동을 기록
예: "signup", "login", "rental_start", "rental_end", "payment_completed"
앱이나 서버에서 발생하는 자동화된 이벤트
예: "app_crash", "server_error", "api_response_time"
사용자의 환경 및 디바이스 상태 기록
예: "device_os":"Android", "battery_level": 80, "network_type": "LTE"
💡 예: "주행 중 속도 변경" 로그 데이터
.png)
🚲 이런 데이터가 제대로 기록되면, 사용자의 주행 패턴 분석 및 서비스 최적화가 가능해집니다.
🚲 퍼스널 모빌리티 서비스에서는 데이터가 많다고 좋은 것이 아니라, ‘적절한’ 데이터를 ‘일관되게’ 수집하는 것이 중요합니다.
✅ "무엇을 측정할 것인가?" 먼저 정의
✅ "데이터를 어떻게 활용할 것인가?" 설계
✅ "데이터 구조를 통일할 것"
✅ "이벤트 수집 기준을 명확히 할 것"
데이터를 체계적으로 수집하기 위해, 이벤트 테이블, 유저 테이블, 공통 이벤트 속성을 정의해야 합니다.
🚲 사용자의 대여, 반납, 결제, 주행 등 주요 행동을 이벤트로 정의합니다. 각 이벤트에는 발생 시점에 기록해야 하는 속성(Attributes)을 포함해야 합니다.
📌 이벤트 테이블 정리 원칙
✅ 이벤트 이름은 직관적으로 설정 (rental_start, payment_completed)
✅ 필요한 속성을 명확하게 정의 (예: "speed", "battery_level")
✅ 데이터의 일관성을 유지 (모든 이벤트에서 "user_id"는 동일한 형식으로 저장)
🚲 사용자의 정보를 효율적으로 저장하고 업데이트하는 것은 맞춤형 서비스 제공과 분석에 필수적입니다.
유저 데이터는 고정된 값, 누적되는 값, 변경될 가능성이 있는 값을 구분하여 관리해야 합니다.
📌 유저 테이블 속성 저장 방식
퍼스널 모빌리티 서비스에서는 사용자의 행동에 따라 속성이 변경될 수 있으므로, 적절한 업데이트 방식을 선택하는 것이 중요합니다.
✅ 속성 업데이트 방식 설명
📌 유저 테이블 정리 원칙 (업데이트 방식 추가 반영)
✅ 모든 유저는 user_id로 고유 식별 (변경 불가)
✅ 고정된 데이터(registration_date)와 변경될 수 있는 데이터(preferred_payment)를 구분하여 업데이트 방식 적용
✅ 누적 데이터(total_rentals 등)는 user_add를 사용하여 데이터 정확성 유지
✅ 목록 데이터(preferred_locations)는 user_uniq_append를 활용하여 중복 없이 관리
🚲 이벤트 간 일관성을 유지하고, 공통적으로 필요한 데이터를 매번 수집할 필요 없이 자동으로 포함합니다.
📌 공통 이벤트 속성 정리 원칙
✅ 모든 이벤트에 포함되도록 자동 적용
✅ 데이터 수집 표준을 유지하여 분석 용이성 증가
🚲 퍼스널 모빌리티 서비스에서 트래킹 정책을 설계하려면, 데이터 수집을 체계적으로 정의해야 합니다.
트래킹 정책이 잘못 설계되면 불필요한 데이터가 쌓이거나, 중요한 데이터가 누락되어 분석이 어려워질 수 있습니다.
🚀 이벤트 정의 → 속성 설계 → 데이터 저장 기준 → QA 검증의 4단계를 거쳐 트래킹 정책을 설계합니다.
서비스에서 어떤 사용자 행동을 기록할 것인지 결정
예: "rental_start", "rental_end", "payment_completed", "accident_report"
📌 불필요한 이벤트(예: 단순 버튼 클릭)는 제거하고, 핵심 이벤트만 수집
각 이벤트가 발생할 때 필요한 데이터를 정의
예: "rental_start" 이벤트에는 "user_id", "vehicle_id", "start_location" 포함
📌 속성을 일관된 데이터 형식으로 저장해야 분석이 용이
이벤트 데이터는 JSON 형식으로 저장
유저 데이터는 user_set, user_add 등의 저장 방식 활용
📌 Thinking Engine을 활용하여 중복 데이터 방지 및 일관성 유지
실제 서비스에서 이벤트가 정상적으로 기록되는지 검토
로그 데이터가 의도한 대로 저장되는지 확인 후 개선
📌 데이터가 너무 많거나 부족하면 이벤트 정의를 조정
🚲 퍼스널 모빌리티 서비스에서 사용자의 행동을 데이터로 기록하는 과정은 다음과 같은 4단계로 진행됩니다.
1️⃣ 이벤트 발생 (사용자 행동) → 사용자가 킥보드를 대여하거나 반납하는 등의 행동을 수행
2️⃣ 데이터 전송 (SDK → 서버) → 클라이언트 SDK가 데이터를 수집하여 서버로 전송
3️⃣ 데이터 저장 및 처리 (Thinking Engine) → 서버에서 데이터를 저장하고 전처리
4️⃣ 데이터 분석 및 활용 → 수집된 데이터를 활용하여 운영 최적화 및 인사이트 도출
🚲 사용자가 특정 행동(대여, 반납, 결제 등)을 하면 이벤트가 생성됩니다.
📍 SDK 또는 API를 통해 이벤트가 감지되며, JSON 형태로 데이터가 수집됩니다.
💡 예: "킥보드 대여 시작" 이벤트 감지
.png)
📌 이 단계에서 해야 할 일
✅ 어떤 이벤트를 로깅할지 명확히 정의 (rental_start, rental_end 등)
✅ 필요한 속성을 포함하여 일관된 JSON 구조 유지
✅ 사용자의 행동이 발생하는 즉시 이벤트 감지
🚲 SDK를 활용하여 이벤트를 서버로 전송하는 과정
📍 클라이언트에서 특정 이벤트가 발생하면 SDK의 track 메서드를 사용하여 데이터를 수집하고 전송
🚲 SDK를 사용하려면 먼저 초기 설정을 해야 합니다.
📍 앱 시작 시 한 번만 실행하면 됩니다.
.png)
📌설명
✅ "appId" → TE 프로젝트의 APP ID
✅ "serverUrl" → TE 데이터 수집 서버 주소
✅ "mode" → NORMAL (운영 환경) / DEBUG (디버그 모드)
💡 사용자가 킥보드를 대여하면 "rental_start" 이벤트를 기록하는 예제
.png)
✅ td.track("이벤트명", {속성}) → 이벤트 발생 시 속성을 포함하여 서버로 전송
✅ 속성(JSON 형태) → "user_id", "vehicle_id", "start_location" 등 포함
✅ Thinking Engine 서버로 즉시 전송되며, 분석을 위해 저장됨
🚲 일반적으로 SDK는 일정한 주기로 데이터를 전송하지만, 특정 이벤트 발생 시 즉시 전송할 수도 있음
.png)
📌 설명
✅ td.flush() → 모든 수집된 이벤트를 즉시 서버로 전송
✅ 실시간 분석이 필요한 이벤트(결제 완료, 사고 신고 등)에 적합
🚲 Thinking Engine에서는 수집된 데이터를 저장하고, 전처리 및 변환을 수행합니다.
📍 이벤트 데이터를 정리하여 분석에 활용할 수 있도록 가공합니다.
💡 예: Thinking Engine에서 데이터가 저장되는 형태
📌 이 단계에서 해야 할 일
✅ 수집된 데이터가 중복되지 않도록 ID 기반 중복 제거
✅ 이벤트별 필수 속성이 누락되지 않도록 데이터 검증 수행
✅ 속도, 배터리 상태 등 주요 데이터가 정상적으로 변환되었는지 확인
🚲 저장된 데이터는 서비스 운영 최적화 및 사용자 행동 분석에 활용됩니다.
📍 이 데이터를 기반으로 운영 전략을 수립하고, 서비스 개선 방향을 결정할 수 있습니다.
💡 예: TE에서 데이터 분석모델을 활용한 분석
📌 이 단계에서 해야 할 일
✅ 대여 수요가 많은 지역을 분석하여 킥보드 배치 최적화
✅ 이용 빈도가 높은 사용자를 식별하여 리텐션 전략 수립
✅ 이벤트 데이터 기반으로 충전 및 유지보수 일정 최적화
🚲 퍼스널 모빌리티 서비스에서 데이터 로깅을 최적화하기 위해 고려해야 할 실전 팁을 정리합니다.
🚀 불필요한 데이터 수집을 줄이고, 필요한 데이터만 정확하게 로깅하는 것이 핵심입니다.
🚨 문제: 모든 버튼 클릭을 이벤트로 수집하면 분석이 어려워짐
✅ 해결: "회원가입 → 킥보드 대여 → 반납 → 결제 완료" 같은 주요 흐름에 집중
💡 예제: 불필요한 이벤트 제거 후 최적화
🚨 문제: 같은 의미의 데이터가 다른 속성명으로 저장됨
✅ 해결: 모든 속성을 사전에 정의하고 일관된 네이밍 규칙 적용
💡 예제: 속성 네이밍 일관성 유지
📌 속성 네이밍 규칙 예시
✅ 카멜 케이스 사용:userId ❌ → user_id ✅
✅ 단위 생략:speed_kmh ❌ → speed ✅ (단위는 설명 문서에서 관리)
✅ 공통 속성 정의:device_os, app_version, network_type
🚨 문제: JSON 데이터가 너무 커서 전송 속도가 느려지고 비용이 증가
✅ 해결: 불필요한 속성 제거, 숫자 데이터 압축
💡 예제: 불필요한 속성 제거 후 최적화된 JSON 데이터
.png)
📌 개선점
✅ "start_location" → JSON 객체 {latitude, longitude} ❌ → 배열 [lat, lon] ✅
✅ "device_os", "app_version" 등 중복 속성은 공통 속성으로 이동
✅ "network_type" → 네트워크 환경에서 불필요하면 제거
🚨 문제: 이벤트가 발생할 때마다 개별적으로 서버로 전송하면 네트워크 부하 증가
✅ 해결: 일정 시간 또는 특정 조건에서 flush()를 사용하여 배치 전송
💡 예제: 특정 이벤트 후 즉시 전송
.png)
📌 개선점
✅ 실시간 분석이 필요한 이벤트(결제, 사고 신고)에는 flush() 사용
✅ 일반적인 이벤트(로그인, 메뉴 클릭)는 배치 처리
퍼스널 모빌리티 서비스에서 데이터 트래킹 정책을 제대로 설계하면, 운영 효율성을 높이고, 사용자 경험을 개선하며, 매출 증대까지 실현할 수 있습니다.
✅ 이벤트, 유저 속성, 공통 이벤트 속성을 체계적으로 정의
✅ 주행, 결제, 사고 등 퍼스널 모빌리티 서비스에 최적화된 데이터 설계 적용
✅ 로깅 프로세스를 최적화하여 빠르고 정확한 데이터 수집 가능
이제 퍼스널 모빌리티 기업이 데이터를 제대로 활용할 수 있도록 트래킹 정책을 구축해 보세요! 🚀
.png)
