맞춤 측정기준 등록해 매개변수를 보고서에 올리기

그 값이 무엇을 설명하는지로 정합니다. 이벤트 하나를 설명하는 값이면 이벤트 범위입니다. 문의 유형, 눌린 버튼 이름, 본 상품의 분류가 여기에 해당합니다. 사람을 설명하는 값이면 사용자 범위입니다. 멤버십 등급, 가입 경로, 회원 유형처럼 한동안 그 사람을 따라다니는 값입니다. 사용자 범위로 등록하면 그 값이 이후에 들어오는 그 사람의 모든 이벤트에 붙어서, 등급별 구매 비교 같은 분석이 됩니다. 헷갈리면 같은 사람이 오늘 안에 이 값을 여러 번 바꿀 수 있는지 확인합니다. 바꿀 수 있으면 이벤트 범위, 아니면 사용자 범위가 맞습니다.

값의 종류가 끝없이 늘어나는 매개변수는 등록하지 않습니다. 회원 번호, 주문 번호, 세션 식별자, 시각이 여기에 해당합니다. 이런 값은 하루 카디널리티를 사용자 수만큼 끌어올려서, 보고서 표가 값을 감당하지 못하고 (other) 줄로 묶어 버립니다. 문제는 그 영향이 등록한 측정기준에서 끝나지 않고 같은 표를 쓰는 다른 보고서까지 번진다는 점입니다. 여기에 더해 이름, 전화번호, 이메일 같은 개인 정보는 종류와 상관없이 보내는 것 자체가 약관 위반입니다. 판단 기준은 하나입니다. 그 매개변수의 서로 다른 값이 하루에 몇 개나 생기는지 세어 보고, 수백을 넘기면 등록을 다시 생각합니다.

표준 속성은 이벤트 범위 50개, 사용자 범위 25개까지 등록됩니다. 한도가 차면 쓰지 않는 것을 보관 처리해 한도를 비웁니다. 보관은 삭제가 아니라서 이미 쌓인 값은 탐색에서 그대로 조회되고, 그날부터 새 값이 붙지 않을 뿐입니다. 다만 두 가지를 주의합니다. 첫째로 보관한 측정기준을 잠재고객 조건이나 탐색 세그먼트에서 쓰고 있었다면 그 조건이 그날부터 채워지지 않습니다. 보관 전에 어디에서 쓰이는지 확인합니다. 둘째로 보관한 이름과 같은 이름으로 다시 만들면 별개의 측정기준으로 취급되어 이전 값과 이어지지 않습니다. 한도 관리는 등록을 아끼는 쪽이 편합니다. 보고서에서 실제로 나눠 볼 매개변수만 등록하고, 한 번 확인하고 말 값은 디버그 뷰로 봅니다.

크게 세 가지를 차례로 확인합니다. 첫째로 시점입니다. 값은 등록한 순간부터 붙기 때문에, 등록 전에 쌓인 기간을 열면 전부 (not set)입니다. 기간을 등록 다음 날부터로 좁혀서 봅니다. 둘째로 철자입니다. 등록할 때 적은 매개변수 이름과 실제로 들어오는 이름이 한 글자라도 다르면 값이 붙지 않습니다. inquiry_type과 inquiryType은 다른 매개변수입니다. 디버그 뷰에서 실제 이름을 확인해 맞춥니다. 셋째로 그 이벤트에 매개변수가 없는 경우입니다. 문의 이벤트에만 붙는 매개변수를 등록해 놓고 전체 이벤트 기준으로 보면, 매개변수가 없는 이벤트가 모두 (not set)으로 잡힙니다. 이때는 보고서에 필터로 그 이벤트만 남기고 읽습니다.

맞춤 이벤트는 행동을 하나 더 세는 것이고, 맞춤 측정기준은 세어 둔 행동을 나눠 보는 축을 여는 것입니다. 문의 양식으로 예를 들면 이렇습니다. 문의가 제출됐다는 사실을 세려면 맞춤 이벤트 contact_submit을 만듭니다. 그 문의가 제품 문의인지 배송 문의인지 나눠 보려면 inquiry_type 매개변수를 맞춤 측정기준으로 등록합니다. 앞의 것은 관리의 이벤트 화면에서, 뒤의 것은 맞춤 정의 화면에서 합니다. 순서도 정해져 있습니다. 매개변수는 이벤트에 실려 오기 때문에, 이벤트가 먼저 들어오고 있어야 측정기준 등록이 의미가 있습니다.