A/B Test에 대한 실용 가이드 - 13장 이벤트 측정 (Instrumentation) 정리

해당 글은 Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing 의 13장 Instrumentation의 내용을 읽고 정리한 것 입니다.

실험을 진행하기 전에 반드시 사용자와 서비스(웹, 앱 등) 사이에 발생하는 이벤트들을 기록할 수 있는 측정기가 있어야 합니다.

해당 장에서는 실험에서 어떤 데이터를 측정해야 하는지에 대해 이야기 하고 있습니다.

어떤 Data(event)를 수집해야 하지?

이벤트 측정은 Client와 Server 2가지 부분으로 나누어 이야기 할 수 있습니다.

Client-Side vs. Server-Side Instrumentation

Client Side

Client에서는 User가 하는 행동과 겪는 것들에 대해 초점을 두고 이벤트들을 수집(측정)해야합니다.

User actions

유저가 하는 행동과 그로 인해 겪는 상황을 이야기하며, 클릭이나 스크롤링, hover와 같은 액션, 화면 노출 여부 및 체류시간 등등을 의미합니다.

Performance

성능으로 인해 겪는 상황들을 이야기하며 대표적으로 TTI(Time to interactive)가 있습니다.

Errors & Crashes

오류로 인해 겪는 상황이며, 예상하지 못한 행동들도 생긴 오류, 웹의 경우 브라우저 별, 앱의 경우 디바이스, OS 버전 등으로 인해 생기는 에러들을 의미합니다.

Server Side

Server가 수행하는 작업들에 초점을 두고 수집을 해야합니다.

Performance

최적화는 얼마나 되어있는가와 같은 내용들을 수집합니다. 응답시간, 가장 오래걸리는 작업들은 어떤 것들이 있는지 등을 수집해야 합니다.

System response rate

요청 및 응답과 관련된 정보들을 수집해야 합니다. 몇건의 요청(Request)가 있었는지, 응답(Response)의 내용은 무엇이었는지? 만약 실패했다면 어떤 처리를 했었는지 등의 내용들이 해당 됩니다.

System information

서버와 관련된 전반적인 정보들 또한 수집해야 합니다. 오류 발생 빈도나 캐싱 적중률은 얼마나 되는지가 이에 해당합니다.

왜 Data(Event)를 수집해야 하지?

Client Side

사용자가 하는 행동과 겪는 상황을 직접적으로 볼 수 있기 때문에 매우매우 유용한 정보들 입니다.

그렇기에 많은 데이터들을 수집하면 할 수록 좋지만 고려(유의)해야 할 것 들이 있습니다.

이러한 데이터 수집은 사용자가 앱(서비스)을 사용하는데 전혀 상관 없는 Action이고 이러한 Action으로 인해 CPU, 네트워크, 배터리 리소스를 잡아먹게 됩니다. 즉, 무작정 많이 달게 된다면 앱이 무거워지게 되며 이로인해 로딩이 느려지거나 렉이 걸리는 등의 사용자 경험을 해치게 되고 이는 매우 치명적인 일 입니다.

아마존에서 퍼포먼스가 100 millisecond가 떨어졌을 때의 임팩트를 실험한 적이 있으며, 매출이 1% 감소하는 것을 확인함

퍼포먼스 외에도 Client에서는 외부의 영향을 받을 가능성이 매우 높아집니다. 예를 들면,

• 이벤트를 측정기(서버)에 전달하기 전에 종료
• 네트워크 문제로 인해 데이터가 손실되는 경우
• 유저가 의도한 행동 외에 예상하지 못한 행동들을 할 경우
• 날짜, 시간 등은 Client에서 임의로 변경 가능함

그렇기 때문에 Client의 데이터를 맹목적으로 신뢰할 수 없습니다.

Server Side

Server의 경우에는 사용자가 겪는 상황을 직접적으로 볼 수 없어 명확하지 않습니다.

하지만 Client와 다르게 시간을 임의로 변경하거나 데이터 손실 등과 같은 외부의 영향을 받지 않고, 내부에서 일어나는 상황과 그 상황이 발생한 이유에 대헤 더 세세하게 알 수 있습니다. (Client에서는 A버튼을 누르면 B화면이 뜬다 정도이지만, Server에서는 A를 눌렀을 때 요청 된 데이터, 해당 데이터를 어떻게 처리해서 응답 데이터를 내려줬는지 등을 통해 세세하게 알 수 있다.)

그래서 어떻게 Data(Event)를 수집해야 하지?

Client Side와 Server Side의 데이터를 엮어서 하나의 Stream을 만들어야 한다. (유저가 앱을 들어와서 화면이 뜨고 스크롤해서 버튼을 눌렀고, 서버에서 데이터를 처리하고 그에 맞는 화면이 떳다. 같이)

책에서는 클라이언트의 정보(국가, 언어, OS, 인터넷 환경), 사용자 별 상태(동의여부 (Opt in, out)), 서버 로그 들을 수집하고 쉽게 활용할 수 있게 결합할 수 있어야 한다고 적혀있다. 분산 되어있는 데이터들을 공통 키를 사용해 Join할 수 있게 하는 것이 중요하고, 이렇게 해야 클라이언트에서 특정 화면 노출 여부(확인 여부)를 알 수 있고, 서버에서 이 화면을 왜 봤는지에 대한 세세한 이유를 알 수 있다고 한다.

Data(Event)를 수집하는데 명심해야 할 것!

실험 분석에 있어 데이터 수집은 매우 중요하다. 적절한 데이터 수집이 없다면 장님이 비행기를 운전하는 것과 같다. 즉 올바른 가정으로 실험을 하고 있는 것인지, 실험이 잘 진행 되고 있는지 알 기 힘들다.

Data(Event)를 수집이 중요하지만 처음부터 개발자가 수집하는 것은 정말 어렵다. 시간이 많이 들기도하고, 서비스(유저가 접하는 것)에 영향을 주는 것이 아니다 보니 쉽게 Event까지 챙겨가는 것이 쉽지 않고, 그렇기 때문에 팀에 Data(Event)를 수집을 반드시 하는 문화가 만들어 져야 한다.

Data(Event)를 수집하는 문화를 만드는 Tip

수집 문화 확립

개발 해야 할 Spec의 한 부분으로 Event 수집을 포함해야 한다.

계기판이 고장나도 운전은 할 수 있지만 너무 위험한 것처럼 Event 수집이 없다면 해당 기능은 죽은 것과 다름 없다. 그렇기 때문에 기능의 일 부분으로 여기고 우선순위를 높게 가져가 반드시 챙겨야 한다.

테스트

개발 후 Event 수집 테스트에 투자해야 한다.

Pull Request를 요청하기 전, 개발 한 내용이 잘 동작하는지 확인 하는 것 처럼 Event가 잘 발생 하는지 확인해야 한다. 또한 Code Review 단계에서 리뷰어가 Event가 잘 달려있는지 또한 확인 해야한다.

모니터링

Monitor the raw logs for quality

Event에 문제가 생겼다면 해당 실험의 결과는 신뢰할 수 없다. 그렇기 때문에 항상 Event가 잘 수집되고 있는지 확인해야 한다.

Observations와 metrics에 특이점은 없는지 확인하는 도구가 있어야하고, 모니터링 해야한다. 문제가 생겼을 경우에 즉시 해결해야 한다.