Så skapar du en veckorapport om publikens reaktion på en produktlansering på TikTok

Efter lanseringen av en app eller en ny funktion sprids återkopplingen snabbt över korta videor. En marknadsförare hittar några videor manuellt och skickar länkarna i en chatt, medan analytikern senare inte kan avgöra vilka inlägg som redan har räknats eller hur visningarna har förändrats. En praktisk lösning är att regelbundet samla sökresultat från några stabila sökfrågor, spara de ursprungliga svaren och skapa rapporter utifrån bekräftade fält.

I den här guiden ställer vi in en sådan insamling för ett konkret fall: ett team har lanserat en ny funktion och vill varje vecka följa offentliga TikTok-videor vars beskrivningar innehåller produktnamnet, en nyckelfunktion eller ett vanligt användarproblem. Detta är bevakning av ett urval som hittats genom sökning: API:et returnerar resultat utifrån sökfrågan och parametrarna, inte en garanterad lista över alla inlägg om lanseringen.

Bestäm först vilken signal teamet behöver

Ett stort antal visningar förklarar i sig dåligt vad teamet bör göra härnäst. Det är mer användbart att veta vilka frågor som återkommer, vilka användningsfall människor visar och vilka videor som får tydliga offentliga reaktioner. Formulera därför först några sökfraser och bestäm vilka fält som ska ingå i rapporten.

För en lansering av ett verktyg för schemaläggning av inlägg kan man till exempel testa sökningarna ”produktnamn”, ”innehållsplanerare” och ”hur schemalägger man TikTok”. Fraserna bör spegla olika sätt som människor kan beskriva samma ämne på. Anteckna dem tillsammans med startdatumet för bevakningen och regionen, så att senare datauttag kan jämföras med samma inställningar.

En grundläggande tabell kan innehålla insamlingstid, sökfras, videons identifierare, länk, beskrivning, skaparnamn, skaparens identifierare och tillgängliga värden för visningar, gilla-markeringar och kommentarer. TikTok Scraper API dokumenterar fält som aweme_id, desc, share_url, uppgifter om skaparen och en del statistik för sökresultat. Kontrollera det specifika fältet i varje objekt: enskilda mätvärden kan saknas.

Anslut till den dokumenterade sökfunktionen

Använd GET-rutten /searchVideo på basadressen https://tiktok.evelode.com för att söka efter videor. Dokumentationen listar den obligatoriska parametern keyword och de extra parametrarna count, cursor, date_posted, sort_by, region och cache_timeout. Tillåtna värden för datumfiltret omfattar this-week, och sorteringsalternativen är relevance, most-liked och date-posted. Kontrollera deras funktion och namn i TikTok API:s ruttöversikt.

Licensnyckeln skickas som en queryparameter med namnet license_key. Läs in den från miljövariabeln JSONSCRAPER_TIKTOK_LICENSE_KEY i produktionsskriptet. Lägg inte in hemligheten i källkoden och skriv inte ut den i loggar. Exemplet är avsett för Python 3.8+ och använder paketet requests:

import os
import requests

BASE_URL = "https://tiktok.evelode.com"
API_KEY = os.environ["JSONSCRAPER_TIKTOK_LICENSE_KEY"]


def search_videos(keyword, cursor=None):
    params = {
        "license_key": API_KEY,
        "keyword": keyword,
        "count": 20,
        "date_posted": "this-week",
        "sort_by": "date-posted",
        "region": "US",
    }
    if cursor is not None:
        params["cursor"] = cursor

    response = requests.get(
        f"{BASE_URL}/searchVideo",
        params=params,
        timeout=30,
    )
    response.raise_for_status()
    payload = response.json()

    if payload.get("status") != "ok":
        raise RuntimeError("TikTok API returnerade en annan status än ok")

    return payload["tiktok"]


result = search_videos("content planning app")
print("Hittade objekt:", len(result.get("aweme_list", [])))

Skriptet kontrollerar HTTP-fel och den övergripande svarsstatusen. Ett lyckat HTTP-svar garanterar inte i sig att sökningen innehåller videor: vid ett tomt urval kan listan vara tom. Vid den första körningen är det bra att spara hela svaret i säker lagring, så att de faktiska objekten kan jämföras med tabellen över normaliserade fält.

Hantera båda varianterna av söksvaret

Sökresultaten har en viktig strukturell egenskap. Videor kan ligga direkt i tiktok.aweme_list, men de kan också finnas i tiktok.search_item_list[].aweme_info. Om hanteraren bara läser den första listan kan den missa resultat som finns i den andra varianten.

Lägg till en liten normaliserare som stöder båda strukturerna och utan problem hoppar över objekt som saknar ett nästlat videoobjekt:

def extract_awemes(tiktok):
    items = list(tiktok.get("aweme_list") or [])

    for item in tiktok.get("search_item_list") or []:
        aweme = item.get("aweme_info")
        if aweme:
            items.append(aweme)

    return items


def normalize(aweme, keyword, collected_at):
    author = aweme.get("author") or {}
    stats = aweme.get("statistics") or {}

    return {
        "collected_at": collected_at,
        "keyword": keyword,
        "video_id": aweme.get("aweme_id"),
        "posted_at": aweme.get("create_time"),
        "description": aweme.get("desc"),
        "share_url": aweme.get("share_url"),
        "author_id": author.get("uid"),
        "author_name": author.get("nickname"),
        "views": stats.get("play_count"),
        "likes": stats.get("digg_count"),
        "comments": stats.get("comment_count"),
        "shares": stats.get("share_count"),
    }

Ett saknat värde förblir None. Ersätt det inte med noll: noll betyder ett uppmätt värde, medan None bevarar informationen om att fältet inte fanns med i svaret. Den skillnaden påverkar medelvärden, andelar och alla slutsatser för teamet.

Spara historiken, inte bara den senaste ögonblicksbilden

För att kunna se utvecklingen bör du lagra separata observationsposter. Videons identifierare passar för att deduplicera inlägg, men inte för att radera historik: när samma video dyker upp igen vid nästa insamling får du en ny observation. Till exempel kan observationspostens unika nyckel bestå av video_id och collected_at, medan länken och beskrivningen sparas i posten så att den enkelt kan kontrolleras.

Ett grundläggande SQLite-schema passar bra för en prototyp:

import sqlite3

conn = sqlite3.connect("tiktok_observations.sqlite3")
conn.execute("""
CREATE TABLE IF NOT EXISTS observations (
    video_id TEXT NOT NULL,
    collected_at TEXT NOT NULL,
    keyword TEXT NOT NULL,
    posted_at INTEGER,
    description TEXT,
    share_url TEXT,
    author_id TEXT,
    author_name TEXT,
    views INTEGER,
    likes INTEGER,
    comments INTEGER,
    shares INTEGER,
    PRIMARY KEY (video_id, collected_at, keyword)
)
""")
conn.commit()

I praktiken bör du normalisera insamlingstiden till UTC, spara den ursprungliga JSON-datan separat och lägga till en kolumn för schemaversion. Det ursprungliga svaret gör det möjligt att kontrollera omvandlingen på nytt när strukturen hos nya objekt skiljer sig från det vanliga mönstret. För inlägg som hittas med flera sökfrågor kan du lagra de matchande sökfraserna i en separat relaterad tabell eller slå ihop dem när du bygger rapporten.

Sidindelning: fortsätt endast med markören från svaret

Parametern cursor används för att fortsätta sökningen. Dess värde hämtas från föregående svar och skickas tillbaka utan omvandling. Insamlingen avslutas när has_more inte längre anger att det finns fler resultat eller när den angivna gränsen har nåtts. Behandla markören som ogenomskinlig: beräkna den inte själv och ersätt den inte med en sidräknare.

def collect_pages(keyword, max_pages=3):
    cursor = None
    collected = []

    for _ in range(max_pages):
        page = search_videos(keyword, cursor)
        collected.extend(extract_awemes(page))

        if not page.get("has_more"):
            break
        cursor = page.get("cursor")
        if cursor is None:
            break

    return collected

En gräns för antalet sidor gör att den återkommande uppgiften får en förutsägbar mängd förfrågningar. Logga antalet sidor och värdet på has_more vid körningen: det ger sammanhang till urvalsrapporten. Även med sidindelning beskriver resultatet de API-svar som hämtats och den angivna insamlingsgränsen; det är inte en uppskattning av alla inlägg på plattformen.

Skapa en rapport som går att upprepa

Kör insamlingen enligt ett schema varje vecka, eller oftare om teamet behöver signaler med tätare mellanrum. För varje körning ska du registrera listan över sökfrågor, parametrar, tidpunkt, antal mottagna objekt och antal unika identifierare. Räkna separat inlägg som upptäcktes för första gången under körningen och inlägg som redan har förekommit.

Fyra enkla vyer är användbara i rapporten:

• Nya videor: länkar, beskrivningar, publiceringsdatum och sökfrasen som hittade videon.
• Återkommande teman: gruppering av beskrivningar efter manuellt definierade kategorier, till exempel ”konfigurationsfel”, ”funktionsönskemål” och ”översikt av användningsfall”.
• Offentliga reaktioner: tillgängliga visningar, gilla-markeringar, kommentarer och delningar, visade tillsammans med observationstidpunkten.
• Signaler att kontrollera: nya formuleringar, vanliga frågor eller videor som en medarbetare bör undersöka.

Kalla inte skillnaden mellan två ögonblicksbilder för ”nya gilla-markeringar” utan att först kontrollera betydelsen och aktualiteten hos värdena i svaret. En korrekt formulering är ”mätvärdets värde i det senast mottagna svaret” och ”skillnaden mellan sparade ögonblicksbilder”. Då ser teamet exakt vad som har beräknats och kan öppna originalinlägget innan det fattar ett beslut.

Använd AI för klassificering, inte i stället för insamling

Efter normaliseringen kan du skicka videobeskrivningarna till en modell som klassificerar dem enligt förutbestämda kategorier. Skicka bara de textfält som behövs och be om ett strukturerat resultat: kategori, en kort motivering, en konfidensnivå och den del av beskrivningen som ligger till grund för etiketten. Spara originalinlägget tillsammans med etiketten så att analytikern kan granska tveksamma fall.

Arbetsflödet är fortfarande enkelt: schemaläggaren startar insamlingen; Python validerar svaret och sparar JSON; en separat uppgift normaliserar nya poster; klassificeraren behandlar endast nya beskrivningar; rapporten skapas från databasen och skickas till den kanal teamet valt. TikTok Scraper API tillhandahåller sökdata, medan klassificering och leverans av rapporten är er integrationslogik, som kan implementeras i Python, n8n eller Make.

För att minska brus bör du fastställa en kategorilista innan du skickar data till modellen och regelbundet kontrollera ett manuellt märkt urval. För korta eller tvetydiga beskrivningar är statusen ”otillräckligt sammanhang” användbarare än att tvinga fram en kategori. AI-etiketter hjälper till att sortera kön för granskning, medan slutsatser om användarproblem bör bekräftas genom att läsa inläggen och jämföra flera observationer.

Fel, omförsök och säker hantering av nyckeln

Ett nätverksanrop kan sluta med en tidsgräns, ett tillfälligt fel eller ett svar som inte går att tolka som JSON. Dela upp hanteringen i steg: anrop, kontroll av HTTP-statuskod, JSON-tolkning, kontroll av den övergripande statusen, normalisering och lagring. Använd ett begränsat antal omförsök med ökande väntetid vid tillfälliga fel. Logga permanenta fel för senare granskning och markera inte körningen som lyckad.

Förvara nyckeln i körmiljöns hemlighetshanterare eller som en miljövariabel. Eftersom API:et tar emot license_key i frågesträngen bör du undvika att logga hela URL:en och frågeparametrarna: då skulle hemligheten hamna i loggarna. För felsökning kan du logga rutten, svarskoden, tidsåtgången, sökfrasen och jobbets identifierare, efter att ha tagit bort nyckeln.

Ställ in schemat och urvalets storlek efter uppgiften och plattformens användarvillkor. Insamling av offentliga data bör begränsas till det som verkligen behövs för analysen; lagring av beskrivningar, länkar och skaparidentifierare bör beskrivas i teamets interna riktlinjer. API-svar och mätvärden kan vara ofullständiga eller ändras mellan observationer, så rapporten bör spara insamlingstidpunkten och varje rads ursprung.

Resultat: från manuella länkar till en verifierbar historik

När insamlingen är inställd får teamet en regelbundet uppdaterad lista över hittade videor, ursprungliga svar för granskning, en tabell över tillgängliga offentliga mätvärden och en översikt över återkommande teman. Det hjälper teamet att snabbare upptäcka frågor om den nya funktionen, hitta exempel på användningsfall och välja inlägg för manuell analys. Jämförelser mellan ögonblicksbilder visar hur de sparade värdena förändras för redan hittade videor, medan sökloggarna förklarar hur urvalet skapades.

Börja med en sökfråga och en låg sidgräns, kontrollera den faktiska svarsstrukturen och lägg sedan till fler formuleringar och ett schema. Innan du flyttar prototypen till produktionsmiljön bör du fastställa regler för deduplicering, lagring och felhantering. Aktuella rutter och parametrar finns i API:ets officiella dokumentation; en beskrivning av funktionerna och en möjlighet att börja testa finns på sidan för TikTok Scraper API.