맞춤 이벤트 만들고 주요 이벤트로 표시하기

사라지지 않습니다. 원래 이벤트는 그대로 들어오고 조건에 맞는 것만 새 이름으로 하나 더 생깁니다. 그래서 이벤트 수 합계가 늘어납니다. 문의 양식 제출이 100회면 form_submit 100회에 contact_submit 40회가 더해져 140회로 잡히는 식입니다. 이 점을 모르고 이벤트 수를 성과로 쓰면 값이 부풀어 보입니다. 원래 이벤트를 없애려면 이벤트 만들기가 아니라 이벤트 수정을 씁니다. 이벤트 수정은 이름 자체를 바꾸므로 하나만 남습니다.

반영되지 않습니다. 표시한 날부터 전환으로 셉니다. 그래서 오늘 표시하고 지난 28일을 열어 보면 앞쪽 기간은 0으로 나옵니다. 값이 갑자기 생긴 것처럼 보여 성과가 늘었다고 잘못 읽기 쉽습니다. 표시한 날짜를 따로 적어 두고, 그 앞뒤를 비교할 때는 전환이 아니라 이벤트 수로 봅니다. 표시를 푸는 경우도 같습니다. 푼 날부터 세지 않을 뿐 그 전에 쌓인 전환 기록은 그대로 남습니다.

속성 하나에 서른 개까지 둘 수 있지만 대개 다섯 개 안쪽이면 넉넉합니다. 개수가 많아지면 어느 것이 진짜 목표인지 흐려지고, 광고 계정으로 내보낼 때도 무엇을 기준으로 입찰할지 정하기 어려워집니다. 고르는 기준은 하나입니다. 그 행동이 매출이나 계약으로 이어지는지 봅니다. 구매, 문의 완료, 견적 요청이 여기에 들어갑니다. 장바구니 담기나 상품 조회는 중간 단계라 주요 이벤트보다 유입경로 탐색에서 보는 편이 낫습니다.

거의 모든 방문에 붙기 때문입니다. 전환율은 주요 이벤트가 일어난 세션의 비율이라, page_view를 표시하면 전환율이 100퍼센트에 가까워집니다. 그 값은 화면을 개선해도 광고를 바꿔도 움직이지 않습니다. 판단에 쓸 수 없는 숫자가 되는 것입니다. 특정 페이지 조회를 성과로 보고 싶다면 page_view 전체가 아니라, 그 주소만 골라낸 맞춤 이벤트를 만들어 그것을 표시합니다. 감사 완료 화면 조회를 문의 완료로 세는 것이 그런 경우입니다.

먼저 시간을 확인합니다. 만든 시점부터 쌓이고 표준 보고서에 값이 채워지는 데 하루쯤 걸립니다. 하루가 지나도 없으면 조건을 봅니다. 조건에 쓴 매개변수 이름이 실제로 들어오는 이름과 같은지, 값의 대소문자가 맞는지, 포함과 같음 가운데 알맞은 연산자를 골랐는지 봅니다. 확인은 디버그 뷰가 빠릅니다. 조건에 해당하는 행동을 직접 하고 이벤트가 두 개로 늘어나는지 봅니다. 원래 이벤트만 들어오고 새 이름이 없으면 조건이 맞지 않는 것입니다.