Casi todos los equipos de apps de consumo cometen un error contable silencioso en su primer año. El dashboard dice un millón de usuarios. El instinto es tratarlos como un millón de activos. No lo son. Si esos usuarios llegan a un servicio a través de una página web de terceros incrustada, lo que posees es un pasillo, no las habitaciones detrás.
Hagamos concreto el mecanismo, porque la pérdida es técnica, no retórica.
Cuando metes un H5 de terceros en un webview, esa página se ejecuta en el origen del proveedor. Sus cookies, su almacenamiento local, su sesión: todo pertenece a ellos, no a ti. La identidad que el usuario establece dentro de ese flujo es del proveedor. Los datos de la transacción caen en los sistemas del proveedor. La relación post-compra — reembolsos, reactivación, la siguiente oferta — también vive ahí. Capturaste el clic. No capturaste nada que componga.
Esta es la diferencia entre tráfico y activo, y la mayoría de los equipos no se da cuenta hasta que intenta activar la audiencia una segunda vez y descubre que no puede.
Lo que realmente posees, cara a cara
| Dimensión | H5 de terceros incrustado | Runtime de mini-programa (del host) |
|---|---|---|
| Identidad | El origen del proveedor posee la sesión | Sistema de cuentas propio del host |
| Propiedad de datos | Queda con el tercero | Se acumula en el almacén del host |
| Reactivación | Se corta al cerrar la pestaña | El canal de mensajería del host recupera |
| Grafo de relación | Pertenece al servicio incrustado | El host posee el grafo del usuario |
| Postura regulatoria | El host puede no ser el controlador | El host es controlador de primera parte |
| Portabilidad | Bloqueada en el tercero | Controlada por el host, portable |
El costo aparece en tres lugares.
Primero, la reactivación. Una sesión webview termina cuando el usuario la cierra. No tienes un canal duradero de vuelta a esa persona; el proveedor sí. La próxima vez que quieras decir «tu pedido salió» o «aquí hay un beneficio», estás pidiendo permiso al proveedor, o comprando la audiencia de nuevo con anuncios que ya pagaste una vez para adquirir.
Segundo, el grafo de datos. La relación entre un usuario y un servicio — qué compró, con qué frecuencia, qué abandonó — es el conjunto de datos más valioso que produce un negocio de consumo. En un H5 de terceros, ese grafo pertenece al servicio incrustado. Ves un agregado que no controlas. Un runtime del host escribe cada evento en el almacén propio del host, así el grafo compone dentro de tu negocio.
Tercero, y este es el que los equipos subestiman, la exposición regulatoria. Bajo marcos como el GDPR de la UE, la LGPD de Brasil y la Ley DPDP de India de 2023, la pregunta de quién es el controlador o fiduciario de datos no es académica. Cuando un tercero procesa datos de usuarios dentro de tu app, puede que no seas el controlador — lo que significa que entregaste tanto el control como la responsabilidad de la parte más sensible de tu operación, mientras sigues cargando el riesgo de marca cuando algo falla.
Nada de esto significa que el H5 sea inútil. Para una campaña de una sola vez — llevar tráfico, convertir una vez, olvidar — una página incrustada es barata y funciona. El error es tratarla como infraestructura. La infraestructura es lo que posees. Un escaparate alquilado no.
Esta es la parte que los super-apps entendieron hace una década, y vale la pena decirla claro porque es la verdadera fuente de sus valuaciones. WeChat, Alipay, Grab, Gojek no construyeron «sitios que haces clic». Construyeron identidad, una billetera y un canal de mensajería como infraestructura propia, y luego dejaron que miles de comercios corrieran dentro de ese runtime. La capa de comercio se apoyaba en una relación que la plataforma controlaba de extremo a extremo. Los ojos nunca fueron el activo. La relación controlada sí.
Un runtime de mini-programa es el mecanismo que reproduce esa estructura sin reconstruir un super-app desde cero. Cuando los servicios corren dentro del runtime del host, el host provee identidad, billetera y notificación — así cada interacción se escribe en las cuentas propias del host, no en las del proveedor. El usuario se vuelve un registro que tienes, no un visitante que el proveedor registra.
Quiero refutar una versión romántica de esto. Controlar el runtime no significa «poseer al usuario» en sentido extractivo, el lock-in por el lock-in. La ventaja duradera es más estrecha y más defendible: convierte una relación que alquilabas, y que podías perder en el momento en que el proveedor cambie los términos o sea retirado de la tienda, en un activo que sobrevive esos golpes porque vive en tus sistemas. Dejas de ser un proveedor de tráfico que alquila su audiencia al servicio de otro, y empiezas a ser una plataforma que posee el estante, la caja y la lista de clientes.
Es la línea real. El tráfico se alquila. Los activos se poseen. Un runtime es cómo pasas de una columna a la otra.
