Analítica de apps móviles para iOS, Android y Flutter

Swift Package Manager. SDK de WebmasterID para iOS 1.3.0, para iOS 15.0 o posterior, desde un paquete Swift público en GitHub.

Gradle, con Kotlin o Java. SDK de WebmasterID para Android 0.3.0, para la API 24 o posterior, desde el repositorio Maven público de webmasterid.com/sdk/maven.

pub.dev: webmasterid_flutter 0.4.0, para Flutter 3.47.0 o posterior, en aplicaciones iOS y Android. Funciona sobre los SDK nativos.

Eventos, sesiones, instalaciones activas, instalaciones observadas por primera vez y usuarios identificados, con eventos por día, los eventos principales y el estado del seguimiento: cuándo llegó el último evento.

Cada nombre de evento con sus recuentos y sesiones, las pantallas y los países principales, y los 50 eventos más recientes con identificadores seudónimos abreviados.

Los eventos de embudo que informa la app, en una tabla; las compras verificadas con Apple o Google, en otra. Las dos nunca se suman.

Cohortes de los días 1, 7 y 30 por instalación, en la zona horaria de informes. Un día que todavía no ha pasado aparece como aún no observable, nunca como 0 %.

Lo que se sabe del origen de la actividad de la app y lo que no. Los SDK no envían fuente, campaña ni referente, así que el origen de las instalaciones aparece como desconocido, nunca como orgánico.

Una cuenta, un espacio de trabajo y un plan. Un panel con las secciones Sitios web y Aplicaciones en la barra lateral. El rango de fechas se mantiene al pasar de una a otra, con una sola zona horaria de informes.

No hay un informe combinado de web y app, ni un recorrido desde una visita web hasta la app, ni coincidencia de una persona entre dispositivos: la clave de cuenta se guarda como un hash distinto en cada app, así que el mismo usuario cuenta una vez en la app iOS y otra en la app Android.

Hasta que la app pasa la decisión del usuario, el SDK no pone nada en cola ni envía nada.

Los eventos llevan un ID de sesión, un ID de instalación y, si la app llama a identify(), una clave de cuenta. Los ID de instalación y las claves de cuenta se guardan como hashes con clave: seudónimos, no anónimos.

Los eventos solo llevan un ID de sesión: ni ID de instalación ni clave de cuenta. Es una identificación reducida, no anonimato: el ID de sesión, las horas exactas y el país se mantienen.

No se envía nada.

El servidor rechaza el IDFA, el IDFV, el ID de publicidad de Android y otros identificadores de dispositivo. No se solicita App Tracking Transparency, y una respuesta de ATT no es un consentimiento para analítica.

El país se obtiene en el borde de la red cuando llega el evento. No se guarda ninguna dirección IP ni agente de usuario.

Los eventos de embudo que envía la app, contados como afirmaciones de la propia app: signup, login, checkout_started, booking_started, payment_started, booking_completed, cancellation y refund_requested.

En iOS, transacciones de StoreKit 2 firmadas por Apple, comprobadas con los certificados de Apple, y notificaciones del servidor de la App Store. En Android, tokens de compra de Google Play comprobados con Google y notificaciones para desarrolladores en tiempo real. Cada una necesita una conexión con la tienda configurada en la página de la app en el panel. Solo transacciones de producción con ingresos, en bruto antes de reembolsos y por moneda. Las compras de sandbox y de prueba nunca cuentan.

Equipos que ya miden una web con WebmasterID y publican una app iOS o Android. Aplicaciones cuyos momentos clave caben en los 14 eventos: pantallas, toques, búsqueda, filtros, registro e inicio de sesión, y los pasos de reserva, pago y compra. Equipos que quieren una analítica de aplicaciones seudónima, con consentimiento y sin identificadores publicitarios. Agencias que llevan webs y aplicaciones de varios clientes (el plan Agency añade espacios de trabajo y miembros del equipo).

Atribución de instalaciones: postbacks de redes publicitarias, SKAdNetwork, Apple AdServices, el Install Referrer de Google Play, campañas de enlaces profundos, coste o ROAS; WebmasterID no es un socio de medición móvil (MMP). Nombres o propiedades de evento personalizados, ni un recorrido único que siga a una persona de la web a la app o entre dispositivos. Descargas de la App Store o de Google Play: una instalación observada por primera vez es el primer evento de un ID de instalación, no una descarga. Informes de fallos, grabación de sesiones, notificaciones push o pruebas A/B. Aplicaciones React Native, Unity o .NET. Datos de aplicaciones en el Explorador de eventos, en las exportaciones o en las herramientas MCP y del agente, que trabajan con datos web.