이건 남의 서비스 분석이 아니라 내 네이버 블로그를 내가 뜯어본 기록이다. 데이터 분석가로 밥 벌어먹으면서 정작 내 콘텐츠는 감으로 굴리고 있었다는 게 좀 부끄러워서 시작했다.
왜 갑자기 내 블로그를 뜯었나
네이버 블로그 관리 페이지에 들어가면 조회수, 유입경로, 성별·연령 같은 걸 예쁜 차트로 보여준다. 문제는 딱 거기까지라는 거다. “어제 몇 명 왔어요” “이번 주 이 글이 인기예요” — 요약은 주는데, 내가 원하는 각도로 다시 자를 raw 데이터는 안 준다. 15일 치 조회수를 CSV로 내려받아서 발행 횟수랑 상관을 보고 싶어도, 화면엔 막대그래프만 떠 있다.
명색이 데이터 분석하는 사람인데, 정작 내 콘텐츠는 “오늘 좀 잘 나왔네” 수준의 감으로 굴리고 있었다. 그래서 마음먹었다. 대시보드가 안 주면, 대시보드가 쓰는 데이터를 직접 가져오자.
대시보드 뒤에서 무슨 일이 벌어지나 — 패킷을 떴다
여기서 핵심 발상 하나. 그 예쁜 차트도 결국 어딘가에서 JSON 숫자를 받아와서 그리는 거다. 브라우저 개발자도구(F12)의 네트워크 탭을 열고 통계 페이지를 눌러보면, 화면이 그려지기 직전에 API 응답(XHR)이 우르르 들어온다. 그 응답이 곧 원본 데이터다.
그래서 크롬을 디버깅 모드로 띄우고(Chrome DevTools Protocol, 로컬 127.0.0.1:9222), 이미 로그인돼 있는 내 세션 위에서 통계 페이지 14개를 순회하며 들어오는 JSON 응답을 전부 받아 적었다.
flowchart LR DASH["네이버 관리 페이지<br/>(예쁜 차트만 보임)"] --> XHR["차트가 그려지기 직전<br/>JSON API 응답이 들어옴"] XHR --> CAP["DevTools Protocol로<br/>내 로그인 세션의 응답 캡처"] CAP --> FILTER["통계 API만 선별<br/>(로그·알림·계정 응답은 버림)"] FILTER --> OUT["원본 JSON → 분석용 CSV"] classDef d fill:#f1f3f5,stroke:#868e96,color:#343a40; classDef k fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class DASH d; class CAP,OUT k;
한 번 훑으니 분석에 쓸 수 있는 통계 API가 25개 나왔다. 크게 두 갈래다.
| 출처 | 엔드포인트 성격 | 뽑히는 것 |
|---|---|---|
| 관리 통계(admin) | visit/cv·uv·visit·averageDuration / referer / hour / demoCv / device / rank | 일별 조회수·순방문·체류시간, 유입경로, 시간대, 성별·연령, 기기, 글별 상위 300 랭킹 |
| 크리에이터 어드바이저 | home/soaring-contents / realtime-summary / trend/demo / trend/category / inflow-analysis | 급상승 글, 실시간 유입, 인구통계·카테고리별 트렌드 검색어 |
⚠️ 안전 선긋기: 이건 내 계정 데이터를 내 로그인 세션으로 본 것뿐이다. 쿠키·인증 토큰·세션 값은 한 줄도 저장하지 않았고, 남의 데이터를 긁는 공개 API도 아니다(로그인해야만 내 숫자가 나온다). 관리 페이지가 POST로 쏘는 텔레메트리 로그(
jackpotlog)나 계정·알림 응답은 통계가 아니라 전부 제외했다.
하루치 말고 3개월치를, 손 안 대고
한 번 구조를 파악하고 나니 그다음은 자동화였다. 대시보드에서 날짜를 하루하루 바꿔 클릭하는 대신, 날짜를 파라미터로 넣어 API를 순회 호출하면 된다. 2026년 2월 19일부터 5월 18일까지, 3개월치를 이렇게 긁었다.
flowchart LR START["날짜 범위<br/>2/19 ~ 5/18"] --> LOOP["날짜별로 통계 API 순회 호출"] LOOP --> JSON["JSON 응답 수집<br/>(총 511회 호출, 실패 0)"] JSON --> CSV["데이터셋별 CSV로 정규화"] CSV --> MERGE["CV·UV·visit·체류시간을<br/>날짜 기준 하나로 병합"] MERGE --> ASK["이제 '질문'을 던질 수 있음<br/>(발행량 상관·유입 구조·상록수 글…)"] ASK -.새 질문.-> LOOP classDef k fill:#e7f5ff,stroke:#1971c2,color:#0b3d66; classDef g fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class LOOP,JSON,CSV k; class ASK g;
511번 호출, 실패 0. 관리 페이지를 수백 번 클릭했으면 며칠 걸렸을 일이, 캡처한 스키마를 재사용하니 한 번에 끝났다. 이게 자동화의 진짜 값어치다 — “대시보드”라는 닫힌 화면을 “내가 쿼리할 수 있는 데이터셋”으로 바꾼 것. 여기서부터가 분석의 시작이었다.
첫 번째 질문 — 트래픽은 대체 어떻게 늘어난 걸까
3개월을 이어 붙이니 성장 곡선이 한눈에 들어왔다. 처음 14일 평균 하루 조회수 72.6 → 마지막 14일 평균 8,125. 약 110배. 최고일(5/15)은 하루 13,174까지 찍었다.
감으론 “글을 많이 써서겠지” 싶었는데, 데이터로 보니 그게 꽤 선명했다.
| 구간 | 하루 평균 발행 | 하루 평균 조회수 |
|---|---|---|
| 2/19 ~ 3/30 | 4.2편 | 376 |
| 3/31 ~ 5/18 | 48.4편 | 7,093 |
3월 말에 발행량을 하루 4편 → 48편으로 확 올린 시점과 트래픽 급증이 겹쳤다. 발행량과 조회수의 상관계수는 0.78~0.81, 그중 3일 시차(lag)에서 0.81로 가장 높았다. 오늘 많이 쓰면 그 효과가 2~3일 뒤 조회수로 번지더라는 얘기다.
물론 상관은 인과가 아니다. 발행량 말고도 계절 이슈·알고리즘 변화가 섞였을 것이다. 다만 “많이 쓰면 대체로 같이 오른다”는 방향성은 데이터가 분명히 말하고 있었다.
그런데 많이 쓴다고 비례해서 오르진 않더라
여기서 감으로는 절대 못 봤을 게 나왔다. 발행량 구간별로 글 한 편당 조회수를 갈라 보니, 많이 쓸수록 편당 효율은 오히려 떨어졌다.
| 하루 발행량 | 하루 평균 조회수 | 글 1편당 조회수 |
|---|---|---|
| 1편 이하 | 185 | 24.8 |
| 15편 안팎 | 3,822 | 198.8 |
| 40편 안팎 | 6,612 | 172.3 |
| 51편 초과 | 7,482 | 113.4 |
flowchart LR A["발행량 ↑"] --> B["총 조회수 ↑<br/>(상관 0.8)"] A --> C["글 1편당 효율 ↓<br/>(199 → 113)"] B --> D{"그래서 최적점은?"} C --> D D --> E["무한정 늘리기보다<br/>'효율 꺾이는 구간'을 알고<br/>발행량을 조율"] classDef y fill:#fff3bf,stroke:#e67700,color:#8a5a00; classDef g fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class B,C y; class E g;
총량은 늘어도 한 편이 데려오는 사람은 줄어드는, 전형적인 수확 체감이다. “무조건 많이”가 아니라 “어디서 효율이 꺾이는지”를 알아야 발행 노동을 어디에 쓸지 정할 수 있다. 대시보드의 막대그래프로는 죽었다 깨어나도 안 보이는 각도다.
트래픽이 ‘어디서’ 오는지가 제일 무서웠다
성장보다 더 오래 들여다본 건 유입 구조였다. 3개월 누적으로 보면 이렇다.
flowchart TD T["총 유입 조회수"] --> NS["비검색 61.6%"] T --> S["검색 38.4%"] NS --> N1["네이버 메인 모바일 홈판 40.8%"] NS --> N2["네이버 블로그 모바일 18.7%"] S --> S1["네이버 통합검색 모바일 33.4%"] S --> S2["블로그검색·PC검색 등 5%"] classDef risk fill:#ffe3e3,stroke:#e03131,color:#a01818; classDef ok fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class N1 risk; class S1 ok;
유입의 40.8%가 네이버 메인 모바일 ‘홈판’ 노출 하나에서 왔다. 비검색 노출을 합치면 61.6%. 이게 왜 무섭냐면 — 노출은 내가 통제할 수 없다. 네이버가 홈에 걸어주면 폭발하고, 안 걸어주면 그날로 반토막이다. 검색 유입(38.4%)은 내가 제목·키워드로 쌓아갈 수 있는 자산이지만, 노출 유입은 알고리즘에 인질로 잡힌 트래픽이다.
숫자로 보고 나니 전략이 명확해졌다. 지금 잘 나온다고 안심할 게 아니라, 통제 가능한 검색 유입 비중을 의도적으로 키워야 이 트래픽이 오래간다.
근데 정작, 아무도 다시 안 온다
유입 다음으로 충격이었던 지표. 재방문율 2.74%, 방문자 1명당 평균 1.05회 방문. 사실상 한 번 왔다 가면 끝이라는 뜻이다.
flowchart LR IN["노출로 왕창 유입"] --> READ["글 하나 보고"] READ --> OUT["그냥 나감<br/>(재방문 2.74%)"] OUT --> DEP["→ 팬덤·구독이 아니라<br/>'노출 의존 휘발성 트래픽'"] classDef risk fill:#ffe3e3,stroke:#e03131,color:#a01818; class OUT,DEP risk;
조회수 8천, 1만이 찍혀도 그게 쌓이는 독자가 아니라 스쳐 가는 노출이라는 걸, 재방문율 한 줄이 말해줬다. 노출 기반 콘텐츠의 숙명이긴 한데, 그래서 더더욱 “이웃·구독으로 남길 장치”와 “다시 찾게 만들 상록수 글”이 필요하다는 결론으로 이어졌다.
누가, 언제 보는가
독자층과 시간대는 오히려 깔끔하게 일관됐다.
| 축 | 데이터 | 함의 |
|---|---|---|
| 성별 | 여성 82.7% | 제목·소재를 여성 독자 기준으로 |
| 기기 | 모바일 93.3% | 모바일에서 읽히는 제목 길이·가독성이 1순위 제약 |
| 연령 | 트렌드 타깃 여성 40~60대 | 관심사·표현을 그 세대에 맞춤 |
| 시간대 | 저녁 20~23시 최대 | 발행·모니터링을 저녁 피크에 배치 |
특히 모바일 93%는 그냥 넘길 숫자가 아니다. 제목이 PC에선 다 보여도 모바일에선 잘린다. “모바일 한 줄에 안 걸리는 제목은 없는 제목”이라는 규칙이 여기서 나왔다.
오래 가는 글 vs 하루 반짝
마지막으로 글별 랭킹(상위 300)을 3개월 이어 붙이니, 똑같이 조회수가 높아도 결이 다른 두 종류가 갈렸다.
flowchart TD RANK["상위 300 랭킹<br/>(3개월 누적, 고유 글 2,342개)"] --> SPIKE["하루 반짝 스파이크형<br/>하루 폭발 후 소멸"] RANK --> EVER["상록수형<br/>30~40일 꾸준히 랭크"] SPIKE --> V1["당장의 조회수는 크지만<br/>수명이 짧음"] EVER --> V2["누적 가치가 큼<br/>→ 이런 글의 '패턴'을 찾아야"] classDef g fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; classDef y fill:#fff3bf,stroke:#e67700,color:#8a5a00; class EVER,V2 g; class SPIKE,V1 y;
어떤 글은 발행 당일 확 뜨고 다음 날 사라졌고, 어떤 글은 40일 가까이 매일 상위권에 남았다. 한 번의 폭발보다 오래 남는 글이 훨씬 값지다. 그럼 상록수 글은 어떤 제목·소재였나? 를 되물으면, 그게 바로 다음 콘텐츠 기획의 근거가 된다.
그래서 — 대시보드로는 못 뽑는 인사이트란
3개월을 데이터로 훑고 내린 결론은 결국 이거였다. 대시보드는 “무슨 일이 있었나”를 서술하고, 원본 데이터는 “그래서 뭘 할 것인가”를 결정하게 해준다.
flowchart TB subgraph LOOP["데이터 기반 블로그 운영 루프"] C1["① 대시보드 뒤 API를 캡처"] --> C2["② 3개월치 자동 수집·정규화"] C2 --> C3["③ 질문을 던져 인사이트 추출"] C3 --> C4["④ 의사결정으로 번역"] C4 --> C5["⑤ 실행 후 다시 데이터로 검증"] C5 -.-> C1 end C3 --> I1["발행량↔효율 꺾이는 지점"] C3 --> I2["노출 의존 리스크 → 검색 유입 키우기"] C3 --> I3["재방문 2.74% → 구독 장치 필요"] C3 --> I4["모바일·여성·저녁 → 제약조건 확정"] C3 --> I5["상록수 글 패턴 → 기획 근거"] classDef k fill:#e7f5ff,stroke:#1971c2,color:#0b3d66; classDef g fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class C1,C2,C3,C4,C5 k; class I1,I2,I3,I4,I5 g;
같은 조회수 1만이라도, 그게 노출로 스쳐 간 1만인지 검색으로 쌓인 1만인지에 따라 완전히 다른 얘기다. 그 차이는 관리 페이지의 숫자 하나로는 절대 안 보이고, 유입·재방문·랭킹 지속성을 교차해야 비로소 보인다. 데이터 분석을 “왜 해야 하냐”고 물으면, 나는 이제 이렇게 답한다 — 감으로는 “많이 나왔다”까지밖에 못 가지만, 데이터로는 “왜, 어디서, 누가, 무엇이 오래가나”까지 가고, 거기서야 다음 수가 나온다.
업데이트 — 글을 쓰자마자, 이번엔 ‘라이브’로 다시 떴다
위 분석은 예전에 저장해둔 2-5월 데이터셋이었다. 글을 마치고 나니 욕심이 생겼다. 저장본 말고, 지금 이 순간 로그인 세션으로 최근 3개월을 다시 뜨면? 그래서 캡처를 일회성 스크립트가 아니라 재사용 가능한 파이프라인으로 다시 짰다. 그 과정에서 배운 것도, 새로 보인 것도 있었다.
방법에서 부딪힌 벽 두 개 (그리고 우회)
라이브로 뜨려니 처음 방식이 그대로는 안 먹혔다.
flowchart TD Q["로그인 세션으로 API를 직접 부르면?"] --> A["관리 통계(blog.stat)"] Q --> B["크리에이터 어드바이저"] A --> A1["페이지에서 fetch → CORS 차단<br/>(교차 서브도메인)"] A1 --> A2["✅ 우회: 통계 페이지로 이동해<br/>대시보드 '자체' 요청 응답을 가로챔"] B --> B1["범위 조회 endpoint 존재<br/>(startDate–endDate 한 방)"] B1 --> B2["⚠️ x-ca-sig 서명 필수<br/>서명 없이 호출 = 403"] classDef risk fill:#ffe3e3,stroke:#e03131,color:#a01818; classDef ok fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class A1,B2 risk; class A2 ok;
- 관리 통계는 CORS에 막혔다. 내 페이지에서
fetch로 부르면 교차 서브도메인이라 브라우저가 막는다. → 대신 통계 페이지로 이동시켜 대시보드가 스스로 쏘는 요청의 응답을 가로채는(DevTools Network 도메인) 방식으로 우회했다. 날짜별 URL로 이동하니 과거 데이터도 그대로 뜬다. - 크리에이터의 ‘범위 조회’ 엔드포인트는 서명(
x-ca-sig)이 필요했다. startDate–endDate를 한 번에 주는 좋은 API가 있는데, 요청마다 프런트가 만드는 서명 헤더가 없으면 403. 남의 계정을 함부로 긁는 걸 막는 장치라, 억지로 뚫지 않고 서명이 필요 없는 관리 API 쪽으로 돌아갔다.
여기서 원칙 하나를 다시 확인했다 — 이건 어디까지나 내 계정 데이터를 내 세션으로 보는 것이고, 서명·쿠키를 위조하지 않으며, 세션 값은 한 줄도 저장하지 않는다.
실제로 어떻게 뜨나 — 파이프라인 뜯어보기
캡처를 다시 짜면서 도구를 네 조각으로 나눴다 — 하루치 스냅샷용, 추이용, 3개월 전체용, 분석용. 한 번 만들어두니 다음엔 크롬 띄우고 로그인만 하면 재실행된다.
flowchart TB CHROME["로그인된 크롬<br/>(원격 디버깅 포트 9222)"] --> CDP["Node 내장 WebSocket으로<br/>CDP 클라이언트 연결(의존성 0)"] CDP --> A["① 일별: 조회/방문/체류<br/>15일씩 창을 거슬러 이동"] CDP --> B["② 주간: 방문빈도·재방문<br/>WEEK 차원 한 번에 약 15주"] CDP --> C["③ 날짜별 루프: 유입·시간대·<br/>성별·기기·상위300글<br/>92일 곱하기 5지표 = 460회 이동"] A --> M["Network 응답 가로채기<br/>→ 원본 JSON"] B --> M C --> M M --> N["컬럼형 JSON 정규화<br/>→ 날짜 기준 병합·집계"] classDef k fill:#e7f5ff,stroke:#1971c2,color:#0b3d66; classDef g fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class CDP,M k; class N g;
만들면서 배운 디테일 몇 개.
- 의존성 0. 요즘 Node에는 WebSocket이 내장돼 있어서, 외부 라이브러리 하나 없이 크롬에 붙어 페이지를 이동시키고 응답을 받아낼 수 있다. 스크립트 파일 하나가 곧 미니 크롤러다.
- “부르는” 게 아니라 “받아온 걸 줍는다”. 관리 통계는 교차 도메인이라 내가 직접 호출하면 브라우저가 막는다(CORS). 그래서 날짜가 박힌 통계 URL로 페이지를 이동만 시키고, 그때 브라우저가 정상적으로 받아온 응답 본문을 DevTools의 Network 기능으로 주워 담는다. 요청을 위조하는 게 아니라 이미 받은 걸 읽을 뿐이라는 선을, 여기서도 지켰다.
- 규모는 생각보다 크다. 유입·시간대·성별·기기·랭킹은 하루치씩만 주는 API라, 92일을 채우려면 지표마다 92번, 5지표면 460번을 이동해야 한다. 사람이 대시보드에서 클릭했으면 반나절짜리 노동이, 스크립트로는 4-5분이면 끝난다. 랭킹만 해도 92일 곱하기 상위 300글 = 27,600행이 쌓였다.
- 데이터가 ‘옆으로 누워’ 있다. 네이버 통계 JSON은 행이 아니라 열 단위 배열로 온다(
{날짜:[...], 조회수:[...]}꼴에 맨 앞이 최신일). 정규화 단계에서 이걸 다시 세워 날짜로 붙이는 코드가 절반의 일이었다. 남의 대시보드를 내 데이터로 쓰려면 이런 스키마 해석이 늘 따라붙는다.
라이브 3개월(4/11-7/10) — 숫자가 더 선명해졌다
| 지표 | 이전(2-5월) | 라이브(4-7월) |
|---|---|---|
| 하루 평균 CV | 4,064 | 11,228 |
| 성장 | — | 첫 14일 7,534 → 끝 14일 17,781 (2.4배) |
| 최고일 CV | 13,174 | 37,792 |
| 비검색 유입 | 61.6% | 82.2% ⬆ |
| 재방문율 | 2.74% | 2.57% |
91일 동안 총 조회수 102만. 월별로 갈라 보면 계단처럼 올라간 게 보인다.
| 월 | 일수 | 총 조회수 | 하루 평균 조회수 | 하루 평균 순방문 |
|---|---|---|---|---|
| 4월 | 20 | 154,350 | 7,718 | 6,909 |
| 5월 | 31 | 306,396 | 9,884 | 8,707 |
| 6월 | 30 | 411,035 | 13,701 | 11,662 |
| 7월 | 10 | 149,959 | 14,996 | 12,050 |
넉 달 내내 하루 평균이 7,700에서 15,000으로 두 배가 됐다. 총량만 보면 분명 잘 크고 있는 블로그다. 문제는 그 아래 ‘구조’였다.
그런데 제일 중요한 건 ‘더 나빠진’ 쪽이었다
노출 의존이 61.6% → 82.2%로 더 심해졌다. 네이버 메인 홈판 하나가 58.3%. 트래픽이 커질수록 오히려 더 남의 알고리즘에 매달리게 된 것이다. 6/27 37,792 → 최근 9,730의 출렁임이 그 취약성을 그대로 보여준다.
flowchart LR P1["2-5월<br/>비검색 61.6%"] --> P2["4-7월<br/>비검색 82.2%"] P2 --> R["트래픽 커질수록<br/>노출 의존 심화<br/>= 알고리즘 리스크 확대"] classDef risk fill:#ffe3e3,stroke:#e03131,color:#a01818; class P2,R risk;
유입처를 전부 펼치면 그 쏠림이 더 적나라하다.
| 순위 | 유입처 | 비중 | 종류 |
|---|---|---|---|
| 1 | 네이버 메인 모바일 ‘홈판’ | 58.3% | 노출 |
| 2 | 네이버 블로그 모바일 | 21.7% | 노출 |
| 3 | 네이버 통합검색 모바일 | 14.4% | 검색 |
| 4 | 네이버 블로그검색 모바일 | 1.9% | 검색 |
| 5 | 네이버 메인 모바일 | 1.6% | 노출 |
| 6 이하 | 통합검색 PC·블로그검색 PC·다음 등 | 합쳐서 약 2% | 혼합 |
상위 둘, 홈판 58.3%와 블로그 노출 21.7%를 합친 80%가 전부 “내가 안 건드려도 네이버가 밀어줘서” 들어온 트래픽이다. 검색을 다 합쳐야 17.8%. 내가 제목·본문으로 직접 쌓을 수 있는 몫이 다섯 중 하나도 안 된다는 뜻이다.
대신, 뜻밖의 ‘숨은 자산’을 찾았다
92일 랭킹을 글 단위로 뒤집어 보다가 재밌는 걸 발견했다. 하루 대여섯 뷰밖에 안 되는데 30-60일씩 꾸준히 랭킹에 남는 글들이 있었다. 노출로 터지는 대박글과는 정반대 결 — 후기·정보·로컬성 “검색형” 글이었다. 노출이 아니라 검색으로 조용히 오래 버티는 것이다.
flowchart TD C["상위 랭킹 글 4,039개"] --> H["노출형 히트<br/>하루 폭발 후 소멸<br/>(스파이크 40%)"] C --> L["검색형 상록수<br/>후기·정보, 하루 대여섯 뷰씩<br/>30~60일 지속"] L --> INSIGHT["→ 노출 리스크를 헤지할<br/>'검색 지반'이 이미 자라고 있었다"] classDef y fill:#fff3bf,stroke:#e67700,color:#8a5a00; classDef g fill:#d3f9d8,stroke:#2f9e44,color:#1d6b2c; class H y; class L,INSIGHT g;
숫자로 보기 전엔 “노출로 터뜨리는 블로그”라고만 생각했는데, 그 밑에 검색으로 스스로 사는 롱테일이 조용히 깔려 있었다. 82% 노출 의존의 해독제가 이미 내 블로그 안에 씨앗으로 있었던 셈이다. (덤으로 크리에이터 API에선 일 광고 수익까지 숫자로 잡혀서, 트래픽을 ‘돈’이라는 또 다른 축으로도 볼 수 있게 됐다.)
누가·언제 보는가 — 상수는 흔들리지 않았다
트래픽 규모와 유입 구조는 출렁였지만, 독자와 시간대는 세 달 내내 놀랄 만큼 일정했다.
| 축 | 라이브 3개월 값 | 그래서 |
|---|---|---|
| 성별 | 여성 82.7% · 남성 17.3% | 소재·화법을 여성 독자 기준으로 |
| 기기 | 모바일 94.9% · PC 5.1% | 제목은 모바일 한 줄이 전장 |
| 연령 | 30-60대 중장년 여성 중심(상위 연령대가 조회수의 70% 이상) | 관심사·표현을 그 세대에 |
| 시간대 | 저녁 20-23시 피크(+ 오후 16-17시 2차 봉우리) | 발행·모니터링을 저녁에 |
특히 모바일 94.9%는 매번 곱씹게 된다. PC에선 멀쩡히 보이는 제목이 모바일에선 뒤가 잘린다. “모바일 한 줄에 안 걸리는 제목은 없는 제목”이라는 규칙을, 이번 데이터가 다시 못 박아줬다.
콘텐츠를 글 하나하나로 뒤집어 보니
92일 랭킹을 글 단위로 집계하니 상위 300에 한 번이라도 든 고유 글이 4,039개였다. 이걸 ‘얼마나 오래 버텼나’로 갈라 보면 성격이 뚜렷이 나뉜다.
| 유형 | 규모 | 성격 |
|---|---|---|
| 상록수 (20일 이상 랭크) | 312개 | 오래 살아남아 누적이 쌓임 |
| 스파이크 (1-2일만 랭크) | 약 40% (1,599개) | 하루 폭발 후 소멸 |
| 중간 수명 | 나머지 | 며칠 반짝 |
대박 히트글은 대개 ‘노출로 하루 폭발’이지만 그 40%는 다음 날이면 사라진다. 반대로 앞서 말한 검색 상록수는 조회수가 작아도 30-60일을 버틴다. 하루 조회수만 보면 히트글이 왕이지만, 누적과 수명으로 보면 이야기가 완전히 달라진다. 어떤 글이 오래 사는지를 알면, 다음에 뭘 쓸지가 정해진다.
그래서 결론이 한 칸 더 갔다
- 노출은 빌린 트래픽이다. 82%가 네이버가 밀어주는 자리에서 온다. 지금은 잘 나오지만, 알고리즘이 마음을 바꾸는 날 통째로 흔들린다. 그래서 검색으로 들어오는 글의 비중을 의도적으로 끌어올리는 것이 1순위 과제다 — 제목에 검색 키워드를 앞세우고, 정보·후기형 글을 꾸준히 심는다.
- 검색 상록수의 패턴은 이미 내 안에 있다. 없는 걸 만드는 게 아니라, 이미 30-60일씩 버티는 글들이 어떤 제목·구조·소재였는지를 뜯어 그 패턴을 의식적으로 재생산하면 된다. 데이터가 교보재를 이미 쥐여준 셈이다.
- 재방문 2.5%의 러닝머신에서 내려야 한다. 매일 새 사람에게 새로 증명하는 구조로는 아무것도 축적되지 않는다. 시리즈물·이웃/구독 유도처럼 “다시 오게 만드는 장치” 하나라도 심어야 트래픽이 자산이 된다.
- 그리고 이 모든 판단을, 이제 로그인 한 번이면 언제든 다시 뜨는 파이프라인으로 뒷받침한다. 한 달 뒤 같은 걸 다시 돌리면 “검색 비중이 정말 올랐나”를 숫자로 확인할 수 있다. 감이 아니라 데이터로 블로그를 보는 습관의 인프라가 생긴 것 — 사실 이게 이번 작업의 진짜 결과물이다.
마무리 — 내 콘텐츠를 데이터로 본다는 것
솔직히 뜯어보기 전엔 “그냥 많이 쓰면 오르는 거 아냐?”였다. 뜯고 나니 많이 쓰면 오르긴 하는데 효율은 꺾이고, 잘 나오는 것 같아도 대부분 노출에 인질로 잡혀 있고, 사람은 쌓이지 않고 스쳐 간다는, 훨씬 입체적인 그림이 나왔다. 남의 회사 데이터를 분석하던 습관을 처음으로 내 콘텐츠에 돌려봤을 뿐인데, 앞으로 뭘 고쳐야 할지가 다섯 개나 선명해졌다.
대시보드가 안 주는 걸 굳이 패킷까지 떠서 가져온 이유가 이거다. 분석가의 무기는 결국 “원본 데이터에 직접 손을 댈 수 있는가”에서 갈린다. 다음 글에서는 이 데이터로 실제 발행 전략을 어떻게 바꿨는지, 검증까지 이어서 써볼 생각이다.
참고 · 방법 메모
- 수집: 크롬 DevTools Protocol로 로그인 세션의 통계 API JSON 응답 캡처 → 데이터셋별 CSV 정규화(관리 통계 11종 + 크리에이터 어드바이저 14종, 3개월·511호출·실패 0).
- 라이브 재수집(업데이트): 캡처를 재사용 파이프라인으로 재작성(Node 내장 WebSocket 기반 CDP 클라이언트, 관리 통계는 Network 응답 가로채기·크리에이터는 서명 필요 확인). 최근 92일 전지표 재캡처(일별 91 + 날짜별 92×5) 후 트래픽·유입·시간대·독자·상록수·충성도 종합 집계.
- 분석: 일별 CV/UV/visit/체류시간 병합 테이블 + 발행량 조인(상관·시차·버킷), 유입·재방문·시간대·인구통계·글별 랭킹 지속성(상록수 vs 스파이크).
- 관련 글: 마케팅 데이터 분석 사례 · 가격 모니터링 파이프라인 · 리텐션 곡선 읽기