분석 추적을 지속적인 협업 프로세스로 전환하는 방법

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

우리 모두는 디지털 제품 및 서비스를 구축하는 모든 조직이 데이터를 수집한다는 것을 알고 있습니다. 또한 단순히 데이터를 수집하는 것이 실제로 데이터를 효과적으로 사용하는 것과는 다르다는 것도 알고 있습니다. 강력한 툴킷의 지원을 받는 놀라운 추적 계획이 있더라도 한 가지 핵심 사항인 협업에 시간을 할애하지 않으면 전략이 실패할 것입니다.

분석은 데이터 기반 회사의 모든 사람을 감동시킵니다.

제품의 새로운 기능을 구축하는 것에 대해 생각해 보십시오. 여기에는 두 가지 주요 고려 사항이 있습니다. 이 기능이 가져올 새로운 데이터 요소는 무엇이며 해당 데이터 요소의 대상은 누구입니까? 글쎄요, 진정으로 데이터 기반 의사 결정을 내리고 싶다면 거의 모든 사람 이 고객 데이터의 청중이 될 것입니다.

분석 추적과 관련된 주요 이해 관계자는 모두 도메인 지식과 기술 노하우의 건전한 혼합인 스토리에 고유한 아이디어와 전문 지식을 제공합니다. 우리는있어:

• 임원/리더십
• 제품 관리자
• 분석가/데이터 팀
• 개발자

이러한 각 팀에는 고유한 작업과 목표가 있지만 궁극적으로 동일한 추적 계획에서 작업하게 됩니다.

팁 : 요리사가 너무 많으면 악몽이 될 수 있습니다. 이 게시물을 읽고 누가 추적 계획을 소유 해야 하는지 자세히 알아보세요.

이러한 팀이 분석에 대해 서로 협업하는 방법.

임원/리더십

가장 높은 수준의 이벤트 추적 보기를 원하는 팀부터 시작하겠습니다. 새 기능을 구축할 때 경영진은 이 새 기능의 목표가 무엇인지, 성공을 측정하는 데 어떤 메트릭이 사용될 것인지에 대해 가장 관심을 가질 것입니다.

즉, 리더십 아래에서 작업하는 팀은 고품질 보고를 수행할 수 있는 장비를 갖추어야 합니다. 훌륭한 리더십 팀은 직감에 기반하여 회사의 미래에 대한 중요한 결정을 내리기를 원하지 않을 것입니다. 그들은 효과가 있는 것과 그렇지 않은 것에 대한 확실한 증거를 원할 것입니다.

이 팀의 주요 협업 행동:

• 경영진은 조직 전체에서 협업을 장려하고 데이터 기반 의사 결정의 가치를 이해하는 문화를 조성하기 위해 최선을 다해야 합니다.
• 데이터에 기반한 의사 결정을 통해 탄생한 성공을 축하합니다.
• 조잡하게도 관리자가 우수한 분석 추적에 관심이 없다면 관리자는 왜 그래야 할까요? ‍

제품 관리자

제품 관리자는 귀사의 제품을 잘 알고 있으며 제품이 시장/산업에서 어떤 위치에 있는지 알고 있습니다. 그들은 이 새로운 기능을 제공할 책임이 있으므로 경영진이 관심을 갖는 메트릭을 추적하려는 실제 이벤트로 전환하는 방법을 모색할 것입니다. 이 새로운 기능에 대한 신뢰할 수 있는 보고서를 작성하려면 이벤트 추적이 처음부터 기본 제공되어야 합니다.

제품 관리자는 많은 도메인 전문 지식으로 무장하고 있지만 추적 계획 자체를 정의하는 데 필요한 기술이 없을 수 있습니다. 이는 작업을 완료하기 위해 다른 팀과 협력해야 함을 의미합니다. 훌륭한 제품 관리자는 추적하려는 이벤트 목록을 지시할 가능성이 적고 그 결과로 완벽한 보고를 기대합니다. 대신 추적 계획을 구현하고 보고서를 작성하는 팀인 분석가 및 개발자와 가능한 사항에 대해 논의하고 동의할 수 있습니다.

따라서 제품 관리자는 어떤 메트릭이 중요한지 알지만 이를 추적 가능한 이벤트로 전환하기 위해 다른 사람에게 의존할 수 있습니다. 그들은 데이터에 대해 올바른 질문을 하고 A/B 테스트 시기를 결정하고 적절한 피드백 루프를 생성하는 데 도움이 될 것입니다. 즉, 이전 결정의 성과를 보고 이를 반복합니다.

이 팀의 주요 협업 행동:

• 추적 중인 이벤트와 그 이유를 분석가와 정기적으로 확인하고 분류 및 명명 규칙을 통해 모든 사람이 동일한 페이지에 있도록 합니다.
• 개발자와 협력하여 추적 계획에 어떤 변경 사항을 구현해야 하는지, 주어진 인프라에서 이러한 변경 사항이 가능한지 여부 및 소요 시간을 결정합니다.
• 고품질 보고서로 리더십에 피드백을 제공하는지 확인

애널리스트

데이터 분석가 팀은 보고를 위한 회사의 중앙 허브와 같습니다. 그들은 원시 데이터를 먼저 손에 넣는 사람들일 가능성이 높습니다(아마도 유일한 사람들일 것입니다). 그들은 데이터를 결합, 모델링 및 시각화하기 위해 노력할 것입니다. 데이터를 통찰력으로 바꾸는 데 도움이 됩니다.

분석가 팀에 대한 중요한 참고 사항 : 그들은 조직 리소스, 즉 데이터와 관련된 것이 필요할 때 "질문할 사람"으로 간주되어서는 안 됩니다. 이 경우 분석가는 실제로 인사이트를 구축하고 의미 있는 보고서를 생성하는 대신 다른 팀의 일일 요청을 이행하는 데 자신의 역량을 사용할 수 있습니다.

분석가의 공동 작업 프로세스의 일부는 다른 팀이 가능한 한 많은 셀프 서비스를 수행할 수 있도록 하는 것입니다. 이에 대한 기본적인 예는 제품 관리자 및 마케팅 담당자와 협력하여 Tableau와 같은 도구에 사전 정의된 쿼리를 구축하여 버튼 클릭만으로 가장 많이 묻는 질문에 대한 답변을 얻을 수 있도록 하는 것입니다. 제품 및 마케팅 팀은 또한 Amplitude와 같은 셀프 서비스 디지털 분석 플랫폼을 사용하여 자체적으로 차트를 작성하고 고객 행동을 분석할 수 있습니다.

이 팀의 주요 협업 행동:

• 제품 관리자와 협력하여 데이터 이면에 있는 사람들에 대해 더 많이 이해합니다. 최종 사용자에 대해 많이 알지 못해도 추상적 데이터로 작업할 수 있지만 이 데이터가 중요한 이유를 더 잘 이해한다면 더욱 효과적일 것입니다.
• 어떤 질문이 데이터를 요청하는 데 가장 도움이 되는지, 다른 팀이 추적하기를 원하는 것은 무엇인지에 대한 도전적인 대화를 촉진합니다(예: 팀이 필요한 것보다 더 많은 데이터를 수집하도록 요청하는 경우 언제 반발해야 하는지 파악).

개발자

물론 개발자는 실제로 제품을 구축하여 추적 계획을 구현하는 사람입니다. 기술적으로 말하면 소프트웨어 엔지니어는 자신이 속한 산업이나 최종 사용자 행동에 대해 많이 알 필요가 없습니다. 이것은 전반적으로 사실이 아니며 개발자가 분석에 관심이 없다는 가정으로 이어졌습니다.

실제로 엔지니어링 팀은 체계화된 협업 프로세스가 없다면 의미 있는 방식으로 분석에 참여하는 데 어려움을 겪을 수 있습니다. 새 기능을 구축할 때 추적할 이벤트가 포함된 스프레드시트를 받는 것은 작업 흐름에 막대한 지장을 주기 때문에 실망스러울 수 있습니다. IDE, 스프레드시트 및 Jira 티켓 간에 전환하는 것은 번거롭고 매우 쉽게 오류와 불일치로 이어집니다.

좋은 개발자는 자신이 만든 제품의 성능에 훨씬 더 관심을 가질 가능성이 높습니다. 또한 제품이 실제로 어떻게 작동하는지 누구보다 잘 알고 있으므로 가장 효과적인 방법으로 추적 계획을 구현할 수 있는 능력이 가장 뛰어납니다.

이 팀의 주요 협업 행동:

• 제품 관리자가 제품 인프라의 한계, 추적이 적절한 시기와 위치, 구현에 걸리는 시간을 이해하도록 합니다.
• 분석가와 긴밀히 협력하여 데이터 및 분석 파이프라인을 구축하고 모든 것이 의도한 대로 진행되도록 합니다.
• 다른 모든 팀이 이벤트를 효과적으로 추적하려면 나중에 생각하는 것이 아니라 처음부터 기능에 추적 기능을 구축할 시간이 필요하다는 점을 이해하도록 돕습니다.

분석 추적에 대한 협업 촉진

팀이 분석 추적에서 협력할 수 있는 방법에 대한 폭넓은 이해를 통해 협력 프로세스 개발을 시작하기가 더 쉬워질 것입니다. 모든 사람이 동일한 제품을 구축하고 유지 관리하기 위해 노력한다면 팀 간 커뮤니케이션이 매우 중요할 것임이 분명합니다.

제품의 백엔드에서 핵심 설계 포인트 로 분석에 대해 생각해 보십시오. 기능을 제공한 후에 추가하는 것이 아니라 SDLC의 필수 부분입니다.

특히 기술 산업의 많은 회사는 이미 Jira, Slack, 물론 Amplitude와 같은 협업 및 지식 공유 도구를 사용하는 데 익숙할 것입니다. 조직에서 더 강력한 협업 프로세스를 채택하는 데 열정적이라면 기꺼이 사례를 구축 하는 것이 좋습니다. 새로운 프로세스에 대한 동의를 얻는 것이 종종 가장 어려운 부분입니다.

바퀴를 재발 명할 필요가 없습니다. 이미 작동하는 기존 프로세스를 적용합니다.

종종 새로운 프로세스를 채택하는 것(예: 분석에 대한 효과적인 협업)은 기술과 거의 관련이 없으며 문화 와 관련이 있습니다. 분석과 관련하여 지식은 한 사람이나 팀에 존재하지 않습니다. 모든 사람이 협력하여 데이터를 최대한 활용해야 합니다.

중요한 점을 알지 못하는 한 아무도 새로운 프로세스를 채택하지 않는다는 점에 유의해야 합니다(아무리 좋은 프로세스라도). 실질적으로 말하자면, 새로운 프로세스에 대한 회사 전체의 동의를 얻을 수 있는 좋은 방법은 해당 프로세스를 기존의 다른 프로세스와 비교하여 해당 프로세스의 가치를 입증하는 것입니다. 몇 가지 예:

GitHub: 소프트웨어를 구축하는 거의 모든 사람/회사/조직이 GitHub를 사용한다고 해도 과장이 아닐 것입니다. 이것은 매우 우아하지만 하드 코딩된 프로세스입니다. 작성된 모든 코드 조각은 분기, 커밋 및 병합의 대상입니다. 따라서 Github는 실제로 도구라기보다는 프로세스에 가깝습니다. 모든 사람이 사용하지 않는다면 작동하지 않을 것입니다.

Figma: 원활한 팀 간 협업을 완벽하게 보여주는 도구입니다. Figma를 사용하면 제품 디자이너가 모든 요소가 어떻게 결합되는지 명확하게 보여주는 프로토타입을 개발자에게 전달할 수 있습니다. 팁: Figma에서 진폭 이벤트 플래너를 사용하십시오.

Amplitude가 협업을 지원합니다.

분석을 위해 Amplitude의 데이터 거버넌스 기능을 GitHub로 생각하면 유용합니다. Amplitude는 기술 능력에 관계없이 모든 주요 이해 관계자가 참여할 수 있는 이벤트 계획과 관련하여 투명하고 감사 가능한 프로세스를 촉진합니다.

가장 좋은 프로세스는 사용자가 눈치채지 못하는 프로세스입니다. 우리는 개발자 도구를 사용하여 누구의 워크플로우도 중단되지 않도록 하여 엔지니어가 형식이 안전한 오픈 소스 SDK, CLI 및 CI/CD를 사용하여 분석 추적을 쉽고 정확하게 구현할 수 있도록 합니다. 완성.

Amplitude는 가장 중요한 협업 플랫폼으로, 분석을 위한 신뢰할 수 있는 정보 소스를 시행합니다. 이것은 데이터를 소비하는 사람들이 데이터를 신뢰할 수 있다는 것을 안다 는 것을 의미합니다. 새로운 협업 프로세스에 대한 상당한 동의를 얻었다면 Amplitude가 확실히 이를 지원하는 역할을 할 수 있습니다. 지금 무료 데모를 요청하고 탐색을 시작하십시오.