Schritt 1: in vier Gruppen teilen (Laden / Konfig / Framework / Anzeige)
Welches «der Chat kam nicht» auch immer du hast, grenze es zuerst auf vier Gruppen ein — das allein spart die meisten Umwege. Das Flussdiagramm macht die Entscheidung klar: prüfe, ob das Skript überhaupt lud (meiqia.js in F12), dann ob es Konfig, Framework oder ein Anzeige-Layer-Problem ist. Für die Grundlagen siehe die 美洽 Website-Integrationsanleitung.
Wie Integration funktioniert: warum diese JS-Injektion scheitert / blockiert wird
Ein Satz genügt: Das 美洽-Web-Widget ist keine statische Komponente in deiner Seite — es ist ein meiqia.js, das asynchron von der externen Domain von 美洽 geladen wird, dynamisch einen Chat-Container (DOM / iframe) injiziert und eine cross-origin Dauerverbindung öffnet. Damit die Injektion gelingt, braucht es «das Skript geladen (gute Platzierung, kein Adblock), den Container nicht durch CSS / andere Plugins verdeckt, entId und Domain passend, und Neu-Mounten nach einem SPA-Routenwechsel». Das Diagramm unten zeichnet diese Kette und vier Blockpunkte — deshalb läuft derselbe Code auf einer Site / einem Framework, auf einer anderen nicht.
Code richtig platziert, aber weiterhin nicht sichtbar: lass das Integrations-Selbstcheck-Panel laufen
Wenn Platzierung, meiqia.js 200 und entId alle bestätigt sind, es aber weiterhin nicht erscheint, ist es im Grunde «Adblock» oder «Framework / Stacking». Das Panel unten ist nach Wichtigkeit geordnet: grün ist meist ok, die roten (Adblock, SPA- / Drittanbieter-Plugin-Stacking) sind die häufigen Fallen. Punkt für Punkt prüfen lokalisiert es schnell.
Vollständige Symptomtabelle (Verhalten / offizielle Einordnung · L2-Grundursache)
Die Tabelle unten listet auf einmal die häufigen Nicht-Anzeige- / Fehler-Symptome, jedes mit offizieller Einordnung und L2-Grundursache. Das Suchfeld oben wird von den Daten dieser Tabelle gespeist — suche das Stichwort, das du getroffen hast.
| Symptom | Gruppe | L1-Verhalten / offizielle Einordnung | L2-Grundursache |
|---|---|---|---|
| Chat-Fenster / Bubble wird gar nicht angezeigt | Ladefehler | Das 美洽-Web-Widget lädt ein schwebendes Chat-Fenster mit einem einzigen eingefügten JS-Snippet; bestätige, dass der Code korrekt eingebettet und die Integrationssite in der Konsole konfiguriert ist. | Das Widget ist meiqia.js, das nach asynchronem Laden ins DOM injiziert wird, daher heißt «gar nichts» meist «das Skript wurde nie geladen» — falsche Platzierung, von Adblock / Cache blockiert, oder Domain / entId stimmen nicht, sodass die Injektion nie lief. |
| Skript geladen, aber Chat-Button fehlt | Anzeigeprobleme | Der Widget-Code passt sich der Site an und zeigt einen Chat-Button; bei Anzeigeproblemen prüfe, ob er durch Styles versteckt oder die Initialisierung unterbrochen ist. | Wenn das Skript lädt, aber der Button fehlt, ist es meist ein «Anzeige-Layer»-Problem: site-weites CSS überschreibt die Button-Position / setzt display:none, der z-index verliert, oder ein anderes festes Element verdeckt ihn; ein anderer JS-Fehler kann die Initialisierung ebenfalls abbrechen. |
| meiqia.js durch eine Adblock-Erweiterung blockiert | Ladefehler | Das 美洽-Chat-Skript kommt von einer Drittanbieter-Domain; ist eine Blockier-Erweiterung installiert, kann sie es als Werbung / Tracker behandeln und das Laden verhindern — Blockierung ausschalten oder whitelisten. | ERR_BLOCKED_BY_CLIENT bedeutet, dass eine Browser-Erweiterung (AdBlock / uBlock / AdGuard) die Anfrage per Filterlisten blockierte. Das 美洽-Skript ist «Drittanbieter außerhalb der Domain + Echtzeit-Kommunikation», was solche Regeln oft als Werbung / Tracker fehldeuten — ein falscher Ausfall «Konsole ok, Nutzerseite fehlt». |
| meiqia.js 404 / falscher Status / Mixed Content | Ladefehler | Nach dem Deployment suche meiqia.js im Network-Panel; ein 200-Status heißt, das Skript ist korrekt platziert und geladen. | Häufige Nicht-200-Ursachen: Code von Seiten- / CDN-Cache zurückgehalten (nach dem Publizieren nicht aktualisiert), Laden auf einer HTTP-Seite / unvollständige Zertifikatskette löst Mixed-Content-Blockierung aus, oder kaputter / teilweise kopierter Code. Schlägt dieser Schritt fehl, passieren Injektion und Verbindung nie. |
| Code falsch platziert (head-Blockierung / wirkungslos) | Ladefehler | 美洽 empfiehlt, den Code am Seitenende vor </body> einzufügen; das Widget läuft, nachdem der Hauptinhalt geladen ist. | Das Widget muss seinen Container nach DOM-Bereitschaft injizieren. Im <head> blockiert es das Rendern (leerer Bildschirm zuerst bei langsamem Netz) oder läuft vor DOM-Bereitschaft und scheitert; in manchem async- / Modul-Scope kann auch die Ladereihenfolge danebengehen. |
| Chat-Fenster / Button-Styling kaputt | Anzeigeprobleme | Das Widget injiziert eigene Styles und passt sich der Site an; Konflikte mit site-weiten Styles können visuelle Fehler verursachen. | Das 美洽-Skript injiziert CSS zur Laufzeit; überschreiben site-weite Styles (Universalselektoren / hochpriore Regeln / Resets) seine Klassen zuerst, brechen Position, Stacking und Schriften — eine Nebenwirkung von «dynamischer Injektion + geteiltem Dokument-Stilraum». |
| Button außerhalb des Bildes / verdeckt | Anzeigeprobleme | Der Widget-Button erscheint als schwebendes Element mit fester Position; wird er von anderen festen Elementen verdeckt, passe Stacking oder Position an. | Andere position:fixed-Elemente der Site (Nach-oben, schwebende Werbung, eine eigene Support-Leiste) mit höherem z-index verdecken den 美洽-Button, oder das Theme berechnet seine Koordinaten falsch, sodass er «außerhalb des Bildes / verdeckt» ist. |
| DOM-Konflikt mit Drittanbieter-Plugin / Analytics | Anzeigeprobleme | Andere Skripte der Seite, die das DOM ändern oder Anfragen abfangen, können das normale Laden und Anzeigen des Widgets beeinträchtigen. | Heatmap- / Analytics- / Conversion-Skripte schreiben das DOM um, injizieren Overlays oder fangen Anfragen ab; da sie und 美洽 ins selbe Dokument injizieren, stören sich Stacking / Events und der 美洽-Container wird verdeckt oder seine Init unterbrochen. |
| Widget verschwindet nach einem SPA-Routenwechsel | Framework-Integration | Für Single-Page-Apps (SPA) nutze die Routen-Hooks des Frameworks, um das 美洽-Widget zu laden / zu initialisieren, damit es zum Frontend-Routing passt. | Eine SPA wechselt Ansichten per Frontend-Routing, zerstört / erstellt das DOM neu, aber meiqia.js injiziert standardmäßig einmal beim ersten Laden und wird beim Routenwechsel nicht automatisch neu erstellt — also «Seite wechseln, Chat weg». |
| Manuelle Init nötig (manualInit / init) | Framework-Integration | Füge _MEIQIA('manualInit') nach dem 美洽-Einbettungscode ein, um Auto-Init nach dem Download zu stoppen; rufe _MEIQIA('init') auf, um bei Bedarf manuell zu initialisieren. | Standardmäßig initialisiert 美洽 direkt nach dem Download; wenn du den Container bereit / Kundendaten übergeben / die Route stabil zuerst brauchst, ist dieses Timing «zu früh» — wechsle zu manueller Init, um die Reihenfolge zu steuern. |
| entId stimmt nicht / Agenten erhalten keine Chats | Konfig / Autorisierung | Die Zahl nach entId im Code ist die eindeutige ID deines Unternehmens; stimmt sie nicht mit der Workbench überein, können Agenten den Chat nicht bedienen — finde die Unternehmens-ID unter Einstellungen - Team - ID-Suche. | entId bindet den Snippet an ein bestimmtes Unternehmenskonto. Mit fremdem / Code aus anderer Umgebung oder vermischten Konten lädt das Frontend das Fenster, aber Nachrichten gehen an «ein anderes Unternehmen», sodass diese Workbench keine erhält — das klassische «sieht gut aus, empfängt aber nichts». |
| Site-Domain in der Konsole nicht autorisiert | Konfig / Autorisierung | Die 美洽-Konsole erlaubt «Integrationssite hinzufügen», jede mit eigener Konfig; eine neue Site muss in der Konsole konfiguriert werden, bevor sie korrekt integriert. | 美洽 verwaltet mehrere Sites als «Integrationssites»; die Domain muss in der Konsole registriert / autorisiert werden, um erkannt zu werden. Eine neue, nicht hinzugefügte Produktions-Domain wird evtl. nicht akzeptiert oder auf die falsche Konfig gemappt. |
| Multi-Site / Subkanal (Sonde) vermischt | Konfig / Autorisierung | 美洽 unterstützt das Deployment unterschiedlicher Widgets und Chat-Links pro Site (Subkanäle / Sonde); zusätzlich zur Standard-Site kannst du weitere hinzufügen, jede mit eigener Konfig. | Verschiedene Geschäftsbereiche brauchen verschiedene Agentengruppen / Auto-Nachrichten, aber teilen alle Sites den einen Standard-Snippet, lassen sich Quellen nicht unterscheiden und Konfigs vermischen sich. Subkanäle (Sonde) sind für «ein Unternehmen, mehrere Eingänge, geroutet» gedacht. |
| Mobil-Web-Chat nicht sichtbar / braucht eigenes Deployment | Mobil / SDK | Der Widget-Code passt sich der Site an; Mobil / PC nutzen denselben Snippet, müssen aber separat deployed werden. | Viele Teams haben getrennte PC- und Mobil-Seiten / -Templates und fügten den Code nur im PC-Template ein. Der Snippet ist derselbe und passt sich an, aber der «Einfügen»-Schritt muss auch im Mobil-Template erfolgen; ausgelassen, hat Mobil keinen Chat. |
| Natives App-SDK-Integration / AppKey | Mobil / SDK | Die In-App-Integration braucht einen AppKey aus der 美洽-Workbench (Einstellungen - Integration - SDK, «APP-Konfig hinzufügen»), und Entwickler integrieren das iOS- / Android-SDK laut offizieller Doku und Demo. | Eine App nutzt das native SDK, nicht Web-JS: zuerst «APP-Konfig hinzufügen» für einen AppKey, dann das SDK je Plattform integrieren für Chat-UI, Ungelesen, Push usw. — ein völlig anderer Pfad als das Web-Widget. |
| SDK-Nachrichten-Push kommt nicht an | Mobil / SDK | 美洽-SDK-Push hat zwei Modi: bei «kein Push» erreichen Agenten-Nachrichten nur die App (zum Empfang öffnen); mit einem «eigenen Push-Server» erhalten Nutzer Push aufs Telefon auch nach Verlassen der App. | Fehlender «Offline-Push» heißt meist, der Push-Modus ist «kein Push», oder es fehlt der eigene Push-Server / Push-Zertifikate je Plattform. Der Pfad ist «美洽 → App-Server → Telefon des Nutzers»; ein fehlendes Glied lässt nur In-App-Empfang. |
| Standard-Button ausblenden / eigener Einstieg | API-Aufrufe | Rufe _MEIQIA('withoutBtn') auf, um den nativen 美洽-Button nicht zu zeigen; nach erfolgreicher Init rufe _MEIQIA('showPanel') auf, um den Chat zu öffnen. | Standardmäßig wird der native schwebende Button gerendert; für deinen Einstieg musst du vor / während der Init «kein nativer Button» deklarieren und «Chat öffnen» an dein Element binden — eine Frage des API-Timings, kein «kaputter Button». |
| Kundendaten übergeben / synchronisieren wirkt nicht | API-Aufrufe | Das 美洽-Web-Widget bietet APIs «Kundendaten übergeben», «Kundenidentität synchronisieren» und «benutzerdefinierte Ereignisinfo hinzufügen», um Besucherdaten in den Chat zu bringen. | Diese APIs müssen innerhalb des korrekten Init-Timings aufgerufen werden: nach erfolgreicher Init (oder im manualInit + init-Timing). Zu früh / spät oder falsche Feldformate, und es ist «gesetzt, aber wirkungslos». |
美洽 Nicht-Anzeige-Ursachen & Vergleich der Integrationsmethoden (Schätzung 2026)
Die Folgenden sind 2026-Schätzungen, synthetisiert aus der offiziellen 美洽-Hilfe (Zugangskanäle / JavaScript-Web-Widget-API) und öffentlichem Integrations-Troubleshooting (keine Herstellerzusagen, keine Erstmessung; zur Orientierung, ändert sich je Version und Browser-Richtlinie):
| Dimension | Schätzung / Vergleich |
|---|---|
| Verteilung der Nicht-Anzeige-Ursachen (Community / Tickets · gesch.) | Platzierung / nicht geladen ~35% > Adblock / Browser-Erweiterung ~25% > Konfig / Autorisierung (entId / Domain) ~20% > Framework (SPA) ~12% > Stil- / Drittanbieter-Plugin-Konflikt ~8% |
| Was Integration wirklich ist | das Web-Widget = asynchrones Drittanbieter-JS außerhalb der Domain, das das DOM injiziert + eine cross-origin Dauerverbindung (keine eingebettete statische Komponente); daher der Einfluss von Platzierung, Adblock-Regeln, CSS-Stacking, SPA-Lebenszyklus |
| Integration je Plattform (gesch.) | PC- / Mobil-Web = JS-Widget (selber Code, separat deployed); App = natives SDK (AppKey); WeChat / Douyin / RED = kanalautorisierte Integration |
| Adblock-Einfluss (gesch.) | etwa 30-40% der PC-Nutzer nutzen eine Adblock-Erweiterung → das Drittanbieter-Chat-Skript wird per Werberegeln blockiert (ERR_BLOCKED_BY_CLIENT), eine Hauptursache für «Konsole ok, Nutzerseite fehlt» |
| Zeit bis live des JS-Widgets (offiziell) | das dedizierte JS am Seitenende einfügen und es geht in etwa 3-5 Minuten live; entId ist die eindeutige Unternehmens-ID, und eine Abweichung von der Workbench lässt Agenten ohne Chats |
Schätzungsbasis: Quellen-Baseline + zeitliche Extrapolation (meiqia.com/help Zugangskanäle / JavaScript-Web-Widget, meiqia.im Integrationsanleitung, öffentliches Troubleshooting, 2026); ändert sich je Version und Browser-Blockier-Richtlinie. Halte dich an die neuesten offiziellen 美洽-Infos. Inoffiziell · LLM-Lokalisierung.
Fünf 美洽-Integrationsmethoden im Vergleich (Code / Schwierigkeit / Funktionen / Szenario / Zeit bis live)
Welche Integrationsmethode? Der Vergleich unten synthetisiert die offizielle 美洽-Doku für eine schnelle Querreferenz (Codemenge, Funktionsumfang, beste Eignung, Zeit bis live). Die meisten Sites wählen das «Web-JS-Widget».
| Integrationsmethode | Code / Schwierigkeit | Funktionsumfang | Am besten für | Zeit bis live |
|---|---|---|---|---|
| Web-JS-Widget | ein JS-Snippet · gering | am vollsten (schwebend / Popup / Auto-Begrüßung / Besucherspur) | PC- + Mobil-Sites (offiziell empfohlen) | ~3-5 Min |
| Chat-Link | kein Code · minimal | Basis-Chat | ohne Technik / schnell einen Chat-Link | sofort |
| API / WebIM-SDK | braucht Dev · hoch | tiefe Anpassung (eigene UI / System / Bestell-Integration) | Teams mit Dev-Kapazität für tiefe Fusion | je nach Dev |
| Natives App-SDK | SDK integrieren · hoch | In-App-Chat + Nachrichten-Push | iOS- / Android-Apps | je nach Dev |
| CMS-Schnellsetup | Plugin / ein Klick · gering | wie das JS-Widget | WordPress- / Fkw- / Shopify-Sites | Minuten |
Kanal / Szenario → Integrations-Ergebnis-Karte
Dasselbe 美洽 integriert sich je Kanal / Szenario anders. Die Karte unten zeigt häufige Kanäle: grün = einfügen und fertig, gelb = braucht Setup (separates Deployment / init / Whitelist), rot = standardmäßig Methode wechseln (Adblock / entId / App nutzt SDK).
Häufige Fragen
美洽 Chat-Fenster / Bubble wird gar nicht angezeigt — wie behebt man das?
Das 美洽-Web-Widget lädt ein schwebendes Chat-Fenster mit einem einzigen eingefügten JS-Snippet; bestätige, dass der Code korrekt eingebettet und die Integrationssite in der Konsole konfiguriert ist. Das Widget ist meiqia.js, das nach asynchronem Laden ins DOM injiziert wird, daher heißt «gar nichts» meist «das Skript wurde nie geladen» — falsche Platzierung, von Adblock / Cache blockiert, oder Domain / entId stimmen nicht, sodass die Injektion nie lief. F12 → Network, suche meiqia.js: keine Anfrage → Code wirkungslos (Platzierung prüfen / Cache leeren); Anfrage, aber Nicht-200 → blockiert oder Pfadproblem; alles ok, aber weiterhin verdeckt → entId / Domain-Autorisierung und die Gruppen unten prüfen.
美洽 Skript geladen, aber Chat-Button fehlt — wie behebt man das?
Der Widget-Code passt sich der Site an und zeigt einen Chat-Button; bei Anzeigeproblemen prüfe, ob er durch Styles versteckt oder die Initialisierung unterbrochen ist. Wenn das Skript lädt, aber der Button fehlt, ist es meist ein «Anzeige-Layer»-Problem: site-weites CSS überschreibt die Button-Position / setzt display:none, der z-index verliert, oder ein anderes festes Element verdeckt ihn; ein anderer JS-Fehler kann die Initialisierung ebenfalls abbrechen. F12 → Elements, finde den 美洽-Container — vorhanden, versteckt oder außerhalb des Bildes?; eigenes CSS / andere Skripte testweise deaktivieren; Konsole auf einen Fehler prüfen, der die Ausführung abbrach.
美洽 meiqia.js durch eine Adblock-Erweiterung blockiert — wie behebt man das?
Das 美洽-Chat-Skript kommt von einer Drittanbieter-Domain; ist eine Blockier-Erweiterung installiert, kann sie es als Werbung / Tracker behandeln und das Laden verhindern — Blockierung ausschalten oder whitelisten. ERR_BLOCKED_BY_CLIENT bedeutet, dass eine Browser-Erweiterung (AdBlock / uBlock / AdGuard) die Anfrage per Filterlisten blockierte. Das 美洽-Skript ist «Drittanbieter außerhalb der Domain + Echtzeit-Kommunikation», was solche Regeln oft als Werbung / Tracker fehldeuten — ein falscher Ausfall «Konsole ok, Nutzerseite fehlt». Im Inkognito oder mit ausgeschaltetem Adblock testen — erscheint es, war die Blockierung die Ursache; Nutzer bitten, die Site zu whitelisten; das Frontend kann das Chat-Skript verzögert / bedingt laden, um manche Auto-Regeln zu umgehen.
美洽 meiqia.js 404 / falscher Status / Mixed Content — wie behebt man das?
Nach dem Deployment suche meiqia.js im Network-Panel; ein 200-Status heißt, das Skript ist korrekt platziert und geladen. Häufige Nicht-200-Ursachen: Code von Seiten- / CDN-Cache zurückgehalten (nach dem Publizieren nicht aktualisiert), Laden auf einer HTTP-Seite / unvollständige Zertifikatskette löst Mixed-Content-Blockierung aus, oder kaputter / teilweise kopierter Code. Schlägt dieser Schritt fehl, passieren Injektion und Verbindung nie. Nach dem Publizieren CDN- / Browser-Cache leeren (oder Inkognito); volles HTTPS mit vollständiger Zertifikatskette und ohne Mixed Content sicherstellen; prüfen, dass der kopierte Code vollständig und nicht escaped ist.
美洽 Code falsch platziert (head-Blockierung / wirkungslos) — wie behebt man das?
美洽 empfiehlt, den Code am Seitenende vor </body> einzufügen; das Widget läuft, nachdem der Hauptinhalt geladen ist. Das Widget muss seinen Container nach DOM-Bereitschaft injizieren. Im <head> blockiert es das Rendern (leerer Bildschirm zuerst bei langsamem Netz) oder läuft vor DOM-Bereitschaft und scheitert; in manchem async- / Modul-Scope kann auch die Ladereihenfolge danebengehen. Setze das 美洽-JS in den gemeinsamen Footer jeder Seite, vor </body>; für SPAs siehe den Eintrag «SPA-Route» und nutze manualInit; stelle sicher, dass ein Bundler es nicht per Tree-Shaking entfernt.
美洽 Chat-Fenster / Button-Styling kaputt — wie behebt man das?
Das Widget injiziert eigene Styles und passt sich der Site an; Konflikte mit site-weiten Styles können visuelle Fehler verursachen. Das 美洽-Skript injiziert CSS zur Laufzeit; überschreiben site-weite Styles (Universalselektoren / hochpriore Regeln / Resets) seine Klassen zuerst, brechen Position, Stacking und Schriften — eine Nebenwirkung von «dynamischer Injektion + geteiltem Dokument-Stilraum». F12, um zu sehen, welche Site-Regel den 美洽-Container überschreibt; site-weite Styles enger fassen / Einfluss auf generische Klassen reduzieren; bei Bedarf 美洽 bitten, das Container-Stacking anzupassen.
美洽 Button außerhalb des Bildes / verdeckt — wie behebt man das?
Der Widget-Button erscheint als schwebendes Element mit fester Position; wird er von anderen festen Elementen verdeckt, passe Stacking oder Position an. Andere position:fixed-Elemente der Site (Nach-oben, schwebende Werbung, eine eigene Support-Leiste) mit höherem z-index verdecken den 美洽-Button, oder das Theme berechnet seine Koordinaten falsch, sodass er «außerhalb des Bildes / verdeckt» ist. Wähle den 美洽-Container in F12, um echte Koordinaten / z-index zu sehen; ihn anheben oder den z-index des verdeckenden Elements senken; vermeide, mehrere feste Elemente in einer Ecke zu stapeln.
美洽 DOM-Konflikt mit Drittanbieter-Plugin / Analytics — wie behebt man das?
Andere Skripte der Seite, die das DOM ändern oder Anfragen abfangen, können das normale Laden und Anzeigen des Widgets beeinträchtigen. Heatmap- / Analytics- / Conversion-Skripte schreiben das DOM um, injizieren Overlays oder fangen Anfragen ab; da sie und 美洽 ins selbe Dokument injizieren, stören sich Stacking / Events und der 美洽-Container wird verdeckt oder seine Init unterbrochen. Verdächtige Plugins einzeln deaktivieren, um den Konflikt zu lokalisieren; Ladereihenfolge / Container-Stacking anpassen; Heatmaps usw. den 美洽-Container-Bereich meiden lassen.
美洽 Widget verschwindet nach einem SPA-Routenwechsel — wie behebt man das?
Für Single-Page-Apps (SPA) nutze die Routen-Hooks des Frameworks, um das 美洽-Widget zu laden / zu initialisieren, damit es zum Frontend-Routing passt. Eine SPA wechselt Ansichten per Frontend-Routing, zerstört / erstellt das DOM neu, aber meiqia.js injiziert standardmäßig einmal beim ersten Laden und wird beim Routenwechsel nicht automatisch neu erstellt — also «Seite wechseln, Chat weg». Nutze _MEIQIA('manualInit'), um Auto-Init zu stoppen, und rufe _MEIQIA('init') in einem Routen-Hook (React useEffect / Vue mounted / router afterEach) auf, um bei Bedarf neu zu mounten; vermeide mehrere Instanzen.
美洽 Manuelle Init nötig (manualInit / init) — wie behebt man das?
Füge _MEIQIA('manualInit') nach dem 美洽-Einbettungscode ein, um Auto-Init nach dem Download zu stoppen; rufe _MEIQIA('init') auf, um bei Bedarf manuell zu initialisieren. Standardmäßig initialisiert 美洽 direkt nach dem Download; wenn du den Container bereit / Kundendaten übergeben / die Route stabil zuerst brauchst, ist dieses Timing «zu früh» — wechsle zu manueller Init, um die Reihenfolge zu steuern. Füge _MEIQIA('manualInit') nach dem Code ein; rufe _MEIQIA('init') auf, sobald die Bedingungen bereit sind (DOM / Login / Route); rufe Daten-APIs in Reihenfolge innerhalb des Init-Timings laut Doku auf.
Mehr Integrations-Setup: 美洽 Web-Integration, APP-SDK-Integration; zum Start: 美洽-Anleitung. Eine durchsuchbare Vollversion (inkl. dieses Tools) auch unter 美洽 Integrations-Troubleshooting (GitHub Pages).