Documentatie

Dynamische velden van payload-arrays mislukken in AJO-pushmeldingen

Last update: Wed Jul 09 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

In Adobe Journey Optimizer (AJO), ontbreken de dupberichten om dynamische gebieden van lading serie-als "callerName" terug te geven - alhoewel de zelfde gegevens in E-mail en SMS werken. Velden kunnen leeg zijn of speciale tekens als hexadecimale codes weergeven. U kunt dit verhelpen door uw expressies te vereenvoudigen, de lading indien mogelijk af te vlakken en ervoor te zorgen dat de UTF-8-codering van begin tot eind behouden blijft.

Beschrijving description

Omgeving

Product: Adobe Journey Optimizer (AJO)
Kanalen: push (iOS via APNs, Android via FCM)

Probleem/symptomen

Dynamische personalisatie mislukt voor op arrays gebaseerde velden in pushmeldingen.

Stappen om te reproduceren

  1. Maak een reis in AJO die een pushmelding start.

  2. Geef een nuttige lading door waar het verpersoonlijkingsattribuut deel van een serie uitmaakt, bijvoorbeeld:

    code language-none 
    {
  "attribute_list_group": [
    {
      "name": "callerName",
      "value": "Bill Robert"
    }
  ]
}

  3. In de titel/het lichaam van het dupbericht, vorm een verpersoonlijkingsuitdrukking:

    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. Verzend het bericht.

Opmerking: op mobiele apparaten wordt het veld leeg weergegeven of worden hexadecimale codes voor speciale tekens weergegeven. Dezelfde expressie werkt correct in e-mail- en sms-kanalen.

Oorzaak

  • AJO's pushkanaalparser is strenger dan E-mail en SMS. De klasse verwacht platte tekenreekswaarden en heeft beperkte ondersteuning voor lussen, complexe expressies en niet-tekenreeksgegevenstypen in de titel of het hoofdgedeelte.
  • De sjablonen en hulplijnsyntaxis (Handlebars versus Nunjucks/Liquid) worden mogelijk niet in dezelfde mate ondersteund in de velden voor pushmeldingen.
  • Speciale tekens in de payload kunnen tijdens de serienummering als hexadecimale tekens (bijvoorbeeld \u2019 ) worden gecodeerd. Met pushservices en bepaalde apparaatapps worden deze reeksen mogelijk niet gedecodeerd en in plaats daarvan op dezelfde manier weergegeven.
  • Met pushservices zoals APNs en FCM wordt UTF-8-codering afgedwongen, worden besturingstekens geweigerd en kunnen berichten met onjuist gevormde of beschermde reeksen worden weergegeven, verwijderd of afgekeurd.
  • AJO ondersteunt alleen tekenreeksen met een juist type. Als een dynamische expressie wordt omgezet in een object, een onjuist gevormde tekenreeks of een array, kan het push-bericht op de achtergrond mislukken of worden afgekapt.

Resolutie resolution

  • Verwijder alle witruimte en nieuwe regels uit de lusexpressie. Gebruik een compacte versie als dit:#each context.journey.events.[ eventId] ._tmobile.decision_detail_group.attribute_list_group as |container|{%#if contains(container.name, "callerName")%}container.value{%/if%}/each Hierdoor is het probleem met Latijnse tekens in een huidige klantimplementatie opgelost.
  • Vlak, indien mogelijk, de nuttige last af door callerName naar een veld op hoofdniveau te verplaatsen. Gebruik vervolgens event.callerName rechtstreeks in de pushsjabloon.
  • Als afvlakken geen optie is, controleert u of de juiste arrayindex is geselecteerd en test u de voorvertoning van de aanpassing in AJO om de rendering te bevestigen.
  • Zorg ervoor dat UTF-8-codering in elk stadium behouden blijft, van het bronsysteem tot AJO-verwerking tot de pushservice. Voorkom dubbele codering of escape-teken voor speciale tekens.
  • Als speciale tekens nog steeds als hexadecimaal worden weergegeven, is dit waarschijnlijk een beperking van de rendering van het pushkanaal of apparaat. AJO biedt momenteel geen instelling om deze tekens op het apparaat te decoderen.

Gerelateerde lezing

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