Silent Push-Benachrichtigungen: DSGVO-konform, Funktionsweise und Einsatz auf iOS und Android

Die meisten Leitfäden zu Push-Benachrichtigungen behandeln Nachrichten, die Nutzer sehen. Silent Push-Benachrichtigungen sind genau das Gegenteil — sie bleiben unsichtbar und erfüllen eine völlig andere Aufgabe.

Eine Silent Push weckt Ihre App im Hintergrund, führt eine Aufgabe aus und versetzt sie zurück in den Ruhezustand. Keine Meldung, kein Ton, kein Badge. Der Nutzer öffnet die App und findet bereits geladene, aktuelle Inhalte vor — ohne zu bemerken, dass eine Push stattgefunden hat. Genau das ist der Sinn.

Weil Silent Push-Benachrichtigungen Daten im Hintergrund verarbeiten — Standortdaten, Verhaltenssignale, Kaufereignisse —, ist die Frage der Datenverarbeitung im deutschen Markt keine Nebensache, sondern der Ausgangspunkt. Dieser Leitfaden behandelt zuerst die datenschutzkonforme Verarbeitung dieser Hintergrunddaten, dann die Funktionsweise auf iOS und Android sowie die Implementierung im Code. Unterwegs sehen Sie, wie Pushwoosh die plattformübergreifende Zustellung von Silent Push mit EU-Datenresidenz abwickelt und in automatisierte Workflows integriert.

Datenschutz zuerst: Hintergrunddaten DSGVO-konform verarbeiten

Bevor wir zu Funktionen und Code kommen, der für den deutschen Markt entscheidende Punkt: Eine Silent Push löst eine Datenverarbeitung aus, die der Nutzer nicht sieht. Standortprüfungen, Segment-Updates und das Synchronisieren von Kaufereignissen finden im Hintergrund statt. Nach DSGVO muss diese Verarbeitung auf einer Rechtsgrundlage beruhen, zweckgebunden und transparent dokumentiert sein.

Drei Anforderungen ergeben sich daraus konkret:

• Einwilligung und Rechtsgrundlage. Auch eine unsichtbare Push benötigt eine Rechtsgrundlage. Für Standortauswertungen ist in der Regel eine ausdrückliche Einwilligung erforderlich; für die Synchronisation transaktionaler Daten kann ein berechtigtes Interesse greifen. Die Verarbeitung darf nie über den eingewilligten Zweck hinausgehen.
• Datenminimierung. Eine Silent Push sollte ein Signal sein, kein Datentransfer. Übertragen Sie nur, was die App benötigt, um die richtige Aufgabe anzustoßen — keine personenbezogenen Daten im Payload selbst.
• Datenresidenz. Wo werden die im Hintergrund synchronisierten Daten gespeichert? Pushwoosh betreibt Rechenzentren in der EU und den USA und ist SOC 2 Type I sowie ISO 27001:2022 zertifiziert und DSGVO-konform. Sie behalten die Kontrolle über den Rechtsrahmen, in dem Kundendaten verarbeitet werden.

Mit diesem Rahmen im Hinterkopf betrachten wir nun, was eine Silent Push technisch ist und welche Aufgaben sie übernimmt.

Was sind Silent Push-Benachrichtigungen?

Silent Push-Benachrichtigungen sind serverseitig ausgelöste Nachrichten, die eine App im Hintergrund wecken, ohne dem Nutzer etwas anzuzeigen. Keine Meldung, kein Ton, kein Badge. Das Betriebssystem empfängt die Push, aktiviert die App kurz, die App führt ihre Hintergrundaufgabe aus und kehrt dann in den Ruhezustand zurück.

Der Unterschied zur klassischen Push ist klar: Eine sichtbare Push ist eine Nachricht an den Nutzer; eine Silent Push ist eine Anweisung an die App.

Was kann eine App in diesen Sekunden im Hintergrund tun?

• Neue Inhalte abrufen. Die neuesten Artikel, einen aktualisierten Produktkatalog oder einen aufgefrischten Feed laden, damit alles bereitsteht, wenn der Nutzer die App öffnet.
• Daten synchronisieren. Den lokalen Zustand mit Änderungen abgleichen, die auf dem Server oder über andere Kanäle erfolgt sind — ein Kauf auf der Website, eine Statusänderung im Backend.
• Standort auswerten. Prüfen, ob der Nutzer eine Geofence betreten oder verlassen hat, ohne dass eine sichtbare Benachrichtigung als Auslöser nötig ist.
• Nutzer-Tags oder Segmentdaten aktualisieren. Die aktuellen Verhaltenssignale an die CDP zurückspielen, damit das Targeting präzise bleibt.
• Inhalte für eine bevorstehende sichtbare Benachrichtigung vorladen. Eine In-App-Nachricht oder einen Rich-Push-Payload vorbereiten, damit dieser bei Auslösung sofort gerendert wird.

Der praktische Nutzen: Nutzer öffnen eine App, die bereits auf dem neuesten Stand ist. Kein Ladebalken, keine veralteten Daten. Dieser Eindruck von Geschwindigkeit und Aktualität wirkt messbar auf die Retention — selbst wenn Nutzer nicht benennen können, warum sich die App gut anfühlt.

Wie Silent Push-Benachrichtigungen funktionieren

Die Zustellkette entspricht der einer regulären Push-Benachrichtigung: Ihr Server sendet einen Payload an APNs (iOS) oder FCM (Android), der Dienst stellt ihn an das Gerät zu, das Betriebssystem reagiert darauf. Anders ist die Struktur des Payloads und das, was das Betriebssystem bei dessen Eintreffen tut.

Der Zustellablauf

1. Server sendet Payload. Ihr Backend oder Pushwoosh sendet eine speziell aufgebaute Nachricht an APNs oder FCM.
2. Dienst stellt an das Gerät zu. APNs oder FCM leitet den Payload anhand des gespeicherten Device-Tokens an das richtige Gerät weiter.
3. Betriebssystem weckt die App. Erkennt das Betriebssystem die Silent-Push-Flags im Payload, aktiviert es die App kurz im Hintergrund.
4. App führt die Hintergrundaufgabe aus. Ihr Code läuft: Daten abrufen, Zustand synchronisieren, Standort prüfen, ein Tag aktualisieren.
5. App signalisiert Abschluss. Auf iOS ruft die App einen completionHandler auf. Auf Android kehrt onMessageReceived() zurück. Das Betriebssystem versetzt die App zurück in den Ruhezustand.

Das Zeitfenster im Hintergrund ist begrenzt. iOS gewährt etwa 30 Sekunden. Bei Android variiert es je nach Gerät und Energiezustand. Hintergrundaufgaben müssen schnell sein oder so gestaltet werden, dass sie innerhalb dieser Grenzen funktionieren.

Payload-Unterschiede: iOS vs. Android

Der häufigste Fehler auf iOS ist, apns-priority: 5 neben apns-push-type: background zu vergessen. Ist die Priorität auf 10 gesetzt (der Standard für sichtbare Pushes), kann Apple die Nachricht ablehnen oder sie visuell anzeigen, selbst ohne Alert-Body. Die niedrige Priorität signalisiert APNs, dass es sich um eine Hintergrundaufgabe handelt und nicht um eine dringende Benachrichtigung.

Auf Android ist die entscheidende Regel einfacher: kein notification-Objekt im FCM-Payload. Ist ein notification-Objekt vorhanden, behandelt Android die Nachricht als reguläre Push-Benachrichtigung und zeigt sie an. Silent Push = ausschließlich Daten.

iOS-Implementierung

Xcode-Konfiguration

Aktivieren Sie Background Modes in Xcode, bevor Sie Code schreiben:

1. Öffnen Sie Ihr Projekt und wählen Sie Ihr App-Target aus.
2. Gehen Sie zu ‘Signing & Capabilities’ und klicken Sie auf ’+ Capability’.
3. Fügen Sie ‘Background Modes’ hinzu und aktivieren Sie ‘Remote Notifications’.

Ihre App ID im Apple Developer Portal muss Push Notifications aktiviert haben. Generieren Sie Ihre Provisioning Profiles nach dieser Änderung neu.

Für Remote-Benachrichtigungen registrieren

Silent Pushes erfordern weiterhin die Geräteregistrierung bei APNs. Behandeln Sie das im AppDelegate:

import UIKit
import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions:
            [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        UNUserNotificationCenter.current().delegate = self
        UNUserNotificationCenter.current().requestAuthorization(
            options: [.badge, .sound, .alert]
        ) { granted, _ in
            if granted {
                DispatchQueue.main.async {
                    application.registerForRemoteNotifications()
                }
            }
        }
        return true
    }

    func application(_ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        let token = deviceToken.map {
            String(format: "%02.2hhx", $0) }.joined()
        // Das Pushwoosh iOS SDK übernimmt die Token-Übermittlung automatisch
    }
}

Die Silent Push verarbeiten

Dies ist die Methode, die iOS aufruft, wenn eine Silent Push eintrifft:

extension AppDelegate {

    func application(_ application: UIApplication,
        didReceiveRemoteNotification userInfo: [AnyHashable: Any],
        fetchCompletionHandler completionHandler:
            @escaping (UIBackgroundFetchResult) -> Void) {

        guard let aps = userInfo["aps"] as? [String: AnyObject],
              aps["content-available"] as? Int == 1 else {
            completionHandler(.noData)
            return
        }

        // Führen Sie hier Ihre Hintergrundaufgabe aus
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

Rufen Sie completionHandler immer auf, bevor das 30-Sekunden-Fenster schließt. Andernfalls kann iOS die App beenden und künftige Silent Pushes drosseln. Übergeben Sie .newData, wenn Sie etwas abgerufen haben, .noData, wenn sich nichts geändert hat, und .failed, wenn die Aufgabe fehlgeschlagen ist.

APNs-Payload für Silent Push

{
    "aps": {
        "content-available": 1
    },
    "update_type": "content_refresh",
    "content_id": "latest_feed"
}

Erforderliche APNs-Header neben diesem Payload:

• apns-push-type: background
• apns-priority: 5

Android-Implementierung

FCM-Setup und Manifest

Fügen Sie den FirebaseMessagingService zu Ihrer AndroidManifest.xml hinzu:

<service
    android:name=".MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

Data-Nachrichten in Kotlin verarbeiten

Erweitern Sie FirebaseMessagingService und implementieren Sie onMessageReceived:

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Das Pushwoosh Android SDK übernimmt die Token-Übermittlung automatisch
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // Silent Push = nur data-Payload, kein notification-Objekt
        if (remoteMessage.data.isNotEmpty()
            && remoteMessage.notification == null) {
            handleSilentPush(remoteMessage.data)
        }
    }

    private fun handleSilentPush(data: Map<String, String>) {
        when (data["update_type"]) {
            "content_refresh" -> {
                // Neue Inhalte von Ihrem Server abrufen
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // Aktualisierte Tags an Pushwoosh senden
                syncUserSegmentData()
            }
            "location_check" -> {
                // Aktuellen Geofence-Status auswerten
                evaluateGeofences()
            }
        }
    }
}

FCM-Payload für Silent Push

Der Payload muss ein data-Objekt und kein notification-Objekt enthalten:

{
    "to": "DEVICE_TOKEN",
    "data": {
        "update_type": "content_refresh",
        "content_id": "latest_news_feed"
    }
}

Setzen Sie die Priorität nur für zeitkritische Hintergrundaufgaben auf ‘high’. Für die meisten Content-Refresh-Anwendungen genügt die Standardpriorität und vermeidet unnötige Akkubelastung.

Plattformübergreifende Silent Push mit Pushwoosh

Silent Push manuell über iOS und Android hinweg zu verwalten, bedeutet zwei separate Payload-Formate, zwei Sätze von Zustellungs-Headern und zwei SDK-Integrationen zu pflegen. Pushwoosh abstrahiert das.

Wenn Sie eine Silent Push über Pushwoosh auslösen — per UI oder API —, generiert die Plattform automatisch den korrekten Payload für jede Zielplattform. APNs erhält content-available: 1 mit den richtigen Headern. FCM erhält eine reine Data-Nachricht. Sie konfigurieren die Kampagne nur einmal.

Die Verwaltung der Device-Tokens ist zentralisiert. iOS-Tokens, Android-Tokens und Web-Push-Abonnements werden an einem Ort gespeichert und aktualisiert. Ändert sich ein Token (Neuinstallation, OS-Upgrade), übernimmt Pushwoosh die Aktualisierung. Für deutsche IT-Verantwortliche relevant: Diese Token-Daten und die ausgelösten Verarbeitungsvorgänge laufen innerhalb der von Ihnen gewählten Datenresidenz — mit EU-Rechenzentrum als Option und einem Datenverarbeitungsvertrag (AVV) als Grundlage.

Für nicht-technische Teammitglieder bietet Pushwoosh eine UI zum Planen und Auslösen von Silent Pushes, ohne einen Payload schreiben zu müssen. Damit lassen sich Silent Pushes praktisch in Customer Journey Builder-Workflows neben sichtbaren Benachrichtigungen und In-App-Nachrichten integrieren.

Strategische Anwendungsfälle

Silent Push-Benachrichtigungen sind am wertvollsten, wenn Sichtbarkeit tatsächlich gegen Sie arbeiten würde. Hier sind die Szenarien, in denen sie besser passen als eine klassische Push.

Content-Vorabruf für Nachrichten- und Medien-Apps

Eine Nachrichten-App, die einen Eilmeldungs-Alert versendet, profitiert von einer 30 Sekunden zuvor gesendeten Silent Push. Diese weckt die App, die den Artikel abruft und lokal zwischenspeichert. Wenn der sichtbare Alert erscheint, öffnet ein Tippen den Artikel sofort. Kein Warten, bis die Meldung lädt.

Bei Apps mit personalisierten Feeds ruft eine Silent Push zu typischen Aufwachzeiten die Morgeninhalte vorab ab, bevor der Nutzer die App öffnet. Die App fühlt sich schnell an, weil sie es ist — die Daten sind bereits da.

Geofence-Auswertung ohne sichtbaren Auslöser

Ein Nutzer geht an einem Geschäft vorbei. Der Standardansatz: eine standortbasierte Push-Benachrichtigung senden. Das Problem: Der Nutzer muss eingewilligt haben, das Timing passt womöglich nicht, und er kann sich überwacht fühlen — im deutschen Markt ein besonders sensibler Punkt.

Der Silent-Push-Ansatz: Der Server sendet eine Silent Push, wenn sich der Nutzer in einer Region befindet. Die App prüft die präzise Geofence clientseitig. Bei einem Treffer aktiviert die App eine In-App-Nachricht oder eine lokale Benachrichtigung im richtigen Moment. Die sichtbare Kommunikation erfolgt nur, wenn die Logik greift — nicht als Auslöser selbst. Aus Datenschutzsicht hat das einen Vorteil: Die Standortauswertung bleibt auf dem Gerät, statt präzise Koordinaten an den Server zu übertragen.

Segmentdaten nach App-externer Aktivität korrekt halten

Ein Nutzer tätigt einen Kauf auf Ihrer Website. Sein RFM-Segment sollte sofort aktualisiert werden. Doch die App weiß davon nichts, bis der Nutzer sie öffnet.

Eine nach dem Web-Kauf gesendete Silent Push weckt die App im Hintergrund, die das aktuelle Kaufereignis mit Pushwoosh synchronisiert. Der Nutzer wechselt in Echtzeit ins korrekte RFM-Segment. Eine Folgekampagne — Treueprämie, Cross-Sell, Dankessequenz — löst auf Basis korrekter Daten aus.

Inhalte für In-App-Nachrichten vorladen

In-App-Nachrichten, die zum Rendern einen Server-Abruf benötigen, können spürbar verzögert erscheinen. Eine Silent Push, die vor dem erwarteten Auslösen der In-App-Nachricht gesendet wird, lädt den Inhalt vorab und speichert ihn lokal. Wenn die Nachricht erscheint, wird sie sofort angezeigt.

Dieses Muster eignet sich für Onboarding-Flows, Feature-Ankündigungen und Promotion-Overlays, bei denen der Inhalt personalisiert ist und nicht fest in das App-Binary codiert werden kann.

Best Practices

OS-Throttling-Grenzen respektieren

iOS drosselt Silent Pushes, die zu häufig eintreffen. Apples Richtwert liegt bei etwa 2–3 pro Stunde, also höchstens etwa alle 21 Minuten eine. Apps, die das überschreiten, erleben womöglich verzögerte oder verworfene Silent Pushes — ohne jede Fehlermeldung.

Androids Doze-Modus und App Standby beschränken die Hintergrundausführung, wenn das Gerät im Leerlauf ist. FCM-Nachrichten mit hoher Priorität können die App während Doze wecken, sollten aber gezielt eingesetzt werden. Nachrichten mit Standardpriorität werden zurückgestellt, bis das Gerät Doze verlässt.

Die praktische Regel: Senden Sie Silent Pushes nur, wenn die Hintergrundaufgabe wirklich zeitkritisch ist. Inhalte einmal in natürlichem Rhythmus vorabzurufen (morgens oder nach einem serverseitigen Update) ist in Ordnung. Alle 10 Minuten zu senden, um Daten frisch zu halten, ist es nicht.

Payloads klein und Aufgaben schnell halten

Der Silent-Push-Payload sollte ein Signal sein, kein Datentransfer. Senden Sie das Minimum, das die App benötigt, um zu erfahren, was wo abzurufen ist. Der eigentliche Datenabruf erfolgt in der App, nachdem die Push eingetroffen ist. Das ist zugleich Datenminimierung im Sinne der DSGVO: keine personenbezogenen Daten im Payload.

Hintergrundaufgaben sollten deutlich innerhalb des Zeitlimits abschließen. Benötigt eine Aufgabe mehr als ein paar Sekunden, gestalten Sie sie unterbrechbar: Fortschritt speichern, completionHandler aufrufen und bei nächster Gelegenheit fortsetzen. Lange Hintergrundaufgaben riskieren eine Beendigung durch das Betriebssystem und können den Akku so belasten, dass Nutzer es bemerken.

Über Energiezustände und OEM-Varianten hinweg testen

Das Verhalten von Silent Push variiert auf Android erheblich zwischen den OEMs. Xiaomi, Huawei und OnePlus haben aggressive Akkuoptimierungen, die die Hintergrundausführung für nicht freigegebene Apps vollständig verhindern können. Testen Sie auf echten Geräten dieser Hersteller, nicht nur auf Stock-Android-Emulatoren.

Testen Sie auf iOS im Energiesparmodus und bei beendeter App. Die Zustellung von Silent Push ist in diesen Zuständen weniger zuverlässig, und Ihre Hintergrundlogik sollte den Fall abdecken, dass die Aufgabe nicht ausgeführt wurde, bevor der Nutzer die App öffnet.

Wirksamkeit über nachgelagerte Events messen

Silent Pushes erzeugen keine Klick-Metriken. Messen Sie ihre Wirksamkeit über die Events, die sie auslösen sollen: content_refreshed, segment_updated, geofence_evaluated. Wenn diese Events nach einer Silent-Push-Kampagne nicht mehr in der erwarteten Rate auftreten, wird die Zustellung gedrosselt oder der Hintergrund-Handler schlägt fehl.

Pushwoosh Analytics stellt App-Events neben den Kampagnendaten dar. Ordnen Sie Ihre Events zum Abschluss von Hintergrundaufgaben den Silent-Push-Sendungen zu, um zu bestätigen, dass die Pipeline funktioniert.

In Journey-Automatisierung integrieren, nicht als Einzelversand

Eine isoliert gesendete Silent Push ist ein technischer Vorgang. Eine in eine Customer Journey eingebettete Silent Push ist ein strategischer. Die nützlichsten Muster setzen Silent Pushes als Schritt ein, der eine bessere nachgelagerte sichtbare Interaktion ermöglicht: das Segment vor der Promotion-Push aktualisieren, den Inhalt vor der In-App-Nachricht vorabrufen, die Geofence vor dem standortbasierten Alert auswerten.

Pushwooshs Customer Journey Builder unterstützt Silent Pushes als Journey-Schritte neben sichtbaren Benachrichtigungen und In-App-Nachrichten.

App-Aktualität und Kampagnenpräzision mit Pushwoosh verbessern

Silent Push-Benachrichtigungen sind die Infrastrukturschicht unter besseren Nutzererlebnissen. Aktuelle Inhalte beim Öffnen, korrekte Segmentdaten, nahtlose geofence-getriggerte Interaktionen — nichts davon funktioniert zuverlässig ohne Hintergrund-App-Updates. Und im deutschen Markt funktioniert nichts davon ohne eine datenschutzkonforme Grundlage.

Pushwoosh wickelt die plattformübergreifende Zustellung von Silent Push, die Payload-Formatierung, die Token-Verwaltung und die Customer-Journey-Integration ab — mit EU-Datenresidenz, SOC 2 Type I, ISO 27001:2022 und DSGVO-Konformität. Entwickler erhalten saubere SDK-Abstraktionen; Marketing-Teams erhalten Silent Push als vollwertigen Schritt in automatisierten Workflows.