내부 애널리틱스
GitLab v19.2요약
내부 애널리틱스 시스템은 고객 성공 서비스와 제품 개발 방향을 결정하기 위해 GitLab 인스턴스의 사용자 행동 및 시스템 상태를 추적하는 기능을 제공합니다. 이 문서 페이지들은 새로운 기능을 개발하거나 기존 기능을 계측할 때 GitLab의 내부 애널리틱스 기능을 활용하는 방법에 대한 가이드와 정보를 제공합니다.
내부 애널리틱스 시스템은 고객 성공 서비스와 제품 개발 방향을 결정하기 위해 GitLab 인스턴스의 사용자 행동 및 시스템 상태를 추적하는 기능을 제공합니다.
이 문서 페이지들은 새로운 기능을 개발하거나 기존 기능을 계측할 때 GitLab의 내부 애널리틱스 기능을 활용하는 방법에 대한 가이드와 정보를 제공합니다.
기본 개념#
이벤트와 메트릭의 개념에 관한 동영상을 참조하세요.
이벤트와 메트릭은 내부 애널리틱스 시스템의 기반입니다. 두 개념 간의 차이를 이해하는 것이 시스템을 올바르게 사용하는 데 필수적입니다.
이벤트#
이벤트는 GitLab 인스턴스 내에서 발생한 작업의 기록입니다. 작업의 예로는 이슈 페이지 방문이나 상단 내비게이션 검색 위로 마우스 커서를 올리는 것과 같은 사용자 상호작용이 있습니다. 다른 작업은 예약된 파이프라인 성공이나 서드파티 시스템으로부터 API 호출을 수신하는 것과 같은 백그라운드 시스템 처리에서 발생할 수 있습니다. 모든 작업이 추적되어 자동으로 기록된 이벤트로 전환되는 것은 아닙니다. 대신, 작업이 제품 인사이트를 도출하고 보다 근거 있는 비즈니스 결정을 내리는 데 도움이 된다면, 해당 작업이 발생할 때 이벤트를 추적할 수 있습니다. 생성된 이벤트 기록은 최소한 해당 작업이 발생했다는 정보를 포함하며, 이 작업에 수반된 컨텍스트에 대한 추가 세부 정보를 포함할 수도 있습니다. 컨텍스트의 예로는 작업을 수행한 사람에 대한 정보나 작업 시점의 시스템 상태가 있습니다.
메트릭#
단일 이벤트 기록은 충분한 정보를 제공하지 못하며 우연의 일치에 의한 것일 수도 있습니다. 분석의 기초를 마련하려면 공통 특성을 공유하는 이벤트 집합을 살펴봐야 합니다. 이것이 바로 메트릭이 활용되는 지점입니다. 메트릭은 정보 조각들에 대해 수행되는 계산입니다. 예를 들어, 새 기능이 출시된 후 유료 사용자가 해당 기능 페이지를 방문한 단일 이벤트만으로는 이 새 기능의 성공 여부를 알 수 없습니다. 그러나 새 기능 출시 전 일주일 동안 발생한 페이지 조회 이벤트 수를 기능 출시 후 일주일 동안의 이벤트 수와 비교하면, 새 기능 출시로 인한 관심 증가에 대한 인사이트를 도출할 수 있습니다.
이 과정에서 우리가 메트릭이라고 부르는 것이 생성됩니다. 이벤트 기반 메트릭은 전체 또는 지정된 기간 내에 이벤트가 발생한 횟수를 계산합니다. 동일한 이벤트를 여러 메트릭에서 사용할 수 있으며, 메트릭은 하나 또는 여러 이벤트를 계산할 수 있습니다. 계산은 이벤트를 수행한 고유 사용자만 계산하는 것과 같은 고유성 기준에 기반할 수 있지만, 반드시 그럴 필요는 없습니다.
메트릭이 반드시 이벤트에 기반할 필요는 없습니다. 메트릭은 설정 값이나 데이터베이스(DB) 테이블의 행 수와 같이 GitLab 인스턴스 자체의 상태에 대한 관측값이 될 수도 있습니다.
계측#
-
계측 계획을 만들려면 이 템플릿을 사용하세요.
-
이벤트 기반 메트릭을 계측하려면 내부 이벤트 추적 빠른 시작 가이드를 참조하세요.
-
GitLab 인스턴스 상태를 관측하는 메트릭을 계측하려면 메트릭 계측을 참조하세요.
데이터 탐색#
이벤트 및 메트릭 데이터는 최종적으로 Snowflake 데이터 웨어하우스에 저장됩니다. 임시 분석을 위해 Snowflake에서 SQL을 통해 직접 액세스하거나, Snowflake에 액세스할 수 있는 데이터 시각화 도구 Tableau에서 시각화할 수 있습니다. 두 플랫폼 모두 액세스 요청이 필요합니다(Snowflake, Tableau).
브라우저에서 사용자 상호작용을 추적하려면 추적 거부(Do-Not-Track, DNT)가 비활성화되어 있어야 합니다. DNT는 대부분의 브라우저에서 기본적으로 비활성화되어 있습니다.
Tableau#
Tableau는 데이터 시각화 플랫폼으로, 이벤트 및 메트릭에 대한 대시보드와 GUI 기반 탐색을 구축할 수 있습니다. 이 탐색 방법은 비즈니스 인텔리전스 도구에 익숙한 사용자, 기본 검증, 그리고 지속적이고 공유 가능한 대시보드 및 시각화를 생성하는 데 가장 적합합니다. Tableau에 대한 액세스는 액세스 요청이 필요합니다.
이벤트 확인#
Snowplow 이벤트 탐색 대시보드를 방문하세요. 이 대시보드는 이벤트 수와 가장 많이 발생한 이벤트를 보여줍니다. "Structured Events Firing in Production Last 30 Days" 차트로 스크롤하여 특정 이벤트 액션을 필터링할 수 있습니다. 필터는 정확한 이름으로만 작동합니다.
메트릭 확인#
메트릭 탐색 대시보드를 방문할 수 있습니다.
사이드에는 메트릭의 key_path인 메트릭 경로 필터와 GitLab.com에 대한 필터링 방법 안내를 포함한 설치 ID 필터가 있습니다.
커스텀 차트 및 대시보드#
Tableau 내에서는 이 퍼널 분석과 같은 보다 고급 차트도 구현할 수 있습니다. 커스텀 차트 및 대시보드는 프로젝트에 이슈를 생성하여 Product Data Insights 팀에 요청할 수 있습니다.
Snowflake#
Snowflake는 Snowflake SQL 방언을 사용하여 UI 내에서 웨어하우스의 관련 테이블을 직접 쿼리할 수 있습니다. 이 탐색 방법은 SQL에 익숙한 사용자와 데이터가 올바르게 전파되었는지 빠르고 유연하게 확인하는 데 가장 적합합니다. Snowflake에 대한 액세스는 액세스 요청이 필요합니다.
이벤트 쿼리#
다음 예시 쿼리는 feature_used 이벤트의 일별 이벤트 발생 횟수를 반환합니다.
SELECT
behavior_date,
COUNT(*) as event_occurences
FROM prod.common_mart.mart_behavior_structured_event
WHERE event_action = 'feature_used'
AND behavior_date > '2023-08-01' --restricted minimum date for performance
AND app_id='gitlab' -- use gitlab for production events and gitlab-staging for events from staging
GROUP BY 1 ORDER BY 1 desc
다른 메트릭 테이블 목록은 데이터 모델 치트 시트를 참조하세요.
메트릭 쿼리#
다음 예시 쿼리는 지난 6개월 내에 count_distinct_user_id_from_feature_used_7d에 대해 보고된 모든 값과 해당 instance_id를 반환합니다:
SELECT
date_trunc('week', ping_created_at),
dim_instance_id,
metric_value
FROM prod.common.fct_ping_instance_metric_rolling_6_months --model limited to last 6 months for performance
WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --set to metric of interest
ORDER BY ping_created_at DESC
다른 메트릭 테이블 목록은 데이터 모델 치트 시트를 참조하세요.
Product Analytics#
내부 애널리틱스는 GitLab Product Analytics 기능을 도그푸딩(dogfooding)하여 이벤트를 시각화할 수 있게 합니다. Analytics Dashboards 문서에서 커스텀 시각화 및 대시보드를 구축하는 방법을 설명합니다. GitLab 프로젝트 내에서 접근 가능한 커스텀 대시보드는 별도의 리포지터리에 정의되어 있습니다. 내부 이벤트 시스템을 통해 계측된 이벤트를 기반으로 대시보드를 구축할 수 있습니다. 해당 시각화에서는 .com 설치에서 발생한 이벤트만 계산됩니다.
Product Analytics 그룹의 대시보드는 개별 이벤트를 기반으로 차트를 구축하는 방법에 대한 영감을 줄 수 있습니다.
데이터 가용성#
GitLab에서는 GitLab.com과 GitLab Self-Managed 또는 GitLab Dedicated 인스턴스 간에 애널리틱스 설정에 본질적인 차이가 있습니다.
Self-Managed 및 Dedicated#
버전 18.0부터 Self-Managed 및 Dedicated 인스턴스 모두에서 이벤트 수준 데이터를 수집하여 제품 사용에 대한 더 상세한 인사이트를 제공합니다.
GitLab 18.0 이상: Self-Managed 및 Dedicated 인스턴스는 이벤트 수준 데이터를 수집하여 GitLab.com에서 사용 가능한 것과 동일한 상세 인사이트를 제공합니다.
18.0 이전 버전: 집계된 메트릭만 사용 가능합니다. 이러한 메트릭은 무작위로 선택된 날에 주 1회 계산되며 Service Ping이라는 프로세스를 통해 Version App으로 전달됩니다. 인스턴스가 실행 중인 버전까지 계측된 메트릭만 사용할 수 있습니다. 예를 들어, 버전 16.9 개발 중에 메트릭이 계측된 경우, 버전 16.9 이상을 실행하는 인스턴스에서는 사용할 수 있지만 16.8과 같은 이전 버전을 실행하는 인스턴스에서는 사용할 수 없습니다. 수신된 페이로드는 하루에 한 번 데이터 웨어하우스로 가져옵니다.
GitLab.com#
GitLab.com 인스턴스에서는 분석을 위해 개별 이벤트와 사전 계산된 메트릭 모두를 사용할 수 있습니다. 또한 페이지 조회는 자동으로 계측됩니다.
개별 이벤트 및 페이지 조회#
개별 이벤트와 페이지 조회는 수집 인프라로 직접 전달되고, 거기서 데이터 웨어하우스로 전달됩니다. 그러나 이 단계에서 데이터는 쿼리하기 어려운 원시 형식으로 되어 있습니다. 이런 이유로 데이터 탐색 섹션에 제시된 테이블과 다이어그램에서 사용할 수 있을 때까지 데이터는 정제되어 웨어하우스를 통해 전파됩니다.
전파 프로세스는 완료되는 데 수 시간이 걸립니다. 다음 다이어그램은 이벤트의 가용성을 보여줍니다:
[
](/19.2/development/internal_analytics/img/event_collection_propagation_v17_5.png)
사전 계산된 메트릭#
메트릭은 Self-Managed와 마찬가지로 주 1회 계산되며, 유일한 차이점은 대부분의 계산이 인스턴스 내가 아닌 웨어하우스 내에서 이루어진다는 점입니다. GitLab.com의 경우 이 프로세스는 월요일 오전에 시작되며 이전 일요일 23:59 UTC부터 해당 일요일 23:59 UTC까지의 기간에 대한 메트릭을 계산합니다.
다음 다이어그램은 이 프로세스를 보여줍니다:
[
](/19.2/development/internal_analytics/img/service_ping_computation_v17_5.png)
데이터 흐름#
SaaS 및 Self-Managed 인스턴스(GitLab 18.0부터)에서 이벤트 기록은 Snowplow라는 수집 시스템으로 직접 전송되고 데이터 웨어하우스로 가져옵니다. 18.0 이전 버전의 Self-Managed 인스턴스에서는 이벤트 수만 로컬에 기록됩니다. 매주 Service Ping이라는 프로세스가 사전 정의된 모든 활성 메트릭의 현재 값을 데이터 웨어하우스로 전송합니다. GitLab.com의 경우 메트릭은 데이터 웨어하우스에서 직접 계산됩니다.
다음 차트는 이 데이터 흐름을 보여주고자 합니다:
flowchart LR; feature-->track track-->|send event record - GitLab.com, Self-Managed 18.0+ and Dedicated 18.0+|snowplow track-->|increase metric counts|redis database-->service_ping redis-->service_ping service_ping-->|json with metric values - weekly export|snowflake snowplow-->|event records - continuous import|snowflake snowflake-->vis
subgraph glb[Gitlab Application]
feature[Feature Code]
subgraph events[Internal Analytics Code]
track[track_event / trackEvent]
redis[(Redis)]
database[(Database)]
service_ping[\Service Ping Process\]
end
end
snowplow[\Snowplow Pipeline\]
snowflake[(Snowflake Data Warehouse)]
vis[Dashboards in Tableau]
데이터 프라이버시#
GitLab 18.0 이상: GitLab은 프라이버시 보호를 위해 가명 처리된 식별자를 사용하여 Self-Managed 인스턴스에서 이벤트 수준 데이터를 수집합니다.
18.0 이전 버전: GitLab은 Self-Managed 인스턴스에서 이벤트 수 또는 유사하게 집계된 정보만 수신합니다. GitLab.com 버전의 경우 개별 이벤트에 대한 사용자 식별자는 가명 처리됩니다. 내부 애널리틱스 시스템을 통해 수집되는 데이터의 종류에 대한 정확한 설명은 핸드북에 나와 있습니다.