escrito por Victor Henri Vargas (Solutions Architect)
Ya lo viviste: un usuario hace clic en una campaña, navega por tres pantallas, agrega al carrito y compra. Entonces alguien pregunta de dónde vino esa compra y el evento no tiene idea.
Para los equipos de producto y marketing, esta es una frustración diaria. Preguntas como «¿qué módulo de la homepage genera más revenue por producto, no por sesión?» o «¿qué términos de búsqueda interna realmente convierten, y con qué ticket promedio?» se hacen constantemente. Y la instrumentación tradicional de analytics hace que sean sorprendentemente difíciles de responder. Amplitude lanzó recientemente los Persisted Properties para cambiar eso; te explicamos que resuelve, cómo funciona y dónde encaja.
El Problema: El Contexto Que Desaparece Entre los Eventos
Para la atribución de adquisición por campaña, esto se resuelve históricamente con MMPs como Adjust o AppsFlyer. Pero para el contexto in-app (qué página de entrada, qué término de búsqueda, qué módulo de descubrimiento llevó a la conversión) no existe un MMP. Esa responsabilidad recae completamente en el equipo de producto y analytics, ya sea a través de una implementación de propagación personalizada, un modelo de atribución construido internamente, o alguna combinación de user properties y lógica de data lake que acumula complejidad sin que nadie lo haya planificado.
Las soluciones alternativas siempre han tenido un costo alto. Propagar contexto en todos los eventos acopla el tracking y requiere mantenimiento constante. Las user properties escriben estado permanente en el perfil del usuario para algo que debería ser temporal, generando perfiles inflados, lógica dispersa de set vs. setOnce, y ninguna forma de distinguir first-touch de last-touch.
La Solución: Persisted Properties
Las Persisted Properties son propiedades de eventos que Amplitude extiende automáticamente a eventos posteriores, basándose en reglas de alocación y expiración, todo computado en el momento de la consulta.
Supongamos que instrumentas page_path solo en la vista de página, pero configuras una Persisted Property llamada «Página de Entrada» con alocación Original y expiración por sesión. A partir de ese momento, cualquier evento en esa sesión (agregar al carrito, compra, registro) lleva automáticamente el valor de Página de Entrada, aunque esos eventos nunca hayan sido instrumentados con esa propiedad.
Ningún dato se altera en la ingesta. No se crea ninguna user property. Amplitude evalúa las reglas en el momento de la consulta y completa el valor retroactivamente.
Persisted Properties vs. User Properties
Esta es la fuente de confusión más común. Imagina un equipo intentando rastrear qué método de descubrimiento llevó a una compra — usan una user property, la sobreescriben en cada nueva interacción y pierden todos los datos de first-touch. Ese es exactamente el problema que las Persisted Properties resuelven.
Las User Properties describen quién es el usuario. Las Persisted Properties describen qué llevó al usuario a actuar.
Modelos de alocación y expiración
Original (First Touch) captura el primer valor observado y lo mantiene durante toda la ventana de expiración. Responde: ¿de dónde vino el usuario?
Most Recent (Last Touch) refleja el último valor antes del evento de conversión. Responde: ¿cuál fue el último estímulo antes de la acción?
Combinar ambos en la misma Data Table permite responder «de dónde vinieron» y «qué los convenció» simultáneamente.
Para la expiración: basada en sesión funciona para contexto dentro de una visita. Tiempo personalizado — hasta 30 días — cubre contexto que necesita sobrevivir entre sesiones, esencial para campañas de larga consideración en fintech, seguros o B2B.
Merchandising y Descubrimiento de Productos
Si hay un escenario donde las Persisted Properties entregan valor desproporcionado, es en la atribución de producto por método de descubrimiento.
Una app con catálogo tiene múltiples canales de descubrimiento — búsqueda interna, recomendaciones, módulos de homepage, deep links. Cuando un usuario agrega tres productos al carrito, cada uno descubierto a través de un canal diferente, «¿qué canal genera más revenue?» es casi imposible de responder de la forma tradicional. Propagar discovery_method manualmente es frágil. Una user property sobreescribe con el último valor. La modelización en el data lake funciona, pero el ciclo de feedback es demasiado lento para decisiones operativas.
Con Persisted Properties:
- Crea una Persisted Property llamada «Método de Descubrimiento Más Reciente», vinculada a la propiedad de evento
discovery_method, con alocación Most Recent y expiración por sesión. - Activa la atribución por ítem vinculada a
product.item_id. - Selecciona los eventos que contengan ambos (
view_item_details,add_to_cart).
Cada producto retiene su propio Método de Descubrimiento. El revenue se atribuye de forma consistente con el modelo definido — last-touch por ítem. No resuelve el multi-touch, pero para decisiones operativas de merchandising es un avance significativo respecto a ninguna atribución o atribución por sesión.
Esto permite: ROI por módulo de homepage, monetización de búsqueda, A/B testing de layouts de recomendación con impacto en revenue, y decisiones de catálogo basadas en canal de descubrimiento.
El Trade-off que vale la pena conocer
Antes de migrar cualquier lógica crítica, aquí está la comparación honesta:
Para equipos con un data lake maduro, las Persisted Properties funcionan mejor como una herramienta exploratoria. Para equipos que operan principalmente dentro de Amplitude, puede ser la solución definitiva.
Un riesgo de gobernanza que vale destacar: la lógica de atribución se mueve del código a las Configuraciones de Datos de Amplitude. Sin un registro para cada Persisted Property — nombre, origen, alocación, expiración, responsable — surgirán definiciones conflictivas.
Limitaciones Actuales
La funcionalidad está en beta, lo que importa para cómo la adoptas:
- Solo Data Tables — sin funnels, cohortes u otros gráficos aún
- Ventana máxima de 30 días
- Sin exportación — riesgo de divergencia entre las métricas de Amplitude y el data warehouse
- Beta — no migres lógica crítica sin un fallback
Por Dónde Empezar
Configura Página de Entrada (Original, sesión) — si page_path ya está siendo capturado, los resultados aparecen el mismo día. Si hay un catálogo, prueba Método de Descubrimiento con atribución por ítem a continuación.
Mantén las user properties existentes en paralelo. Alinea con el equipo de data lake que estas métricas no serán reproducibles fuera de Amplitude. La configuración está completamente en las Configuraciones de Datos de Amplitude — sin deploy, sin refactoring.
¿Has enfrentado desafíos similares con atribución in-app o análisis de descubrimiento de productos? Nos encantaría saber cómo tu equipo aborda esto — intercambiemos ideas.
Referencia: Persisted Properties — Amplitude Docs
