FAQ

Erklärung zur Benutzer-UID (User Unique Identifier)

1. Bei der Initialisierung muss eine eindeutige Zeichenfolge angegeben werden, um eine einzigartige User-ID (UID) zu generieren. Diese UID dient als Identifikationscode für Push-Benachrichtigungen und ist nicht an ein bestimmtes Gerät gebunden.
   
   
2. Wenn ein:e Nutzer:in denselben user_str verwendet, wird er:sie als dieselbe Person erkannt. Abonnements auf verschiedenen Browsern oder Geräten ersetzen jeweils die vorherigen Abonnementinformationen durch die neuesten für den Nachrichtenversand. Beispiel: Nutzer:in A abonniert nacheinander mit demselben user_str auf den Browsern a1, a2 und a3. Theoretisch kann nur das zuletzt abonnierte a3 Nachrichten empfangen. So wird verhindert, dass ein:e Nutzer:in mehrfach benachrichtigt wird und unnötig viele Nachrichten verschickt werden. Im Backend wird immer nur die aktuellste Abonnementinformation für dieselbe UID gespeichert.
   
   
3. Nachrichtenabonnements können gekündigt werden. Das SDK stellt dafür eine Schnittstelle bereit. Diese Kündigung entfernt lediglich die Verknüpfung zwischen UID und Abonnementinformation, ändert jedoch nicht die Benachrichtigungsberechtigungen des Browsers.
   
   
4. Theoretisch sollte user_str eindeutig einer realen Person zugeordnet sein. In bestimmten Situationen, etwa im Besuchermodus, müssen Entwickler:innen explizit eine eindeutige user_str generieren. Das SDK übernimmt keine automatische Standardverarbeitung, um Fehler zu vermeiden, falls Entwickler:innen die Beziehung zwischen user_str und realen Nutzer:innen nicht korrekt abbilden. Andernfalls könnten Statistikdaten nicht den Erwartungen entsprechen.

   Im Besuchermodus können Entwickler:innen folgende Funktion nutzen, um eine eindeutige user_str zu generieren. Diese Funktion verwendet den Browser des:der Nutzer:in als eindeutigen Identifikationscode. Beachten Sie, dass bei einem Wechsel des Browsers, Geräts oder nach dem Löschen des Caches ein neuer user_str generiert wird.
   Beispiel-Funktion:

   function randomUid() { const keyStr = 'mtWebPushRandomUid'; let uid = window.localStorage.getItem(keyStr); if (!uid) { uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36); window.localStorage.setItem(keyStr, uid); } return uid; } var user_str = randomUid();

                 
                 function randomUid() {
    const keyStr = 'mtWebPushRandomUid';
    let uid = window.localStorage.getItem(keyStr);
    if (!uid) {
        uid = new Date().getTime().toString(36) + Math.floor(Math.random() * 10000000).toString(36);
        window.localStorage.setItem(keyStr, uid);
    }
    return uid;
   }
   var user_str = randomUid();
   
               

   Diesen Codeblock im schwebenden Fenster anzeigen

Welche Plattformen unterstützen WebPush?

Browser-Unterstützung nach Betriebssystem

Hinweis 1: Microsoft Edge (ab 2019), Opera, Samsung Internet, Yandex und UC Browser basieren auf Chromium und werden in EngageLab als Chrome erkannt.
Hinweis 2: Der Internet Explorer erhält keine Funktionsupdates mehr. Microsoft entwickelt den Browser nun auf Basis von Edge weiter.
Hinweis 3: Inkognito-Modus, privates Surfen und Gastmodus unterstützen keine WebPush-Benachrichtigungen.

Unterstützung nach Browserversion

Häufig gestellte Fragen (FAQ) zu Safari-Browser-WebPush-Benachrichtigungen

WebPush-Benachrichtigungen im Safari-Browser werden auf macOS (ab V11.1+) sowie iOS/iPadOS 16.4+ unterstützt.

Welche Funktionen unterstützen Safari-Push-Benachrichtigungen?

Wie erhalten Nutzer:innen auf iOS und iPadOS Safari-WebPush-Benachrichtigungen?

1. Wie können Entwickler:innen Nutzer:innen ermöglichen, WebPush-Benachrichtigungen unter iOS/iPadOS 16.4+ zu empfangen?

Ab iOS/iPadOS 16.4+ sind WebPush-Benachrichtigungen verfügbar. Die Website muss jedoch eine korrekte Manifest-Datei besitzen und die richtigen Attribute setzen. Fügen Sie folgenden Code in das HTML der Integrationsseite ein: <link rel="manifest" href="manifest.json"/>

Manifest-Datei-Beispiel:

              
              {
    "$schema": "https://json.schemastore.org/web-manifest-combined.json",
    "display": "standalone",
    "start_url": "/webpush/index.html",
    "name": "Engagelab WebPush Example",
    "short_name": "Engagelab",
    "icons": [
        {
            "src": "/icon-large-cb438cac.png",
            "type": "image/png",
            "sizes": "1024x1024"
        }
    ]
}

            

2. Damit Nutzer:innen mobile Safari-WebPush-Benachrichtigungen abonnieren und empfangen können, müssen sie die Web-App zum Home-Bildschirm hinzufügen

Um mobile Safari-WebPush-Benachrichtigungen (iOS/iPadOS 16.4+) zu empfangen, sind folgende Schritte erforderlich:

• Besuchen Sie die Website mit Safari auf einem Apple-Gerät mit Version 16.4+.
• Tippen Sie auf das Teilen-Symbol im Safari-Browser.
• Wählen Sie „Zum Home-Bildschirm hinzufügen“.
• Speichern Sie die Anwendung auf dem Gerät.
• Öffnen Sie die Anwendung vom Home-Bildschirm aus.
• Abonnieren Sie Benachrichtigungen (dazu muss vor dem nativen Berechtigungs-Popup auf „Abonnieren“ getippt werden). Diese Schritte sind notwendig, um mobile WebPush-Benachrichtigungen zu erhalten.

Da diese Interaktion für Endnutzer:innen relativ komplex ist, sollten Sie Ihre Nutzer:innen aktiv über die Vorteile des Abonnements informieren.

3. Banner-Hinweis auf der Website integrieren, um Nutzer:innen zum „Zum Home-Bildschirm hinzufügen“ zu leiten

Sie können ein Banner auf Ihrer Website einblenden, das Nutzer:innen auf mobilen Apple-Geräten über den Mehrwert von WebPush-Benachrichtigungen informiert und erklärt, wie sie abonnieren können.
Wir empfehlen, ein Banner zu integrieren, das Besucher:innen auffordert, das Teilen-Symbol und anschließend „Zum Home-Bildschirm hinzufügen“ zu wählen.
Ein beliebtes Open-Source-Projekt zur Unterstützung:
Bottom-Banner-Beispiel auf Github: https://github.com/rajatsehgal/add-to-home-screen

Kann ich Benachrichtigungen empfangen, wenn der Browser geschlossen ist?

• Über den EngageLab-Kanal müssen Sie die Website geöffnet haben, um Benachrichtigungen zu empfangen.
• Über den Systemkanal können Benachrichtigungen auch dann empfangen werden, wenn der Browser geschlossen ist. Das Verhalten variiert je nach Plattform:

Unter Windows können Systembenachrichtigungen empfangen werden, solange der Browserprozess im Hintergrund läuft. Ist der Prozess geschlossen, werden keine Benachrichtigungen empfangen.

Unter macOS laufen die meisten Browserprozesse auch nach dem Schließen aller Fenster weiter, sodass Systembenachrichtigungen empfangen werden können. Wird der Prozess jedoch komplett beendet, sind keine Benachrichtigungen mehr möglich. Safari kann Benachrichtigungen auch ohne laufenden Prozess empfangen, da diese direkt an das Betriebssystem gesendet werden. Nutzer:innen müssen Safari-Benachrichtigungen jedoch zuvor registrieren.

Fragen zum Benachrichtigungsberechtigungs-Popup

Wann erscheint das Popup erneut, wenn ein:e Nutzer:in die WebPush-Aufforderung ablehnt?

Wenn ein:e Nutzer:in im nativen Berechtigungs-Popup auf „Blockieren“ (Chrome), „Nicht erlauben“ (Safari) oder „Nie erlauben“ (Firefox) klickt, kann die Website keine weiteren Popups anzeigen, es sei denn, der:die Nutzer:in ändert die Einstellungen manuell im Browser. Daher empfiehlt EngageLab die Nutzung des EngageLab-Prompts (zu den Einstellungen).

Native Berechtigungs-Aufforderung

Ein WebPush-Abonnement erfordert ein natives Browser-Berechtigungs-Popup, das nicht angepasst werden kann. Es verwendet die im Browser eingestellte Sprache. Nur HTTPS-Websites können das native Popup anzeigen.

Chrome: Sie haben drei Versuche, Nutzer:innen zum Abonnieren zu bewegen. Nach dreimaligem Schließen des Popups erscheint es für eine Woche nicht mehr. Details zu dieser Chrome-Funktion finden Sie hier.
Firefox: Ab Version 70 muss nach dem Schließen des Popups auf das kleine Benachrichtigungssymbol im Browser geklickt werden, um das Popup erneut zu erhalten. Ab Version 72 wird das native Popup standardmäßig blockiert, Details hier.
Safari: Ähnlich wie Firefox gibt es eine ruhigere Benutzeroberfläche für Nutzer:innen, die Berechtigungen meist ablehnen, und automatische Popups für Websites, bei denen Push abgelehnt wurde, Safari 12.1+

EngageLab Soft Prompt

Da das native Popup nur einmal erscheint und nach Ablehnung keine erneute Abfrage möglich ist, empfiehlt EngageLab, das „Soft Prompt“-Verfahren zu nutzen:
Wenn ein:e Nutzer:in im EngageLab-Prompt auf „Erlauben“ oder „Abbrechen“ klickt, aber noch kein natives Abonnement besteht, kann das EngageLab-Prompt erneut angezeigt werden.

• Klickt der:die Nutzer:in auf „Erlauben“ im EngageLab-Prompt, erscheint das native Popup. Wird dort auf „Abbrechen“ geklickt, kann das EngageLab-Prompt beim nächsten Besuch erneut erscheinen.
• Klickt der:die Nutzer:in auf „Erlauben“ im EngageLab-Prompt und dann auch im nativen Popup, ist die Berechtigung erteilt; bei „Ablehnen“ im nativen Popup ist keine erneute Abfrage möglich.
• Klickt der:die Nutzer:in auf „Abbrechen“ im EngageLab-Prompt, wird davon ausgegangen, dass aktuell kein Interesse besteht. Das native Popup wird nicht angezeigt, aber beim nächsten Besuch kann das EngageLab-Prompt erneut erscheinen.

WebPush Benachrichtigungen werden nicht angezeigt – Fehlerbehebung

Fehlerbehebung bei nicht erhaltenen Benachrichtigungen

1. Prüfen Sie die Berechtigungen in der Benachrichtigungsleiste der Webseite.

2. Prüfen Sie, ob die Benachrichtigungsberechtigungen der Browser-Anwendung aktiviert sind. Windows-Benachrichtigungseinstellungen:

• Schalten Sie den Fokus-Assistenten aus. Weitere Informationen finden Sie in der offiziellen Microsoft-Dokumentation.
  
• Prüfen Sie Einstellungen > Benachrichtigungen und Aktionen > Benachrichtigungen von Apps und anderen Absendern aktivieren. Stellen Sie sicher, dass Ihre Website und der Browser aktiviert sind. Weitere Informationen in der offiziellen Microsoft-Dokumentation.
  

macOS-Benachrichtigungseinstellungen:

• In Systemeinstellungen > Mitteilungen > Chrome oder den gewünschten Browser, „Mitteilungen erlauben“ aktivieren.
• In Systemeinstellungen > Mitteilungen > Fokus > „Nicht stören“ und „Schlafen“ prüfen, ob diese Modi deaktiviert sind oder Sie sich im erlaubten Benachrichtigungszeitraum befinden.
• macOS bietet außerdem eine temporäre „Nicht stören“-Einstellung im Menü oben rechts > nach oben scrollen.

3. Instabilität beim Browser-Hersteller – Wechseln Sie bevorzugt auf den EngageLab-Kanal.

              
              {
    "from":"web_push",
    "to":{
        "registration_id":[
            "xxx"
        ]
    },
    "body":{
        "platform":"web",
        "notification":{
            "web":{
                "title":"web_push",
                "alert":"Hi,MTPush !",
                "url":"http://www.google.com",
                "extras":{
                    "web-key1":"web-value1"
                }
            }
        },
        "options":{
            "time_to_live":30,
            "third_party_channel":{
                "w3push":{
                    "distribution":"mtpush"
                }
            }
        },
        "request_id":"12345678",
        "custom_args":"business info"
    }
}

            

Safari Benachrichtigungen aktivieren – Fehlerbehebung

Wie behebe ich Probleme, wenn Safari keine Benachrichtigungen anzeigt?

Schritt 1: Überprüfen Sie die Safari-Browserberechtigungen und achten Sie darauf, ob der Schalter „Erlauben“ aktiviert ist. Der Normalfall ist im Bild dargestellt:

Schritt 2: Prüfen Sie den Push-Service-Status und die Benachrichtigungsberechtigung im Browser. Der Normalfall ist im Bild dargestellt:

Schritt 3: Gehen Sie in Safari auf „Einstellungen“ > „Websites“ > „Mitteilungen“ und prüfen Sie, ob die Website für das Notification Center zugelassen ist. Der Normalfall ist im Bild dargestellt.

Hinweis:

1. Nach Klick auf „Push stoppen“ werden keine Aurora-Push-Nachrichten mehr empfangen; die Seite muss aktualisiert werden.
   
2. Wenn für eine Domain mehrere HTML-Seiten konfiguriert sind, entfernen Sie nicht die Website-Berechtigungen des Notification Centers. Nach dem Löschen erhalten die HTML-Seiten keine Benachrichtigungen mehr (Sie müssen die Hauptseite finden und die Berechtigung erneut einholen).
   

Was passiert, wenn ein:e Nutzer:in mehrere Browser verwendet und eine Nachricht an ihn:sie gesendet wird?

Wenn die gewählte Verteilungsstrategie Systemkanäle priorisiert, wird die Nachricht nur über den zuletzt genutzten Browserkanal gesendet. Wird ausschließlich der Jiguang-Kanal genutzt, werden mehrere Nachrichten versendet.

Erhält ein:e Nutzer:in weiterhin WebPush von dieser Website, wenn Browser-Cache und Cookies gelöscht werden?

Beim Jiguang-Kanal können Push-Benachrichtigungen weiterhin empfangen werden, solange der:die Nutzer:in online ist.
Bei Browser-Hersteller-Kanälen führt das Löschen von Cookies und Cache dazu, dass das Abonnement aufgehoben wird, da die Abonnementdaten im IndexedDB-Speicher des Browsers liegen. Das Entfernen dieser Daten lässt den Browser den:die Abonnent:in „vergessen“. Die bereits erteilte Benachrichtigungsberechtigung bleibt jedoch erhalten. Das SDK muss neu initialisiert werden, damit Nutzer:innen beim erneuten Besuch automatisch wieder abonnieren.
Werden die Benachrichtigungseinstellungen im Browser auf „Fragen“ oder „Blockieren“ gesetzt, erfolgt keine automatische Wiederanmeldung.
Wird die Benachrichtigung in den Browsereinstellungen entfernt, erfolgt ebenfalls keine automatische Wiederanmeldung.

So löschen Sie Benachrichtigungen in verschiedenen Browsern:

• Chrome: chrome://settings/content/notifications
  

• Firefox: about:preferences#privacy > Berechtigungen > Mitteilungen

• Safari: Einstellungen > Websites > Mitteilungen > Entfernen !

Nach erneutem Abonnement erhalten Nutzer:innen eine neue Registration-ID. Sie können window.MTpushInterface.getRegistrationID() verwenden, um die rid zu erhalten.

Was passiert, wenn mehrere Nachrichten gleichzeitig an denselben Nutzer gesendet werden?

Die Anzeige von Nachrichten unterscheidet sich je nach Push-Kanal:

• EngageLab-Kanal: Es gibt keinen Überschreibungsmechanismus – werden mehrere Nachrichten gleichzeitig gesendet, werden alle angezeigt. Im Notification Center werden mehrere Nachrichten gespeichert, wobei nur die neueste Nachricht hervorgehoben wird, die anderen werden zusammengeklappt.
• Safari: Ebenfalls kein Überschreibungsmechanismus – alle Nachrichten werden angezeigt und im Notification Center zusammengeklappt.
• Chrome: Überschreibungsmechanismus – jede neue Nachricht ersetzt die vorherige, es wird nur die letzte angezeigt.
• Edge: Überschreibungsmechanismus – jede neue Nachricht ersetzt die vorherige, es wird nur die letzte angezeigt.
• Firefox: Überschreibungsmechanismus – jede neue Nachricht ersetzt die vorherige, es wird nur die letzte angezeigt.

WebPush Domainwechsel – Unterstützt EngageLab WebPush einen Domainwechsel?

Browser binden WebPush-Abonnent:innen an eine bestimmte Quelle (Domain/Website-URL).
Aus Sicherheitsgründen und wegen der Same-Origin-Policy der Browser ist es nicht möglich, Abonnent:innen auf eine andere Quelle zu übertragen. Dies ist keine Einschränkung von EngageLab – jeder Anbieter, der das Gegenteil behauptet, sollte kritisch hinterfragt werden.
Bei einem Domainwechsel empfiehlt es sich, eine neue WebPush-Anwendung für die neue Website einzurichten und die Nutzer:innen zum erneuten Abonnieren aufzufordern. Ein Import von Abonnent:innen zwischen verschiedenen Quellen ist nicht möglich.
Sie können weiterhin Push-Benachrichtigungen an Abonnent:innen der alten Website senden, aber für die neue Domain müssen Nutzer:innen erneut abonnieren. Empfohlene Schritte für die Migration:

• Neue WebPush-Anwendung für die neue Domain einrichten.
  
• Weiterhin Pushes von der alten Anwendung mit der alten Domain versenden. In der Benachrichtigung („launch URL“) die neue Domain angeben.
  
• Nach 2 Wochen bis 2 Monaten (je nach Versandhäufigkeit und Abonnent:innenzahl) kann die alte Anwendung abgeschaltet werden.
  
• Senden Sie die gleiche Nachricht nicht gleichzeitig von beiden Anwendungen, da sonst doppelte Nachrichten erscheinen.
  
• Senden Sie einige Benachrichtigungen wie „Wir sind umgezogen, klicken Sie hier, um unsere neue Website zu besuchen und weiterhin Benachrichtigungen zu erhalten.“ Dies hilft, Nutzer:innen auf den Wechsel aufmerksam zu machen.
  
• Rechnen Sie damit, dass kurzfristig einige Abonnent:innen verloren gehen können.
  Achten Sie beim Umzug auf eine gute Nutzererfahrung.

Unterstützt EngageLab WebPush PWA Push-Benachrichtigungen?

1. Was ist PWA?

PWA Push bezeichnet das Versenden von Benachrichtigungen an Nutzer:innen von Progressive Web Apps (PWA) mittels WebPush-Technologie. PWAs sind Webanwendungen, die sich wie native Apps verhalten und direkt im Browser genutzt werden können.
PWA Push wird über die WebPush-Technologie des Browsers realisiert. Damit können Benachrichtigungen auch dann empfangen werden, wenn die App nicht aktiv ist oder komplett geschlossen wurde.
Im Gegensatz zu klassischen Apps müssen PWAs nicht aus App-Stores installiert werden, sondern sind direkt über eine URL im Browser erreichbar. PWA Push-Benachrichtigungen sorgen für zeitnahe Informationen und steigern die Nutzerbindung.
Zusammengefasst ist PWA Push eine Methode, um Nutzer:innen von Progressive Web Apps mit WebPush-Benachrichtigungen zu versorgen und so die Interaktion und das Nutzungserlebnis zu verbessern.

2. Unterstützt EngageLab WebPush PWA Push-Benachrichtigungen?

Der EngageLab WebPush-Service unterstützt Progressive Web App Push-Benachrichtigungen. Sie müssen dazu das WebPush-Feature mit dem Web SDK von EngageLab in Ihre PWA integrieren, den Service Worker (Hintergrunddienst im Browser) registrieren und die Funktion initialisieren. Nach der Integration können Sie die EngageLab WebPush API nutzen, um Benachrichtigungen an Ihre PWA-Nutzer:innen zu senden.

Hinweis: Für die Unterstützung von PWA durch das WebSDK sind zwei Voraussetzungen notwendig:
1. Die Anwendung läuft in einem Browser mit W3C-Benachrichtigungsunterstützung; 2. Es existiert eine eigene Domain und HTTPS wird verwendet.

3. Kann der Service Worker einer PWA mit dem von EngageLab WebPush in Konflikt geraten?

Der Service Worker (Hintergrunddienst im Browser) einer PWA und der von EngageLab WebPush könnten in Konflikt geraten, da pro Ursprung (Origin) normalerweise nur ein Service Worker aktiv sein kann.

Service Worker sind Skripte, die im Hintergrund laufen und Funktionen wie Offline-Nutzung, Push und Synchronisierung ermöglichen. Da ein Service Worker alle Seiten in seinem Geltungsbereich kontrolliert, können nicht mehrere Service Worker gleichzeitig für denselben Bereich aktiv sein.

Wenn Sie versuchen, mehrere Service Worker für dieselbe Anwendung/Domäne zu registrieren, kann der zuletzt registrierte den vorherigen ersetzen oder es entstehen Konflikte bei sich überschneidenden Geltungsbereichen. Das kann dazu führen, dass Push-Nachrichten nur über einen Kanal korrekt funktionieren.

Um Konflikte zu vermeiden, beachten Sie bitte:

1. Verwenden Sie möglichst nur einen Service Worker pro Anwendung. Wenn Sie sowohl EngageLab WebPush als auch PWA-Funktionen benötigen, sollten beide in einem gemeinsamen Service Worker-Skript integriert werden.

2. Falls zwei separate Service Worker notwendig sind, stellen Sie sicher, dass sich deren Geltungsbereiche nicht überschneiden. Dies erreichen Sie durch unterschiedliche Scope-Pfade bei der Registrierung.

Lesen Sie vor der Implementierung die Dokumentation sorgfältig und testen Sie ausgiebig in Entwicklungs- und Produktionsumgebungen, damit die Service Worker problemlos koexistieren.

4. Unterschiede beim Berechtigungs-Popup für PWA-Benachrichtigungen auf iOS- und Android-Geräten

• iOS-Systemeinschränkungen (Safari/WebKit-Richtlinien): · Aus Datenschutzgründen ist für das Berechtigungs-Popup eine Nutzeraktion (z. B. Klick) erforderlich
  · Diese WebKit-Richtlinie gilt für alle PWAs und Webanwendungen
  · Auch nach der Installation einer PWA ist eine Interaktion zur Berechtigungsanfrage nötig

• Android-Systemeigenschaften: · Chrome/WebView erlauben automatische Berechtigungsanfragen beim Laden der Seite
  · Lockeres Berechtigungsmodell
  · Einige Android-Versionen unterstützen sogar schrittweise Berechtigungsabfragen

Warum haben verschiedene Browser dieselbe regid?

A: Wenn für dieselbe Anwendung und Domain derselbe userStr verwendet wird, wird unabhängig vom Browser dieselbe rid generiert.

              
              // Registrieren von Event-Listenern vor der Initialisierung
// Callback bei Trennung vom JPush-Kanal
MTpushInterface.mtPush.onDisconnect(function () {
  console.log("onDisconnect");
});

// Empfang von Push-Nachrichten (WebPush, Browser-Herstellerkanal)
MTpushInterface.onMsgReceive((msgData) => {
  // msgData Struktur {data:{xxx}, type:0} 
  // type:0 ist JPush-Kanal, type:1 ist Systemkanal
  console.log("Push-Nachricht empfangen:", msgData);
});

// Push-Initialisierung
MTpushInterface.init({
  appkey: "", // Pflichtfeld, siehe Anwendungsinformationen oben
  user_str: visitorId, // Pflichtfeld, Nutzerkennung
  fail(err) {
    console.log("Online-Push-Erstellung fehlgeschlagen", err);
  },
  success(data) {
    console.log("Online-Push erfolgreich erstellt", data);
  },
  webPushcallback(code, tip) {
    console.log("Statuscode und Hinweis erhalten", code, tip);
  },
  swUrl: '', // Standard: "/sw.min." + sdkEnv.version + ".js"
  canGetInfo(data) {
    // Benachrichtigungskonfiguration hier verfügbar
    // RegId nach diesem Callback verfügbar
    console.log(data); // Konfigurationsinformationen
    console.log("Erhaltene RegId", MTpushInterface.getRegistrationID());
  },
  custom: (fuc) => {
    // Bei individueller Benachrichtigungskonfiguration:
    // 1. fuc() manuell aufrufen, um Berechtigung anzufordern
    // 2. Nur über individuellen Callback verfügbar
    // 3. fuc() fordert Benachrichtigungsberechtigung an
  }
});

            

Sollten während der Nutzung Fragen auftreten, die in diesem Dokument nicht beantwortet werden, wenden Sie sich gerne an den Kundenservice. Wir unterstützen Sie gerne mit professionellem Support und Lösungen.