Provedly wird als einzelnes Script-Tag installiert, rund 6 KB gzipped, und rendert in einem Shadow DOM, sodass es sich nicht mit deinen Styles in die Quere kommt. Damit eignet es sich gut für einen KI-Coding-Agenten: Gib ihm das Snippet, sag ihm, wo dein Layout liegt, und lass ihn das Ergebnis prüfen. Dieser Beitrag liefert dir einen Prompt zum Einfügen und eine Checkliste für das, was du danach kontrollieren solltest.
Was der Agent von dir braucht
Agenten arbeiten gut mit konkreten Vorgaben und schlecht mit Vermutungen. Bevor du loslegst, sammle:
- Das Script-Snippet deiner Website aus dem Provedly-Dashboard. Es enthält deine Site-ID; lass den Agenten keine erfinden.
- Wo dein gemeinsames Layout liegt. Die Datei, die jede Seite umschließt: ein Root-Layout in Next.js, ein Blade-Layout in Laravel, ein Basis-Template in Django,
header.phpin einem WordPress-Theme. - Welche Seiten Social Proof zeigen sollen. Das Targeting wird in Provedly konfiguriert, nicht im Code, aber der Agent sollte wissen, dass er keine eigene Bedingungslogik einbauen soll.
- Ob du Stripe nutzt. Falls ja, solltest du auch den Webhook-Endpunkt einrichten, damit Käufe verifiziert ankommen.
Shopify-Shops brauchen nichts davon. Die Provedly-Shopify-App nutzt eine Theme App Extension, die du im Theme-Editor einschaltest, ganz ohne Code-Änderungen.
Ein Prompt zum Einfügen
Passe die Teile in eckigen Klammern an und gib ihn deinem Agenten.
Add the Provedly social proof script to this project.
Snippet (use exactly as given, do not modify the site id):
[paste the script tag from the Provedly dashboard]
Requirements:
- Add it once, in the shared layout so it loads on every page:
[path to your layout file]
- Place it before the closing </body> tag, or use the framework's
standard mechanism for third-party scripts (for example next/script
with a non-blocking strategy).
- Do not add page-level conditions; targeting is configured in Provedly.
- Do not add any other analytics or tracking.
- Do not create sample data or placeholder records anywhere.
Then verify:
- Start the dev server and confirm the script tag is present in the
rendered HTML of two different pages.
- Confirm there are no console errors from the script.
- Confirm the script does not block rendering.
Report what you changed and the result of each check.
Der letzte Block ist wichtig. Wenn du den Agenten prüfen und berichten lässt, erklärt er die Aufgabe nicht nach einer einzigen Änderung für erledigt.
Hinweise zu Frameworks
Next.js (App Router). Der Agent sollte das Tag ins Root-Layout setzen, typischerweise mit next/script und einer Lazy- oder After-Interactive-Strategie, damit es die Hydration nie blockiert. Eine Platzierung deckt jede Route ab.
Laravel mit Blade oder Inertia. Das Root-Blade-Layout, das die App umschließt, ist der richtige Ort, direkt vor </body>. Auch eine Inertia-App hat eine einzige Root-View, also deckt eine Änderung alles ab.
WordPress. Das Footer-Template eines Themes oder ein kleines Plugin, das das Script im Footer einbindet. Füge es nicht in einzelne Seiten-Templates ein.
Statische Websites und reines HTML. Das gemeinsame Footer-Include. Wenn die Seiten kein Include teilen, sollte der Agent das Tag auf jeder Seite einfügen, aber das ist ein Zeichen, zuerst ein gemeinsames Include einzuführen.
Shopify. Fass den Theme-Code nicht an. Installiere die App, bestätige Shopify Billing und aktiviere das Provedly-Embed im Bereich App-Embeds des Theme-Editors. Die App registriert die Bestell-Webhooks für dich.
Die Installationsdetails für jeden Weg werden unter /docs aktuell gehalten.
Was du prüfst, wenn der Agent fertig ist
Agenten liefern selbstbewusste Berichte, also kontrolliere ein paar Dinge selbst.
| Prüfung | So geht's |
|---|---|
| Das Tag steht einmal im gemeinsamen Layout | Codebase nach dem Snippet durchsuchen; ein Treffer |
| Es rendert auf echten Seiten | Quelltext von zwei Seiten ansehen, auch einer tiefen Seite |
| Es blockiert nicht | Lädt nach dem Hauptinhalt; kein Layout-Shift |
| Das Shadow DOM ist vorhanden | Toast inspizieren; er liegt in einem Shadow Root |
| Das Targeting funktioniert | Ausgeschlossene Seite öffnen und nichts sehen |
| Die Größe stimmt | Netzwerk-Panel zeigt ein kleines gzipped Script |
Falls der Agent bedingtes Rendering, Umgebungsprüfungen oder Wrapper eingebaut hat, um die du nicht gebeten hast, entferne sie. Das Script ist dafür gemacht, unverändert eingefügt zu werden, und Provedlys URL- und Geräte-Targeting regelt, welche Seiten was zeigen. Die Targeting-Regeln selbst behandeln wir in /blog/where-to-show-social-proof-page-targeting.
Verifizierte Käufe zum Laufen bringen
Das Script zeigt Social Proof an; es erzeugt ihn nicht. Damit Toasts das Kennzeichen Verifizierter Kauf tragen, müssen Käufe über einen signierten Webhook ankommen.
Bei Stripe heißt das: Du legst in deinem Stripe-Dashboard einen Webhook-Endpunkt an, der auf die von Provedly angegebene Adresse zeigt, und fügst das Signing Secret in Provedly ein. Auch dabei kann ein Agent helfen, aber überleg dir gut, was du ihm gibst: Das Signing Secret ist sensibel und gehört in Provedlys Einstellungen, nicht in dein Repository. Welche Events du abonnieren musst, steht in /docs, und den kompletten Weg vom Checkout bis zum Toast findest du in /blog/how-verified-purchase-notifications-work.
Bis der erste Webhook ankommt, hat das Widget nichts Verifiziertes anzuzeigen. Widersteh der Versuchung, den Agenten Datensätze anlegen zu lassen. Alles, was von Hand hinzugefügt wird, ist als „Sample“ gekennzeichnet, und alles aus einer CSV als „Imported“. Samples auf einer Live-Website sind für Vorschauen da, Importe für echte frühere Bestellungen, nicht um Stille zu füllen. Siehe /blog/sample-records-labelled-honestly.
Was Agenten bei dieser Aufgabe falsch machen
Ein paar Muster, auf die du achten solltest, basierend darauf, wie Coding-Agenten sich typischerweise verhalten:
- Eine Site-ID erfinden, wenn das Snippet nicht mitgegeben wurde. Füge immer das echte Snippet ein.
- Das Tag in mehrere Templates einfügen statt in das gemeinsame, was zu doppeltem Laden führt.
- Das Script in Umgebungsprüfungen verpacken, sodass es nur in Produktion läuft, was eine lokale Prüfung unmöglich macht. Provedlys Free-Plan und das Targeting machen es unbedenklich, es lokal laufen zu lassen.
- Eine Fake-Toast-Komponente schreiben, statt das Script zu installieren, weil der Agent die Aufgabe als „bau eine Benachrichtigung“ missverstanden hat. Der Prompt oben beugt dem vor, indem er sagt, dass das Snippet exakt so verwendet werden soll.
- Erfolg melden, ohne eine Seite gerendert zu haben. Verlange Belege.
Nichts davon ist schwer zu erkennen, wenn du hinschaust. Die Installation selbst ist eine Zeile; die Sorgfalt steckt in der Kontrolle.
Häufige Fragen
Braucht das Widget irgendeine Konfiguration im Code?
Nein. Alle Einstellungen zu Targeting, Timing und Aussehen liegen im Provedly-Dashboard. Die Code-Änderung ist das einzelne Script-Tag.
Kann der Agent den Stripe-Webhook für mich einrichten?
Er kann dich durch die Schritte im Stripe-Dashboard führen, aber das Signing Secret solltest du selbst in Provedly eintragen und es nach Möglichkeit aus dem Repository und dem Kontext des Agenten heraushalten.
Beeinflusst das Script die Ladezeit der Seite?
Es ist etwa 6 KB gzipped groß und lädt ohne das Rendering zu blockieren, wenn du es wie beschrieben platzierst. Das Shadow DOM hält seine Styles von deinen getrennt.
Hol dir dein Snippet aus dem Dashboard, nachdem du dich unter /register registriert hast, und halte /docs für die Framework-Details offen.