Ik Bouwde een AI-Merkmonitor Die Elke LLM Bijhoudt
Het marketingteam van Freshdesk had een probleem dat ze niet kenden.
Hun product werd aanbevolen door Google Search. Maar wanneer iemand ChatGPT opende — dat inmiddels 900 miljoen wekelijks actieve gebruikers heeft per februari 2026 — en typte "wat is de beste klantenservicetool voor een team van 50 personen?", stond Freshdesk niet in het antwoord. Gorgias wel. Zendesk wel. Intercom wel. Freshdesk? Onzichtbaar.
En niemand in hun team had er enig idee van, want niemand controleerde het.
Dat is het probleem dat ik wilde oplossen met één codesessie, een Next.js-app en een scraping API die ik nog nooit eerder had gebruikt. Een werkende applicatie die ChatGPT, Perplexity, Gemini, Grok, Copilot en Google Search bevraagt voor elke merknaam die je invoert — en je vervolgens precies vertelt waar je verschijnt, waar je ontbreekt, en hoe het sentiment eruitziet als je wel aanwezig bent.
Het bouwen kostte een hele middag. En het ding dat het hele project bijna deed mislukken? Een kloof tussen hoe AI-platforms reageren via hun API's versus wat ze gebruikers daadwerkelijk tonen in de browser.
Waarom Je Merk's Google-Ranking Niet Langer het Volledige Verhaal Vertelt
Het zoekvolume via zoekmachines zal naar verwachting met 25% dalen tegen 2026, nu gebruikers overstappen op AI-chatbots voor informatieontdekking. ChatGPT alleen heeft in januari 2026 meer dan 1 miljard geschatte maandelijks actieve gebruikers bereikt. Perplexity groeit snel. Gemini is ingebakken in elk Google-product.
Het oude SEO-playbook werkt nog steeds. Maar er is nu een parallel ontdekkingskanaal waar de regels compleet anders zijn. LLMs ranken geen pagina's. Ze bevelen merken aan. En hier is het verontrustende deel: er is minder dan 1 op 100 kans dat ChatGPT dezelfde lijst met merkaanbevelingen geeft in twee antwoorden op dezelfde prompt.
Wat betekent dat als je de LLM-zichtbaarheid van je merk vorige dinsdag controleerde en het er goed uitzag, het vrijdag misschien verdwenen is.
Ik wist dat tools zoals Otterly.ai, Semrush's AI Visibility Toolkit en Siftly bestonden. Ze vragen $200-500/maand voor dit soort monitoring. Maar ik wilde de mechanica begrijpen — de beste manier om iets te begrijpen is het zelf te bouwen.
Het API vs. Browser Probleem Waarover Niemand Je Waarschuwt
Mijn eerste instinct was voor de hand liggend: de API's aanroepen. Behalve dat het zo niet werkt.
De respons die je krijgt van ChatGPT's API is niet dezelfde respons die een gebruiker ziet in de browser. De webapplicatie voegt extra optimalisaties toe — citaatopmaak, bronkoppelingen, responsherstructurering. De API geeft je een ruwe voltooiing. De browser geeft je een samengestelde ervaring met bronnen, links en context die de API eruit filtert.
En dan is er Copilot. Helemaal geen publieke API. Als je wilt weten wat Copilot aanbeveelt, moet je zien wat de daadwerkelijke browserinterface toont.
Geolocatie voegt een extra laag toe. Wanneer een gebruiker in Londen Perplexity vraagt "beste projectmanagementtool", krijgt hij andere resultaten dan een gebruiker in San Francisco. API-aanroepen vangen die variatie niet op. Het scrapen van de gebruikersgerichte interface — vanuit een proxy in de doelgeografie — wel.
Dit inzicht vernietigde mijn plan om "gewoon de API's aan te roepen" binnen het eerste uur. Als het doel is te zien wat echte gebruikers zien, moet je de daadwerkelijke gebruikersinterface scrapen.
Dat is waar Bright Data de build binnenkwam.
Bright Data's AI Scrapers: Wat Ze Eigenlijk Doen
Bright Data's AI scraper-product: vooraf gebouwde scrapers voor AI-platforms die gestructureerde data retourneren — responstekst, bronnen, citaten en metadata — van de gebruikersgerichte webinterfaces van ChatGPT, Gemini AI Mode, Copilot, Perplexity en Google SERP.
Prijzen starten bij $0,001 per record op basis van betalen per gebruik.
Maar de implementatie heeft een eigenaardigheid. Het scrapen van AI-platforms is niet direct. Wanneer je een scrape van een ChatGPT-respons triggert, moet de scraper de pagina laden, wachten tot het model zijn volledige antwoord genereert (10-30 seconden), en vervolgens het resultaat extraheren en structureren. Als de scrape langer duurt dan ongeveer 60 seconden, geeft Bright Data een snapshot-ID terug in plaats van het resultaat. Je pollt dan dat snapshot-ID met GET-verzoeken totdat het resultaat klaar is.
Dit is het trigger-poll-download patroon, en het heeft de architectuur van de app fundamenteel bepaald.
De Stack: Next.js, SQLite, Drizzle en een Codeeragent
Dit is waar ik mee begon:
- Next.js met React voor de frontend en API-routes
- SQLite met Drizzle ORM voor lokale persistentie
- Bright Data API voor het scrapen van alle zes platforms
- Claude Code als primaire codeeragent (met een overstap naar Cursor halverwege)
Het databaseschema: drie tabellen — brands, scans en results. Elk resultaat slaat de providernaam op, of het merk werd vermeld, het sentiment, de ruwe responstekst en eventuele bronnen.
Ik begon te bouwen met Claude Code, waarbij ik de Bright Data API-documentatie als context aanleverde. Dit is waar context engineering belangrijk was — ik zei niet zomaar "bouw me een scraper." Ik plakte de volledige API-documentatie voor de scraper van elke provider erin.
De eerste versie kwam in ongeveer twee uur samen.
Wat Er Fout Ging: De Foutmodi van de Eerste Architectuur
Drie problemen kwamen naar voren binnen de eerste dag van testen.
Probleem 1: Time-out cascades. Wanneer de scrape van één provider langer duurde dan verwacht, bereikte de API-route-handler de standaard time-out van Next.js. De hele scan mislukte dan.
Probleem 2: Geen herstel. Als ik mijn laptop dichtklapte, verdwenen alle lopende scans. Geen manier om te hervatten.
Probleem 3: Snelheidsbeperkingen. Wanneer ik meerdere merkscannen tegelijk probeerde uit te voeren, liep ik tegen snelheidsbeperkingen aan zonder een schoon mechanisme voor nieuwe pogingen.
Inngest: De Achtergrondwachtrij Die Alles Oploste
Inngest: duurzame workfloworchestratie voor serverloze omgevingen. Je definieert functies die als achtergrondtaken draaien, en Inngest behandelt wachtrijen, nieuwe pogingen, gelijktijdigheidsbeperkingen en persistentie. Als je server crasht, hervat de taak zodra hij weer beschikbaar is.
Zo veranderde de architectuur:
Ervoor (kwetsbaar):
- Gebruiker klikt op "Scan"
- API-route triggert alle zes scrapers synchroon
- Wacht op alle resultaten of treedt time-out op
Erna (duurzaam):
- Gebruiker klikt op "Scan"
- API-route stuurt een event naar Inngest
- Inngest-functie triggert alle zes scrapers parallel, elk als een aparte stap
- Elke stap behandelt zijn eigen poll-lus onafhankelijk
- Resultaten worden naar SQLite geschreven zodra ze klaar zijn
- Frontend pollt op updates en rendert resultaten stapsgewijs
// inngest/functions/scan-brand.ts
import { inngest } from "../client";
export const scanBrand = inngest.createFunction(
{
id: "scan-brand",
concurrency: { limit: 3 }, // avoid rate limits
},
{ event: "brand/scan.requested" },
async ({ event, step }) => {
const { brandName, prompt, providers } = event.data;
const results = await Promise.allSettled(
providers.map((provider) =>
step.run(`scrape-${provider}`, async () => {
const snapshot = await triggerScrape(provider, prompt);
const result = await pollForResult(snapshot.id);
const analysis = analyzeMention(result, brandName);
await saveResult(brandName, provider, analysis);
return analysis;
})
)
);
return results;
}
);
De parameter concurrency: { limit: 3 } loste het probleem met snelheidsbeperkingen op.
De Overstap van Claude Code naar Cursor
Ik stapte halverwege over naar Cursor met Opus 4.6 — toen ik de Bright Data poll-logica implementeerde.
Het probleem was mijn context engineering, niet het hulpmiddel. Wanneer je documentatie voor meerdere API's aan een codeeragent aanlevert, moet je chirurgisch zijn over welke context in elke prompt gaat. In plaats van alle zes providerdocumentaties tegelijk te plakken, had ik het werk moeten structureren als zes opeenvolgende taken, elk met alleen de documentatie van de relevante provider.
Na de overstap voltooide ik de resterende providerimplementaties in ongeveer 90 minuten.
Hoe de Scanresultaten Er Eigenlijk Uitzien
Wanneer een scan voltooid is, rendert de app resultaten als een raster van providerkaarten. Elke kaart toont:
- Providernaam (ChatGPT, Perplexity, Gemini, Grok, Copilot, Google Search)
- Vermeldingsstatus — werd het merk vermeld? Ja/Nee
- Sentiment — positief, neutraal of negatief?
- Responsfragment — het relevante deel van het antwoord van de AI
- Bronnen/citaten — eventuele links die het AI-platform heeft opgenomen
Omgaan met de Zes Providers: Wat Elke Provider Vereist
ChatGPT: Vereist een prompt-veld. Accepteert optioneel een country voor geolocatie.
Perplexity: Vereist een prompt. Retourneert gestructureerde tekst met inline citaten.
Gemini AI Mode: Vereist zowel een url als een prompt.
Grok: Vereist een prompt. Retourneert door X-platform beïnvloede responses.
Copilot: Vereist een url die verwijst naar de Copilot-webinterface. Er bestaat geen publieke API.
Google SERP: Vereist een query (niet prompt — andere veldnaam).
const PROVIDER_CONFIG = {
chatgpt: {
datasetId: process.env.BRIGHTDATA_CHATGPT_ID,
buildPayload: (prompt: string, country?: string) => ({
prompt,
...(country && { country }),
}),
},
perplexity: {
datasetId: process.env.BRIGHTDATA_PERPLEXITY_ID,
buildPayload: (prompt: string) => ({ prompt }),
},
copilot: {
datasetId: process.env.BRIGHTDATA_COPILOT_ID,
buildPayload: (prompt: string) => ({
url: "https://copilot.microsoft.com",
prompt,
}),
},
// ... vergelijkbaar voor gemini, grok, google
};
Wat Ik Anders Zou Doen bij een Tweede Bouw
Ik had vanaf het begin met Inngest moeten beginnen. Het eerst bouwen van de synchrone versie kostte me vier uur aan herwerk.
Ik over-engineerde het databaseschema. Alles kon leven als een JSON-blob in één enkele raw_response-kolom.
Ik had het planningssysteem vanaf dag één moeten bouwen. Enkelvoudige scans zijn nuttig. Maar de echte waarde is het bijhouden van veranderingen over tijd.
Foutafhandeling moest granulairer zijn. "Snelheidsbeperkingsfout" (opnieuw proberen over 30 seconden) verschilt van "element niet gevonden" (de UI is veranderd, waarschuw me) en verschilt van "geen resultaten" (geldige respons, merk wordt gewoon niet vermeld).
De Business Case
Bedrijven zoals Otterly.ai en Siftly vragen $200-500/maand voor LLM-monitoring. Het zichtbaarheidskloof tussen traditionele SEO en AI-aanbevelingen is reëel en groeit.
Bedrijven die de eerste pagina van Google domineren, hebben vaak een zwakke aanwezigheid in LLM-aanbevelingen. De vaardigheden die je goed laten scoren in traditionele zoekopdrachten zijn niet dezelfde signalen die LLMs ertoe aanzetten je aan te bevelen. LLMs prioriteren semantische relevantie en structurele duidelijkheid boven domeinautoriteit.
Het Systeem Uitbreiden: Planning, Waarschuwingen en Trendanalyse
Geplande scans met behulp van Inngest's cron-trigger:
export const scheduledScan = inngest.createFunction(
{ id: "scheduled-brand-scan" },
{ cron: "0 */6 * * *" }, // elke 6 uur
async ({ step }) => {
const brands = await step.run("get-brands", () =>
db.select().from(brands).where(eq(brands.active, true))
);
for (const brand of brands) {
await step.sendEvent("trigger-scan", {
name: "brand/scan.requested",
data: {
brandName: brand.name,
prompt: brand.defaultPrompt,
providers: brand.providers
},
});
}
}
);
Waarschuwingen: Stel je voor dat je een Slack-melding krijgt: "Jouw merk werd gisteren door ChatGPT vermeld, maar wordt vandaag niet vermeld voor 'beste CRM voor startups.'"
Trendanalyse: "Toen ik dat gedetailleerde vergelijkingsartikel publiceerde, nam mijn LLM-vermeldingspercentage toe?"
Het Productieklare Patroon dat het Stelen Waard Is
De combinatie van Bright Data + Inngest + Next.js geeft je een patroon dat het moeilijkste deel van backend-ontwikkeling aanpakt: onbetrouwbare dingen betrouwbaar maken.
Als je één ding meeneemt uit dit bouwlogboek: stop met proberen onbetrouwbare externe aanroepen betrouwbaar te maken via foutafhandeling alleen. Gebruik een workflow-engine die onbetrouwbaarheid als standaard beschouwt.
Veelgestelde Vragen
Wat is AI-merkmonitoring en waarom is het belangrijk?
AI-merkmonitoring houdt bij hoe AI-platforms zoals ChatGPT, Perplexity en Gemini je merk vermelden wanneer gebruikers om aanbevelingen vragen. Nu ChatGPT in vroeg 2026 meer dan 900 miljoen wekelijks actieve gebruikers overschreed, zijn AI-platforms een primair ontdekkingskanaal geworden.
Kun je ChatGPT's API gebruiken in plaats van scrapen?
API-responses wijken aanzienlijk af van de gebruikersgerichte webinterface. Voor nauwkeurige merkmonitoring vangt het scrapen van de daadwerkelijke gebruikersinterface op wat echte gebruikers zien.
Hoeveel kost het om te draaien?
Bright Data's API begint bij $0,001 per record. Voor 10 merken over 6 providers dagelijks is dat ongeveer $54/maand — aanzienlijk minder dan commerciële alternatieven à $200-500/maand.
Waarom veranderen LLM-merkaanbevelingen tussen zoekopdrachten?
LLM-responses zijn van nature niet-deterministisch. Minder dan 1 op 100 kans dat ChatGPT dezelfde merklijst geeft in twee responses op identieke prompts.
Wat is het trigger-poll-download patroon?
Een asynchrone workflow waarbij je een langlopende operatie triggert, pollt op voltooiing, en vervolgens het resultaat downloadt zodra het klaar is.
Laten We Samenwerken
- Fiverr: fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited: ramlit.com
- ColorPark: colorpark.io
- xCyberSecurity: xcybersecurity.io
