Search Console 클릭이 실제의 5%로. 페이지×쿼리 집계에서 익명화 쿼리가 빠진 이야기

안녕하세요. まさきん입니다.

이 블로그의 주간 리포트에서 검색 클릭이 28일간 ‘7건’으로 나왔습니다. 페이지 단위로 다시 보니 실제로는 145건이었어요. 원인은 집계 방식에 있었기에, 같은 함정에 빠지지 않도록 실무 메모로 남겨 둡니다.

※글 게시 시점의 정보입니다. 최신 조건은 공식 사이트에서 확인해 주세요.

무슨 일이 있었나

이 블로그에는 매주 자동으로 도착하는 분석 리포트가 있습니다. Search Console과 GA4 숫자를 모아서 지난주와의 차이를 나열하는 구조입니다.

어느 주, 그 주간 리포트의 검색 클릭이 28일간 ‘7건’이었습니다. 글은 매주 늘고 있었고 검색 노출도 늘던 시기였어요. 아무리 그래도 너무 적다고 느꼈습니다.

그래서 Search Console 화면에서 같은 기간을 페이지 단위로 봤습니다. 합계는 145건이었습니다. 7건은 실제의 약 5%밖에 안 됩니다.

방문이 줄어든 게 아니라 집계 오류였습니다. 숫자를 보고 ‘이번 주는 검색이 약하네’라고 결론 내리기 전이라 다행이었다고 생각합니다.

원인은 페이지×쿼리 덧셈

주간 리포트 스크립트는 Search Console 데이터를 page와 query 조합으로 가져오고 있었습니다. 그 행을 전부 더해서 ‘검색 클릭 합계’로 삼았던 거예요.

얼핏 보면 페이지별·쿼리별 내역을 전부 더하면 합계가 될 것 같습니다. 그런데 Search Console에서는 그렇게 되지 않습니다.

쿼리 중에는 ‘익명화 쿼리’가 있습니다. 이 몫은 query를 포함한 표에 한 줄도 나오지 않습니다. 그래서 더하는 시점에 그 몫이 사라지고 있었습니다.

익명화 쿼리란

익명화 쿼리는 개인정보 보호를 위해 표에서 빠지는 쿼리입니다. Google Search Central 블로그에서 설명하고 있습니다. 기준은 ‘2~3개월 사이에 수십 명을 넘는 사용자가 검색하지 않은 것’이라고 되어 있습니다.

실제 검색어는 표시되지 않습니다. 반면 그래프 합계에는 이 몫도 포함됩니다. 다만 쿼리로 필터링하면 합계에서도 빠집니다.

공식 블로그에 알기 쉬운 예가 있었습니다. 내역의 쿼리를 더하면 450클릭입니다. 반면 전체 합계는 550클릭이었습니다. 차이 100이 익명화 쿼리 몫이라는 거죠.

작은 사이트일수록 차이가 클지도 모른다

익명화 기준은 ‘검색한 사람 수’입니다. 그래서 세세한 검색어로 조금씩 읽히는 사이트일수록 익명화 비율이 높아질 것 같습니다.

이 블로그가 딱 그런 유형이었습니다. 검색어 하나하나는 적고, 세세한 표현으로 읽히고 있어요. 그 결과 클릭 대부분이 익명화 쿼리 쪽에 있었던 거라고 생각합니다.

5%만 남는 건 극단적으로 보입니다. 다만 개인 블로그나 막 시작한 사이트에서는 드문 일이 아닐지도 모릅니다.

합계가 어긋나는 이유 정리

Search Console 숫자가 맞지 않는 이유는 익명화만이 아닙니다. 공식 도움말과 블로그에서 확인한 것을 표로 만들었습니다.

제 주간 리포트에서 영향을 준 건 거의 맨 위 항목입니다. 그렇다 해도 다른 이유까지 겹치면 더 읽기 어려워집니다.

속성 단위와 페이지 단위의 차이

Search Console에는 집계 방식이 두 가지 있습니다. 속성 단위(byProperty)와 페이지 단위(byPage)입니다.

공식 도움말에 따르면 그래프 합계는 속성 단위입니다. 같은 쿼리에서 내 사이트가 여러 번 표시되어도 노출 수는 1회로 셉니다.

반면 표를 ‘페이지’로 묶으면 페이지 단위 집계가 됩니다. 같은 검색 결과에 두 페이지가 나오면 각각 노출 수가 붙습니다. 그래서 페이지별 합계가 그래프 합계보다 커질 수 있습니다.

API 레퍼런스에는 page로 묶거나 좁히는 경우 byProperty를 선택할 수 없다고 나와 있습니다. 그럴 때는 auto를 지정하라고 안내합니다.

API 행 수 상한도 주의

Search Analytics API의 rowLimit은 기본값이 1,000행입니다. 지정할 수 있는 범위는 1~25,000행이고, 그 이상은 startRow로 페이지를 넘깁니다.

API로 가져올 수 있는 상한은 ‘하루·사이트 하나·검색 유형별 50,000행’입니다. Search Central 블로그에서 그렇게 설명합니다. Looker Studio 커넥터도 같은 상한이라고 해요.

또 API 레퍼런스에는 ‘모든 행을 반환한다는 보장은 없다’는 취지의 주석이 있습니다. 상위 행이 돌아온다는 전제로 쓰는 게 좋아 보입니다.

한편 query나 URL을 포함하지 않는 조회라면 전체 데이터가 반환된다고 되어 있습니다. 국가별이나 기기별 등이 여기에 해당합니다. 합계를 구한다면 이 점도 기억해 두고 싶은 포인트죠.

노출 수·CTR·게재 순위의 정의

주간 리포트에서 숫자를 이야기하기 전에 지표의 의미도 맞춰 두겠습니다. 공식 도움말의 정의를 정리하면 다음과 같습니다.

평균 게재순위는 한 번의 검색에서 여러 번 표시되어도 가장 위 순위만 씁니다. 지표 하나만으로 판단하지 말고 조합해서 읽는 게 중요하다고 생각합니다.

주간 리포트에서 고친 것

원인을 알았으니 주간 리포트 구성을 바꿨습니다. 한 일은 세 가지입니다.

1. 주인공을 ‘GSC 페이지 단위 검색 성적’과 ‘GA4 유입 경로’ 두 가지로 했다
2. 전후 30PV 미만인 카테고리는 증감을 논하지 않는 규칙을 만들었다
3. 새 글과 기존 글을 나눠서 보도록 했다

첫째는 이번 오류 자체에 대한 대책입니다. 합계는 query를 포함하지 않고 가져오고, 글별 성적은 페이지 단위로 봅니다. 쿼리별 표는 어떤 말로 읽히는지를 훑어보는 재료로 격을 낮췄습니다.

둘째는 작은 숫자로 호들갑 떨지 않기 위한 규칙입니다. 몇 건 차이로 ‘늘었다’ ‘줄었다’고 쓰면 다음 판단이 흔들리기 쉽습니다.

셋째는 새 글의 성장과 기존 글의 변화를 섞지 않기 위해서입니다. 합계만 보면 어느 쪽이 효과가 있었는지 알 수 없게 되죠.

‘보이지 않는 숫자’는 가계에도 있다

이번 일로 느낀 건, 합계를 아래부터 쌓아 올리면 누락을 알아차릴 수 없다는 점입니다. 위에서 전체를 보고 내역과 맞춰 본다. 그래서 비로소 차이가 보였습니다.

가계의 고정비도 비슷합니다. 명세를 한 줄씩 봐도 전체 지출과 비교하지 않으면 빠진 걸 알아차리기 어렵습니다. 휴대폰 요금처럼 매달 자동으로 빠져나가는 지출은 한번 모아서 점검해 보는 것도 좋을지 모릅니다.

직접 만든 집계에서 빠지기 쉬운 함정

여기부터는 직접 만든 주간 리포트나 API·BigQuery 일괄 내보내기로 GSC를 보는 분들을 위한 내용입니다. 제가 밟은 것도 포함해서 나열하겠습니다.

• page×query 행을 더해서 사이트 전체 합계로 쓰고 있다
• 쿼리로 좁힌 숫자와 좁히지 않은 숫자를 같은 표에서 비교하고 있다
• 페이지별 합계와 그래프 합계가 맞지 않는 걸 오류라고 생각한다
• rowLimit을 지정하지 않고 기본 1,000행만으로 집계하고 있다
• 최근 2~3일의 아직 확정되지 않은 숫자로 지난주와 비교하고 있다

BigQuery 일괄 내보내기에도 주의할 점이 있습니다. 공식 도움말에서는 익명화 쿼리를 is_anonymized_query라는 열로 구분합니다. 그 행의 query 열은 비어(null) 있다고 합니다.

또 테이블은 속성 단위와 URL 단위 두 개로 나뉘어 있습니다. query로 집계해서 빈 행을 빼면 마찬가지로 합계가 작아질 겁니다. 합계를 낼 때는 query로 좁히지 않고 집계하는 게 무난할지도 모릅니다.

잘 맞는 보기 방식·안 맞는 보기 방식

어떤 숫자를 어떤 목적으로 쓸지 대략 나눠 두겠습니다.

• 잘 맞음: 사이트 전체 추이는 속성 단위 합계로 본다
• 잘 맞음: 글별 성적은 page 단위로 본다
• 잘 맞음: 쿼리별 표는 ‘어떤 말로 읽히는지’ 경향 파악에 쓴다
• 안 맞음: 쿼리별 행을 더해서 전체 합계로 삼는다
• 안 맞음: 몇 건 차이를 증감의 근거로 삼는다

개인적으로는 합계와 내역을 서로 다른 방식으로 뽑는 게 가장 안심된다고 느낍니다. 분석 업무에서도 숫자의 출처를 설명할 수 있는 게 중요하다고 생각합니다. 데이터 분석에 필요한 ‘통역력’ 이야기와도 가까울지 모르겠네요.

시작하기 전에 확인할 것

• 주간 리포트의 합계 클릭이 query를 포함한 조회 방식으로 되어 있지 않은가
• Search Console 화면의 합계와 주간 리포트의 합계를 한 번 맞춰 봤는가
• API의 rowLimit과 startRow를 지정하고 있는가
• aggregationType을 목적에 맞게 고르고 있는가
• 최근 2~3일의 미확정 데이터를 비교에 쓰고 있지 않은가
• 작은 카테고리의 증감을 논하는 규칙을 정했는가

자주 묻는 질문

Q. 익명화 쿼리 몫은 나중에 볼 수 있나요?

실제 검색어는 표시되지 않습니다. Search Central 블로그에서는 개인정보 보호를 위해 빠진다고 설명합니다. 합계에 포함된 몫으로서, 차이로 짐작하는 수밖에 없어 보입니다.

Q. 화면 합계와 쿼리별 표의 합계 중 어느 쪽이 맞나요?

용도에 따라 다릅니다. 사이트 전체 클릭수라면 그래프 합계 쪽이 실제에 더 가까울 겁니다. 쿼리별 표는 익명화 몫이 들어가지 않은 내역으로 보는 게 좋다고 생각합니다.

Q. 페이지별 합계가 그래프 합계보다 큰 건 왜인가요?

집계 방식이 다르기 때문입니다. 페이지 단위에서는 같은 검색에 여러 페이지가 나오면 각각 셉니다. 그래프는 속성 단위라서 1회로 셉니다.

Q. API로 주간 리포트를 만든다면 어떻게 가져오는 게 좋나요?

합계는 query를 포함하지 않고 가져오는 게 안전합니다. 글별 숫자는 page만으로 가져오고 aggregationType은 auto로 합니다. 쿼리별은 별도 호출로 가져와서 합계와 섞지 않도록 하고 있습니다.

Q. Looker Studio에서도 같은 일이 일어나나요?

Looker Studio 커넥터도 API와 같은 행 수 상한이라고 설명되어 있습니다. 출처는 Search Central 블로그입니다. 익명화 구조도 같으니 쿼리를 포함한 표의 합계는 작게 나올지도 모릅니다.

Q. BigQuery 일괄 내보내기라면 전부 가져올 수 있나요?

행 수 상한의 영향은 받지 않는다고 공식 블로그에서 설명합니다. 다만 익명화 쿼리는 query 열이 비어 있습니다. 쿼리로 집계하면 역시 그 몫은 보이지 않게 됩니다.

Q. 30PV 미만 카테고리를 논하지 않는 건 왜인가요?

숫자가 적으면 우연한 증감에 휘둘리기 쉽기 때문입니다. 몇 건 차이로 방침을 바꾸면 판단이 흔들려 버립니다. 제 주간 리포트에서는 기준값을 정해 기계적으로 빼도록 했습니다.

참고한 공식 정보

• Performance report (Search results): Overview and basic setup(Search Console 도움말)
• Performance report (Search results): Troubleshooting data discrepancies(Search Console 도움말)
• What are impressions, position, and clicks?(Search Console 도움말)
• Table names and location(Search Console 도움말·일괄 데이터 내보내기)
• Search Analytics: query(Search Console API 레퍼런스)
• A deep dive into Search Console performance data filtering and limits(Search Central 블로그)
• Bulk data export: a new and powerful way to access your Search Console data(Search Central 블로그)

정리

Search Console 데이터는 가져오는 방식에 따라 합계가 크게 달라집니다. 제 주간 리포트에서는 page×query 덧셈으로 145건이 7건이 되어 있었습니다.

합계는 query를 포함하지 않고 가져온다. 글 성적은 page 단위로 본다. 쿼리별 표는 경향을 훑어보는 재료로 쓴다. 이 세 가지만 지켜도 잘못 읽는 일은 꽤 줄어든다고 생각합니다.

구조를 알면 숫자가 보이는 방식도 조금 달라지죠. 직접 만든 주간 리포트를 쓰고 있다면 한 번쯤 화면 합계와 맞춰 봐 주세요.

비슷한 ‘기록상으로는 맞는데 실제는 어긋나 있던’ 이야기로 ‘해지 완료’라고 적은 구독이 계속 결제되던 이야기도 남겨 둡니다. 고정비를 점검한다면 고정비 점검 시작하는 법도 참고가 될지 모릅니다.

이 글에는 제휴 광고가 포함되어 있습니다. 이 사이트의 링크를 통해 상품·서비스에 신청하시면 제휴사로부터 보상을 받을 수 있습니다. 또한 운영자는 라쿠텐 그룹 소속 직원으로, 사원 추천 프로그램을 통해 보상을 받는 경우가 있습니다. 기사 내용과 평가는 광고 유무와 관계없이 운영자의 실제 경험과 조사를 바탕으로 작성했지만, 위 관계를 이해하신 후 읽어 주시기 바랍니다. 자세한 내용은 면책조항·제휴 링크 안내를 참고해 주세요. 면책조항·제휴 링크 안내

이 글에는 기계 번역이 포함되어 있습니다. 정확한 조건은 라쿠텐 모바일 공식 사이트의 다국어 페이지에서 확인해 주세요.

라쿠텐 모바일의 통신 지역·전파 상황이 궁금하신 분은, 공식 전파 개선·조사 요청 양식 을 통해 문의하실 수 있습니다.