Amplitude, 그리고 서비스를 데이터로 맵핑하기

데이터의 근본

서비스를 데이터로 맵핑한다는 것은

서비스를 데이터로 맵핑한다는 것은, 서비스 내에서 일어나는 일을 이해하기 쉽고 분석하기 쉬운 기록으로 남긴다는 것이다. 그리고 이러한 기록은 그 기록으로 무엇을 하고자 하는지에 따라 다양한 형태로 남겨질 수 있다. 그렇기에 서비스를 데이터로 맵핑한다는 것은 많은 부서들의 이해관계와 데이터를 다루는 사람의 철학이 들어가게 된다. 그렇다면 이런 뜬구름 잡는 소리 말고, 실제로 서비스를 분석하기 위해 데이터를 남길 때 어떠한 점들을 유의해야 할까? 사실 가장 중요한 점을 꼽자면은 아래와 같다

1. 서비스의 특성을 잘 반영해야 한다

2. 일관적 이어야 한다

3. 쉽게 이해되어야 한다

4. 유연해야 한다

언뜻 보면은 너무 모호한 이야기처럼 보이지만, 실질적으로 데이터를 다루다 보면 위의 4가지가 잘 이루어지지 않아서 데이터 자체가 거의 암호처럼 되어 있는 경우를 굉장히 많이 볼 수 있다. 그리고 이 4가지 고려사항을 한 문장으로 바꾸면 아래와 같이 축약할 수 있다

데이터는 모두가 쉽게 이해할 수 있는 룰을 따라 만들어져야 하고, 그렇게 만들어진 데이터를 통해 서비스를 쉽게 해석할 수 있어야 한다

Amplitude를 도입하며 알게 된 올바른 분석용 데이터 구조

그렇다면, 어떤 것들을 고려해야 되는지는 알겠고, 실제로 분석용 데이터 구조를 만들 때, 어떻게 만들어야 할까? 나 같은 경우 요번에 데이터 분석 도구인 Amplitude(앰플리튜드)를 회사에 도입하면서. 앰플리튜드가 유저들을 잘 분석할 수 있도록 해당 도구의 회사가 제공하는 "데이터 구조 가이드라인"을 따라 회사의 데이터 구조를 변경시켜야 하는 경우가 있었다. 그 가이드라인을 읽고 또 우리 회사의 기존 데이터 구조를 비교하면서 알게 된 것은, 분석용 데이터 구조는 설령 이름이 엄청 길어지더라도 명확해야 하고, 서비스의 특성을 잘 반영해야 하고, 또 해당 데이터를 통해 무엇을 분석하고자 하는지 명확한 방향을 가져야 한다는 것이었다. 좀 더 자세히 말하자면, 나는 우리 회사의 분석용 데이터 구조를 전면적으로 개편하면서 (사실 그냥 갈아 없는 수준이었다) 아래와 같은 생각의 단계를 거치고 난 후에야 데이터 구조를 본격적으로 정할 수 있었다

1. 우리 서비스(앱)는 어떤 구조로 이루어져 있는가?

2. 유저의 어떤 기록이 우리에게 중요한가?

3. 회사의 데이터 인프라는 어떤 형태의 데이터 구조를 감당할 수 있는가?

4. 어떻게 하면 더 쉽게 이해될 수 있는 형식으로 만들 수 있을까?

우리 서비스(앱)는 어떤 구조로 이루어져 있는가?

가장 중요한 것은 서비스 자체가 어떤 구조로 이루어져 있는가 이다. 물론 서비스가 무엇인지에 따라서 다 다르겠지만 요번의 경우 서비스가 "앱"이라고 해보자. 그러면 서비스는 크게 2가지로 이루어져 있다

1. 페이지 (콘텐츠를 나열하여 보여주는 판)

2. 버튼 (유저가 상호작용- 클릭, 스와이프..- 을 할 수 있는 버튼)

엄청 간단해 보이지만, 이 두 가지 개념을 잡는데 굉장히 많은 논의와 고민이 있었다. 유저가 앱에 들어오면 앵커가 되는 부분, 즉 웬만하면 사라지거나 아예 변하지 않는 서비스의 부분은 "페이지"이고, 그 페이지들을 연결하는, 언제나 변경되고 사라질 수 있는 것이 "버튼"이라고 개념을 잡고 나서야 분석용 데이터가 어떤 정보들을 어떤 형태로 보여주어야 하고 또 각 데이터가 어떤 특성을 가지는지 확실히 알 수 있었다. 사실 예제로 보여주면 확실 하지만, 회사의 자원 이기 때문에 보여줄 수 없다는 것이 참 아쉽다

유저의 어떤 기록이 우리에게 중요한가?

이렇게 분석 입장에서 앱이 어떤 구조로 되어 있고, 그 구조를 반영하기 위해 데이터가 어떤 형태를 가져야 하는지 정했다면, 이제는 유저의 어떤 기록들이 우리에게 중요한 기록인지 정해야 한다. 물론 유저의 모든 행동과, 앱이 유저의 행동에 따라 반응하는 모든 것들을 데이터로 기록할 수 있다면 좋지만, 그렇게 하면 기록되는 데이터가 폭발적으로 늘어나기 때문에 데이터를 기록할 때, 기록된 데이터를 저장할 때, 그리고 그러한 데이터를 불러올 때 굉장히 많은 리소스 (서버 비용 이라던가)가 들어가기 때문에, 웬만하면 유저를 분석할 때 중요한 기록부터 남기는 것이 좋다. 보통의 앱 서비스는 적어도 아래와 같은 기록(데이터)을 꼭 가지고 있어야 한다.

1. 앱 진입

2. 앱 종료

3. 로그인 / 회원가입

4. 장바구니

5. 상품 클릭

6. 구매

회사의 데이터 인프라는 어떤 형태의 데이터 구조를 감당할 수 있는가?

어떤 데이터를 어떻게 남길지 정했다면, 이제는 그 설계대로 서버에 데이터를 저장해도 되는가 고민해볼 차래이다. 보통의 분석용 데이터의 경우 아래와 같은 형태로 데이터가 이루어져 있다

데이터 이름 : A , 데이터 특징 1(파라미터) : a, 데이터 특징 2(파라미터) : b......

문제는 데이터를 저장할 때 사용하는 데이터 베이스의 형태와 (relationa db, non relational db.) 종류 (postgresql, big query...)에 따라서 해당 데이터가 몇 개의 파라미터를 가질 수 있는지, 데이터 이름은 최대 몇 자 인지 등이 정해 진다는 것이다. 즉, 아무리 설계를 잘했어도 그거를 받쳐줄 인프라가 되어 있지 않으면 헛것이 되기 때문에 회사의 데이터 인프라가 어떤지 고려해야 하는 것이다

어떻게 하면 더 쉽게 이해될 수 있는 형식으로 만들 수 있을까?

그리고 이제 마지만 단계만 남았다. 바로 이 데이터를 사용할 사람의 입장에서 이 데이터가 쉽게 이해가 될 수 있는지 생각해보는 것이다. 많은 경우 데이터 구조를 설계하는 사람이 데이터에 대해서 가장 잘 아는 사람이다 보니, "이 정도면 충분히 이해하겠지"라고 생각하고 데이터 이름을 축약하거나 이상한 형태로(보통 자신에게 가장 친숙한 이름으로) 만드는 경우가 많은데, 그러면 설계자 자신은 이해하기 엄청 쉽고 동시에 깔끔한 데이터 형태가 만들어지지만, 실제로 그 데이터를 사용하여 분석을 해보려는 기획자들 에게는 거대한 진입 장벽이 되어 다가오는 경우가 많다. 이것을 해결하기 위해서는 단 하나의 원칙만 명심하면 된다.

너무 길어지더라도, 최대한 명확히, 초등학생 이더라도 이해할 수 있도록 데이터 이름과 파라미터 이름을 정하는 것이다

결론적으로...

사실 가장 확실한 방법은 회사에서 분석용 데이터를 설계하며 다양한 삽질을 해보는 것이지만, 그런 기획가 많이 있는 것도 아니고, 있다고 하더라도 사실 설계보다 설계를 해야 한다는 필요성을 설득시키는 것이 더 많은 시간과 노력이 든다. 하지만 혹시라도 분석용 데이터를 설계할 경우가 있을 경우, 나중에 들어올 사람들을 위해서라도 위의 내용들을 참고하여 만들도록 하자!