Medir el rendimiento conjunto en apps y web: el reto del seguimiento entre dispositivos

Si hace años decíamos que el perro es el mejor amigo del hombre, quizás desde hace unos años (no muchos) podríamos decir que, en cierta medida, el smartphone está empezando a ocupar cada vez más lugar del peludo de cuatro patas. Y no lo decimos nosotros desde Singular, sino que cualquier persona con cara y ojos lo ve en su día a día.

Y así lo corroboramos los datos:

​​

No obstante, si bien es cierto que el móvil cada vez se erige más como el rey, hay mucho contenido que todavía se sigue viendo en otras plataformas . Ya sean tradicionales (como sobremesa o tablets) o vía otros nuevos como pueden ser smartwatches/videoconsolas, etc.

Además, aquí no acaba la cosa, sino que dentro de cada propia plataforma, podemos tener grandes diferencias. Sin ir más lejos, cuando hablamos del consumo de internet en móviles, incluímos dos grandes mundos:

• Consumo vía navegadores en el móvil 
• Consumo vía aplicaciones móviles  

Y, de nuevo, aunque las apps sean las reinas de la fiesta “móvil”, bien es cierto que también hay gente consumiendo Internet vía navegadores en sus smartphones. Los menos, pero los hay. 

Por lo tanto, nos encontramos con tres realidades:

• Los usuarios pueden interactuar con marcas a través de diferentes plataformas como 
• Los usuarios, dentro de una plataforma como el móvil, nos pueden conocer o llegar a nosotros a través de la web o una aplicación

Entonces, ¿cómo sabemos de verdad cómo nos ha conocido un usuario?

Este es uno de los grandes retos de la atribución moderna. Y es lo que se conoce como medición cross-device , siendo la forma en la que medimos (o al menos lo intentamos) los usuarios que llegan a nosotros a través de diferentes sitios.

Por simplificar, diremos que esta atribución se divide en dos grandes mundos:

• Medición en web : medir todo lo que ocurre en una web, donde no haremos grandes diferencias (por no complicarlo más) entre la web en escritorio y la web en móvil. Porque se miden de una manera “bastante similar”
• Medición de aplicación : donde mediremos lo que ocurre en las aplicaciones móviles. Y es aquí donde necesitaremos la ayuda de un MMP (Mobile Measurement Partner) para entender mejor cómo se originan, no solo las descargas, sino todo lo que ocurre después. Incluyendo el ingresos, porque queremos que nuestra empresa haga dinero, ¿verdad?

¿Por qué necesitamos medir lo que ocurre entre dispositivos (cross-device)?

Piensa en ti mismo planeando unas vacaciones de dos semanas en la ciudad de Nueva York. 

• Buscas en Google “qué hacer en NYC en 14 días” mientras estás esperando un autobús / tren 
• Lees algunos artículos interesantes y empiezas a entender que hay más NYC además de Manhattan, que Central Park es más grande de lo que pensabas, que el Empire State necesita un boleto especial y que sí o sí tiene de ir a Madison Square Garden para ver un partido de los Knicks. Aunque te cueste un ojo de la cara. 
• Unos días más tarde empiezas a mirar vuelos en la web de Skyscanner en tu descanso para comer del trabajo. Dejas algunos en favorito y empiezas a darte cuenta de que el viaje a NYC barato no va a ser. Pero, como dirían los americanos “ YOLO ” (You Only Live Once o “que la vida se vive una vez”).
• De vuelta del trabajo, en la aplicación de TikTok ves un anuncio de la aplicación de Airbnb, con un anuncio enfocado a ir a NYC. Piensas que “te escuchan” pero se te olvida rápido e instalas la aplicación. Buscas a ver qué hay en NYC durante un rato pero ahí lo deja.   
• Dos días después, mientras esperas en la sala de espera del dentista, te entra un arrebato de adrenalina y reservas los billetes de avión a través de la app de Skyscanner. 
• Y a los dos días, encuentras una “ganga” de piso en Airbnb porque te llegó un correo electrónico que abriste en el ordenador y decidiste reservar. Era ahora o nunca.   

¿Te suena? Pues extrapola esto a cualquier circunstancia de tu vida donde puedas interactuar con marcas a través de diferentes plataformas. Y es que el customer Journey de un usuario no es “monoplataforma”. Vamos saltando de una en otra en función de nuestro momento vital y esto obliga a las marcas a medirnos (o perseguirnos) allá por donde vamos. 

Porque si un usuario ve un anuncio enfocado a descargar la aplicación pero después acaba generando la compra / reserva en la web, necesitamos tener alguna forma de cruzar esos dos puntos. Aunque ocurran en plataformas diferentes. Porque Juan / Lucía / María / Fran / Lucas u Olinda siguen siendo ellos mismos allá donde usen internet. A pesar de la plataforma que están usando.

Y esque, como marketer, si estás gastando dinero en campañas enfocadas a descarga de app, querrás saber el rendimiento que han tenido (es decir, el ROAS) independientemente de dónde ocurra la transacción. Si ocurre en la propia aplicación, más fácil de medir. Pero si ocurre en la web, no vas a decidir no medirlo y mirar para otro lado, ¿verdad?

Identificando a los usuarios entre los diferentes dispositivos/plataformas 

Si sabemos que Juan / Lucía / María / Fran / Lucas u Olinda usan indiferentemente apps y webs, ¿cómo podemos identificarlos a cada uno de ellos? Pues de igual manera que las Administraciones utilizan el NIF (Número de Identificación Fiscal), un identificador único de cada ciudadano, nosotros también tenemos que poder tener algún tipo de indicador que nos permita reconocer siempre a nuestros usuarios. Algo así como ponerles una prenda que nos permitan, allá donde estén, reconocer que son ellos.  

Si has trabajado alguna vez ya con equipos técnicos o de Data, sabrás de la existencia (casi siempre) de un concepto llamado User ID. Se trata de un identificador que los usuarios suelen tener cuando se registran en un producto. Es independiente a la plataforma / dispositivo donde se registra y, cuando eso pasa, suele generar un identificador único para cada usuario en la base de datos de la compañía. 

Pues bien, ese User ID (que también verás como u_id, user_id, UID, etc) suele ser el identificador más robusto que podemos tener para identificar al usuario haga lo que haga, allá donde esté (web desktop, web móvil, app, etc). 

ID de usuario en cada “acción” (evento) del usuario 

Es por eso que, si queremos identificar al usuario gracias a su identificador, uno de los parámetros que tenemos que siempre “medir” de las acciones del usuario es este User ID. Así que…

• Si el usuario ingresa en la aplicación… rastrearemos un evento de app_open y agregaremos su ID de usuario como uno de los parámetros de este evento.
• Si el usuario llega al checkout de nuestro ecommerce en la web, trackearemos un evento de checkout_viewed y agregaremos el User ID como uno de los parámetros de este evento
• Si el usuario hace match en la aplicación de citas que tenemos, mandaremos un evento de match_occured y mediremos el ID de usuario. Y en este caso concreto, muy probablemente lo mediremos para dos usuarios, con sus respectivos ID de usuario. Porque no hay amor (ni match) sin dos personas involucradas, ¿verdad?

Y así con todas las acciones del usuario. Si algo tenemos que tratar de medir con cada acción que hacer el usuario es el User ID. Porque como hemos dicho, es el identificador más robusto que podemos tener para tratar de “encontrar” al usuario allá donde vaya y haga lo que haga. Y no lo decimos nosotros, sino que el todopoderoso Google también recomienda mandar un ID de usuario para poder hacer seguimiento entre dispositivos (en su caso multiplataforma). Porque tampoco Google puede hacer seguimiento entre dispositivos sin tener identificadores únicos por usuario

¿En qué nos ayuda en el día a día tener este ID de usuario?

Como este ID identifica de forma clara y contundente al usuario, nos va a permitir poder medir todo lo que haga. De tal manera, que cuantos más usuarios tengan claramente identificados con User ID, por ejemplo podremos llegar a:

• Medir el ingreso promedio por usuario (ARPU), lo cual me ayudará a entender cuánto dinero de medios me generan mis usuarios. Y con ello, sepa qué segmentos son más interesantes para:
  • Entender qué tipo de usuarios nos aportan más valor. En base a su género, país de origen, tipología de producto que consume, tiempo en el producto, etc. 
  • Hacer campañas Lookalike con estos usuarios y conseguir usuarios “similares” al producto
  • Poder entender qué han hecho estos usuarios (patrones) para tratar de fomentar que el resto lo haga. Aquí es donde entramos en el reino de la Analítica de Producto o Product Analytics. 
• Entender mejor la retención en el producto, ya que podremos medir el volumen de usuarios que vuelven todos los días (Daily Active Users o DAU), todas las semanas (Weekly Active Users o WAU) o meses (Monthly Active Users o MAU). 
• Podremos agregar estos usuarios a herramientas de terceros. Por ejemplo, hay muchas herramientas (como algunos CRM) que solo nos permiten añadir usuarios identificándose con un User ID. De lo contrario, no podremos usar ciertas capacidades para enviar a estos usuarios correos electrónicos o notificaciones push (aunque tendremos otras formas de hacerlo algo más “artesanales”).

Y otro largo etcétera de cosas que no podremos hacer pero que dejamos para otros artículos.  

Si no tengo ID de usuario… ¿no puedo hacer seguimiento entre dispositivos?

Respuesta corta: sí, sí puedes hacerlo. Hay empresas que no trabajan con User ID cuando un usuario se registra (esto daría para una larga conversación) pero sí que guardan el correo electrónico de registro del usuario. Pues bien, podemos usar ese correo electrónico como identificador del usuario. 

Pero tienes de tener en cuenta que un mismo usuario puede registrarse en un producto con varios correos electrónicos. Por lo que la solidez del correo electrónico como identificador único es menor que la de un User ID generado de manera automática en tu base de datos. Es decir: 

• Un usuario con User ID puede tener dos (o tres o cuatro) correos electrónicos asociados
• Un correo electrónico de un usuario nunca debería tener más de un ID de usuario 

Si, por lo que sea, tienes correos electrónicos con más de un ID de usuario, aquí lo que tienes es otro tipo de problema un poco más serio. Te recomiendo hablar con tus desarrolladores y buscar una solución cuanto antes.  

Además, hay otras circunstancias donde no podemos tener User ID como identificador del usuario:

• El usuario todavía no se ha registrado en un dispositivo 
• El usuario no requiere “registro” para usar el producto 

Veamos ambos casos un poco más en detalle

Usuario no registrado en una plataforma

Siguiendo el ejemplo de Skyscanner de antes, se podría dar el ejemplo de que aunque tú te hayas registrado en Skyscanner vía app, uses la web sin loguearte. Es decir, sin decirle entrar con tu usuario y contraseña y que Skyscanner “ sepa que eres tú .”

Aquí el seguimiento entre dispositivos es algo más complejo, ya que Skyscanner no tiene ni idea de que esos vuelos que estás mirando en la aplicación vienen de ti. Saben que alguien está mirando vuelos a NYC pero, como han visto la prenda que te identifica, no saben que eres tú.

Si bien, esta visita que estás haciendo sí que genera un identificador (ID) de la visita/sesión. Pongamos un ejemplo: 

• Tu ID de usuario en Skyscanner es: ABC123
• El ID de la sesión en la aplicación es: S19101199

Lo ideal es, de alguna manera, asociar que S19101199 pertenece al ID de usuario ABC123. Porque una vez lo hagamos, sabremos que ese usuario ha hecho X, Y o Z acciones. Es lo que en la industria de datos se conoce como hacer “cosido” o, en inglés, stitching .

Usuario no requiere registro para usar el producto 

Otra de las posibles situaciones donde un usuario no tenga User ID parte del hecho de que muchas marcas, para usarlas, no obligan a registrarse ni loguearse. Piensa en webs de periódicos, donde no te obligan a medir credenciales de ningún tipo. O en alguna aplicación que sirva para borrar archivos duplicados en tu móvil. Por lo general estos productos:

• O bien no necesita que el usuario se registre para generar valor al negocio. Por ejemplos los periódicos viven:
  • De enseñar anuncios, los cuales segmentan usando otras fuentes de datos, como la información a la que pueden acceder desde el navegador o propio dispositivo (localización, idioma, etc) 
  • De modelos de suscripción donde cuando quieras leer una noticia Premium en un medio, este esté “detrás” de un paywall y necesites acceder con credenciales propias. Un correo y contraseña que, ¿adivináis con que identificador estará asociado casi con total seguridad? De hecho, con un ID de usuario

• De generar ingresos con modelos que no requieren información alguna del usuario. Por ejemplo, una aplicación que ofrece servicios de VPN, donde registrarse en sí mismo va ligeramente desalineado con lo que buscan algunos (que no todos) los usuarios que usan VPN. 

Entonces, ¿cómo llegamos a hacer esta identificación al usuario? 

Si has llegado hasta aquí, ya sabes que tener información de usuario es más valioso que tenerla del dispositivo o sesión, ¿verdad? Porque repasemos:

• Cada usuario debería tener un identificador único robusto, idealmente un User ID que no fuera el correo electrónico. 
• Un dispositivo puede tener varias ID de sesión
• Un ID de usuario puede tener varios ID de dispositivo 

Para llegar a la conclusión de qué IDs “suaves” (sesión, dispositivo, etc) corresponden a cada ID “fuerte·(User ID), tenemos que llevar a cabo un proceso de recolección de datos y consolidación de los mismos. Todo ello para generar algo así como una especie de historial de todo lo que hace un usuario.

A este historial se le denomina Grafo de Identidad o Identity . Este “historial” nos genera una visión unificada de nuestros usuarios / clientes en base a las diferentes interacciones. Y esto se hace, en parte, a través de un proceso de Resolución de Identidad o , el cual nos permite “reconciliar y unificar” todo el camino del usuario a través de sesiones, plataformas/dispositivos, etc.

Y para ello, hay que seguir tres pasos:

1. Identificar las acciones del usuario 

2. Consolidar los datos una vez identificados 

3. Cruzar esta entre plataformas 

1. Identificar las acciones del usuario

Ya lo hemos explicado anteriormente. Se trata de poder asociar tanto como podamos cada acción a un ID de usuario. De ahí que: 

• Si usas Singular como MMP para tus aplicaciones, tengas que asociar a cada evento que quieras medir el ID de usuario. Y lo tendrás que hacer tanto para tus aplicaciones de Android como para tus aplicaciones de iOS
• Si tu producto también cuenta con web, también tendrás que usar el WebSDK y enviar el User ID de los eventos que allí ocurran.

Si llegas hasta aquí, por ahora tendrás plataformas separadas midiendo (con suerte) las acciones de usuarios que usan algunas o todas ellas. Siendo honestos, lo normal será usar, como mucho dos de ellas (Android + Web o iOS + Web), ya que es raro el caso de un usuario que tiene un dispositivo iOS y Android simultáneamente. Pero más vale prevenir que curar. 

2. Consolidar los datos una vez identificados 

Una vez Singular ha hecho su trabajo (identificación y atribución por dispositivo), toca enviar estos datos usando un proceso de ETL. Desde Singular, puedes mandar toda esta información a:

• Bases de datos y Data Warehouses como Google BiQuery, Snowflake, Redshift o MySQL 
• Fuentes de datos basadas en filas como Google Sheets, Amazon S3 o Google Cloud Storage

Entre los tipos que puedes exportar de Singular a estos destinos tienes:

• Datos de campañas agregadas : información de Ad Spend, creatividades, instalaciones, etc. Este es interesante, sobre todo, para los equipos de User Acquisition.
• Datos de Monetización vía anuncios agregados : más enfocado a modelos de negocio que ganan dinero enseñando anuncios a sus usuarios. Si quieres saber más sobre esto, puedes leer sobre Monetización de anuncios en apps
• Datos a nivel de usuario : este será el más relevante para el seguimiento entre dispositivos que nos buscamos
• Datos de Monetización vía anuncios a nivel de usuario: parecidos a los mencionados antes pero con mayor granularidad a nivel de cada usuario. Puede ser interesante también para el seguimiento entre dispositivos si una de tus formas de generar ingresos en la aplicación es a través de anuncios

3. Cruzar los datos para tomar decisiones acertadas

Aquí es donde tendremos que involucrar a nuestros equipos de Data. Depende del tipo de datos que tengamos, necesitaremos o bien involucrar Ingenieros de Datos (procesado, normalización y limpieza de datos) o Analistas de Datos (representación de datos y extracción de insights). 

Pero, como especialistas en marketing, como hemos visto por ahora hemos hecho gran parte del trabajo solo:

• Leyendo este artículo para entender sobre ID suaves y fuertes, Gráfico de identidad, Resolución de identidad, etc. 
• Eligiendo una herramienta que nos permita rastrear eventos de usuario con el User ID incorporado, como es el caso de Singular 
• Mandando los datos ya trackeados a cualquiera de los destinos que nos permita hacer un análisis más en detalle 

Otras plataformas hacen el proceso completo de seguimiento entre dispositivos. ¿Es correcto?

Respuesta corta: no. Ninguna herramienta puede inventarse por ti un User ID para poder “cruzar” los usuarios que vengan de diferentes plataformas. Ni siquiera Google Analytics 4, aunque lo dicen ciertos gurús de la Analítica Web.

 En el caso de plataformas como GA4, lo que ocurre es que se generan varios ID:

• Pseudo ID de usuario : es un identificador asociado a cada dispositivo. Es decir, si tu usuario tiene capacidad de usar en Android, iOS y web, muy probablemente tendrás hasta tres pseudo_user_id por cada usuario.

​​

• ID de usuario: ID del usuario que se ha de mandar desde el lado de la marca. Repetimos, lo has de mandar tú como marca. GA4 ni lo crea ni lo puede crear. Si lo hiciera, sería más bien digno de un mago de Gryffindor que de una plataforma de medición.

Por cierto, además de los límites de GA4 como herramienta de atribución, este “cosido” de IDs no es algo que puedas ver de manera sencilla en GA4. Solo se ve si exportas los datos de GA4 al Data Warehouse de Google, BigQuery y trabajas con él. Y para eso, tu conocimiento y habilidades en Data han de ser bastante elevadas.

O contar con un Ingeniero de Datos cerca.

Ejemplo de una tabla de BigQuery donde se ve el pseudo_user_id