서버 수집

행동 기록은 원래 전부 브라우저에서 보냈습니다. 화면에 스크립트 한 줄을 넣으면 버튼을 누른 사실이 분석 도구로 날아갔으니 개발 품이 거의 들지 않았습니다. 페이지덱도 결제 완료를 그렇게 심었습니다.

문제는 분기 매출을 맞춰 보는 자리에서 드러났습니다. 분석 도구의 결제 완료 이벤트는 1,840건인데 결제 데이터베이스의 승인 건수는 2,050건이었습니다. 210건이 비었습니다. 태오가 확인해 보니 원인이 셋이었습니다. 광고 차단 프로그램이 분석 도구 주소를 막은 경우, 결제 직후 화면이 넘어가면서 요청이 끊긴 경우, 그리고 모바일 네트워크가 잠깐 죽은 경우입니다.

빈 210건이 고르게 빠졌다면 비율로 보정해 쓸 수도 있었습니다. 그런데 차단 프로그램을 쓰는 쪽은 특정 사용자층에 몰려 있어서, 빠진 몫도 한쪽으로 기울어 있었습니다. 서버 수집은 이 지점에서 자리를 잡은 방식입니다. 기록을 남기는 곳을 사용자 기기에서 회사 서버로 옮기면 차단 프로그램도 네트워크도 끼어들 수 없고, 값을 사용자가 고칠 수도 없습니다.

어떤 이벤트를 서버로 옮길지 고르는 일부터 시작합니다. 전부 옮기지 않습니다. 절차는 다섯 단계입니다.

1. 옮길 이벤트를 고릅니다. 기준은 돈과 권한, 그리고 되돌릴 수 없는 상태 변화입니다. 결제 승인, 환불, 요금제 변경, 관리자 권한 부여가 여기 듭니다. 트래킹 플랜, 곧 어떤 행동을 어떤 이름으로 남길지 적어 둔 문서에 어느 쪽에서 보내는지를 칸으로 표시해 둡니다.
2. 기록 호출을 넣을 자리를 정합니다. 그 일이 실제로 끝난 지점이어야 합니다. 결제라면 카드사 승인 응답을 받고 데이터베이스 저장까지 끝난 다음입니다. 버튼을 눌렀을 때 보내면 실패한 결제까지 세어집니다.
3. 사용자 식별자를 함께 실어 보냅니다. 서버는 브라우저에 심어 둔 값을 모르니 로그인 계정 번호를 씁니다. 가입 전 행동과 이어 보려면 클라이언트가 쓰던 익명 식별자를 요청에 담아 넘겨야 합니다.
4. 전송을 사용자 요청과 분리합니다. 분석 도구가 3초를 응답하지 않을 때 결제 화면이 3초 멈추면 안 되니, 기록은 큐에 넣고 따로 보냅니다.
5. 중복을 막습니다. 전송 실패 시 재시도를 붙이면 같은 결제가 두 번 들어옵니다. 이벤트마다 고유한 키를 실어 보내고 같은 키가 오면 버리도록 해 둡니다.

3번과 5번을 건너뛴 기록이 나중에 가장 손이 많이 갑니다. 식별자가 없으면 결제 건수는 맞아도 누구의 결제인지 알 수 없고, 중복을 막지 않으면 매출이 실제보다 높게 잡힙니다.

맞는 자리는 돈과 권한이 걸린 사실, 그리고 서버만 아는 사실입니다. 결제 승인과 환불, 구독 갱신과 해지, 권한 부여가 앞쪽입니다. 뒤쪽은 사용자가 화면에 없는데 일어나는 일들입니다. 밤에 도는 배치 작업이 만료시킨 구독이나 외부 결제사가 웹훅으로 알려 온 정기 결제는 기기에서 보낼 방법이 없습니다.

한계는 셋입니다. 첫째로 화면 안에서만 일어난 일을 못 잡습니다. 어느 요금제 위에 마우스를 올렸다가 지나갔는지, 가입 양식을 어디까지 채우고 그만뒀는지는 서버까지 오지 않습니다. 이 몫은 클라이언트 수집이 맡습니다.

둘째로 심는 비용이 다릅니다. 클라이언트 쪽은 태그 관리 도구로 기획자가 직접 심을 수 있지만, 서버 쪽은 개발자가 코드를 고치고 배포해야 합니다. 이번 주에 확인하고 싶은 숫자가 있어도 다음 배포까지 기다립니다.

셋째로 화면 맥락이 자동으로 붙지 않습니다. 유입 경로, 리퍼러, 화면 크기, 브라우저 종류는 브라우저가 알고 서버는 모릅니다. 유입 경로별 결제 전환을 보려면 클라이언트가 그 값을 요청에 담아 서버로 넘기고, 서버가 그것을 이벤트에 붙여야 합니다. 그래서 실무에서는 둘 중 하나를 고르지 않습니다. 돈이 걸린 것은 서버에서, 화면에서만 일어나는 것은 클라이언트에서 보내고 사용자 식별자로 두 줄기를 잇습니다.

"결제 완료는 서버에서 보내죠. 클라이언트로 두면 차단되는 만큼 매출이 비어 보여요."

돈이 걸린 이벤트는 유실을 감당할 수 없으니 수집 위치를 옮기자는 제안입니다.

"이 이벤트 서버 수집이죠? 그러면 유입 경로가 안 붙어 있을 텐데요."

서버가 모르는 값이라, 채널별로 쪼개 보려면 따로 넘기는 작업이 필요하다는 지적입니다.

"서버 수집으로 옮기려면 개발 일정을 잡아야 해요. 이번 스프린트에는 안 들어갑니다."

기획자가 혼자 처리할 수 없는 작업이라 다른 개발 항목과 같은 줄에 세워야 한다는 뜻입니다.

페이지덱에서 이 구분은 새 기능의 기록을 정할 때 표로 정리됩니다. 지현이 기능마다 남길 이벤트를 적으면 태오가 그 옆 칸에 어디서 보낼지를 채웁니다. 요금제 업그레이드 완료는 서버, 요금제 비교 화면에서 어느 칸을 눌렀는지는 클라이언트입니다. 현우가 광고별 성과를 보려면 유입 경로가 필요하니, 가입 시점에 클라이언트가 가진 유입 값을 서버로 넘겨 계정에 한 번 저장해 둡니다. 이렇게 남긴 값은 외부 도구를 거치지 않고 쓸 수 있어 퍼스트파티 데이터가 됩니다.

서버로 옮기면 수집 유실이 사라진다고 읽는 경우가 많습니다. 차단 프로그램이라는 가장 큰 원인이 없어지니 그렇게 보일 만합니다. 그런데 서버 쪽에도 새는 자리가 있습니다. 큐가 넘쳐 버려진 이벤트, 새 코드 경로에 기록 호출을 빼먹은 배포, 재시도로 두 번 들어간 이벤트가 그렇습니다. 사라졌다고 믿으면 대조를 그만두게 되고, 그때부터는 어긋난 것을 알아챌 방법이 없어집니다. 페이지덱은 결제 데이터베이스 건수와 이벤트 건수를 매주 맞춰 보는 쪽을 택했습니다.

정확하니까 전부 서버로 옮기자는 판단도 자주 봅니다. 한쪽이 나으면 그쪽으로 통일하는 것이 깔끔해 보입니다. 하지만 서버로 다 옮기면 퍼널의 앞쪽이 통째로 비어 버립니다. 결제 건수는 정확해지는데 결제 화면까지 몇 명이 왔고 어디서 그만뒀는지를 모르게 되니, 결제가 줄었을 때 원인을 찾을 곳이 없어집니다.