Eine webbasierte Plattform f\u00fcr automatisierte Marktforschung durch KI-gest\u00fctzte Persona-Agents. Nutzer erstellen Frageb\u00f6gen \u00fcber ein Next.js-Frontend und erhalten Feedback von 500 individualisierten KI-Personas anstelle realer Testpersonen.<\/p>\n\n\n\n
Die Herausforderung dahinter ist grundlegend: Traditionelle Marktforschung kostet Zeit und Geld \u2013 oft zu viel f\u00fcr fr\u00fche Produktphasen, in denen schnelle Iterationszyklen entscheidend sind. Genau hier setzt die Plattform an: Sie erm\u00f6glicht es, Produktideen, Features oder Messaging innerhalb von Minuten statt Wochen mit verschiedenen Zielgruppen zu validieren.<\/p>\n\n\n\n
Der Nutzer definiert \u00fcber einen strukturierten Fragebogen seine Forschungsfragen. Nach Absenden werden im Backend LangGraph-Agents aktiviert, die auf Basis ihrer zugewiesenen Persona-Profile antworten. Jeder Agent setzt sich individuell mit dem Produkt und Briefing auseinander und liefert entweder Freitextantworten oder skalierte Bewertungen.<\/p>\n\n\n\n
Der entscheidende Unterschied zu statischen Templates oder einfachen Prompt-Variationen: Jede Persona reagiert tats\u00e4chlich kontextbezogen auf die spezifische Fragestellung. Ein 28-j\u00e4hriger Tech-Enthusiast aus dem urbanen Milieu antwortet anders auf die gleiche Produktfrage als eine 52-j\u00e4hrige Mutter aus dem l\u00e4ndlichen Raum \u2013 nicht weil unterschiedliche Prompts verwendet werden, sondern weil die zugrundeliegenden Persona-Profile diese Unterschiede in Wertesystemen, Lebenssituationen und Konsumverhalten bereits enthalten.<\/p>\n\n\n\n
Das Herzst\u00fcck der Plattform bilden 500 individualisierte Personas, die verschiedene Alters-, Milieu- und Geschlechtergruppen abdecken. Hier liegt eine der gr\u00f6\u00dften technischen und konzeptionellen Herausforderungen des Projekts: Wie erschafft man Personas, die glaubw\u00fcrdig und konsistent antworten?<\/p>\n\n\n\n
Die Erstellung erfolgte \u00fcber einen mehrstufigen, KI-gest\u00fctzten Prozess, der auf etablierten deutschen Milieustudien basiert. Zun\u00e4chst wurden neue Milieugruppen generiert, die aktuelle gesellschaftliche Strukturen abbilden. Jede Milieugruppe erhielt eine statistische Verteilung nach Geschlecht und Alter \u2013 beispielsweise 100 Personen in Milieu 1, davon 70% m\u00e4nnlich, 30% weiblich, mit spezifischen Altersverteilungen pro Geschlecht.<\/p>\n\n\n\n
Die Komplexit\u00e4t zeigt sich bereits bei einem scheinbar simplen Detail: den Namen. Bei der Generierung wurde ber\u00fccksichtigt, welches Geschlecht die Person hat, in welchem Jahr sie geboren wurde (um zeitgem\u00e4\u00dfe Namen zu w\u00e4hlen) und ob sie einen Migrationshintergrund besitzt. Das f\u00fchrte zu einer generationenspezifischen Namensgebung: In der Gen Z sind beispielsweise t\u00fcrkische Namen inkludiert, w\u00e4hrend in der Silent Generation (alles vor den 90ern) eher griechische, italienische oder polnische Namen dominieren \u2013 ein Abbild der deutschen Migrationsgeschichte.<\/p>\n\n\n\n
Die Verarbeitung dieser komplexen Datenmengen erfolgte \u00fcber n8n als Workflow-Automation-Tool. Der initiale Generierungsprozess war nur der erste Schritt. Danach folgte die Validierung auf Konsistenz \u2013 widersprechen sich Datenpunkte innerhalb einer Persona? Ist die Verteilung \u00fcber verschiedene Milieus realistisch? Gibt es ungewollte Bias in der Altersverteilung oder Geschlechterrepr\u00e4sentation? Diese Fragen mussten systematisch beantwortet werden, bevor die Personas produktiv eingesetzt werden konnten.<\/p>\n\n\n\n
Jede Persona verf\u00fcgt \u00fcber ein detailliertes Profil mit 25 Spalten, die jeweils multiple Datenpunkte enthalten. Es reicht nicht, einfach „weiblich, 35 Jahre, verheiratet“ zu definieren. Erst die Kombination aus demografischen Daten, Wertesystemen, Konsumverhalten, Mediennutzung, politischen Einstellungen und konkreter Lebenssituation macht eine Persona glaubw\u00fcrdig und differenziert genug, um auf unterschiedliche Fragestellungen authentisch zu reagieren.<\/p>\n\n\n\n
Bei der Umfrageerstellung k\u00f6nnen spezifische Zielgruppen definiert werden \u2013 etwa nach Geschlecht, Familienstand oder anderen demografischen Merkmalen. Umfragen lassen sich mit unterschiedlichen Personagruppen wiederholen, um verschiedene Zielgruppensegmente zu validieren. Das macht iteratives Testing m\u00f6glich: Einmal den Fragebogen erstellt, mehrmals mit verschiedenen Zielgruppen getestet. Die Architektur erlaubt es, eine Produktidee erst mit Tech-Early-Adopters zu testen, dann mit preisbewussten Familien, dann mit Senioren \u2013 alles innerhalb weniger Stunden statt Wochen.<\/p>\n\n\n\n
Das technische Fundament der Plattform besteht aus zwei zentralen Komponenten: einem individuell entwickelten Python-Backend mit FastAPI und Supabase als Backend as a Service.<\/p>\n\n\n\n
Die Entscheidung f\u00fcr FastAPI war strategisch: Alle Funktionen, die momentan vom Frontend abgerufen werden, sind bereits API-ready. Das bedeutet, dass die gesamte Marktforschungs-Logik perspektivisch als Schnittstelle in andere Systeme integriert oder f\u00fcr andere Kunden verf\u00fcgbar gemacht werden kann. Ein SaaS-Produkt zu bauen war von Anfang an mitgedacht \u2013 nicht als nachtr\u00e4gliche Anpassung, sondern als Teil der Grundarchitektur.<\/p>\n\n\n\n
Das FastAPI-Backend \u00fcbernimmt das gesamte Handling von LangGraph, die Orchestrierung der Agent-Chains und die Kommunikation mit den verschiedenen Services. Die asynchrone Natur von FastAPI ist hier besonders wertvoll: Wenn 50 Personas parallel auf einen Fragebogen antworten sollen, laufen diese Prozesse non-blocking ab.<\/p>\n\n\n\n
Ein kritischer Aspekt der Architektur ist die Sicherstellung der Datenqualit\u00e4t. Die LLM-Agents werden zu strukturierten JSON-Antworten gezwungen. Wenn eine JSON-Antwort nicht korrekt formatiert vom LLM zur\u00fcckgegeben wird, greift ein Validation Layer: Die Antwort wird abgelehnt und ein automatisches Retesting findet statt. Diese Fehlerbehandlung auf mehreren Ebenen stellt sicher, dass nur valide, verarbeitbare Daten in die Datenbank gelangen.<\/p>\n\n\n\n
Supabase \u00fcbernimmt die Datenbankverwaltung f\u00fcr Personas, Umfragen und Ergebnisse sowie das komplette User-Authentication-System. Jeder Nutzer verf\u00fcgt \u00fcber einen individuellen Login-Bereich, in dem ausschlie\u00dflich die eigenen Projekte und Umfragen angezeigt werden.<\/p>\n\n\n\n
Der entscheidende Vorteil dieser Architektur liegt in der PostgreSQL-Basis von Supabase. Es ist keine „Black Box“ wie bei vielen anderen Backend-as-a-Service-L\u00f6sungen. Row Level Security erm\u00f6glicht granulare Zugriffskontrolle direkt auf Datenbankebene. Nutzer k\u00f6nnen technisch gar nicht auf fremde Umfragen zugreifen \u2013 nicht weil die Application-Logik das verhindert, sondern weil die Datenbank es nicht zul\u00e4sst. Diese Sicherheitsebene direkt in der Datenbank zu haben, statt sie nur in der Application-Layer zu implementieren, reduziert das Risiko von Sicherheitsl\u00fccken erheblich.<\/p>\n\n\n\n
Als LLM-Provider kommt OpenRouter zum Einsatz. Die Entscheidung f\u00fcr OpenRouter statt direkter Integration einzelner Anbieter bietet einen strategischen Vorteil: maximale Flexibilit\u00e4t in der Modellauswahl ohne Vendor Lock-in. Eine API f\u00fcr alle Provider bedeutet konkret, dass man innerhalb von Minuten auf neue, bessere Modelle von OpenAI, Anthropic, Google oder anderen Anbietern wechseln kann. In einem Feld, das sich so schnell entwickelt wie Large Language Models, ist diese Flexibilit\u00e4t entscheidend.<\/p>\n\n\n\n
In einer initialen Testphase wurden verschiedene Language Models auf ihr Preis-Leistungs-Verh\u00e4ltnis und ihre Output-Qualit\u00e4t hin getestet. Schnell zeigte sich: Teurere Modelle liefern nicht automatisch bessere Ergebnisse \u2013 es kommt auf den spezifischen Use Case an. F\u00fcr strukturierte Umfrageantworten mit klaren Persona-Vorgaben ben\u00f6tigt man nicht unbedingt die h\u00f6chste Reasoning-Kapazit\u00e4t der teuersten Modelle. Wichtiger sind Konsistenz, Zuverl\u00e4ssigkeit und die F\u00e4higkeit, Instruktionen pr\u00e4zise zu befolgen.<\/p>\n\n\n\n
Die Balance zwischen Kosten und Qualit\u00e4t ist kritisch: Bei 500 Personas und potenziell dutzenden Fragen pro Umfrage summieren sich die API-Kosten schnell. Ein Modell, das 30% teurer ist aber nur 10% bessere Ergebnisse liefert, ist wirtschaftlich nicht tragf\u00e4hig. Die Tests f\u00fchrten zur Auswahl eines Modells, das sowohl wirtschaftlich als auch qualitativ optimale Ergebnisse f\u00fcr diesen konkreten Anwendungsfall liefert.<\/p>\n\n\n\n
Jede Agent-Antwort wird \u00fcber Langfuse als LLM Observability Tool getrackt. Langfuse \u00fcbernimmt dabei mehrere zentrale Funktionen: Es erm\u00f6glicht versionierte Prompts mit vollst\u00e4ndiger Historie und macht es m\u00f6glich, verschiedene Prompt-Varianten zu testen und zu vergleichen.<\/p>\n\n\n\n
Das Besondere: Langfuse wird f\u00fcr alle KI-Funktionen in der App genutzt \u2013 sowohl bei der initialen Persona-Generierung als auch f\u00fcr System-Prompts, Persona-Prompts, Summary-Prompts und alle weiteren KI-gest\u00fctzten Features. Alles l\u00e4uft zentral \u00fcber dieses System, und es ist selbst gehostet, was zus\u00e4tzliche Flexibilit\u00e4t bietet.<\/p>\n\n\n\n
Die gesammelten Daten dienen mehreren Zwecken: Sie erm\u00f6glichen kontinuierliches Monitoring der Agent-Performance \u2013 welche Personas antworten konsistent? Wo gibt es Ausrei\u00dfer? Welche Fragen f\u00fchren zu qualitativ hochwertigen Antworten? Gleichzeitig sind die gespeicherten Daten bereits so vorstrukturiert, dass sie sp\u00e4ter sehr einfach in ein klassisches Frage-Antwort-Format f\u00fcr das Training spezialisierter Large oder Small Language Models \u00fcberf\u00fchrt werden k\u00f6nnen. Je mehr Umfragen durchgef\u00fchrt werden, desto mehr Daten \u00fcber erfolgreiche Persona-Antworten sammeln sich an \u2013 ein wachsendes Asset f\u00fcr zuk\u00fcnftige Modell-Optimierungen.<\/p>\n\n\n\n
F\u00fcr die Nutzungsverwaltung wurde ein ma\u00dfgeschneidertes Token-System entwickelt. Die Token-Berechnung basiert auf zwei Faktoren: der Anzahl der Fragen im Fragebogen und der Anzahl der ausgew\u00e4hlten Personas. Beispielrechnung: Bei einem Fragebogen mit 8 Fragen und 50 befragten Personas werden 400 Tokens verbraucht (8 \u00d7 50 = 400).<\/p>\n\n\n\n
Warum ein Custom System statt einer Standard-L\u00f6sung? Die spezifische Berechnungslogik reflektiert die tats\u00e4chlichen Kosten und den Wert der Plattform. Jede Frage an jede Persona verursacht einen LLM-API-Call \u2013 das Token-System bildet also direkt die dahinterliegende Ressourcennutzung ab. Standard-L\u00f6sungen wie „Credits pro Umfrage“ oder „Flatrate f\u00fcr X Umfragen“ h\u00e4tten diese Granularit\u00e4t nicht bieten k\u00f6nnen.<\/p>\n\n\n\n
Das System beinhaltet eine automatische Token-Regeneration: Alle 30 Tage werden die Tokens des jeweiligen Nutzers wieder aufgef\u00fcllt. Diese Mechanik f\u00f6rdert regelm\u00e4\u00dfige Nutzung ohne dass sich Nutzer Gedanken \u00fcber „verschwendete“ Tokens machen m\u00fcssen. Die gesamte Token-Verwaltung \u2013 Verbrauch, Tracking und Regeneration \u2013 l\u00e4uft \u00fcber die Supabase-Datenbank und wurde vollst\u00e4ndig individuell entwickelt, von der Berechnungslogik bis zur automatischen Cronjob-Ausf\u00fchrung f\u00fcr die monatliche Regeneration.<\/p>\n\n\n\n
Das Frontend bereitet die Agent-Antworten in einem \u00fcbersichtlichen Bericht auf. Der Fokus liegt dabei nicht nur auf Darstellung, sondern auf echtem Erkenntnisgewinn: Die automatische Zusammenfassung von Meinungsbildern priorisiert bereits in welche Richtung es geht und liefert konkrete Key Takeaways.<\/p>\n\n\n\n
Statt nur zu schreiben „Die meisten Personas fanden das Produkt interessant“, werden spezifische Handlungsempfehlungen generiert: „47 von 50 Personas haben den Preis als zu hoch kritisiert, besonders in der Altersgruppe 25-35. Gleichzeitig wurde die Funktionalit\u00e4t X von 38 Personas positiv hervorgehoben. Handlungsempfehlung: Preis \u00fcberdenken oder zus\u00e4tzliche Features kommunizieren, die den Preis rechtfertigen.“<\/p>\n\n\n\n
Zus\u00e4tzlich erm\u00f6glichen Visualisierungsfunktionen die Darstellung der Umfrageergebnisse in Diagrammform. Die Balance zwischen \u00dcberblick und Detail ist entscheidend \u2013 zu oberfl\u00e4chlich, und die Ergebnisse wirken nicht vertrauensw\u00fcrdig; zu detailliert, und niemand wird sich durch hunderte Einzelantworten arbeiten. Die Plattform bietet beides: Schnelle Erfassbarkeit der wichtigsten Erkenntnisse in wenigen Minuten, aber gleichzeitig die M\u00f6glichkeit, bei Bedarf tief in die Einzelantworten einzutauchen.<\/p>\n\n\n\n
Erste Tests haben gezeigt, dass das System grundlegend funktioniert. Die entscheidende Frage bleibt jedoch: Sind die Ergebnisse valide? Antworten KI-Personas tats\u00e4chlich so, wie echte Menschen es tun w\u00fcrden?<\/p>\n\n\n\n
Hier zeigt sich eine bekannte Problematik von LLM-basierten Umfragen: die sogenannte „generische Mitte“. Wenn ein Language Model auf einer Skala von 1 bis 7 bewerten soll, w\u00e4hlt es \u00fcberproportional h\u00e4ufig mittlere Werte \u2013 ein Verhalten, das menschliche Antwortmuster nicht authentisch abbildet. Menschen sind polarisierter, emotionaler, weniger „ausgeglichen“ in ihren Bewertungen. Sie tendieren zu den Extremen, besonders wenn sie starke Meinungen haben.<\/p>\n\n\n\n
Eine vielversprechende L\u00f6sung bietet die k\u00fcrzlich ver\u00f6ffentlichte Semantic Similarity Rating (SSR) Methode (Maier et al., 2025: „LLMs Reproduce Human Purchase Intent via Semantic Similarity Elicitation of Likert Ratings“). Die Studie basiert auf 57 Consumer-Research-Surveys mit \u00fcber 9.300 realen Teilnehmern und zeigt wissenschaftlich fundiert, dass LLMs mit der richtigen Methodik valide Marktforschungsergebnisse liefern k\u00f6nnen.<\/p>\n\n\n\n
Der Ansatz dreht das Problem elegant um: Statt die KI direkt eine Zahl w\u00e4hlen zu lassen, l\u00e4sst man sie tun, was sie am besten kann \u2013 nat\u00fcrliche Sprache generieren. Die KI gibt zun\u00e4chst eine Freitextantwort, beispielsweise „Ich k\u00f6nnte mir vorstellen, das Produkt zu kaufen“. Diese Antwort wird anschlie\u00dfend vektorisiert und mit vordefinierten Musterantworten f\u00fcr jede Skalenstufe semantisch abgeglichen. Das System vergibt dann basierend auf der h\u00f6chsten semantischen \u00dcbereinstimmung das Rating \u2013 nicht die KI selbst.<\/p>\n\n\n\n
Die Studie zeigt beeindruckende Ergebnisse: SSR erreicht 90% der menschlichen Test-Retest-Reliabilit\u00e4t bei gleichzeitig realistischen Antwortverteilungen (KS-Similarity > 0.85). Dieser Umweg \u00fcber die Vektorsuche umgeht die Tendenz zur generischen Mitte und f\u00fchrt zu authentischeren Antwortverteilungen. Die KI bleibt in ihrer Komfortzone (Textgenerierung), w\u00e4hrend das Rating systemseitig erfolgt. Es ist ein Beispiel daf\u00fcr, wie man die St\u00e4rken von LLMs nutzt und gleichzeitig ihre Schw\u00e4chen umgeht, statt gegen sie anzuk\u00e4mpfen.<\/p>\n\n\n\n
Die Integration dieser Methode ist ein logischer n\u00e4chster Schritt, um die Validit\u00e4t der Umfrageergebnisse wissenschaftlich fundiert zu erh\u00f6hen und das System n\u00e4her an reale Marktforschungsstandards heranzuf\u00fchren. Die technische Infrastruktur daf\u00fcr ist bereits vorhanden \u2013 Vektorisierung und semantische Suche sind etablierte Technologien. Die Herausforderung liegt in der Erstellung und Kalibrierung der Musterantworten f\u00fcr jede Skalenstufe, aber die wissenschaftliche Evidenz aus der Studie liefert klare Richtlinien f\u00fcr die Implementation.<\/p>\n","protected":false},"excerpt":{"rendered":"
KI-gest\u00fctzte Marktforschungsplattform mit 500 individualisierten Persona-Agents f\u00fcr automatisierte Produkt- und Messagingvalidierung<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[2,3,4,5,6,7,8,9,10,11,12,13],"class_list":["post-7","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-agent","tag-authentication","tag-automation","tag-fastapi","tag-langfuse","tag-n8n","tag-next-js","tag-prompt-engineering","tag-python","tag-supabase","tag-token-tracking","tag-tooling"],"_links":{"self":[{"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/posts\/7","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/comments?post=7"}],"version-history":[{"count":2,"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/posts\/7\/revisions"}],"predecessor-version":[{"id":45,"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/posts\/7\/revisions\/45"}],"wp:attachment":[{"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/media?parent=7"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/categories?post=7"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/content.doppel-t.com\/index.php\/wp-json\/wp\/v2\/tags?post=7"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}