Recomendação de produto boa começa muito antes do algoritmo: no feed, no contexto de página e nos eventos. Veja os componentes de uma implementação completa da Dynamic Yield.
Índice do artigo
- O que é a Dynamic Yield?
- Script ou Experience API?
- Os 5 componentes de uma implementação completa
- O endpoint Choose na prática
- Eventos: o que é obrigatório
- Cookies server-side: o detalhe que salva a identificação
- Clique e atribuição em campanhas via API
- Os erros que mais aparecem
- Perguntas frequentes sobre Dynamic Yield
A Dynamic Yield é conhecida pelo que o usuário vê: vitrines de “quem viu também comprou”, banners personalizados, testes. O que decide se isso funciona é invisível: o catálogo sincronizado, o tipo de página informado corretamente e o evento de compra chegando inteiro.
O que é a Dynamic Yield?
A Dynamic Yield é uma plataforma de personalização, recomendação de produtos e testes, gerenciada pelo console Experience OS. Ela usa comportamento de navegação, catálogo e eventos para montar experiências 1-a-1, segmentações e otimização de conteúdo.
Em uma frase: a Dynamic Yield decide o que mostrar para cada usuário; a sua implementação decide se ela tem dado suficiente para decidir bem.
Script ou Experience API?
Existem dois caminhos, com as mesmas capacidades de personalização e coleta:
- Script no site: coleta dados e renderiza campanhas criadas e publicadas inteiramente no Experience OS.
- Experience API (server-side): endpoints chamados pelo código do seu site; a resposta chega para a sua aplicação, que decide como renderizar.
A recomendação oficial é usar os dois, escolhendo script em algumas áreas e API em outras.
Por que usar API? Ela elimina flicker, entrega a mesma experiência em canais diferentes, não expõe a estratégia de campanhas no navegador e ajuda em privacidade. O custo é exigir desenvolvimento, e, se você usa CDN, garantir que a página pode entregar conteúdo dinâmico em vez de totalmente cacheado.
Os 5 componentes de uma implementação completa
- Seções: cada site ou app é uma section no Experience OS, o centro de toda a operação.
- Feed de produtos: o catálogo sincronizado por arquivo CSV ou API, com suporte a múltiplos idiomas. É ele que alimenta afinidade, recomendações e social proof.
- Contexto de página e pageviews: a Dynamic Yield precisa saber o tipo de cada página (home, categoria, produto, carrinho) para medir personalização e calcular recomendações. Via API, o pageview é reportado pelo Choose ou pelo endpoint de Pageviews.
- Renderização de campanhas: campanhas de script vivem no Experience OS; campanhas de API são criadas lá mas chamadas pelo endpoint Choose.
- Eventos: implementados por snippet no site ou pelo endpoint de Reporting Events. Ambos exigem desenvolvimento.
O endpoint Choose na prática
O Choose ativa uma ou mais campanhas pelo nome (o API Selector Name definido no console), resolve regras de targeting e alocação de grupos de teste e devolve a variação certa para o usuário. Normalmente ele é chamado dentro do pipeline de renderização da página.
O fluxo: identifique as campanhas que fazem parte do conteúdo da página, chame o Choose pedindo as variações e, se o script não roda naquela página, aproveite a mesma chamada para reportar o pageview.
Para quem quer o melhor dos dois mundos, há templates client-side para campanhas server-side: o Choose devolve um token, e o front busca o template (HTML, CSS e JS) correspondente e preenche as variáveis.
Eventos: o que é obrigatório
A Dynamic Yield oferece esquemas de eventos predefinidos, eventos customizados e até eventos disparados fora do site via pixel. Para e-commerce, Add to Cart e Purchase são obrigatórios: são usados como metas de otimização e alimentam o perfil de afinidade do usuário. Segundo a documentação, na grande maioria dos casos as chamadas de evento respondem entre 5 e 25 ms.
Uma dica de qualidade de dado: reportar eventos pelo servidor facilita evitar ruído de bots.
Boa prática: o evento de compra da Dynamic Yield tem que bater com o purchase do GA4. Se não bate, a otimização está aprendendo com dado errado.
Cookies server-side: o detalhe que salva a identificação
O script guarda informação do usuário em cookies e local storage. A orientação oficial é que o cookie de usuário seja definido pelo backend no seu domínio, para não sofrer com as políticas de expiração de cookies dos navegadores. É o mesmo princípio que motiva o GTM Server-Side: cookie first-party definido pelo servidor dura mais e identifica melhor.
Clique e atribuição em campanhas via API
Em campanhas via API, guarde os identificadores únicos que vêm na resposta do Choose. Quando o usuário clicar numa variação ou num produto recomendado, esses identificadores precisam ser devolvidos à Dynamic Yield. Sem isso, a plataforma não sabe qual recomendação gerou o clique, e o relatório de desempenho da campanha fica vazio.
Os erros que mais aparecem
- Feed de produtos desatualizado, recomendando item sem estoque.
- Tipo de página informado errado, confundindo o algoritmo.
- Evento de compra duplicado ou com valor diferente do GA4.
- Cookie de usuário definido só pelo navegador, perdendo identificação no Safari.
- Campanhas via API sem devolver os identificadores de clique.
Perguntas frequentes sobre Dynamic Yield
O que é a Dynamic Yield?
Uma plataforma de personalização, recomendação de produtos e testes, operada pelo console Experience OS.
Qual a diferença entre script e Experience API na Dynamic Yield?
O script coleta dados e renderiza campanhas no navegador; a Experience API é chamada pelo servidor e devolve a variação para a sua aplicação renderizar, sem flicker.
O que é o endpoint Choose?
O endpoint principal da Experience API: ativa campanhas pelo nome, resolve targeting e grupos de teste e devolve a variação do usuário.
Quais eventos são obrigatórios no e-commerce?
Add to Cart e Purchase.
Preciso de feed de produtos?
Sim. O feed alimenta afinidade, recomendações e mensagens de prova social.
Posso usar script e API juntos?
Sim, e é a recomendação oficial: script em algumas áreas, API em outras.