Xiaohongshu 데이터 분석, 합계만 보지 마세요: 내보낸 노트와 과거 스냅샷 활용하기

Xiaohongshu에서 내보낸 노트로 최근 북마크 증가를 측정하려면, 필드가 누적 합계인지 구간 증가분인지 확인한 뒤 같은 정의로 같은 노트의 두 관측값을 비교해야 합니다. 현재 합계 스냅샷 하나로는 일별 증가 이력을 복원할 수 없으며, 같은 파일을 매일 다시 가져온다고 신뢰할 수 있는 시계열 데이터가 만들어지지는 않습니다.

DeanThompson이 V2EX에 공유한 xhs-trail 프로젝트는 구체적인 출발점이 됩니다. 크리에이터 대시보드 내보내기 파일로 노트 변화를 시간에 따라 추적하는 방식입니다. 핵심은 여러 번의 관측을 보존하는 것이며, 작성자의 기능 구성을 이름만 바꿔 가져오는 것이 아닙니다.

이 글은 2026년 9월 5일까지의 원문 게시물, 작성자 README 파일, 도구 문서를 교차 확인해 독립적인 처리 방법을 정리합니다. 이 프로젝트를 설치하거나 감사하지 않았고, 인증이 필요한 Xiaohongshu 백엔드에도 접근하지 않았습니다. 구체적인 내보내기 엔드포인트, 필드, 범위는 승인된 계정 접근 권한에 따라 달라집니다.

비공개 대시보드 데이터는 공개 노트 데이터와 다릅니다

공개 노트, 댓글 텍스트, 크리에이터 통계는 서로 다른 질문에 답합니다. 공개 콘텐츠는 공개 논의에 대한 코퍼스 분석에 쓰이고, 크리에이터 리포트는 노출, 열람, 전환에 대한 내부 검토에 쓰입니다. 리포트는 직접 확인해야 하며, 공개 좋아요 수로 관찰되지 않은 백엔드 지표를 추정해서는 안 됩니다. EveryInfra의 Xiaohongshu 노트 상세 API로 링크를 통해 공개 노트를 읽을 수 있습니다. 이 API는 백엔드 리포트 데이터가 아니라 조회 시점의 공개 수치(예: like_count, collect_count)를 반환합니다.

"사용자가 댓글에서 가장 많이 묻는 질문은 무엇인가?"와 "어떤 노트가 북마크 전환율이 더 높은가?"에는 서로 다른 스키마가 필요합니다. 전자는 검증 가능한 댓글 샘플을, 후자는 북마크와 열람을 명확히 정의한 기준을 요구합니다. 노트 URL이 있다는 이유만으로 여러 데이터셋을 출처 구분 없이 하나의 테이블로 합치는 방식은 성립하지 않습니다.

내부 Xiaohongshu 댓글 일괄 수집 가이드는 이미 알고 있는 노트 목록의 댓글 조회를 다루며, 경쟁사 계정의 비공개 통계는 다루지 않습니다. 데이터를 선택하기 전에 분석 질문을 올바른 수집 진입점에 매핑해야 합니다.

자신의 계정이라면 승인된 데이터 파이프라인을 추가하기 전에 정제된 내보내기 파일로 오프라인 처리를 먼저 검증해야 합니다. 자동 수집이 수동 내보내기보다 낫다고 전제하지 않으며, 내보내기 권한이 있다고 해서 폭넓은 사용 권한이 주어지는 것도 아닙니다.

통계 날짜, 내보내기 날짜, 가져오기 타임스탬프 분리하기

작성자의 README는 과거 파일을 현재 실행 결과로 잘못 귀속하지 않도록 기본 파일명에 데이터 날짜를 명시적으로 넣을 것을 강조합니다. 오늘 파일을 가져왔다고 해서 그 파일이 오늘의 운영 상태를 반영하는 것은 아닙니다.

최소 세 가지 타임스탬프를 기록해야 합니다. 리포트의 집계 기간 또는 기준 시점, 실제 내보내기 시각, 분석 시스템에 적재한 시각입니다. 필요한 경우 시간대도 함께 보존합니다. 파일 수정 시각은 파일 작업을 디버깅하는 데 도움이 되지만 통계 날짜를 판단하는 유일한 근거가 되어서는 안 됩니다.

수집 시각 기준으로 파티셔닝하는 상태에서 수요일 리포트를 금요일에 백필하면 수요일은 누락으로 표시되고 금요일 스냅샷은 서로 충돌하게 됩니다. 이후 차감 계산을 하면 잘못된 추세가 그려집니다.

같은 날 여러 번 내보낸 경우에는 명시적인 정책이 필요합니다. 각각을 별개의 관찰 시점으로 보존하거나 최종 확정본을 채택합니다. 이 선택에는 파일이 들어온 순서가 아니라 항상 같은 결과를 내는 명확한 규칙을 적용해야 합니다. 중복 가져오기는 표시하고, 수정된 파일은 교체 이력을 보존해야 합니다.

차감은 구간 윈도가 아닌 누적값으로

수식을 세우기 전에 필드 정의부터 확인해야 합니다. 두 스냅샷의 누적 북마크 수를 비교하면 해당 구간의 순변화량이 나옵니다. 롤링 "최근 7일" 윈도끼리 빼면 롤링 윈도 간의 차이가 나올 뿐, 하루 단위 순증가량은 나오지 않습니다.

가상의 예시: 월요일 09:00에 어떤 노트의 누적 북마크가 120개이고 수요일 09:00에 165개라면 차이는 45입니다. 두 시점 사이에 누적값이 순 45만큼 증가했다고 말할 수는 있지만, 45 전체를 수요일에 귀속하거나 화요일과 수요일에 각각 22.5씩 늘었다고 단정할 수는 없습니다.

평균 변화량에는 실제 시간 간격과 함께 "48시간 구간 기준 일평균 순변화"처럼 명시적인 라벨을 붙여야 합니다. 평균은 파생된 산출값이지, 관찰되지 않은 일별 데이터 포인트가 아닙니다.

노트 식별자, 지표 일관성, 이전 수정본 가져오기 여부를 확인하지 않은 채 음수 차이를 0으로 잘라내서는 안 됩니다. 음수 차이는 관찰된 순감소 또는 검토 대기 항목으로 보존하고, 플랫폼이 정리했다는 식의 근거 없는 설명을 지어내지 않아야 합니다. 카운터 차이로는 집계를 재구성할 수 있을 뿐, 사용자 단위의 이벤트 로그를 재구성할 수는 없습니다.

스냅샷 조인은 제목이 아닌 노트 ID로

제목은 바뀌고, 반복 연재 시리즈는 서로 겹칩니다. 스냅샷 간 조인 키로는 승인되고 검증된 노트 식별자를 사용하고, 여러 계정을 다루는 경우 계정 범위도 함께 유지해야 합니다. 제목과 게시 시각으로 매칭하는 방식에는 충돌 해소 절차가 필요하며, 이를 기본 키처럼 암묵적으로 취급해서는 안 됩니다.

조인 전에 중복 키를 확인해야 합니다. 테이블마다 두 번씩 나타나는 노트가 있으면 일반 조인 결과 4개 행이 생겨 수치와 표본 크기가 부풀려집니다. pandas merge 문서는 고유성 검증을 위한 validate="one_to_one"과 한쪽에만 있는 레코드를 분리하기 위한 indicator를 설명합니다.

pandas를 쓰지 않더라도 고유성 검증은 유지해야 합니다. 조인 전에 행의 의미를 확인합니다. 중복을 최댓값으로 뭉개서는 안 됩니다. 중복은 재내보내기일 수도 있고 계정이나 지표 정의가 섞인 것일 수도 있으며, 각각 처리 방식이 다릅니다.

SQLite에 스냅샷을 저장한다면 공식 UPSERT 문서에 따라 충돌 해소는 고유성 제약 조건에 의존합니다. DB 제약은 중복 쓰기를 막아 주지만 잘못된 스냅샷 날짜는 감지하지 못합니다. 중복 가져오기를 무시, 거부, 수정본 중 무엇으로 처리할지 정하기 전에 계정, 노트, 통계 타임스탬프, 지표 정의를 아우르는 고유성 기준부터 정의해야 합니다.

파일이 없다고 성장이 0인 것은 아니다

내보내기 파일에 항목이 없는 이유는 필터 범위, 불완전한 파일, 조인 실패 등일 수 있습니다. 누락이 삭제를 증명하지는 않으며, 누적 지표를 0으로 초기화할 근거도 되지 않습니다.

스냅샷 비교는 양쪽 모두에 있는 레코드, 왼쪽에만 있는 레코드, 오른쪽에만 있는 레코드로 나눠야 합니다. 직접 차이 계산은 식별자와 정의가 일치하는 공통 레코드로 한정합니다. 이전 기준값이 없는 새로 나타난 노트는 현재 관찰값만 보여 줄 뿐이며, 과거 값을 0으로 가정해서는 안 됩니다.

"이번 주 계정 전체 성장"처럼 포괄적인 라벨 대신 "두 파일에서 매칭된 노트"처럼 리포트 범위를 명시해야 합니다. 계정 전체 집계에는 내보내기 범위와 누락 데이터에 대한 설명이 필요하며, 뺄셈이 가능한 모든 행을 단순히 합산해서는 안 됩니다.

내부 멀티 플랫폼 평판 모니터링 블루프린트도 같은 원칙을 적용합니다. API든 스프레드시트든 비즈니스 로직에서 수집 공백을 0으로 변환해서는 안 됩니다.

콘텐츠 성과 비교를 위한 관찰 기간 정규화

30일 전에 게시된 노트와 어제 게시된 노트는 품질과 무관하게 누적 합계가 다릅니다. 게시 후 동일한 관찰 기간으로 비교하고, 스냅샷 커버리지가 충분하지 않은 노트는 비교 불가로 표시해야 합니다.

비율을 비교할 때는 분모의 범위(열람, 조회, 노출)를 명시하고 분자와 분모가 일치하도록 해야 합니다. 풀링된 표본 비율을 구할 때는 분자와 분모를 각각 합산한 뒤 나눕니다. 노트별 비율을 평균 내면 트래픽이 적은 노트와 많은 노트에 같은 가중치가 부여됩니다. 질문이 다르면 집계 정의도 달라야 합니다.

결과는 알고리즘 기여도 분석이 아니라 향후 콘텐츠 결정을 위한 입력으로 다뤄야 합니다. 오래된 노트에서 증가가 꾸준히 이어진다면 주제와 댓글 신호를 검토해 볼 만하지만, 스냅샷만으로 추천 메커니즘을 증명하거나 성과 재현을 보장할 수는 없습니다.

Xiaohongshu 분석에서는 모든 숫자마다 대상 식별자, 타임스탬프, 지표 정의를 명확히 밝혀야 합니다. 내보내기 범위가 제한적이더라도 날짜, 식별자, 차이, 누락 처리를 우선하는 편이 해석할 수 없는 성장 순위표보다 낫습니다.