Das Marketing-Cockpit läuft heute als Claude-Artifact: eine Seite, ein Link, die Zahlen stehen da. Technisch ist das eine einzelne HTML-Datei, die vollständig im Browser von jedem läuft, der die Adresse öffnet — samt dem API-Key, mit dem sie die Zahlen holt. Bevor du den ersten Befehl für den Umzug tippst, lohnt sich ein Bild davon, wo Code eigentlich ausgeführt wird.
Was im Browser ankommt
Wenn du eine Adresse öffnest, schickt ein Server dir eine Datei. Ab diesem Moment passiert alles auf deinem Rechner: Der Browser liest das Markup, wendet die Styles an und führt das JavaScript aus. Er kann nur ausführen, was er vollständig bekommen hat — deshalb liegt jeder Wert, den der Code braucht, auch bei dir.
Das ist keine Lücke im Artifact, sondern die Bauart einer Seite ohne Server
dahinter. Nachsehen kannst du es an jeder Seite: Cmd+U zeigt den Quelltext, die
Entwicklerwerkzeuge zeigen zusätzlich jeden Request samt Kopfzeilen. Im Terminal
geht dasselbe mit curl.
Enter führt aus · Tab vervollständigt den nächsten Befehl · alle Ausgaben sind Beispielwerte
Im Cockpit steht der API-Key im JavaScript. Was hilft dagegen?
Die drei Ebenen
Ein Tool wie das Cockpit steht üblicherweise auf drei Ebenen. Ebene 1 ist der Browser: Er zeigt an und reagiert auf Klicks, und alles dort ist einsehbar. Ebene 2 ist dein eigener Server: Er läuft, bevor der Browser etwas sieht, hier liegen die Secrets und hier wird gerechnet. Ebene 3 sind die externen APIs, die die Rohdaten liefern.
Tipp die Punkte im Schaubild an — jeder erklärt seine Ebene und den Weg dorthin.
Dein Artifact spielt komplett auf Ebene 1. Es holt die Zahlen selbst, also braucht es den Key selbst, also steht er in der Datei. Erst eine zweite Ebene trennt beides: Der Browser fragt bei deinem Server an, dein Server fragt bei der API an, und der Key kommt nur im zweiten Schritt vor.
Das Cockpit wird über HTTPS ausgeliefert. Was genau schützt HTTPS dabei?
Der Weg einer Zahl
Nimm eine konkrete Zahl: den ROAS der letzten 30 Tage. Im Cockpit steht dann
irgendwann 2,0 auf einer Karte — 1.000 € Werbeausgaben, 2.000 € Umsatz. Auf dem
Weg dorthin berührt die Anfrage alle drei Ebenen, und zwar in einer festen Folge.
Du wählst im Cockpit den Zeitraum 30 Tage. Bring die Stationen in die Reihenfolge, die die Anfrage danach durchläuft.
- 1Der Browser fragt bei deinem Server an — ohne Key, den kennt er nicht.
- 2Dein Server liest den Key aus seiner Umgebung.
- 3Dein Server ruft damit die Reporting-API auf.
- 4Die API antwortet deinem Server mit JSON.
- 5Dein Server rechnet aus Ausgaben und Umsatz den ROAS.
- 6Der Browser bekommt die fertige Zahl und zeigt sie an.
Wichtig ist die Richtung. Der Browser stellt Anfragen, aber er bekommt nie Zugriff auf das, was dein Server dafür benutzt. Zwei Werte hat er nach diesem Ablauf: den Zeitraum, den er selbst geschickt hat, und die Zahl, die zurückkam.
Was Next.js daran ändert
Next.js ist nicht nur eine Bibliothek für Oberflächen, es bringt Ebene 2 mit. Komponenten laufen dort standardmäßig auf dem Server: Sie holen ihre Daten, bevor irgendetwas an den Browser geht, und was der Browser bekommt, ist das fertige Ergebnis. Braucht die Seite später Daten nach, kommt ein Route Handler dazu — eine eigene kleine Adresse in deinem Projekt, die der Browser anfragen darf und die den Key auf ihrer Seite behält.
Du baust dafür kein Backend und verwaltest keinen Server. Du bekommst gerade so viel davon, dass Secrets einen Platz haben und die Rechenlogik nicht im Schaufenster liegt. Alles Weitere — gespeicherte Historie, nächtliche Auswertungen, mehrere Nutzer mit eigenen Rechten — braucht irgendwann ein echtes Backend. Ebene 2 bleibt dann bestehen und ruft es auf, statt direkt bei den externen APIs anzufragen.
Häufige Fragen
Ist ein Artifact damit unbrauchbar?
Für Mockups und einmalige Auswertungen ist es praktisch: in Minuten da, ohne Setup, teilbar per Link. Die Grenze liegt bei allem, was einen Key, eine Historie oder monatelange Weiterentwicklung braucht — dafür fehlt die zweite Ebene, und die lässt sich nicht nachrüsten.
Könnte ich den Key nicht beim Öffnen abfragen und im Browser speichern?
Damit liegt er anschließend im Speicher jedes Browsers, in den ihn jemand eingetippt hat, und jede dieser Seiten schickt ihn weiter an die API. Für ein Tool, das mehrere Leute nutzen, verschiebt das das Problem nur: Statt in einer Datei steht der Key dann in mehreren Rechnern. Außerdem kann niemand ihn zentral austauschen.
Warum antwortet die API auf Anfragen aus dem Artifact heraus manchmal mit 403?
Vor vielen APIs sitzt ein Schutz, der Anfragen ohne eigenen User-Agent oder aus fremden Seiten heraus ablehnt — der 403 mit „error code: 1010" kommt von dort und nicht von der API selbst. Dazu kommt CORS: Der Browser lässt Anfragen an fremde Adressen nur zu, wenn die Gegenseite es erlaubt. Beides sind Regeln der Browser-Ebene, denen dein Server nicht unterliegt: Er schickt seinen eigenen User-Agent, und CORS gilt für ihn nicht.