Blog · BL-08

Beyond Totals in Xiaohongshu Data Analysis: Using Exported Notes and Historical Snapshots

Parse cumulative vs. interval metrics, snapshot dates, bookmark deltas, deduplication, and missing samples from creator exports to avoid cross-temporal and cross-note distortion.

To measure recent bookmark growth from exported Xiaohongshu notes, verify whether fields represent cumulative totals or interval deltas, then compare two observations for the same note under identical definitions. A single current-total snapshot cannot reconstruct daily growth history, and re-importing the same file daily does not produce reliable time-series data.

The xhs-trail project shared by DeanThompson on V2EX provides a concrete entry point: tracking note changes over time using creator-dashboard exports. The core takeaway is retaining multiple observations rather than adopting the author's feature set under a new name.

This note cross-checks source posts, author README files, and tooling docs through 2026-9-5 to outline independent processing methods. We did not install or audit the project or access authenticated Xiaohongshu backends; specific export endpoints, fields, and scope depend on your authorized account access.

Private Dashboard Data Differs From Public Note Data

Public notes, comment text, and creator stats answer distinct questions. Public content supports corpus analysis of public discussion, whereas creator reports support internal review of exposure, reads, or conversion. Reports must be inspected directly rather than estimating unobserved backend metrics from public like counts.

"What questions do users ask most in comments?" and "Which note converts better for bookmarks?" require different schemas—auditable comment samples versus explicitly defined bookmark and read definitions. Combining datasets with note URLs into a single uncredited table is invalid.

The internal Xiaohongshu Batch Comment Guide covers comment retrieval for known note lists, not private stats for competitor accounts. Map analytical questions to the correct ingestion entry point before selecting data.

For your own account, validate offline processing on clean exports before adding authorized data pipelines. Automated collection is not assumed superior to manual export, nor does export permission imply broad authorization.

Separate Stat Date, Export Date, and Import Timestamp

The author's README emphasizes explicitly tagging default filenames with data dates to prevent misattributing historical files to current runs. Ingesting a file today does not mean it reflects today's operational state.

Record at least three timestamps: the report's coverage window/point, actual export time, and ingestion time into the analytical system. Retain timezones when relevant. File modification times aid debugging file operations but should not serve as the sole source of truth for stat dates.

Backfilling Wednesday's report on Friday under ingestion-time partitioning marks Wednesday as missing and creates conflicting Friday snapshots. Subsequent subtraction will plot invalid trends.

Same-day multi-exports require explicit policy: retain distinct observation points or adopt the final confirmed revision. Design choices must be deterministic, not driven by file-drop order. Flag duplicate imports and preserve replacement provenance for revised files.

Subtract Cumulative Values, Not Interval Windows

Inspect field definitions before formulas. Cumulative bookmark counts across two snapshots yield net change over that interval. Subtracting rolling "last 7 days" windows yields a difference of rolling windows, not single-day net additions.

Synthetic illustration: on Monday at 09:00 a note has 120 cumulative bookmarks, and on Wednesday at 09:00 it has 165, resulting in a delta of 45. You can state that the cumulative value increased by a net amount of 45 between these points, but you cannot attribute all 45 to Wednesday or assert that Tuesday and Wednesday each increased by 22.5.

For average rates, label explicitly as "daily net change over 48-hour window" alongside real time intervals. Averages are derived outputs, not unobserved daily data points.

Do not floor negative diffs to zero without checking note identity, metric consistency, or old revision imports. Retain negative diffs as observed net decreases or pending review, avoiding fabricated platform-purge rationales. Counter diffs reconstruct tallies, not user-level event logs.

Join Snapshots by Note ID, Not Title

Titles change and recurring series overlap. Use authorized, validated note identifiers as cross-snapshot join keys, retaining account scope for multi-account sets. Title-plus-publish-time matching requires conflict resolution, not silent primary-key treatment.

Check duplicate keys pre-join. A note appearing twice per table produces four rows on a standard join, inflating counts and sample size. pandas merge docs document validate="one_to_one" for uniqueness validation and indicator for asymmetric record isolation.

Without pandas, retain uniqueness validation: confirm row semantics prior to join. Avoid max-value collapse on duplicates; duplicates signal re-exports versus mixed account/metric definitions with distinct handling requirements.

With SQLite snapshot storage, official UPSERT docs rely on uniqueness constraints for conflict resolution. DB enforcement prevents duplicate writes but cannot detect wrong snapshot dates. Define uniqueness across account, note, stat timestamp, and metric definition before handling duplicate imports as ignore, reject, or revision.

Missing File Does Not Mean Zero Growth

Absence from an export may reflect filter scope, incomplete files, or join failure. Absence does not prove deletion or reset cumulative metrics to zero.

Split snapshot comparisons into joint records, left-only records, and right-only records. Restrict direct diffs to identity- and definition-matched joint records. Newly surfaced notes with no prior baseline show current observation only, not zero-assumed history.

State report scope explicitly (e.g., "matched notes across two files") rather than sweeping labels like "all account growth this week." Account-wide aggregates require export-scope and missing-data accounting, not summing all subtractable rows.

Internal Multi-Platform Reputation Monitoring Blueprint applies the same rule: collection gaps must not convert to zero values in business logic across APIs or spreadsheets.

Normalize Observation Windows for Content Performance

A note published 30 days ago and one published yesterday differ in cumulative totals independently of quality. Compare equal post-publication observation windows; mark notes lacking sufficient snapshot coverage as non-comparable.

State denominator scope (reads, views, exposure) for rate comparison, ensuring numerator/denominator alignment. For pooled sample rates, sum numerators and denominators separately before dividing; per-note averaging weights low-traffic and high-traffic notes equally. Distinct questions require distinct aggregate definitions.

Treat results as inputs for future content decisions, not algorithmic attribution. Persistent incremental gains on an older note prompt review of topic and comment signals, but snapshots do not prove recommendation mechanisms or guarantee repeat performance.

Xiaohongshu analysis requires explicating object identity, timestamp, and metric definition per number. Prioritizing date, identity, delta, and missingness handling beats uninterpretable growth leaderboards even under restricted export scope.