Tags de personalização compatíveis

Este artigo de referência abrange uma lista completa de tags de personalização Liquid compatíveis.

Resumo das tags suportadas

Por conveniência, é fornecido um resumo das tags de personalização compatíveis. Para obter mais detalhes sobre cada tipo de tag e práticas recomendadas, continue lendo.

Atribuições suportadas

As atribuições Campaign, Card e Canva são compatíveis apenas com seus modelos de envio de mensagens correspondentes (por exemplo, dispatch_id não está disponível em campanhas de mensagens no app).

Consulte este artigo de ajuda para saber mais sobre como algumas dessas atribuições diferem entre as origens na Braze.

Diferenças na canva e na tag da campanha

O comportamento das seguintes tags difere entre o Canva e as campanhas:

• dispatch_id O comportamento é diferente porque o Braze trata as etapas do Canva como eventos disparados, mesmo quando são “programadas” (exceto as etapas de entrada, que podem ser programadas). Para saber mais, consulte [Comportamento do Dispatch ID][50].
• O uso da tag {{campaign.${name}}} com o canvas exibirá o nome do componente do canvas. Ao usar essa tag com campanhas, ela exibirá o nome da campanha.

Informações do dispositivo usado mais recentemente

É possível modelar os seguintes atributos para o dispositivo mais recente do usuário em todas as plataformas. Se um usuário não tiver usado seu aplicativo (por exemplo, você importou o usuário via API REST), esses valores serão todos null.

Como há uma grande variedade de operadoras de dispositivos, nomes de modelos e sistemas operacionais, recomendamos que você teste minuciosamente qualquer Liquid que dependa condicionalmente de qualquer um desses valores. Esses valores serão null se não estiverem disponíveis em um dispositivo específico.

Informações sobre aplicativos direcionados

Para mensagens no app, você pode usar as seguintes atribuições do app no Liquid. Os valores são baseados na chave de API SDK que seus apps usam para solicitar o envio de mensagens:

Por exemplo, esse código Liquid abortará uma mensagem se os aplicativos solicitantes não forem uma das duas chaves de API na lista:

1
2
3
4
5
6
{% assign allowed_api_keys = 'sdk_api_key_1,sdk_api_key_2' | split: ',' %}
{% if allowed_api_keys contains {{app.${api_id}}} %}
User is in list of apps
{% else %}
{% abort_message("User not in list of apps") %}
{% endif %}

Informações sobre dispositivos direcionados

Para notificações por push e canais de envio de mensagens no app, é possível modelar os seguintes atributos para o dispositivo para o qual a mensagem está sendo enviada. Ou seja, uma notificação por push ou uma mensagem no app pode incluir atribuições do dispositivo no qual a mensagem está sendo lida. Note que essas atribuições não funcionarão para cartões de conteúdo.

Como há uma grande variedade de operadoras de dispositivos, nomes de modelos e sistemas operacionais, recomendamos que você teste minuciosamente qualquer lógica que dependa condicionalmente de qualquer um desses valores. Esses valores serão null se não estiverem disponíveis em um dispositivo específico.

Além disso, para notificações por push, é possível que o Braze não consiga discernir o dispositivo anexado à notificação por push em determinadas circunstâncias, como se o token por push tivesse sido importado por meio da API, resultando em valores null para essas mensagens.

Uso da lógica condicional em vez de um valor padrão

Em algumas circunstâncias, você pode optar por usar a lógica condicional em vez de definir um valor padrão. A lógica condicional lhe permite enviar mensagens diferentes com base no valor de um atributo personalizado. Além disso, você pode usar a lógica condicional para abortar o envio de mensagens para clientes com valores de atributos nulos ou em branco.

Caso de uso

Por exemplo, digamos que você esteja enviando uma notificação de saldo de recompensas aos clientes. Não há uma boa maneira de contabilizar clientes com saldos baixos e nulos usando valores padrão.

Nesse caso, há duas opções que podem funcionar melhor do que definir um valor padrão:

1. Abortar a mensagem para clientes com saldos baixos, nulos e em branco.

   1
   2
   3
   4
   5
   {% if {{custom_attribute.${balance}}} > 0 %}
   Your rewards balance is {{custom_attribute.${balance}}}
   {% else %}
   {% abort_message() %}
   {% endif %}
   

2. Envie uma mensagem completamente diferente para esses clientes, como, por exemplo, “Não é uma mensagem de marketing”:

   1
   2
   3
   4
   5
   {% if ${first_name} != blank and ${first_name} != null %}
   Hello {{${first_name} | default: 'there'}}, thanks for downloading!
   {% else %}
   Thanks for downloading!
   {% endif %}
   

Nesse caso de uso, um usuário com um nome em branco ou nulo receberá a mensagem “Thanks for downloading” (Obrigado por baixar). Você deve incluir um valor padrão para o primeiro nome para garantir que seu cliente não veja Liquid em caso de erro.

Tags de variáveis

Você pode usar a tag assign para criar uma variável no criador de mensagens. Recomendamos o uso de um nome exclusivo para sua variável. Se você criar uma variável com um nome semelhante ao das tags de personalização compatíveis (como language), isso poderá afetar sua lógica de envio de mensagens.

Depois de criar uma variável, você pode fazer referência a ela na lógica ou na mensagem de envio de mensagens. Essa tag é útil quando você deseja reformatar o conteúdo que é retornado pelo nosso recurso conteúdo conectado]. Você pode ler mais na documentação da Shopify sobre tags variáveis.

Caso de uso

Digamos que você permita que seus clientes troquem seus pontos de recompensas por prêmios depois de acumularem 100 pontos de recompensas. Portanto, você só quer enviar mensagens aos clientes que teriam um saldo de pontos maior ou igual a 100 se fizessem essa compra adicional:

1
2
3
4
5
6
{% assign new_points_balance = {{custom_attribute.${current_rewards_balance} | plus: 50}} %}
{% if new_points_balance >= 100 %}
Make a purchase to bring your rewards points to {{new_points_balance}} and cash in today!
{% else %}
{% abort_message('not enough points') %}
{% endif %}

Tags de iteração

As tags de iteração podem ser usadas para executar um bloco de código repetidamente. O caso de uso abaixo apresenta a tag for.

Caso de uso

Digamos que você esteja fazendo uma venda de tênis Nike e queira enviar mensagens aos clientes que manifestaram interesse na Nike. Você tem uma variedade de marcas de produtos visualizadas no perfil de cada cliente. Essa matriz pode conter até 25 marcas de produtos, mas você só deseja enviar mensagens aos clientes que visualizaram um produto da Nike como uma das 5 visualizações de produto mais recentes.

1
2
3
4
5
6
7
8
9
10
{% for items in {{custom_attribute.${Brands Viewed}}} limit:5 %}
{% if {{items}} contains 'Converse' %}
{% assign converse_viewer = true %}
{% endif %}
{% endfor %}
{% if converse_viewer == true %}
Sale on Converse!
{% else %}
{% abort_message() %}
{% endif %}

Nesse caso de uso, verificamos os cinco primeiros itens da matriz visualizada de marcas de tênis. Se um desses itens for inverso, criaremos a variável converse_viewer e a definiremos como verdadeira.

Em seguida, enviamos a mensagem de venda quando converse_viewer é verdadeiro. Caso contrário, a mensagem será cancelada.

Este é um exemplo simples de como as tags de iteração podem ser usadas no criador de mensagens do Braze. Você pode encontrar mais informações na documentação da Shopify sobre tags de iteração.

Tags de sintaxe

As tags de sintaxe podem ser usadas para controlar como o Liquid é renderizado. Você pode usar a tag echo para retornar uma expressão. É o mesmo que envolver uma expressão usando colchetes, exceto que você pode usar essa tag dentro de tags Liquid. Você também pode usar a tag liquid para ter um bloco de Liquid sem nenhum delimitador em cada tag. Cada tag deve estar em sua própria linha ao usar a tag liquid. Dê uma olhada na documentação da Shopify sobre tags de sintaxe para saber mais informações e exemplos.

Com [whitespace control][49], é possível remover espaços em branco ao redor das tags, o que ajuda a controlar ainda mais a aparência da saída do Liquid.

Códigos de status HTTP

Você pode utilizar o status HTTP de uma chamada conteúdo conectado salvando-o primeiro como uma variável local e, em seguida, usando a tecla __http_status_code__. Por exemplo:

1
2
3
4
{% connected_content https://example.com/api/endpoint :save connected %}
{% if connected.__http_status_code__ != 200 %}
{% abort_message('Connected Content returned a non-200 status code') %}
{% endif %}

Envio de mensagens com base no idioma, no fuso local mais recente e no fuso horário

Em algumas situações, talvez você queira enviar mensagens específicas para determinadas localizações. Por exemplo, o português brasileiro é tipicamente diferente do português europeu.

Caso de uso: Localize com base na localidade recente

Aqui está um caso de uso de como você pode usar a localização mais recente para localizar ainda mais uma mensagem internacionalizada.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{% if ${language} == 'en' %}
Message in English
{% elsif  ${language} == 'fr' %}
Message in French
{% elsif  ${language} == 'ja' %}
Message in Japanese
{% elsif  ${language} == 'ko' %}
Message in Korean
{% elsif  ${language} == 'ru' %}
Message in Russian
{% elsif ${most_recent_locale} == 'pt_BR' %}
Message in Brazilian Portuguese
{% elsif ${most_recent_locale} == 'pt_PT' %}
Message in European Portuguese
{% elsif  ${language} == 'pt' %}
Message in default Portuguese
{% else %}
Message in default language
{% endif %}

Nesse caso de uso, os clientes com uma localização mais recente de pt_BR receberão uma mensagem em português do Brasil, e os clientes com uma localização mais recente de pt_PT receberão uma mensagem em português da Europa. Os clientes que não atenderem às duas primeiras condições, mas tiverem seu idioma definido como português, receberão uma mensagem no tipo de idioma padrão que você desejar.

Caso de uso: Direcionamento de usuários por fuso horário

Também é possível direcionar os usuários por fuso horário. Por exemplo, envie uma mensagem se a pessoa estiver em EST e outra se estiver em PST. Para fazer isso, salve a hora atual em UTC e compare uma instrução if/else com a hora atual do usuário para enviar a mensagem certa para o fuso horário certo. Defina a campanha para ser enviada no fuso local do usuário, para que ele receba a campanha no momento certo.

Veja o caso de uso a seguir para saber como escrever uma mensagem que será enviada entre 14h e 15h e terá uma mensagem específica para cada fuso horário.

1
2
3
4
5
6
7
8
{% assign hour_in_utc = 'now' | date: '%H' | plus:0 %}
{% if hour_in_utc >= 19 && hour_in_utc < 20 %}
It is between 2:00:00 pm and 2:59:59 pm ET!
{% elsif hour_in_utc >= 22 && hour_in_utc < 23 %}
It is between 2:00:00 pm and 2:59:59 pm PT!
{% else %}
{% abort_message %}
{% endif %}

Daqui a [49]: https://shopify.github.io/liquid/basics/whitespace/ [50]: /docs/pt-br/help/help_articles/data/dispatch_id/ [75]: /docs/pt-br/api/objects_filters/trigger_properties_object/