FAQ

Informationen zur eindeutigen Benutzerkennung user_str

1. Während der Initialisierung muss der Entwickler eine eindeutige Zeichenfolge (user_str) bereitstellen, um den eindeutigen Identifikationscode (UID) des Benutzers zu generieren. Diese UID wird zur Identitätserkennung für Push-Benachrichtigungen verwendet und ist unabhängig vom Gerät des Benutzers.
   

2. Wenn sich ein Benutzer mit derselben user_str in mehreren Browsern oder auf mehreren Geräten anmeldet, identifiziert das System ihn als denselben Benutzer. Die neuen Abonnementinformationen ersetzen die alten Informationen, sodass der Benutzer Nachrichten auf dem Gerät bzw. im Browser erhält, das bzw. der für das zuletzt erfolgte Abonnement verwendet wurde. Dadurch wird verhindert, dass derselbe Benutzer doppelte Nachrichten auf mehreren Geräten oder in mehreren Browsern erhält. Das System-Backend speichert für jede UID nur die neuesten Abonnementinformationen.
   

3. Benutzer können das Abonnement jederzeit kündigen, und unser SDK bietet die entsprechende Schnittstelle zur Implementierung dieser Funktion. Durch das Abbestellen wird die UID von den Abonnementinformationen entkoppelt, die Benachrichtigungsberechtigungseinstellungen des Browsers werden dadurch jedoch nicht geändert.
   

4. Theoretisch sollte user_str einer Benutzerkennung eins zu eins entsprechen. In einigen Szenarien befinden sich Benutzer möglicherweise im Gastmodus. In diesem Fall müssen Entwickler entsprechend der tatsächlichen Situation eine eindeutige user_str generieren. Unser SDK übernimmt diesen Schritt nicht automatisch, um ungenaue Statistikdaten zu vermeiden, die durch eine unsachgemäße Verarbeitung von user_str verursacht werden.
   

Für Benutzer im Gastmodus können Entwickler die folgende Beispielfunktion verwenden, um auf Grundlage der Eindeutigkeit des Browsers des Benutzers eine user_str zu generieren. Bitte beachten Sie jedoch, dass bei diesem Ansatz eine neue user_str generiert werden kann, wenn der Benutzer den Browser wechselt, das Gerät wechselt oder den Cache löscht.
Beispielfunktion

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 Web Push?

Browser-Unterstützung nach Betriebssystem

Hinweis 1: Microsoft Edge (seit 2019 aktualisiert), Opera, Samsung Internet, Yandex und UC Browser sind allesamt Chromium-basierte Browser und werden in EngageLab als Chrome gekennzeichnet.
Hinweis 2: Internet Explorer erhält keine Funktionsupdates mehr. Microsoft hat die Browserentwicklung auf die Edge-Plattform verlagert.
Hinweis 3: Der Inkognito-Modus, der private Browsermodus und der Gastmodus des Browsers unterstützen keine Web-Push-Benachrichtigungen.

Unterstützung nach Browserversion

Probleme mit Web-Push-Benachrichtigungen im Zusammenhang mit dem Safari-Browser

Web-Push-Benachrichtigungen werden in Safari unter macOS (11.1+) und iOS/iPadOS 16.4+ unterstützt.

Welche Funktionen unterstützt Safari Push?

Wie können Benutzer unter iOS und iPadOS Safari-Web-Push-Benachrichtigungen erhalten?

1. Wie sollten Entwickler die Einstellungen konfigurieren, damit Benutzer unter iOS/iPadOS 16.4+ Web-Benachrichtigungen erhalten können?

Web-Push-Benachrichtigungen können unter iOS/iPadOS 16.4+ verwendet werden. Allerdings muss die Website über eine korrekte Manifest-Datei und korrekt konfigurierte Eigenschaften verfügen, damit Benachrichtigungen ordnungsgemäß funktionieren. Fügen Sie den folgenden Code in das HTML der entsprechenden Integrationsseite ein: <link rel="manifest" href="manifest.json" />

Fügen Sie die Manifest-Datei ein:

              
              {
  "$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 Benutzer mobile Safari-Web-Push-Benachrichtigungen abonnieren und empfangen können, müssen sie die Web-App zum Home-Bildschirm hinzufügen

Zum Senden mobiler Safari-Web-Push-Benachrichtigungen (für iOS und iPadOS 16.4+) müssen Benachrichtigungsempfänger Folgendes tun:

• Besuchen Sie Ihre Website im Safari-Browser auf einem mobilen Apple-Gerät mit Version 16.4+.
• Tippen Sie in Safari auf dem mobilen Gerät auf die Teilen-Schaltfläche.
• Tippen Sie auf die Option „Zum Home-Bildschirm“.
• Speichern Sie die App auf dem Gerät.
• Öffnen Sie die App über den Home-Bildschirm.
• Abonnieren Sie Benachrichtigungen (bevor die native Berechtigungsabfrage erscheint, müssen Sie auf die Schaltfläche zum Abonnieren tippen). Diese Schritte sind erforderlich, um mobile Web-Push-Benachrichtigungen zu erhalten.

Da dieser Interaktionsablauf für Endbenutzer relativ komplex ist, sollten Sie ihnen helfen, die Vorteile des Abonnierens von Benachrichtigungen zu verstehen.

3. Fügen Sie auf Ihrer Website eine Banner-Benachrichtigung hinzu, um Benutzer zur Aktion „Zum Home-Bildschirm hinzufügen“ zu führen

Sie können Ihrer Website ein Banner hinzufügen, um Endbenutzer über den Nutzen mobiler Web-Push-Benachrichtigungen zu informieren und sie beim Abonnieren zu unterstützen.
Wir empfehlen, Ihrer Website ein Banner hinzuzufügen, das auf mobilen Apple-Geräten angezeigt wird und Besucher dazu anleitet, auf die Teilen-Schaltfläche und die Option „Zum Home-Bildschirm“ zu tippen.
Es gibt auch ein beliebtes Open-Source-Projekt, das Ihnen helfen kann, diese Anweisungen für Benutzer bereitzustellen:
GitHub-Link zum Beispiel für ein unteres Banner: https://github.com/rajatsehgal/add-to-home-screen

Können Benutzer Benachrichtigungen erhalten, wenn der Browser geschlossen ist?

• Bei Verwendung des EngageLab-Kanals können Benachrichtigungen nur empfangen werden, wenn die Website geöffnet ist.
• Bei Verwendung des Systemkanals können Benachrichtigungen auch dann empfangen werden, wenn der Browser geschlossen ist, wobei sich das Verhalten je nach Plattform unterscheidet. Siehe die folgende Tabelle für Details:

Unter Windows können Systembenachrichtigungen weiterhin empfangen werden, wenn alle Fenster geschlossen sind, der Browser aber noch im Hintergrund läuft. Wenn der Browserprozess beendet wurde, werden keine Systembenachrichtigungen empfangen.
Unter macOS laufen die meisten Browserprozesse auch dann im Hintergrund weiter, wenn alle Fenster geschlossen sind, sodass Systembenachrichtigungen weiterhin empfangen werden können. Wenn der Browserprozess zwangsweise beendet wird, werden keine Systembenachrichtigungen empfangen. Safari muss zum Empfangen von Benachrichtigungen nicht ausgeführt werden, da diese direkt an das Betriebssystem zugestellt werden. Benutzer müssen Safari-Benachrichtigungen zunächst registrieren; danach können sie Benachrichtigungen weiterhin empfangen, selbst wenn Safari vollständig geschlossen ist.

Probleme im Zusammenhang mit Berechtigungsabfragen für Benachrichtigungen

Wann erscheint die Abfrage erneut, nachdem ein Benutzer die Web-Push-Abfrage geschlossen hat?

Wenn ein Benutzer in der nativen Berechtigungsabfrage auf „Block“ (Chrome), „Don't Allow“ (Safari) oder „Never Allow“ (Firefox) klickt, kann die Website ihn nicht erneut auffordern, es sei denn, der Benutzer durchläuft mehrere Schritte in den Browsereinstellungen, um Benachrichtigungen zu abonnieren oder Berechtigungen zurückzusetzen. Deshalb wird die Verwendung der EngageLab-Abfrage (Zu den Einstellungen) empfohlen.

Native Berechtigungsabfrage

Für Web-Push-Abonnements ist die native Berechtigungsabfrage des Browsers erforderlich, und diese kann nicht angepasst werden. Sie verwendet die in den Browsereinstellungen des Benutzers festgelegte Sprache. Nur HTTPS-Websites können die native Browserabfrage anzeigen.

Chrome: Sie haben 3 Chancen, Benutzer zum Abonnieren zu bewegen. Nachdem der Benutzer zum dritten Mal auf das „X“ der nativen Berechtigungsabfrage geklickt hat, erhält er die Abfrage eine Woche lang nicht erneut. Weitere Informationen zu dieser Chrome-Funktion finden Sie hier.
Firefox: Seit Firefox 70 muss der Benutzer nach dem Klicken auf die Schließen-Schaltfläche auf das kleine Benachrichtigungssymbol im Browser klicken, um die Abfrage erneut zu erhalten. Außerdem wurde ab Firefox 72+ die Anzeige der nativen Browserabfrage blockiert. Details finden Sie hier.
Safari: Ähnlich wie bei Firefox hat Safari eine unaufdringlichere UI für Benutzer eingeführt, die Berechtigungen häufig ablehnen, und fordert Websites, denen Push-Berechtigungen verweigert wurden, automatisch mit einer entsprechenden Abfrage auf, Safari 12.1+

EngageLab Soft Prompt

Da das native Popup nur eine einzige Chance bietet und die Website nach einer Ablehnung keine Autorisierung erneut anfordern kann, empfiehlt EngageLab die Verwendung eines „Soft Prompt“, um die Autorisierung des Benutzers einzuholen:
Wenn der Benutzer in der EngageLab-Abfrage (Zu den Einstellungen) auf „Allow“ oder „Cancel“ klickt und das Abonnement über das native Popup noch nicht abgeschlossen wurde, kann die EngageLab-Abfrage erneut erscheinen.

• Nachdem der Benutzer in der EngageLab-Abfrage auf „Allow“ geklickt hat, wird das native Popup ausgelöst. Wenn der Benutzer in der nativen Abfrage dann jedoch auf „Cancel“ klickt, erscheint die EngageLab-Abfrage beim nächsten Besuch der Website weiterhin und fragt, ob Benachrichtigungen von der Website erlaubt werden sollen.
  
• Nachdem der Benutzer in der EngageLab-Abfrage auf „Allow“ geklickt hat, wird das native Popup ausgelöst. Wenn der Benutzer in der nativen Abfrage dann auf „Allow“ klickt, autorisiert der Benutzer die Website für Web-Benachrichtigungen; wenn der Benutzer in der nativen Abfrage dann auf „Deny“ klickt, kann die Website keine Autorisierung vom Benutzer mehr erhalten.
  
• Wenn der Benutzer in der EngageLab-Abfrage auf „Cancel“ klickt, kann daraus geschlossen werden, dass der Benutzer derzeit keine Benachrichtigungen von der Website erhalten möchte. Da eine Abfrage zu diesem Zeitpunkt wahrscheinlich abgelehnt würde, lösen wir das native Popup nicht aus, und beim nächsten Besuch kann über die EngageLab-Abfrage erneut gefragt werden, ob Benachrichtigungen empfangen werden sollen.

Fehlerbehebung, wenn Benachrichtigungen nicht empfangen werden

1. Prüfen Sie, ob Benachrichtigungsberechtigungen für die Webseite aktiviert sind

2. Prüfen Sie, ob Benachrichtigungsberechtigungen für die Browseranwendung aktiviert sind
Windows-Benachrichtigungseinstellungen:

• Deaktivieren Sie „Focus Assist“. Details finden Sie in der offiziellen Microsoft-Dokumentation.
• Prüfen Sie Einstellungen > Benachrichtigungen & Aktionen > Benachrichtigungen von Apps und anderen Absendern erhalten. Stellen Sie sicher, dass auch Ihre Website und Ihr Browser aktiviert sind. Weitere Details finden Sie in der offiziellen Microsoft-Dokumentation.

macOS-Benachrichtigungseinstellungen:

• Stellen Sie unter Systemeinstellungen > Mitteilungen > Chrome oder dem ausgewählten Browser sicher, dass Mitteilungen erlauben aktiviert ist.
• Stellen Sie unter Systemeinstellungen > Mitteilungen > Fokus > Nicht stören und Schlafen sicher, dass dieser Modus nicht aktiviert ist oder dass Sie sich innerhalb eines zulässigen Benachrichtigungszeitraums befinden.
• macOS verfügt außerdem über eine temporäre Benachrichtigungseinstellung Nicht stören im Menü oben rechts; scrollen Sie nach oben, um sie anzuzeigen.

3. Browseranbieter-Kanäle können instabil sein. Wechseln Sie daher zur priorisierten Zustellung über 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-Browser kann keine Benachrichtigungen anzeigen?

Schritt 1: Prüfen Sie die Berechtigungen des Safari-Browsers und stellen Sie sicher, dass der Schalter zum Zulassen aktiviert ist. Ein normaler Zustand ist unten dargestellt:

Schritt 2: Klicken Sie, um den Status des Push-Dienstes und die Berechtigungen für Browserbenachrichtigungen zu prüfen. Ein normaler Zustand ist unten dargestellt:

Schritt 3: Klicken Sie in Safari auf Einstellungen.

Klicken Sie auf Websites > Mitteilungen, und prüfen Sie, ob die Website im Mitteilungszentrum erlaubt ist. Ein normaler Zustand ist unten dargestellt:

Besonderer Hinweis:

1. Wenn Sie auf Stop Push klicken, wird der Empfang von JPush-Nachrichten verhindert, und die Seite muss aktualisiert werden.
2. Wenn unter einer Domain mehrere HTML-Seiten konfiguriert sind, entfernen Sie die Website-Berechtigung nicht aus dem Mitteilungszentrum. Nach dem Entfernen empfangen alle HTML-Seiten keine Benachrichtigungen mehr (der Benutzer muss dann die Hauptseite finden und die Benachrichtigungsberechtigung für die Website erneut erteilen).

Wenn derselbe Benutzer mehrere Browser gleichzeitig verwendet und eine Nachricht an diesen Benutzer gesendet wird, wie wird sie auf dem Gerät des Benutzers angezeigt?

Wenn als Zustellstrategie die Priorisierung des Systemkanals ausgewählt ist, wird diese Nachricht nur über den Browseranbieter-Kanal zugestellt, den der Benutzer zuletzt verwendet hat. Wenn die Zustellung nur über den JPush-Kanal ausgewählt ist, werden mehrere Nachrichten zugestellt.

Wenn der Benutzer den Browser-Cache und Cookies löscht, kann er dann weiterhin Web Push von dieser Website empfangen?

Wenn der Benutzer online ist, kann der JPush-Kanal weiterhin Push-Nachrichten empfangen.
Bei Browseranbieter-Kanälen gilt: Wenn Benutzer Browser-Cookies und den Cache löschen, kündigen sie ihr Benachrichtigungsabonnement. Das liegt daran, dass Benutzerdaten von Abonnenten im IndexedDB-Speicher des Browsers gespeichert werden. Wird dieser Datensatz entfernt, „vergisst“ der Browser den Abonnenten. Das Löschen dieser Daten entfernt jedoch nicht die dem Benutzer bereits erteilte Berechtigung zum Empfangen von Benachrichtigungen in diesem Browser. An diesem Punkt ist eine SDK-Initialisierung erforderlich, damit der Benutzer bei seiner Rückkehr zur Website automatisch erneut abonniert werden kann.
Wenn der Benutzer die Benachrichtigungsberechtigung des Browsers jedoch auf „Ask“ oder „Block“ ändert, wird er nicht automatisch erneut abonniert.
Wenn der Benutzer Benachrichtigungen in den Benachrichtigungseinstellungen des Browsers löscht, wird er ebenfalls nicht automatisch erneut abonniert.

So löschen Sie Benachrichtigungen in den einzelnen Browsern:

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

• Firefox: about:preferences#privacy > Permissions > Notifications
  

• Safari: Einstellungen > Websites > Mitteilungen > Entfernen
  

Wenn der Benutzer erneut abonniert, erhält er einen neuen Registration-ID-Datensatz. Sie können window.MTpushInterface.getRegistrationID() verwenden, um die RID abzurufen.

Wenn mehrere Nachrichten gleichzeitig an denselben Benutzer gesendet werden, werden dann alle Nachrichten angezeigt?

Der Mechanismus zur Nachrichtenanzeige variiert je nach Push-Kanal:
EngageLab-Kanal: Kein Überschreibungsmechanismus. Wenn mehrere Nachrichten gleichzeitig an denselben Benutzer gesendet werden, werden dem Benutzer mehrere Nachrichten gleichzeitig angezeigt. Das Mitteilungszentrum behält mehrere Nachrichten bei; mit Ausnahme der neuesten Nachricht werden die anderen eingeklappt.
Safari: Kein Überschreibungsmechanismus. Wenn mehrere Nachrichten gleichzeitig an denselben Benutzer gesendet werden, werden dem Benutzer mehrere Nachrichten gleichzeitig angezeigt. Das Mitteilungszentrum behält mehrere Nachrichten bei; mit Ausnahme der neuesten Nachricht werden die anderen eingeklappt.
Chrome: Verfügt über einen Überschreibungsmechanismus. Wenn mehrere Nachrichten gleichzeitig an denselben Benutzer gesendet werden, wird jede Benachrichtigung durch die aktualisierte Benachrichtigung ersetzt, und nur die zuletzt gesendete Nachricht wird angezeigt.
Edge: Verfügt über einen Überschreibungsmechanismus. Wenn mehrere Nachrichten gleichzeitig an denselben Benutzer gesendet werden, wird jede Benachrichtigung durch die aktualisierte Benachrichtigung ersetzt, und nur die zuletzt gesendete Nachricht wird angezeigt.
Firefox: Verfügt über einen Überschreibungsmechanismus. Wenn mehrere Nachrichten gleichzeitig an denselben Benutzer gesendet werden, wird jede Benachrichtigung durch die aktualisierte Benachrichtigung ersetzt, und nur die zuletzt gesendete Nachricht wird angezeigt.

Unterstützt EngageLab WebPush einen Domainwechsel?

Browser haben Web Push bereits so implementiert, dass Abonnenten an einen bestimmten Ursprung (Domainname/Website-URL) gebunden sind.
Aus Sicherheitsgründen und aufgrund der Same-Origin-Policy des Browsers erlauben Browser nicht, Abonnenten zu einem anderen Ursprung zu verschieben. Dies ist keine Einschränkung von EngageLab. Wenn ein Anbieter behauptet, Abonnenten von einer Website auf eine andere verschieben zu können, stellen Sie unbedingt sicher, dass tatsächlich Ihre Website abonniert wird.
Wenn Sie Ihre Website geändert haben, ist die beste Lösung, eine neue WebPush-App für die neue Website einzurichten und Ihre Benutzer die Website unter dieser neuen App abonnieren zu lassen. Sie können keine Abonnenten von einem Ursprung in einen anderen importieren.
Sie können weiterhin Push-Benachrichtigungen an Abonnenten der alten Website (alte WebPush-App) senden, aber Ihre Benutzer müssen die neue Website erneut abonnieren, um Push-Nachrichten von der neuen Domain zu erhalten. Die empfohlenen Migrationsschritte sind wie folgt:

• Richten Sie eine neue WebPush-App für die Domain der neuen Website ein.
  
• Senden Sie weiterhin Push-Nachrichten aus der alten WebPush-App mit der Domain der alten Website. Verwenden Sie in der „Launch URL“ der Benachrichtigung die Domain der neuen Website.
  
• Nach 2 Wochen bis 2 Monaten (je nachdem, wie viele Benachrichtigungen Sie täglich senden und wie viele Abonnenten Sie auf der neuen Website gewinnen), können Sie die alte WebPush-App nicht mehr verwenden und nur noch die neue WebPush-App nutzen.
  
• Wenn Sie dieselbe Nachricht sowohl aus der alten WebPush-App als auch aus der neuen WebPush-App senden, erhalten Abonnenten beider Apps doppelte Nachrichten. Deshalb empfehlen wir, diesen Zeitplan einzuhalten.
  
• Sie können mehrere Nachrichten senden wie „Wir sind umgezogen. Klicken Sie hier, um unsere neue Website zu besuchen und sich erneut anzumelden, damit Sie auf dem Laufenden bleiben.“ Dadurch werden Benutzer daran erinnert, dass sie möglicherweise keine Push-Nachrichten mehr von Ihrer Website erhalten, wenn sie nicht zurückkehren und sich erneut anmelden. Es wird empfohlen, diese Art von Benachrichtigung zu Beginn der Migration und mit der letzten aus der App gesendeten Nachricht zu senden.
  
• Leider ist jede Website und jede Benutzergruppe anders. Bitte stellen Sie sich darauf ein, kurzfristig Abonnenten zu verlieren.
  

Achten Sie bei der Durchführung der oben genannten Migrationsschritte unbedingt auf die Benutzerfreundlichkeit, um Unannehmlichkeiten für Benutzer zu vermeiden.

Unterstützt EngageLab WebPush PWA-Push?

1. Was ist PWA?

PWA-Push bezeichnet den Prozess, bei dem in Progressive Web Apps (PWAs) mithilfe von Web-Push-Technologie Benachrichtigungen an Benutzer gesendet werden. Eine PWA ist eine mit Webtechnologien erstellte Anwendung, die Funktionen und eine Benutzererfahrung ähnlich einer nativen Anwendung bietet und gleichzeitig ohne Installation über einen Browser zugänglich ist.
PWA-Push wird über die vom Browser bereitgestellte Web-Push-Technologie umgesetzt. Mit Web-Push-Technologie können Webanwendungen Push-Benachrichtigungen wie native Anwendungen senden, selbst wenn die Anwendung nicht aktiv oder vollständig geschlossen ist.
Im Gegensatz zu herkömmlichen Anwendungen müssen PWAs nicht aus einem App-Store heruntergeladen und installiert werden und können direkt über eine URL im Browser aufgerufen werden. Gleichzeitig kann PWA-Push Benutzern zeitnahe Nachrichtenhinweise bereitstellen und so Benutzererfahrung und Interaktion verbessern.
Kurz gesagt ist PWA-Push eine Methode, mit der mithilfe von Web-Push-Technologie Benachrichtigungen an Benutzer von Progressive Web Apps gesendet werden, um die Benutzerinteraktion und das Engagement zu verbessern und Webanwendungen gleichzeitig eine Benutzererfahrung zu bieten, die nativen Anwendungen näherkommt.

2. Unterstützt EngageLab WebPush PWA-Push?

Der EngageLab-WebPush-Dienst unterstützt PWA-Push. Sie müssen das von EngageLab WebPush bereitgestellte Web SDK verwenden, um die Web-Push-Funktionalität in Ihre PWA-Anwendung zu integrieren, und dem Beispielcode in der Dokumentation folgen, um einen Service Worker zu registrieren und die Web-Push-Funktionalität zu initialisieren. Sobald die Integration abgeschlossen ist, können Sie die EngageLab-WebPush-API verwenden, um Push-Benachrichtigungen an Benutzer Ihrer PWA-Anwendung zu senden.

Hinweis: Damit das Web SDK PWA unterstützt, müssen zwei notwendige Bedingungen erfüllt sein:

1. Die Anwendung läuft in einem Browser, und der Browser unterstützt W3C-Benachrichtigungen.
2. Es gibt einen bestimmten Domainnamen, und es wird das HTTPS-Protokoll verwendet.

3. Kommt es zu Konflikten zwischen dem PWA-Service-Worker und dem EngageLab-WebPush-Service-Worker?

Der Service Worker einer PWA (Progressive Web App) und der Service Worker von EngageLab WebPush können miteinander in Konflikt geraten, da beide im Hintergrund des Browsers ausgeführt werden und für denselben Ursprung in der Regel jeweils nur ein Service Worker gleichzeitig aktiv sein kann.

Service Worker sind Skripte, die von Websites im Browser installiert werden und Offline-Erlebnisse, Push-Messaging, Hintergrundsynchronisierung und mehr unterstützen können. Da Service Worker Seiten innerhalb ihres Geltungsbereichs steuern, können mehrere Service Worker Seiten unter demselben Geltungsbereich nicht gleichzeitig steuern.

Wenn Sie versuchen, mehrere Service Worker unter derselben Anwendung bzw. derselben Domain zu registrieren, kann der später registrierte den vorherigen ersetzen, oder es können Konflikte auftreten, wenn sich die Geltungsbereiche der beiden Service Worker überschneiden. Dieser Konflikt kann zu unerwartetem Verhalten führen, etwa dazu, dass Push-Messaging nur über einen Kanal ordnungsgemäß funktioniert.

Um diesen Konflikt zu vermeiden, können Sie:

1. Stellen Sie sicher, dass Sie in Ihrer Anwendung nur einen Service Worker verwenden. Wenn die von EngageLab bereitgestellte Web-Push-Funktionalität und Ihre PWA-Funktionalität über denselben Service Worker umgesetzt werden können, ist es am besten, beides in einem Service-Worker-Skript zusammenzuführen.

2. Wenn Sie zwei separate Service Worker verwenden müssen, sollten Sie sicherstellen, dass sich ihre Geltungsbereiche nicht überschneiden. Dies kann erreicht werden, indem beim Registrieren der Service Worker unterschiedliche Scope-Pfade angegeben werden.

Vor der Implementierung wird empfohlen, die relevante Dokumentation sorgfältig zu lesen und sowohl in Entwicklungs- als auch in Produktionsumgebungen ausreichende Tests durchzuführen, um sicherzustellen, dass die Service Worker nebeneinander bestehen können, ohne sich gegenseitig zu beeinträchtigen.

4. Unterschiede im Verhalten des Berechtigungs-Popups für PWA-App-Benachrichtigungen auf iOS- und Android-Geräten

• iOS-Systemeinschränkungen (Safari/WebKit-Richtlinie):
  · Aus Datenschutzgründen verlangt iOS eine Benutzeraktion (z. B. einen Klick), bevor ein Berechtigungs-Popup ausgelöst werden kann.
  · Dies ist eine zwingende WebKit-Richtlinie und gilt für alle PWAs und Webanwendungen.
  · Auch nachdem eine PWA erstmals installiert wurde, ist vor der Berechtigungsanfrage weiterhin eine Benutzerinteraktion erforderlich.

• Eigenschaften des Android-Systems:
  · Chrome/WebView erlaubt es, Berechtigungen beim Laden der Seite automatisch anzufordern.
  · Es folgt einem großzügigeren Modell für Berechtigungsanfragen.
  · Einige Android-Versionen unterstützen sogar progressive Berechtigungsabfragen.

Warum kann die Registration ID in verschiedenen Browsern identisch sein?

Antwort: Für denselben integrierten Domainnamen, der für eine Anwendung konfiguriert ist, und dieselbe userStr des Benutzers wird unabhängig davon, ob es derselbe Browser ist, dieselbe RID generiert.

• Um zu prüfen, ob es sich um denselben Benutzer handelt, verwenden Sie die folgende Methode: Sehen Sie sich den HTML-Quellcode an und suchen Sie die Initialisierungsfunktion.

              
              // Bitte registrieren Sie Event-Listener vor der Initialisierung
// Callback, wenn die Verbindung zum JPush-Kanal getrennt wird
MTpushInterface.mtPush.onDisconnect(function () {
  console.log("onDisconnect");
});

// Push-Nachrichten empfangen (Web Push, Browseranbieter-Kanal)
MTpushInterface.onMsgReceive((msgData) => {
  // Datenstruktur von msgData {data:{xxx},type:0} type:0 ist der JPush-Kanal, 1 ist der Systemkanal
  console.log("Empfangene Push-Nachricht:", msgData);
});

// Push initialisieren
MTpushInterface.init({
  appkey: "", // Erforderlich. Wie Sie Anwendungsinformationen abrufen, siehe oben
  user_str: visitorId, // Erforderlich. Benutzerkennung zur Identifizierung des Benutzers
  fail(err) {
    console.log("Online-Push konnte nicht erstellt werden", err);
  },
  success(data) {
    console.log("Online-Push erfolgreich erstellt", data);
  },
  webPushcallback(code, tip) {
    console.log("Vom Benutzer empfangener Statuscode und Hinweis", code, tip);
  },
  swUrl: '', // Standard "/sw.min." + sdkEnv.version + ".js". Dieses Konfigurationselement ist die Adresse der Service-Worker-Datei. Der Domainname muss der aktuelle Domainname sein, und der Pfad bestimmt den Geltungsbereich des Service Workers.
  canGetInfo(data) {
    // An diesem Punkt können Sie einige Konfigurationsdaten für Benachrichtigungen abrufen, und nach dieser Callback-Funktion können Sie die RegId erhalten
    console.log(data); // Zugehörige Konfigurationsinformationen
    console.log("RegId abrufen", MTpushInterface.getRegistrationID());
  },
  custom: (fuc) => {
    // Wenn Sie eine benutzerdefinierte Prompt-Konfiguration verwenden, müssen Sie fuc() manuell aufrufen, um die Berechtigung für Benachrichtigungen anzufordern.
    // Die Funktion zum Anfordern der Benachrichtigungsberechtigung kann nur über custom abgerufen werden.
    // Durch den Aufruf von fuc() wird die Berechtigung für Benachrichtigungen angefordert
  },
});

            

Wenn Sie bei der Verwendung auf Probleme stoßen, die in diesem Dokument nicht behandelt werden, können Sie sich jederzeit gern an uns wenden. Wir bieten Ihnen professionelle Unterstützung und Antworten.