Consejos Financieros · Ueno Individuos
Dos tablas en el data lake que convierten 500 millones de eventos crudos por mes en algo consultable, y que dejan escritas las reglas de negocio que hacen falta para no volver a contar mal.
Los datos de la app viven en ueno_staging.ueno_amplitude_individuos: unos
500 millones de eventos por mes, con toda la información útil enterrada dentro de dos
columnas JSON. Consultarla directo desde un dashboard significa escanear decenas de
gigabytes en cada click.
Pero el problema real no es la velocidad. Es que las reglas para contar bien no son evidentes mirando los datos. Quien escriba una query sin conocerlas va a obtener un número que parece razonable y está mal.
Antes
~60 GB por consulta
Cada interacción con el dashboard escanea el JSON crudo. Lento y caro.
Ahora
~1M filas en memoria
Las tablas se cargan a SPICE y responden al instante, con las reglas ya aplicadas.
Ninguna de estas se deduce mirando la tabla cruda. Todas costaron encontrarlas:
casa_bolsa con
step_name = fondo_success. El flujo fondos_mutuos nunca existió.
investment_amount, user_payment_amount, insured_amount.
La pregunta que responde: ¿esta inversión ocurrió porque la persona leyó un consejo? No alcanza con que las dos cosas hayan pasado cerca en el tiempo. El modelo exige que se pueda trazar el camino.
| Paso | Evento | Cómo se identifica |
|---|---|---|
| 1. Apertura | BANNER_TAP | El clic en "Aprender más" del Consejo del díaflow = consejos_financieros |
| 2. Intención | BUTTON_TAP | El CTA de producto dentro del consejo abiertoflow = consejos_financieros ·
element_section = Consejo del díaevent_label ∈ Empezar a ahorrar | Empezar a invertir | Conocer coberturas
|
| 3. Conversión | FLOW_SUCCESS | El éxito del flujo del producto, con status = oky el step_name exacto de
suscripción |
El modelo anterior no tenía cota superior: bastaba con que el banner tap fuera anterior a la conversión. El efecto es que cualquiera que alguna vez tocó un consejo quedaba atribuido para siempre, y el grupo de comparación se vaciaba. Sin grupo de comparación no se puede afirmar que el canal aporte nada.
Sin ese paso, una persona que lee un consejo sobre ahorro y al día siguiente entra por su cuenta a colocar 50 millones en un CDA queda contada como conversión del canal. La lectura y la inversión pasaron cerca, pero no hay nada que las conecte.
Medido sobre la misma ventana, exigir el CTA cambia esto:
| Definición | Conversiones | Volumen |
|---|---|---|
| Sin exigir el CTA | 604 | 1,11 B PYG |
| Exigiendo el CTA del producto | 255 | 0,41 B PYG |
| Diferencia | −58 % | −63 % |
El hallazgo no es la caída, es dónde cae
Las conversiones bajan 58 % pero el volumen baja 63 %: los tickets grandes son desproporcionadamente los que no pasan por el CTA. Tiene sentido — una inversión grande no es un impulso que dispara un banner del home, es una decisión que ya venía tomada. Ahorro Programado, con mediana de conversión de 3 minutos, es el que mejor sobrevive.
El CTA tiene que ser del mismo producto que la conversión. Y el producto
no se deduce del texto del botón: dos productos comparten el label "Empezar a invertir" y
otros dos comparten "Empezar a ahorrar". Se identifica por element_destination,
que además no se rompe si mañana cambian el copy del consejo.
| Texto del botón | element_destination | Producto |
|---|---|---|
| Empezar a ahorrar | /savings-and-investments/scheduled-savings/information | Ahorro Programado |
| Empezar a ahorrar | /mkt/home/product/ahorro_a_plazo | Ahorro a Plazo |
| Empezar a invertir | /savings-and-investments/savings-deposit-certificate/information | CDA |
| Empezar a invertir | /funds/subscription/verification | Fondos Mutuos |
| Conocer coberturas | /mkt/home/product/SEGURO_VIDA | Seguro de Vida |
Si el FLOW_SUCCESS no aparece, el modelo usa el paso de
confirmación —el inmediatamente anterior— como señal de conversión, y lo marca
como inferido. El éxito medido siempre tiene prioridad: la confirmación solo entra si no
hay un éxito del mismo cliente y producto en las 2 horas siguientes.
No es una precaución teórica. En junio de 2026 el evento de éxito de CDA no se emitió en todo el mes: sin este mecanismo, se habrían perdido 2.208 conversiones y 99.460 millones de guaraníes. La contrapartida es que el paso de confirmación no distingue éxito de error, así que sobreestima alrededor de 1 %.
La excepción es Ahorro a Plazo, el único producto que emite un evento de error propio para el paso de confirmación. Ahí, alrededor del 28 % de las confirmaciones terminan en error, así que las conversiones inferidas de ese producto —y solo de ese— hay que leerlas con esa salvedad.
| Valor de origen | Qué significa |
|---|---|
| Atribuido a Consejo Financiero | Los tres pasos, en orden, con el CTA del producto correcto. El número oficial. |
| Banner sin CTA | Abrió un consejo y convirtió, pero nunca tocó el CTA. Es exactamente lo que el modelo anterior contaba de más |
| No atribuido a Consejos | Convirtió sin haber abierto ningún consejo. Vino de alguno de los otros 11 canales |
| Interesado sin conversión | Abrió un consejo y no convirtió. Es el denominador de la tasa |
Dos lecturas que conviene no hacer
"No atribuido" no quiere decir orgánico. El modelo de adquisición tiene 12 canales y el orgánico directo es apenas uno (~13,7 %). Esa gente vino en su mayoría de Banner Home Inversiones, Nav umarket o Banner Loyalty.
"Banner sin CTA" no es ruido descartable. Es la medida de cuánto cambió la definición. Mostrarla al lado del número oficial permite explicar la caída dentro del gráfico, en vez de tener que justificarla en una reunión.
dev.mas_money_atribucion_consolidada → dev.vw_mas_money_atribucion
| Grano | Una fila por conversión, más una fila por banner tap que no convirtió |
| Volumen | ~1.000.000 de filas |
| Período | 2026-03-01 a 2026-08-06 · particionada por mes |
| Actualización | Recarga completa · ~4 h de escaneo |
Por qué el denominador está adentro
La tabla incluye los banner taps que no convirtieron. Eso permite calcular la tasa de conversión sin cruzar contra ninguna otra fuente: numerador y denominador viven en el mismo dataset.
| Columna | Qué indica |
|---|---|
| id_cliente | Clave de usuario. Se usa para atribución y recurrencia |
| tipo_inversion | CDA · Ahorro Programado · Fondos Mutuos · Seguro de Vida · Ahorro a Plazo · Sin Conversión |
| origen | El campo clave. Atribuido a Consejo Financiero · Banner sin CTA · No atribuido a Consejos · Interesado sin conversión |
| origen_conversion | Si la conversión se midió (success) o se infirió del paso de confirmación
(confirmar_inferido) |
| converted | 1 / 0 — numerador y denominador del funnel |
| paso_especifico | El step_name crudo, para trazabilidad |
| fecha_evento | El campo de fecha a usar. Único poblado en todas las filas |
| success_time | Momento de la conversión. Nulo en filas de banner sin conversión |
| banner_time | Momento del clic en "Aprender más". Nulo si no vino de un consejo |
| cta_time | Momento del clic en el CTA de producto. Nulo si no hubo atribución estricta |
| hora_evento · dia_semana | Para análisis de estacionalidad intradía y semanal |
| titulo_banner | El consejo que originó la conversión. Permite ranking por contenido |
| genero_cliente · city | Segmentación demográfica disponible en el evento |
| monto_original · currency | Monto en la moneda en que se hizo la operación |
| investment_amount_pyg | Monto normalizado a guaraníes |
| investment_amount_usd | Monto normalizado a dólares, con la cotización del mes aplicada |
| investment_term | Plazo elegido (CDA y Ahorro Programado) |
| selected_day · selected_option | Día de débito y opción elegida en el flujo |
| tiempo_conversion_minutos | Del banner tap a la conversión. Alimenta el KPI de velocidad |
| tiempo_conversion_horas | Lo mismo, en horas |
| platform · version_name | iOS / Android y versión de la app. Permite detectar tracking roto por release |
| dias_atraso_ingesta | Diferencia entre cuándo ocurrió el evento y cuándo llegó al lake |
| mes | Partición · formato YYYY-MM |
| Columna | Qué indica |
|---|---|
| nro_inversion_usuario | Número de orden de esa inversión en la historia del cliente |
| is_recurrente | Si es la segunda inversión o posterior. Alimenta el KPI de recurrencia |
| rango_monto_pyg | Minorista · Medio · Alto · Gran Capital |
Van en la vista y no en la tabla porque son un ROW_NUMBER() sobre la
historia completa del cliente: no se pueden calcular dentro de un bloque de la carga
incremental.
dev.mas_money_impresiones → dev.vw_mas_money_apertura
| Grano | Una fila por día × consejo × género |
| Volumen | ~10.000 filas |
| Período | 2026-03-01 a 2026-08-06 |
| Actualización | Recarga completa · ~1,5 h de escaneo |
Existe por separado porque el grano es distinto: BANNER_VIEW son unos 25
millones de eventos cada 5 días. A nivel de fila reventaría cualquier tabla. Acá se
agrega la impresión y la apertura en la misma pasada de escaneo, así que
la tabla es autosuficiente: no hay que cruzarla con nada para calcular la tasa.
| Columna | Qué indica |
|---|---|
| fecha_evento | Día. La periodicidad que pide el documento de métricas es diaria |
| banner_title | El consejo — el mensaje principal |
| overline | La categoría del consejo ("ORGANIZÁ TUS METAS") |
| genero_cliente | Segmentación |
| impresiones | Veces que el consejo se renderizó en el home |
| usuarios_impresion | Usuarios únicos que lo vieron — el denominador |
| aperturas | Clics en "Aprender más" |
| usuarios_apertura | Usuarios únicos que lo abrieron — el numerador |
| tasa_apertura | Calculada en la vista, sobre usuarios y no sobre eventos |
Dos cuidados al usarla
La tasa no se promedia. Es un cociente: hay que recalcularla como
sum(usuarios_apertura) / sum(usuarios_impresion) en cada nivel de
agregación.
usuarios_impresion no es aditivo entre días. Un usuario
que ve el consejo el lunes y el martes cuenta dos veces al sumar. La tasa sigue siendo
válida — el sesgo afecta numerador y denominador por igual — pero la suma no se puede
leer como "usuarios únicos del mes".
La tasa va sobre usuarios porque así lo define el documento de métricas. Un usuario ve el consejo unas 5 veces por día, ya que se renderiza en cada carga del home: medida sobre eventos, la tasa da 5 veces más chica y significa otra cosa.
Dos datasets independientes en QuickSight, los dos en SPICE. No se cruzan entre sí: cada uno responde su bloque de preguntas.
Dataset 1
Todo lo que pasa después de que el usuario abre un consejo.
Dataset 2
Todo lo que pasa antes: cuánta gente lo ve y cuánta lo abre.
| Gráfico | Columnas que usa | Estado |
|---|---|---|
| ROI — monto total y promedio, como KPI | investment_amount_pyg / _usd | Listo |
| Distribución de montos por rangos | rango_monto_pyg | Listo |
| Velocidad de conversión | tiempo_conversion_minutos | Listo |
| Tasa de recurrencia | is_recurrente | Listo |
| Consejos vs resto (LTV relativo) | origen × investment_amount_pyg | Listo |
| Funnel y KPIs de cabecera | converted, origen | 2 pasos |
El funnel queda en dos pasos y no tres. El paso intermedio del
dashboard viejo era FLOW_START, y ese evento está en cero desde julio
2026: se eliminaron las pantallas de value proposition donde disparaba. Afecta a CDA,
Ahorro Programado y Seguro de Vida. Un funnel de tres pasos que se rompe a mitad de la
serie es peor que uno de dos que siempre cierra.
| Gráfico | Qué responde |
|---|---|
| Ranking de consejos por conversión y LTV | Qué contenido genera negocio, no solo clicks |
| Medido vs inferido por mes y producto | Si se puede confiar en el resto del dashboard |
| Salud del tracking por versión de app | Detectar un release que rompe la instrumentación |
| Heatmap hora × día de semana | Cuándo conviene mostrar cada consejo |
| Mix de productos | Hacia dónde empuja el canal |
| Segmentación por género y ciudad | A quién le está funcionando |
| Plazo y día de débito elegidos | Cómo configuran el producto los que entran por consejos |
| Brecha estricta vs laxa | Cuánto del número viejo era atribución de más |
| Gráfico | Qué responde |
|---|---|
| KPI de tasa de apertura | Cuán relevante es el contenido en general |
| Ranking de consejos por tasa | El más accionable. Hay casi el doble de tasa entre el mejor consejo y el peor |
| Serie temporal de la tasa | Si el interés se sostiene o se desgasta |
| Scatter alcance vs tasa | Separa los que llegan a mucha gente de los que convencen |
El gráfico que no estaba en el pedido
El panel de calidad del dato muestra qué proporción de las conversiones se infirió en vez de medirse. En un mes sano ronda el 1 %. En junio de 2026, CDA estuvo en 100 %: el evento de éxito no se emitió en todo el mes y nadie lo notó hasta tres meses después. Con este panel se ve el mismo día.
| Qué | Cómo |
|---|---|
| Todos los gráficos de la sección anterior | Construcción en QuickSight sobre los dos datasets |
| Valor económico del cross-selling | Cruzar nro_inversion_usuario > 1 con el monto de esas conversiones |
| Cohortes por mes de primera inversión | Agrupar por el mes de nro_inversion_usuario = 1 |
| Qué | Qué falta | Bloqueo |
|---|---|---|
| Retención y curva de supervivencia de Ahorro Programado | Una tercera tabla con los eventos de cancelación, que hoy se excluyen a propósito porque contaminaban el volumen | Desarrollo |
| La torta de los 12 canales de adquisición | Generalizar el pipeline a los otros 11 canales. La estructura ya está hecha; falta el mapeo | Desarrollo |
| Del consejo abierto al CTA tocado | Una columna más en la tabla de impresiones. Hoy tenemos impresión → apertura y CTA → conversión, falta el paso del medio | Desarrollo |
| Historia de Ahorro a Plazo anterior al 5 de agosto | La ingesta se habilitó el 2026-08-05 y no trae datos hacia atrás. El producto va a mostrar cero hasta esa fecha | Sin historia |
| Qué | Por qué |
|---|---|
| Score crediticio del usuario | No está en Amplitude. Requiere cruce contra la tabla de clientes |
| Edad y tipo de empresa | Misma razón. Solo tenemos género y ciudad |
| Funnel de 3 pasos de julio en adelante | El evento FLOW_START dejó de emitirse en los flujos afectados |
Dos definiciones que hay que cerrar
La ventana de atribución. El documento de métricas dice 1 día en un KPI y 2 días en la sección por producto. Está implementada en 2. Si termina siendo 1, hay que rehacer la carga.
Cómo se valoriza Seguro de Vida. Hoy se usa insured_amount,
que es suma asegurada y no prima. Sumarlo al volumen junto con inversiones mezcla dos
cosas distintas.