Wir haben die strategische Begründung an anderer Stelle dargelegt: Die Ära der Massenbenachrichtigungen ist vorbei, und verhaltensgesteuerte Benachrichtigungen sind das, was Plattformen belohnen und Abonnenten tolerieren. Dieser Leitfaden ist die andere Hälfte – wie man Push-Benachrichtigungen von App-Ereignissen unter iOS tatsächlich auslöst, von der Instrumentierung bis zur Übergabe an das Marketing. Er richtet sich an den Entwickler, der die Verkabelung vornimmt, mit dem Code, den Sie ausliefern werden, und den Konventionen, die ihn wartbar halten.
Die Architektur in einem Absatz
Ihre App löst benannte Ereignisse mit typisierten Eigenschaften aus. PushEngage gleicht diese Ereignisse mit Trigger-Regeln ab, die im Dashboard konfiguriert sind, und Kampagnen werden gesendet – sofort, mit Verzögerung oder als mehrstufige Sequenz mit Abbruchbedingungen. Die Arbeitsteilung ist der Punkt: Die Technik instrumentiert jedes Ereignis einmal; das Marketing erstellt, bearbeitet und beendet Kampagnen gegen diese Ereignisse für immer, ohne einen weiteren Build. Ihre Instrumentierung ist eine API für Ihr Marketingteam.
trackEvent: das Allzwecksignal
Das iOS SDK 1.0 führte trackEvent ein, das Arbeitspferd für benutzerdefinierte Verhaltenssignale:
PushEngage.trackEvent(name: "product_viewed",
properties: [
"sku": "WCJ-1042",
"category": "outerwear",
"price": 189.00,
"in_stock": true
],
profileId: currentUserId, // ties the event to an identified subscriber
provider: nil,
eventType: nil) { success, error in
if !success { log(error) }
}Drei Regeln, die das SDK erzwingt, also planen Sie sie von Anfang an ein:
- Eigenschaftswerte müssen Zeichenketten, Zahlen oder Booleans sein. Arrays, Dictionaries und Daten werden clientseitig abgelehnt – flachen Sie sie ab, bevor Sie sie senden.
- Ereignisnamen und Eigenschaftsschlüssel dürfen nicht leer sein. Der Abschluss-Handler teilt Ihnen mit, wenn die Validierung fehlschlägt; protokollieren Sie dies in Debug-Builds.
- Abschluss-Handler kommen auf einer Hintergrundwarteschlange an. Leiten Sie zur Hauptwarteschlange weiter, bevor Sie die Benutzeroberfläche berühren.
Übergeben Sie profileId, wann immer der Benutzer identifiziert wird – dies ermöglicht es einer Kampagne, einem Kunden geräteübergreifend zu folgen, anstatt einem Gerät zu folgen.
sendTriggerEvent: klassische Trigger-Kampagnen verdrahten
Für Kampagnen, die im Trigger-Builder des Dashboards erstellt wurden – Warenkorbabbrüche, Browse-Abbrüche, benutzerdefinierte Journeys – löst die App sendTriggerEvent mit den vom Vermarkter konfigurierten Kampagnen- und Ereignisnamen aus, plus die Datentoken, die die Benachrichtigungsvorlage rendern wird:
let trigger = TriggerCampaign(campaignName: "cart_abandonment",
eventName: "add_to_cart",
data: [
"productname": "Waxed Canvas Jacket",
"price": "$189",
"cartlink": "myapp://cart"
])
PushEngage.sendTriggerEvent(triggerCampaign: trigger) { success, error in
// background queue — dispatch before UI work
}Die data-Token fließen in den Benachrichtigungstext – so wird „Ihre gewachste Canvas-Jacke wartet“ personalisiert, ohne dass der Vermarkter Code anfassen muss. Die vollständige Warenkorb-Wiederherstellungssequenz haben wir im Playbook für Warenkorbabbrüche in mobilen Apps durchlaufen; dieser Aufruf ist die treibende Kraft dahinter.
addAlert: Preisfall und Wiederverfügbarkeit, integriert
Die beiden umsatzstärksten Commerce-Trigger erfordern nicht einmal benutzerdefinierte Kampagnen – sie sind First-Class-SDK-Bürger. Wenn ein Benutzer ein Produkt beobachtet, registrieren Sie die Benachrichtigung:
let alert = TriggerAlert(type: .priceDrop, // or .inventory
productId: "WCJ-1042",
link: "myapp://product/WCJ-1042",
price: 189.00,
data: ["size": "M"])
PushEngage.addAlert(triggerAlert: alert) { success, error in }PushEngage kümmert sich um das Beobachten, Abgleichen und Senden, wenn der Preis fällt oder der Bestand zurückkehrt. Wenn Sie unseren Leitfaden für Preisfall-Benachrichtigungen gelesen haben, ist dies die App-seitige Registrierung, die diese Kampagnen auslöst.
Eine Ereignis-Taxonomie, die skaliert
Instrumentierungs-Schulden sind real: Sechs Monate später erinnert sich niemand mehr daran, ob das Ereignis addToCart, cart_add oder CartUpdated heißt. Legen Sie von Anfang an Konventionen fest – Namen im snake_case-Format, Objekt-Aktions-Reihenfolge, singuläre Eigenschaftsschlüssel – und decken Sie die Kern-Commerce-Elemente ab:
| Ereignis | Schlüsseleigenschaften | Kampagnen, die es antreibt |
|---|---|---|
product_viewed | sku, kategorie, preis | Browsing-Abbruch, Personalisierung |
product_saved | sku, preis | Preisnachlass, wieder auf Lager, Win-Back-Hooks |
cart_updated | cart_value, item_count, top_item | Warenkorb-Abbruch |
purchase_completed | order_value, item_count | Ausstiegsbedingungen, Nachkauf, Ziele |
search_performed | query, results_count | Wiederherstellung bei Null-Ergebnissen, Interessensegmente |
onboarding_step | step, completed | Verzweigung der Onboarding-Serie |
Sechs Ereignisse, einmal instrumentiert, treiben die Onboarding-Serie, Warenkorb-Wiederherstellung, Win-Back-Hooks und jedes Segment an, nach dem Ihr Marketingteam dieses Jahr fragen wird.
Testen Sie die Schleife, bevor Sie sie übergeben
Setzen Sie PushEngage.enableLogging = true in Debug-Builds und beobachten Sie, wie Ereignisse das Gerät verlassen. Lösen Sie jedes Ereignis von einem Test-Build aus, bestätigen Sie, dass es in der Ereignisansicht des Dashboards ankommt, und senden Sie eine End-to-End-Testkampagne pro Trigger. Die Beispiel-Apps im SDK-Repository enthalten einen funktionierenden Trigger-Bildschirm, von dem Sie den Ablauf übernehmen können. Fünfzehn Minuten Verifizierung hier sparen die spätere Untersuchung „Warum wurde die Kampagne nicht ausgelöst?“ – die normalerweise ein Tippfehler im Ereignisnamen auf einer Seite des Vertrags ist.
Die Übergabe: Was das Marketing von hier aus übernimmt
Sobald die Ereignisse fließen, ist Ihr Teil erledigt. Das Marketing erstellt Trigger-Regeln, schreibt Texte, legt Verzögerungen und Ausstiegsbedingungen fest, testet Varianten A/B und fügt Zielverfolgung für die Umsatzzuordnung hinzu – alles im Dashboard, alles ohne Ticket. Veröffentlichen Sie die Ereignis-Taxonomietabelle in Ihrem Team-Wiki als Vertrag zwischen den beiden Seiten. Beobachten Sie dann, wie die Anfragewarteschlange für „Können Sie einen Push senden?“-Tickets leise auf Null sinkt – was von Anfang an der Sinn der Sache war. Für die Strategie, der diese Kampagnen folgen sollten, übergeben Sie Ihrem Marketingteam den Leitfaden für App-Push-Marketing.
