대시 보드가 있습니다. 페이로드는 그렇지 않습니다. 그래서 나는 드리프트를 잡을 수있는 도구를 만들었습니다

당신은 믿음으로 퍼널을 고칠 수 없습니다

모든 팀에는 하나가 있습니다.

“대부분 작동하는 대시 보드. 누군가가 추적 계획을 기침 할 때 스파이크하는 채택 차트. 기술적으로 완전한 깔때기, 정확하지 않거나 최근 또는 재현 할 수있는 깔때기.

그리고 모든 데이터 엔지니어는 다음과 같습니다. 플랫 플라이닝 그래프를 응시하는 것, 기능이 실패했기 때문이 아니라 제품 업데이트가 CTA_Click 이벤트를 조용히 깨뜨 렸고 아무도 3 개의 스프린트를 발견하지 못했기 때문입니다.

그래서 나는 물건이 크게 부러지기를 기다리는 것을 멈췄습니다. 나는 내 자신의 행동 분석 디버거를 구축했습니다.

다른 도구를 만들고 싶었 기 때문이 아닙니다. 그러나 가시성이 빠졌고 신뢰가 사라 졌기 때문입니다.

우리는 관찰 도구를 가지고있었습니다. 로그, 메트릭, 대시 보드. 그러나 그들은 이것을 위해 만들어지지 않았습니다.

우리의 문제는 파이프 라인 실패가 아니었고 행동 적 실명이었습니다. Datadog 또는 Sentry와 같은 도구는 시스템 오류를 감지하는 데 능숙했습니다. 그러나 프론트 엔드 릴리스에서 Plan_Selected 이벤트가 조용히 사라 졌는지 신경 쓰지 않았습니다.

Amplitude 또는 MixPanel과 같은 제품 분석 플랫폼조차 부족했습니다. 스키마 버전에서 페이로드 수준의 일관성을 검증하지 않고 트렌드를 표시하도록 설계되었습니다. 이벤트가 표류했을 때 차트는 여전히 잘 보였습니다.

우리는 더 많은 데이터가 필요하지 않았습니다. 우리는 정렬이 필요했습니다.

대시 보드가 아닌 디버거 구축

문제는 데이터 파이프 라인이 아니 었습니다. 저를 포함하여 아무도 우리가 추적하고있는 것이 우리의 것인지 쉽게 확인할 수 없었습니다. 생각 우리는 추적했다.

물론 도구가 존재했습니다. 그러나 그들은 행동 적 완전성이 아니라 인프라 가동 시간에 초점을 맞췄습니다. 우리는 자신감있는 깔때기와 조용히 무너지는 이벤트 로그로 기능을 배송했습니다.

저의 목표는 명확하게 빠르고 내부적이며 잔인한 것을 구축하는 것이 었습니다.

• 모든 사용자 여정에 대한 원시 추적 페이로드를 당기십시오
• 환경에서 스키마 준수를 비교하십시오
• 깃발 누락 된 이벤트와 이름이 바뀌 었습니다
• 시간이 지남에 따라 이벤트 드리프트를 시각화하십시오

Diff-Checker와 Detective Board 사이의 십자가처럼 대시 보드처럼 덜 생각하십시오.

드리프트 설계

추적은 깨지기 쉽습니다. 이벤트는 이름을 변경합니다. 필드는 더 이상 사용되지 않습니다. 페이로드는 경고없이 돌연변이합니다.

그래서 나는 일류 시민으로 드리프트로 디버거를 만들었습니다. 피해야 할 것이 아니라, 잡아야 할 것이 빠르고 빠릅니다.

이 시스템은 준비 및 생산에서 샘플 페이로드를 끌어 당겨 예상 스키마에 매핑했으며 간단한 빨간색/노란색/녹색 코드로 불일치를 강조했습니다. 무언가가 바뀌면 실패하지 않았고, 그것을 나타 냈습니다.

또한 기능별로 예상 스키마 버전을 버전했습니다. 이렇게하면 팀이 CTA_Clicked를 CTA_TAP로 변경했을 때 다운 스트림 대시 보드를 깨뜨리는 것이 아니라 의도를 추적 할 수 있습니다.

디버깅 이벤트 데이터는 다른 종류의 어렵습니다

백엔드 시스템을 사용하면 오류 로그, 스택 추적, 중단 점이 발생합니다. 무언가가 끊어지면, 당신은 알고 있습니다.

그러나 행동 추적은 침묵에 실패합니다. 제품 팀이 이벤트를 바꾸거나 조건부 렌더로 인해 프론트 엔드 페이로드가 필드를 잃을 때 알람이 꺼지지 않습니다. 전환율이 급락하거나 더 나쁜 것은 전혀 눈치 채지 못합니다.

디버깅 이벤트 데이터는 디버깅 가정과 비슷합니다. 당신은 단지 코드를 추적하는 것이 아니라 의도를 추적하고, 컨벤션을 명명하고, 롤아웃 시퀀싱 및 팀 커뮤니케이션을하고 있습니다. 코드와 달리, 아무도 추적 계층을 완전히 소유하지 않습니다.

이것이 놓치기 쉽고 무시하기가 너무 위험합니다.

그것이 만든 것

나는 관찰 가능성을 재발 명하지 않았다. 방금 우리가 가장 필요한 각도에서 다시 조립했습니다.

• 파이썬 스크립트는 BigQuery를 통해 추적 페이로드를 당겼습니다
• JSON 스키마 유효성 검사기 플래그가 지정된 필드 레벨 드리프트
• 이벤트 타임 라인을 시각화 한 간단한 앱
• Slack WebHooks는 페이로드 격차에 대한 경고를 보냈습니다

없음 ai. 유행어가 없습니다. 단지 물어 보는 도구 :이 사용자 여정에서 실제로 무슨 일이 있었습니까?

그것이 우리가 잡는 데 도움이되는 버그

한 기능의 채택은 주 1 주일에 40% 감소했습니다. 제품이 휘젓는 제품. 마케팅 예산을 재 경공합니다.

Frontend Dev는 구성 요소 리팩터 중에 plan_select로 이름을 select_plan으로 바꿨습니다. 아무도 추적 계획을 업데이트하지 않았습니다. 디버거는 새로운 이벤트를 타의 추종을 불허했습니다.

또 다른 경우 : 두 가지 동일한 Signup_Complete 이벤트이지만, 논리가 A/B 테스트 분기에 조건부로로드 되었기 때문에 참조 _code가 부족했습니다. 이것은 파이프 라인 문제가 아니 었습니다. 맥락 문제였습니다.

또 다른 : 다른 : 이벤트 추적으로 시작된 실험은 제어 그룹에서 전환되었습니다. 쿼리가 엄청나게 비대칭 깔때기 완성을 반환 할 때까지 아무도 눈치 채지 못했습니다. 디버거는 테스트 변형에 걸쳐 비정상적인 이벤트 분포를 표시하여이를 잡았습니다.

그들이 Looker에 도달하기 전에 불일치를 표면함으로써, 우리는 증상 진단을 중단하고 원인을 해결하기 시작했습니다.

팀이 출시하기 전에 알고있는 것

시간이 지남에 따라, 나는 우리가 이전에 요청했던 질문을 수집하기 시작했습니다. 그들은 누군가가“우리는이 다음 스프린트를 시작하고 있습니다”라고 말할 때마다 체크리스트가되었습니다.

• 어떤 이벤트가 추적되고 있으며 어디에 있습니까?
• 추적 스키마를 누가 소유합니까?
• 이 스키마 버전이 제어됩니까?
• 생산 전에 준비를 어떻게 검증 할 수 있습니까?
• 이 필드가 널이면 어떻게됩니까?
• 우리는 이벤트를 재사용하거나 같은 이름의 이벤트를 만들고 있습니까?

이것들은 차단제가 아닙니다. 그것들입니다 버퍼혼돈에 대하여. 그리고 그들에게 물어 보면 말기 디버깅보다 더 많은주기가 절약되었습니다.

하루 안에 자신을 짓는 방법

복잡 할 필요는 없습니다. SaaS를 구축하지 않고 기본 이벤트 디버거를 회전시키는 방법은 다음과 같습니다.

• 데이터 출처 : 원시 이벤트 테이블에 액세스 할 수있는 BigQuery 또는 Snowflake
• 추출 : 페이로드를 샘플링하고 표준화하기위한 파이썬 또는 DBT 스크립트
• 스키마 유효성 검사 : Cerberus 또는 Pydantic과 같은 JSON 스키마 검증기 사용
• 드리프트 감지 : 버전, 타임 스탬프 또는 Env에 의한 Diff 필드
• UI : 세션 또는 사용자 ID 당 이상을 시각화하기 위해 간소 또는 재구성
• 알림 : 플래그가 지정된 세션이있는 Slack Webhook 또는 이메일 경고

세련되지 않았습니다. 그럴 필요가 없습니다. 누군가가 묻기 전에 무엇이 부러 졌는지 확인하면됩니다.

이 도구없이 :

• 불완전한 데이터를 기반으로 기능을 일몰 할 것입니다

• 우리는 예상 깔때기 단계의 30%를 제거한 리팩터를 놓쳤을 것입니다.

• 오래된 페이로드를 기반으로 “검증 된”대시 보드를 배송했을 것입니다

더 중요한 것은 우리는 메트릭에 대한 팀 신뢰를 계속 침식 한 것입니다. 버그를 고치는 것이 한 가지입니다. 함수에 대한 두 번째 추측을 피합니까? 그게 또 다른 것입니다.

추적을 디자인하는 방식을 변경 한 버그 중 하나입니다

4 분기 중반에 출시 된 기능. 우리가 다운 스트림 사용이 줄어드는 것을 볼 때까지 모든 것이 잘 보였습니다. 우리는 이탈을 가정했습니다. 우리는 심지어 조사를 위해 개발을 일시 중지했습니다.

사소한 리팩터가 핵심 이벤트가 잘못된 버튼을 발사하게했습니다. 같은 이름, 다른 사용자 의도. 디버거가 표시되었습니다. 우리는 그것을 패치했다. 그러나 우리는 이미 2 주와 3 개의 로드맵 품목을 잃었습니다.

QA에서 필드 특정 페이로드 테스트를 추가 한 순간이었습니다. 하나의 버그는 교대를 만들었습니다. 조기 추적, 자주 검증을 받고 아무것도 가정하지 않습니다.

디버거는 보고서뿐만 아니라 신뢰를 구축합니다

이 도구가 우리에게 준 것은 버그 수정이 아닙니다. 그것은 팀에게 명확성을 공유했습니다.

PMS는 “이것이 진짜입니까?”라고 묻지 않았습니다. 더 나은 질문을 시작했습니다. 애널리스트들은 이상을 쫓는 것을 멈추고 검증 된 땅에 자신있게 건설을 시작했습니다.

그리고 런칭 리뷰 전에 오후 11시에 대시 보드 형사 플레이를 중단했습니다.

가시성은 새로운 관찰 가능성입니다

대시 보드는 훌륭합니다. 그러나 대부분의 데이터 문제는 대시 보드에 없습니다. 그들은 상류입니다. 그들은 보이지 않습니다. 그렇지 않을 때까지.

이벤트 데이터, 깔때기 또는 행동 메트릭을 사용하는 경우 자신의 디버거를 구축하십시오. 완벽한 것이 아닙니다. 대시 보드가하기 전에 진실을 알려주는 것만.

믿음으로 깔때기를 고칠 수 없기 때문입니다. 그러나 의도적으로 디버깅 할 수 있습니다.