Vi har lagt fram det strategiska argumentet på annat håll: "bombningsepoken" är över, och beteendestyrda notiser är vad plattformar belönar och prenumeranter tolererar. Den här guiden är den andra halvan – hur man faktiskt skapar push-notiser från apphändelser på iOS, från instrumentering till överlämning till marknadsföring. Den är skriven för utvecklaren som gör kopplingarna, med den kod du kommer att leverera och de konventioner som gör den underhållbar.
Arkitekturen i en paragraf
Din app skickar namngivna händelser med typade egenskaper. PushEngage matchar dessa händelser mot utlösarregler som konfigurerats i instrumentpanelen, och kampanjer skickas – omedelbart, med fördröjning, eller som en flerstegssekvens med avslutningsvillkor. Arbetsfördelningen är poängen: ingenjörsteamet instrumenterar varje händelse *en gång*; marknadsföringsteamet skapar, redigerar och tar bort kampanjer mot dessa händelser för alltid, utan ytterligare en utvecklingsomgång. Din instrumentering är ett API för ditt marknadsföringsteam.
trackEvent: den allmänna signalen
iOS SDK 1.0 introducerade trackEvent, arbetshästen för anpassade beteendesignaler:
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) }
}Tre regler som SDK:n upprätthåller, så designa för dem från början:
- Egenskapsvärden måste vara strängar, tal eller booleska värden. Arrayer, dictionaries och datum avvisas på klientsidan – platta ut dem innan du skickar.
- Händelsenamn och egenskapsnycklar får inte vara tomma. Återanropsfunktionen talar om för dig när valideringen misslyckas; logga det i debug-byggen.
- Återanropsfunktioner anländer på en bakgrundskö. Skicka till huvudtråden innan du rör vid UI.
Skicka profileId när användaren identifieras – det är det som gör att en kampanj kan följa en kund över olika enheter istället för att följa en enhet.
sendTriggerEvent: koppla klassiska utlösarkampanjer
För kampanjer som skapats i instrumentpanelens utlösarbyggare – varukorgsavhopp, webbplatsavhopp, anpassade resor – skickar appen sendTriggerEvent med kampanj- och händelsenamn som marknadsföraren konfigurerat, plus datatoken som notismallen kommer att rendera:
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
}data-token flödar in i notisens text – det är så "Din Waxed Canvas Jacket väntar" blir personlig utan att marknadsföraren behöver röra vid koden. Vi gick igenom hela återhämtningssekvensen för varukorgen i playboken för varukorgsavhopp i mobilappar; det här anropet är dess motor.
addAlert: prisuppdatering och åter i lager, inbyggt
De två vanligaste e-handelsutlösarna kräver inte ens anpassade kampanjer – de är förstklassiga SDK-medborgare. När en användare bevakar en produkt, registrera varningen:
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 hanterar bevakningen, matchningen och sändningen när priset sjunker eller lagret återkommer. Om du har läst vår guide för prisuppdateringsnotiser, är detta registreringen på app-sidan som gör att dessa kampanjer utlöses.
En händelsetaxonomi som skalar
Instrumenteringsskuld är verklig: sex månader in, ingen minns om händelsen är addToCart, cart_add eller CartUpdated. Välj konventioner från dag ett — snake_case-namn, objekt_åtgärdsordning, entalsnycklar — och täck kärnkommersen:
| Händelse | Nyckelegenskaper | Kampanjer den driver |
|---|---|---|
product_viewed | sku, kategori, pris | Bläddringsavbrott, personalisering |
product_saved | sku, pris | Prissänkning, åter i lager, återaktiveringskrokar |
cart_updated | cart_value, item_count, top_item | Varukorgsavhopp |
purchase_completed | order_value, item_count | Avslutningsvillkor, efterköp, mål |
search_performed | query, results_count | Återhämtning vid noll resultat, intresse segment |
onboarding_step | step, completed | Onboarding-seriens förgrening |
Sex händelser, instrumenterade en gång, driver onboarding-serien, kundvagnsåterhämtning, återaktiveringskrokar och alla segment ditt marknadsföringsteam kommer att be om i år.
Testa loopen innan du lämnar över den
Ställ in PushEngage.enableLogging = true i debug-byggen och se händelser lämna enheten. Skicka varje händelse från en testbyggnation, bekräfta att den anländer i instrumentpanelens händelsevy och skicka en ende-till-ende-testkampanj per utlösare. SDK-repot exempelappar inkluderar en fungerande utlösarskärm som du kan kopiera flödet från. Femton minuters verifiering här sparar undersökningen "varför avfyrades inte kampanjen" senare — vilket vanligtvis är ett stavfel i händelsenamnet på ena sidan av kontraktet.
Överlämningen: vad marknadsföring äger härifrån
När händelserna flödar är din del klar. Marknadsföring bygger utlösarregler, skriver texter, ställer in fördröjningar och avslutningsvillkor, A/B-testar varianter och kopplar målföljning för intäktsattribuering — allt i instrumentpanelen, allt utan en biljett. Publicera händelsetaxonomitabellen i ditt team-wiki som kontraktet mellan de två sidorna. Se sedan kö-förfrågningarna för "kan du skicka en push"-biljetter tyst gå till noll — vilket var poängen hela tiden. För strategin som dessa kampanjer bör följa, ge ditt marknadsföringsteam guiden för app push-marknadsföring.
