AGdev
AGdev

Produktvergleich & Wettbewerbsanalyse

Vertrauliches Industrie-B2B-Projekt

Von vielen Stunden Katalogrecherche zu einem klaren Ablauf für den Produktvergleich.zu einem klaren Ablauf für den Produktvergleich.

Ich habe für ein vertrauliches Industrie-B2B-Projekt ein internes System für Produktvergleich und Wettbewerbsanalyse geplant und gebaut.

Das System sammelt Produktdaten aus verschiedenen Herstellerkatalogen, bringt sie in eine gemeinsame Struktur, findet mögliche Konkurrenzprodukte und zeigt die besten Kandidaten an einem Ort. So muss das Team nicht jedes Mal wieder mehrere Webseiten öffnen und alles manuell vergleichen.

Vertrauliche Anwendung für Produktvergleich und Wettbewerbsanalyse
Rolle
Full-Stack Entwickler mit KI-Fokus
Verantwortung
Datensammlung → Produktstruktur → Produktvergleich → interne Anwendung
Status
Internes Produkt · Vertrauliches Projekt
Ablauf
Sammeln → Strukturieren → Abgleichen → Vergleichen
ProjektüberblickDie Herausforderung01 Gemeinsame Produktsprache02 Wiederverwendbare Produktdaten03 Semantisches Matching04 Menschliche Entscheidung05 Nachvollziehbarer VergleichRealität in ProduktionSo hängt das System zusammenDas ErgebnisWas ich als Nächstes verbessern würdeWas ich übernommen habeTechnologien

Der Name des Kunden, echte Produktdaten, Namen von Wettbewerbern und interne Details werden hier bewusst nicht gezeigt.

[ Projektübersicht ]

Problem

Für die Recherche von Konkurrenzprodukten musste man verschiedene Hersteller-Kataloge öffnen, mögliche Alternativen suchen und technische Daten Produkt für Produkt vergleichen. Bei wenigen Produkten war das noch machbar. Bei größeren Produktgruppen konnte diese Arbeit viele Stunden dauern und sich über mehrere Tage ziehen.

[ Lassen Sie uns zusammenarbeiten ]

Verteilte operative Daten in ein vertrauenswürdiges Produkt verwandeln?ein vertrauenswürdiges Produkt verwandeln?

Ich kann dabei helfen, Daten, System und Interface zu einem verlässlichen Workflow zu verbinden.

AGdev
ImpressumDatenschutzerklärung
ImpressumDatenschutzerklärung

© 2026 Aleksandar Gjurchevski. Alle Rechte vorbehalten.

© 2026 Aleksandar Gjurchevski. Alle Rechte vorbehalten.

Was ich gebaut habe

Ein System für Produktvergleich und Wettbewerbsanalyse, das Produktdaten sammelt und strukturiert, Produkte in eine gemeinsame Kategorisierung bringt, semantische Produktdaten erstellt, passende Konkurrenzprodukte findet und die besten Treffer in einer internen Anwendung zeigt.

Meine Verantwortung

Architektur der Datenerfassung, Datensammlung, Produktmodell, Datenbank, Preisdaten und technische Daten, Vektordarstellungen, Vektorsuche, Produktvergleich-Logik, Anmeldung und Zugriff, UX/UI und Produktvergleich.

[ Die Herausforderung ]

Die Recherche nach Konkurrenzprodukten brauchte zu viel manuelle Arbeit.

Ein passendes Konkurrenzprodukt zu finden war nicht einfach nur eine Suche.

Man musste verschiedene Hersteller-Kataloge öffnen, unterschiedliche Kategorien durchsuchen, ähnliche Produkte finden, technische Daten und Preise prüfen, Varianten beachten und danach entscheiden, ob der Vergleich wirklich sinnvoll ist.

Die Informationen waren online vorhanden.

Das Problem war: Jeder Hersteller zeigte seine Daten anders.

Produktnamen waren unterschiedlich. Kategorien waren anders aufgebaut. Technische Daten hatten andere Bezeichnungen und Formate. Manche Seiten waren dynamisch. Manche Produkte hatten Varianten. Manche Informationen gab es nur bei einem Hersteller.

Darum ging es nicht einfach nur darum, Daten automatisch von Webseiten auszulesen.

Ich musste die verschiedenen Kataloge in eine gemeinsame Produktstruktur bringen, ähnliche Produkte auffindbar machen und dem Team einen Ort geben, an dem es die besten Kandidaten prüfen kann.

Das Ziel war, aus manueller Katalog-Recherche einen klaren Ablauf für Produktvergleiche machen.
01

[ Verschiedene Kataloge brauchten eine gemeinsame Produktsprache ]

Bevor Produkte gematcht werden konnten, mussten ihre Daten vergleichbar werden.

Ein einzelner allgemeiner Scraper wäre einfacher gewesen.

Aber das hätte das echte Problem nicht gelöst.

Jede Quelle hatte eine andere Seitenstruktur, andere Kategorien, andere Preisformate und andere technische Daten.

Darum durfte jeder Crawler die Webseite auf seine eigene Art verstehen.

Am Ende mussten aber alle Daten in die gleiche interne Struktur kommen: Firma, Kategorie, Unterkategorie, Produkt, Varianten, Preise, technische Daten und Quelle.

Wenn ein Konkurrenzkatalog andere Kategorien benutzt hat, wurden diese Kategorien zuerst der gemeinsamen internen Struktur zugeordnet.

So konnte der Rest des Systems immer mit den gleichen Daten arbeiten.

Der Crawler musste die Webseite verstehen. Das Produktmodell musste die fachliche Logik verstehen.
02

[ Daten einmal zu sammeln war nicht genug ]

Für einen guten Vergleich mussten die wichtigen Details erhalten bleiben.

Ein Produkt ist mehr als nur Name und Beschreibung.

Bei technischen B2B-Produkten sind oft Dinge wie Maße, Material, Tragkraft, Verfügbarkeit, Preis und Varianten wichtig.

Ich habe diese Informationen nicht einfach in ein großes Feld gelegt.

Produkte behalten ihre Verbindung zur Firma und zur Katalogstruktur. Varianten bleiben mit ihrem Hauptprodukt verbunden. Preise und technische Daten werden separat gespeichert.

So können diese Informationen später leichter geprüft, aktualisiert und verglichen werden.

Die Daten-Pipeline bereitet die Daten außerdem so vor, dass der Produktvergleich-Teil mit einer klaren Struktur arbeiten kann.

Wichtig war nicht die Webseite, von der die Daten kamen. Wichtig war die Produktstruktur, die ich danach weiter benutzen konnte.
03

[ Beim Produktvergleich ging es um Bedeutung, nicht nur um gleiche Wörter ]

Ähnliche Produkte haben nicht immer ähnliche Namen.

Eine einfache Textsuche hätte zu viele gute Produkte übersehen.

Zwei Hersteller können Produkte für den gleichen Einsatz komplett anders benennen.

Ein wichtiger Wert kann bei einem Hersteller im Titel stehen und bei einem anderen nur in den technischen Daten.

Darum hat jedes Produkt neben den normalen Daten auch eine semantische Darstellung bekommen.

Dafür werden Kategorie, Produktname, Bezeichnung, Beschreibung und technische Daten zusammen benutzt.

Über Vektorsuche kann das System dann Produkte finden, die sich inhaltlich ähnlich sind, auch wenn die Wörter nicht genau gleich sind.

Strukturierte Daten zeigen, was ein Produkt enthält. Die semantische Suche hilft dabei, ähnliche Produkte zu finden.
04

[ Ein Ähnlichkeitswert war nur der Anfang ]

Kandidaten finden und echte Gleichwertigkeit prüfen sind zwei verschiedene Dinge.

Das war eine wichtige Grenze im Produkt.

Ein hoher Ähnlichkeitswert kann zeigen, welche Produkte interessant sind.

Er kann aber nicht garantieren, dass zwei technische Produkte wirklich austauschbar sind.

Darum nutzt die interne Anwendung Vektorsuche zuerst nur, um gute Kandidaten zu finden.

Der Nutzer startet mit einem Produkt aus dem eigenen Katalog. Das System sucht passende Produkte, entfernt Produkte von der gleichen Firma, zeigt nur Konkurrenzprodukte und sortiert sie nach Ähnlichkeit.

Die KI trifft nicht die endgültige technische oder geschäftliche Entscheidung.

Sie hilft, schneller zu den richtigen Kandidaten zu kommen.

Das System zeigt, wo man schauen sollte. Der Mensch entscheidet, ob die Produkte wirklich zusammenpassen.
05

[ Ein Ähnlichkeitswert allein schafft kein Vertrauen ]

Der Nutzer musste sehen können, warum zwei Produkte ähnlich sind.

Eine Liste mit Prozentzahlen wäre schnell gewesen.

Aber sie wäre schwer zu vertrauen.

Darum habe ich den Vergleich um die echten Produktdaten gebaut.

Ein Nutzer kann das ausgewählte Produkt und ein mögliches Konkurrenzprodukt nebeneinander öffnen und wichtige Informationen vergleichen: Produktdaten, Beschreibung, technische Daten, Preise, Verfügbarkeit und Quelle.

So kann der Nutzer nachvollziehen, warum zwei Produkte ähnlich sind.

Das System sagt nicht einfach:

„Diese Produkte sind gleich.“

Es sagt eher:

„Das sind die besten Kandidaten. Hier sind die Daten. Prüfe selbst, ob der Vergleich passt.“

Der Produktvergleich reduziert die Suche. Der Vergleich zeigt die Beweise.

[ Realität in Produktion ]

Produktdaten werden schon lange vor dem Interface kompliziert.

Der saubere Vergleich im Frontend funktioniert nur, weil die Daten vorher aufwendig verarbeitet werden.

Seiten können dynamisch laden. Produktlisten können auf mehrere Seiten verteilt sein. Für manche Varianten sind eigene Anfragen nötig. Technische Daten können doppelt vorkommen. Felder können fehlen. Preise können anders aufgebaut sein. Anfragen können fehlschlagen. Gleiche Dinge können auf verschiedenen Seiten anders heißen.

Ich habe diese Probleme so weit wie möglich in der Daten-Pipeline gelöst und nicht im Interface.

Die Crawler warten zwischen Anfragen, versuchen fehlgeschlagene Abrufe erneut, vermeiden doppelte Daten, verarbeiten dynamische Seiten und protokollieren URLs, die auch nach mehreren Versuchen nicht funktionieren.

Der Produktvergleich soll mit sauberen Produktdaten arbeiten.

Es soll nicht wissen müssen, wie schwierig eine bestimmte Webseite war.

Der Nutzer sieht nur den Produktvergleich. Die meiste Arbeit passiert schon vorher bei der Verarbeitung der Daten.

[ So hängt das System zusammen ]

Jeder Teil hat eine klare Aufgabe.

  1. Hersteller-Kataloge
    Liefern die Produktinformationen.
  2. Crawler Layer
    Liest jede Quelle aus, verarbeitet dynamische Seiten, Varianten, Preise und technische Daten.
  3. Data Pipeline

[ Das Ergebnis ]

Die Recherche konnte bei einem Produkt starten statt bei mehreren Katalogen.

Ein Nutzer kann mit einem internen Produkt starten, mögliche Konkurrenzprodukte finden und die wichtigsten Informationen in einem Vergleich ansehen.

Das System übernimmt einen großen Teil der wiederkehrenden Arbeit: Webseiten finden, Daten sammeln, strukturieren und mögliche Kandidaten suchen.

Der Mensch kann sich dadurch auf den Teil konzentrieren, bei dem Erfahrung wirklich wichtig ist: zu entscheiden, ob ein Produkt technisch und geschäftlich wirklich passt.

Das Projekt hat außerdem eine Datenbasis geschaffen, die später auch für weitere Analysen genutzt werden kann, zum Beispiel für Preisvergleiche, Lücken im Sortiment oder weitere Analysen von Wettbewerbern.

Weniger Zeit mit Suchen. Mehr Zeit für die echte Entscheidung.

[ Was ich als Nächstes verbessern würde ]

Der nächste Schritt ist nicht mehr KI. Der nächste Schritt sind bessere Beweise.

Das aktuelle System nutzt semantische Ähnlichkeit, um gute Kandidaten zu finden.

Als nächsten Schritt würde ich daraus einen hybriden Produktvergleich machen.

Technische Werte sollten zuerst in klare gemeinsame Formate gebracht werden. Zum Beispiel sollten Kilogramm und Tonnen am Ende als derselbe maschinenlesbare Wert vergleichbar sein.

Danach kann man Semantic Search mit festen technischen Regeln und gewichteten Attributen kombinieren.

Ein Produkt sollte nicht nur deshalb weit oben stehen, weil die Beschreibung ähnlich klingt, wenn ein wichtiger technischer Wert nicht passt.

Ich würde außerdem ein geprüftes Set mit bekannten Produktpaaren aufbauen. Damit könnte man messen, wie gut der Produktvergleich funktioniert, zum Beispiel wie viele der besten Treffer wirklich passen und wie viele relevante Produkte gefunden werden.

Auch beim Crawling würde ich die Herkunft und Änderungen der Daten besser speichern: Woher kommt ein Wert? Wann wurde er gelesen? Was hat sich seit dem letzten Crawl geändert? Wo hat sich die Struktur einer Quelle verändert?

So könnte das System leichter überwacht und verbessert werden.

Ein gutes Vergleichssystem findet Kandidaten. Ein zuverlässiges System zeigt auch, wie sicher diese Ergebnisse sind.

[ Was ich übernommen habe ]

Ich habe am kompletten System gearbeitet.

Meine Arbeit ging von der Datensammlung bis zur internen Anwendung.

Dazu gehörten Architektur der Datenerfassung, dynamische Seiten, Katalogzuordnung, Datennormalisierung, Produktmodell, Varianten, Preise, technische Daten, Vektordarstellungen, Vektorsuche, Produktvergleichslogik, Supabase, Authentifizierung, Produktsuche, Ranking und der direkte Produktvergleich.

  • Datenerfassung01
  • Crawling mit Python02
  • Datenmodellierung03
  • PostgreSQL / Supabase04
  • Vektordarstellungen05
  • Vektorsuche06
  • Produktvergleichslogik07
  • Authentifizierung08
  • Full-Stack-Anwendung09
  • Produkt-UX/UI10
  • Zuverlässigkeit11
  • Datenerfassung01
  • Crawling mit Python02
  • Datenmodellierung03
  • PostgreSQL / Supabase04
  • Vektordarstellungen05
  • Vektorsuche06
  • Produktvergleichslogik07
  • Authentifizierung08
  • Full-Stack-Anwendung09
  • Produkt-UX/UI10
  • Zuverlässigkeit11

[ Technologien ]

Datenerfassung
  • Scrapy
Bringt die Daten in eine gemeinsame Struktur.
  • Postgres / Supabase
    Speichert Firmen, Kategorien, Produkte, Preise, technische Daten, Varianten und Vektordarstellungen.
  • Vektorsuche
    Findet mögliche Konkurrenzprodukte zur ausgewählten Ware.
  • Interne Anwendung
    Lässt Nutzer Produkte suchen, einen Produktvergleich starten, Kandidaten sortieren und Produkte direkt vergleichen.
  • Die Anwendung verbindet diese Teile zu einem klaren Ablauf, der immer wieder genutzt werden kann.

    Einmal sammeln. Einmal strukturieren. Danach die Daten immer wieder nutzen.
  • Playwright
  • Daten & Speicherung
    KI & Produktsuche
    • Claude
    Anwendung
    Authentifizierung
  • Motion