So steigern Sie die Anzahl der Web-Push-Impressionen

„Der Push wurde gesendet, aber die Impressionen liegen weit unter den Erwartungen“ ist eine der häufigsten Fragen von Web-Push-Integratoren. Impressionen sind keine isolierte Kennzahl, sondern das Ergebnis von Verlusten, die sich über Abonnement, Versand, Zustellung und weitere Stufen aufsummieren. Dieser Artikel hilft Ihnen, die Ursache zu geringer Impressionen Schicht für Schicht entlang des Funnels zu lokalisieren, liefert Optimierungsmaßnahmen für jede Ursachenart und schließt mit einem nachhaltigen Gesamtansatz.

Zuerst Begriffe klären: Wo die Impression im Funnel steht

EngageLab erfasst jeden Push nach den folgenden Stufen. Die Definition der einzelnen Stufen finden Sie in Push-Statistik und in der Statistik-API:

flowchart LR
    plan["Geplante Ziele"]
    targets["Gültige Ziele<br/>in den letzten 365 Tagen aktive Geräte"]
    sent["Gesendet<br/>Sendeauftrag vom Server erstellt"]
    delivered["Zugestellt<br/>tatsächlich an den Web-Client zugestellt"]
    impressions["Impressionen<br/>auf dem Gerät erfolgreich angezeigt"]
    clicks["Klicks"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

Drei Punkte zur „Impression“ müssen vorab geklärt sein, sonst wird ein Problem der statistischen Definition leicht mit einem Push-Problem verwechselt:

1. Impressionen werden vom SDK gemeldet. In der Callback-API ist der Status Impression definiert als „Web-Push-Benachrichtigungen und In-App-Nachrichten, deren erfolgreiche Anzeige vom SDK gemeldet wurde“; siehe Callback-API. Anzeigen, die nicht über das SDK gemeldet werden, zählen nicht als Impression.
2. Benutzerdefinierte Nachrichten zählen standardmäßig nicht als Impression. Die message (benutzerdefinierte Nachricht) der Push-Erstellungs-API wird nicht im Browser angezeigt, sondern an Ihre Webseite durchgereicht. Um Impressionen zu zählen, müssen Sie auf Ihrer Seite customDisplayReport aufrufen; siehe Web SDK API.
3. Das Statistikfenster beträgt 5 Tage. Zustellungen und Impressionen, die mehr als 5 Tage nach dem erfolgreichen Versand erfolgen, werden nicht mehr gezählt und lösen keine Callbacks mehr aus.

Unterscheiden Sie bei der Analyse geringer Impressionen daher zuerst zwischen „niedriger Impressionsrate“ (zugestellt, aber nicht angezeigt) und „niedriger Impressionszahl bei normaler Impressionsrate“ (das Problem liegt weiter oben bei Abonnement, Versand oder Zustellung). Ursachen und Lösungen dieser beiden Fälle unterscheiden sich grundlegend.

Teil 1: So finden Sie die Ursache geringer Impressionen

Arbeiten Sie den Funnel von oben nach unten durch und prüfen Sie auf jeder Schicht zunächst die Daten, bevor Sie die Ursache eingrenzen.

1.1 Ist der Abonnentenpool groß genug?

Die Obergrenze der Impressionen wird durch die Größe Ihrer Abonnentenbasis bestimmt. Bei wenigen Abonnenten führen auch hervorragende Zustell- und Impressionsraten nicht zu nennenswerten Impressionszahlen.

Wo nachsehen:

• Nutzerübersicht: Vergleichen Sie „abonnierte Nutzer“ mit „aktiven Nutzern“. Abonnierte Nutzer sind die Anzahl eindeutiger Nutzergeräte, die abonniert und dem Empfang von Benachrichtigungen zugestimmt haben. Liegen sie deutlich unter den aktiven Nutzern, haben viele Besucher die Berechtigung nicht abgeschlossen.
• Übersicht: Prüfen Sie die Aktivierungsrate der Benachrichtigungsberechtigung auf den Geräten sowie die Anzahl der Nutzer, die Benachrichtigungen deaktiviert haben.
• Datenabfrage: Prüfen Sie stichprobenartig den Online-Status und die letzte Online-Zeit konkreter Registration IDs, um zu bestätigen, dass das Abonnement noch gültig ist.

Häufige Ursachen (siehe FAQ und Grundeinstellungen):

• Der Modus „direkte Anfrage“ zeigt die native Berechtigungsabfrage des Browsers. Klickt der Nutzer einmal auf Block / Don't Allow, kann die Berechtigung nicht erneut angefragt werden, sofern der Nutzer die Browsereinstellungen nicht selbst ändert.
• Die Website nutzt kein HTTPS oder die Domain ist nicht in der Konsole konfiguriert, sodass weder die native Abfrage erscheinen noch ein Abonnement erfolgen kann.
• Der Service Worker liegt nicht im Stammverzeichnis der Website oder sein Scope kollidiert mit einem vorhandenen PWA-Service-Worker, sodass das Abonnement fehlschlägt.
• iOS-Nutzer haben die Website nicht zum Home-Bildschirm hinzugefügt oder die Berechtigungsanfrage wird nicht durch eine Nutzergeste ausgelöst.
• Nutzer verwenden den Inkognito-, privaten oder Gastmodus, die Web Push nicht unterstützen.
• Abonniert derselbe user_str auf mehreren Browsern oder Geräten, ersetzt das neue Abonnement das alte, und nur das zuletzt abonnierte Gerät empfängt Nachrichten.

1.2 Gibt es hohe Verluste zwischen gültigen Zielen und Gesendet?

Wo nachsehen:

• Push-Verlauf: Vergleichen Sie gültige Ziele und Gesendet eines einzelnen Pushs und prüfen Sie die Fehlerursachen in den Nachrichtendetails.
• Die Lebenszyklusabfrage der Statistik-API: Die Status target_invalid und sent_failed lokalisieren die Verluststufe einzelner Geräte.

Häufige Ursachen:

• Gültige Ziele sind als „in den letzten 365 Tagen aktiv“ definiert; lange inaktive Abonnements werden nicht zu gültigen Zielen.
• In den Erweiterten Einstellungen sind Push-Obergrenzen pro Gerät pro Stunde / Tag / Woche oder ein zulässiges Push-Zeitfenster konfiguriert; Nachrichten über dem Limit oder außerhalb des Zeitfensters werden direkt verworfen.

1.3 Gibt es hohe Verluste zwischen Gesendet und Zugestellt?

Diese Schicht wird am häufigsten mit „wenigen Impressionen“ verwechselt. Ist die Zustellzahl niedrig, sind auch die Impressionen niedrig – die Impressionsrate kann dabei jedoch völlig normal sein.

Wo nachsehen:

• Die Zustellrate eines einzelnen Pushs im Push-Verlauf; die nach Browser (Chrome, Safari, Firefox, Edge, EngageLab-Kanal usw.) aufgeschlüsselten Zustelldaten in der Push-Statistik.
• Das von der Statistik-API zurückgegebene Feld sub zeigt Zustellungen und Impressionen getrennt für notification und message; die Felder engageLab_web, chrome, safari, firefox und edge ermöglichen die Aufschlüsselung nach Kanal.

Häufige Ursachen (siehe Push-Erstellungs-API und FAQ):

• time_to_live ist auf 0 gesetzt: Offline-Nachrichten werden nicht aufbewahrt, nur aktuell online befindliche Nutzer empfangen sie. Standard sind 86400 Sekunden (1 Tag), maximal 15 Tage.
• Kanalunterschiede: Der EngageLab-Kanal erfordert, dass der Nutzer Ihre Website geöffnet hat; Systemkanäle (Chrome, Edge, Firefox usw.) stellen zu, solange der Browserprozess im Betriebssystem existiert, jedoch nicht mehr, wenn der Browser vollständig beendet wurde; der Safari-Systemkanal setzt keinen laufenden Browser voraus.
• Der Nutzer hat Browser-Cookies / Cache gelöscht, wodurch das Abonnement des Anbieterkanals verloren ging. Steht die Benachrichtigungsberechtigung weiterhin auf „Zulassen“, abonniert das SDK beim nächsten Besuch automatisch neu und vergibt eine neue Registration ID; wurde die Berechtigung auf „Fragen“ oder „Blockieren“ geändert, erfolgt kein automatisches Neuabonnement.
• Die Strategie third_party_channel.w3push.distribution passt nicht zum Nutzerverhalten, z. B. wenn mtpush (nur EngageLab-Kanal) erzwungen wird, obwohl Nutzer sich kaum auf der Website aufhalten.
• Der Kanal des Browseranbieters ist instabil; die FAQ empfiehlt in diesem Fall den Wechsel zur bevorzugten Zustellung über den EngageLab-Kanal.

1.4 Gibt es Verluste zwischen Zugestellt und Impressionen (niedrige Impressionsrate)?

Erst wenn die Zustellzahl normal, die Impressionen aber deutlich zu niedrig sind, liegt ein echtes „Impressionsraten“-Problem vor.

Wo nachsehen:

• „Zugestellt / Impressionen“ und das Verhältnis pro Plattform in den Details des Push-Verlaufs.
• Die Ereignisse Impression und impression_failed der Callback-API.

Häufige Ursachen:

1.5 Prüfliste

Gehen Sie die Punkte in der angegebenen Reihenfolge durch und schließen Sie Definitions- und Upstream-Probleme aus, bevor Sie die Impressionen selbst betrachten:

Teil 2: Gezielte Optimierung nach Ursachenfindung

2.1 Abonnentenpool vergrößern

• Auf geführte Anfrage (Soft-Prompt) umstellen. Wählen Sie in den Grundeinstellungen unter Benachrichtigungsberechtigung „geführte Anfrage“: Erläutern Sie zunächst mit einem eigenen Hinweis den Nutzen der Benachrichtigungen und lösen Sie die native Abfrage erst aus, wenn der Nutzer Interesse zeigt. So verhindern Sie, dass Nutzer ohne Verständnis des Nutzens auf Block klicken und die Berechtigung dauerhaft nicht mehr angefragt werden kann. Der Soft-Prompt unterstützt ein Anfangsintervall (Standard 3 Tage) und ein Folgeintervall (Standard 7 Tage), bis der Nutzer abonniert.
• Voraussetzungen vollständig erfüllen. Nutzen Sie HTTPS und konfigurieren Sie Ihre Domains unter [Integrationseinstellungen] - [Website-Domain] (bis zu 100). Legen Sie die Service-Worker-Datei für maximalen Scope im Stammverzeichnis ab. Besitzt die Website bereits einen PWA-Service-Worker, führen Sie beide zusammen oder stellen Sie sicher, dass sich die Scopes nicht überschneiden; siehe Web SDK-Integrationsanleitung und FAQ.
• iOS-Nutzer anleiten. Safari unter iOS / iPadOS 16.4 und höher erfordert, dass der Nutzer die Website zum Home-Bildschirm hinzufügt und von dort öffnet; anschließend muss die Berechtigung durch eine Nutzergeste (z. B. Tippen auf einen Abonnieren-Button) ausgelöst werden. Ein Hinweisbanner auf der Seite wird empfohlen.
• Gegenseitiges Verdrängen von Geräten vermeiden. Wenn Sie Nutzer über user_str identifizieren, beachten Sie, dass bei Abonnement desselben user_str auf mehreren Browsern / Geräten nur das zuletzt abonnierte Gerät Nachrichten empfängt. Um alle Geräte eines Nutzers abzudecken, verwenden Sie denselben user_str nicht auf verschiedenen Geräten.
• Abonnements bei der Migration nicht verlieren. Behandeln Sie bei der Migration von einem anderen Anbieter zu EngageLab den alten Service Worker gemäß So vermeiden Sie Abonnentenverluste bei der Web-Push-Migration; Nutzer, die die Berechtigung bereits erteilt haben, erhalten nach der Initialisierung keine erneute Abfrage.

2.2 Verluste zwischen gültigen Zielen und Gesendet reduzieren

• Konfigurieren Sie in den Erweiterten Einstellungen Push-Obergrenzen pro Gerät und das zulässige Zeitfenster entsprechend Ihren geschäftlichen Anforderungen. Frequenzkontrolle schützt das Nutzererlebnis, zu strenge Einstellungen verwerfen Nachrichten jedoch direkt; bewerten Sie sie zusammen mit Ihrem Push-Plan.
• Bereinigen Sie regelmäßig über die Nutzer-Lösch-API nachweislich inaktive Abonnements, damit die gültigen Ziele die erreichbaren Nutzer genauer abbilden und die Statistik nicht durch ungültige Abonnements verwässert wird. Das Löschen ist unwiderruflich; gehen Sie sorgfältig vor.

2.3 Zustellung verbessern

• time_to_live sinnvoll setzen. Verwenden Sie nicht 0; behalten Sie den Standard von 1 Tag bei oder verlängern Sie ihn je nach Aktualität des Inhalts auf bis zu 15 Tage. Bei nicht zeitkritischen Inhalten ermöglicht eine längere Offline-Aufbewahrung, dass offline befindliche Nutzer die Nachricht nach dem erneuten Öffnen des Browsers noch erhalten.

• Passende Verteilungsstrategie wählen. In third_party_channel.w3push.distribution:

  • first_ospush (Standard): zuerst Systemkanal, bei Nichtverfügbarkeit EngageLab-Kanal;
  • secondary_push: zuerst EngageLab-Kanal, bei Offline-Nutzern Systemkanal; die Push-Erstellungs-API empfiehlt diese Option;
  • mtpush: erzwingt den EngageLab-Kanal; nur geeignet, wenn Nutzer lange auf der Website verweilen;
  • ospush: erzwingt ausschließlich den Systemkanal.

  Bei instabilem Kanal des Browseranbieters können Sie vorübergehend auf EngageLab-Kanal-Priorität umstellen.

• override_msg_id mit Bedacht einsetzen. Das Überschreiben einer noch nicht geschlossenen vorherigen Benachrichtigung führt dazu, dass der Nutzer nur die neueste sieht. Das eignet sich für Inhaltsaktualisierungen, nicht für Szenarien, in denen mehrere Benachrichtigungen sichtbar bleiben sollen.

• Bei Kampagnen oder großen Volumen ratenbegrenzt senden. Verteilen Sie den Push mit big_push_duration gleichmäßig über die angegebene Minutenzahl (maximal 1440) und vermeiden Sie so Lastspitzen.

2.4 Impressionen verbessern

• Benachrichtigungen bevorzugen. Verwenden Sie für Inhalte, die im Benachrichtigungsbereich angezeigt und als Impression gezählt werden sollen, notification statt message. Sind benutzerdefinierte Nachrichten geschäftlich zwingend erforderlich, rufen Sie nach der Anzeige auf der Seite customDisplayReport('msg_id') und beim Klick customClickReport('msg_id') auf.
• Nicht mehrere Benachrichtigungen kurz hintereinander an denselben Nutzer senden. In Chrome, Edge und Firefox ersetzt die spätere Benachrichtigung die frühere; der Nutzer sieht nur die letzte, und nur eine Impression wird gezählt. Fassen Sie mehrere Inhalte in einer Benachrichtigung zusammen oder ziehen Sie die Sendungen zeitlich auseinander.
• Browserkompatibilität von Bildmaterial und Texten beachten. icon sollte 192×192 und höchstens 1 MB groß sein; eigene Icons werden nur von Chrome und Firefox unterstützt, Safari und Edge verwenden das Systemstandard-Icon. image sollte 360×180 und höchstens 1 MB groß sein; es wird nur von Chrome und Edge unterstützt, nicht von Firefox oder Safari. Systemkanäle begrenzen die Titellänge (weniger als 20 chinesische bzw. 40 englische Zeichen); zu lange Titel können die Darstellung beeinträchtigen.
• Für In-App-Nachrichten eine angemessene Anzeigegültigkeit festlegen. Nach Ablauf der Gültigkeit wird die Nachricht beim erneuten Seitenaufruf nicht angezeigt und impression_failed ausgelöst. Verlängern Sie die Gültigkeit für nicht zeitkritische Inhalte und begrenzen Sie die Bildgröße, um Downloadfehler zu vermeiden.
• In den aktiven Zeiten der Nutzer senden. Nutzen Sie die intelligente Zustellung der Geplanten Aufgaben oder die Aktivzeit-Abgleichsdaten der Push-Statistik, um dann zu senden, wenn Nutzer den Browser wahrscheinlich geöffnet haben, und so Offline-Verfall zu reduzieren.
• Safari-Daten richtig interpretieren. Der Safari-Systemkanal liefert keine Impressions- oder Klick-Callbacks; niedrige Impressionen in diesem Kanal sind eine statistische Einschränkung und bedeuten nicht, dass Benachrichtigungen nicht angezeigt wurden. Bewerten Sie Safari bei der Beurteilung der Impressionsrate getrennt von den übrigen Kanälen.

Teil 3: Gesamtansatz zur systematischen Steigerung der Impressionen

Punktuelle Korrekturen lösen jeweils nur eine Schicht. Um die Impressionen dauerhaft zu steigern, betreiben Sie „Abonnentenwachstum, Zustellsicherung und Impressions-Monitoring“ als laufende Routine.

3.1 Kanalbezogene Monitoring-Sicht aufbauen

• Prüfen Sie täglich in der Übersicht den Push-Conversion-Funnel, die Trends von Zustell- / Impressions- / Klickrate sowie die Anzahl der Nutzer mit aktivierten / deaktivierten Benachrichtigungen.
• Schlüsseln Sie Zustellungen und Impressionen in der Push-Statistik nach Browser auf, mit Fokus auf Chrome und den EngageLab-Kanal; bewerten Sie Safari separat.
• Empfangen Sie über die Callback-API Ereignisse wie delivered, Impression, impression_failed und click und speichern Sie sie, um feinere Analysen pro Nutzer und pro Nachricht als in der Konsole durchzuführen (Statistiken pro Nachricht werden auf EngageLab-Seite höchstens einen Monat aufbewahrt).
• Legen Sie getrennte Basiswerte für Zustell- und Impressionsrate fest: Bei auffälligem Rückgang der Zustellrate prüfen Sie zuerst time_to_live, Verteilungsstrategie und Anbieterkanäle; bei auffälligem Rückgang der Impressionsrate zuerst Nachrichtentyp, Überschreiben durch mehrere Benachrichtigungen und Berechtigungen auf Nutzerseite.

3.2 Maßnahmenliste nach Phasen

Integrationsphase (rund um den Launch)

• HTTPS verwenden, Domains konfigurieren, Service Worker im Stammverzeichnis ablegen und Scope-Konflikte ausschließen;
• Für die Benachrichtigungsberechtigung „geführte Anfrage“ wählen und Text sowie Intervalle des Soft-Prompts konfigurieren;
• Anleitung „Zum Home-Bildschirm hinzufügen“ für iOS-Nutzer vorbereiten;
• Benachrichtigungen (notification) statt benutzerdefinierter Nachrichten (message) als primären Kanal nutzen;
• Beim Integrationstest über Push-Verlauf und Datenabfrage bestätigen, dass Online-Status, Zustellung und Impressionen der Zielgeräte korrekt gezählt werden.

Wachstumsphase (Tagesbetrieb)

• Wöchentlich das Wachstum abonnierter und aktiver Nutzer vergleichen; bei schwacher Abonnement-Conversion Text und Auslösezeitpunkt des Soft-Prompts anpassen;
• time_to_live bei mindestens 1 Tag halten und für distribution secondary_push oder die Standardstrategie verwenden;
• Push-Frequenz pro Nutzer steuern, um Impressionsverluste durch Überschreiben zu vermeiden, und gleichzeitig Frequenzkontrolle zum Schutz des Nutzererlebnisses konfigurieren;
• Sendezeitpunkte mithilfe der intelligenten Zustellung oder der Aktivzeit-Abgleichsdaten wählen;
• Lange inaktive Abonnements regelmäßig bereinigen.

Kampagnenphase (Spitzenlast)

• Lastspitzen mit ratenbegrenztem Versand glätten;
• time_to_live für zeitkritische Inhalte verkürzen und die Offline-Aufbewahrung für später zustellbare Inhalte verlängern;
• Mehrere Marketing-Benachrichtigungen zu einer zusammenfassen oder nach Nutzersegmenten zeitversetzt in Batches senden;
• Nach dem Push Zustell- und Impressionsrate je Kanal auswerten und Erkenntnisse aus auffälligen Kanälen in die nächste Push-Konfiguration einfließen lassen.

3.3 In einem Satz

Impressionen = abonnierte Nutzer × Anteil gültiger Ziele × Zustellrate × Impressionsrate. Bestimmen Sie anhand der Funnel-Daten, auf welcher Schicht der Verlust entsteht, und optimieren Sie diese Schicht. Für die Schicht „Impression“ selbst gilt: Benachrichtigungen verwenden und SDK-Meldung sicherstellen, Überschreiben durch mehrere Benachrichtigungen vermeiden und Daten kanalweise interpretieren.

Referenzdokumente

• Web SDK-Integrationsanleitung
• Web SDK API
• Grundeinstellungen
• Erweiterte Einstellungen
• Push-Erstellungs-API
• Callback-API
• Statistik-API
• Push-Statistik
• Push-Verlauf
• FAQ
• So vermeiden Sie Abonnentenverluste bei der Web-Push-Migration