Slik lager du en ukentlig TikTok-rapport om publikums reaksjoner på en produktlansering

Etter lanseringen av en app eller en ny funksjon spres tilbakemeldingene raskt på tvers av korte videoer. En markedsfører finner noen klipp manuelt og deler lenkene i en chat, og senere klarer ikke analytikeren å se hvilke innlegg som allerede er tatt med, eller hvordan visningstallene har endret seg. En praktisk løsning er å samle søkeresultater jevnlig med noen stabile søkefraser, lagre de opprinnelige svarene og lage rapporter basert på bekreftede felt.

I denne veiledningen setter vi opp en slik innsamling for et konkret tilfelle: Et team har lansert en ny funksjon og ønsker å følge med på offentlige TikTok-videoer ukentlig når beskrivelsene inneholder produktnavnet, en nøkkelfunksjon eller et typisk brukerproblem. Dette er overvåking av et funnet søkeutvalg: API-et returnerer resultater basert på søket og parameterne, ikke en garantert oversikt over alle innlegg om lanseringen.

Definer først hvilket signal teamet trenger

Et høyt antall visninger alene sier lite om hva teamet bør gjøre videre. Det er mer nyttig å vite hvilke spørsmål som går igjen, hvilke bruksscenarioer folk viser, og hvilke videoer som får tydelige offentlige reaksjoner. Formuler derfor først noen søkefraser og bestem hvilke felt som skal inngå i rapporten.

For eksempel kan man søke etter «produktnavn», «innholdsplanlegger» og «slik planlegger du TikTok-innlegg» ved lanseringen av et verktøy for planlegging av innlegg. Frasene bør gjenspeile ulike måter folk kan beskrive det samme temaet på. Noter dem sammen med datoen overvåkingen starter og regionen, slik at senere uttrekk kan sammenlignes med de samme innstillingene.

En minimumstabell kan inneholde innsamlingstidspunkt, søkefrase, video-ID, lenke, beskrivelse, skaperens navn, skaper-ID og tilgjengelige verdier for visninger, likerklikk og kommentarer. TikTok Scraper API dokumenterer felt som aweme_id, desc, share_url, forfatterinformasjon og deler av statistikken for søkeresultater. Kontroller hvert enkelt objekt for det aktuelle feltet: enkelte måltall kan mangle.

Koble til det dokumenterte søket

Bruk GET-ruten /searchVideo på basisadressen https://tiktok.evelode.com for å søke etter videoer. Dokumentasjonen oppgir den obligatoriske parameteren keyword og tilleggsparameterne count, cursor, date_posted, sort_by, region og cache_timeout. Gyldige verdier for datofilteret inkluderer this-week, mens sorteringsalternativene inkluderer relevance, most-liked og date-posted. Kontroller formål og navn i oversikten over TikTok API-rutene.

Lisensnøkkelen sendes som en query-parameter kalt license_key. I et produksjonsskript bør du lese den fra miljøvariabelen JSONSCRAPER_TIKTOK_LICENSE_KEY, ikke skrive hemmeligheten inn i kildekoden eller ta den med i logger. Eksempelet bruker Python 3.8+ og pakken 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 returnerte en status som ikke var ok")

    return payload["tiktok"]


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

Skriptet kontrollerer HTTP-feil og den overordnede svarstatusen. Et vellykket HTTP-svar garanterer ikke i seg selv at søket inneholder videoer: listen kan være tom hvis utvalget er tomt. Ved første kjøring er det nyttig å lagre hele svaret i et sikkert lager, slik at de faktiske objektene kan sammenlignes med tabellen over normaliserte felt.

Håndter begge formatene for søkeresultater

Søkeresultatene har en viktig strukturell særhet. Videoer kan ligge direkte i tiktok.aweme_list, eller de kan komme i tiktok.search_item_list[].aweme_info. Hvis behandleren bare leser den første listen, kan den gå glipp av resultater som finnes i det andre formatet.

Legg til en liten normaliserer som støtter begge strukturene og hopper over elementer uten et innebygd 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"),
    }

Manglende verdier forblir None. Ikke erstatt dem med null: null betyr en målt verdi, mens None bevarer informasjonen om at feltet ikke ble sendt. Denne forskjellen påvirker gjennomsnitt, andeler og alle konklusjoner teamet trekker.

Lagre historikken, ikke bare det nyeste øyeblikksbildet

For å følge utviklingen bør du lagre separate observasjonsrader. Video-ID-en egner seg til å deduplisere innlegg, men ikke til å slette historikk: Når den samme videoen dukker opp i neste innsamling, gir det et nytt observasjonspunkt. Den unike nøkkelen i observasjonstabellen kan for eksempel bestå av video_id og collected_at, mens lenken og beskrivelsen lagres i raden for enkel kontroll.

Et enkelt SQLite-skjema er nyttig for en prototype:

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 praksis bør du normalisere innsamlingstidspunktet til UTC, lagre den opprinnelige JSON-en separat og legge til en kolonne for skjemaversjon. Det opprinnelige svaret gjør det mulig å kontrollere transformasjonen på nytt når strukturen til nye objekter avviker fra det vanlige. Hvis innlegg oppdages gjennom flere søk, kan du lagre de samsvarende søkefrasene i en separat, tilknyttet tabell eller slå dem sammen når rapporten bygges.

Sideinndeling: fortsett bare med markøren fra svaret

Parameteren cursor brukes til å fortsette søket. Verdien hentes fra det forrige svaret og sendes tilbake uten endringer. Innsamlingen avsluttes når has_more ikke lenger viser at det finnes flere resultater, eller når den angitte grensen er nådd. Behandle markøren som ugjennomsiktig: Ikke beregn den selv eller erstatt den med et sidetall.

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 grense for antall sider gjør at den regelmessige jobben får et forutsigbart antall forespørsler. Loggfør antall sider og verdien av has_more under kjøringen: Det gir kontekst for utvalget rapporten bygger på. Selv med sideinndeling beskriver resultatet svarene som ble mottatt fra API-et og den angitte innsamlingsgrensen; det er ikke et estimat på alle innlegg på plattformen.

Lag en rapport som kan gjentas

Kjør innsamlingen etter en ukentlig tidsplan, eller oftere hvis teamet trenger hyppigere signaler. For hver kjøring bør du registrere søkelisten, parameterne, tidspunktet, antall mottatte objekter og antall unike ID-er. Tell separat innlegg som først ble sett i denne kjøringen, og innlegg som er observert tidligere.

Fire enkle visninger er nyttige i rapporten:

• Nye videoer: Lenker, beskrivelser, publiseringsdato og søkefrasen videoen ble funnet med.
• Gjentakende temaer: Grupper beskrivelsene etter manuelt definerte kategorier, for eksempel «oppsettfeil», «funksjonsønske» og «gjennomgang av bruksscenario».
• Offentlige reaksjoner: Tilgjengelige visninger, likerklikk, kommentarer og delinger, vist sammen med observasjonstidspunktet.
• Signaler som bør undersøkes: Nye formuleringer, vanlige spørsmål eller videoer en medarbeider bør se nærmere på.

Ikke kall forskjellen mellom to øyeblikksbilder for «nye likerklikk» uten å kontrollere betydningen og aktualiteten til verdiene i svaret. En mer presis formulering er «måltall i det siste mottatte svaret» og «forskjell mellom lagrede øyeblikksbilder». Da ser teamet hva som faktisk er beregnet, og kan åpne originalinnlegget før det tar en beslutning.

Bruk KI til klassifisering, ikke som erstatning for innsamling

Etter normalisering kan du sende videobeskrivelser til en modell som klassifiserer dem etter forhåndsdefinerte kategorier. Send bare de nødvendige tekstfeltene, og be om et strukturert resultat med kategori, en kort begrunnelse, sikkerhetsnivå og tekstutdraget som ligger til grunn for etiketten. Oppbevar originalinnlegget sammen med etiketten, slik at analytikeren kan kontrollere tvilstilfeller.

Arbeidsflyten forblir enkel: En planlegger starter innsamlingen; Python kontrollerer svaret og lagrer JSON; en separat jobb normaliserer nye rader; klassifisereren behandler bare nye beskrivelser; og rapporten bygges fra databasen og sendes til kanalen teamet har valgt. TikTok Scraper API leverer søkeresultatene, mens klassifisering og distribusjon av rapporten er integrasjonslogikk du selv kan implementere i Python, n8n eller Make.

For å redusere støy bør du definere en kategoriliste før du sender tekst til modellen, og jevnlig kontrollere et manuelt merket utvalg. For korte eller tvetydige beskrivelser er statusen «ikke nok kontekst» nyttigere enn å tvinge fram en kategori. KI-etiketter kan hjelpe med å sortere køen for gjennomgang, men konklusjoner om brukerproblemer bør bekreftes ved å lese innleggene og sammenligne flere observasjoner.

Feil, gjentatte forsøk og sikker håndtering av nøkkelen

Nettverksforespørsler kan ende med tidsavbrudd, midlertidige feil eller svar som ikke kan tolkes som JSON. Del behandlingen inn i trinn: forespørsel, kontroll av HTTP-statuskode, JSON-parsing, kontroll av den overordnede statusen, normalisering og lagring. Ved midlertidige feil bør du bruke et begrenset antall nye forsøk med stadig lengre pauser. Loggfør permanente feil for senere gjennomgang, og ikke marker kjøringen som vellykket.

Oppbevar nøkkelen i en hemmelighetstjeneste for kjøremiljøet eller som en miljøvariabel. Siden API-et tar imot license_key i forespørselsstrengen, må du unngå å loggføre hele URL-en og parameterne: Der vil hemmeligheten være synlig. For feilsøking kan du loggføre ruten, svarskoden, varigheten, søkefrasen og jobb-ID-en, men fjern nøkkelen fra loggene.

Sett opp tidsplan og utvalgsstørrelse i tråd med oppgaven og plattformens bruksvilkår. Innsamling av offentlige data bør begrenses til det som faktisk trengs for analysen. Teamets interne retningslinjer bør beskrive lagringen av beskrivelser, lenker og forfatter-ID-er. API-svar og måltall kan være ufullstendige eller endres mellom observasjoner, så rapporten bør bevare innsamlingstidspunktet og opphavet til hver rad.

Resultatet: fra manuelle lenker til en historikk som kan kontrolleres

Når løsningen er satt opp, får teamet en oppdatert liste over videoer som er funnet, de opprinnelige svarene for revisjon, en tabell over tilgjengelige offentlige måltall og en oversikt over temaer som går igjen. Dette gjør det enklere å oppdage spørsmål om en ny funksjon, finne eksempler på bruksscenarioer og velge innlegg for manuell analyse. Sammenligning av øyeblikksbilder viser hvordan de lagrede verdiene for tidligere funne videoer endrer seg, mens søkeloggen forklarer hvordan utvalget ble satt sammen.

Begynn med ett søk og en lav sidegrense, kontroller den faktiske svarstrukturen, og legg deretter til flere søkefraser og en tidsplan. Før du flytter prototypen til produksjon, bør du fastsette regler for deduplisering, lagring og feilhåndtering. Oppdaterte ruter og parametere finnes i den offisielle API-dokumentasjonen; beskrivelse av funksjonene og tilgang til testing finnes på siden for TikTok Scraper API.