Vi har fremlagt den strategiske begrundelse andre steder: blæst-æraen er forbi, og adfærdsudløste notifikationer er, hvad platforme belønner, og abonnenter tolererer. Denne guide er den anden halvdel – hvordan man rent faktisk udløser push-notifikationer fra app-begivenheder på iOS, fra instrumentering til marketingoverdragelse. Den er skrevet til udvikleren, der udfører ledningsføringen, med den kode, du vil levere, og de konventioner, der holder den vedligeholdelsesvenlig.
Arkitekturen i ét afsnit
Din app udløser navngivne begivenheder med typede egenskaber. PushEngage matcher disse begivenheder mod udløserregler konfigureret i instrumentbrættet, og kampagner sendes – øjeblikkeligt, med forsinkelse eller som en flertrinssekvens med exit-betingelser. Arbejdsdelingen er pointen: ingeniørvidenskab instrumenterer hver begivenhed én gang; marketing opretter, redigerer og fjerner kampagner mod disse begivenheder for evigt, uden en ny build. Din instrumentering er en API for dit marketingteam.
trackEvent: det generelle signal
Den iOS SDK 1.0 introducerede trackEvent, arbejdshesten for brugerdefinerede adfærdssignaler:
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'en håndhæver, så design efter dem på forhånd:
- Egenskabsværdier skal være strenge, tal eller boolske værdier. Arrays, ordbøger og datoer afvises på klientsiden – flad dem ud, før du sender.
- Begivenhedsnavne og egenskabsnøgler må ikke være tomme. Fuldførelseshåndteringen fortæller dig, hvornår validering mislykkes; log det i debug-builds.
- Fuldførelseshåndteringer ankommer på en baggrundskø. Send til hovedkøen, før du rører ved UI.
Send profileId, når brugeren er identificeret – det er det, der lader en kampagne følge en kunde på tværs af enheder i stedet for at følge en enhed.
sendTriggerEvent: tilslutning af klassiske udløserkampagner
For kampagner bygget i instrumentbrættets udløserbygger – forladt indkøbskurv, forladt browsing, brugerdefinerede rejser – udløser appen sendTriggerEvent med kampagne- og begivenhedsnavnene, som marketingmedarbejderen har konfigureret, plus datatokenene, som notifikationsskabelonen vil gengive:
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-tokenene flyder ind i notifikationsteksten – det er sådan, "Din Waxed Canvas Jacket venter" bliver personliggjort, uden at marketingmedarbejderen rører ved koden. Vi gennemgik hele indkøbskurv-genopretningssekvensen i playbooken for forladt indkøbskurv i mobilappen; dette kald er dens motor.
addAlert: prisaldrig og tilbage på lager, indbygget
De to mest efterspurgte e-handelsudløsere kræver ikke engang brugerdefinerede kampagner – de er førsteklasses SDK-borgere. Når en bruger ser et produkt, registrer alarmen:
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 håndterer overvågningen, matchingen og afsendelsen, når prisen falder, eller lageret vender tilbage. Hvis du har læst vores guide til prisaldrig-notifikationer, er dette app-siden registrering, der får disse kampagner til at blive udløst.
En hændelsestaksonomi, der skalerer
Instrumenteringsgæld er reel: seks måneder inde, ingen husker, om begivenheden er addToCart, cart_add eller CartUpdated. Vælg konventioner fra dag ét — snake_case navne, object_action rækkefølge, entals nøgleord — og dæk det centrale handelssæt:
| Begivenhed | Nøgleegenskaber | Kampagner den driver |
|---|---|---|
produkt_vist | sku, kategori, pris | Gennemse-afvisning, personalisering |
produkt_gemt | sku, pris | Prisfald, tilbage-på-lager, genaktiverings-kroge |
kurv_opdateret | kurv_værdi, antal_varer, top_vare | Forladt indkøbskurv |
køb_gennemført | ordre_værdi, antal_varer | Afslutningsbetingelser, efter-køb, mål |
søgning_udført | forespørgsel, antal_resultater | Nul-resultat-genopretning, interesse-segmenter |
onboarding_trin | trin, gennemført | Onboarding-serie-forgrening |
Seks begivenheder, instrumenteret én gang, driver onboarding-serien, indkøbsvogn-genopretning, genaktiverings-kroge og alle segmenter, dit marketingteam vil bede om i år.
Test løkken, før du afleverer den
Indstil PushEngage.enableLogging = true i debug-builds og se begivenheder forlade enheden. Afskyd hver begivenhed fra en test-build, bekræft, at den ankommer i dashboardets begivenheds-visning, og send én ende-til-ende testkampagne pr. trigger. SDK-repoets eksempel-apps inkluderer en fungerende trigger-skærm, du kan kopiere flowet fra. Femten minutters verifikation her sparer "hvorfor blev kampagnen ikke afskudt"-undersøgelsen senere — hvilket normalt er et forkert stavet begivenhedsnavn på den ene side af kontrakten.
Afleveringen: hvad marketing ejer herfra
Når begivenheder flyder, er din del færdig. Marketing opbygger trigger-regler, skriver tekst, indstiller forsinkelser og afslutningsbetingelser, A/B-tester varianter og vedhæfter målesporing for omsætnings-attribution — alt i dashboardet, alt uden en billet. Udgiv begivenheds-taksonomi-tabellen i din team-wiki som kontrakten mellem de to sider. Se derefter anmodnings-køen for "kan du sende en push"-billetter stille og roligt gå til nul — hvilket var pointen hele tiden. For den strategi, disse kampagner bør følge, giv dit marketingteam app push marketing-guiden.
