Michael JohnsonМаркетинговая команда замечает, что в TikTok появляются ролики о новом продукте, но вручную проверять несколько хэштегов каждый день трудно. Чтобы сравнивать публикации и видимые показатели во времени, нужен повторяемый сбор с меткой времени, архивом исходных ответов и проверкой изменений.
Для такого прототипа подходит TikTok Scraper API от jsonscraper: на странице продукта перечислены маршруты для хэштегов, пользователей, видео и поиска. Первый шаг — проверить нужный маршрут и формат ответа в Postman, затем перенести подтверждённую конфигурацию в Python. Так можно построить повторяемый процесс, извлекая только те поля, которые действительно присутствуют в ответе.
Задача: увидеть динамику, а не отдельный популярный ролик
Одна публикация с большим числом просмотров может привлечь внимание, но для планирования кампании полезнее понять, сколько новых видео обнаруживается по теме и как меняются публичные показатели уже найденных публикаций. Например, интернет-магазину спортивных товаров важно оценить поток роликов о конкретном виде тренировок, прежде чем готовить связанные с ним креативы.
Ручная проверка затрудняет сравнение: набор результатов меняется, показатели накапливаются, а сотрудники могут записывать их в разных форматах. Если сохранять снимок каждого запуска вместе со временем сбора и исходным JSON, команда получает историю собственных наблюдений и может повторно обработать данные при изменении аналитической схемы.
Автоматизация состоит из нескольких шагов: проверить маршрут и параметры, запросить данные по расписанию, сохранить ответ, подтвердить его структуру и затем извлечь нужные поля. Полученную таблицу можно использовать для графиков, тематической классификации или отчёта.
Что подтверждает документация API
На странице TikTok Scraper API указан базовый адрес https://tiktok.evelode.com и перечислены маршруты класса Hashtag: GET /getHashtagInfo, GET /getHashtagFeed и GET /getHashtagFeedByID. Страница также показывает пример запроса к другому маршруту с параметром license_key и описывает настройку ключа в коллекции Postman.
Для GET /getHashtagFeed официальная спецификация маршрутов указывает обязательный параметр query (URL хэштега или имя тега), а также необязательные cursor, count, region и cache_timeout. В ответе ленты ожидается массив tiktok.aweme_list; среди перечисленных полей элемента — aweme_id, desc, create_time, share_url, данные автора и statistics. Отдельные поля могут отсутствовать, поэтому перед обработкой проверяйте фактический JSON.
В коллекции jsonscraper в Postman удобно выполнить пробный запрос, сверить фактический ответ и получить тестовый пример для последующей проверки кода. Для авторизации передаётся license_key; ключ храните в переменной окружения и не выводите в логи.
Сначала проверьте запрос в Postman
Начните с одного тестового хэштега. В коллекции выберите маршрут ленты хэштега, задайте license_key способом, указанным в документации, и передайте имя тега в query. При необходимости добавьте count и код страны в region. Выполните запрос и проверьте HTTP-статус, поле верхнего уровня status и содержимое tiktok.aweme_list.
Сохраните успешный ответ как тестовый JSON-файл. По нему проверьте наличие идентификатора публикации, описания, времени публикации, ссылки и статистики. Включайте поле в аналитическую схему только после того, как убедились, что оно приходит в нужном типе.
Ключ API храните в переменной окружения, а не в исходном файле. Если ключ передаётся в URL, маскируйте его при журналировании запроса, чтобы полный адрес не попадал в логи.
Python-клиент для запроса и архивации
Маршрут и имена параметров ниже соответствуют опубликованной спецификации: для хэштега используется query, а авторизация передаётся через license_key. Пример совместим с Python 3.8+ и сохраняет исходный ответ вместе с метаданными запуска.
import json
import os
from datetime import datetime, timezone
from pathlib import Path
import requests
BASE_URL = "https://tiktok.evelode.com"
API_KEY = os.environ["JSONSCRAPER_TIKTOK_LICENSE_KEY"]
def fetch_hashtag_feed(hashtag: str) -> dict:
params = {
"license_key": API_KEY,
"query": hashtag,
"count": 20,
}
response = requests.get(
f"{BASE_URL}/getHashtagFeed",
params=params,
timeout=45,
)
response.raise_for_status()
payload = response.json()
if payload.get("status") != "ok":
raise RuntimeError("API вернул статус, отличный от ok")
return payload
def archive_response(hashtag: str, payload: dict) -> Path:
collected_at = datetime.now(timezone.utc).isoformat()
safe_tag = hashtag.lstrip("#").replace("/", "_")
output_dir = Path("data/raw") / safe_tag
output_dir.mkdir(parents=True, exist_ok=True)
filename = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ.json")
file_path = output_dir / filename
file_path.write_text(
json.dumps(
{
"hashtag": hashtag,
"collected_at": collected_at,
"response": payload,
},
ensure_ascii=False,
indent=2,
),
encoding="utf-8",
)
return file_path
if __name__ == "__main__":
tag = "#примертемы"
payload = fetch_hashtag_feed(tag)
saved_path = archive_response(tag, payload)
print(f"Архив сохранён: {saved_path}")
Перед запуском задайте переменную окружения JSONSCRAPER_TIKTOK_LICENSE_KEY. Запрос использует подтверждённый query и ограничивает число запрошенных элементов через count. В ответе проверяются внешний статус и JSON-статус; архив сохраняет фактические данные для последующей обработки. Проверьте запуск на одном хэштеге, прежде чем добавлять расписание и аналитику.
Как добавить нормализацию без хрупких предположений
В ответе ленты документация указывает массив tiktok.aweme_list. Перед преобразованием проверьте, что tiktok — объект, а aweme_list — список. Для каждого элемента извлекайте только подтверждённые поля, например aweme_id, desc, create_time, share_url и значения из statistics, если они присутствуют.
Внутренняя таблица может содержать хэштег запроса, время сбора, идентификатор видео и выбранные метрики. Для необязательного или отсутствующего показателя сохраняйте пустое значение: отсутствие метрики отличается от измеренного нуля. Исходные ответы храните отдельно, чтобы повторно построить таблицу без нового запроса.
Если формат ответа изменится, проверка типов должна остановить некорректную обработку и создать диагностическое сообщение. Сохраните тестовый JSON рядом с тестом парсера: он поможет проверить, что новая версия кода продолжает обрабатывать известную схему.
Метрики на основе повторных наблюдений
Если ответ предоставляет счётчики, сохраняйте каждое наблюдение с временной меткой. Для одной публикации сравните значения при двух запусках и вычислите наблюдаемое изменение за интервал. Для сопоставления используйте aweme_id, указанный в спецификации, и проверьте его наличие в каждом элементе.
Количество впервые обнаруженных публикаций за день можно считать по результатам ваших запусков. Эта метрика описывает поток, возвращённый конкретными запросами при заданных параметрах и расписании. Она позволяет сравнивать собственные снимки, если метод сбора остаётся последовательным.
Минимальный отчёт может показывать число новых обнаруженных публикаций по дням, распределение доступных счётчиков и изменение значений у видео, найденных повторно. Добавьте время запроса и имя исходного файла, чтобы аналитик мог проверить происхождение каждой записи.
Расписание и обработка ошибок
Когда запрос и разбор проверены, запускайте скрипт по расписанию — например, через cron, GitHub Actions или оркестратор данных. Список хэштегов вынесите в отдельную конфигурацию, чтобы добавлять и удалять темы без изменения логики клиента.
Для автоматического запуска задайте тайм-аут, ограниченное число повторов при временных сетевых ошибках и журналирование HTTP-статуса и длительности запроса. Не записывайте ключ в журнал. При ошибке разбора сохраняйте безопасные диагностические сведения и уведомляйте ответственного сотрудника.
Спецификация поддерживает пагинацию параметром cursor для ленты хэштега. Если она нужна, сохраняйте курсор из ответа и передавайте его в следующем запросе без преобразования; обрабатывайте только возвращённые результаты и контролируйте has_more, если оно присутствует. Если запросы по нескольким хэштегам возвращают одну публикацию, выберите ключ дедупликации исходя из задачи: учитывать публикацию отдельно для каждого хэштега или считать только уникальные видео.
Классификация и автоматизация отчётов
После получения проверенных строк можно добавить классификацию описаний видео по заданным темам: поле desc указано в схеме элемента. Модель может группировать публикации по формату — например, инструкции, обзоры или пользовательский опыт. Сохраняйте исходный текст, метку, версию инструкции и результат, а сомнительные случаи направляйте на проверку человеку.
Числовые показатели рассчитывайте обычным кодом, чтобы повторные запуски давали воспроизводимую арифметику. Классификатор полезен для обработки текста; итоговый отчёт должен связывать выводы с конкретными строками и датами наблюдений.
В no-code-сценарии те же этапы можно связать в автоматизаторе: расписание, HTTP-запрос по проверенной конфигурации, проверка ответа, сохранение JSON, преобразование подтверждённых полей и уведомление об ошибке. Сначала проверьте контракт в Postman, затем переносите его в Python, n8n или Make.
Ожидаемый результат и следующий шаг
После настройки у команды будет архив ответов API и таблица наблюдений по выбранным хэштегам. Они помогут находить новые публикации, сравнивать доступные показатели во времени и выбирать материалы для содержательного анализа. Для сопоставимых результатов сохраняйте единое расписание, параметры запросов и правила нормализации.
Начните с одного маршрута и одного реального ответа: выполните запрос /getHashtagFeed с параметром query, сохраните JSON и затем добавляйте разбор полей и расписание. Страница TikTok Scraper API показывает базовый адрес и карту маршрутов, а спецификация маршрутов содержит имена параметров для реализации клиента.