앱 애널리틱스 최소 설계: 이벤트 세 개와 유저 식별자

계측 없이 마케팅하면 무엇이 사라지는가

사라지는 것은 인과입니다. 광고비를 얼마 썼고 설치가 몇 건인지는 광고 콘솔과 스토어가 알려 줍니다. 그러나 설치한 사람이 앱을 열어 무엇을 했는지는 앱 안에서만 확인됩니다. 그 구간을 기록하지 않으면 어떤 채널이 실제로 쓰는 사람을 데려왔는지는 끝까지 추측으로 남습니다.

스토어 대시보드는 설치와 삭제, 평점, 국가별 분포를 보여 줍니다. 광고 콘솔은 노출과 클릭, 설치당 비용을 보여 줍니다. 둘 다 앱 바깥의 숫자입니다. 어떤 사람이 첫 화면에서 멈췄는지, 가입까지 갔는지, 핵심 기능을 한 번이라도 썼는지는 어느 쪽 화면에도 나오지 않습니다. 앱 안이 비어 있는 상태로 광고를 최적화하면 목표는 자동으로 설치 단가로 내려앉습니다. 값싼 설치를 잘 만들어 내는 캠페인이 이깁니다. 그 설치가 대부분 첫날에 사라지는 종류여도 보고서상으로는 성공입니다.

두 번째로 사라지는 것은 제품 논쟁의 기준입니다. 계측이 없으면 회의에서 오가는 근거가 체감과 인상으로 채워집니다. 온보딩이 길다는 주장과 짧아도 안 쓴다는 주장이 부딪히면 결론은 목소리가 큰 쪽으로 기웁니다. 화면을 고쳐도 나아졌는지 알 수 없으니 다음 개선의 순서도 정할 수 없습니다. 이런 상태가 몇 달 이어지면 팀은 개선을 멈추는 대신 기능을 계속 붙이는 쪽을 택합니다. 확인할 수 없는 개선보다 눈에 보이는 추가가 안전해 보이기 때문입니다.

세 번째 손실이 가장 큽니다. 계측은 소급되지 않습니다. 오늘 붙인 이벤트는 오늘부터 쌓입니다. 출시 직후 몇 주는 사람들이 제품을 처음 만나는 단 한 번의 구간인데, 그때 기록이 없으면 그 구간은 복원되지 않습니다. 나중에 파트너나 투자자가 초기 반응을 물어볼 때 내밀 자료도 남지 않습니다. 재현할 수 없는 데이터를 놓치는 손해는 광고비 몇 주치보다 큽니다.

현장에서 더 흔한 문제는 계측을 하지 않기로 결정한 경우가 아닙니다. 계측 설계를 지나치게 크게 잡았다가 결국 아무것도 붙이지 못한 경우입니다. 이벤트 목록이 마흔 개가 되면 개발 일정에서 뒤로 밀립니다. 밀린 채로 출시되고, 출시 후에는 손댈 사람이 없습니다. 붙였더라도 절반은 잘못된 위치에서 발화하고, 그 사실을 아무도 모른 채로 몇 달이 지나갑니다. 그래서 출발점은 완전한 설계가 아니라 확실히 살아남는 최소 설계여야 합니다.

최소 설계의 목표는 데이터를 적게 모으는 것이 아닙니다. 믿을 수 있는 숫자를 먼저 확보하는 것입니다. 믿을 수 없는 숫자 마흔 개보다 정의가 분명한 숫자 세 개가 의사결정에 훨씬 쓸모 있습니다. 세 개가 안정적으로 돌아가기 시작하면 그때부터는 늘리는 일이 쉬워집니다. 순서를 뒤집으면 대부분 처음으로 돌아옵니다.

이벤트를 세 개로 줄이는 기준

기준은 하나입니다. 그 숫자가 오르내릴 때 팀이 실제로 다르게 행동하는가. 이 질문을 통과하는 이벤트는 대개 셋으로 수렴합니다. 앱을 처음 연 순간, 핵심 가치를 한 번 경험한 순간, 그 경험을 다시 한 순간입니다. 획득과 활성화와 반복이라고 불러도 좋습니다.

첫 번째는 앱을 처음 여는 사건입니다. 대부분의 애널리틱스 도구가 첫 실행과 세션 시작을 자동으로 수집하므로 이 항목은 직접 정의할 일이 적습니다. 다만 도구마다 자동 수집 범위가 다르니, 무엇이 자동으로 들어오는지 먼저 확인하고 그 위에서 나머지를 설계하는 편이 낫습니다. 확인하지 않은 채 같은 사건을 손으로 한 번 더 붙이면 첫 화면부터 숫자가 두 배로 부풀어 오릅니다.

진짜 설계 작업은 두 번째에 있습니다. 활성화는 제품이 약속한 가치를 사용자가 처음 손에 쥔 순간입니다. 정의는 제품마다 다릅니다. 출결 관리 서비스라면 출결이 한 번 기록된 순간이 후보가 됩니다. 배우는 사람과 가르치는 사람을 잇는 매칭 서비스라면 상대에게 연결 요청이 실제로 전달된 순간입니다. 구인구직 서비스라면 지원이 접수된 순간입니다. 공통점은 화면을 봤다가 아니라 결과가 남았다는 데 있습니다. 기록이 생겼거나 상대에게 무언가 전달됐다면 그 사람은 제품을 구경한 것이 아니라 쓴 것입니다.

세 번째는 그 행동을 다시 한 사건입니다. 여기서 흔한 실수는 재방문용 이벤트를 따로 만드는 것입니다. 같은 행동에 이름을 두 개 붙이면 정의가 갈라지고 합계가 맞지 않습니다. 두 번째 이벤트를 그대로 다시 받고, 같은 사람인지 아닌지는 식별자로 구분하면 됩니다. 반복이라는 개념은 이벤트 이름이 아니라 사람 단위 집계에서 나옵니다. 그래서 세 번째 이벤트는 새 이벤트가 아니라 새 질문에 가깝습니다.

무엇을 빼는지가 무엇을 넣는지만큼 중요합니다. 버튼 탭, 화면 조회, 스크롤 깊이, 배너 노출, 토글 변경 같은 항목은 초기 목록에서 제외합니다. 이들은 나중에 특정한 질문이 생겼을 때 그 질문을 위해 붙이면 됩니다. 처음부터 넣으면 이름 규칙이 흔들리고, 검수해야 할 지점이 늘어나고, 릴리스마다 확인 비용이 붙습니다. 목록이 길어질수록 목록 전체가 방치될 확률이 올라갑니다.

세 개로 줄이는 작업은 기술 작업이 아니라 합의 작업입니다. 활성화의 정의를 한 문장으로 적고 기획, 개발, 마케팅이 같은 문장에 동의하는 순간 계측의 절반이 끝납니다. 그 문장이 없으면 나중에 같은 대시보드를 보면서 서로 다른 이야기를 하게 됩니다. 정의를 적을 때는 조건도 함께 적습니다. 취소된 요청은 포함하는지, 테스트 계정은 제외하는지, 실패한 시도는 어떻게 처리하는지까지 적어야 문장이 완성됩니다.

유저 식별자가 필요한 이유와 다루는 법

식별자가 없으면 세 번의 사건이 세 사람인지 한 사람인지 구분되지 않습니다. 반복은 정의상 같은 주체를 전제로 하므로, 식별자 없이는 재방문도 유지도 계산되지 않습니다. 다만 식별자는 개인정보와 곧장 맞닿습니다. 동의와 최소 수집을 전제로 다뤄야 하고, 요건은 지역마다 다릅니다.

실무에서 식별자는 두 층으로 나뉩니다. 하나는 도구가 앱 설치 시점에 자동으로 발급하는 익명 식별자입니다. 사람이 아니라 설치 단위에 붙기 때문에 앱을 지웠다 다시 깔면 다른 값이 됩니다. 다른 하나는 로그인한 계정에 붙는 식별자입니다. 기기를 바꿔도 따라옵니다. 두 층을 다 쓰는 이유는 로그인 전 행동과 로그인 후 행동을 하나의 흐름으로 잇기 위해서입니다. 로그인 시점에 두 값을 연결하는 처리를 넣지 않으면, 가입 전에 앱을 살펴본 기록이 가입 이후 기록과 끊어진 채로 남습니다.

계정 식별자로 무엇을 쓰는지가 이 절의 핵심입니다. 이메일 주소, 전화번호, 이름, 사번, 주민 성격의 번호를 그대로 쓰지 않습니다. 내부에서만 의미를 갖는 무의미한 값을 따로 만들어 씁니다. 이유는 단순합니다. 애널리틱스 시스템은 여러 사람이 열어 보고, 다른 도구로 내보내지고, 외부 대시보드에 연결되기도 합니다. 한 번 들어간 값을 전부 회수하기는 어렵습니다. 같은 원칙이 이벤트 파라미터에도 적용됩니다. 검색어, 메모 내용, 주소, 연락처처럼 사람을 특정할 수 있는 값을 파라미터에 담지 않습니다. 자유 입력 텍스트를 그대로 실어 보내는 습관이 사고의 가장 흔한 경로입니다.

동의는 계측의 시작 조건입니다. 동의를 받기 전에는 이벤트를 발화시키지 않고, 나중에 보내려고 쌓아 두지도 않는 편이 안전합니다. 동의 화면의 문구는 무엇을 어떤 목적으로 수집하는지 사람이 읽을 수 있는 말로 씁니다. 동의를 철회할 수 있는 경로도 앱 안에 둡니다. 철회했을 때 무엇이 멈추고 무엇이 남는지는 미리 정해 두어야 합니다. 철회 처리를 만들지 않은 앱은 문제가 생겼을 때 대응할 수단 자체가 없습니다.

최소 수집은 원칙이자 방어선입니다. 목적이 분명하지 않은 속성은 붙이지 않습니다. 정밀한 위치, 연락처 목록, 기기 광고 식별자는 그것으로 답하려는 질문이 명확할 때만 다룹니다. 저장 기간도 정합니다. 무기한 보관은 결정을 미룬 상태이지 정책이 아닙니다. 계정 삭제 요청이 들어왔을 때 애널리틱스 쪽 식별자를 찾아낼 수 있어야 하므로, 내부 계정과 분석용 식별자를 잇는 매핑을 어디에 어떤 형태로 두는지도 미리 정합니다. 요청을 받은 뒤에 찾기 시작하면 늦습니다.

법적 요건은 지역마다 다릅니다. 한국, 베트남, 유럽을 비롯해 각 관할이 요구하는 동의 방식과 통지 항목, 국외 이전 절차가 같지 않습니다. 앱 스토어 정책도 법과 별개로 자체 요구사항을 둡니다. 아동을 대상으로 하거나 건강, 금융처럼 민감한 범주를 다루는 앱은 추가 조건이 붙습니다. 이 글은 설계 원칙만 다루며 특정 조항을 단정하지 않습니다. 실제 적용 전에는 서비스 대상 지역의 요건과 스토어 정책을 확인하고, 필요하면 법률 검토를 거치는 편이 안전합니다.

중복과 누락을 막는 최소 규약

규약은 네 줄이면 시작할 수 있습니다. 이름을 한 방식으로 짓고, 발화 시점을 한 문장으로 정하고, 재시도와 화면 복귀에서 두 번 나가지 않게 막고, 네트워크가 끊긴 동안 유실되지 않게 처리합니다. 이 네 줄을 한 장짜리 표로 적어 코드와 같은 곳에 둡니다.

이름 규칙은 사소해 보이지만 뒤에 가장 오래 남습니다. 소문자와 밑줄만 쓰기, 대상과 동작 순서를 고정하기처럼 규칙 하나를 정하고 예외를 두지 않습니다. 도구마다 예약된 이름과 글자 수 제한, 파라미터 개수 제한이 다르므로 시작 전에 해당 도구의 문서에서 확인하고 확인한 범위 안에서 짓습니다. 기억으로 짐작해서 짓다가 나중에 이름을 바꾸면 그 시점 앞뒤 데이터가 갈라집니다.

가장 많은 사고는 발화 시점에서 납니다. 같은 이름 아래 두 가지 사건이 섞이는 경우입니다. 버튼을 누른 순간에 보낼지, 서버가 성공으로 응답한 순간에 보낼지 정해 두지 않으면 실패한 시도까지 성공으로 집계됩니다. 결과가 남는 행동은 성공 응답을 기준으로 잡는 편이 해석하기 쉽습니다. 시도 자체를 보고 싶다면 그것은 별도의 질문이며, 나중에 별도 이벤트로 붙이면 됩니다. 정의를 문장으로 적어 두면 몇 달 뒤 코드를 만지는 사람이 같은 판단을 반복하지 않습니다.

중복은 조용히 늘어납니다. 화면 복귀, 뒤로 가기, 백그라운드에서 돌아오기, 네트워크 실패 후 재시도, 사용자가 빠르게 두 번 누르기가 전형적인 경로입니다. 대응은 간단합니다. 하나의 사건에 고유한 키를 하나 만들어 붙이고, 같은 키로는 한 번만 보냅니다. 클라이언트에서 막기 어려운 경우에는 수집한 뒤 집계 단계에서 같은 키를 제거하는 방법도 있습니다. 어느 쪽이든 중복을 막는 지점이 어디인지 팀이 알고 있어야 합니다.

누락은 반대 방향의 문제입니다. 앱이 강제 종료되거나 네트워크가 끊긴 상태에서 발생한 이벤트가 사라지는 경우입니다. 많은 도구가 로컬에 잠시 담아 두었다가 나중에 보내는 방식을 씁니다. 다만 동작 방식과 보관 조건이 도구마다 다르므로 실제로 어떻게 처리되는지 확인하고 그 범위 안에서 기대치를 잡아야 합니다. 배치 전송 때문에 대시보드에 늦게 반영되는 현상은 결함이 아닙니다. 이 차이를 모르면 정상 동작을 버그로 오해하고 시간을 씁니다.

검수는 자동화보다 눈으로 하는 확인이 먼저입니다. 릴리스 전에 실제 기기에서 세 이벤트를 한 번씩 발화시키고 도구가 제공하는 실시간 확인 화면에서 들어오는지 봅니다. 계측 코드는 실패해도 앱이 멈추지 않기 때문에 아무도 모르는 채로 몇 달이 지나갑니다. 이름, 발화 시점, 파라미터, 담당자, 추가된 앱 버전을 적은 한 장짜리 이벤트 사전을 코드 저장소 안에 두고 이벤트를 바꿀 때 같이 고칩니다. 문서가 코드에서 멀어지면 반드시 낡습니다.

늘리기 전에 먼저 굳혀야 할 것

늘리는 조건은 시간이 아니라 상태입니다. 세 이벤트가 몇 주 동안 끊기지 않고 들어오고, 팀 전원이 그 숫자를 같은 뜻으로 읽고, 앱을 업데이트한 뒤에도 그대로 발화한다면 그때 늘립니다. 그 전에 늘리면 잡음만 커지고 아무도 대시보드를 열지 않게 됩니다.

첫 조건은 안정성입니다. 계측은 조용히 깨집니다. 화면 구조를 바꾸거나 라이브러리를 올리거나 조건문을 손대는 과정에서 이벤트가 사라져도 앱은 정상으로 보입니다. 릴리스마다 세 이벤트가 살아 있는지 확인하는 절차를 배포 체크리스트에 한 줄로 넣습니다. 주간으로 보는 숫자에서 갑자기 0에 가까운 구간이 생기면 사용자 행동이 바뀐 것이 아니라 계측이 끊긴 경우가 더 많습니다.

두 번째 조건은 해석의 합의입니다. 활성화의 정의를 문장으로 적어 팀이 같이 보는 곳에 붙입니다. 정의를 바꿔야 한다면 바꾼 날짜를 적고, 그 앞뒤 수치를 나란히 비교하지 않습니다. 정의가 달라진 두 구간을 하나의 추세선으로 보면 없는 변화를 본 것으로 착각합니다. 숫자를 늘리는 일보다 숫자의 뜻을 고정하는 일이 먼저입니다.

세 번째 조건은 질문의 존재입니다. 새 이벤트를 추가할 때는 그 이벤트로 답하려는 질문과, 답에 따라 달라질 행동을 함께 적습니다. 이 두 줄이 안 적히면 그 이벤트는 아직 필요하지 않습니다. 조건을 만족한 뒤 붙일 만한 것으로는 유입 경로 구분, 결제나 전환 시점, 이탈이 집중되는 단계, 비교 실험 정도가 있습니다. 각각 다른 비용을 부릅니다. 유입 경로는 광고 도구와 연동 작업이 필요하고, 결제는 실패와 환불 처리까지 설계해야 하며, 실험은 분석 인력의 시간을 지속적으로 씁니다.

여우비 인터랙션은 고객사 개발과 자체 제품 운영을 함께 합니다. 출결 관리 서비스 onSpots, 한국어 학습에서 배우는 사람과 가르치는 사람을 잇는 매칭과 맵핑 서비스 랭토리, 베트남 구인구직 서비스 Job Connect VN은 활성화의 정의가 서로 다릅니다. 같은 회사에서 만들어도 핵심 행동이 다르면 세 이벤트의 내용이 달라집니다. 이 글에 자사 제품의 계측 수치를 싣지 않은 이유도 같은 자리에 있습니다. 아직 공개할 만큼 정리된 숫자가 없고, 없는 숫자를 만들어 쓰지는 않습니다.

정리하면 순서는 이렇습니다. 활성화를 한 문장으로 정의하고, 세 이벤트를 붙이고, 익명 식별자와 계정 식별자를 연결하고, 개인 식별 정보를 파라미터에서 걷어내고, 중복과 누락을 막는 규약을 한 장으로 적고, 릴리스마다 확인합니다. 이 여섯 가지가 자리를 잡으면 그다음 확장은 어렵지 않습니다. 계측을 처음 붙이는 팀이 실패하는 이유는 대개 설계가 부족해서가 아니라 처음부터 너무 컸기 때문입니다.