Не ограничивайтесь итоговыми значениями в анализе данных Xiaohongshu: используйте экспорт заметок и исторические снимки

Чтобы измерить недавний прирост добавлений в избранное по экспортированным заметкам Xiaohongshu, проверьте, что отражают поля: накопительные итоги или приращения за интервал, а затем сопоставьте два наблюдения для одной и той же заметки, в которых показатели определены одинаково. По одному снимку текущих итогов нельзя восстановить историю ежедневного прироста, а ежедневный повторный импорт одного и того же файла не даёт надёжного временного ряда.

Проект xhs-trail, которым DeanThompson поделился на V2EX, даёт конкретную отправную точку: отслеживание изменений заметок во времени по выгрузкам из панели автора. Главный вывод — сохранять несколько наблюдений, а не перенимать набор функций автора под новым названием.

В этой заметке мы сверили исходные посты, README-файлы авторов и документацию инструментов по состоянию на 2026-9-5, чтобы описать независимые способы обработки. Мы не устанавливали и не проверяли проект и не обращались к закрытым бэкендам Xiaohongshu, требующим авторизации; конкретные эндпоинты экспорта, поля и объём данных зависят от уровня доступа вашего авторизованного аккаунта.

Данные закрытой панели отличаются от публичных данных заметок

Публичные заметки, тексты комментариев и статистика автора отвечают на разные вопросы. Публичный контент подходит для корпусного анализа открытых обсуждений, а отчёты автора нужны для внутренней оценки охвата, прочтений или конверсии. Отчёты нужно изучать напрямую, а не восстанавливать недоступные бэкенд-метрики по публичным счётчикам лайков. Публичную заметку можно прочитать по ссылке через API для получения данных о заметке Xiaohongshu от EveryInfra. Он возвращает публичные счётчики на момент чтения, например like_count и collect_count, а не данные бэкенд-отчётов.

«Какие вопросы пользователи чаще всего задают в комментариях?» и «Какая заметка лучше конвертирует в добавления в избранное?» требуют разных схем: в первом случае нужны проверяемые выборки комментариев, во втором — явно заданные определения добавлений в избранное и прочтений. Объединять наборы данных с URL заметок в одну таблицу без указания источников некорректно.

Внутреннее руководство по пакетному сбору комментариев Xiaohongshu описывает получение комментариев для известных списков заметок, а не закрытую статистику аккаунтов конкурентов. Прежде чем выбирать данные, сопоставьте аналитические вопросы с правильной точкой входа для загрузки.

Для собственного аккаунта сначала проверьте офлайн-обработку на чистых выгрузках и только потом добавляйте авторизованные конвейеры данных. Автоматизированный сбор не считается заведомо лучше ручной выгрузки, а разрешение на выгрузку не означает разрешения на более широкий доступ.

Разделяйте дату статистики, дату выгрузки и время импорта

В README автор подчёркивает, что в имена файлов по умолчанию нужно явно добавлять дату данных, чтобы исторические файлы не приписывались текущим запускам. Если файл загружен сегодня, это не значит, что он отражает сегодняшнее состояние.

Фиксируйте как минимум три метки времени: окно или момент, который охватывает отчёт, фактическое время выгрузки и время загрузки в аналитическую систему. Если это важно, сохраняйте часовые пояса. Время изменения файла помогает отлаживать файловые операции, но не должно быть единственным источником даты статистики.

Если отчёт за среду догружается в пятницу при партиционировании по времени загрузки, среда помечается как пропущенная, а за пятницу появляются конфликтующие снимки. Последующее вычитание построит некорректные тренды.

Для нескольких выгрузок за один день нужна явная политика: сохранять отдельные точки наблюдения или брать последнюю подтверждённую версию. Выбор должен быть детерминированным и не зависеть от порядка поступления файлов. Помечайте повторные импорты и сохраняйте историю замены для исправленных файлов.

Вычитайте накопительные значения, а не интервальные окна

Прежде чем писать формулы, изучите определения полей. Разница накопительных счётчиков добавлений в избранное между двумя снимками даёт чистое изменение за этот интервал. Вычитание скользящих окон «за последние 7 дней» даёт разницу скользящих окон, а не чистый прирост за один день.

Условный пример: в понедельник в 09:00 у заметки 120 накопленных добавлений в избранное, а в среду в 09:00 — 165, то есть дельта составляет 45. Можно утверждать, что между этими точками накопительное значение выросло на 45 в чистом выражении, но нельзя приписать все 45 среде или утверждать, что во вторник и в среду прирост составил по 22,5.

Для средних темпов явно указывайте подпись вида «среднесуточное чистое изменение за 48-часовое окно» вместе с реальными временными интервалами. Средние — это производные показатели, а не ненаблюдавшиеся ежедневные данные.

Не обнуляйте отрицательные разницы, не проверив идентичность заметки, согласованность метрики и наличие импортированных старых версий файлов. Сохраняйте отрицательные разницы как наблюдаемое чистое снижение или отправляйте их на проверку, не придумывая объяснений вроде чисток на платформе. Разницы счётчиков восстанавливают итоговые значения, а не журнал событий на уровне пользователей.

Объединяйте снимки по ID заметки, а не по заголовку

Заголовки меняются, а регулярные рубрики пересекаются. В качестве ключей объединения между снимками используйте авторизованные проверенные идентификаторы заметок, а для наборов из нескольких аккаунтов сохраняйте привязку к аккаунту. Сопоставление по заголовку и времени публикации требует разрешения конфликтов и не должно молча считаться первичным ключом.

Перед объединением проверяйте дубликаты ключей. Если заметка встречается дважды в каждой таблице, обычный join даст четыре строки и завысит счётчики и размер выборки. В документации pandas merge описаны validate="one_to_one" для проверки уникальности и indicator для выделения записей, которые есть только в одной из таблиц.

Без pandas проверка уникальности тоже нужна: перед объединением убедитесь, что понимаете смысл строк. Не схлопывайте дубликаты по максимальному значению: дубликаты могут означать как повторные выгрузки, так и смешение аккаунтов или определений метрик, и обрабатывать эти случаи нужно по-разному.

Если снимки хранятся в SQLite, разрешение конфликтов по официальной документации UPSERT опирается на ограничения уникальности. Ограничения на уровне БД предотвращают повторную запись, но не обнаружат неверную дату снимка. Задайте уникальность по аккаунту, заметке, метке времени статистики и определению метрики, прежде чем решать, игнорировать ли повторные импорты, отклонять их или считать новой версией.

Отсутствие файла не означает нулевой рост

Отсутствие записи в выгрузке может объясняться рамками фильтра, неполными файлами или ошибкой объединения. Оно не доказывает удаление и не обнуляет накопительные метрики.

Разбивайте сравнение снимков на общие записи, записи только из левой таблицы и записи только из правой. Прямые разницы считайте только для общих записей с совпадающими идентификаторами и определениями метрик. Для впервые появившихся заметок без предыдущей базы показывайте только текущее наблюдение, а не историю, принятую за нулевую.

Явно указывайте охват отчёта (например, «сопоставленные заметки из двух файлов») вместо слишком общих формулировок вроде «весь рост аккаунта за неделю». Агрегаты по всему аккаунту требуют учёта рамок выгрузки и пропущенных данных, а не простого суммирования всех строк, для которых получилось посчитать разницу.

Внутренний план мониторинга репутации на нескольких платформах применяет то же правило: пропуски при сборе данных не должны превращаться в нулевые значения в бизнес-логике, будь то API или таблицы.

Нормализуйте окна наблюдения при оценке эффективности контента

Заметка, опубликованная 30 дней назад, и заметка, опубликованная вчера, различаются по накопленным итогам независимо от качества. Сравнивайте одинаковые окна наблюдения после публикации, а заметки без достаточного покрытия снимками помечайте как несопоставимые.

При сравнении показателей указывайте охват знаменателя (прочтения, просмотры, показы) и следите, чтобы числитель и знаменатель соответствовали друг другу. Для показателя по объединённой выборке сначала отдельно суммируйте числители и знаменатели, а потом делите: усреднение по заметкам придаёт одинаковый вес заметкам с низким и высоким трафиком. Разные вопросы требуют разных определений агрегатов.

Воспринимайте результаты как входные данные для будущих решений по контенту, а не как атрибуцию работы алгоритма. Устойчивый прирост у старой заметки — повод изучить тему и сигналы в комментариях, но снимки не доказывают механизм рекомендаций и не гарантируют повторения результата.

Анализ Xiaohongshu требует для каждого числа явно указывать идентичность объекта, метку времени и определение метрики. Даже при ограниченных рамках выгрузки корректная обработка дат, идентичности, дельт и пропусков полезнее рейтингов роста, которые невозможно интерпретировать.