angebots-radar

Warum es so gebaut ist

Vier Stellen, an denen es auch anders gegangen wäre.

• Keine Angebote aus der Texterkennung

  Ein Prospekt wurde probeweise durch eine Texterkennung geschickt. Die Produktnamen las sie gut, aber ein Drittel bis vier Fünftel der so gewonnenen Angebote wären falsch gewesen, und zwar plausibel falsch: richtiger Preis am falschen Produkt, Rabattaufkleber als Preis. Das ist die schlechteste Sorte Fehler für eine Anwendung, die ungefragt aufs Handy meldet, denn was gemeldet wird, glaubt man.

• Die ganze Prospektseite ans Bildmodell, nicht die einzelne Kachel

  Ein Bildmodell zu fragen war zunächst verworfen: laufende Kosten und eine Abhängigkeit von einem fremden Dienst in einer Anwendung, die bis dahin keine hatte. Die Rechnung kippte, als nicht mehr jede der 189 Produktkacheln einzeln geschickt wurde, sondern die 17 Seiten des Hefts am Stück. Das dauert anderthalb Minuten je Prospekt, einmal pro Woche, und die Namen stimmen vollständig; der selbst geschriebene Leser war bei 88 Prozent stehen geblieben. Übernommen wird trotzdem nur, was die Gegenprüfungen besteht: Genannte Preise müssen im zitierten Text wirklich vorkommen, und das Modell darf selbst „unsicher“ sagen.

• Eine gesperrte Schnittstelle bleibt gesperrt

  Eine der großen Ketten weist Anfragen an ihre eigene Angebots-Schnittstelle ausdrücklich ab. Das ist eine Entscheidung des Betreibers und keine technische Hürde, also wird sie nicht mit anderen Kopfzeilen umgangen. Die Angebote dieser Kette stehen trotzdem im Bestand, über den Dienst, auf dem sie ohnehin veröffentlicht werden.

• Kein zugekaufter Dienst zum Auslesen fremder Seiten

  Ein bezahlter Auslesedienst hätte mit rund 600 Abrufen im Monat bequem ins kostenlose Kontingent gepasst. Sein Nutzen ist aber der Zugang zu Seiten, die sich gegen Skripte wehren. Die hier genutzte Quelle liefert schlichtes HTML, die Zahl der gefundenen Angebote wäre exakt dieselbe geblieben. Richtig wäre er erst, wenn diese Quelle wegfällt.