{"id":7908,"date":"2026-04-20T15:17:25","date_gmt":"2026-04-20T18:17:25","guid":{"rendered":"https:\/\/minders.io\/?p=7908"},"modified":"2026-04-20T16:06:34","modified_gmt":"2026-04-20T19:06:34","slug":"amplitude-persisted-properties-pt","status":"publish","type":"post","link":"https:\/\/minders.io\/pt-br\/amplitude-persisted-properties-pt\/","title":{"rendered":"O contexto que seus eventos perdem e como a Amplitude resolve"},"content":{"rendered":"
\n
\n

\"\" escrito por Victor Henri Vargas<\/strong><\/a> (Solutions Architect)<\/p>\n

 <\/p>\n

Voc\u00ea j\u00e1 passou por isso: um usu\u00e1rio clica em uma campanha, navega por tr\u00eas telas, adiciona ao carrinho e compra. A\u00ed algu\u00e9m pergunta de onde veio aquela compra \u2014 e o evento n\u00e3o tem a menor ideia.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Para times de produto e marketing, essa \u00e9 uma frustra\u00e7\u00e3o di\u00e1ria. Perguntas como “qual m\u00f3dulo da homepage gera mais receita por produto, n\u00e3o por sess\u00e3o?” ou “quais termos de busca interna realmente convertem, e com qual ticket m\u00e9dio?” surgem o tempo todo. E a instrumenta\u00e7\u00e3o tradicional de analytics torna essas respostas surpreendentemente dif\u00edceis de obter. A Amplitude lan\u00e7ou recentemente os Persisted Properties<\/strong> para mudar isso. Aqui est\u00e1 o que resolve, como funciona e onde se encaixa.<\/p>\n

\n
\n

O Problema: O Contexto Que Desaparece Entre os Eventos<\/strong><\/h2>\n<\/div>\n<\/div>\n
\n
\n

O cen\u00e1rio \u00e9 familiar: um usu\u00e1rio clica em uma campanha, navega por tr\u00eas telas, adiciona ao carrinho e compra. Na hora de analisar, o evento de compra n\u00e3o sabe de onde o usu\u00e1rio veio.<\/p>\n<\/div>\n<\/div>\n

\n
\n

Para a atribui\u00e7\u00e3o de aquisi\u00e7\u00e3o por campanha<\/strong>, isso \u00e9 historicamente resolvido por MMPs como Adjust ou AppsFlyer. Mas para o contexto in-app<\/strong> \u2014 qual p\u00e1gina de entrada, qual termo de busca, qual m\u00f3dulo de descoberta levou \u00e0 convers\u00e3o \u2014 n\u00e3o existe MMP. Essa responsabilidade recai inteiramente sobre o time de produto e analytics, seja por uma implementa\u00e7\u00e3o de propaga\u00e7\u00e3o customizada, um modelo de atribui\u00e7\u00e3o constru\u00eddo internamente, ou alguma combina\u00e7\u00e3o de user properties e l\u00f3gica de data lake que acumula complexidade sem que ningu\u00e9m tenha planejado isso.<\/p>\n

\"amplitude<\/p>\n<\/div>\n<\/div>\n

\n
\n

As solu\u00e7\u00f5es alternativas sempre tiveram um custo alto. Propagar contexto em todos os eventos<\/strong> acopla o tracking e exige manuten\u00e7\u00e3o constante. User properties<\/strong> gravam estado permanente no perfil do usu\u00e1rio para algo que deveria ser tempor\u00e1rio \u2014 gerando perfis inflados, l\u00f3gica dispersa de set vs. setOnce, e nenhuma forma de distinguir first-touch de last-touch.<\/p>\n

A Solu\u00e7\u00e3o: Persisted Properties<\/strong><\/h2>\n

Persisted Properties s\u00e3o propriedades de eventos que a Amplitude estende automaticamente para eventos subsequentes<\/strong>, com base em regras de aloca\u00e7\u00e3o e expira\u00e7\u00e3o \u2014 tudo computado no momento da consulta.<\/p>\n

\"amplitude<\/p>\n

Digamos que voc\u00ea instrumenta page_path<\/code> apenas na visualiza\u00e7\u00e3o de p\u00e1gina, mas configura uma Persisted Property chamada “P\u00e1gina de Entrada” com aloca\u00e7\u00e3o Original<\/strong> e expira\u00e7\u00e3o por sess\u00e3o<\/strong>. A partir da\u00ed, qualquer evento nessa sess\u00e3o \u2014 adicionar ao carrinho, compra, cadastro \u2014 carrega automaticamente o valor de P\u00e1gina de Entrada, mesmo que esses eventos nunca tenham sido instrumentados com essa propriedade.<\/p>\n

\"amplitude<\/p>\n

Nenhum dado \u00e9 alterado na ingest\u00e3o. Nenhuma user property \u00e9 criada. A Amplitude avalia as regras no momento da consulta e preenche o valor retroativamente.<\/p>\n

Persisted Properties vs. User Properties<\/strong><\/h2>\n

Essa \u00e9 a fonte de confus\u00e3o mais comum. Imagine um time tentando rastrear qual m\u00e9todo de descoberta levou a uma compra \u2014 eles usam uma user property, sobrescrevem a cada nova intera\u00e7\u00e3o e perdem todos os dados de first-touch. Esse \u00e9 exatamente o problema que as Persisted Properties resolvem.<\/p>\n

\"persistent<\/p>\n

User Properties descrevem quem \u00e9 o usu\u00e1rio. Persisted Properties descrevem o que levou o usu\u00e1rio a agir.<\/strong><\/p>\n

Modelos de Aloca\u00e7\u00e3o e Expira\u00e7\u00e3o<\/strong><\/h2>\n

Original (First Touch)<\/strong> captura o primeiro valor observado e o mant\u00e9m por toda a janela de expira\u00e7\u00e3o. Responde: de onde o usu\u00e1rio veio?<\/em><\/p>\n

Most Recent (Last Touch)<\/strong> reflete o \u00faltimo valor antes do evento de convers\u00e3o. Responde: qual foi o \u00faltimo est\u00edmulo antes da a\u00e7\u00e3o?<\/em><\/p>\n

Combinar ambos na mesma Data Table permite responder “de onde vieram” e “o que os convenceu” simultaneamente.<\/p>\n

Para expira\u00e7\u00e3o<\/strong>: baseada em sess\u00e3o funciona para contexto dentro de uma visita. Tempo personalizado<\/strong> \u2014 at\u00e9 30 dias \u2014 cobre contexto que precisa sobreviver entre sess\u00f5es, essencial para campanhas de longa considera\u00e7\u00e3o em fintechs, seguros ou B2B.<\/p>\n

Merchandising e Descoberta de Produtos<\/strong><\/h2>\n

Se h\u00e1 um cen\u00e1rio onde as Persisted Properties entregam valor desproporcional, \u00e9 na atribui\u00e7\u00e3o de produto por m\u00e9todo de descoberta<\/strong>.<\/p>\n

Um app com cat\u00e1logo tem m\u00faltiplos canais de descoberta \u2014 busca interna, recomenda\u00e7\u00f5es, m\u00f3dulos da homepage, deep links. Quando um usu\u00e1rio adiciona tr\u00eas produtos ao carrinho, cada um descoberto por um canal diferente, “qual canal gera mais receita?” \u00e9 quase imposs\u00edvel de responder da forma tradicional. Propagar discovery_method<\/code><\/span><\/strong> manualmente \u00e9 fr\u00e1gil. Uma user property sobrescreve com o \u00faltimo valor. A modelagem no data lake funciona, mas o ciclo de feedback \u00e9 lento demais para decis\u00f5es operacionais.<\/p>\n

\"amplitude<\/p>\n

Com Persisted Properties:<\/strong><\/p>\n

    \n
  1. Crie uma Persisted Property chamada “M\u00e9todo de Descoberta Mais Recente”, vinculada \u00e0 propriedade de evento discovery_me<\/strong>tho<\/strong>d<\/span><\/strong><\/span><\/code>, com aloca\u00e7\u00e3o Most Recent e expira\u00e7\u00e3o por sess\u00e3o.<\/li>\n
  2. Ative a atribui\u00e7\u00e3o por item<\/strong> vinculada a product.item_id<\/code><\/strong><\/span>.<\/li>\n
  3. Selecione eventos que contenham ambos (view_item_details<\/code>, <\/strong>add_to_cart<\/strong><\/code><\/span>).<\/li>\n<\/ol>\n

    Cada produto ret\u00e9m seu pr\u00f3prio<\/strong> M\u00e9todo de Descoberta. A receita \u00e9 atribu\u00edda de forma consistente com o modelo definido \u2014 last-touch por item. N\u00e3o resolve multi-touch, mas para decis\u00f5es operacionais de merchandising \u00e9 um avan\u00e7o significativo em rela\u00e7\u00e3o a nenhuma atribui\u00e7\u00e3o ou atribui\u00e7\u00e3o por sess\u00e3o.<\/p>\n

    Isso viabiliza: ROI por m\u00f3dulo da homepage, monetiza\u00e7\u00e3o de busca, testes A\/B de layouts de recomenda\u00e7\u00e3o com impacto em receita, e decis\u00f5es de cat\u00e1logo baseadas em canal de descoberta.<\/p>\n

    O Trade-off Que Vale Conhecer<\/strong><\/h2>\n

    Antes de migrar qualquer l\u00f3gica cr\u00edtica, aqui est\u00e1 a compara\u00e7\u00e3o honesta:<\/p>\n

    \"persistent<\/p>\n

    Para times com um data lake maduro, as Persisted Properties funcionam melhor como uma ferramenta explorat\u00f3ria<\/strong>. Para times que operam principalmente dentro da Amplitude, pode ser a solu\u00e7\u00e3o definitiva.<\/p>\n

    Um risco de governan\u00e7a que vale destacar: a l\u00f3gica de atribui\u00e7\u00e3o migra do c\u00f3digo para as Configura\u00e7\u00f5es de Dados da Amplitude. Sem um registro para cada Persisted Property \u2014 nome, origem, aloca\u00e7\u00e3o, expira\u00e7\u00e3o, respons\u00e1vel \u2014 defini\u00e7\u00f5es conflitantes v\u00e3o surgir.<\/p>\n

    Limita\u00e7\u00f5es Atuais<\/strong><\/h2>\n

    A funcionalidade est\u00e1 em beta, o que importa para a forma como voc\u00ea a adota:<\/p>\n