기본 개념
- 이벤트
- 메트릭스
계기화
데이터 검색
데이터 가용성
- 자체 관리 및 Dedicated
- GitLab.com
  - 개별 이벤트 및 페이지 뷰
  - 미리 계산된 메트릭
데이터 흐름
데이터 프라이버시
기여 가이드라인

내부 분석

내부 분석 시스템은 GitLab 인스턴스의 사용자 동작과 시스템 상태를 추적하여 고객 성공 서비스 및 더 나은 제품 개발에 도움이 됩니다.

이 문서 페이지는 GitLab의 내부 분석 기능을 활용하는 방법과 새로운 기능을 개발하거나 기존 기능을 계기화하는 방법에 대한 가이드와 정보를 제공합니다.

기본 개념

이벤트와 메트릭스는 내부 분석 시스템의 기초입니다. 두 개념 간의 차이를 이해하는 것은 시스템 사용에 있어서 중요합니다.

이벤트

이벤트는 GitLab 인스턴스 내에서 발생한 동작의 기록입니다. 예를 들어 사용자 상호작용 및 이슈 페이지 방문 또는 상단 내비게이션 검색에 마우스 커서를 올리는 것과 같은 동작이 될 수 있습니다. 예정된 파이프라인이 성공하거나 제 3자 시스템에서 API 호출을 받는 것과 같이 백그라운드 시스템 처리로 인한 다른 동작들 역시 해당됩니다. 모든 동작이 추적되어 자동으로 기록된 이벤트로 전환되는 것은 아닙니다. 대신, 동작이 제품 통찰력을 도출하고 더 학습된 비즈니스 결정을 할 수 있도록 도와주는 경우에만 이벤트를 추적할 수 있습니다. 생성된 이벤트 기록은 최소한 동작이 발생한 것에 대한 정보를 보유하고 있으며, 해당 동작이 발생할 때 동반된 컨텍스트에 대한 추가적인 세부 정보를 포함할 수도 있습니다. 컨텍스트의 예로 동작을 수행한 사람의 정보나 동작 시 시스템의 상태에 대한 정보가 있습니다.

메트릭스

단일 이벤트 기록만으로는 충분한 정보를 얻을 수 없으며 우연으로 인한 것일 수도 있습니다. 분석의 기초를 위해 공통 특성을 갖는 이벤트 집합을 찾아야 합니다. 이 때 메트릭스가 필요합니다. 메트릭스는 정보 조각에 수행된 계산입니다. 예를 들어, 새로운 기능을 릴리스한 후 유료 사용자가 기능 페이지를 방문하는 단일 이벤트만으로는 새로운 기능의 성공에 대해 알 수가 없습니다. 그러나, 새로운 기능 릴리스 전 주에 발생한 페이지 뷰 이벤트의 수를 계산하고, 릴리스 후 주에 발생한 이벤트 수와 비교한다면, 새로운 기능 릴리스로 인한 관심 증가에 대한 통찰을 얻을 수 있습니다.

이 프로세스는 메트릭스로 이어지게 됩니다. 이벤트 기반 메트릭스는 이벤트의 발생 횟수를 전체적으로 또는 지정된 시간 프레임 내에 계산합니다. 동일한 이벤트는 다른 메트릭스에서도 사용될 수 있으며, 메트릭스는 하나 이상의 이벤트를 계산할 수 있습니다. 계산은 단일 동작을 수행한 고유성 기준을 기반으로 할 수 있지만, 그렇지 않을 수도 있습니다.

메트릭스는 이벤트를 기반으로 할 필요가 없습니다. 메트릭스는 GitLab 인스턴스 자체의 상태에 대한 관측일 수도 있으며, 예를 들어 설정의 값을 또는 데이터베이스 테이블의 행 수를 포함할 수 있습니다.

계기화

계기화 계획을 생성하려면 이 템플릿을 사용하세요.
이벤트 기반 메트릭스를 계기화하려면 내부 이벤트 추적 빠른 시작 가이드를 참조하세요.
GitLab 인스턴스 상태를 관찰하는 메트릭스를 계기화하려면 메트릭스 계기화를 참조하세요.

데이터 검색

이벤트 및 메트릭스 데이터는 기본적으로 Snowflake 데이터 웨어하우스에 저장됩니다. 이 데이터는 특수한 분석을 위해 Snowflake에서 직접 SQL을 통해 액세스하거나 Snowflake에 접근 권한을 갖는 Tableau을 통해 시각화될 수 있습니다. 두 플랫폼 모두 액세스 요청이 필요합니다(Snowflake, Tableau).

참고: 브라우저에서 사용자 상호작용을 추적하려면 대부분의 브라우저에서 Do-Not-Track (DNT) 설정을 해제해야 합니다. 대부분의 브라우저에서 DNT는 기본적으로 해제되어 있습니다.

Tableau

Tableau는 데이터 시각화 플랫폼으로 대시보드 및 GUI 기반 이벤트 및 메트릭스의 발견을 제공합니다. 비즈니스 인텔리전스 도구, 기본 검증에 익숙한 사용자들 및 지속적이고 공유 가능한 대시보드 및 시각화를 생성하기 위해 가장 적합한 방법입니다. Tableau에 액세스하기 위해서는 액세스 요청이 필요합니다.

이벤트 확인

Snowplow 이벤트 탐색 대시보드를 방문하세요. 이 대시보드는 이벤트 수와 가장 많이 발생한 이벤트를 보여줍니다. “구조화된 이벤트가 마지막 30일 동안 제품화되는 이벤트 수” 차트로 스크롤하여 특정 이벤트 액션을 필터링할 수 있습니다. 필터는 정확한 이름만 작동합니다.

메트릭스 확인

메트릭스 탐색 대시보드를 방문할 수 있습니다. 측면에는 메트릭 경로의 필터와 GitLab.com에 대한 필터링 방법에 대한 안내가 표시됩니다.

사용자 정의 차트 및 대시보드

Tableau 내에서 퍼널 분석과 같은 고급 차트를 생성할 수도 있습니다. 추가로 사용자 정의 차트와 대시보드는 제품 데이터 인사이트 팀의 프로젝트에서 요청할 수 있습니다.

Snowflake

Snowflake를 사용하면 데이터 웨어하우스의 관련 테이블을 직접 쿼리하는데 사용되는 Snowflake SQL 방언을 통해 구체적으로 확인이 가능합니다. 이것은 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' --성능에 대한 제한된 최소 날짜
AND app_id='gitlab' -- 프로덕션 이벤트에는 gitlab을 사용하고 스테이징 이벤트에는 gitlab-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 --성능을 위해 마지막 6개월로 제한된 모델
WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --관심 메트릭으로 설정
ORDER BY ping_created_at DESC

기타 메트릭 테이블 목록은 데이터 모델 치트 시트를 참조하십시오.

제품 분석

내부 분석은 GitLab 제품 분석 기능을 Dogfooding하고 이벤트를 시각화하는 기능을 제공합니다. 분석 대시 보드 설명서에서 사용자 정의 시각화 및 대시 보드를 작성하는 방법을 설명합니다. GitLab 프로젝트 내에서 접근 가능한 사용자 정의 대시 보드는 별도의 저장소에서 정의됩니다. 내부 이벤트 시스템을 통해 생성된 이벤트를 기반으로 대시 보드를 작성하는 것이 가능합니다. 해당 시각화에는 .com 설치에서 발생한 이벤트만이 포함됩니다.

제품 분석 그룹 대시 보드는 개별 이벤트를 기반으로 차트를 작성하는 방법에 대한 영감을 제공할 수 있습니다.

데이터 가용성

GitLab은 자체 관리 및 GitLab Dedicated 인스턴스와 GitLab.com 간에 분석을 위한 중요한 차이가 있습니다.

자체 관리 및 Dedicated

자체 관리 및 Dedicated 인스턴스에서는 미리 계산된 메트릭만 사용할 수 있습니다. 이러한 메트릭은 매주 무작위로 선택한 하루에 한 번 계산되어 버전 앱으로 전달됩니다. 인스턴스가 실행 중인 버전의 개발 중에 계측된 메트릭만 사용할 수 있습니다. 예를 들어, 버전 16.9의 개발 중에 메트릭이 계측되면 16.9 이상의 인스턴스에서 사용할 수 있지만 16.8과 같은 이전 버전에서는 사용할 수 없습니다. 받은 페이로드는 매일 우리 데이터 웨어하우스로 가져옵니다.

GitLab.com

GitLab.com에서는 분석을 위해 개별 이벤트 및 미리 계산된 메트릭 양쪽 모두를 사용할 수 있습니다. 추가로 페이지 뷰는 자동으로 계측됩니다.

개별 이벤트 및 페이지 뷰

개별 이벤트와 페이지 뷰는 직접 수집 인프라로 전달되고 여기서 데이터 웨어하우스로 가져옵니다. 그러나이 단계에서 데이터는 쿼리하기 어려운 원시 형식으로 되어 있습니다. 이러한 이유로 데이터는 데이터 검색 섹션에서 가리키는 테이블 및 다이어그램에 도달할 때까지 정리되고 전파됩니다.

전파 프로세스는 여러 시간이 소요됩니다. 다음 다이어그램은 이벤트의 가용성을 보여줍니다:

출처

미리 계산된 메트릭

미리 계산된 메트릭은 자체 관리와 마찬가지로 매주 계산되지만, 대부분의 계산이 인스턴스 내에서가 아닌 데이터 웨어하우스에서 수행됩니다. GitLab.com의 경우,이 프로세스는 월요일 아침에 시작되어 일요일 23:59 UTC부터 다음 주 23:59 UTC까지의 기간에 대한 메트릭을 계산합니다.

다음 다이어그램은 이 프로세스를 보여줍니다:

출처

데이터 흐름

SaaS에서 이벤트 레코드는 직접 Snowplow라는 수집 시스템으로 전송되어 데이터 웨어하우스로 가져옵니다. 자체 관리 및 GitLab Dedicated 인스턴스에서는 이벤트 카운트를 로컬로 기록합니다. 매주 Service Ping 프로세스가 모든 사전 정의 및 활성 메트릭에 대한 현재값을 데이터 웨어하우스로 전송합니다. GitLab.com의 경우 메트릭은 데이터 웨어하우스에서 직접 계산됩니다.

다음 차트는이 데이터 흐름을 설명하는 것을 목표로 합니다:

flowchart LR; feature-->track track-->|이벤트 레코드 전송 - gitlab.com에서만 실행|snowplow track-->|메트릭 카운트 증가|redis database-->service_ping redis-->service_ping service_ping-->|주간 내보내기를위한 메트릭 값의 json|snowflake snowplow-->|이벤트 레코드 - 연속적인 가져오기|snowflake snowflake-->vis subgraph glb[Gitlab Application] feature[기능 코드] subgraph events[내부 분석 코드] track[track_event / trackEvent] redis[(Redis)] database[(데이터베이스)] service_ping[\Service Ping Process\] end end snowplow[\Snowplow 파이프라인\] snowflake[(Snowflake 데이터 웨어하우스)] vis[Tableau에서 대시보드]

데이터 프라이버시

GitLab은 자체 관리 인스턴스로부터 이벤트 횟수 또는 유사하게 집계된 정보만을 수신합니다. GitLab의 SaaS 버전에서 개별 이벤트에 대한 사용자 식별자는 익명화됩니다(의사 실명화). 내부 분석 시스템을 통해 수집되는 데이터 유형에 대한 정확한 설명은 핸드북에서 제공됩니다.