이벤트 속성

Event Property

개념

행동 기록 한 줄에 함께 담기는 부가 정보로, 같은 행동을 어떤 경우로 갈라 볼지를 정하는 칸입니다.

등장 배경

행동 기록에 이름만 있던 시절에도 세는 일은 됐습니다. 이벤트는 누가 언제 무엇을 했는지 적은 한 줄이고, 같은 이름이 몇 줄인지 세면 그 행동이 며칠에 몇 번 일어났는지가 나왔습니다. 막히는 자리는 그다음이었습니다. 지현이 "공유가 늘었는데 어떤 공유가 늘었나요" 하고 물으면 답할 방법이 없었습니다.

그래서 한동안 쓰인 방법은 이름을 잘게 쪼개는 것이었습니다. document_shared_via_link 와 document_shared_via_email 을 따로 심는 식입니다. 두 갈래까지는 견딜 만했습니다. 여기에 문서 종류를 더하고 무료인지 유료인지까지 더하자 이름이 열두 개로 불어났고, 전체 공유 횟수를 보려면 열두 개를 손으로 더해야 했습니다. 갈래를 하나 더 얹는 순간 이름 개수가 두 배로 뛰는 구조였습니다.

이벤트 속성은 그 갈래를 이름에서 떼어 칸으로 옮긴 것입니다. 이름은 document_shared 하나로 두고, 공유 방식과 문서 종류를 그 줄에 딸린 칸으로 담습니다. 전체는 이름 하나로 세고 갈래는 칸으로 나눕니다. 갈래를 하나 더 얹어도 늘어나는 것은 칸 하나뿐입니다.

작동 방식

속성은 이벤트 한 줄에 붙는 이름과 값의 짝입니다. 공유 이벤트라면 share_method 라는 칸에 link 라는 값이 들어가는 식이고, 한 줄에 이런 짝을 여러 개 붙일 수 있습니다. 짝을 만들 때 정할 것이 넷입니다.

  1. 값의 종류 — 글자, 숫자, 참과 거짓, 여러 값의 목록 가운데 하나를 고릅니다. 종류를 고르는 기준은 나중에 그 값으로 무엇을 할지입니다. 문서 글자 수를 글자로 담으면 갈라 보기만 되고, 숫자로 담아야 평균과 합계를 낼 수 있습니다.
  2. 값의 가짓수 — 그 칸에 들어올 수 있는 값이 몇 종류인지입니다. 공유 방식처럼 서넛이면 갈라 봤을 때 읽을 수 있는 표가 나오지만, 문서 제목처럼 줄마다 값이 다르면 갈라 본 결과가 한 줄에 하나씩 늘어선 목록이 되어 아무것도 알려 주지 않습니다.
  3. 값 표기 통일 — 같은 뜻을 한 가지 표기로만 씁니다. 웹에서 link, 앱에서 LINK, 확장 프로그램에서 링크 가 들어오면 화면에는 세 줄로 갈라져 나오고 어느 것도 전체를 보여 주지 않습니다. 이름 짓는 방식을 통일해 둔 규칙인 네이밍 컨벤션은 칸 이름만이 아니라 값에도 적용합니다.
  4. 담기는 시점 — 속성은 그 일이 벌어진 순간의 사실이라서 나중에 바뀌지 않습니다. 3월에 무료 요금제로 공유한 줄은 그 사람이 5월에 유료로 바꿔도 계속 무료로 남습니다. 이 점이 유저 속성과 갈리는 자리입니다. 유저 속성은 사람에게 붙은 지금 상태라서 값이 덮어씌워집니다.

무엇을 붙일지는 기능을 만들기 전에 정합니다. 어떤 행동을 어떤 이름과 어떤 속성으로 남길지 미리 적어 둔 문서인 트래킹 플랜에 칸 이름과 들어올 수 있는 값까지 적어 둡니다. 나중에 채우는 것이 안 되기 때문입니다. 5월에 속성을 하나 추가하면 그 뒤로 쌓이는 줄에만 값이 들어가고, 4월까지의 줄은 빈칸으로 남습니다. 지난 분기와 비교하려면 속성이 있는 기간이 쌓일 때까지 기다려야 합니다.

쓰이는 곳

속성은 갈라 보기, 거르기, 더하기 세 가지 방식으로 쓰입니다.

  1. 갈라 보기 — 같은 이벤트를 속성 값별로 쪼개 나란히 놓습니다. 지난주 공유 1,000건을 방식으로 갈라 링크 복사 800건, 이메일 초대 200건이 나오면 늘어난 쪽이 어느 쪽인지 바로 보입니다. 지표 하나가 왜 움직였는지를 묻는 자리에서 가장 먼저 꺼내는 수단입니다.
  2. 거르기 — 조건에 맞는 줄만 남깁니다. 유료 팀에서 일어난 공유만, 또는 모바일에서 일어난 공유만 세는 식입니다. 같은 이벤트를 두고도 보는 사람마다 필요한 범위가 달라서, 숫자를 주고받을 때는 어떤 조건으로 걸렀는지를 함께 말해야 합니다.
  3. 더하기 — 숫자 속성을 합치거나 평균 냅니다. 결제 이벤트에 금액을 담아 두면 결제 횟수만이 아니라 매출과 건당 평균 금액이 같은 줄에서 나옵니다.

A/B 테스트처럼 두 안을 나눠 보여 주고 결과를 비교하는 실험에서도 이 칸이 기준이 됩니다. 어느 안을 본 사람인지를 속성으로 담아 두면 두 무리의 행동을 같은 이벤트 안에서 갈라 볼 수 있고, 담아 두지 않으면 실험이 끝난 뒤 누가 어느 안을 봤는지 되짚을 방법이 없습니다.

실무 용례

"이 이벤트에 요금제 속성도 같이 붙여 주세요."

무료와 유료를 갈라 보고 싶으니 그 칸을 함께 담아 달라는 요청입니다.

"그 속성은 값 종류가 너무 많아서 갈라 봐도 못 읽어요."

값이 거의 줄마다 달라 쪼갠 결과가 목록만 길어진다는 뜻입니다.

"속성 이름은 같은데 값이 두 가지로 들어와 있어요."

같은 뜻을 서로 다른 표기로 보내고 있어 한 줄로 합쳐 봐야 한다는 말입니다.

페이지덱에서 지표가 흔들릴 때 지현이 가장 먼저 하는 일은 그 이벤트를 속성별로 갈라 보는 것입니다. 지난주 공유가 30퍼센트 줄었다면 방식으로 갈라 링크 복사만 줄었는지, 기기로 갈라 모바일에서만 줄었는지를 봅니다. 이 단계에서 범인이 좁혀지면 그다음 대화는 구체적으로 흘러가고, 속성이 없어서 갈라 보지 못하면 30퍼센트가 왜 줄었는지를 놓고 추측만 오갑니다.

흔한 오해

속성은 붙일 수 있는 만큼 붙여 두는 게 이득이라고 생각하기 쉽습니다. 나중에 쓸지 모르니 남겨 두자는 판단이고, 한 줄에 칸을 더 넣는 일 자체는 비용이 들어 보이지 않습니다. 하지만 칸이 40개인 이벤트는 그중 무엇이 쓸 만한지 아무도 모르는 이벤트가 됩니다. 이름과 전화번호처럼 사람을 특정할 수 있는 값까지 습관적으로 담기기 시작하면, 분석 도구에 개인정보가 흘러 들어가 나중에 지우는 일이 훨씬 커집니다.

속성이 이름보다 덜 중요하다고 보는 것도 흔한 오해입니다. 이벤트 이름은 회의에서 함께 정하면서 속성은 개발할 때 알아서 넣는 팀이 많습니다. 실제로는 답을 주는 쪽이 속성입니다. 이름만 있으면 몇 번 일어났는지까지만 알 수 있고, 어떤 경우에 더 많이 일어나는지는 속성이 있어야 나옵니다. 속성 없이 반년을 쌓으면 그 반년치는 총계 말고 아무것도 답하지 못하는 기록으로 남습니다.

같이 보면 좋은 페이지

  • 이벤트 수집

    속성을 포함해 무엇을 어떻게 남길지 정하는 전체 과정을 봅니다

  • 이벤트

    속성이 붙는 그 한 줄이 어떻게 만들어지는지 봅니다

마지막 업데이트 2026-09-16