Mautic Audiences para Drupal: personalização construída sobre os segmentos que já manténs
A tua equipa de marketing já sabe quem são os VIP. Mantém o segmento no Mautic, envia-lhe uma campanha todos os meses, acrescenta e retira pessoas à medida que as encomendas e o comportamento mudam. Depois alguém pede um banner para VIP no site, e o site não sabe nada disso. Então "VIP" é construído uma segunda vez, como uma role do Drupal ou uma checkbox no utilizador: duas definições da mesma audiência, mantidas por duas equipas, a divergir desde a primeira semana.
O segundo problema chega com o primeiro. Personalizar no Drupal costuma significar variar a página por visitante, e uma página que varia por visitante é uma página que não pode ser servida a mais ninguém, portanto o banner que era para aumentar a conversão acaba a tornar o site mais lento para toda a gente.
Construímos e operamos marketing assente em Mautic para os nossos clientes de e-commerce, por isso fomos encontrando os dois problemas nos mesmos projetos. O Mautic Audiences é a nossa resposta, e está agora no drupal.org como software livre (GPL-2.0-or-later) para Drupal 10.3 e 11, coberto pela política de security advisories do Drupal. Lê os segmentos e as tags que já manténs no Mautic e transforma-os em primitivas nativas do Drupal: block visibility, Twig, tokens, JavaScript, Views, Search API e, desde a 1.1, um campo.
O que os editores conseguem fazer sem programador
Editas um bloco qualquer, desces até Visibility, escolhes Mautic segment, escreves vip. Gravas. É esta a configuração toda, e cobre a maior parte do que as pessoas pedem:
- Um banner para VIP que aparece no momento em que o Mautic mete alguém no segmento. Sem gravar nada no Drupal, sem limpar cache.
- Um hero de homepage por origem de tráfego: três blocos, um para
newsletter, outro parainstagram, outro parapaid-search, cada um preso ao seu segmento. - Esconder o que a pessoa já tem. O bloco de subscrição da newsletter desaparece para quem já tem a tag
subscriber. - Detalhes ligados a cupões para quem traz uma tag
coupon:*, disparados do lado do cliente para a própria página continuar cacheável no edge. - Campanhas cross-channel. O Mautic envia o email, e a página de Drupal onde o link aterra reconhece o segmento a que foi enviado. Uma definição de audiência, dois canais.
Os visitantes anónimos contam: quem traz o cookie de tracking do Mautic tem audiência sem ter feito login, que é o que permite a um link de campanha abrir uma página personalizada. Os editores confirmam o trabalho acrescentando ?ma_preview_segments=vip a qualquer URL, que mostra o site como o vê quem está nesse segmento.
Quem faz temas tem a mesma decisão numa linha, que traz consigo os cache contexts, e há um token para padrões de metatags e uma chamada de JavaScript para o que tiver de acontecer depois de a página ser servida:
{% if is_in_segment('vip') %}
<p>Portes grátis hoje, a tua vantagem VIP.</p>
{% endif %}
Conteúdo que sabe para quem é
O módulo começou por responder a "quem é este visitante?". A versão 1.1 acrescenta a outra metade, "para quem é este conteúdo?", num submódulo incluído.
Acrescentas o campo Mautic audience ao bundle que quiseres e os editores escolhem, a partir da lista real de nomes de segmentos, para quem é aquele conteúdo. Por omissão isso é apenas uma indicação de segmentação, que templates e listagens leem. Campo a campo, podes ligar Restrict viewing to the selected Mautic segments, e aí o conteúdo com um segmento escolhido passa a ser recusado a toda a gente fora dele. O conteúdo sem nada escolhido continua a ser para todos.
Um gate que só fecha a página não é um gate, por isso o submódulo traz também um filtro de Views que mantém as linhas a que cada visitante tem direito, e um processador do Search API que acrescenta a condição no momento da query em vez de deixar os itens fora do índice. O README do submódulo enumera o que nada disto cobre, exports, feeds, código próprio que carrega entidades sem verificar acesso, porque uma promessa de restrição com buracos é pior do que promessa nenhuma.
A parte interessante é o que ele se recusa a expor
Nomes de segmentos e tags são inteligência de negócio: cancelled-subscription, risk:churn-90d, coupon:VIP-50. Manda-os para o browser e publicaste a forma como categorizas os teus clientes, e às vezes um código de cupão válido, a quem tiver as DevTools abertas.
Por isso a API do lado do cliente responde a perguntas em vez de listar factos. Diz-te se este visitante está num segmento que tu nomeies; não te diz que segmentos existem nem em quais é que ele está. O endpoint que devolve mesmo uma lista começa vazio e devolve só o que um editor autorizou. O tipo de campo não tem formatter nenhum, e ler os valores exige uma permissão administrativa, o que cobre JSON:API, REST e Views por igual.
Fica fora do caminho de render
As audiências são lidas de armazenamento local em cada render, nunca da API do Mautic, por isso um Mautic lento nunca fica à frente de uma página, e uma indisponibilidade degrada para audiência vazia em vez de dar erro. Os cache contexts são indexados pela audiência resolvida e não pelo visitante, por isso duas pessoas nos mesmos segmentos partilham a mesma entrada de cache e uma página com dois blocos segmentados tem quatro variantes, não uma por visitante. Personalizar para anónimos custa-te mesmo a Internal Page Cache do Drupal nas páginas onde o fazes, e o docs/cdn.md trata disso de frente.
Instalar
composer require drupal/mautic_audiences
drush en mautic_audiences
Precisa do Advanced Mautic Integration para a ligação à API, de uma instância de Mautic com credenciais de API, e de PHP 8.2 ou superior. Um submódulo incluído liga o Klaro ao resolver, para que quem não deu consentimento resolva para audiência vazia sem escrever código.
A página do projeto, a issue queue e a documentação estão em drupal.org/project/mautic_audiences. Se usas Drupal Commerce, é o Commerce Mautic Connect que empurra para o Mautic os carrinhos abandonados, as métricas de cliente e as tags de cupão que este módulo depois lê. Issues e merge requests são muito bem-vindos.