PostHog en una fintech mobile: qué se puede grabar

Querés saber por qué la gente abandona el onboarding en el paso tres, justo antes de terminar de cargar el documento. Para eso hace falta ver la sesión real, no solo un embudo agregado que da el número pero no la causa. El problema es que esa misma pantalla puede tener una foto de DNI, un CBU o un saldo en pantalla, y "grabar todo" no es una opción en una fintech, es un incidente de seguridad esperando a que alguien lo reporte. La pregunta que importa no es qué puede medir PostHog, sino qué puede grabar sin capturar lo que no debería, y qué de todo eso tiene paridad en mobile, porque no todo la tiene.

Session replay funciona en mobile, pero no es lo mismo en todas partes

Session Replay de PostHog es general availability confirmado en Android, iOS, React Native y Flutter,. Graba screen recording, requests de red, logs y touches, y las garantías de enmascarado más importantes vienen activadas por default: los inputs de contraseña se enmascaran siempre, sin excepción, y los inputs de texto y las imágenes se enmascaran por default tanto en iOS como en Android. Ese default importa: alguien tiene que activar conscientemente mostrar un campo, no al revés.

Cada plataforma tiene su control fino. En iOS, accessibilityIdentifier = "ph-no-capture" bloquea un elemento y ph-no-mask fuerza lo contrario; en SwiftUI están los modificadores postHogMask() y postHogNoMask(). En Android se usa un tag o contentDescription = "ph-no-capture", con ph-no-mask aplicando a todos los hijos del view, y en Compose los equivalentes son postHogMask() y postHogUnmask(). React Native tiene maskAllTextInputs, maskAllImages y el componente PostHogMaskView. Flutter tiene maskAllTexts, maskAllImages, el widget PostHogMaskWidget, y algo a remarcar: las vistas nativas embebidas se enmascaran por default con maskAllPlatformViews.

Con eso ya sale una regla operativa para KYC: texto e imágenes parten enmascarados, así que el riesgo real está en decidir qué desenmascarar, no en acordarse de ocultar cada campo sensible uno por uno.

Los dos límites que cambian el análisis de riesgo

Acá está lo que una lista de features no cuenta, y es lo que más importa para una fintech. En iOS, SwiftUI, las custom views y los WebViews solo se graban con detalle si activás screenshotMode, y la propia documentación lo advierte: el screenshot puede contener información sensible, hay que usarlo con precaución. Sin ese modo, el replay queda en wireframe: menos fiel, pero más seguro por default. En una app con pantallas de verificación de identidad, decidir si activar screenshotMode en las pantallas de KYC es la decisión central de todo el proyecto de replay, no un detalle de configuración.

El segundo límite es más duro y aplica distinto según cómo esté construida la app: React Native y Flutter graban siempre en modo screenshot, y no es configurable. No tienen el fallback a wireframe que sí tienen iOS y Android nativos. Si la app está hecha en RN o Flutter, esto cambia el análisis de riesgo de fondo, porque no hay forma de degradar la fidelidad del replay para ganar seguridad por default; la decisión pasa a definir con más cuidado qué pantallas quedan fuera de la captura directamente. Vale chequear versiones antes de instrumentar: SDK de iOS ≥3.6.0, SDK de Android ≥3.4.0, y Android API ≥26.

Onboarding y activación, medidos como embudo

Resuelto qué se puede grabar, el resto es terreno conocido. Product Analytics responde qué hace la gente realmente en el producto: trends, funnels, retention, paths, stickiness y lifecycle sobre los mismos eventos, la capa que recorrimos en la nota sobre product analytics en PostHog. Funnels es la pieza clave acá, porque en todo flujo de producto más gente lo arranca que la que lo termina, y eso aplica literal a un onboarding con verificación de identidad: cada paso de carga de documento, selfie o validación de datos es un punto de abandono medible, no una intuición. Esa disciplina de decidir con el dato antes que con la intuición es la que planteamos en la nota sobre el gate de medición.

Si la fintech tiene un producto B2B, Group Analytics agrupa eventos por entidad (organización, cuenta) en vez de por usuario individual, algo clave cuando quien usa el producto día a día no es quien decidió contratarlo. Es un add-on pago, hasta cinco tipos de grupo por proyecto, y hay un detalle de facturación a tener claro: una vez suscripto, la facturación aplica a todos los eventos identificados del proyecto, no solo a los que llevan propiedades de grupo.

Sacar features de a poco, sin redeploy

Para una fintech, cambiar algo en producción sin poder apagarlo al instante si algo sale mal es un riesgo que no vale la pena correr. Los feature flags de PostHog están para eso: lanzar algo al 1% de los usuarios, ver qué pasa, y apagarlo en el momento en que algo se ve mal, sin redeploy ni hotfix. Los rollouts aceptan decimales con hasta dos posiciones, desde 0,01% hasta 33,33%.

En mobile hay una pieza extra que importa por la latencia de red: el bootstrapping, que carga los valores de los flags antes de que el SDK termine de inicializar. Está confirmado en JS web, React Native, iOS, Android y Flutter, y persiste identidad y flags en el dispositivo, así que la app no arranca a ciegas mientras espera la primera respuesta del servidor. Un matiz: el soporte de esta configuración con evaluación local varía según el SDK, conviene revisar la documentación puntual de cada plataforma antes de asumir que el early exit funciona igual en todos lados.

Errores: útil, pero sin promesa de estado

Error Tracking tiene guías de instalación dedicadas para iOS, Android y React Native, captura excepciones de todo el stack y las convierte en issues priorizables, cada uno con el session replay y los eventos del usuario afectado adjuntos. Lo que hay que decir claro: la documentación de PostHog no etiqueta este producto como GA ni como beta en ninguna plataforma, así que no corresponde presentarlo como algo terminado sin esa aclaración.

Los límites son concretos. En iOS, los símbolos y frames del sistema (UIKit, Foundation) no se symbolican, y los crashes de Swift aparecen como SIGTRAP sin el mensaje real del error. En Android todavía no hay contexto de código fuente asociado a una excepción, aunque la documentación dice que es una feature planeada. Versiones mínimas: SDK de iOS ≥3.56.0, SDK de Android ≥3.32.0 para el remote config de error tracking.

Surveys: la brecha de paridad más grande del producto

Si hay una parte de PostHog donde mobile va claramente atrás de web, es Surveys. La documentación lo dice sin vueltas: web tiene el soporte de features más completo, mientras que mobile tiene limitaciones. Lo que no existe en mobile y sí en JS web es bastante: targeting por URL con regex o match exacto, encuestas tipo botón de feedback, recolección de respuestas parciales, eventos de cancelación, targeting por actions, y shuffle de preguntas y opciones. El auto-submit al seleccionar respuesta llegó a React Native en la versión 4.26.0, pero no está en iOS ni Android nativos según la tabla de soporte oficial. Para targetear una encuesta justo después de un pago o una transferencia, conviene chequear esa tabla antes de prometer el mismo comportamiento que en web.

Compliance: lo que hay, y lo que todavía no está claro

PostHog está certificado SOC 2 Type II tras auditoría externa, con el reporte cubriendo controles hasta el 31 de mayo de 2026 en un ciclo anual junio-mayo. Tiene guía dedicada de GDPR, DPA disponible y soporte para el derecho al olvido. Para residencia de datos en la Unión Europea, PostHog Cloud EU está alojado en servidores en Frankfurt.

El dato más interesante para compliance en fintech no es sobre datos financieros: es HIPAA. PostHog ofrece BAA solo en los planes Boost, Scale y Enterprise, y excluye explícitamente las features de IA de esa cobertura: PostHog AI y otras features de IA no están cubiertas por los BAA y no deberían activarse en organizaciones donde algún proyecto procese información protegida de salud. HIPAA es sobre datos de salud, no financieros, así que no aplica directo acá, pero es la señal más clara de que las features de IA reciben un tratamiento de compliance distinto al del resto del producto. Vale mirarlo como precedente antes de asumir que PostHog AI corre bajo las mismas garantías que el resto de la plataforma en un contexto regulado.

Sobre self-hosting: existe, es open source bajo licencia MIT y se instala con Docker Compose, pero todas las features de los planes pagos son exclusivas de Cloud, y PostHog es explícito en que no ofrece garantías de funcionamiento en infraestructura propia, sin soporte pago ni parches de CVE dedicados. Para una fintech con requisitos regulatorios estrictos, esa combinación es una decisión para tomar con el equipo de compliance en la mesa, no solo con el de producto, que es justamente el tipo de cruce entre producto, growth y tecnología que discutimos en esta nota.

Y un nombre que cambió: lo que antes era Max AI ahora es PostHog AI, un analista de producto que vive dentro de la herramienta, responde en lenguaje natural sobre los datos del proyecto y respeta los controles de acceso existentes, así que solo ve lo que la persona que pregunta puede ver. Dónde termina la asistencia y dónde empieza el piloto automático es la distinción que desarrollamos en la nota sobre el modo self-driving.

Por dónde arrancar

El orden con más sentido para una fintech mobile: primero, decidir la política de masking en pantallas de KYC y datos financieros, incluyendo si activar screenshotMode en iOS, aceptando que en React Native o Flutter esa decisión ya viene tomada por la plataforma. Segundo, instrumentar Funnels sobre el onboarding completo, desde registro hasta la primera transacción. Tercero, activar Feature Flags con bootstrapping para lanzar cambios de forma gradual sin depender de un redeploy. Cuarto, sumar Error Tracking sabiendo que no es GA ni beta según la documentación, así que conviene tratarlo como herramienta útil, no como SLA. Recién después, evaluar Surveys conociendo la brecha con web, y revisar SOC 2, GDPR y la política de self-host con compliance antes de escalar a producción con datos reales de usuarios.

Para quién es esto

Esta nota es para equipos de producto y de datos de una fintech con app mobile que ya evalúan PostHog o lo tienen instalado y necesitan saber, antes de activar session replay o error tracking en pantallas sensibles, qué está realmente enmascarado por default, qué cambia si la app es nativa o está hecha en React Native o Flutter, y qué partes del producto todavía no tienen la misma madurez en mobile que en web. No reemplaza una revisión de compliance formal ni una auditoría de seguridad propia, pero da el mapa de qué preguntar antes de esa revisión.

Este contenido fue desarrollado con asistencia de IA y revisado por el equipo de Zenda. Las malas ideas son 100% nuestras.