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 compatíveis

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

Atributos compatíveis

Os atributos de campanha, cartão e Canvas 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 alguns desses atributos diferem entre as origens na Braze.

Diferenças entre tags do Canvas e da campanha

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

• O comportamento de dispatch_id difere porque a Braze trata as etapas do canva como eventos disparados, mesmo quando estão “agendadas” (exceto para etapas de entrada, que podem ser agendadas). Para saber mais, consulte Comportamento do dispatch ID.
• 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

Você pode usar os seguintes atributos como modelo 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 ampla variedade de operadoras, 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 apps direcionados

Para mensagens no app, você pode usar os seguintes atributos do app no Liquid. Os valores são baseados na Chave da 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, mensagens no app e Banners, você pode usar os seguintes atributos como modelo para o dispositivo que recebe a mensagem. Uma notificação por push, mensagem no app ou Banner pode incluir atributos do dispositivo no qual o usuário lê a mensagem. Esses atributos não funcionam para Cartões de conteúdo ou e-mails. Para e-mails, as mensagens são renderizadas antes do envio, então o dispositivo no qual o usuário abre o e-mail é desconhecido nesse momento.

Como há uma ampla variedade de operadoras, 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 a Braze não consiga identificar o dispositivo associado à notificação por push em determinadas circunstâncias, como quando o token por push foi 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 lógica condicional em vez de definir um valor padrão. A lógica condicional permite enviar mensagens diferentes com base no valor de um atributo personalizado. Além disso, você pode usar lógica condicional para abortar mensagens para clientes com valores de atributo 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 lidar com 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. Enviar uma mensagem completamente diferente para esses clientes, como:

   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”. Você deve incluir um valor padrão para o 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 usar um nome exclusivo para sua variável. Se você criar uma variável com um nome semelhante às tags de personalização compatíveis (como language), isso pode afetar sua lógica de envio de mensagens.

Depois de criar uma variável, você pode referenciá-la na lógica ou no corpo da mensagem. Essa tag é útil quando você deseja reformatar o conteúdo retornado pelo nosso recurso de Conteúdo conectado. Você pode ler mais na documentação da Shopify sobre tags de 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. 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 promoção de tênis Nike e queira enviar mensagens aos clientes que demonstraram interesse na Nike. Você tem um array de marcas de produtos visualizadas no perfil de cada cliente. Esse array pode conter até 25 marcas de produtos, mas você só deseja enviar mensagens aos clientes que visualizaram um produto Nike entre as 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 do array de marcas de tênis visualizadas. Se um desses itens for Converse, criamos a variável converse_viewer e a definimos como verdadeira.

Em seguida, enviamos a mensagem de promoção 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 da 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 chaves, 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 mais informações e exemplos.

Com o controle de espaços em branco, você pode remover espaços em branco ao redor de suas tags, ajudando a controlar melhor a aparência da saída do Liquid.

Códigos de status HTTP

Você pode utilizar o status HTTP de uma chamada de Conteúdo conectado salvando-o primeiro como uma variável local e, em seguida, usando a chave __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 local mais recente e no fuso horário

Em algumas situações, você pode desejar 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 no local recente

Aqui está um caso de uso de como você pode usar o local 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 um local mais recente de pt_BR receberão uma mensagem em português do Brasil, e os clientes com um local 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 seu idioma definido como português, receberão uma mensagem no tipo de português padrão que você desejar.

Caso de uso: Direcionar 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 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 %}

Enviar mensagens com um número aleatório

A tag {% random %} retorna um número aleatório. Você pode usá-la para lógica no estilo de teste A/B, amostragem ou variação do conteúdo da mensagem.

Caso de uso: Enviar variantes aleatórias aos usuários

1
2
3
4
5
6
7
{% capture roll_str %}{% random %}{% endcapture %}
{% assign roll = roll_str | plus: 0 %}
{% if roll < 0.5 %}
Show variant A
{% else %}
Show variant B
{% endif %}