보고서에 (other) 행이 생길 때 — 카디널리티 한도

증상

보고서에서 측정기준을 펼쳤는데 상위 몇 줄 아래에 (other)라는 행 하나가 앉아 있습니다. 숫자는 큰데 클릭해도 펼쳐지지 않고, 필터를 걸어도 쪼개지지 않습니다. 개별 페이지나 개별 상품의 성과를 보려고 만든 측정기준인데, 정작 보고 싶던 값들은 전부 그 한 줄 안에 들어가 있습니다.

같은 측정기준을 탐색에서 열어도 결과는 비슷합니다. 세그먼트를 나눌 수 없으니 그 측정기준으로 할 수 있는 분석이 사실상 없습니다.

원인

GA4의 표준 보고서는 원본 이벤트가 아니라 날마다 집계해 둔 표에서 숫자를 읽습니다. 하루에 들어오는 값의 종류가 그 표가 담을 수 있는 한도를 넘으면, GA4는 상위 값만 개별 행으로 남기고 나머지를 전부 (other) 한 줄로 합칩니다. 이것이 카디널리티(고유값 개수) 초과입니다.

중요한 건 트래픽 양이 아니라 값의 종류 수라는 점입니다. 하루 방문자가 적어도 파라미터에 건마다 다른 값을 실어 보내면 똑같이 걸립니다. 실제 진단에서 자주 나오는 형태는 이렇습니다.

AnalyticScan은 맞춤 측정기준을 대상으로 하루 고유값 수와 (other) 행 존재 여부를 봅니다. 하루 고유값이 300을 넘으면 주의, 500을 넘거나 이미 (other) 행이 보이면 감점으로 판정합니다.

식별자를 그대로 싣는 습관은 다른 문제도 같이 만듭니다. 그 값 안에 이메일이나 전화번호가 섞여 들어오면 카디널리티를 넘어 Google 정책 위반이 됩니다.

GA4에서 확인

1) 어느 측정기준인지 좁힌다. (other) 행이 보이는 보고서에서 측정기준을 하나씩 바꿔 보세요. 기본 측정기준에서는 멀쩡한데 특정 맞춤 측정기준에서만 뜨는 경우가 대부분입니다.

2) 값의 생김새를 본다. 문제의 측정기준에서 상위 행 몇 개만 읽어 보면 원인이 대개 그 자리에서 보입니다. 값 끝에 숫자·해시·물음표가 붙어 있으면 그것이 범인입니다.

3) 기간을 하루로 좁혀 본다. 한도는 하루 단위로 걸리므로, 한 달을 합쳐 놓고 보면 왜 뭉개지는지 알기 어렵습니다. 하루씩 보면 언제부터 늘었는지도 함께 드러납니다 — 보통 배포일입니다.

수정

고치는 자리는 보고서가 아니라 수집 코드입니다. 값을 보내기 전에 종류를 줄이는 것 말고 다른 방법은 없습니다.

• URL은 정규화해서 보냅니다. 쿼리스트링을 떼고 경로만 남기거나, /product/10293처럼 아이디가 들어가는 경로는 /product/detail 같은 템플릿으로 바꿉니다.
• 식별자는 맞춤 측정기준에 넣지 않습니다. 주문번호나 회원 ID로 개별 조회를 해야 한다면 그건 보고서가 아니라 BigQuery 내보내기가 할 일입니다. BigQuery로 내보내면 원본 이벤트 행이 그대로 남습니다.
• 상품은 그룹으로 보냅니다. 상품명 대신 카테고리·가격대·브랜드처럼 종류가 수십 개에서 멈추는 값으로 바꿉니다. 상품 하나하나의 성과는 원래 이커머스 items 데이터와 항목 보고서가 담당하는 자리입니다.
• 검색어는 사이트 검색 기능이 만드는 기본 측정기준을 씁니다. 같은 값을 맞춤 측정기준으로 한 번 더 받을 이유가 없습니다.

고친 뒤에는 다음 날부터 새 값이 들어옵니다. 다만 이미 (other)로 묶인 기간은 돌아오지 않습니다 — GA4는 지난 데이터를 다시 계산하지 않으므로, 그 기간의 세부 내역은 영구히 없는 상태로 남습니다.

한 줄 요약

(other)는 GA4의 고장이 아니라 값의 종류가 너무 많다는 신호입니다. 파라미터에 식별자·전체 URL을 싣고 있지 않은지 지금 확인하세요. 오늘 고치면 오늘부터 남고, 어제는 복구되지 않습니다.