Tags de personalização compatíveis

Este artigo de referência abrange uma lista completa das tags de personalização do 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.

Atributos suportados

Os atributos Campaign, Card e Canvas são compatíveis apenas com seus modelos de mensagens correspondentes (por exemplo, dispatch_id não está disponível em campanhas de mensagens in-app).

Consulte este artigo de ajuda para saber mais sobre como alguns desses atributos diferem entre as origens no Braze.

Diferenças entre o Canvas e a tag da campanha

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

• dispatch_id O comportamento é diferente porque o Braze trata as etapas do Canvas como eventos acionados, mesmo quando são “programadas” (exceto as etapas de entrada, que podem ser programadas). Para saber mais, consulte Comportamento da ID de despacho.
• 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 sobre o 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 por meio da API REST), todos esses valores serão 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 determinado dispositivo.

Informações sobre aplicativos direcionados

Para mensagens in-app, você pode usar os seguintes atributos de aplicativo no Liquid. Os valores são baseados na chave de API do SDK que seus aplicativos usam para solicitar 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 mensagens in-app, você pode criar modelos nos seguintes atributos para o dispositivo para o qual a mensagem está sendo enviada. Ou seja, uma notificação por push ou uma mensagem no aplicativo pode incluir atributos do dispositivo no qual a mensagem está sendo lida. Observe que esses atributos 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 determinado dispositivo.

Além disso, no caso das 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 sendo null para essas mensagens.

!Exemplo de uso de um valor padrão de “there” ao usar uma variável de primeiro nome em uma mensagem push.

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 permite que você envie mensagens diferentes com base no valor de um atributo personalizado. Além disso, você pode usar a lógica condicional para abortar 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 primeiro nome em branco ou nulo receberá a mensagem “Thanks for downloading” (Obrigado pelo download). Você deve incluir um valor padrão para o primeiro nome para garantir que seu cliente não veja o Liquid em caso de erro.

Tags de variáveis

Você pode usar a tag assign para criar uma variável no compositor 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 mensagens.

Depois de criar uma variável, você pode fazer referência a ela em sua lógica de mensagens ou mensagem. Essa tag é útil quando você deseja reformatar o conteúdo que é retornado pelo nosso recurso Connected Content ]. 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 recompensa por prêmios depois de acumularem 100 pontos de recompensa. 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 cinco 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 de marcas de tênis visualizadas. 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 compositor 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. Isso é 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. Confira a documentação da Shopify sobre tags de sintaxe para obter mais informações e exemplos.

Com o controle de espaço em branco, é 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 Connected Content 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, na localidade mais recente e no fuso horário

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

Caso de uso: Localizar com base na localidade recente

Aqui está um caso de uso de como você pode usar a localidade 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 localidade mais recente de pt_BR receberão uma mensagem em português do Brasil, e os clientes com uma localidade mais recente de pt_PT receberão uma mensagem em português europeu. Os clientes que não atenderem às duas primeiras condições, mas tiverem o idioma definido como português, receberão uma mensagem no tipo de idioma português padrão que você desejar.

Caso de uso: Usuários-alvo por fuso horário

Você também pode segmentar 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. Você deve configurar a campanha para ser enviada no fuso horário 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 %}