{"id":7916,"date":"2026-04-20T15:17:25","date_gmt":"2026-04-20T18:17:25","guid":{"rendered":"https:\/\/minders.io\/?p=7916"},"modified":"2026-04-20T16:06:03","modified_gmt":"2026-04-20T19:06:03","slug":"amplitude-persisted-properties-es","status":"publish","type":"post","link":"https:\/\/minders.io\/es\/amplitude-persisted-properties-es\/","title":{"rendered":"El contexto que pierden tus eventos y c\u00f3mo Amplitude lo resuelve"},"content":{"rendered":"

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

Ya lo viviste: un usuario hace clic en una campa\u00f1a, navega por tres pantallas, agrega al carrito y compra. Entonces alguien pregunta de d\u00f3nde vino esa compra y el evento no tiene idea.<\/p>\n

Para los equipos de producto y marketing, esta es una frustraci\u00f3n diaria. Preguntas como \u00ab\u00bfqu\u00e9 m\u00f3dulo de la homepage genera m\u00e1s revenue por producto, no por sesi\u00f3n?\u00bb o \u00ab\u00bfqu\u00e9 t\u00e9rminos de b\u00fasqueda interna realmente convierten, y con qu\u00e9 ticket promedio?\u00bb se hacen constantemente. Y la instrumentaci\u00f3n tradicional de analytics hace que sean sorprendentemente dif\u00edciles de responder. Amplitude lanz\u00f3 recientemente los Persisted Properties<\/strong> para cambiar eso; te explicamos que resuelve, c\u00f3mo funciona y d\u00f3nde encaja.<\/p>\n

El Problema: El Contexto Que Desaparece Entre los Eventos<\/strong><\/h2>\n

Para la atribuci\u00f3n de adquisici\u00f3n por campa\u00f1a<\/strong>, esto se resuelve hist\u00f3ricamente con MMPs como Adjust o AppsFlyer. Pero para el contexto in-app<\/strong> (qu\u00e9 p\u00e1gina de entrada, qu\u00e9 t\u00e9rmino de b\u00fasqueda, qu\u00e9 m\u00f3dulo de descubrimiento llev\u00f3 a la conversi\u00f3n) no existe un MMP. Esa responsabilidad recae completamente en el equipo de producto y analytics, ya sea a trav\u00e9s de una implementaci\u00f3n de propagaci\u00f3n personalizada, un modelo de atribuci\u00f3n construido internamente, o alguna combinaci\u00f3n de user properties y l\u00f3gica de data lake que acumula complejidad sin que nadie lo haya planificado.<\/p>\n

\"amplitude<\/p>\n

Las soluciones alternativas siempre han tenido un costo alto. Propagar contexto en todos los eventos<\/strong> acopla el tracking y requiere mantenimiento constante. Las user properties<\/strong> escriben estado permanente en el perfil del usuario para algo que deber\u00eda ser temporal, generando perfiles inflados, l\u00f3gica dispersa de set vs. setOnce, y ninguna forma de distinguir first-touch de last-touch.<\/p>\n

La Soluci\u00f3n: Persisted Properties<\/strong><\/h2>\n

Las Persisted Properties son propiedades de eventos que Amplitude extiende autom\u00e1ticamente a eventos posteriores<\/strong>, bas\u00e1ndose en reglas de alocaci\u00f3n y expiraci\u00f3n, todo computado en el momento de la consulta.<\/p>\n

\"amplitude<\/p>\n

Supongamos que instrumentas page_path<\/code><\/strong><\/span> solo en la vista de p\u00e1gina, pero configuras una Persisted Property llamada \u00abP\u00e1gina de Entrada\u00bb con alocaci\u00f3n Original<\/strong> y expiraci\u00f3n por sesi\u00f3n<\/strong>. A partir de ese momento, cualquier evento en esa sesi\u00f3n (agregar al carrito, compra, registro) lleva autom\u00e1ticamente el valor de P\u00e1gina de Entrada, aunque esos eventos nunca hayan sido instrumentados con esa propiedad.<\/p>\n

\"amplitude<\/p>\n

Ning\u00fan dato se altera en la ingesta. No se crea ninguna user property. Amplitude eval\u00faa las reglas en el momento de la consulta y completa el valor retroactivamente.<\/p>\n

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

Esta es la fuente de confusi\u00f3n m\u00e1s com\u00fan. Imagina un equipo intentando rastrear qu\u00e9 m\u00e9todo de descubrimiento llev\u00f3 a una compra \u2014 usan una user property, la sobreescriben en cada nueva interacci\u00f3n y pierden todos los datos de first-touch. Ese es exactamente el problema que las Persisted Properties resuelven.<\/p>\n

\"amplitude<\/p>\n

Las User Properties describen qui\u00e9n es el usuario. Las Persisted Properties describen qu\u00e9 llev\u00f3 al usuario a actuar.<\/strong><\/p>\n

Modelos de alocaci\u00f3n y expiraci\u00f3n<\/strong><\/h2>\n

Original (First Touch)<\/strong> captura el primer valor observado y lo mantiene durante toda la ventana de expiraci\u00f3n. Responde: \u00bfde d\u00f3nde vino el usuario?<\/em><\/p>\n

Most Recent (Last Touch)<\/strong> refleja el \u00faltimo valor antes del evento de conversi\u00f3n. Responde: \u00bfcu\u00e1l fue el \u00faltimo est\u00edmulo antes de la acci\u00f3n?<\/em><\/p>\n

Combinar ambos en la misma Data Table permite responder \u00abde d\u00f3nde vinieron\u00bb y \u00abqu\u00e9 los convenci\u00f3\u00bb simult\u00e1neamente.<\/p>\n

Para la expiraci\u00f3n<\/strong>: basada en sesi\u00f3n funciona para contexto dentro de una visita. Tiempo personalizado<\/strong> \u2014 hasta 30 d\u00edas \u2014 cubre contexto que necesita sobrevivir entre sesiones, esencial para campa\u00f1as de larga consideraci\u00f3n en fintech, seguros o B2B.<\/p>\n

Merchandising y Descubrimiento de Productos<\/strong><\/h2>\n

Si hay un escenario donde las Persisted Properties entregan valor desproporcionado, es en la atribuci\u00f3n de producto por m\u00e9todo de descubrimiento<\/strong>.<\/p>\n

Una app con cat\u00e1logo tiene m\u00faltiples canales de descubrimiento \u2014 b\u00fasqueda interna, recomendaciones, m\u00f3dulos de homepage, deep links. Cuando un usuario agrega tres productos al carrito, cada uno descubierto a trav\u00e9s de un canal diferente, \u00ab\u00bfqu\u00e9 canal genera m\u00e1s revenue?\u00bb es casi imposible de responder de la forma tradicional. Propagar discovery_method<\/code> manualmente es fr\u00e1gil. Una user property sobreescribe con el \u00faltimo valor. La modelizaci\u00f3n en el data lake funciona, pero el ciclo de feedback es demasiado lento para decisiones operativas.<\/p>\n

\"amplitude<\/p>\n

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

    \n
  1. Crea una Persisted Property llamada \u00abM\u00e9todo de Descubrimiento M\u00e1s Reciente\u00bb, vinculada a la propiedad de evento discovery_method<\/code><\/strong><\/span>, con alocaci\u00f3n Most Recent y expiraci\u00f3n por sesi\u00f3n.<\/li>\n
  2. Activa la atribuci\u00f3n por \u00edtem<\/strong> vinculada a product.item_id<\/strong><\/span><\/code>.<\/li>\n
  3. Selecciona los eventos que contengan ambos (view_item_details<\/code>, add_to_cart<\/code><\/span><\/strong>).<\/li>\n<\/ol>\n

    Cada producto retiene su propio<\/strong> M\u00e9todo de Descubrimiento. El revenue se atribuye de forma consistente con el modelo definido \u2014 last-touch por \u00edtem. No resuelve el multi-touch, pero para decisiones operativas de merchandising es un avance significativo respecto a ninguna atribuci\u00f3n o atribuci\u00f3n por sesi\u00f3n.<\/p>\n

    Esto permite: ROI por m\u00f3dulo de homepage, monetizaci\u00f3n de b\u00fasqueda, A\/B testing de layouts de recomendaci\u00f3n con impacto en revenue, y decisiones de cat\u00e1logo basadas en canal de descubrimiento.<\/p>\n

    El Trade-off que vale la pena conocer<\/strong><\/h2>\n

    Antes de migrar cualquier l\u00f3gica cr\u00edtica, aqu\u00ed est\u00e1 la comparaci\u00f3n honesta:<\/p>\n

    \"amplitude<\/p>\n

    Para equipos con un data lake maduro, las Persisted Properties funcionan mejor como una herramienta exploratoria<\/strong>. Para equipos que operan principalmente dentro de Amplitude, puede ser la soluci\u00f3n definitiva.<\/p>\n

    Un riesgo de gobernanza que vale destacar: la l\u00f3gica de atribuci\u00f3n se mueve del c\u00f3digo a las Configuraciones de Datos de Amplitude. Sin un registro para cada Persisted Property \u2014 nombre, origen, alocaci\u00f3n, expiraci\u00f3n, responsable \u2014 surgir\u00e1n definiciones conflictivas.<\/p>\n

    Limitaciones Actuales<\/strong><\/h2>\n

    La funcionalidad est\u00e1 en beta, lo que importa para c\u00f3mo la adoptas:<\/p>\n