"고객은 우리가 가장 잘 알죠" — 대시보드가 있는데도 확신이 없는 이유

"그래도 고객 데이터는 꽤 잘 보고 있지 않나요?"

데이터 이야기를 하다 보면 꼭 이 말이 나온다. 여기에는 약간의 안도감이 섞여 있다. 고객 데이터의 변화는 놓치지 않고 보고 있으며, 맡은 일을 제대로 하기 위해 나름의 노력을 올바른 과정으로 수행하고 있음을 표현하려는 것이다.

그런데 '고객 데이터'라고 보고 있는 것이 정말 '고객의 데이터'인가.

되묻는 질문: 그 '고객'은 누구인가

이 질문을 받을 때마다 바로 대답하지 않고 이렇게 되묻는다.

"우리가 알고 있다는 그 '고객'은 어떤 사람인가요?"

한 조직 안에서 고객은 여러 개의 지표로 존재한다.

팀	그들에게 '고객'이란
마케팅	유입된 사용자
제품	특정 기능을 사용하는 사용자
운영	문의와 불만을 남긴 사용자

각 팀이 다루는 데이터는 고객을 지칭하는 말로 모두 맞다. 하지만 묘하게도 같은 사람을 말하고 있는 것 같지 않다.

"우리 서비스로 유입되어(마케팅), 특정 기능을 사용하고(제품), 사용 중에 문의와 불편함을 남겼다(운영)고 하면 그를 '고객'이라고 말할 수 있는 것인가?"

고객은 있는데, '서비스 관련 고객의 이야기'는 없었다.

대시보드에는 고객 데이터가 넘친다

DAU, MAU, 전환율, 이탈률, 재방문율, 불만 유형 TOP5.

그런데 이 모든 데이터를 다 보고 나서도 아래 질문에는 답하기 어렵다.

"이 사람은, 왜 우리 서비스를 쓰기 시작했고, 왜 지금은 덜 쓰고 있을까?"

숫자는 많았지만 고객별 서비스 사용 경험에 관한 이야기는 찾기 어려운 구조였다.

그럴 수밖에 없다. '고객 행동 데이터'의 책임 소재가 불명확하고, 그로 인해 수치상의 변화에만 예민할 뿐이다. 데이터 변화의 원인이나 다른 데이터와 어떤 변화를 주고받는지에 대해서는 관심이, 아니 인지가 없어 보였다.

회의실이 조용해지는 순간

회의 중에 대표가 이런 질문을 던진 적이 있다.

"이번 이탈, 원인은 뭘로 보세요?"

회의실이 잠시 조용해졌다. 조금 더 침묵이 지나자, 아무 말이라도 해야 하는 분위기라고 느꼈는지 각자의 생각이 나왔다.

• "기능 복잡도가 높아서 고객이 어렵다고 느껴서 이탈한 것일 수도 있고요."
• "마케팅 메시지가 과장됐다고 느껴서, 고객의 기대와는 달라서 그럴 수도 있고요."
• "우리와 경쟁 관계에 있는 모 서비스의 영향도 무시할 수 없는 것 같습니다."

모두 가능성 있는 이야기였다. 그러나 그 답들을 들으며 든 생각은 이것이었다.

"우리는 원인을 '알고' 있는 게 아니라, '추측'하고 있구나."

각자가 자신이 관리해야 하는 데이터에 충실한 구조에서는, 아무리 종합해도 답할 수 없는 질문이다. 결국 '자신이 알고 있는 범위' 안에서 답변하게 된다. 그리고 그런 이야기는 회의에 참석한 모두가 할 수 있는 말이다.

데이터는 많은데 왜 확신이 없을까

"우리는 고객이 아니라, 수집 가능한 데이터를 수집한 것이다."

고객 행동 데이터도 있고, VOC도 있고, 정량 지표도 충분하다. 그런데도 고객 이야기를 하다 보면 대부분의 문장이 이렇게 끝난다.

• "~인 것 같습니다"
• "~일 수도 있죠"
• "경험상으로는요"

이건 데이터가 없어서가 아니다. 데이터가 '고객의 흐름'으로 연결되어 있지 않기 때문이다.

무엇이 필요한가

정확히는 고객의 경험 경로와 과정에 맞춰 고객을 이해하고 파악하기 위한 데이터 수집 장치가 있어야 한다.

1. 수집된 데이터를 고객 데이터와, 고객·서비스 간 거래 과정상 데이터로 분류한다
2. 어떤 고객 타입(층)이 서비스 내에 존재하는지 확인한다
3. 그중 어떤 고객 타입을 확보·육성하는 것이 현 상황에 가장 적합한지 전략적 목표를 세운다
4. 이를 달성하기 위한 계획과 실행을 이어간다

그러나 이런 방식으로 '고객 데이터를 통해 일할 수 있는 구조'를 짜본 적도, 그렇게 운용하는 서비스를 본 적도 없기 때문에 고객 이탈에 현명하게 대처하지 못한다.

그 시작이 되는 질문은 이것이다.

"고객이 누구이고, 왜 우리 서비스를 이용하는가."

여기서부터 스스로 떳떳하게 답할 수 있게 준비해야 한다.

고객은 '지표의 묶음'이 아니다

많은 조직이 고객 데이터를 '고객 행동 데이터' 기준으로 나눠 관리한다.

영역	담당
유입	마케팅
사용	제품
불만	운영

각각의 데이터는 자기 영역 안에서는 잘 관리된다. 그러나 이 구조를 보며 남긴 메모는 이것이었다.

"고객은 나뉘어 있지 않은데, 데이터만 나뉘어 있다."

그래서 우리는 고객을 이해한다고 느끼지만, 실제로는 각자의 시선으로 고객의 일부만 보고 있을 뿐이다.

"장님 코끼리 다리 만지기" 방식으로는 내가 만지는 것이 코인지, 다리인지, 심지어 코끼리인지도 모를 수 있다. 고객이라는 코끼리가 있다면, 그들이 우리를 스치고 갈 때를 모두 데이터로 기록하고 관리할 뿐이고, 그게 무엇이었고 왜 스쳐갔는지에 대한 답은 전혀 알 수 없게 된다.

실무 정리

첫째, "고객 데이터를 보고 있다"와 "고객을 알고 있다"를 구분한다. 이 글 전체의 출발점이다. 수집 가능한 데이터를 수집한 것과 고객을 이해한 것은 다르다.

둘째, 팀별 '고객' 정의를 한자리에 놓고 비교한다. 마케팅의 유입 사용자, 제품의 기능 사용자, 운영의 불만 제기자가 같은 사람인지 확인하는 것만으로 문제가 드러난다.

셋째, "왜 덜 쓰게 됐는가"에 답할 수 있는지로 자가 진단한다. DAU·전환율·이탈률을 다 보고도 이 질문에 답할 수 없다면 데이터가 흐름으로 연결돼 있지 않은 것이다.

넷째, 회의에서 "~인 것 같습니다"의 빈도를 센다. 추측 화법이 반복된다면 데이터 부족이 아니라 구조 부재의 신호다.

다섯째, 고객 타입 분류를 먼저 하고 목표를 세운다. 어떤 고객층이 존재하는지 확인한 뒤 어떤 층을 확보·육성할지 결정하는 순서다. 지표 개선을 목표로 삼는 것과 다르다.

여섯째, 데이터 소유권을 채널이 아니라 여정 기준으로 재배치한다. 유입·사용·불만이 각각 다른 팀에 묶여 있는 한 고객은 계속 조각으로 남는다. 조직 구조가 지표 통합을 막는 같은 유형의 문제는 소셜 인사이트가 의사결정자에게 닿지 않는다 — 93%가 중요하다는데 36%만 쓴다에서 다뤘다.

일곱째, 귀속과 인과를 구분한다. 이탈 원인을 지표에서 읽어내려는 시도가 실패하는 이유는 어트리뷰션과 인크리멘털리티는 다른 질문에 답한다 — 둘 다 필요한 이유와 같은 구조다.