SDK / Android / Apple / Web / KMP

Dokumentation

Wählen Sie Ihre Plattform, bereiten Sie die Zugangsdaten vor und verbinden Sie das SDK. Android nutzt Firebase Cloud Messaging. Apple nutzt APNs direkt — Firebase ist für iOS nicht erforderlich.

01 / Erste Schritte

Plattform auswählen

Eine PushPort-Anwendung kann Android, iOS und Web zusammenfassen. Die App-ID bezeichnet sie in PushPort; Android applicationId und Apple Bundle ID bezeichnen die nativen Apps. Für die Anmeldung im PushPort-Dashboard müssen Kunden keinen eigenen Google-OAuth-Client einrichten.

Plattform auswählen
PlattformPush-DienstAktueller Stand
AndroidFirebase Cloud Messaging (FCM)Maven Central · dev.pushport:android-sdk:0.0.5
iOS / iPadOSApple APNsSwift SDK 0.0.2 über SPM; APNs-Einstellungen je Umgebung im App-Konto.
WebWeb Push / VAPIDWeb SDK 0.0.2 als npm-Archiv auf GitHub. Website-Origin speichern und Web Push aktivieren.
KMPAndroid / APNs / Web PushMaven Central · dev.pushport:kmp-sdk:0.0.2
Nächster Schritt: App erstellen →

02 / Erste Schritte

App erstellen

Erstellen Sie eine Anwendung und wählen Sie die Plattformen. Speichern Sie den Android-Paketnamen, die Apple Bundle ID oder den genauen HTTPS-Origin der Website. Konfigurieren Sie Firebase, APNs oder Web Push in den Einstellungen und folgen Sie der jeweiligen SDK-Anleitung.

Kopieren Sie die App-ID aus den Einstellungen. Sie ist eine PushPort-Kennung, keine Firebase-Projekt-ID und kein Android-Paketname.

Voraussetzungen

  • Apple SDK 0.0.2 ist veröffentlicht. Laden Sie in den App-Einstellungen den APNs-.p8-Schlüssel mit Team ID, Key ID und der Umgebung Sandbox oder Production hoch. Der Server sendet direkt über APNs. Prüfen Sie ein echtes Gerät vor einer Kampagne.
  • Web Push verwendet den Push-Dienst des Browsers und VAPID-Schlüssel. Ein Firebase-Projekt ist nicht erforderlich. Anbieter-Routen für Chrome/Edge, Firefox und Safari sind vorbereitet.
Nächster Schritt: Team →

03 / Erste Schritte

Team

Geben Sie Mitarbeitern Zugriff auf die Anwendungen Ihres Teams.

Wählen Sie alle aktuellen und zukünftigen Team-Anwendungen oder einzelne Anwendungen mit jeweils eigenen Rechten.

Lesen: Zielgruppen und Berichte. Senden: auch Kampagnen und Segmente. Verwalten: auch Einstellungen und Löschen. Neue Anwendungen erfordern Verwaltungsrechte für das gesamte Team.

Nur der Inhaber verwaltet Mitglieder, Berechtigungen und API-Schlüssel.

Mitarbeiter einladen

Die Einladung wird automatisch per E-Mail gesendet. Sie können den Link auch kopieren. Zum Annehmen mit der eingeladenen Adresse anmelden oder registrieren. Einladungen gelten 7 Tage.

Team ↗

Nächster Schritt: Firebase für Android einrichten →

04 / Android / Firebase

Firebase für Android einrichten

Für diese PushPort-Integration benötigen Sie ein Firebase-Projekt und einen JSON-Dienstkontoschlüssel. Nur für PushPort müssen Sie weder Firebase-Abhängigkeiten noch eine Google-Konfigurationsdatei in Ihre Android-App aufnehmen.

  1. Projekt auswählen

    Erstellen oder wählen Sie in der Firebase Console das Projekt für den Android-Versand. Google Analytics kann deaktiviert bleiben. Firestore, Realtime Database und Firebase Authentication werden für den Versand nicht benötigt.

  2. Android-Paket prüfen

    Lesen Sie applicationId in build.gradle.kts des app-Moduls und tragen Sie den Wert als Android-Paket in PushPort ein. Eine separate Android-App-Registrierung in Firebase und SHA-Fingerabdrücke sind für diese Verbindung nicht erforderlich. Bestehende Firebase-Funktionen Ihrer App können bleiben.

  3. APIs aktivieren

    Wählen Sie dasselbe Projekt in Google Cloud → APIs & Services → Library. Aktivieren Sie Firebase Cloud Messaging API (HTTP v1) und Firebase Management API. Die erste dient dem Versand, die zweite dem Lesen der Absendernummer des Projekts.

  4. Privaten JSON-Schlüssel herunterladen

    Firebase → Project settings → Service accounts → Firebase Admin SDK → Generate new private key. Die JSON-Datei enthält type: service_account, project_id, client_email und private_key. Die Sprache des Firebase-Codebeispiels ändert den Schlüssel nicht.

  5. Schlüssel in PushPort hochladen

    Öffnen Sie die betreffende Anwendung → Einstellungen → Firebase. Wählen Sie die heruntergeladene JSON-Datei und laden Sie sie hoch. Prüfen Sie den Konfigurationsstatus. Der Schlüssel gehört in die Android-Einstellungen dieser Anwendung.

  6. SDK verbinden und testen

    Folgen Sie der Android-SDK-Anleitung unten. Initialisieren Sie mit der PushPort-App-ID, öffnen Sie die App, erlauben Sie Benachrichtigungen und suchen Sie die Installation unter Zielgruppe. Senden Sie zunächst einen Test an genau diese Installation.

Die private JSON-Datei ist ein Server-Zugangsschlüssel. Sie gehört nicht in app/src, Git, eine APK oder das Kontaktformular. Für PushPort selbst sind google-services.json und das Google-Services-Gradle-Plugin nicht erforderlich.

Dateien und Kennungen unterscheiden

Dateien und Kennungen unterscheiden
Datei oder WertZielZweck
Dienstkonto-JSONPushPort → Anwendung → Einstellungen → FirebaseAutorisiert den Server zum Versand über das gewählte Firebase-Projekt.
google-services.jsonFür diese Android-Integration nicht erforderlichClient-Konfiguration für eigene, getrennt genutzte Firebase-Funktionen der App.
PushPort App IDSDK-Initialisierung im App-CodeÖffentliche Anwendungskennung, kein Provider-Schlüssel und kein Geräte-Token.
APNs-Schlüssel .p8PushPort → App → Einstellungen → Apple APNsApple-Absenderschlüssel. Für PushPort weder in die iOS-App noch in Firebase aufnehmen.

Wenn die Firebase-Einrichtung scheitert

Zugriff verweigert / 403
Prüfen Sie Projekt und Schlüssel. Das Dienstkonto benötigt in Google Cloud IAM Firebase Viewer (roles/firebase.viewer) zum Lesen der Projektdaten und Firebase Cloud Messaging API Admin (roles/firebasecloudmessaging.admin) zum Versand. Prüfen Sie beide APIs.
Falsche JSON-Datei
Laden Sie den Dienstkontoschlüssel hoch, nicht google-services.json oder eine Google-OAuth-Clientdatei.
Installation oder Nachricht fehlt
Prüfen Sie App-ID, Paketbeschränkung, Google Play-Dienste, Netzwerk, Systemberechtigung und SDK-Abonnement. Firebase Analytics steuert die Erfassung des Gebietsschemas nicht.
Nächster Schritt: Android-SDK installieren →

05 / Android / Firebase

Android-SDK installieren

Android SDK 0.0.5 ist auf Maven Central veröffentlicht. Ergänzen Sie google() und mavenCentral() in Gradle sowie implementation("dev.pushport:android-sdk:0.0.5"). Gradle lädt das SDK und seine transitiven Abhängigkeiten.

settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        google()
        mavenCentral()
    }
}
app/build.gradle.kts
dependencies {
    implementation("dev.pushport:android-sdk:0.0.5")
}

Initialisieren Sie das SDK in Ihrer Application-Klasse und registrieren Sie diese in AndroidManifest.xml. Nutzen Sie eine vorhandene Application-Klasse weiter. Bei mehreren Prozessen erfolgt die Initialisierung nur im Hauptprozess.

MyApplication.kt
import android.app.Application
import dev.pushport.sdk.PushPort

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        PushPort.initWithContext(this, "PUSHPORT_APP_ID")
    }
}
AndroidManifest.xml
<application android:name=".MyApplication" />
Activity
PushPort.requestNotificationPermission(this)
  • Fragen Sie die Benachrichtigungsberechtigung aus einer sichtbaren Activity ab und erklären Sie den Nutzen.
  • Firebase Messaging, WorkManager und Manifest-Komponenten kommen mit der Abhängigkeit.
  • Starten Sie die App, erteilen Sie die Berechtigung und prüfen Sie die Installation unter Zielgruppe.

Offizielle Referenzen und vollständige Anleitungen

Nächster Schritt: Apple APNs vorbereiten →

06 / Apple / APNs

Apple APNs vorbereiten

Das PushPort-Apple-SDK verwendet APNs direkt. Registrieren Sie für PushPort keine iOS-App in Firebase und fügen Sie weder Firebase Messaging noch GoogleService-Info.plist hinzu. Firebase kann für unabhängige Funktionen Ihrer App weiterhin genutzt werden.

Apple SDK 0.0.2 ist veröffentlicht. Laden Sie in den App-Einstellungen den APNs-.p8-Schlüssel mit Team ID, Key ID und der Umgebung Sandbox oder Production hoch. Der Server sendet direkt über APNs. Prüfen Sie ein echtes Gerät vor einer Kampagne.
  1. Apple-Developer-Mitgliedschaft

    Zum Herunterladen des SDK ist kein Apple-Konto nötig. Echte APNs-Tests benötigen eine aktive Apple Developer Program-Mitgliedschaft, eine signierte App und ein passendes Provisioning Profile.

  2. Bundle ID prüfen

    Apple Developer → Certificates, Identifiers & Profiles → Identifiers: Wählen oder registrieren Sie eine explizite App ID passend zum Bundle Identifier in Xcode. Aktivieren Sie Push Notifications.

  3. APNs-Schlüssel vorbereiten

    Erstellen Sie unter Keys einen Schlüssel mit Apple Push Notification service. Konfigurieren Sie die angebotenen Umgebungs- und Topic-Beschränkungen für Ihre App. Laden Sie .p8 herunter; Apple ermöglicht den Download nur einmal.

  4. Vier Werte sichern

    Sie benötigen Team ID, Key ID, Bundle ID und die .p8-Datei. Prüfen Sie die erlaubten Umgebungen und Apps: Nicht jeder neue Schlüssel gilt gleichzeitig für Development und Production.

  5. Xcode-Capability aktivieren

    Haupt-Target → Signing & Capabilities → + Capability → Push Notifications. Entwicklungsteam und Signaturprofil müssen das Entitlement unterstützen.

  6. Umgebung wählen

    Nutzen Sie .sandbox bei aps-environment: development und .production für Production, TestFlight und App Store. App-Umgebung, APNs-Serveradresse und Schlüsselumfang müssen zusammenpassen. Fahren Sie mit der SDK-Integration fort.

Nächster Schritt: Apple-SDK installieren →

07 / Apple / APNs

Apple-SDK installieren

Installieren Sie das öffentliche Swift-Paket auf einem Mac mit Xcode. Mindestversion: iOS 15.0. Ein CocoaPods-Konto, eine Firebase-Datei oder ein manueller Framework-Download sind nicht erforderlich.

Apple SDK 0.0.2 ist veröffentlicht. Laden Sie in den App-Einstellungen den APNs-.p8-Schlüssel mit Team ID, Key ID und der Umgebung Sandbox oder Production hoch. Der Server sendet direkt über APNs. Prüfen Sie ein echtes Gerät vor einer Kampagne.
  1. Paket hinzufügen

    Xcode → File → Add Package Dependencies → URL unten → Exact Version → 0.0.2. Fügen Sie das Produkt PushPort zum Haupt-Target hinzu.

Swift Package Manager · Exact Version 0.0.2
https://github.com/IamFromUA/PushPortLibraryApple.git

Im App-Delegate initialisieren

Verwenden Sie die App-ID aus den PushPort-Einstellungen. Das SwiftUI-Beispiel unten leitet beide APNs-Callbacks weiter. In UIKit gehören dieselben Aufrufe in den bestehenden AppDelegate.

Nutzen Sie .sandbox bei aps-environment: development und .production für Production, TestFlight und App Store. App-Umgebung, APNs-Serveradresse und Schlüsselumfang müssen zusammenpassen. Fahren Sie mit der SDK-Integration fort.

MyApp.swift
import SwiftUI

import UIKit

import OSLog

import PushPort



@main

@MainActor

struct MyApp: App {

    @UIApplicationDelegateAdaptor(AppDelegate.self) var delegate

    var body: some Scene {

        WindowGroup { NotificationSettings() }

    }

}



@MainActor

final class AppDelegate: NSObject, UIApplicationDelegate {

    private let logger = Logger(subsystem: "app.notifications", category: "PushPort")



    func application(_ application: UIApplication,

                     didFinishLaunchingWithOptions options: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool {

        do {

            try PushPort.shared.initialize(

                appId: "YOUR_PUSHPORT_APP_ID",

                environment: .sandbox

            )

        } catch {

            logger.error("PushPort initialization failed")

        }

        return true

    }



    func application(_ application: UIApplication,

                     didRegisterForRemoteNotificationsWithDeviceToken token: Data) {

        PushPort.shared.didRegisterForRemoteNotifications(deviceToken: token)

    }



    func application(_ application: UIApplication,

                     didFailToRegisterForRemoteNotificationsWithError error: Error) {

        PushPort.shared.didFailToRegisterForRemoteNotifications(error: error)

    }

}

Benachrichtigungsberechtigung anfragen

Erklären Sie den Nutzen und fragen Sie beispielsweise über eine Schaltfläche nach. Die Initialisierung zeigt keinen Dialog. Nach einer Ablehnung ändert der Nutzer die Berechtigung in Settings.

NotificationSettings.swift
import SwiftUI

import PushPort



@MainActor

struct NotificationSettings: View {

    @State private var result = ""

    @State private var requesting = false



    var body: some View {

        VStack {

            Button("Enable notifications") {

                requesting = true

                Task { @MainActor in

                    defer { requesting = false }

                    do {

                        let granted = try await PushPort.shared.requestPermission()

                        result = granted ? "Notifications allowed" : "Check notification settings"

                    } catch {

                        result = "Unable to request permission"

                    }

                }

            }

            .disabled(requesting)

            Text(result)

        }

    }

}

Systemberechtigung und PushPort-Abonnement sind getrennt. setSubscribed(false) speichert die Abmeldung; true umgeht keine Systemablehnung. Das SDK erfasst App- und Systemsprachen sowie die Zeitzone automatisch. setLocale(nil) stellt die automatische Auswahl wieder her. Bereits versendete APNs-Nachrichten können nach einer Abmeldung noch eintreffen.

Swift
// Call from your app's settings action.

@MainActor

func updateNotifications(subscribed: Bool, locale: String?) async throws {

    try await PushPort.shared.setSubscribed(subscribed)

    try await PushPort.shared.setLocale(locale)

}



// locale: "uk-UA" for an override, nil for automatic selection.

// Handle errors in the calling view and update its displayed state.

Profile, Einwilligung und Benachrichtigungsdiagnose

Das aktuelle SDK unterstützt bestätigte Profile, Tags mit Zeichenkettenwerten, verifizierten External-ID-Login/Logout, ausdrücklich übergebene E-Mail/Telefon/Position und Ereignisse. Identitätsnachweise stellt Ihr vertrauenswürdiges Backend aus; ein Konto-API-Schlüssel gehört niemals in die App. Einwilligungsanforderungen bei Bedarf vor der Initialisierung setzen. Dateneinwilligung und Benachrichtigungsberechtigung sind getrennt.

Empfang, Ergebnisse der Benachrichtigungs-API, Bildvorbereitung/-fehler, Klicks und Vordergrundsitzungen/Nutzungszeit werden dauerhaft gepuffert und mit Ereignisbestätigung erneut gesendet. Rückkehr binnen 60 Sekunden nach einem Klick ist direkt; binnen einer Stunde nach Empfang ohne Klick nur geschätzt beeinflusst. Providerannahme, SDK-Vorbereitung und API-Erfolg beweisen keine menschliche Sichtung.

Offizielle Referenzen und vollständige Anleitungen

Offizielle Referenzen und vollständige Anleitungen

Nächster Schritt: Bilder und Benachrichtigungen unter iOS →

08 / Apple / APNs

Bilder und Benachrichtigungen unter iOS

Für Bilder legen Sie in Xcode eine Notification Service Extension an und verbinden damit das Produkt PushPortNotificationService. Die Haupt-App verwendet weiterhin PushPort.

  1. Extension-Klasse verwenden

    Ersetzen Sie die generierte Klasse durch die Unterklasse unten. NSExtensionPrincipalClass bleibt $(PRODUCT_MODULE_NAME).NotificationService.

  2. Bildnachricht vorbereiten

    Apple SDK 0.0.2 lädt standardmäßig bis 5 MiB und berücksichtigt 1–20 MiB aus den Projekteinstellungen, begrenzt auf 10 MiB für iOS-Anhänge. JPEG/PNG/GIF und WebP-zu-PNG, soweit unterstützt, verwenden begrenzte Dekodierung, 20 Sekunden Gesamttimeout und höchstens 2000 Pixel je Seite. Fehler erhalten den Text. Das Benachrichtigungssymbol stammt aus der installierten App; Android small_icon und large_icon ersetzen es nicht.

  3. Tippen in der App behandeln

    onNotificationOpened liefert die Nachrichten-ID und optional einen sicheren HTTPS-Link. Die App bestimmt die Navigation. Bei Bildfehlern oder Ablauf der Extension bleibt der ursprüngliche Text erhalten.

NotificationService.swift
import PushPortNotificationService



final class NotificationService: PushPortNotificationService {}

Für Hintergrund-Empfangs- und Bilddiagnosen dieselbe App Group in App und Extension aktivieren und PushPortAppGroup in beiden Info.plist gleich setzen. Nur begrenzte Ereignisdateien werden geteilt; Installationszugangsdaten verbleiben in der App. Die nächste App-Synchronisierung lädt die Ereignisse hoch. Bilder allein benötigen keine App Group.

Info.plist · app + extension
<key>PushPortAppGroup</key>
<string>group.com.example.app.pushport</string>
Das SDK leitet Ereignisse an einen bestehenden UNUserNotificationCenterDelegate weiter. Installieren Sie ihn vor der SDK-Initialisierung oder verwenden Sie manageNotificationDelegate: false und rufen Sie handleNotificationResponse(_:) im eigenen Delegate auf.
Nächster Schritt: Web Push einrichten →

09 / Web / KMP

Web Push einrichten

Web Push verwendet den Push-Dienst des Browsers und VAPID-Schlüssel. Ein Firebase-Projekt ist nicht erforderlich. Anbieter-Routen für Chrome/Edge, Firefox und Safari sind vorbereitet.

  1. Website-Origin speichern

    App erstellen oder Web aktivieren. Den genauen HTTPS-Origin ohne Pfad eintragen, etwa https://example.com. Subdomains sind eigene Origins.

  2. Web Push aktivieren

    App → Einstellungen → Web Push aktivieren. PushPort erzeugt ein dauerhaftes Schlüsselpaar und schützt den privaten Schlüssel auf dem Server. Das SDK erhält nur den öffentlichen Schlüssel. Bestehende Abonnements benötigen unveränderte Schlüssel.

  3. Service Worker bereitstellen

    SDK installieren und den Worker auf die eigene Website kopieren. Die URL muss JavaScript vom selben Origin liefern, keine HTML-Ersatzseite.

  4. Berechtigung per Klick anfordern

    Nach dem Laden initialisieren; die Berechtigung direkt aus einem Klick anfordern. Auf iPhone/iPad ist eine unterstützte Home-Screen-Web-App nötig. Eine Ablehnung wird in den Browser-Einstellungen geändert.

Offizielle Referenzen und vollständige Anleitungen

Nächster Schritt: Web SDK installieren →

10 / Web / KMP

Web SDK installieren

Version 0.0.2 lässt sich als normale npm-Abhängigkeit aus dem GitHub-Release installieren. Die npm-Registry-Veröffentlichung wartet auf das Publisher-Konto. Beim Website-Build node_modules/@pushport/web-sdk/dist/pushport-sw.js nach public/pushport-sw.js kopieren.

npm
npm install https://github.com/IamFromUA/PushPortLibraryWeb/releases/download/0.0.2/pushport-web-sdk-0.0.2.tgz
TypeScript
import { PushPort } from '@pushport/web-sdk';



if (PushPort.isSupported()) {

  const push = await PushPort.initialize({

    appId: 'YOUR_PUSHPORT_APP_ID',

    serviceWorkerUrl: '/pushport-sw.js',

  });

  document.querySelector('#enable-push')?.addEventListener('click', () => {

    void push.requestPermission().catch(error => {

      const status = document.querySelector('#push-status');

      if (status) status.textContent = error.message;

    });

  });

}

Ein Worker ist bereits vorhanden? Den kopierten PushPort-Worker darin importieren und serviceWorkerRegistration übergeben. Die Website kontrolliert Scope und Updates. Das SDK ersetzt keinen anderen Worker. HTTPS-Benachrichtigungslinks bleiben innerhalb des Website-Origins.

setSubscribed(false) meldet ab und synchronisiert die Auswahl. setLocale(null) aktiviert die automatische Sprache. Nach Änderungen status().lastSyncedAt und syncError prüfen.

Profile, Einwilligung und Benachrichtigungsdiagnose

Das aktuelle SDK unterstützt bestätigte Profile, Tags mit Zeichenkettenwerten, verifizierten External-ID-Login/Logout, ausdrücklich übergebene E-Mail/Telefon/Position und Ereignisse. Identitätsnachweise stellt Ihr vertrauenswürdiges Backend aus; ein Konto-API-Schlüssel gehört niemals in die App. Einwilligungsanforderungen bei Bedarf vor der Initialisierung setzen. Dateneinwilligung und Benachrichtigungsberechtigung sind getrennt.

Empfang, Ergebnisse der Benachrichtigungs-API, Bildvorbereitung/-fehler, Klicks und Vordergrundsitzungen/Nutzungszeit werden dauerhaft gepuffert und mit Ereignisbestätigung erneut gesendet. Rückkehr binnen 60 Sekunden nach einem Klick ist direkt; binnen einer Stunde nach Empfang ohne Klick nur geschätzt beeinflusst. Providerannahme, SDK-Vorbereitung und API-Erfolg beweisen keine menschliche Sichtung.

Web SDK 0.0.2 lädt großes Bild und HTTPS-large_icon unabhängig. Standard: 5 MiB, im Projekt auf 1–20 MiB einstellbar. Browserdekodierung/Canvas reduziert Bilder auf 2000 und Icons auf 256 Pixel, soweit verfügbar. Externe Bildserver müssen CORS erlauben. Browser und Betriebssystem bestimmen die Anzeige; Android-small_icon-Ressourcen sind keine Web-badge-URLs. Seitenpaket und kopierten Service Worker desselben Origins gemeinsam aktualisieren.

Offizielle Referenzen und vollständige Anleitungen

Offizielle Referenzen und vollständige Anleitungen

Nächster Schritt: Kotlin Multiplatform verbinden →

11 / Web / KMP

Kotlin Multiplatform verbinden

KMP nutzt unsere nativen Android-, Apple- und Web-SDKs ohne zweite Installation. Dafür sind keine separate PushPort-App oder zusätzliche Anbieter-Schlüssel nötig.

KMP SDK 0.0.2 ist auf Maven Central veröffentlicht. Ergänzen Sie google() und mavenCentral() sowie dev.pushport:kmp-sdk:0.0.2 in commonMain. Das Android SDK ist transitiv. Apple- und Web-Anwendungen binden zusätzlich das jeweilige native SDK gemäß der folgenden Anleitung ein.
build.gradle.kts
commonMain.dependencies {

    implementation("dev.pushport:kmp-sdk:0.0.2")

}
  1. Gemeinsames Modul

    dev.pushport:kmp-sdk:0.0.2 in commonMain hinzufügen. Android SDK wird transitiv aufgelöst. Einen Client pro App im UI/Main-Thread verwenden.

  2. Android

    createAndroidPushPort(applicationContext) mit einem Provider für die aktive Activity verwenden. Keine zerstörte Activity behalten.

  3. Apple

    PushPort 0.0.2 über SPM hinzufügen, PushPortKMPBridge() in Swift erzeugen und APNs-Callbacks weiterleiten. createApplePushPort() mit identischer App ID und Umgebung verwenden.

  4. Web

    Web SDK installieren, Worker auf demselben Origin bereitstellen und das Modul an createWebPushPort übergeben. Kotlin/Wasm und native Desktop-Benachrichtigungen sind nicht enthalten.

commonMain · Kotlin
import dev.pushport.kmp.PushPort

import dev.pushport.kmp.PushPortConfiguration

import dev.pushport.kmp.AppleEnvironment



suspend fun initializePush(client: PushPort) {

    client.initialize(PushPortConfiguration(

        appId = "YOUR_PUSHPORT_APP_ID",

        appleEnvironment = AppleEnvironment.SANDBOX,

    ))

    client.setLocale(null)

}

Der macOS-Build einschließlich eines unabhängigen Kotlin-Frameworks in einer Swift-App mit dem veröffentlichten Apple SDK war erfolgreich. Die Zustellung auf Geräten und Browsern wird separat geprüft.

Profile, Einwilligung und Benachrichtigungsdiagnose

Das aktuelle SDK unterstützt bestätigte Profile, Tags mit Zeichenkettenwerten, verifizierten External-ID-Login/Logout, ausdrücklich übergebene E-Mail/Telefon/Position und Ereignisse. Identitätsnachweise stellt Ihr vertrauenswürdiges Backend aus; ein Konto-API-Schlüssel gehört niemals in die App. Einwilligungsanforderungen bei Bedarf vor der Initialisierung setzen. Dateneinwilligung und Benachrichtigungsberechtigung sind getrennt.

Empfang, Ergebnisse der Benachrichtigungs-API, Bildvorbereitung/-fehler, Klicks und Vordergrundsitzungen/Nutzungszeit werden dauerhaft gepuffert und mit Ereignisbestätigung erneut gesendet. Rückkehr binnen 60 Sekunden nach einem Klick ist direkt; binnen einer Stunde nach Empfang ohne Klick nur geschätzt beeinflusst. Providerannahme, SDK-Vorbereitung und API-Erfolg beweisen keine menschliche Sichtung.

Offizielle Referenzen und vollständige Anleitungen

Nächster Schritt: Zielgruppe verstehen →

12 / Zielgruppe und Nachrichten

Zielgruppe verstehen

Nutzer, Installationen und erfasste Daten

Android SDK 0.0.5 ist auf Maven Central veröffentlicht. Profile, Tags, bestätigter External-ID-Login/Logout, Einwilligung und Vordergrundnutzung werden vom aktuellen Backend unterstützt. Apple, Web und KMP SDK 0.0.2 bieten die entsprechenden nativen APIs.

Automatisch: Installations-UUID, separate PushPort-Nutzer-ID, verfügbare Android ID, FCM-Token, Berechtigung und Abonnementstatus, Sprache und Gebietsschemas, Zeitzone, Paket und App-/OS-/SDK-Versionen, Hersteller/Modell, Mobilfunkanbieter sowie Sitzungen und Vordergrundzeit. Das Backend speichert die letzte IP-Adresse und das ungefähre Land vom vertrauenswürdigen Proxy. Hintergrundsynchronisierung zählt nicht als Besuch.

Jede neue Installation erhält eine neue PushPort userId. Neustarts und Updates behalten sie bei. Android ID verknüpft nur den Verlauf; Nutzer und Tags werden nach einer Neuinstallation nicht zusammengeführt. Bestehende IDs bleiben erhalten. Ein explizit bestätigter Login kann Konten verknüpfen.

Tags, E-Mail, E.164-Telefonnummer, Koordinaten und Ereignisse werden ausdrücklich von Ihrer App übergeben. PushPort liest Kontakte, IMEI, Werbe-ID oder GPS nicht automatisch. Kontaktdaten aktivieren keinen E-Mail-/SMS-Versand.

Nach Authentifizierung des Nutzers fordert Ihr Backend mit POST /api/v1/apps/{appId}/identity-tokens und installationId/externalId einen fünf Minuten gültigen Nachweis an und gibt token an die App zurück. Der Sitzungstoken des Besitzers bleibt auf dem Backend. Nach Ablauf oder fehlgeschlagener Anmeldung ist ein neuer Nachweis erforderlich. SDK-Aufrufe stellen Änderungen in eine Warteschlange; PushPort.user(context) liefert das zuletzt bestätigte Profil, status().syncError den Fehler.

Bei erforderlicher Einwilligung setConsentRequired vor der Initialisierung aufrufen. Dateneinwilligung und Android-Benachrichtigungsberechtigung sind getrennt. Widerruf stoppt weitere PushPort-Erfassung, Synchronisierung und Anzeige, kann laufende Anfragen aber nicht zurückrufen und löscht keine Serverhistorie.

Android · Kotlin
PushPort.setConsentRequired(this, true) // before init

PushPort.initWithContext(this, appId)

// After your consent flow:

PushPort.setConsentGiven(this, true)

// After your backend verifies the account:

PushPort.login(context, externalId, identityToken)

PushPort.setTags(context, mapOf("plan" to "pro"))

val confirmedUser = PushPort.user(context)

PushPort.logout(context)

Die Zielgruppe zählt Installationen. Eine Person mit zwei Geräten kann zweimal erscheinen. Filtern Sie nach Sprache, Gebietsschema, ungefährem Land und Abonnementstatus; speichern Sie hilfreiche Kombinationen als Segmente.

Das SDK synchronisiert App- und System-Gebietsschemas, Zeitzone, Version und Benachrichtigungsstatus. de-DE ist ein Gebietsschema, de eine Sprache. Das Land wird anhand der IP geschätzt und kann unbekannt sein.

Android · Kotlin
PushPort.setLocale(context, "de-DE")
PushPort.setLocale(context, null)
PushPort.setSubscribed(context, false)
PushPort.setSubscribed(context, true)
PushPort.sync(context)
  • SUBSCRIBED — Versand möglich, wenn Token und Berechtigung vorliegen.
  • UNSUBSCRIBED / PERMISSION_DENIED — App oder System hat Benachrichtigungen deaktiviert.
  • AWAITING_TOKEN / INVALID_TOKEN — kein verwendbares Token vorhanden.
Nächster Schritt: Partnerintegration und API →

13 / Zielgruppe und Nachrichten

Partnerintegration und API

Die Server-API ist unter pushport.dev verfügbar. Automatische Markierung nach API-Pushs und Ausschluss von allgemeinen Kampagnen werden getrennt in den Projekteinstellungen aktiviert. Dafür ist kein SDK-Update erforderlich.

Anwendung → Einstellungen → API-Schlüssel öffnen. Einen Schlüssel für den Partnerserver erstellen und sofort kopieren; er wird nur einmal angezeigt. Schlüssel auf dem Partnerserver aufbewahren; nicht in Apps oder öffentliche URLs einbetten. Apps werden anhand der userId ermittelt; keine App ID erforderlich. Kontoschlüssel gelten für eigene Apps und Team-Apps nach Annahme der Einladung. Schlüsselrechte sind durch aktuelle Teamrechte begrenzt: Betrachter dürfen lesen, Sender Push-Nachrichten senden, Manager auch Tags ändern. Berechtigungen für einzelne Apps gelten ebenfalls; Entfernung oder Rollenwechsel ändern den Zugriff sofort. App-Schlüssel bleiben auf eine App begrenzt.

Die API akzeptiert die ursprüngliche PushPort userId als UUID ohne Präfix oder Suffix. Sie ist weder FCM-Token noch Android ID. Der App-Entwickler legt den Linkparameter und die Formatierung fest. Der Partner entfernt die Formatierung und sendet die ursprüngliche UUID an die API.

Link aus der App

Nach erfolgreicher Synchronisierung die bestätigte userId lesen. Ohne Profil die Synchronisierung abwarten und erneut versuchen. Die App erstellt und öffnet ihre Links selbst; ein URL-Builder kodiert die Werte. Bei einem Kontowechsel die Bestätigung des neuen Profils abwarten.

Android · Kotlin
val userId = PushPort.user(context)?.userId
if (userId != null) {
    val offerUrl = android.net.Uri.parse("https://example.com/offer")
        .buildUpon()
        .appendQueryParameter("sub_id_10", userId + "::|00030")
        .build().toString()
    // Open offerUrl using your application flow.
} else {
    PushPort.sync(context) // async; retry after synchronization
}

Installation abfragen

Die Abfrage akzeptiert genau eine ID. Antwort: installId, appId (Android-Paketname), customAppName, locale (Sprache), countryCode (ggf. null), timezone und type: api. Apps werden anhand der userId ermittelt; keine App ID erforderlich. Kontoschlüssel gelten für eigene Apps und Team-Apps nach Annahme der Einladung. Schlüsselrechte sind durch aktuelle Teamrechte begrenzt: Betrachter dürfen lesen, Sender Push-Nachrichten senden, Manager auch Tags ändern. Berechtigungen für einzelne Apps gelten ebenfalls; Entfernung oder Rollenwechsel ändern den Zugriff sofort. App-Schlüssel bleiben auf eine App begrenzt.

HTTP
POST /api/v1/partner/getInstall/

Authorization: Bearer YOUR_API_KEY

Content-Type: application/json



{"id":"11111111-2222-4333-8444-555555555555"}

An eine Liste senden

1–10.000 IDs je Versandauftrag. Duplikate werden entfernt, unbekannte/fremde IDs stehen in excludedUserIds. Ohne Treffer: 422. click_uuid akzeptiert eine Liste oder aus Kompatibilitätsgründen eine Zeichenkette. Titel, Text und Link gelten für alle Empfänger. Die allgemeine API nutzt userIds, title, body, imageUrl und clickUrl. Bei Benutzern mehrerer Apps enthält die Antwort messages: einen Auftrag mit messageId je App sowie gemeinsame requestedCount, queuedCount und excludedUserIds. Status für jede messageId abrufen. Für eine App bleibt das Antwortformat unverändert.

HTTP
POST /api/v1/partner/push/

Authorization: Bearer YOUR_API_KEY


Content-Type: application/json



{

  "header": "Hello",

  "content": "Your notification",

  "click_uuid": ["11111111-2222-4333-8444-555555555555", "aaaaaaaa-bbbb-4ccc-8ddd-eeeeeeeeeeee"],

  "chrome_web_image": "https://cdn.example.com/image.jpg",
  "large_icon": "https://cdn.example.com/avatar.png",
  "small_icon": "ic_stat_offer",

  "url": "https://example.com/offer"

}

Versandstatus

Idempotency-Key ist optional. Ohne diesen Header erzeugt jede Anfrage einen neuen Versand, auch bei Wiederholungen. Falls angegeben, bei Wiederholungen denselben Schlüssel verwenden. Geänderter Inhalt mit gleichem Schlüssel: 409. 202 bedeutet eingereiht, nicht zugestellt. Eine aktuelle Android-Subscription je userId wird ausgewählt; deaktivierte werden übersprungen. Status per messageId mit demselben Schlüssel abrufen. Widerruf beendet keine angenommenen Aufträge.

60 Anfragen/Minute je Schlüssel, Versandkörper bis 2 MiB. scheduledAt: Unix-Millisekunden, bis 366 Tage im Voraus. Bei 429 Retry-After beachten. accepted: vom Anbieter angenommen; opened: geöffnet; unknown: ungewiss, keine blinde Wiederholung.

PushPort Android SDK 0.0.4+ unterstützt ein farbiges Vorschaubild unabhängig vom großen Bild. In CSV/XLSX und der Partner-API heißt es large_icon, in der allgemeinen API largeIcon. Verwenden Sie eine öffentliche HTTPS-URL oder einen Ressourcennamen aus der App. Empfohlen: quadratisch, 256 × 256. Bestehende OneSignal Android SDKs unterstützen diese Felder ebenfalls; ältere PushPort-Versionen ignorieren sie und zeigen die bisherige Benachrichtigung.

small_icon (allgemeine API: smallIcon) ist ein drawable/mipmap-Ressourcenname ohne Erweiterung, etwa ic_stat_offer. Die Ressource muss im APK enthalten sein: eine weiße Silhouette auf transparentem Hintergrund. URLs und Galerie-Uploads können kein Statussymbol ersetzen.

HTTP
GET /api/v1/public/notifications/MESSAGE_ID

Authorization: Bearer YOUR_API_KEY

Registrierung, Kauf und Nutzer-Tags

Übergeben Sie dieselbe PushPort userId im WebView-Link und an den Partnerserver. Sobald der Partner eine Registrierung oder einen Kauf bestätigt bekommt, aktualisiert sein Server die Tags per API. PushPort erkennt Aktionen auf fremden Websites nicht automatisch.

Tags sind nach App getrennt. Wenn eine Person mehrere Apps nutzt, übergeben Sie die gewünschte App ID und deren PushPort userId. Die App ID steht unter Übersicht → App ID und Einstellungen → API-Schlüssel. GET /api/v1/public/app liefert sie mit dem App-Schlüssel. Jede App benötigt einen eigenen Schlüssel. Eine abweichende App ID führt zu 403. Bisherige URLs ohne App ID bestimmen die App weiterhin anhand des Schlüssels.

Erstellen Sie einen App-Schlüssel mit USER_TAGS_WRITE (Nutzer-Tags ändern). Bestehende Schlüssel erhalten dieses Recht nicht automatisch. PATCH ändert nur die angegebenen Tags: die Zeichenfolge "true" setzt ein Merkmal, null löscht ein Tag. Identische Wiederholungen sind sicher. GET unter demselben Pfad benötigt INSTALLATIONS_READ. Eine unbekannte oder fremde userId liefert 404 und erstellt kein Profil.

HTTP
PATCH /api/v1/public/apps/APP_ID/users/USER_ID/tags
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{"tags":{"registration":"true"}}

// After a confirmed purchase:
// {"tags":{"purchase":"true"}}
// Remove a tag: {"tags":{"purchase":null}}

Bis zu 50 Tags pro Nutzer, Schlüssel bis 64 Zeichen und Werte bis 256. Groß- und Kleinschreibung wird berücksichtigt; Werte sind Zeichenfolgen, keine Booleans. Trifft ein Postback vor der Geräteregistrierung ein, speichern Sie ihn und wiederholen ihn nach der Synchronisierung. Der API-Schlüssel bleibt auf Ihrem Server.

Zielgruppe und Kampagneneditor zeigen tatsächlich empfangene Tags der gewählten App. Ein Klick fügt Vorhanden hinzu; mit Gleich und einem Wert prüfen Sie exakt. Alle Bedingungen gelten gemeinsam, höchstens 10. Ungleich schließt fehlende Tags ein. Filter können als Segmente gespeichert werden. install="true" wird unabhängig von der Push-Berechtigung automatisch gesetzt, auch für bestehende Nutzer. Dieses System-Tag ist unveränderlich und zählt nicht zum Limit von 50 eigenen Tags.

Für alle außer Nutzern mit bestimmten Tags wählen Sie Tags ausschließen und geben die Namen an, etwa reg und dep. Ein Nutzer mit einem dieser Tags wird unabhängig vom Wert ausgeschlossen. Nutzer ohne beide Tags bleiben in der Zielgruppe. Bis zu 10 Bedingungen gelten gemeinsam, auch in Automatisierungen und gespeicherten Segmenten. Ungleich vergleicht dagegen einen bestimmten Wert.

Geplante Kampagnen wählen Empfänger beim Start aus und prüfen Tags vor jedem Versand erneut. Nicht mehr passende Nutzer werden mit audience_changed übersprungen. Bereits an den Anbieter übergebene Push-Nachrichten lassen sich nicht zurückrufen. Tags starten keine Kampagnen automatisch: Erstellen und senden oder planen Sie eine Kampagne.

Partner-API-Pushs

Projekt öffnen → Projekteinstellungen → Sonstiges → Partner-API-Pushs. Beide Optionen sind unabhängig und standardmäßig aus. Änderungen anschließend speichern.

  1. Nutzer nach Annahme eines API-Pushs markieren

    Setzt api_managed=true, sobald ein neuer Push über die Partner- oder öffentliche API eingereiht wird. Dies bestätigt keine Zustellung. Postbacks und Admin-Test-Pushs setzen das Tag nicht.

  2. Markierte Nutzer automatisch von Kampagnen ausschließen

    Gilt für manuelle und automatische Kampagnen einschließlich wartender Empfänger. API-Pushs bleiben erlaubt. Nutzer bleiben in der Zielgruppe sichtbar.

Ohne automatischen Ausschluss in einer manuellen oder automatischen Kampagne eine Zielgruppenbedingung hinzufügen: Tag api_managed, Ungleich, Wert true. Nutzer ohne dieses Tag bleiben eingeschlossen.

Beide Optionen sind unabhängig und standardmäßig aus. Das Abschalten der Markierung erhält vorhandene Tags. Ohne automatischen Ausschluss kann api_managed=true in einzelnen Kampagnenfiltern ausgeschlossen werden. Frühere API-Pushs werden nicht rückwirkend markiert.

Das Tag gilt für einen Nutzer und seine verknüpften Geräte innerhalb eines Projekts. Nutzer bleiben sichtbar; ihr Abonnementstatus ändert sich nicht. Postbacks reg/dep, Installationsabfragen und Admin-Test-Pushs setzen das Tag nicht. Kein SDK-Update nötig. Importe und Tag-Änderungen durch Apps oder Partner können die Systemmarkierung nicht überschreiben.

Ein geplanter API-Push setzt das Tag bereits bei Annahme des neuen Auftrags in die Warteschlange. Fehlerhafte oder abgelehnte Aufträge markieren niemanden. Wartende Empfänger werden erneut geprüft; ein bereits an den Anbieter übergebener Push kann nicht zurückgerufen werden.

Beispiel: Nach der Installation erhalten alle allgemeine Pushs. Sendet Extendy den ersten API-Auftrag für einen Nutzer, setzt die aktivierte erste Option api_managed=true. Ist auch die zweite Option aktiv, enden allgemeine Kampagnen für diesen Nutzer; Partner-API-Pushs bleiben erlaubt. Ein reg- oder dep-Postback allein ändert diese Zuordnung nicht.

Tags per Postback

Für eine URL für alle Apps erstellen Sie unter API-Schlüssel des Kontos einen Schlüssel mit dem Recht, Benutzer-Tags zu ändern. Wählen Sie Ohne Ablaufdatum für einen dauerhaften Schlüssel. Übergeben Sie den Schlüssel als key, die PushPort userId ohne Suffix als user und das Ereignis als tag. Die App wird anhand der userId ermittelt; keine App ID erforderlich. Eigene Tags wie reg, dep, reg_team1 und buyer_team1 benötigen keine vorherige Liste. Kontoschlüssel gelten nur für Apps, die das Konto verwalten darf. App-Schlüssel mit demselben Recht funktionieren innerhalb ihrer eigenen App. Bestehende ppb_-Schlüssel behalten ihre Tag-Beschränkungen. user_id wird ebenfalls akzeptiert; die tatsächliche Android ID ist ungeeignet.

GET
https://pushport.dev/postback?key=ACCOUNT_API_KEY&user=USER_ID&tag=dep

Verwenden Sie reg und dep für allgemeine Nachrichten. Nutzen Sie für einzelne Käufer oder Extendy getrennte Tags wie buyer_team1 oder buyer_extendy und richten Sie die Zielgruppe ein. install bleibt nach Registrierung und Einzahlung bestehen: Ergänzen Sie Nicht vorhanden zum Ausschluss relevanter Gruppen. Ein Postback aktualisiert nur ein Tag und sendet keine Nachricht. Ein unbekanntes Tag schließt Benutzer nicht automatisch von anderen Nachrichten aus.

OpenAPI JSON herunterladen ↓

Nächster Schritt: Automatisierungen →

14 / Zielgruppe und Nachrichten

Automatisierungen

XLSX bis 32 MB; CSV bis 1 MB. Eingebettete PNG/JPEG/GIF in image_url und large_icon werden nach der Prüfung automatisch gespeichert. Bilder in small_icon werden nach large_icon übernommen. Google Tabellen als XLSX exportieren; CSV enthält keine Bilder. Vorhandene Bilder werden wiederverwendet.

Nach der Prüfung werden Bilder in einem Ordner mit dem Dateinamen oder im gewählten Ordner gespeichert.

Jedem leeren Feld wird einmal ein zufälliges Bild zugewiesen. Wiederholungen sind möglich. Die Auswahl bleibt in den Nachrichten gespeichert.

XLSX bis 32 MB oder UTF-8-CSV bis 1 MB, 5.000 Nachrichten und 200 Sprachen. Emojis unterstützt. Reihenfolge oder Zufall in den Einstellungen wählen.

Spalten: title, message, language, image_url, url. Titel und Nachricht sind Pflicht; Sprache aus der Zeile oder dem Standard. Optionale Android-Symbole: large_icon, small_icon (PushPort SDK 0.0.4+ oder OneSignal).

Unterstützte Formate

Eine Sprache: title, message. Sprache im Feld unten festlegen.

Mehrere Sprachen: title, message, language. Sprache in jeder Zeile angeben.

Mit Bildern und Links: title, message, language, image_url, url. Bilder und Links sind optional.

ISO-Sprachcodes: en, ru, de, tg; Gebietsschemas: en-US, pt-BR. Großschreibung ist egal. Nicht unterstützte Sprachen können nach Bestätigung ausgeschlossen werden.

Nicht unterstützte Sprachcodes können nach Bestätigung mit allen zugehörigen Zeilen ausgeschlossen werden. Eine Ersetzung wird nicht angeboten. Die Originaldatei bleibt unverändert.

XLSX: nur das erste Blatt. Formeln werden nicht unterstützt.
CSV UTF-8
title,message,language,image_url,url,large_icon,small_icon
🎁 Hello!,Your message,en,,,https://example.com/avatar.png,ic_stat_offer
  1. Tabelle hochladen

    Datei prüfen

  2. Anwendungen

    Zielgruppe prüfen

  3. Sendezeiten, durch Kommas getrennt

    Zeitzone · UTC · 15:00, 18:00, 21:00

  4. Zeitmodus

    Im lokalen Modus bedeutet 15:00 die Ortszeit des Nutzergeräts. Unbekannte Zeitzonen verwenden die Ersatzzeitzone. Sommerzeit wird berücksichtigt.

  5. Zeitraum

    Beide Daten sind eingeschlossen. Im lokalen Modus gilt die Zeitzone des Nutzers. Ein leeres Datum bedeutet keine Einschränkung.

  6. Nachrichtenauswahl

    Jeder Sprachpool wird gemischt. Nach dem Pool endet die Automatisierung oder startet bei aktivierter Wiederholung einen neuen Durchlauf.

  7. Ohne Start speichern

    Ohne Start gespeichert

  8. Starten

    Nach letzter Nachricht wiederholen

Die Zielgruppe wird vor jedem Versand aktualisiert. Gemeinsame Sequenz, kein Ablauf ab Installation. Eine Pause storniert noch nicht gestartete Sendungen; laufende können enden.

Nach Ausfall wird der vergangene Termin übersprungen und eine Nachricht weitergeschaltet. Fortsetzung zum nächsten zukünftigen Termin.

Öffnen Sie die Automatisierung und wählen Sie Bearbeiten. Eine aktive Automatisierung zuerst pausieren. Name, Nachrichten, Bilder, Zeitplan, Zeitraum, Zielgruppe und Wiederholung sind änderbar. Speichern lässt sie pausiert; Zielgruppe prüfen und danach Fortsetzen wählen. Beendete oder dauerhaft gestoppte Automatisierungen lassen sich nicht bearbeiten.

Änderungen an Nachrichten oder deren Auswahl beginnen einen neuen Durchlauf. Name, Zeitplan, Zielgruppe und Wiederholung behalten die Nachrichtenposition. Frühere Berichte bleiben erhalten; laufende Sendungen verwenden ihre bisherige Nachricht und Zielgruppe.

Für alle außer Nutzern mit bestimmten Tags wählen Sie Tags ausschließen und geben die Namen an, etwa reg und dep. Ein Nutzer mit einem dieser Tags wird unabhängig vom Wert ausgeschlossen. Nutzer ohne beide Tags bleiben in der Zielgruppe. Bis zu 10 Bedingungen gelten gemeinsam, auch in Automatisierungen und gespeicherten Segmenten. Ungleich vergleicht dagegen einen bestimmten Wert.

Öffnen Sie Nachrichten → Bibliothek oder das Kontomenü. Erstellen Sie Kampagnen- und Automatisierungsvorlagen direkt in der Bibliothek. Nachrichten lassen sich ohne Tabelle manuell hinzufügen. Gespeicherte Vorlagen über ihre Karten bearbeiten. Auch bestehende Kampagnen können als Vorlage gespeichert werden. Das Projekt wählen Sie bei der Verwendung. Einstellungen prüfen und vor dem Start einen Entwurf oder eine pausierte Automatisierung speichern. Vorlagen sind privat; Änderungen und Löschen ändern bestehende Kopien nicht.

Versandverlauf

Nächster Schritt: Senden und planen →

15 / Zielgruppe und Nachrichten

Senden und planen

Öffnen Sie die Kampagnen Ihrer App. Speichern Sie Titel, Nachricht und Zielgruppe als Entwurf. Prüfen Sie die erreichbare Anzahl und senden Sie zunächst einen Test an Ihre eigene Installation.

Wählen Sie sofortigen Versand oder einen zukünftigen Zeitpunkt. Die Anzeige nutzt die Browser-Zeitzone, gespeichert wird UTC. Der Zeitplan läuft auf dem Server auch nach dem Schließen der Seite weiter.

  • Reihenfolge der Übersetzung: genaues Gebietsschema → Sprache → Standardtext.
  • Täglich wiederkehrende Kampagnen und Automatisierungen mit mehreren Uhrzeiten sind verfügbar. Automatisierungen können die lokale Empfängerzeitzone nutzen; die Warteschlange zeigt Zeiten in Ihrer Browserzeitzone.
  • Abbrechen stoppt ausstehende Nachrichten, ruft aber bereits an FCM übergebene nicht zurück.

Vorlagenbibliothek

Öffnen Sie Nachrichten → Bibliothek oder das Kontomenü. Erstellen Sie Kampagnen- und Automatisierungsvorlagen direkt in der Bibliothek. Nachrichten lassen sich ohne Tabelle manuell hinzufügen. Gespeicherte Vorlagen über ihre Karten bearbeiten. Auch bestehende Kampagnen können als Vorlage gespeichert werden. Das Projekt wählen Sie bei der Verwendung. Einstellungen prüfen und vor dem Start einen Entwurf oder eine pausierte Automatisierung speichern. Vorlagen sind privat; Änderungen und Löschen ändern bestehende Kopien nicht.

Text, Übersetzungen, Bildlinks, Zielgruppenbedingungen und Automatisierungseinstellungen werden kopiert. Geräte-IDs, Daten und Versandfortschritt werden entfernt. Bildlinks bleiben gemeinsam: Quelldateien müssen verfügbar bleiben.

Nächster Schritt: Bilder und Links →

17 / Zielgruppe und Nachrichten

Ergebnisse verstehen

Ein erfolgreicher Versand bedeutet, dass FCM, APNs oder der Push-Dienst des Browsers die Anfrage angenommen hat. Das bestätigt keine Anzeige auf dem Gerät. Gemeldete Öffnungen, Fehler und ungewisse Ergebnisse werden getrennt erfasst.

Android SDK 0.0.3+ ergänzt Zustellberichte je Anwendung: SDK-Empfang, Android-Benachrichtigungserstellung, Bilddownload und Anhang mit Größe, Dauer und HTTP-Status, Klicks, Linkstart- und Synchronisierungsfehler. Nach Datum oder Nutzer-/Installations-/Nachrichten-ID filtern und den Verlauf prüfen. FCM-Annahme bestätigt keine Zustellung, Android-Erstellung keine Sichtbarkeit und Linkstart kein Laden der Website. Ältere SDKs funktionieren weiter, liefern diese Ereignisse jedoch nicht. Registrierung, Einzahlungen und Folgeeinzahlungen muss der Partner melden.

  • Vor einem neuen Versuch Abonnement und Systemberechtigung prüfen.
  • Vorschau und tatsächliche Zielgruppe können sich unterscheiden.
  • Für die Untersuchung Zeitpunkt und Installations-ID vergleichen.
Nächster Schritt: Probleme beheben →

18 / Zielgruppe und Nachrichten

Probleme beheben

Fehlt die Installation, starten Sie die App und prüfen Sie App-ID, Serververbindung und SDK-Initialisierung. Ist sie vorhanden, aber nicht erreichbar, prüfen Sie Berechtigung, Abonnement und Token.

Wurde die Nachricht angenommen, erscheint aber nicht, prüfen Sie Netzwerk, Benachrichtigungseinstellungen und Zielinstallation. Bei Bildproblemen öffnen Sie die URL ohne Anmeldung und prüfen Sie Größe und Format.

  • Code fehlt: Spamordner und Adresse prüfen, vor einem neuen Code eine Minute warten.
  • Firebase-Fehler: Gehören die Sender-Zugangsdaten zum richtigen Projekt?
  • Weiterhin Probleme? Senden Sie App-ID, ungefähren Zeitpunkt und erwartetes Ergebnis über Kontakt.
PushPort-Support ↗