escrito por Victor Henri Vargas (Solutions Architect)
Você já passou por isso: um usuário clica em uma campanha, navega por três telas, adiciona ao carrinho e compra. Aí alguém pergunta de onde veio aquela compra — e o evento não tem a menor ideia.
Para times de produto e marketing, essa é uma frustração diária. Perguntas como “qual módulo da homepage gera mais receita por produto, não por sessão?” ou “quais termos de busca interna realmente convertem, e com qual ticket médio?” surgem o tempo todo. E a instrumentação tradicional de analytics torna essas respostas surpreendentemente difíceis de obter. A Amplitude lançou recentemente os Persisted Properties para mudar isso. Aqui está o que resolve, como funciona e onde se encaixa.
O Problema: O Contexto Que Desaparece Entre os Eventos
O cenário é familiar: um usuário clica em uma campanha, navega por três telas, adiciona ao carrinho e compra. Na hora de analisar, o evento de compra não sabe de onde o usuário veio.
Para a atribuição de aquisição por campanha, isso é historicamente resolvido por MMPs como Adjust ou AppsFlyer. Mas para o contexto in-app — qual página de entrada, qual termo de busca, qual módulo de descoberta levou à conversão — não existe MMP. Essa responsabilidade recai inteiramente sobre o time de produto e analytics, seja por uma implementação de propagação customizada, um modelo de atribuição construído internamente, ou alguma combinação de user properties e lógica de data lake que acumula complexidade sem que ninguém tenha planejado isso.
As soluções alternativas sempre tiveram um custo alto. Propagar contexto em todos os eventos acopla o tracking e exige manutenção constante. User properties gravam estado permanente no perfil do usuário para algo que deveria ser temporário — gerando perfis inflados, lógica dispersa de set vs. setOnce, e nenhuma forma de distinguir first-touch de last-touch.
A Solução: Persisted Properties
Persisted Properties são propriedades de eventos que a Amplitude estende automaticamente para eventos subsequentes, com base em regras de alocação e expiração — tudo computado no momento da consulta.
Digamos que você instrumenta page_path apenas na visualização de página, mas configura uma Persisted Property chamada “Página de Entrada” com alocação Original e expiração por sessão. A partir daí, qualquer evento nessa sessão — adicionar ao carrinho, compra, cadastro — carrega automaticamente o valor de Página de Entrada, mesmo que esses eventos nunca tenham sido instrumentados com essa propriedade.
Nenhum dado é alterado na ingestão. Nenhuma user property é criada. A Amplitude avalia as regras no momento da consulta e preenche o valor retroativamente.
Persisted Properties vs. User Properties
Essa é a fonte de confusão mais comum. Imagine um time tentando rastrear qual método de descoberta levou a uma compra — eles usam uma user property, sobrescrevem a cada nova interação e perdem todos os dados de first-touch. Esse é exatamente o problema que as Persisted Properties resolvem.
User Properties descrevem quem é o usuário. Persisted Properties descrevem o que levou o usuário a agir.
Modelos de Alocação e Expiração
Original (First Touch) captura o primeiro valor observado e o mantém por toda a janela de expiração. Responde: de onde o usuário veio?
Most Recent (Last Touch) reflete o último valor antes do evento de conversão. Responde: qual foi o último estímulo antes da ação?
Combinar ambos na mesma Data Table permite responder “de onde vieram” e “o que os convenceu” simultaneamente.
Para expiração: baseada em sessão funciona para contexto dentro de uma visita. Tempo personalizado — até 30 dias — cobre contexto que precisa sobreviver entre sessões, essencial para campanhas de longa consideração em fintechs, seguros ou B2B.
Merchandising e Descoberta de Produtos
Se há um cenário onde as Persisted Properties entregam valor desproporcional, é na atribuição de produto por método de descoberta.
Um app com catálogo tem múltiplos canais de descoberta — busca interna, recomendações, módulos da homepage, deep links. Quando um usuário adiciona três produtos ao carrinho, cada um descoberto por um canal diferente, “qual canal gera mais receita?” é quase impossível de responder da forma tradicional. Propagar discovery_method manualmente é frágil. Uma user property sobrescreve com o último valor. A modelagem no data lake funciona, mas o ciclo de feedback é lento demais para decisões operacionais.
Com Persisted Properties:
- Crie uma Persisted Property chamada “Método de Descoberta Mais Recente”, vinculada à propriedade de evento
discovery_method, com alocação Most Recent e expiração por sessão. - Ative a atribuição por item vinculada a
product.item_id. - Selecione eventos que contenham ambos (
view_item_details,add_to_cart).
Cada produto retém seu próprio Método de Descoberta. A receita é atribuída de forma consistente com o modelo definido — last-touch por item. Não resolve multi-touch, mas para decisões operacionais de merchandising é um avanço significativo em relação a nenhuma atribuição ou atribuição por sessão.
Isso viabiliza: ROI por módulo da homepage, monetização de busca, testes A/B de layouts de recomendação com impacto em receita, e decisões de catálogo baseadas em canal de descoberta.
O Trade-off Que Vale Conhecer
Antes de migrar qualquer lógica crítica, aqui está a comparação honesta:
Para times com um data lake maduro, as Persisted Properties funcionam melhor como uma ferramenta exploratória. Para times que operam principalmente dentro da Amplitude, pode ser a solução definitiva.
Um risco de governança que vale destacar: a lógica de atribuição migra do código para as Configurações de Dados da Amplitude. Sem um registro para cada Persisted Property — nome, origem, alocação, expiração, responsável — definições conflitantes vão surgir.
Limitações Atuais
A funcionalidade está em beta, o que importa para a forma como você a adota:
- Apenas Data Tables — sem funis, coortes ou outros gráficos ainda
- Janela máxima de 30 dias
- Sem exportação — risco de divergência entre as métricas da Amplitude e do data warehouse
- Beta — não migre lógica crítica sem um fallback
Por Onde Começar
Configure Página de Entrada (Original, sessão) — se page_path já está sendo capturado, os resultados aparecem no mesmo dia. Se há um catálogo, teste Método de Descoberta com atribuição por item em seguida.
Mantenha as user properties existentes em paralelo. Alinhe com o time de data lake que essas métricas não serão reproduzíveis fora da Amplitude. A configuração é inteiramente nas Configurações de Dados da Amplitude — sem deploy, sem refatoração.
Você já enfrentou desafios semelhantes com atribuição in-app ou análise de descoberta de produtos? Adoraríamos saber como seu time aborda isso — vamos trocar ideias.
Referência: Persisted Properties — Amplitude Docs
