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

  1. Skapa en resa i AJO som utlöser ett push-meddelande.

  2. Skicka en nyttolast där personaliseringsattributet ingår i en array, till exempel:

    code language-none
    {
      "attribute_list_group": [
        {
          "name": "callerName",
          "value": "Bill Robert"
        }
      ]
    }
    
  3. 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
    
  4. 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%}/each Detta löste problemet med latinska tecken i en aktuell kundimplementering.
  • Om det är möjligt bör du förenkla nyttolasten genom att flytta callerName till ett fält på den översta nivån. Använd sedan event.callerName direkt 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:

Tecken
Escape-sekvens
Backsteg
\b
Formulärfeed
\f
Newline
\n
Radretur
\r
Tabb
\t
Dubbelt citattecken
\"
Backslash
\\\

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 JavaScript
    • json.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

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f