Was er leistet: Carmens Funnel (ClickFunnels + WebinarJam + Zapier + Superchat)
zwischen einem echten LIVE-Termin und einem automatisierten EverWebinar-Zyklus
umschalten — Anmeldungen, Erinnerungen und Zugangslinks laufen danach wieder
korrekt zum jeweils richtigen Format.
Auslöser laut Domi (04.08.2026): EverWebinar läuft bei Carmen nur 2-3× im
Jahr als Lückenfüller/Test; der Normalzustand ist Live. Jeder Wechsel in eine
der beiden Richtungen ist also ein wiederkehrender Vorgang.
Warum das nicht trivial ist: Live-Webinar und EverWebinar sind bei Carmen
zwei komplett getrennte WebinarJam-Entitäten mit eigener ID, eigenem
Registrierungs-Zap und eigenem Verhalten beim Reminder-Link. Wer nur „das
Datum ändern" denkt, übersieht die Verdrahtung dahinter — und genau das hat
beim letzten Wechsel (01.08.2026, Live→Ever) schon einmal 75 Minuten lang eine
halb verdrahtete Kette produziert, bis alles stand (siehe Runbook Station 8).
Galt bis 20:00 Uhr: nur lesen, EverWebinar-Kampagne gehörte einer anderen
Session. Eine Ausnahme gab es noch am selben Abend (siehe „Vorfall
04.08.2026" unten) — mit Benedikts ausdrücklicher Freigabe, weil ein Live-Bug
Besucher aktiv falsch informierte.
| Live-Webinar | EverWebinar | |
|---|---|---|
webinar-ID | 67 | 62 |
| Channel/Hash | aktien_workshop → Hash 81p3ycy6 | (kein evergreen Channel-Link) |
| Reminder-Link | event.webinarjam.com/channel/aktien_workshop — generischer Channel-Link, zeigt live auf den nächsten anstehenden Termin von Webinar 67 | kein generischer Link — persönliche Räume via everwebinar/registrants |
| Letzter bekannter Termin/Schedule | 30.06.2026, Schedule 644 | 04.08.2026 20:00, Schedule 650 |
| Nächster Termin | 08.09.2026, 20:00 — Session angelegt (Session 3, Status „On"), numerische Schedule-ID noch zu lesen | — |
⚠️ Hypothese, noch nicht am neuen Termin bewiesen: Der Channel-Link ist an
das Webinar (67) gebunden, nicht an eine einzelne Session — er zeigte am
30.06./04.08. auf …/ended/81p3ycy6…, weil kein zukünftiger Termin unter 67
mehr existierte. Wenn das stimmt, fängt der Link von selbst wieder an zu
funktionieren, sobald unter Webinar 67 eine neue Session für 08.09. angelegt
ist — ohne dass der Link selbst geändert werden muss. Vor dem Verlassen
auf diese Annahme: Station D unten, Verifikation ist Pflicht (curl -sIL),
nicht raten.
Domi/Markus haben Session 3 unter Webinar 67 schon angelegt (WhatsApp-Beleg
Domi → Bene, 04.08.2026 18:30, Screenshot): **08.09.2026, 20:00 Uhr, GMT+2
(Berlin)**, Status „On". Beleg auch aus Domis Sprachnachricht 17:24 Uhr:
„Markus … deaktiviert dann [die Aufzeichnung] selbst bei EverWebinar … und
gibt mir Bescheid, wenn er wieder die Live-Webinar selbst aktiviert hat." —
Markus (Carmens Techniker) ist der Ansprechpartner für den WebinarJam-Teil,
nicht Domi selbst und nicht wir.
Noch offen, aber nicht mehr blockierend: die numerische Schedule-ID
(intern, für den Zapier-Parameter) ist aus dem UI-Screenshot nicht ablesbar
(nur die UI-Nummer „3"). Lesen vor dem nächsten Lauf: `GET
https://api.webinarjam.com/webinarjam/webinar` mit Carmens API-Key,
webinar_id=67 → schedules[] enthält nur zukünftige Termine, darunter der
neue mit seiner echten schedule-ID (siehe webinarjam/living-doc.md §6).
Rein lesend, kein Risiko — aber nicht am 04.08. gemacht, weil der
WebinarJam-Browser (domi-ai, Port 9262) an dem Abend aktiv in Benutzung war
und nicht gestört werden sollte.
**Nicht Teil der Live/Ever-Umschaltung selbst, aber am selben Abend gefunden
und mit Benedikts Freigabe sofort behoben, weil es Besucher aktiv in die Irre
führte** (Webinar startete in <2h, Countdown zeigte "00:01:48" statt echter
"01:48:xx").
Ursache: ClickFunnels blendet die größte Zeiteinheit aus, sobald sie auf 0
fällt (z. B. „Tage" verschwindet unter 1 Tag Restzeit). Der bestehende
Countdown-Timezone-Fix (siehe reference_cf_folgeseiten_2026-06-16.md) nahm
fix 4 Felder [Tage,Std,Min,Sek] an und schrieb sie stur in die ersten 4
gefundenen .countdown-amount-Elemente. Sobald nur noch 3 da waren, verschob
sich jeder Wert um ein Feld.
⭐ Der eigentlich teure Teil war nicht der Bug, sondern die falsche Seite:
Die zuerst editierte Page-ID (59003894, aus alten Notizen als „Danke-Control"
bekannt) trägt seit Juli 0 % Traffic — der Split-Test wurde irgendwann
zwischen Juni und heute auf die Variante 63999826 geflippt (100 %), ohne
dass das irgendwo nachgetragen wurde. Leere css, fehlender Fix-Script im
Editor-Read, wochenaltes updated_at — alles Symptome der falschen Seite, erst
über /pages/<id>.json → control/split_test_weight aufgelöst. Volle
Korrektur: reference_cf_folgeseiten_2026-06-16.md.
Fix (v3): mappt die vier Werte von HINTEN an die tatsächlich vorhandenen
Felder, fragt deren Anzahl jeden Tick frisch ab (keine gecachte Referenz mehr).
Live verifiziert: 18:44 Uhr korrekt „01:15:04", 19:47 Uhr korrekt „00:12:07".
Selbst-Doku direkt im Script (page[body_tag] von 63999826).
Lehre für diesen Baustein: Bei JEDER künftigen Bearbeitung einer Seite in
diesem Funnel zuerst control/split_test_weight prüfen, nie die
published_url aus /funnels/<id>.json blind für „das ist die richtige
Page-ID" halten.
*(Wer die Session anlegt und der Stand der Schedule-ID: siehe oben, „✅ Geklärt
04.08.2026, 21:00 Uhr".)*
Die umgekehrte Richtung (Live → EverWebinar) ist symmetrisch — überall wo
„67 statt 62 / neue Schedule statt 650" steht, gilt beim Rückweg das Gegenteil.
Sie wurde real am 01.08.2026 einmal durchgeführt (siehe ~/api-lab/zapier/02-zaps.md,
Abschnitt „PATCH gibt 200 und aendert TROTZDEM nichts") — das ist die Blaupause
für den Mechanismus, nicht für die Werte.
Wer: Markus (Carmens Techniker), bestätigt am 04.08.2026 — Session 3 steht.
Wie (Referenz, falls nochmal nötig): webinarjam/living-doc.md §4 (Wizard-Weg) oder
über die offizielle API POST https://api.webinarjam.com/webinarjam/webinar
mit Carmens API-Key (liegt in ClientShare, Kunde domi) zum Auslesen, Anlegen
nur über die UI (kein Save-Endpoint gecapturet, Stand 31.07.2026).
Verifikation: GET https://api.webinarjam.com/webinarjam/webinar mit
webinar_id=67 → schedules[] muss den neuen Termin mit einer schedule-ID
enthalten (nur zukünftige Termine erscheinen dort). Diese ID ist die einzige
Quelle der Wahrheit für Station C — nicht raten, nicht aus der UI abschreiben,
wenn die API sie liefert.
Domi ändert das Datum am Countdown-Widget selbst im CF-Editor
(#tmp_countdown-35053, natives „Date Countdown 2.0", data-date/data-time).
Verifikation, NACHDEM Domi live gestellt hat (nicht vorher):
reference_cf_folgeseiten_2026-06-16): CF interpretiert data-time als lokale Besucherzeit, nicht als die in
data-tz angegebene Zone. Falls damals ein Timezone-Fix-Skript in
page[body_tag] nachgerüstet wurde (liest data-date/data-time und
re-initialisiert mit einem festen Europe/Berlin-Ziel) — prüfen, ob dieses
Skript noch da ist und mit dem neuen Datum sauber greift. Wenn nicht: der
Countdown läuft für jeden Besucher auf seine eigene Ortszeit, statt auf einen
festen Moment.
ist minimal länger, auf Overflow/Umbruch in der Badge/Headline prüfen.
Bild-Text in Ads) — ein Countdown-Fix allein deckt nicht jede Textstelle ab.
Ziel-Zap: 370878496 („Carmen-Webinar-Anmeldung", ClickFunnels-Trigger,
16-17 Steps inkl. Paths/Error-Handling). Der WebinarJam-Register-Schritt darin
hat die Step-ID 370878497 (register_person_to_webinar, Stand 22.07.2026:
{"webinar":"62","schedule":"650"} — vor dem Umstellen frisch prüfen, das
könnte seither wieder verändert worden sein).
**Vorgehen (Methodik aus ~/api-lab/zapier/05-crm-feldmapping-blueprint.md,
dort generisch beschrieben, hier angewandt):**
node ~/api-lab/zapier/zap-baum.mjs 370878496 --params — ganzen Baumausgeben, nicht nur den bekannten Schritt. Bei Carmen gab es am 03.08.2026
bereits einen Fall, wo ein Fehler-Zweig zusätzliche, zeichengenaue Kopien
von Schritten enthielt (dort Pipedrive, nicht WebinarJam) — vor dem Ändern
prüfen, ob register_person_to_webinar nur einmal vorkommt oder auch
in einem error_wrapper-Zweig dupliziert ist.
GET .../storage/v1/zaps/370878496 → Feld draft) — gehört er zu diesem Vorhaben oder ist es ein fremder,
unveröffentlichter Stand? Falls fremd: klären, nicht stillschweigend
mitveröffentlichen (siehe Fallen-Index).
GET → JSON wegschreiben, wie backups/zap-367085449_vor-umhaengung_2026-08-01.json als Vorbild).
PATCH /api/gulliver/storage/v1/zaps/370878496 mit demselben zdl, nur webinar und schedule im Step 370878497 auf "67" und die neue
Schedule-ID (aus Station A) geändert. Nichts sonst.
GET erneut → draft.zdl gegen current_version.zdl diffen. Erwartet:genau 2 geänderte Werte (webinar, schedule) an genau dieser Stelle, sonst
nichts.
POST .../zaps/370878496/draft/publish-version → 201, version_number hochgezählt, draft weg.
publish-version schaltet den Zap an, falls er aus war — hier unkritisch, weil er produktiv laufen soll, aber danach is_enabled/State
gegenlesen, nicht nur den Statuscode.
Verifikation, nicht optional (Station 8-Prinzip aus dem Reaktivierungs-Runbook):
danach in WebinarJam prüfen: Registrant landet unter Webinar 67, nicht 62.
03-zap-history.md-Methodik) zeigt success amWebinarJam-Schritt.
Station D erst zu erledigen, landet der Testkontakt zwar korrekt in
WebinarJam, aber NICHT in Superchat, und das sieht wie ein Erfolg aus.
Zwei separate Zaps beobachten WebinarJam auf neue Registrierungen und
schieben den Kontakt in die Superchat-Opt-in-Kette:
| Variante | Zap-ID | Beobachtet Webinar | Soll-Zustand nach dem Wechsel auf Live |
|---|---|---|---|
| Live | 367401515 | 67 | AN |
| EverWebinar | 371000532 | 62 | AUS |
⚠️ **Das ist der Kern von Fallen-Index-Eintrag „Zwei Registrierungs-Trigger,
einer davon falsch" aus dem Reaktivierungs-Runbook: immer genau einer
aktiv.** Beide an → jede Anmeldung landet doppelt in Superchat. Beide aus →
niemand landet dort, und das fällt nicht auf, weil WebinarJam selbst
trotzdem sauber registriert (Station C sieht dann „erfolgreich" aus).
Verfahren: zap.disable/zap.enable über trpc
(02-zaps.md, Abschnitt „NACHTRAG 2026-07-14"), NICHT der storage-PATCH
is_enabled (unzuverlässig, siehe dort). zap.enable braucht die
currentVersionId aus GET .../storage/v1/zaps/367401515.
Verifikation: nach dem dem Testdurchlauf aus Station C prüfen, dass der
Testkontakt tatsächlich in der Superchat-Zielliste des Opt-in-Workflows
landet — nicht nur, dass der Zap-Run success zeigt (Zaehlfelder lügen,
siehe Fallen-Index unten).
Die Antwort an Domi: Das läuft nicht als Einmal-Handgriff, sondern ist
Teil des bestehenden, monatlichen Bausteins
whatsapp-reaktivierung.md. Für den 08.09.-Lauf
gilt genau dessen Checkliste, mit zwei Punkten, die speziell beim Wechsel
zurück auf Live wichtig sind (Nummerierung dort):
(Station 6b im Reaktivierungs-Runbook) trägt den Channel-Link
event.webinarjam.com/channel/aktien_workshop. Sobald Station A (neue
Live-Session unter Webinar 67) steht, muss dieser Link mit
curl -sIL <link> geprüft werden — Status 200 beweist NICHTS (auch die
„ist vorbei"-Seite antwortet 200), nur das Redirect-Ziel zählt.
Wann das dran ist: nicht heute, sondern beim nächsten regulären
Reaktivierungslauf vor dem 08.09.2026 (nach bisherigem Rhythmus ca. 1-2 Wochen
vorher — Kohorte ziehen, Listen anlegen, Kette verdrahten, Reminder aufsetzen).
Betroffen: Zwischenseite (Page-ID 63995749) und Dankeseite (63995751),
Tenant dominik-fuertbauer-app. Aus einem älteren Stand (16.06.2026, vor dem
EverWebinar-Umbau) bekannt: Zwischenseite hat einen nativen
„Jetzt Zugangslink speichern"-Button/Link, Dankeseite einen nativen CTA-Button
(tmp_button-dkcta) — beide zeigen auf den WebinarJam-Channel-Link.
Ein kontextfreier Agent hat live per CDP (kein Publish, kein POST) genau
diese beiden Seiten (63995749/63995751) gelesen und gezielt nach
display:none/hidden/data-hide-Mechanismen an den Link-Elementen gesucht:
#headline-zwlink — Text „Jetzt Zugangslink speichern:event.webinarjam.com/channel/aktien_workshop" — **sichtbar, nichts
ausgeblendet.**
#tmp_button-dkcta — CTA „Hier klicken und Zugangslinkspeichern" → derselbe Channel-Link, plus ein zweiter älterer Button
tmp_button-49797 mit demselben Link — beide sichtbar.
Countdown auf 06/30/2026, Headline „Dienstag, 9. Juni · 20:00 Uhr".
Einordnung, bewusst nicht als Tatsache verkauft: Das spricht dafür, dass
**63995749/63995751 gar nicht die aktuell live geschaltete Produktionsseite
ist**, auf die heutige Besucher/Reaktivierungs-Klicks tatsächlich landen.
Aus reference_cf_folgeseiten_2026-06-16.md (Phase 5, 16.06.2026) ist bekannt:
diese beiden IDs waren dort ausdrücklich als **„unsere Test-Seiten" in
separaten „Test-Bene"-Funnel-Steps** markiert, getrennt von den echten
Split-Test-Varianten des Funnels „Dr Carmen Mayer Funnel" (ID 9771252) —
Zwischen-Control 44575853 / Zwischen-Variante 63784421,
Danke-Control 59003894 / Danke-Variante 63999826. Das würde erklären,
warum hier nichts ausgeblendet ist UND warum die Daten veraltet sind: es ist
schlicht nicht die Seite, die heute im Funnel hängt.
Zwei offene Erklärungen, keine davon bewiesen:
63995749/63995751 — dort müsste zuerst geprüft werden, welche gerade
100 % Traffic trägt (GET /pages/<id>.json → control/split_test_weight),
und DORT nach dem Ausblend-Mechanismus gesucht werden.
Ausblenden bewahrt bzw. noch nicht angefasst — dann existiert die
Hide-Logik, die Domi meint, noch gar nicht, und er beschreibt etwas, das
ERST für den heutigen Lauf passieren sollte.
⛔ Nächster Schritt, NICHT heute: Vor Station F zuerst klären, welche
Page-IDs aktuell wirklich 100 % Live-Traffic tragen (Funnel 9771252 abfragen),
und ERST DORT nach Ausblend-Logik suchen. Die Aussage „nichts muss
eingeblendet werden" wäre auf Basis dieses einen Befunds verfrüht — geprüft
wurde nachweislich nur eine der möglicherweise falschen Seiten.
Vorgehensweise, sobald geklärt (nach dem 04.08., NICHT vorher):
control/split_test_weight).clickfunnels-page-edit- Skill, Pflicht: fresh fetch, NIE aus einer alten meta.json bauen — siehe
Gotcha in reference_cf_folgeseiten_2026-06-16.md).
einfügen — je nachdem, was sich dort zeigt).
--check lossless), dann erst schreiben. verify_live.
Wie Station 8 im Reaktivierungs-Runbook: eigene Testnummer durchs CF-Formular
schicken, alle vier prüfen:
DONE, Kontakt in der richtigen Listecurl -sIL) zeigt auf den Live-Raum, nicht auf „ist vorbei"⛔ Nach jeder weiteren Änderung an der Kette erneut testen — im Lauf vom
01.08.2026 lief live eine andere Workflow-Version als die getestete
(Reaktivierungs-Runbook, Station 8).
| Falle | Symptom | Woher bekannt |
|---|---|---|
| Zwei Registrierungs-Trigger, nicht synchron mit dem Haupt-Zap umgeschaltet | Anmeldungen landen korrekt in WebinarJam, aber gar nicht oder doppelt in Superchat | Reaktivierungs-Runbook Fallen-Index; hier Station D |
| Toter Reminder-Link, der wie ein lebender aussieht (HTTP 200 auf „ist vorbei") | Teilnehmer landen auf einer toten Seite, Status-Check merkt nichts | Reaktivierungs-Runbook Station 6b; hier Station E |
| PATCH auf einen Zap ändert scheinbar nichts | HTTP 200, Live-Version unverändert, weil nur der Entwurf beschrieben wurde | 02-zaps.md, real an Zap 367085449 durchgespielt |
| Versteckter Zweig im Zap übersehen (Error-Handler-Kopie) | Änderung wirkt „normal", fällt nur bei Fehlerfällen als Lücke auf | 05-crm-feldmapping-blueprint.md, real bei Carmen 03.08.2026 (Pipedrive-Fall) |
publish-version schaltet einen Zap ein, der aus bleiben sollte | Zap läuft plötzlich parallel zu einem anderen mit demselben Trigger, Doppelverarbeitung | 02-zaps.md, realer Vorfall 14.07.2026 |
Aus altem meta.json/Skeleton gebaut statt frisch gepullt | Live-CSS-Regression, unsichtbare Drift | reference_cf_folgeseiten_2026-06-16.md |
| Channel-Link-Hypothese ungeprüft übernommen | Reminder zeigt weiter auf „ist vorbei", obwohl der neue Termin längst steht | diese Datei, Abschnitt „Die zwei WebinarJam-Entitäten" |
| Countdown zeigt Besucher-Lokalzeit statt festem Termin | Manche Besucher sehen ein falsches Ablaufdatum | reference_cf_folgeseiten_2026-06-16.md, Countdown-TZ-Fix |
| Thema | Datei |
|---|---|
| Monatlicher WhatsApp-Reaktivierungs-Baustein (übernimmt Station E) | whatsapp-reaktivierung.md |
| Vollständiges Runbook mit Stationen 1-10, Fallen-Index, Live-vs-Ever-Klärung | Brand - Carmen Mayer/Superchat-Prozedere/03-runbook-reaktivierung.md |
| Alle real aufgetretenen Fehler (F-01…F-19) | Brand - Carmen Mayer/Superchat-Prozedere/FEHLERLOG.md |
| Einzige Quelle der IDs für den Reaktivierungslauf | Brand - Carmen Mayer/Superchat-Prozedere/konfig.json + KONFIG.md |
| WebinarJam Living-Doc (Auth, Schedule-IDs, offizielle API) | ~/api-lab/webinarjam/living-doc.md |
| Zapier: Zap-Mechanik, Publish-Fallen, An/Aus | ~/api-lab/zapier/02-zaps.md |
| Zapier: Methodik „Feld in ein CRM/System schreiben, ganzer Baum" | ~/api-lab/zapier/05-crm-feldmapping-blueprint.md |
| Superchat: Kampagnen, Workflows | ~/api-lab/superchat/04-campaigns.md, 03-automations-workflows.md |
| CF-Seiten programmatisch bearbeiten | Skill clickfunnels-page-edit, ~/api-lab/clickfunnels/00-master-process.md |
Trägt nur, wenn eine Marke überhaupt beide Formate (Live + EverWebinar) fährt
— bei Danny z. B. gibt es nur WebinarJam live, kein EverWebinar, die Frage
stellt sich dort nicht. Was trägt: die Grundidee „zwei getrennte
WebinarJam-IDs, ein Haupt-Zap, ein gekoppelter Registrierungs-Trigger, ein
Reminder mit Channel-Link" als Muster, um schnell die Stellschrauben zu finden
— nicht die konkreten IDs.