Banner, Popups und mehrstufige Formulare

Du baust ein Widget für deine Website — Banner, Popup, Slide-in oder mehrstufiges Formular —, legst fest, wer es wann sieht, und veröffentlichst es. Solange du nicht auf Publish gedrückt hast, sieht es niemand.

Alles liegt unter /admin/interaction-widgets ("Widget Builder"), und du brauchst die ADMIN-Rolle.

Wähle eine Oberfläche, keinen "Formulartyp"

Hinter New widget stehen neun Typen: Banner, Popup modal, Slide-in, Big sidebar, Fullscreen, Standalone page, Embedded widget, Site widget (ein schwebender Button, den Besucher selbst öffnen) und Interactive video.

"Mehrstufig" ist keiner davon. Jede Oberfläche kann mehrere Steps tragen — ein dreistufiges Qualifizierungsformular kann also ein Modal sein, ein Slide-in oder eine eigene Seite. Hier wählst du die Oberfläche, die Steps kommen später.

Das Widget entsteht sofort als Draft, heißt "Untitled popup modal" oder entsprechend und hat schon einen Trigger: Banner bekommen Immediately, alles andere After time on page mit 3 Sekunden.

Sechs Tabs: Steps, Design, Display, Targeting, Schedule, Actions. Interactive video ist die einzige Ausnahme — dort fehlt Display, dafür gibt es einen Video-Tab (er steht ganz vorn in der Leiste), in dem du erst die Videoquelle setzt, bevor du auf der Zeitachse Cues baust.

Embedded widget, Standalone page und Site widget behalten ihren Display-Tab, nur enthält er keine Trigger. Du findest dort stattdessen eine Erklärung: Diese Oberfläche wird gar nicht ausgelöst; ob sie sichtbar ist, entscheiden ihr Status, ihr Schedule und ihr Targeting.

Drei Typen, die du platzierst statt auslöst

Standalone page. Die URL steht im Tab Design unter Page URL: ein Dropdown für die Basis (/ (root), /forms, /myarea) plus ein Slug — mehr ist nicht erreichbar. Beim Tippen zeigt das Feld entweder ein grünes "· Available" oder rot den Grund: Der Name kollidiert mit einer reservierten Route (admin, blog, products, events, login und rund zwanzig weitere auf root), mit einer bestehenden Seite oder mit einem anderen Standalone-Formular. Der rote Text ist ein Hinweis, keine Sperre — dich hindert nichts daran, auf einen belegten Pfad zu veröffentlichen; dort gewinnt dann die echte Seite oder Route, und das Widget taucht schlicht nie auf. Bring das also vorher in Ordnung. Und die URL liefert nichts, solange das Widget nicht veröffentlicht ist — auch dir nicht. Rufst du sie selbst auf, sieht das exakt wie ein falscher Pfad aus; nimm bis dahin Preview on site.

Embedded widget. Du setzt es über die Widget-Auswahl im Seiten-, Blogbeitrags- und Lektionseditor ein, über eine Embed-Section, die im Seitenbaukasten auf Widget steht, oder als Element Embedded widget in einem anderen Widget. Where it's used listet Platzierungen in Seiten, Blogbeiträgen, Lektionen und Host-Widgets — ein Embed in einer Embed-Section findet es dagegen nicht, weder im Seitenbaukasten noch in den Produkt-, Event- oder Custom-Page-Buildern, die denselben Baukasten benutzen. Diese Stellen musst du selbst durchgehen, bevor du ein Embed offline nimmst oder löschst. Auch das Targeting greift hier anders: Reached a conversion wird ignoriert, so ein Embed zeigt sich also allen; und Segmente kommen aus einer gespeicherten Liste, die alle paar Minuten neu berechnet wird, statt live ausgewertet zu werden — ein Segment aus anonymen Besuchern trifft bei einem Embed nie zu.

Site widget. Sein Button erscheint auf jeder Seite, für die das Widget qualifiziert ist; Trigger spielen keine Rolle. Im Tab Steps legst du unter "When the launcher button is clicked" fest, was ein Klick tut: entweder Show its own content — dann wählst du im Tab Design unter Opens as, wie der Inhalt aufgeht (modal, slide-in, sidebar oder fullscreen) — oder Open an existing widget, dann gestaltet der Design-Tab nur noch den runden Button, und das geöffnete Widget behält sein eigenes Design.

Inhalte bauen im Tab Steps

Ein Step ist eine geordnete Liste von Elementen, die du über Add element hinzufügst: Headline, Body text, Image, Video, Audio, Countdown, CTA button, Form field, Divider, Spacer, Embedded widget. Die Reihenfolge änderst du per Drag & Drop.

Ein neues Widget hat einen Step. Add step neben dem Step-Dropdown oben im Tab legt den nächsten an — das ist der Schritt, der aus dem Widget ein mehrstufiges Formular macht, und die Voraussetzung für die Verzweigungen weiter unten. Über das Dropdown wechselst du, welchen Step du bearbeitest, oder zeigst mit All steps alle zusammen. Jede Step-Karte hat außerdem Duplicate step und Delete step; der letzte verbliebene Step lässt sich nicht löschen.

Ein Form field hat ein Kind (text, email, phone, textarea, select, radio, checkbox, consent, hidden) und die Einstellung Map to contact: (store only), email, fname, lname, phone oder tag. Nur zugeordnete Felder aktualisieren den Kontaktdatensatz, alles andere wird als Antwort an der Einsendung gespeichert.

Sobald ein Step eine E-Mail-Adresse erfasst, kommt das nächste Feld, das du hinzufügst, als fertige Consent-Checkbox statt als Textfeld. Sie ist Pflicht, erscheint immer ungehakt und lässt sich nicht vorab ankreuzen. Ihr Text ist ein Startpunkt, kein Rechtstext — schreib hinein, was du tatsächlich verschickst.

Conditional flow pro Step ist der Ort für Verzweigungen: über eine Antwort ("wenn Interest = Pricing, springe zu Step 3") oder über einen CTA, der springt. Die Reihenfolge zählt: Add branch ist deaktiviert, bis es einen zweiten Step gibt, und die antwortgesteuerte Variante bleibt gesperrt, bis der Step ein radio-, select- oder checkbox-Feld hat. Geprüft wird von oben nach unten, die erste passende Regel gewinnt, ohne Treffer geht es linear weiter; eine Verzweigung auf einen gelöschten Step fällt auf den nächsten Step durch.

Einen Zurück-Button legt der Builder nicht an — das ist ein CTA mit "Go to previous step". Und ein Step, dessen Elemente du löschst, wird als leerer Inhalt gerendert; er fällt auf nichts zurück.

CTAs: was der Button auslöst

Die Aktionen eines CTA kommen aus drei Gruppen im Menü: Navigation (nächster / vorheriger / bestimmter Step, Link öffnen, anderes Widget öffnen, schließen), Side effects (Tags, Berechtigungen, Automations, Asset-Download, Konfetti) und System (Cookie-Einstellungen, Log in / out, My Area, Referrals, Testimonials, Knowledge Base).

Stapelst du mehrere auf einem Button, laufen die Side effects alle der Reihe nach. Bei mehr als einer Navigations-Aktion greift aber nur die letzte: "Add tag" + "Open a link" tut, was du erwartest, "Go to next step" + "Close widget" schließt dagegen nur (der Editor weist darauf hin). Eine System-Aktion legt Text und Icon des Buttons fest; das Feld Label lässt sich dann nicht mehr bearbeiten.

Jeder CTA hat einen Schalter Mark as conversion. Rührst du ihn nicht an, leitet er sich ab: Ein CTA, der einen Link öffnet, zählt immer; auf dem letzten Step zählen auch "next step" und "close". Sonst nichts — ein "Weiter" mitten im Ablauf schließt keine Einsendung ab (sie steht in der Auswertung weiter auf In progress), seine Tags und Automations laufen aber trotzdem.

Ein Feld mit Map to contact = email wird serverseitig geprüft, Domain inklusive; eine unbrauchbare Adresse blockiert die Conversion mit "Please enter a valid email address." Eine gültige legt einen Kontakt als LEAD an oder füllt bei einem bestehenden nur die leeren Felder.

Der Editor "On dismiss" tut nichts. Der Tab Actions bietet Aktionen auf Widget-Ebene für den Fall, dass jemand ohne Conversion schließt. Sie lassen sich speichern und veröffentlichen, ausgeführt werden sie nie: "Tag beim Schließen" setzt kein Tag.

Design: wie es aussieht

Die Position steht hier, je nach Typ — oben oder unten beim Banner, eine Ecke beim Slide-in, links oder rechts bei der Sidebar —, dazu Eckenradius, Desktop width (mobil ist immer volle Breite), Field & button size und das Verhalten der Überlagerung: Schließen-Button, Scroll-Sperre, Schließen per Klick daneben oder mit Esc.

Farben sind bis zu drei Tokens mit je einem hellen und einem dunklen Wert: Accent, Card bg und eine Hintergrundzeile — bei einer Standalone page heißt sie Page background, sonst Overlay background. Wie viele du bekommst, hängt vom Typ ab: Banner, Slide-in und Embed malen keinen eigenen Hintergrund und zeigen nur die ersten beiden; Modal, Fullscreen, Sidebar, Site widget, Interactive video und Standalone page zeigen alle drei. Ein Site widget, das ein anderes Widget öffnet, gestaltet nur seinen Button und zeigt deshalb allein Accent.

Lässt du einen Wert leer, greift die Voreinstellung deines Workspace, danach ein eingebauter Standard. Einen Hell/Dunkel-Schalter pro Widget gibt es nicht: Ein Widget folgt dem Theme der Website beim jeweiligen Betrachter — dafür sind die dunklen Werte da. Ein dunkles Popup auf einer hellen Seite lässt sich nicht erzwingen.

Display: wann es erscheint

Stell Show when auf Any trigger oder All triggers (dann muss jeder Trigger greifen), und füge darunter Trigger hinzu:

Exit intent funktioniert praktisch nur am Desktop. Er wartet darauf, dass die Maus das Fenster nach oben verlässt; fürs Zurückwischen am Handy gibt es nichts Vergleichbares, dort löst er nie aus.

Kein Trigger heißt "öffnet sich nie von selbst", nicht "immer zeigen" — und ist ein sinnvoller Aufbau. So ein Widget geht auf, wenn der CTA eines anderen Widgets ("Open another widget") darauf zeigt oder jemand einen Link darauf klickt. Linkfelder mit der gemeinsamen Link-Auswahl — Navigationspunkte und Nav-Buttons, Footer-Links, Buttons in Seiten-Sections — haben neben Pick page und Section auch Widget. Nicht jedes Linkfeld hat das: Ein paar schlichtere (der Link eines Logo-Eintrags, der Link eines Team-Mitglieds) sind reine URL-Felder ohne Auswahl. Von dort lässt sich ein Overlay-Widget gar nicht öffnen — ein hineinkopierter Widget-Link bleibt wirkungslos. Nur eine Standalone page geht, weil deren Ziel ein normaler Pfad ist.

Targeting: wer es sieht

Audience: Everyone, Anonymous visitors only, Known contacts only, In a segment (contacts or visitors), Reached a conversion (Goal / Micro / Trigger). Segmente und Conversions kommen aus /admin/audiences und werden bei jedem Seitenaufruf live ausgewertet — jemand qualifiziert sich in dem Moment, in dem er die Kriterien erfüllt. Ein Segment ohne Bedingungen trifft auf niemanden zu; ein Widget, das darauf zielt, erscheint nirgends. Das ist eine häufige Ursache für ein Widget, das stumm bleibt.

Capture URL / UTM parameters ist standardmäßig an: Jeder Query-Parameter der Seite (utm_*, gclid, eigene Kennzeichen) wird mit der Einsendung gespeichert, pro Wert bei 512 Zeichen abgeschnitten.

Consent category (Functional / Analytics / Marketing / Remarketing) lässt das Widget warten, bis der Besucher diese Cookie-Kategorie erlaubt. Lass es auf No consent required, solange du das nicht brauchst — wartet ein Widget auf eine Kategorie, die niemand erteilt, erscheint es nie.

Page targeting hat Show on, Hide on und Pflicht-Query-Parameter. Die Muster sind Globs, in denen nur * eine Sonderbedeutung hat; ein leeres Show on heißt jede Seite. Hide on wird zuerst geprüft und gewinnt immer. Sprachpräfixe fallen weg, /pricing deckt also auch /de/pricing ab.

Zeitplan, Häufigkeit und Kollisionen

Start- und End-Zeitpunkt, Max shows per visitor (0 = unbegrenzt), Cooldown (hours), Once per session, Stop showing after conversion (standardmäßig an) und Priority (higher wins).

Die Begrenzung gilt pro Browser, nicht pro Person. Die Zähler liegen in Cookies mit dem Präfix wgt_ und im Session Storage des jeweiligen Geräts. Cookies löschen, ein privates Fenster oder der Wechsel vom Handy zum Laptop setzt damit jede Begrenzung zurück. Der Server erzwingt nichts davon — behandle das als gute Umgangsform, nicht als Garantie.

Eine Einstellung schlägt sie alle. Steht bei einem Countdown-Element When timer hits zero auf Hide widget forever (for this visitor), schreibt das ein dauerhaftes Cookie, das noch vor allem aus dem Tab Schedule geprüft wird — der schnellste Weg, ein Widget beim Testen für dich selbst verschwinden zu lassen und es dann für kaputt zu halten. Zurück kommst du über ein privates Fenster. Ein Evergreen-Countdown merkt sich seine Deadline ebenfalls im Cookie; ein Reload startet die Uhr also nicht neu.

Von jedem Typ außer Banner kann nur eines gleichzeitig offen sein, dabei gewinnt das mit der höheren Priority; ein Modal und ein Slide-in dürfen zusammen offen sein, und Banner stapeln sich an derselben Kante.

Der Ablauf für echte Terminplanung: erst veröffentlichen, dann Start / End setzen. Ausgeliefert wird nur, was auf active steht — ein Widget mit einem anderen Status, auch mit dem blauen Badge scheduled, sieht niemand.

Veröffentlichen

Es gibt keinen Save-Button. Änderungen wandern etwa eine Sekunde nach dem letzten Tippen in den Draft und fassen den Status nie an; versehentlich live gehen kann also nichts. Die Kehrseite ist der häufigste Irrtum: Wenn du ein laufendes Widget bearbeitest, ändert sich für Besucher nichts. Öffentlich läuft der Stand, der beim Veröffentlichen eingefroren wurde, nicht dein Draft.

Der Button neben dem Status-Badge hat drei Zustände:

• Publish — nicht live. Friert den Draft ein und schaltet auf active.
• Republish — live, aber dein Draft ist weiter. Besucher sehen die alte Fassung, bis du das drückst.
• Unpublish — live und deckungsgleich. Nimmt es offline.

Jeder fragt vorher nach. In der Liste sind die Zeilen eingefärbt: grün = live und deckungsgleich, gelb = live mit unveröffentlichten Änderungen, ohne Farbe = Draft. Gelb erinnert dich an eine Bearbeitung, die du vergessen hast; Umbenennen färbt absichtlich nicht gelb. Neu laden muss niemand: Offene Seiten übernehmen eine Veröffentlichung binnen Momenten, ein schon geöffnetes Widget behält aber die Fassung, mit der es aufgegangen ist.

Unpublish pausiert das Widget und verwirft die veröffentlichte Fassung, lässt deinen Draft aber unangetastet — Publish stellt es wieder her. Pausierst du eines, während jemand mitten im mehrstufigen Formular steckt, kann diese Person fertig ausfüllen; abgewiesen werden nur neue Starts.

Vor dem Veröffentlichen: Preview on site — eine echte Seite deiner Website mit dem Widget unter seinen echten Triggern. Im Feld Page stellst du eine andere Seite ein, Trigger widget öffnet es, wenn ein Trigger schwer nachzustellen ist, und Data collected zeigt, was eine echte Einsendung gesendet hätte. Status, Seitenregeln, Häufigkeit und Consent werden dabei übergangen, gespeichert wird nichts.

Varianten, Auswertung und Löschen

Neben der Live-Vorschau sitzt ein Menü Variant. Legst du eine Variante an, wird aus dem Widget ein A/B-Test. Der neue Arm ist eine vollständige Kopie des Arms, aus dem du ihn geklont hast — Design, Steps, Trigger, Targeting, Seitenregeln, Häufigkeit und Aktionen, alles dupliziert —, keine dünne Schicht über A. Spätere Änderungen an A wandern deshalb nicht nach B: Ab dem Split ist jeder Arm eine eigene Sache, die du von Hand pflegst, und eine Textkorrektur musst du in jedem einzeln machen. Manage variants stellt Gewichtung und Aufteilung ein: Sticky (ein Besucher bleibt bei seinem Arm) oder Random (bei jedem Seitenaufruf neu gewürfelt).

Duplicate verwirft Varianten stillschweigend. Kopiert werden Design, Steps, Trigger, Targeting, Seitenregeln, Häufigkeit, Aktionen, Zeitplan und Priorität — die Kopie kommt einarmig zurück, ohne Hinweis.

Die Antworten liegen im Tab Analytics neben der Widget-Liste: gefiltert nach Widget und Zeitraum, mit den Kennzahlen Impressions, Completed, Conversion rate und Drafts. Das Listen-Symbol in einer Zeile zeigt die Einsendungen dieses Widgets direkt. Jede steht auf Completed, In progress oder Abandoned (30 Minuten ohne Aktivität). Der Conversion-Zähler zählt Klicks, nicht Personen: Eine Person kann in einer Session mehrere Conversion-CTAs auslösen, und jeder wird gezählt.

Wer ein Widget löscht, löscht seine Einsendungen mit — endgültig, und einen Export gibt es nicht. Wenn dir die Antworten wichtig sind, hol sie vorher aus Analytics heraus.