Priya — du hast mich letzte Woche gefragt, ob dein Preis-Abfall-Watcher die Produktseite einfach jede Minute abfragen sollte, "um sicherzugehen". Bevor du das einbaust, lass mich mit dir das Ganze durchgehen, denn das Abfrageintervall ist eigentlich die kleinste Entscheidung hier, und wenn die grundsätzliche Struktur von Anfang an stimmt, sparst du dir vor deinem Launch einen oder zwei Review-Durchläufe.
Beginnen wir mit dem Prompt selbst. Du hast mir gesagt: "eine Erweiterung, die diese Seite beobachtet und mir Bescheid gibt, wenn der Preis fällt", und das ist eine gute Idee, aber noch keine Spezifikation — der Builder muss wissen, wann er handelt, nicht nur was er tut. Dein Watcher ist die dritte von drei Trigger-Formen, und es lohnt sich, die anderen beiden zu kennen, auch wenn du sie nicht brauchst, denn die Form bestimmt die Berechtigungen, und die Berechtigungen bestimmen deinen Review-Zeitplan.
- Klick-zum-Handeln ist am günstigsten: ein Popup, das einmal auf der aktuellen Seite läuft, wenn jemand auf das Symbol in der Symbolleiste klickt — etwa "jeden Preis auf dieser Seite in eine Liste ziehen".
- Dauerhaft aktives Content-Skript läuft automatisch auf einem von dir festgelegten URL-Muster — gut für so etwas wie das Hervorheben des Namens eines Mitbewerbers auf jeder Seite unter einer Domain, aber du musst das Muster explizit angeben, denn "auf unseren internen Seiten" wird enger interpretiert, als du meinst.
- Dein Fall ist der dritte: ein Hintergrund-Watcher, dessen Zustand erhalten bleibt, egal ob der Tab geöffnet ist oder nicht, der als Service Worker unter MV3 läuft und das Symbol markiert, wenn sich etwas ändert.
Das ist die eine Form, bei der der Builder mit einer Rückfrage nachhaken sollte — und das wird er auch, denn die Abfragehäufigkeit ist ein echter Kompromiss, keine Formalität.
Was mich zu deinem "jede Minute"-Instinkt zurückbringt. Ich habe vor einiger Zeit fast genau deinen Build angefragt — eine Seite beobachten, das Symbol bei einer Preisänderung markieren — und der erste Durchlauf hat alle 60 Sekunden abgefragt. Funktionierte einwandfrei für eine Person, die lokal testet. Multipliziere das mit der Anzahl der Leute, die dieses Ding tatsächlich installieren, und du bombardierst die Produktseite von jemandem ohne guten Grund, denn Preise auf einem normalen Einzelhandelseintrag ändern sich nicht öfter als ein paar Mal am Tag. Sag dem Builder "alle 30 Minuten prüfen" im Prompt. Das ist kein Kompromiss, das ist die ehrlichere Anfrage — niemand braucht Sekundenbruchteile-genaue Alerts von einer Browser-Erweiterung, und du wirst dir später selbst danken, wenn du einem Reviewer nicht erklären musst, warum deine Erweiterung 1.440-mal am Tag nach Hause telefoniert.
Die Teile, über die du dir keine Gedanken machen musst
Du hast erwähnt, dass du wegen des Manifests nervös bist — das musst du nicht sein, das ist die eine Sache, die du wirklich nicht anfassen musst. Beide Stores verlangen inzwischen Manifest V3; MV2 wird für neue Einträge nicht mehr akzeptiert, und Chrome stellt aktiv noch laufende MV2-Erweiterungen ab. Die Kernänderung unter MV3 ist, dass deine Hintergrundlogik als Service Worker läuft statt als dauerhafte Hintergrundseite — er startet bei einem Ereignis, der Browser kann ihn zwischen Ereignissen beenden, und der Zustand muss über chrome.storage laufen, statt einfach in einer Variablen zu liegen. Genau solche Lifecycle-Details baut der Builder standardmäßig korrekt. Du wirst nie eine Manifest-Datei zu Gesicht bekommen, es sei denn, du suchst gezielt danach.
Worauf du deine Aufmerksamkeit tatsächlich richten solltest, sind die Berechtigungen, denn die entscheiden über die Geschwindigkeit deiner Prüfung, nicht der Code. Dein Watcher braucht alarms für das Abfragen und wahrscheinlich storage um sich den letzten Preis zu merken — er braucht kein tabs oder <all_urls>, und wenn du nach „der Möglichkeit, irgendwann auf jeder Website zu funktionieren“ fragst, weil du sie später vielleicht erweitern willst, baut der Builder genau dafür, und du forderst dann breiten Host-Zugriff für eine Funktion an, die noch gar nicht existiert. Das ist der beängstigendste Punkt im Installationsdialog — „Daten auf jeder Website lesen und ändern, die du besuchst“ — und genau das befördert eine automatisierte Prüfung in eine manuelle. Beschreibe, was die Erweiterung heute tut. Erweitere es später, wenn du es wirklich brauchst.
Zwei weitere Dinge verdienen dreißig Sekunden Aufmerksamkeit, bevor du das für erledigt erklärst: die Popup-UI und die Icons.
- Popup-UI — eine Standard-Optionsseite mit nackten Checkboxen ohne Hierarchie ist eine echte Quelle für Ein-Stern-Bewertungen, die nichts damit zu tun haben, ob die Erweiterung funktioniert. Deine hat nur ein paar Einstellungen (die URL, vielleicht das Intervall), aber sie sollte trotzdem aussehen, als gehöre sie zu einem Produkt, und nicht wie eine hingeworfene Formularseite.
- Icons — lass das Icon in allen vier Chrome-Größen prüfen (16, 32, 48, 128px, bei Firefox mit einer leicht abweichenden Matrix), denn ein Logo, das bei 128px scharf ist, wird bei 16px zu einem Fleck — und genau dort verbringt es die meiste Zeit in einer überfüllten Symbolleiste.
Bevor du einen der beiden Stores anfasst
Teste das wirklich, nicht nur in der Chat-Vorschau. Was der Build liefert, ist eine tatsächlich ladbare Erweiterung, also geh zu chrome://extensions, aktiviere den Entwicklermodus, „Entpackt laden“ und lass sie gegen die echte Produktseite laufen, die dich interessiert — nicht gegen eine simulierte Version davon. Ich würde speziell zwei Dinge von Hand prüfen: Steht im Installations-Berechtigungsdialog das, was du angesichts deiner Anfragen erwarten würdest, und was passiert, wenn das Content-Script auf eine Seite trifft, für die es nicht gebaut wurde — schlägt es leise fehl oder wirft es etwas Sichtbares? Beides dauert unter einer Minute und beides ist die Art Fehler, die offensichtlich ist, sobald man hinschaut, und unsichtbar, wenn man es nicht tut.
Wenn du wirklich bereit zum Veröffentlichen bist, läuft das über deine eigenen Entwicklerkonten bei beiden Stores — der Eintrag gehört dir, diese Plattform verwaltet ihn nicht für dich. Und ich möchte betonen, dass die beiden Stores keineswegs symmetrisch sind, damit du deinen Launch-Termin nicht in dieser Annahme planst.
| Store | Einreichungsprozess |
|---|---|
| Chrome | Füllt den Eintrag automatisch aus — Titel, Beschreibung, Kategorie und den Text zur Berechtigungsbegründung, den die Prüfung tatsächlich liest, generiert aus dem, was der Code wirklich tut, statt separat getippt. Das ist wichtig, denn nicht übereinstimmende Begründungen sind für sich genommen schon ein häufiger Ablehnungsgrund. |
| Firefox | Im Grunde ohne Zutun; Mozillas Pipeline ist schlanker und die Einreichung läuft einfach durch. |
Das Listing-Kit, das nach Abschluss deines Builds entsteht, erzeugt außerdem Screenshots, die von deiner tatsächlich laufenden Erweiterung stammen (kein Mockup), Listing-Texte sowie Antworten zum Datenschutz, die mit dem echten Code abgeglichen statt aus dem Gedächtnis ausgefüllt wurden. Letzteres ist wichtiger, als es klingt, bei etwas, das mit einer externen Seite kommuniziert: Chromes Datenschutz-Fragebogen stellt schlichte Ja/Nein-Fragen zur Datenverarbeitung, und ein „Nein“ auf „Erfasst dies Daten?“, während dein Watcher Preise abfragt und speichert, ist genau die Art kleiner Unehrlichkeit, die nach dem Launch entfernt wird, nicht nur vorher abgelehnt. Dass die Antworten mit dem tatsächlichen Code abgeglichen werden, schließt diese Lücke automatisch für dich.
| Store | Typische Prüfdauer |
|---|---|
| Firefox | Stunden, manchmal unter einer |
| Chrome | Ein paar Tage, gelegentlich näher an zwei in einer schlechten Woche |
Erweiterungen mit Hintergrund-Persistenz wie deine landen eher in der langsameren, manuellen Prüfschlange als eine einfache Klick-und-Aktion-Erweiterung. Darauf hat keiner von uns beiden Einfluss. Plane deine Ankündigung nach Chromes Zeitrahmen, nicht nach dem von Firefox, und lege nichts auf denselben Tag wie deine Einreichung.
Noch eine letzte Sache, weil ich dich kenne — du denkst wahrscheinlich schon darüber nach, nach dem Launch „Watchlist über Geräte synchronisieren“ und „Preisverlauf über die Zeit verfolgen“ hinzuzufügen. Das ist völlig in Ordnung, aber beachte: Jede dieser Funktionen bedeutet eine neue Berechtigung, und eine neue Berechtigung kann eine langsamere Prüfung bedeuten als die, die du gerade durchlaufen hast. Wenn du dir sicher bist, dass du die größere Version willst, ist es tatsächlich besser, jetzt schon danach zu fragen und eine langsamere Prüfung in Kauf zu nehmen, statt Berechtigungen nach und nach nachzureichen. Wenn du dir noch nicht sicher bist, veröffentliche das, was du hast — ein eng begrenzter Watcher wird schnell freigegeben, bringt dir echte Nutzung, und echte Nutzung ist gerade jetzt mehr wert als eine längere Feature-Liste, die in Chromes Warteschlange festsitzt. Um mehr kannst du später immer noch bitten; diesen Launch bekommst du nicht zurück, sobald er wegen etwas, das du noch gar nicht brauchtest, in der manuellen Prüfung feststeckt.
