귀하의 추적 계획을 실제로 소유해야 하는 사람은 누구입니까?

편집자 주: 이 기사는 원래 2021년 1월 11일 Iteratively 블로그에 게시되었습니다.

"데이터는 팀 스포츠입니다"는 우리가 Amplitude에서 강력하게 믿고 자주 이야기하는 것입니다. 애널리틱스 추적 계획도 마찬가지입니다. 추적 계획(및 계획의 계측)은 본질적으로 협력적입니다. 관련 팀이 모일 때 가장 잘 작동합니다.

새 기능 릴리스의 예를 들어 보겠습니다. 제품 팀은 이 새로운 기능에 대한 목표와 메트릭을 정의했으며 이러한 메트릭을 측정하는 데 필요한 이벤트 추적을 볼 수 있습니다. iOS, Android 및 웹 개발 팀은 코드에서 이러한 이벤트를 계측(및 이상적으로는 테스트)할 책임이 있으며 실현 가능한 것에 대한 의견을 가질 것입니다. 분석가 또는 분석 엔지니어는 데이터 모델링을 담당하고 해당 구조에 관심을 가집니다. 보고서 작성 및 여러 도구에서 데이터 분석을 담당하는 여러 팀이 있을 수 있습니다. 요컨대 데이터 기반 회사 분석에는 거의 모든 사람이 참여합니다.

이 예는 분석 추적이 실제로 얼마나 복잡한지 말하며 올바른 이벤트를 정의 및 캡처하고 이를 정확하게 구현하며 데이터 소비자가 데이터를 쉽게 탐색할 수 있도록 할 때 협업의 중요성을 말해줍니다. 즉, 너무 많은 사람이 참여하면 분석 추적이 쉽게 뜨거운 감자가 됩니다.

모두의 소유라면 아무도 소유하지 않는다

많은 이해 관계자가 관련되어 있으므로 추적 계획은 종종 명확한 소유자 없이 공동 책임이 됩니다. 그리고 공동 책임에는 책임이 거의 없습니다.

우리는 분석 추적과 관련된 프로세스를 (재)생성하려는 많은 회사와 이야기를 나눴습니다. 일반적으로 스프레드시트나 Confluence 또는 Notion 페이지를 중심으로 진행됩니다. 대부분 수동이고 코드에서 추적 계획을 시행할 방법이 없지만 처음에는 유용하며 팀이 이벤트 추적에 대해 더 많이 생각하도록 합니다.

그러나 몇 달이 지나면 Notion 페이지나 Google 스프레드시트가 구식이 됩니다. 최신 릴리스에 대한 추적은 Jira 스토리에만 문서화되었으며 몇 가지 다른 기능 릴리스에 대해서는 추적이 구현되었는지 여부가 이제 불분명합니다. 아무도 추적 계획을 최신 상태로 유지하는 것을 책임지지 않습니다.

그렇다면 이것을 어떻게 개선하고 분석 추적을 소유하기에 가장 좋은 위치에 있는 사람은 누구입니까?

분석을 전면 중앙에 배치하여 시작

소유권 문제로 들어가기 전에 성공적인 분석 추적에 필요한 기반을 언급해야 합니다. 현실은 대부분의 팀에서 분석은 나중에 생각하는 것입니다. 다음은 우리가 항상 보는 예입니다.

• PM은 릴리스 작업
• 릴리스 발생
• CEO는 PM에게 실적을 묻습니다.
• PM: "데이터 팀에 물어보겠습니다."
• 데이터 팀: "당신은 우리를 데려온 적이 없습니다. 이 기능에 대한 데이터가 없습니다."
• PM은 대답없이 CEO에게 돌아갑니다.
• 데이터 팀과 PM은 혼란스러워합니다.

분석이 모든 릴리스의 필수적인 부분이 되지 않는다면, 이는 계속 반복될 것이며 추적 계획이 정말 매끄럽고 최신 상태인지 여부는 중요하지 않습니다. 분석 추적이 기능 자체만큼 중요하다는 모든 이해 관계자(및 리더십 팀)의 동의가 필요합니다. 추적 없음, 릴리스 없음.

관련 팀에 권한을 부여하려면 명확한 책임, 시간 및 리소스가 필요하며 이벤트 추적 및 성공 지표를 Jira 티켓 수준까지 포함해야 합니다(추적 코드가 나머지 코드와 함께 배송될 때만 완료 됨).

데이터 및 제품 전문가와의 400회 이상의 인터뷰에서 배운 것

2년 동안 우리는 400명 이상의 제품 관리자, 데이터 팀 및 엔지니어를 인터뷰했습니다. 우리는 몇 가지를 보았습니다.

물론 추적 계획과 그 주변의 프로세스는 비즈니스, 팀 구조 및 수직에 고유합니다(아마도 이것이 바로 잡기가 어려운 이유일 것입니다). 전자상거래 회사의 추적 계획은 B2B SaaS 회사의 추적 계획과 매우 다르게 보입니다. 서로 다른 이해 관계자가 관련되어 있으며 완전히 별개의 현실을 해결합니다. 가장 일반적으로 우리는 회사 규모별로 본 것을 세분화할 수 있습니다.

스타트업

소기업의 경우 추적 관련 프로세스는 일반적으로 임시적입니다. 참여하는 사람이 거의 없고 복잡성을 관리하기 쉽기 때문에 자연스러운 일입니다. 대부분의 경우 제품 책임자 또는 성장 책임자가 회사 여정의 이 단계에서 주도권을 잡는 것을 봅니다.

중소기업

중간 규모 회사에서 프로세스는 일반적으로 데이터/분석의 책임자입니다. 이제 더 많은 이해 관계자가 참여하고 복잡성이 쉽게 문제가 될 수 있습니다. 이 단계에서는 피해를 제한하기 위해 소유권이 확실히 필요하며 일반적으로 데이터 팀의 누군가에게 해당됩니다.

기업

대기업에서는 궁극적으로 추적 계획을 소유하는 사람이 일반적으로 제품 분석 책임자가 됩니다. 전자 상거래 회사의 경우 전자 상거래의 책임자가 되는 경우가 많습니다. 종종 그들은 계획을 유지하거나 프로세스를 시행하는 실제 일상적인 사람이 아니라 팀 내에서 책임을 지는 사람이 될 것입니다.

우리는 이러한 유형의 설정에서 다양한 수준의 성공을 보았습니다. 그래서 우리는 무엇이 가장 잘 작동한다고 생각합니까?

작동 방식: 제품 팀이 최종 소유자입니다.

이것이 우리가 아는 것입니다. 최고의 소유권 프로세스는 제품 팀이 최종 소유자 역할을 할 때 발생합니다. 제품 관리자는 주요 동인이어야 하며 분석 추적이 모든 기능 릴리스의 일부인지 확인해야 합니다 . 팀 규모에 따라 한 명 이상의 제품 관리자 또는 전담 제품 분석가가 될 수 있습니다. 역할 및 OKR의 일부로 분석 추적에 대한 책임을 져야 합니다.

그러나 앞서 언급했듯이 데이터는 팀 스포츠이므로 팀이 함께 이벤트 명명 및 분류와 같은 항목을 정의하는 것이 좋습니다. 엔지니어와 데이터 팀은 일상 업무에도 영향을 미치므로 중요한 관점을 갖게 됩니다. 제품 팀이 집행자이자 궁극적인 소유자이지만 올바른 이해 관계자의 참여 없이 사일로에서 작업하거나 중요한 결정을 내려서는 안 됩니다.

모든 관련 이해관계자를 대표하는 자문위원회를 구성하는 것은 우리가 함께 일한 회사에 잘 맞았습니다. 모든 결정이 자문 위원회에 전달되는 것은 아니지만 자문 위원회는 초기에 동인이 되어 분류 및 프로세스를 정의하고 시간이 지남에 따라 얼마나 많은 주요 변경 사항이 발생하는지에 따라 정기적으로 회의를 해야 합니다.

제품 팀이 이를 성공적으로 소유하려면 명확한 프로세스가 필요합니다.

• 모든 사용자 스토리의 일부로 정성적 및 정량적 메트릭 모두에 대한 명확한 성공 기준을 갖습니다 . 이는 PM이 정의하고 데이터 팀 또는 분석가와 스파링해야 합니다.
• 추적이 누락되었습니까? 빌드에 실패합니다. 완료라는 개념은 모든 릴리스의 일부로 분석 추적을 포함하도록 진화해야 합니다. 이는 출시 직전에 릴리스를 차단하는 것이 아니라 처음부터 추적 고려 사항을 포함하는 프로세스를 구현하는 것을 의미합니다.
• 협업이 핵심입니다. PM이 이벤트 추적 사양을 소유하는 동안 데이터 팀 또는 분석가는 개입하여 추적해야 하는 세부 사항을 정의하는 데 도움을 줄 수 있어야 합니다.

제품 관리자가 소유권을 갖도록 권한 부여

일부 PM의 경우 추적 계획을 소유하는 것이 자연스러운 일입니다. 그들은 통제를 원하고 경험이 있습니다. 그리고 그들은 필요할 때 도움을 요청하는 것을 두려워하지 않습니다. 그러나 모든 PM에게 자연스러운 것은 아닙니다.

첫째, 문화 변화가 일어나야 합니다. 새 기능이나 제품 릴리스의 성능과 성공을 축하해야 합니다. 놀랍게도 많은 사람들에게 여전히 칭찬을 받는 것은 제품의 성능 여부가 아니라 배송입니다.

그렇다면 제품 팀이 추적 계획을 소유하도록 어떻게 권한을 부여합니까? 이것은 완전한 목록은 아니지만 사람들이 시작할 수 있는 곳이 되기를 바랍니다.

• 정기적인 교육 : 이벤트 추적을 올바르게 하는 것은 과학만큼이나 예술입니다(즉, 쉽지 않음). 팀이 편안하게 주도권을 잡는 데 필요한 지식을 갖추도록 하세요. 교육은 점심 및 학습 스타일, 워크숍 또는 일대일 세션이 될 수 있습니다(향후 고용을 위해 세션을 녹음하는 것을 잊지 마십시오).
• 근무 시간 : 데이터 팀이 다른 팀이 데이터 팀의 전문성과 지식을 활용할 수 있도록 정기적인 근무 시간을 주최할 때 큰 성공을 거두었습니다. 팀이 "지원 데스크 스타일" 회의로 바뀌지 않도록 의제나 특정 질문을 준비하도록 합니다.
• 명확한 프로세스 및 체크포인트: 정의된 프로세스의 중요성은 아무리 강조해도 지나치지 않습니다. 모든 사람이 알고 이해하고 따르는 명확한 프로세스가 있는지 확인하고 소프트웨어 개발의 코드 검토 및 병합 요청과 마찬가지로 품질을 보장하기 위해 정기적인 검토 지점을 포함하십시오.
• 분석가 임베드 : 물론 이것이 항상 가능한 옵션은 아니지만, 성공적인 팀이 분석 추적을 소유하고 PM의 데이터 탐색 및 분석을 돕기 위해 부분 또는 정규직으로 제품 팀에 데이터 분석가를 임베드하는 것을 보았습니다.
• 셀프 서비스 분석: PM과 조직의 다른 모든 사람이 쉽게 데이터 세트를 탐색하고 질문에 대한 답변을 신속하게 얻을 수 있도록 권한을 부여하는 것이 모범 사례라고 생각합니다. Amplitude는 이에 적합하며 회사 전체에서 높은 수준의 데이터 리터러시를 보장합니다.

알림: 좋은 PM은 SQL을 알 필요가 없습니다.

어쨌든 데이터를 직접 탐색할 수 없다면 이벤트 추적에 신경을 써야 하는 이유는 무엇입니까? 위의 마지막 항목을 확장하기 위해 모든 보고 및 데이터 분석을 담당하는 중앙 데이터 팀이 있는 회사를 보았습니다. 장점이 있지만 경험상 PM과 다른 사람들을 제한할 수 있으며 분석 추적이나 데이터 품질에 덜 신경을 쓸 것입니다.

PM 및 다른 사람들에게 Redash 또는 기타 SQL 기반 도구에 대한 액세스 권한을 부여하는 것은 PM이 셀프 서비스할 수 있도록 권한을 부여하는 것과 같지 않습니다. PM이 SQL을 알거나 배울 것이라고 기대하지 마십시오. 그것은 그들의 일이 아닙니다. 대신 사용하기 쉬운 UI와 도구 및 데이터 세트와 함께 사용할 수 있는 많은 교육을 통해 권한을 부여하십시오. 물론 SQL 지식에는 명백한 이점이 있으며 회사 전체에서 인재를 찾거나 교육할 수 있다면(제품, 마케팅, 고객 성공 등을 생각) 이를 작동시킬 수 있지만 명백한 단점과 한계가 있습니다.

PM이 셀프 서비스를 할 수 있는 경우 최신 릴리스와 같은 데이터를 탐색할 가능성이 더 큽니다. 데이터를 탐색하면서 데이터의 품질, 풍부함 및 가용성에 더 관심을 갖게 됩니다. 권한 부여 문화를 만들고 분석 추적을 중심으로 견고한 프로세스를 구축하면 행복한 PM, 행복한 분석가, 행복한 데이터 팀 및 행복한 개발자를 갖게 될 것입니다.

Amplitude가 도와드리겠습니다.

Amplitude는 데이터 팀, 제품 관리자 및 엔지니어가 분석 추적을 정의, 계측, 확인 및 협업하는 데 도움이 됩니다. 일관되지 않은 이벤트 이름 지정 및 추적 누락으로 인해 발생하는 데이터 품질 문제를 사전에 해결하고 추적의 진화를 관리하기 위한 워크플로우를 제공합니다.

우리는 제품 관리자가 추적 계획의 소유권을 갖고 팀 간의 협업 수준을 높일 수 있도록 권한을 부여합니다 . 회사에서 Amplitude를 사용해 보고 싶다면 지금 계정을 만들거나 당사 팀과 함께 데모를 예약하여 자세한 내용을 알아보십시오.