Dynamiska fält från nyttolastmatriser misslyckas i AJO push-meddelanden
I Adobe Journey Optimizer (AJO) kan push-meddelanden inte återge dynamiska fält från nyttolastmatriser, som callerName", trots att samma data fungerar i e-post och SMS. Fält kan vara tomma eller visa specialtecken som hexadecimala koder. Du kan åtgärda detta genom att förenkla uttrycken, förenkla nyttolasten om det går och se till att UTF-8-kodningen bevaras från början till slut.
Beskrivning description
Miljö
Produkt: Adobe Journey Optimizer (AJO)
Kanaler: push (iOS via APN:er, Android via FCM)
Problem/symtom
Dynamisk personalisering misslyckas för matrisbaserade fält i push-meddelanden.
Steg som ska återskapas
-
Skapa en resa i AJO som utlöser ett push-meddelande.
-
Skicka en nyttolast där personaliseringsattributet ingår i en array, till exempel:
code language-none { "attribute_list_group": [ { "name": "callerName", "value": "Bill Robert" } ] } -
Konfigurera ett personaliseringsuttryck i titeln/brödtexten för push-meddelanden:
code language-none #each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container| {%#if contains(container.name, "callerName")%} container.value {%/if%} /each -
Skicka meddelandet.
Observera: På mobilen visas fältet tomt eller hexadecimala koder för specialtecken visas. Samma uttryck fungerar korrekt i e-post- och SMS-kanaler.
Orsak
- AJO push channel parser är striktare än Email och SMS. Den förväntar sig platta strängvärden och har begränsat stöd för slingor, komplexa uttryck och andra datatyper än strängar i titeln eller brödtexten.
- Mallen och hjälpsyntaxen (Handlebars vs. Nunjucks/Liquid) kanske inte stöds i lika hög grad i push-meddelandefält.
- Specialtecken i nyttolasten kan kodas som hexadecimala (t.ex.
\u2019) under serialiseringen. Push-tjänster och vissa enhetsappar kan inte avkoda dessa sekvenser utan visa dem i befintligt skick. - Push-tjänster som APN och FCM tillämpar UTF-8-kodning, avvisar kontrolltecken och kan felåterge, släppa eller avvisa meddelanden med felaktiga eller escape-sekvenser.
- AJO har bara stöd för korrekt skrivna strängar. Om ett dynamiskt uttryck löses till ett objekt, en felformaterad sträng eller en array, kan push-meddelandet misslyckas i tysthet eller kortas av.
Upplösning resolution
- Ta bort alla mellanrum och nya rader från slinguttrycket. Använd en kompakt version som den här:
#each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container|{%#if contains(container.name, "callerName")%}container.value{%/if%}/eachDetta löste problemet med latinska tecken i en aktuell kundimplementering. - Om det är möjligt bör du förenkla nyttolasten genom att flytta
callerNametill ett fält på den översta nivån. Använd sedanevent.callerNamedirekt i push-mallen. - Om förenkling inte är ett alternativ kontrollerar du att korrekt matrisindex är markerat och testar personaliseringsförhandsvisningen i AJO för att bekräfta återgivningen.
- Kontrollera att UTF-8-kodningen bevaras i alla faser - från källsystemet till AJO-bearbetningen till push-tjänsten. Undvik dubbelkodning och flykt från specialtecken.
- Om specialtecken fortfarande visas som hexadecimala är det troligtvis en begränsning av push-kanalen eller enhetsåtergivningen. AJO har för närvarande ingen inställning för att tvinga avkodning av dessa tecken på enheten.
Hantera specialtecken och Unicode i nyttolaster
När du skickar strängar i JWT-nyttolaster eller personaliseringsdata måste du alltid se till att koda eller undvika specialtecken och validera Unicode-indata. Felaktig kodning kan leda till återgivningsproblem, parsningsfel eller tomma fält i push-meddelanden.
Korrekt JSON-strängkodning och teckenborttagning
JSON kräver att vissa tecken escape-konverteras för att nyttolasten ska tolkas korrekt:
Exempel:
{
"message": "Hello\\nWorld! She said, \\\"Hi there!\\\"."
}
Escaping in Code
- JavaScript:
JSON.stringify("Hello\nWorld! She said, \"Hi there!\".") - Python:
json.dumps("Hello\nWorld! She said, \"Hi there!\".")
Unicode-hantering
JSON stöder Unicode via UTF-8-kodning. Tecken kan återges direkt eller med \uXXXX-notation:
{
"emoji": ":grinning:",
"currency": "€",
"chinese": "你好",
"heart": "\u2764"
}
Exempel på nyttolast med specialtecken:
{
"scopes": [ "read", "write", "special:áéíóú", "quote:\"test\""] ,
"user": "John\\nDoe"
}
Tecken som inte stöds eller är känsliga i JWT-moduler
Nyttolasterna måste vara giltiga JSON. Undvik:
- Unescape-konverterade dubbla citattecken eller nya rader utanför strängar
- Kontrolltecken (ASCII-koder 0-31, utom blanksteg)
- Icke-UTF-8 byte
Se RFC 8259 Section 7 för JSON-teckenkodningsregler.
Kända fel:
- Kommatecken, punkter och omvända snedstreck i fältnamn
- Oescape-konverterade citattecken bryter parsning
- Kontrollera tecken och ogiltiga Unicode-sekvenser
Best Practices for Unicode and Encoding
-
Ange alltid sidhuvud:
Content-Type: application/json; charset=UTF-8 -
Använd standardbibliotek för serialisering:
JSON.stringify()i JavaScriptjson.dumps()i Python
-
Validera nyttolaster med verktyg som JSONLint
-
Undvik dubbelflytning och dubbelserialisering
-
Testa med flerspråkiga tecken och känslolägesikoner för att säkerställa korrekt återgivning
Relaterad läsning
- Personalization i push-meddelanden i AJO Guide
- Användningsexempel för Personalization i AJO Guide