Ich Baute einen KI-Markenmonitor, der Jeden LLM Verfolgt
Das Marketingteam von Freshdesk hatte ein Problem, von dem es nichts wusste.
Ihr Produkt wurde von Google Search empfohlen. Aber wenn jemand ChatGPT öffnete — das inzwischen 900 Millionen wöchentlich aktive Nutzer im Februar 2026 hat — und tippte "Was ist das beste Kundensupport-Tool für ein 50-Personen-Team?", war Freshdesk nicht in der Antwort. Gorgias schon. Zendesk schon. Intercom schon. Freshdesk? Unsichtbar.
Und niemand in ihrem Team hatte eine Ahnung davon, weil niemand nachschaute.
Das ist das Problem, das ich mit einer einzigen Codesitzung, einer Next.js-App und einer Scraping-API, die ich noch nie zuvor verwendet hatte, lösen wollte. Eine funktionierende Anwendung, die ChatGPT, Perplexity, Gemini, Grok, Copilot und Google Search nach jedem Markennamen abfragt, den man eingibt — und dann genau sagt, wo man erscheint, wo nicht, und wie das Sentiment aussieht, wenn man erscheint.
Der Bau dauerte einen ganzen Nachmittag. Und das, was das gesamte Projekt fast zum Scheitern gebracht hätte? Eine Lücke zwischen der Art, wie KI-Plattformen über ihre APIs reagieren, versus dem, was sie Nutzern tatsächlich im Browser zeigen.
Warum das Google-Ranking Ihrer Marke Nicht Mehr die Ganze Geschichte Erzählt
Das Suchmaschinenvolumen soll bis 2026 um 25 % sinken, da Nutzer auf KI-Chatbots zur Informationsfindung umsteigen. ChatGPT allein hat im Januar 2026 mehr als 1 Milliarde geschätzte monatlich aktive Nutzer überschritten. Perplexity wächst schnell. Gemini ist in jedes Google-Produkt eingebettet.
Das alte SEO-Playbook funktioniert noch. Aber es gibt jetzt einen parallelen Entdeckungskanal, in dem die Regeln völlig anders sind. LLMs ranken keine Seiten. Sie empfehlen Marken. Und hier ist der beunruhigende Teil: Es gibt weniger als eine 1-von-100-Chance, dass ChatGPT in zwei Antworten auf dieselbe Anfrage dieselbe Liste von Markenempfehlungen gibt.
Was bedeutet: Wenn Sie die LLM-Sichtbarkeit Ihrer Marke letzten Dienstag überprüft haben und sie gut aussah, könnte sie bis Freitag verschwunden sein.
Ich wusste, dass Tools wie Otterly.ai, Semrush's AI Visibility Toolkit und Siftly existierten. Sie verlangen $200-500/Monat für diese Art von Monitoring. Aber ich wollte die Mechanik verstehen — der beste Weg, etwas zu verstehen, ist es selbst zu bauen.
Das API vs. Browser Problem, Vor dem Niemand Warnt
Mein erster Instinkt war naheliegend: Die APIs aufrufen. Außer dass es so nicht funktioniert.
Die Antwort, die man von ChatGPTs API erhält, ist nicht dieselbe Antwort, die ein Nutzer im Browser sieht. Die Webanwendung schichtet zusätzliche Optimierungen auf — Zitatformatierung, Quellenverknüpfung, Antwortumstrukturierung. Die API gibt eine rohe Vervollständigung zurück. Der Browser gibt eine kuratierte Erfahrung mit Quellen, Links und Kontext, die die API herausfiltert.
Und dann ist da Copilot. Überhaupt keine öffentliche API. Wenn man wissen möchte, was Copilot empfiehlt, muss man sehen, was die eigentliche Browseroberfläche zeigt.
Geolokalisierung fügt eine weitere Schicht hinzu. Wenn ein Nutzer in London Perplexity fragt "bestes Projektmanagement-Tool", bekommt er andere Ergebnisse als ein Nutzer in San Francisco. API-Aufrufe erfassen diese Varianz nicht. Das Scrapen der nutzerorientierten Oberfläche — von einem Proxy in der Zielgeografie — schon.
Diese Erkenntnis tötete meinen Plan, "einfach die APIs aufzurufen", innerhalb der ersten Stunde. Wenn das Ziel ist, zu sehen, was echte Nutzer sehen, muss man die eigentliche Benutzeroberfläche scrapen.
Dort trat Bright Data in den Build ein.
Bright Datas KI-Scraper: Was Sie Tatsächlich Tun
Bright Datas KI-Scraper-Produkt: vorgefertigte Scraper für KI-Plattformen, die strukturierte Daten zurückgeben — Antworttext, Quellen, Zitate und Metadaten — von den nutzerorientierten Weboberflächen von ChatGPT, Gemini AI Mode, Copilot, Perplexity und Google SERP.
Die Preise beginnen bei $0,001 pro Datensatz auf Pay-as-you-go-Basis.
Aber die Implementierung hat eine Eigenheit. Das Scrapen von KI-Plattformen ist nicht sofort. Wenn man einen Scrape einer ChatGPT-Antwort auslöst, muss der Scraper die Seite laden, warten, bis das Modell seine vollständige Antwort generiert hat (10-30 Sekunden), dann das Ergebnis extrahieren und strukturieren. Wenn der Scrape länger als etwa 60 Sekunden dauert, gibt Bright Data eine Snapshot-ID anstelle des Ergebnisses zurück. Man fragt dann diese Snapshot-ID mit GET-Anfragen ab, bis das Ergebnis bereit ist.
Dies ist das Trigger-Poll-Download-Muster, und es hat die Architektur der App grundlegend geprägt.
Der Stack: Next.js, SQLite, Drizzle und ein Code-Agent
Das war mein Ausgangspunkt:
- Next.js mit React für das Frontend und API-Routen
- SQLite mit Drizzle ORM für lokale Persistenz
- Bright Data API zum Scrapen aller sechs Plattformen
- Claude Code als primärer Code-Agent (mit einem Wechsel zu Cursor auf halbem Weg)
Das Datenbankschema: drei Tabellen — brands, scans und results. Jedes Ergebnis speichert den Provider-Namen, ob die Marke erwähnt wurde, das Sentiment, den rohen Antworttext und etwaige Quellen.
Ich begann mit Claude Code zu bauen und fütterte es mit der Bright Data API-Dokumentation als Kontext. Hier war Context Engineering wichtig — ich sagte nicht einfach "Baue mir einen Scraper." Ich fügte die vollständige API-Dokumentation für den Scraper jedes Providers ein.
Die erste Version wurde in etwa zwei Stunden zusammengestellt.
Was Schief Ging: Die Fehlermodi der Ersten Architektur
Drei Probleme tauchten innerhalb des ersten Testtages auf.
Problem 1: Timeout-Kaskaden. Wenn der Scrape eines Providers länger als erwartet dauerte, traf der API-Routen-Handler das Standard-Timeout von Next.js. Der gesamte Scan schlug fehl.
Problem 2: Keine Wiederherstellung. Wenn ich meinen Laptop schloss, verschwanden alle laufenden Scans. Keine Möglichkeit zur Fortsetzung.
Problem 3: Rate-Limiting. Als ich versuchte, mehrere Marken-Scans gleichzeitig auszuführen, stieß ich auf Rate-Limits ohne einen sauberen Wiederholungsmechanismus.
Inngest: Die Hintergrundwarteschlange, die Alles Löste
Inngest: dauerhafte Workflow-Orchestrierung für serverlose Umgebungen. Man definiert Funktionen, die als Hintergrundjobs laufen, und Inngest übernimmt Warteschlangen, Wiederholungen, Gleichzeitigkeitsbeschränkungen und Persistenz. Wenn der Server abstürzt, wird der Job bei Wiederherstellung fortgesetzt.
So veränderte sich die Architektur:
Vorher (fragil):
- Nutzer klickt auf "Scan"
- API-Route löst alle sechs Scraper synchron aus
- Wartet auf alle Ergebnisse oder läuft in einen Timeout
Nachher (dauerhaft):
- Nutzer klickt auf "Scan"
- API-Route sendet ein Event an Inngest
- Inngest-Funktion löst alle sechs Scraper parallel aus, jeder als separater Schritt
- Jeder Schritt verwaltet seine eigene Abfrageschleife unabhängig
- Ergebnisse werden in SQLite geschrieben, sobald sie abgeschlossen sind
- Frontend fragt nach Updates und rendert Ergebnisse schrittweise
// 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;
}
);
Der Parameter concurrency: { limit: 3 } löste das Rate-Limit-Problem.
Der Wechsel von Claude Code zu Cursor
Ich wechselte etwa auf halbem Weg zu Cursor mit Opus 4.6 — als ich die Bright Data Polling-Logik implementierte.
Das Problem war mein Context Engineering, nicht das Tool. Wenn man einem Code-Agenten Dokumentation für mehrere APIs einreicht, muss man chirurgisch vorgehen, welcher Kontext in jeden Prompt kommt. Anstatt alle sechs Provider-Dokumente auf einmal einzufügen, hätte ich die Arbeit als sechs sequentielle Aufgaben strukturieren sollen, jede nur mit der Dokumentation des relevanten Providers.
Nach dem Wechsel schloss ich die verbleibenden Provider-Implementierungen in etwa 90 Minuten ab.
Wie die Scan-Ergebnisse Tatsächlich Aussehen
Wenn ein Scan abgeschlossen ist, rendert die App Ergebnisse als Raster von Provider-Karten. Jede Karte zeigt:
- Provider-Name (ChatGPT, Perplexity, Gemini, Grok, Copilot, Google Search)
- Erwähnungsstatus — wurde die Marke erwähnt? Ja/Nein
- Sentiment — positiv, neutral oder negativ?
- Antwortausschnitt — der relevante Teil der KI-Antwort
- Quellen/Zitate — etwaige Links, die die KI-Plattform eingeschlossen hat
Umgang mit den Sechs Providern: Was Jeder Benötigt
ChatGPT: Erfordert ein prompt-Feld. Akzeptiert optional ein country für die Geolokalisierung.
Perplexity: Erfordert einen prompt. Gibt strukturierten Text mit eingebetteten Zitaten zurück.
Gemini AI Mode: Erfordert sowohl eine url als auch einen prompt.
Grok: Erfordert einen prompt. Gibt X-Plattform-beeinflusste Antworten zurück.
Copilot: Erfordert eine url, die auf die Copilot-Weboberfläche verweist. Es gibt keine öffentliche API.
Google SERP: Erfordert eine query (nicht prompt — anderer Feldname).
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,
}),
},
// ... ähnlich für gemini, grok, google
};
Was Ich Beim Zweiten Bau Anders Machen Würde
Ich hätte von Anfang an mit Inngest beginnen sollen. Der Bau der synchronen Version zuerst kostete mich vier Stunden Nacharbeit.
Ich habe das Datenbankschema überentwickelt. Alles könnte als JSON-Blob in einer einzigen raw_response-Spalte leben.
Ich hätte das Planungssystem von Tag eins an bauen sollen. Einzelne Scans sind nützlich. Aber der eigentliche Wert liegt darin, Veränderungen über die Zeit zu verfolgen.
Die Fehlerbehandlung musste granularer sein. "Rate-Limit-Fehler" (in 30 Sekunden erneut versuchen) unterscheidet sich von "Element nicht gefunden" (die UI hat sich geändert, benachrichtige mich) und von "keine Ergebnisse" (gültige Antwort, Marke wird einfach nicht erwähnt).
Das Geschäftsmodell
Unternehmen wie Otterly.ai und Siftly verlangen $200-500/Monat für LLM-Monitoring. Die Sichtbarkeitslücke zwischen traditionellem SEO und KI-Empfehlungen ist real und wächst.
Unternehmen, die Googles erste Seite dominieren, haben oft eine schwache Präsenz in LLM-Empfehlungen. Die Fähigkeiten, die eine gute Platzierung in der traditionellen Suche bewirken, sind nicht dieselben Signale, die LLMs dazu veranlassen, sie zu empfehlen. LLMs priorisieren semantische Relevanz und strukturelle Klarheit über Domain-Autorität.
Das System Erweitern: Planung, Benachrichtigungen und Trendanalyse
Geplante Scans mit Inngest's Cron-Trigger:
export const scheduledScan = inngest.createFunction(
{ id: "scheduled-brand-scan" },
{ cron: "0 */6 * * *" }, // alle 6 Stunden
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
},
});
}
}
);
Benachrichtigungen: Stellen Sie sich vor, eine Slack-Benachrichtigung zu erhalten: "Ihre Marke wurde gestern von ChatGPT erwähnt, wird heute aber für 'bestes CRM für Startups' nicht erwähnt."
Trendanalyse: "Als ich diesen detaillierten Vergleichsartikel veröffentlichte, stieg meine LLM-Erwähnungsrate?"
Das Produktionsreife Muster, das Es Wert Ist, Übernommen zu Werden
Die Kombination aus Bright Data + Inngest + Next.js gibt einem ein Muster, das den schwierigsten Teil der Backend-Entwicklung bewältigt: unzuverlässige Dinge zuverlässig machen.
Wenn man eine Sache aus diesem Build-Protokoll mitnimmt: Hören Sie auf zu versuchen, unzuverlässige externe Aufrufe allein durch Fehlerbehandlung zuverlässig zu machen. Verwenden Sie eine Workflow-Engine, die Unzuverlässigkeit als Standard behandelt.
Häufig Gestellte Fragen
Was ist KI-Markenmonitoring und warum ist es wichtig?
KI-Markenmonitoring verfolgt, wie KI-Plattformen wie ChatGPT, Perplexity und Gemini Ihre Marke erwähnen, wenn Nutzer nach Empfehlungen fragen. Da ChatGPT Anfang 2026 mehr als 900 Millionen wöchentlich aktive Nutzer überschritt, sind KI-Plattformen zu einem primären Entdeckungskanal geworden.
Kann man ChatGPTs API anstelle von Scraping verwenden?
API-Antworten unterscheiden sich erheblich von der nutzerorientierten Weboberfläche. Für genaues Markenmonitoring erfasst das Scrapen der eigentlichen Benutzeroberfläche, was echte Nutzer sehen.
Wie viel kostet der Betrieb?
Bright Datas API beginnt bei $0,001 pro Datensatz. Für 10 Marken über 6 Provider täglich sind das etwa $54/Monat — deutlich weniger als kommerzielle Alternativen bei $200-500/Monat.
Warum ändern sich LLM-Markenempfehlungen zwischen Abfragen?
LLM-Antworten sind von Natur aus nicht-deterministisch. Weniger als eine 1-von-100-Chance, dass ChatGPT dieselbe Markenliste in zwei Antworten auf identische Anfragen liefert.
Was ist das Trigger-Poll-Download-Muster?
Ein asynchroner Workflow, bei dem man eine lang laufende Operation auslöst, auf den Abschluss abfragt und dann das Ergebnis herunterlädt, wenn es bereit ist.
Lassen Sie Uns Zusammenarbeiten
- Fiverr: fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited: ramlit.com
- ColorPark: colorpark.io
- xCyberSecurity: xcybersecurity.io
