클라이언트 수집

기록이라고 부를 만한 것이 서버 접속 기록뿐이던 시절이 있었습니다. 어느 주소가 몇 번 요청됐는지는 남았지만 그 화면을 연 사람이 안에서 무엇을 했는지는 한 줄도 남지 않았습니다. 요금제 안내 페이지를 열었다는 사실은 알아도, 그 사람이 연간 결제 쪽을 눌렀다가 되돌아갔는지 아래까지 훑고 그냥 닫았는지는 알 방법이 없었습니다.

그래서 화면을 고치는 회의는 늘 추측으로 흘렀습니다. 민서가 "결제 버튼이 아래에 묻혀 있어서 못 보는 것 같다" 고 말하면 태오가 "그 페이지 요청 수는 지난달이랑 같은데요" 하고 답했습니다. 한쪽은 화면 안에서 벌어진 일을 말하고 한쪽은 서버까지 닿은 것만 말하니, 같은 자료를 앞에 두고도 대화가 이어지지 않았습니다.

클라이언트 수집은 기록을 남기는 자리를 서버에서 화면으로 옮겨 이 공백을 메웁니다. 사용자의 브라우저나 앱 안에 짧은 코드를 심어 두고, 버튼을 누르거나 입력을 끝내는 순간 그 자리에서 이벤트 한 줄을 만들어 보냅니다. 이벤트는 누가 언제 무엇을 했는지를 적은 기록 한 줄을 말합니다. 서버에 요청이 가지 않는 행동도 이렇게 하면 남습니다.

붙이는 일은 코드 한 줄을 넣는 것으로 끝나지 않고 대개 다섯 단계를 밟습니다.

1. 무엇을 남길지 먼저 적습니다. 트래킹 플랜, 그러니까 어떤 행동을 어떤 이름으로 남길지 미리 정해 둔 문서를 만드는 단계입니다. 이 문서 없이 심기 시작하면 같은 행동이 화면마다 다른 이름으로 들어갑니다.
2. 분석 도구가 주는 조각 코드를 화면에 넣습니다. 웹이면 모든 페이지가 공통으로 불러오는 자리에, 앱이면 앱이 켜질 때 한 번 도는 자리에 넣습니다. 이 코드가 뒤에서 만들어지는 이벤트를 모아 도구 서버로 보내는 통로입니다.
3. 행동이 일어나는 지점마다 호출을 심습니다. 공유 버튼을 처리하는 코드 옆에 이벤트 이름과 함께 이벤트 속성을 붙여 보내는 한 줄을 넣는 식입니다. 이벤트 속성은 그 행동에 딸린 부가 정보로, 공유 방식이 링크였는지 이메일 초대였는지 같은 것을 담습니다.
4. 누가 한 행동인지 묶어 줍니다. 로그인한 사용자라면 사용자 식별자를 도구에 알려 주고, 로그인 전이라면 도구가 기기에 심어 둔 임시 값이 그 자리를 대신합니다. 이 단계를 빼면 이벤트는 쌓이는데 몇 명이 한 일인지는 세지 못합니다.
5. 도착했는지 확인하고 엽니다. 대부분의 도구가 방금 보낸 이벤트를 실시간으로 보여 주는 화면을 갖고 있으니, 직접 버튼을 눌러 보고 이름과 속성이 정한 대로 들어왔는지 봅니다. 여기서 확인하지 않고 넘기면 한 달 뒤에 숫자를 보다가 빈 것을 발견합니다.

3번을 매번 개발자에게 맡기지 않으려고 태그 매니저를 함께 쓰기도 합니다. 배포 없이 화면에서 추적 코드를 붙였다 떼는 도구인데, 급할 때 빠르다는 장점과 누가 무엇을 심었는지 관리가 흐트러진다는 단점이 같이 옵니다.

서버까지 가지 않는 행동을 보려는 자리에 맞습니다. 요금제 표를 끝까지 내려 봤는지, 검색창에 글자를 넣었다가 지웠는지, 결제 화면에서 카드 번호를 입력하다 멈췄는지는 서버에 아무 요청도 남기지 않으므로 화면에서 잡는 수밖에 없습니다.

한계는 셋입니다. 첫째, 일부가 도착하지 않습니다. 광고 차단 프로그램이 분석 도구로 가는 요청을 막고, 지하철에서 화면을 닫아 버리면 보내려던 이벤트가 사라집니다. 이 수집 유실이 곤란한 이유는 줄어든다는 사실보다 고르게 줄지 않는다는 데 있습니다. 차단 프로그램은 개발자 쪽 사용자에게 몰려 있어서, 그 무리의 행동만 옅어진 그림을 놓고 판단하게 됩니다.

둘째, 값을 믿기 어렵습니다. 화면에서 만들어 보내는 값이라 마음먹은 사람은 결제 금액이 백만 원인 이벤트를 손으로 만들어 보낼 수 있습니다. 그래서 돈이 걸린 사실은 이쪽에 맡기지 않습니다.

셋째, 화면 밖에서 벌어지는 일은 못 봅니다. 결제가 나중에 취소되거나 정기 결제가 한 달 뒤에 자동으로 걸리는 일은 사용자의 브라우저가 켜져 있지 않을 때 일어납니다.

그래서 실무에서는 둘 중 하나를 고르지 않습니다. 화면 안의 움직임은 클라이언트에서 보내고 돈과 계약에 관한 사실은 서버에서 보내도록 나눠 심습니다.

"이 버튼 클릭은 클라이언트에서 심어 주세요. 서버에는 안 남는 동작이라서요."

화면 안에서 끝나는 행동이니 수집 방식을 화면 쪽으로 정하자는 말입니다.

"결제 완료 수가 우리 집계랑 안 맞는데요. 클라이언트라서 그럴 거예요."

차단이나 이탈로 이벤트 일부가 도착하지 못했을 가능성을 먼저 의심한다는 뜻입니다.

"클라이언트 수치는 추세만 보고, 정산은 서버 기록으로 하시죠."

같은 항목이라도 판단 근거와 정산 근거를 다른 곳에서 가져오자는 제안입니다.

페이지덱이 요금제 화면을 고칠 때 이 방식이 먼저 붙었습니다. 지현이 어느 구간에서 사람들이 멈추는지 알고 싶다고 하자 태오가 화면을 연 시점, 연간 결제 탭을 누른 시점, 결제 버튼을 누른 시점 세 자리에 이벤트를 심었습니다. 일주일 뒤 숫자를 보니 탭을 누른 사람의 절반이 결제 버튼까지 가지 않았고, 민서가 그 구간의 화면을 다시 그렸습니다.

다만 같은 화면의 결제 성공 건수는 태오가 서버 쪽 기록으로 따로 냈습니다. 지현이 본 클라이언트 숫자가 매달 3퍼센트쯤 적게 나왔기 때문입니다.

클라이언트 수집을 붙이면 사용자의 모든 행동이 빠짐없이 남는다고 여기는 경우가 많습니다. 화면에서 직접 보내니 중간에 샐 데가 없어 보이는 것이 자연스러운 오해입니다. 실제로는 광고 차단과 네트워크 끊김, 심어 둔 코드가 도는 순서 때문에 5퍼센트 안팎이 늘 비고, 그 비는 몫이 무작위로 흩어지지도 않습니다. 이 사실을 모르고 쓰면 클라이언트 숫자를 매출 보고에 그대로 올렸다가 재무 쪽 집계와 어긋나 숫자 전체의 신뢰를 잃게 됩니다.

코드 한 줄만 넣으면 알아서 다 쌓인다는 오해도 흔합니다. 도구가 주는 안내문이 조각 코드 붙이는 일부터 보여 주니 그렇게 읽힙니다. 하지만 자동으로 남는 것은 화면을 열었다는 기록 정도이고, 무엇을 눌렀는지는 누군가 그 자리에 한 줄을 심어야 남습니다. 이걸 미루면 반년 뒤에 질문이 생겼을 때 돌아볼 과거 기록이 아예 없습니다.