페이지뷰처럼 대화를 추적하는 문제

Source: Dev.to

대화형 AI 제품에 이벤트 기반 분석이 전혀 적용되지 않은 이유와 대신 해야 할 일

페이지 뷰처럼 대화를 추적하는 문제

상상을 해보세요. 여러분은 AI 스타트업의 PM이고, 출시 후 6개월 차입니다. 월요일 아침에 대시보드를 열었는데 모든 것이… 괜찮아 보입니다.

• 세션 수가 전주 대비 20 % 상승했습니다.
• 평균 세션 길이는 4 분 30 초입니다.
• DAU가 상승하고 있습니다.

스크린샷을 찍어 투자자 업데이트 슬랙 채널에 올립니다.

그 다음 유지율을 살펴봅니다.

사용자는 나타났다가 대화를 나누고 사라집니다. 지표는 참여도가 높다고 말하지만, 비즈니스는 뭔가 심각하게 잘못됐다고 말합니다.

첫 AI 제품을 출시했을 때 아무도 알려주지 않는 사실: 여러분은 대화를 페이지 뷰처럼 추적하고 있었으며, 그래서 매일 아침 대시보드가 거짓말을 하고 있는 겁니다.

지표 대시보드를 바라보며 혼란스러워하는 사람
^ 월요일 아침에 숫자는 좋아 보이지만 유지율이 절벽처럼 떨어질 때마다 모든 AI PM이 겪는 상황

페이지뷰는 콘텐츠가 정적인 세계를 위해 만들어졌다

페이지뷰 메트릭은 1990년대 중반에 누군가가 이 것을 보았는가? 라는 질문에 답하기 위해 고안되었습니다. 그게 전부입니다.

• 신문이 기사를 인쇄한다.
• 당신이 그것을 열었나요? 클릭. 페이지뷰가 기록됩니다.
• 콘텐츠는 당신이 하는 행동에 따라 변하지 않습니다. 그저 그대로 존재합니다. 당신이 소비했든 아니든 말이죠.

이 사고 방식은 어디에나 퍼졌습니다: 클릭, 세션, 페이지 체류 시간, 이탈률, 페이지 깊이. 이 모든 것은 동일한 기본 가정 위에 세워졌습니다:

제품은 정적인 아티팩트이며 사용자는 그것을 탐색한다.
참여 = 소비. 클릭이 많을수록 = 더 많은 참여. 더 많은 참여 = 더 큰 가치.

그 가정은 25년 동안 유지되었습니다. 그리고 분석이 오늘날의 모습을 갖추게 만든 것이죠.

그 후 우리는 제품 자체가 사용자의 말에 반응하는 제품을 출시했습니다.

전체 전제가 무너졌으며, 대부분의 팀은 아직 이를 눈치채지 못하고 있습니다.

• 대화는 정적인 아티팩트가 아니다.
• 내부 구조를 가진 양측의 동적 교환이다.
• 의미는 순서에 살아 있습니다: 무엇을 물었는지, 어떻게 답했는지, 그 다음에 무슨 일이 일어났는지, 사용자가 실제로 원했던 것을 얻었는지 여부.

이 모든 것은 순진한 이벤트 스트림에서는 드러나지 않습니다.

Source: …

conversation_started와 conversation_ended를 기록할 때 놓치는 것

AI 제품을 웹 앱처럼 계측하면 이벤트 로그는 다음과 같습니다:

conversation_started   { "user_id": 123, "timestamp": "10:04:12" }
message_sent           { "user_id": 123, "turn": 1 }
message_sent           { "user_id": 123, "turn": 2 }
message_sent           { "user_id": 123, "turn": 3 }
conversation_ended     { "user_id": 123, "duration": "4m32s" }

괜찮아 보이죠. 이제 정확히 같은 로그를 생성하는 세 가지 전혀 다른 이야기를 생각해 보세요.

세 이야 모두 동일한 이벤트 로그를 생성하지만 결과는 완전히 다릅니다:

• Story A: 제품‑시장 적합.
• Story B: 품질 문제.
• Story C: 이탈 진행 중.

대시보드에는 4분짜리 “성공적인” 세션이 세 개 표시됩니다.

Surprised Pikachu
^ Amplitude에서 세 사용자가 모두 동일하게 보인다는 사실을 깨달은 나

이벤트 추적에서 도출되는 메트릭은 잘못된 것을 측정하고 있다

MAU, DAU, 세션 길이, 대화 깊이와 같은 메트릭은 모두 같은 가정을 공유합니다: 활동이 많을수록 가치가 높다. 이들은 참여도를 나타내는 대리 지표이며, 제품이 웹사이트였을 때는 참여도가 유용한 대리 지표였습니다.

대화형 AI 제품의 경우, 그 대리 지표는 특정 방식으로 깨집니다.

우리는 Agnost를 사용해 제품 전반에 걸쳐 수백만 건의 대화를 추적하고 있으며, 이 패턴은 일관됩니다: 가장 긴 세션 시간을 가진 사용자가 가장 만족하는 사용자는 아닙니다; 때로는 가장 좌절감을 느끼는 사용자일 수도 있습니다.

간단 비교

오른쪽 열은 대화 구조를 이해해야 합니다: 단순히 턴이 발생했는지 여부가 아니라, 어떤 종류의 턴이었는지, 사용자가 무엇을 시도했는지, 그리고 성공했는지를 파악해야 합니다.

올바른 사고 모델: 대화는 작업 시도이다

모든 것을 재구성하세요:

• 대화는 페이지 조회가 아닙니다.
• 전통적인 의미의 세션도 아닙니다.
• 대화는 작업 시도입니다.

사용자는 의도를 가지고 나타나 무언가를 달성하려 시도하며, 성공하거나 실패합니다.

질문은 “그들이 대화를 했나요?”가 아니라
“그들이 원했던 작업을 완료했나요?” 입니다.

지원 담당자를 평가하는 방법도 마찬가지입니다: 담당자가 연 티켓 수를 추적하지 않고, 해결한 티켓 수를 추적합니다.

대신 추적할 항목

요점

1. 대화를 페이지 뷰처럼 다루는 것을 멈추세요.
2. 활동 기반 프록시에서 결과 기반 지표로 전환하세요.
3. 작업 의도, 성공/실패, 품질 신호를 포착하도록 제품에 계측을 추가하세요.

그렇게 하면 대시보드가 매주 월요일 아침에 확인해야 할 진실을 마침내 알려줄 것입니다. 🚀

Conversation‑Native Analytics: Why the Shift Matters

대화가 제품이다. 여러분의 분석은 이를 반영해야 한다.

The Problem with Traditional Event‑Based Tracking

• 각 통화가 얼마나 오래 지속됐는지 추적하지 않는다.
• 고객 문제 해결 여부만 추적한다.
• AI 제품도 마찬가지다: 대화는 작업 완료 시도가 이루어지는 매개체일 뿐이며, 대부분의 대시보드는 여전히 이벤트(클릭, 페이지 뷰, 세션 길이) 에 초점을 맞추고 결과에는 집중하지 않는다.

When you make the shift from “event = success” to “conversation = success,” a lot of things become clearer:

• 짧은 대화는 훌륭한 결과(효율적인 해결) 또는 끔찍한 결과(사용자가 즉시 포기)일 수 있다. 상황이 어느 쪽인지 결정한다.
• 긴 대화는 깊은 참여를 나타낼 수도 있고 또는 좌절의 나선일 수도 있다. 역시 상황이 중요하다.

You need an analytics layer that understands which is which.

대화‑네이티브 분석이 실제로 어떻게 보이는가

이것은 가상의 이야기가 아닙니다. 원시 데이터 레이어는 이미 존재하지만, AI 팀을 위해 제품화되지 않았을 뿐입니다.

대화에는 구조가 있습니다:

1. Intent(의도) – 사용자가 달성하고자 하는 목표.
2. Sequence of attempts(시도 순서) – 각 턴이 그 의도를 해결하려고 시도합니다.
3. Outcome(결과) – 해결(또는 실패).

각 턴은 그 구조가 얼마나 잘 작동하고 있는지를 보여주는 증거입니다.

추적할 실용적인 신호

• Resolution signals(해결 신호)

  • Positive(긍정적):
    • 사용자가 원하는 것을 얻고 대화가 종료됨.
    • 종료 시 긍정적인 감정.
    • 이전 답변을 기반으로 한 후속 질문.
    • 사용자가 48 시간 이내에 관련 질문으로 다시 방문.
  • Negative (failure)(부정적·실패):
    • 사용자가 같은 질문을 세 번이나 다시 표현함.
    • 대화 중간에 이탈.
    • 흐름의 시작으로 즉시 돌아감.

• Repetition detection(반복 감지) – 같은 질문을 다르게 표현 → AI가 이해하지 못함 → 품질 실패. 평균 세션 길이로 가려지지 않고 메트릭에 표시되어야 합니다.

• Drop‑off by position(위치별 이탈) – 사용자가 대화의 어느 지점에서 포기하는가?

  • 예시: 대화의 40 %가 턴 3 이후 해결 신호 없이 종료 → 턴 3에 고칠 수 있는 구체적인 문제 존재.

• Intent clusters(의도 클러스터) – 사용자가 무엇을 하려는지에 따라 대화를 그룹화하고, 어떤 기능을 사용했는지에 따라가 아니라. 숨겨진 패턴을 드러냄(예: 지원 채팅의 30 %가 문서에 답이 없는 동일한 질문을 함).

None of this is magic. It’s just applying the right model to data you already have. The raw conversation data is there; the question is whether your analytics layer knows how to read it.

시각적 은유

“전체 대시보드가 당신에게 거짓말을 하고 있었다는 걸 깨닫고 대화‑네이티브 분석을 구축하는 중.”

Where This Is All Going

AI 제품으로 성공하고 있는 팀들은 하나의 습관을 공유합니다:

• 참여도 최적화를 멈추고 해결에 초점을 맞추기 시작했습니다.
• 성공을 세션 수준이 아니라 대화 수준에서 측정합니다.
• 추적 항목:
  • 작업‑완료 비율.
  • 첫 번째 턴 해결 비율.
  • 일반적인 대화에서 정확히 이탈되는 지점.

그들은 대화를 분석의 기본 단위로 다루는 도구를 채택했으며, 이벤트의 집합이 아니라 대화 자체를 중심에 두었습니다.

업계의 나머지는 여전히 MAU 차트를 스크린샷으로 찍으며 왜 유지율이 낮은지 고민하고 있습니다.

전환이 다가오고 있습니다. 대화형 AI는 10년 전 모바일이 새로운 웹‑분석 패러다임을 만든 것처럼 새로운 분석 패러다임을 강요하고 있습니다. 이를 가장 먼저 마스터하는 팀은 제품 품질은 물론, 이탈 지표가 나타나기 전 문제를 진단하고 해결하는 데 의미 있는 경쟁 우위를 확보하게 될 것입니다.

마무리

• 핵심 제품 루프가 대화라면, 핵심 분석 기본 요소도 이벤트가 아니라 대화여야 합니다.
• 이벤트 기반 추적은 제품이 실제로 작동하는지 거의 알 수 없는 숫자만 제공합니다 (영화 프레임을 세는 것을 생각해 보세요).
• 대화 = 단위.
• 해결 = 메트릭.
• 작업 완료 = 최적화 목표.

그 외 모든 것은 잡음에 불과합니다.

Agnost는 바로 이 문제를 해결하기 위해 만들어졌습니다: 대화형 제품을 위해 처음부터 설계된 분석 도구로, 추측을 멈추고 확신을 가질 수 있습니다.
👉 여기서 Agnost 사용해 보기

TL;DR

이벤트 기반 분석은 대화가 발생했는지 추적합니다.
대화형 네이티브 분석은 그 대화가 작동했는지 추적합니다.
두 번째 것이 필요합니다.

읽는 시간: ~7 분