Ofertas Amazon

Se você chegou aqui esperando um texto que explique o que é personalização como se fosse 2012, pode sair. Este texto é para quem já sabe que mandar o mesmo e-mail para uma base inteira é o equivalente digital de gritar numa praça pública e torcer para alguém ouvir.

O Marketing Cloud Personalization, que até pouco tempo atrás atendia pelo nome de Interaction Studio (e antes disso pela marca Evergage, que a Salesforce adquiriu em 2020), é uma plataforma de personalização em tempo real, multicanal e orientada por inteligência artificial. Seu papel dentro do ecossistema Salesforce é claro: enquanto o Marketing Cloud Engagement cuida da orquestração de jornadas e disparo de comunicações em escala, o MCP entra com o componente de inteligência contextual e adaptativa. Na prática a diferença não é pequena. Imagine que você tem um cliente que visitou três vezes a página de um produto específico no seu e-commerce, abriu dois e-mails sobre aquela categoria e tem um histórico de compras que aponta afinidade com determinada faixa de preço. O Marketing Cloud Engagement pode disparar uma jornada baseada nessa lógica, mas o MCP vai além: ele decide, em tempo real, qual conteúdo mostrar para essa pessoa quando ela acessa o site agora, neste exato momento, considerando o contexto da sessão atual junto com tudo o que ele já sabe sobre ela.

A plataforma opera sobre um conceito central chamado unified customer profile, ou perfil unificado do cliente. Cada visitante, seja ele identificado ou anônimo, acumula um histórico de interações que alimenta esse perfil continuamente. Quando o visitante eventualmente se identifica (via login, preenchimento de formulário ou clique em um link de e-mail), o MCP faz o trabalho de costurar as sessões anônimas anteriores ao perfil conhecido. O resultado é uma visão longitudinal do comportamento daquela pessoa, que vai muito além do que qualquer cookie isolado poderia oferecer.

O começo

A configuração do MCP começa antes mesmo de qualquer linha de código. O primeiro passo estratégico é o desenho do blueprint, um documento que vai definir a arquitetura de toda a implementação: quais páginas serão mapeadas, quais atributos serão capturados, quais identidades serão utilizadas, quais são as Content Zones e quais são os casos de uso de personalização que o negócio quer endereçar. O JavaScript configurado em um Sitemap de Personalização fornece a funcionalidade que permite à Personalization identificar: perfis de usuário por meio de identidade conhecida ou ID de rastreamento anônimo; tipos de página que o usuário está navegando; atributos detalhados sobre o usuário e os objetos de negócio com os quais ele interage; Content Zones em cada tipo de página; e eventos de atividade do usuário que disparam eventos para a Personalization.

Um erro clássico em projetos mal planejados é confundir velocidade de entrega com qualidade de configuração. Sair implementando o beacon e configurando page types sem um blueprint sólido é a receita para ter um catálogo bagunçado, eventos mal capturados e, consequentemente, recomendações de IA que não fazem sentido nenhum. O beacon em si é o JavaScript que precisa estar presente em todas as páginas do site que você quer que o MCP monitore. Ele é a conexão entre o site e a plataforma, e sua implantação correta é pré-requisito para qualquer coisa que venha depois. Você pode iniciar a integração web de Personalização implantando o JavaScript web beacon em todas as páginas que deseja que a Personalização monitore.

Do ponto de vista da administração da plataforma, a configuração de datasets (conjuntos de dados que representam sites ou canais distintos dentro de uma mesma conta) é outra decisão crítica. Empresas com múltiplos sites, idiomas ou marcas precisam pensar com cuidado se vão usar datasets separados ou um único dataset com estratégia de localização. A Salesforce suporta localização de catálogo baseada em locale, o que permite que uma mesma conta sirva múltiplas línguas sem duplicar a infraestrutura de dados.

Os dados

A plataforma precisa de duas grandes categorias de informação para funcionar bem: dados de comportamento (o que o usuário fez) e dados de catálogo (os produtos, artigos, promoções e conteúdos que podem ser recomendados ou exibidos).

A ingestão de dados comportamentais acontece em tempo real, principalmente via SDK e via Event API. Cada vez que um usuário visualiza uma página de produto, adiciona um item ao carrinho, realiza uma compra ou executa qualquer ação mapeada no Sitemap, um evento é enviado ao MCP e passa a compor o perfil daquele visitante. Essa é a camada mais imediata e reativa da plataforma. Já os dados de catálogo podem ser ingeridos de duas formas: via Sitemap (em tempo real, conforme as páginas são navegadas) ou via ETL, que nada mais é do que o processo de envio de arquivos .csv estruturados para o SFTP da plataforma. Você deve usar o Sitemap para popular o catálogo principalmente em dois cenários: quando você precisa de atualizações de itens em tempo real (por exemplo, devido a mudanças rápidas de preço baseadas em demanda) ou quando não é possível agendar um arquivo .csv corretamente preparado para o SFTP do MCP.

As campanhas

Ofertas Amazon

O MCP suporta múltiplos tipos de campanha, cada um com uma arquitetura própria e casos de uso específicos. Entender as diferenças entre eles é essencial para escolher a abordagem certa em cada situação.

Campanhas Web

As campanhas web são o tipo mais comum e o primeiro que a maioria dos times explora. Elas permitem modificar o conteúdo de páginas do site em tempo real, exibindo banners, recomendações de produtos, mensagens personalizadas ou qualquer outro conteúdo configurado em templates dentro de Content Zones previamente mapeadas no Sitemap.

A lógica de renderização é direta: o SDK detecta que o usuário está em uma página específica, verifica quais campanhas estão ativas para aquela Content Zone, avalia se o usuário é elegível para cada uma delas com base nas regras de segmentação definidas, e então renderiza o conteúdo da campanha vencedora. Tudo isso acontece em milissegundos, de forma assíncrona, sem bloquear o carregamento da página.

Campanhas Server-Side

As campanhas server-side são uma camada mais sofisticada, voltada para times que querem personalizar experiências fora da renderização direta no browser. Nesse modelo, o cliente faz uma requisição à API de eventos do MCP e recebe de volta um payload de dados, que então usa para renderizar a experiência no lado do servidor ou em aplicações que não são browsers.

Em uma execução de campanha server-side, o cliente assume a responsabilidade de renderizar o payload de resposta retornado pela Personalization. Como a saída de uma campanha server-side é simplesmente um payload de dados, a criação de templates ou a segmentação de campanhas não requer seleção de Content Zone.

Campanhas Triggered

As campanhas triggered são acionadas por comportamentos específicos do usuário e se conectam diretamente com o Journey Builder do Marketing Cloud Engagement. Quando o MCP detecta que um usuário realizou uma ação de interesse (como abandonar um carrinho, visualizar um produto acima de um certo número de vezes ou atingir um determinado nível de engajamento), ele dispara um evento que entra numa jornada configurada no Journey Builder. Campanhas Triggered no Journey Builder podem segmentar vários eventos, incluindo Catalog Triggers.

Campanhas Mobile

O MCP também oferece suporte a personalização em canais mobile, tanto para Android quanto para iOS. Por meio do SDK mobile, é possível configurar campanhas que entregam experiências personalizadas dentro de aplicativos, aproveitando o mesmo perfil unificado do usuário que alimenta as campanhas web e e-mail. Isso é especialmente relevante para empresas com estratégia de app forte, como bancos digitais, varejistas com aplicativo próprio e empresas de streaming. Um usuário que demonstrou interesse em determinada categoria de produtos no site pode, ao abrir o app, receber uma experiência adaptada a esse comportamento, sem nenhuma ação manual da equipe de marketing.

A Inteligência

Se há um diferencial claro do MCP em relação a ferramentas de personalização mais simples, ele está na camada de IA. A plataforma tem dois módulos principais de inteligência artificial: Einstein Recipes e Einstein Decisions.

Einstein Recipes

O Einstein Recipes é o motor de recomendações do MCP. Ele permite criar algoritmos configuráveis que apresentam aos usuários produtos ou conteúdos personalizados, baseados em suas preferências, comportamentos e no comportamento coletivo da base.

A configuração de uma Recipe é feita em camadas. Primeiro, você define os ingredientes, que são as regras algorítmicas base. Ingredientes formam o algoritmo central no Einstein Recipes. Quando a Personalization cria recomendações para seus clientes, os ingredientes definem os parâmetros para considerar itens em seu catálogo. O Personalization então pondera esses itens de acordo com os comportamentos e afinidades de seus clientes.

Além dos ingredientes, as Recipes permitem configurar boosters (para dar mais peso a produtos que se alinham com as afinidades do usuário), exclusions (para remover itens que o usuário já comprou, por exemplo) e variations (para garantir diversidade nas recomendações, como não mostrar mais de dois produtos da mesma categoria numa mesma lista).

Como uma boa inteligência artificial as Recipes tornam se progressivamente mais precisas à medida que acumulam dados. Nos primeiros dias de uma implementação, com poucos eventos registrados, as recomendações tendem a ser mais genéricas. Com o tempo e o volume de interações crescendo, o algoritmo afina sua percepção das preferências individuais e as recomendações ganham relevância. Portanto, métricas de desempenho de Recipes precisam ser analisadas com uma janela de tempo adequada.

Einstein Decisions

O Einstein Decisions é uma camada diferente de IA, voltada não para recomendação de produtos, mas para decisão de promoções e ações de marketing. Enquanto o Einstein Recipes responde à pergunta “o que recomendar para este usuário?”, o Einstein Decisions responde “qual promoção, oferta ou ação devo apresentar agora para maximizar o resultado que me interessa?”.

O algoritmo do Einstein Decisions analisa a lista de promoções e ações disponíveis para cada cliente e, usando essa combinação de dados contextuais e comportamentais, combina as promoções ou ações certas para aquele cliente com base no resultado de negócio que você está otimizando. O modelo é baseado em técnicas de bandit (multi-armed bandit), o que significa que ele aprende continuamente qual conteúdo performa melhor para cada contexto, sem precisar de testes A/B manuais estruturados. A cada impressão e clique registrados, o modelo atualiza seu entendimento sobre quais promoções funcionam melhor para quais perfis de usuário, em quais dispositivos, provenientes de quais fontes de tráfego e em quais momentos do dia.

A segmentação

Ofertas Amazon

A segmentação no MCP vai muito além de filtros simples como “usuários que compraram nos últimos 30 dias”. A plataforma permite criar segmentos baseados em: sequências de comportamento (ex.: visualizou categoria A e depois categoria B sem comprar), afinidades calculadas pelo algoritmo (ex.: alta afinidade com produto de luxo), atributos vindos de sistemas externos via ETL, e combinações arbitrárias dessas condições com operadores lógicos AND/OR. Esses segmentos não servem apenas para segmentar campanhas. Eles também são a base para configurar goals (metas de conversão que o MCP rastreia) e para exportar audiências para o Marketing Cloud Engagement, onde podem ser usadas em jornadas de comunicação. Essa capacidade bidirecional de compartilhamento de audiências entre MCP e MCE é um dos pontos de integração mais poderosos do ecossistema.

Os insights

O módulo de analytics do MCP oferece uma visão consolidada do desempenho das campanhas, do comportamento dos segmentos e do impacto das personalizações nos objetivos de negócio. O dashboard principal apresenta métricas como receita atribuída, uplift gerado pelas campanhas, taxa de conversão por segmento e comparativos entre grupos de controle e grupos expostos às personalizações.

Uma funcionalidade relevante do módulo de analytics é o monitoramento de segmentos ao longo do tempo. É possível ver como um segmento específico evolui em tamanho, quais comportamentos estão sendo capturados e como ele performa em relação aos goals definidos. Isso é particularmente útil para equipes que usam o MCP como uma ferramenta de inteligência de audiência, não apenas como motor de entrega de campanhas. A análise de campanhas deveria, idealmente, exibir atribuição com a mesma lógica do Dashboard principal, mas com detalhamento por experiência. Esse nível de granularidade permitiria uma visão mais clara e detalhada da atribuição direta de campanhas específicas, possibilitando análise mais significativa e melhor tomada de decisão.

Projetos bem sucedidos com o MCP têm em comum uma característica: as equipes não usam o analytics da plataforma apenas para reportar resultados passados, mas como um loop de aprendizado contínuo. Os insights gerados alimentam decisões sobre novos segmentos a criar, novas campanhas a testar e ajustes nas Recipes e Decisions, gerando um ciclo virtuoso de melhoria das personalizações ao longo do tempo.

Depois de tudo isso, a reflexão final é simples: o MCP é uma ferramenta poderosa, mas ela só entrega o que promete quando existe uma estratégia clara por trás. Tecnologia sem estratégia é desperdício de licença. Personalização sem dados de qualidade é ilusão. IA sem volume de interações para aprender é algoritmo voando às cegas. O que separa os projetos de MCP que geram ROI real daqueles que viram monumento de consultoria é exatamente isso: times que entenderam que a plataforma é um meio, não um fim. O fim é entregar para cada pessoa, no canal certo, no momento certo, a experiência mais relevante possível. E isso requer tanto domínio técnico da ferramenta quanto clareza sobre o que o negócio realmente quer alcançar.

O Marketing Cloud Personalization é, no fundo, sobre uma coisa, tratar cada pessoa como indivíduo, não como membro de um segmento.

SAIBA MAIS: