출시 후 점수 지키기

대시보드는 저희가 이 제품의 이 절반에 넣은 것 중 가장 덜 중요한 부분입니다. 일정에 맞춰 나머지를 모두 출시하기 위해 무언가 하나를 잘라내야 했다면, 저는 그것부터 잘라냈을 겁니다 — 매일 우리 대시보드를 들여다보는 사람으로서 하는 말입니다.

이유는 이렇습니다. 저는 같은 패턴을 예측할 수 있을 만큼 여러 번 지켜봤습니다: 누군가 6주에 걸쳐 좋은 것을 만들고, 화요일에 출시하고, 첫날 Analytics를 열한 번 확인하고, 다음 날 두 번, 그다음 날 한 번, 그리고 그 뒤로는 다시는 확인하지 않습니다. 신경을 안 쓰게 된 게 아닙니다. 확인하는 건 쉽지만 행동하는 건 어렵습니다 — 40개의 Search Console 쿼리 중 실제로 중요한 것이 무엇인지, 4,000회 노출에 클릭률 2.1%가 나쁜 건지 아니면 그 순위대에서는 정상인지 알아야 하고, 그런 다음 출시 주 이후로 열어보지도 않은 CMS에 들어가 메타 설명을 다시 써야 합니다. 각 단계마다 순환을 끊기에 충분한 마찰이 존재하는 세 단계입니다. 대시보드는 이걸 해결하지 못합니다. 마찰이 존재하는 곳이 바로 대시보드입니다.

매일 무엇이 들어오고, 첫 주에는 그중 얼마나 신뢰해야 하는가

동기화는 네 곳에서 데이터를 가져오지만, 첫날부터 모두 같은 수준의 신호를 담고 있는 건 아닙니다.

너무 일찍 들여다보면 거짓말을 하는 게 바로 서치 콘솔입니다. 구글은 새 페이지를 즉시 색인하거나 순위에 반영하지 않습니다 — 신규 도메인의 경우 노출 수가 나타나기까지 2~4주가 걸릴 수 있고, 첫 한 달 동안은 구글이 아직 순위를 정하는 중이라 순위 데이터도 들쭉날쭉합니다. 이런 이유로 저희는 1주차 서치 콘솔 수치만으로 변경을 제안하는 것을 에이전트에게 막고 있습니다. 노출 3회에 클릭 0회인 페이지는 통계적으로 아무것도 말해주지 않습니다. 그 수치만으로 제목을 다시 쓰는 것은 그냥 추측에 절차만 더한 것일 뿐입니다. 애널리틱스는 훨씬 빨리 신뢰할 수 있습니다. 크롤링 지연 없이, 누군가 방문하는 순간 세션은 실제가 되기 때문입니다.

앱 스토어는 사람들이 아예 잊고 지나치는 항목인데, 데이터가 중요하지 않아서가 아닙니다 — 다른 포털, 다른 로그인, 다른 용어 체계(그들의 "노출"은 "페이지에 렌더링됨"보다 "검색 결과에 표시됨"에 가깝습니다) 때문에 아무도 자발적으로 거기로 전환하고 싶어 하지 않는 거죠. 이를 동일한 일일 동기화에 통합하면, 리스팅 전환율 급락이 이를 유발했을 법한 웹 트래픽 하락 옆에 바로 표시됩니다. 아무도 열어볼 생각을 못 하는 앱 안에 방치되는 대신 말이죠.

캐시된 필터를 신뢰하면 안 된다는 것을 가르쳐준 프로퍼티 혼동 사건

한 사용자가 하나의 Google 애널리틱스 프로퍼티에 두 개의 사이트를 두고 있었습니다. 플랫폼에 가입하기 훨씬 전부터, 관리할 프로퍼티 수를 하나 줄이려고 그렇게 설정해둔 것이었죠. 약 하루 동안 저희 대시보드는 두 도메인의 트래픽을 마치 하나의 사이트인 것처럼 합산해서 보여줬습니다. 세션 수는 좋아 보였습니다. 이탈률은 사실 의심스러울 정도로 좋아 보였는데, 돌이켜보면 그게 바로 단서였어야 했습니다 — 서로 매우 다른 두 사이트의 평균값이었을 뿐, 어느 쪽에도 진짜 수치가 아니었으니까요.

해결책: 모든 애널리틱스 쿼리는 연결 시점에 캐시된 설정값이 아니라 실제 요청에 대해 호스트명 필터를 적용합니다. 프로퍼티는 재할당되고 서브도메인은 추가되며, 오래된 필터는 필터가 없는 것보다 더 나쁩니다. 요란하게 실패하는 대신 조용히 실패하기 때문입니다. 저희는 공유 프로퍼티 케이스를 특별히 테스트합니다 — GA4 프로퍼티 하나에 도메인 20개, 필터링된 합계가 단일 프로퍼티 대조군과 일치하는지 확인하죠 — 이 버그는 오류를 던지지 않기 때문입니다. 그저 당신 것이 아닌 좋은 소식을 조용히 알려줄 뿐입니다.

숫자를 결정으로 바꾸는 것, 그것이 진짜 제품입니다

대시보드는 그 자체로는 아무런 행동 의무 없이 정보를 알고 있다는 느낌만 주는 수단입니다. 가치는 숫자를 보는 것과 그에 따라 행동하는 것 사이의 간극에서 생기며, 대부분의 사이드 프로젝트의 최적화 작업은 바로 그 간극에서 사라져버립니다.

Optimize 팀의 역할은 그 간극을 메우는 것입니다. 저희 자체 도메인 중 하나에 "셀프 호스팅 애널리틱스 구축" 관련 쿼리 클러스터로 주당 1,800회의 노출을 얻는 페이지가 있었는데, 클릭률은 1.4%에 불과했습니다 — 순위 6~8위 정보성 쿼리에서 기대되는 3~5%에 크게 못 미치는 수준이었죠. 에이전트는 단순히 이를 지적하는 데 그치지 않았습니다. 사람들이 실제로 검색하는 핵심 고민을 결과 페이지에서 잘리지 않는 처음 60자 안에 담은 제목 재작성을 제안했고, 구체적인 검색어와 노출 수를 근거로 제시했습니다. 적용 후 2주 만에 클릭률은 3.8%로 올랐습니다. 실제 페이지에 대한 실제 수정이었습니다. 차트가 빨간색에서 초록색으로 바뀐 게 아니라요.

이 중 얼마나 많은 부분이 당신의 개입 없이 이루어지는지는 성격이 아니라 다이얼입니다:

• 보고 전용. 발견 사항은 근거 자료와 함께 읽기 쉬운 보고서로 전달됩니다. 실행 여부는 당신이 결정합니다. 소중히 다루는 도메인이나, 아직 판단 근거를 직접 확인하고 싶은 초기 단계 도메인에 적합합니다.
• 제안. 에이전트가 실제 변경안을 작성합니다 — 실제 제목 태그, 실제 문단 — 그리고 승인을 기다립니다. 대부분의 사용자는 제안이 신뢰를 얻은 후에도 최종 결정권은 갖고 싶어 하는 한 달 뒤쯤 이 단계에 정착합니다.
• 자율. 승인된 변경 유형은 곧바로 적용되고, 1~2주 후 수치를 기준으로 재검증됩니다. 지표가 반대 방향으로 움직였다면, 사용자가 알아챌 때까지 더 나쁜 페이지를 방치하는 대신 자동으로 롤백합니다.

저희는 메타와 제목 변경에는 자율 모드로, 페이지 구조나 새 콘텐츠에 관련된 것에는 제안 모드로 저희 사이트를 운영합니다. 잘못된 제목은 틀렸더라도 2초면 고칠 수 있습니다. 하지만 잘못된 콘텐츠 재작성은 몇 달 걸려 쌓은 순위를 망칠 수 있고, 저는 배포 후가 아니라 배포 전에 사람이 그것을 잡아내는 편을 선호합니다. 당신의 위험 계산은 다른 곳에 떨어질 수 있고, 그래야 합니다 — 자동화를 원칙적으로 아무리 신뢰하더라도, 수입 전부가 걸린 도메인은 취미 프로젝트보다 더 신중을 기할 가치가 있습니다.

롤백이야말로 자율 모드를 무모함이 아니라 정당한 선택으로 만드는 요소입니다. 변경 사항이 배포되면, 플랫폼은 해당 지표에 맞게 조정된 측정 기간을 기다립니다 — 트래픽이 적은 페이지의 클릭률이라면, 고정된 일수를 세는 대신 몇 백 건의 노출이 누적되기를 기다리는 것을 의미할 수 있습니다 — 그런 다음 전후를 비교합니다. 결과가 불리하게 움직이면 되돌리고 이유를 기록합니다. 실험이 내장된 변경인 셈이며, 사실 신중한 사람이라면 원래 이렇게 최적화해야 합니다. 대부분은 그저 기다리고 확인할 인내심이 없을 뿐이죠.

비판자들이 옳은 지점

그래서 인정할 부분이 있습니다. 자율 모드에 반대하는 사람들은 가시성 자체에 가치가 있다는 점에서 틀리지 않았습니다 — 자기 사이트에서 무엇이 바뀌었는지 놓치는 것은 실제 비용이고, 저도 그것을 느껴본 적이 있습니다. 제안 모드가 존재하는 이유가 바로 그 흐름을 놓치지 않기 위해서입니다. 대가로 치르는 것은 변경을 승인할 시점 대신 보고서를 읽을 시점을 결정하는 것뿐입니다. 그리고 대시보드는, 가치가 만들어지는 곳은 아니더라도, 새벽 3시에 조용히 발동한 롤백을 발견하고 왜인지 물어볼 장소로는 여전히 남아 있습니다. 저라면 그 밑을 받치는 동기화 파이프라인보다 대시보드를 먼저 줄이겠지만, 그렇다고 아예 없애지는 않을 겁니다. 당신도 그러지 않는 편이 좋습니다.

설정을 의도적으로 최소화했습니다. 여기서의 마찰이야말로 대부분의 출시 후 데이터 파이프라인이 아예 구축되지 않는 이유이기 때문입니다. 내 도메인에서 서치 콘솔과 애널리틱스를 연결하면 — 하나의 Google 서비스 계정으로 둘 다 커버하고, OAuth 인증도 한 번만 진행하면 됩니다 — 일일 동기화가 시작되어 에이전트가 실제로 참조하는 대시보드에 데이터를 공급합니다. 플랫폼의 빌드 파이프라인을 통해 배포된 항목에는 스토어 애널리틱스가 자동으로 연결됩니다.