Medir el performance conjunto en apps y web: el reto del cross-device tracking

Si hace años decíamos que el perro es el mejor amigo del hombre, quizá 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 corroboran 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 desktop 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 mobile apps  

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 app

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 desktop y la web en móvil. Porque se miden de una manera “bastante similar”
• Medición de app: donde mediremos lo que ocurre en las apps 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 revenue, 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 Nueva York City. 

• 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 ticket especial y que sí o sí has 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 app de TikTok ves un anuncio de la app de Airbnb, con un anuncio enfocado a ir a NYC. Piensas que “te escuchan” pero se te olvida rápido e instalas la app. Buscas a ver qué hay en NYC durante un rato pero ahí lo dejas.   
• 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 email 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 “mono-plataforma”. 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 app 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 performance que han tenido (es decir, el ROAS) independientemente de dónde ocurra la transacción. Si ocurre en la propia app, 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 devices / 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 permita, 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 / device donde se registren y, cuando eso pasa, se 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). 

User ID 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 entra en la app… trackearemos un evento de app_open y añadiremos su User ID como uno de los parámetros de este evento
• Si el usuario llega el checkout de nuestro ecommerce en la web, trackearemos un evento de checkout_viewed y añadiremos el User ID como uno de los parámetros de este evento
• Si el usuario hace match en la app de citas que tenemos, mandaremos un evento de match_occured y mediremos el User ID. Y en este caso concreto, muy probablemente lo mediremos para dos usuarios, con sus respectivos User ID. 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 User ID para poder hacer cross-device (en su caso cross-platform) tracking. Porque tampoco Google puede hacer cross-device tracking sin tener identificadores únicos por usuario

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

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 tenga claramente identificados con User ID, por ejemplo podremos llegar a:

• Medir el Average Revenue per User (ARPU), lo cual me ayudará a entender cuánto dinero de media me generan mis usuarios. Y con ello, saber 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 consumen, 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), todos las semanas (Weekly Active Users o WAU) o meses (Monthly Active Users o MAU). 
• Podremos añadir estos usuarios a herramientas de terceros. Por ejemplo, hay muchas herramientas (como algunos CRMs) que solo nos permiten añadir usuarios identificándose con un User ID. De lo contrario, no podremos usar ciertas capacidades para mandar a estos usuarios emails o push notifications (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 User ID … ¿no puedo hacer cross-device tracking?

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 email de registro del usuario. Pues bien, podemos usar ese email como identificador del usuario. 

Pero has de tener en cuenta que un mismo usuario puede registrarse en un producto con varios emails. Por lo que la solidez del email 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) emails asociados
• Un email de un usuario nunca debería tener más de un User ID 

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

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

• El usuario todavía no se ha registrado en un device 
• El usuario no requiere de “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 cross-device tracking es algo más complejo, ya que Skyscanner no tiene ni idea de que esos vuelos que estás mirando en app 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 User ID en Skyscanner es: ABC123
• El ID de la sesión en la app es: S19101199

Lo ideal es, de alguna manera, asociar que S19101199 pertenece al User ID 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 meter credenciales de ningún tipo. O en alguna app que sirva para borrar archivos duplicados en tu móvil. Por lo general estos productos:

• O bien no necesitan 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 device (localización, idioma, etc) 
  • De modelos de suscripción donde cuando quieras leer una noticia Premium en un medio, esta 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? En efecto, con un User ID

• De generar ingresos con modelos que no requieren información alguna del usuario. Por ejemplo, una app 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 device o sesión, ¿verdad? Porque, repasemos:

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

Para llegar a la conclusión de qué IDs “suaves” (sesión, device, 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 Graph. 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 Identity Resolution, el cual nos permite “reconciliar y unificar” todo el camino del usuario a través de sesiones, plataformas / devices, etc.  

Y para ello, hay seguir tres pasos:

1. Identificar las acciones del usuario 

2. Consolidar la data una vez identificada 

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 User ID. De ahí que: 

• Si usas Singular como MMP para tus apps, tengas que asociar a cada evento que quieras medir el User ID. Y lo tendrás que hacer tanto para tus apps de Android como para tus apps 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 la data una vez identificada 

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

• Bases de datos y Data Warehouses como Google BiQuery, Snowflake, Redshift o MySQL 
• Fuentes de dato 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 via anuncios agregados: más enfocado a modelos de negocio que ganan dinero enseñando anuncios a sus usuarios. Si quieres saber mas sobre esto, puedes leer sobre Ad Monetization en apps
• Datos a nivel de usuario: este será el más relevante para el cross-device tracking que buscamos nosotros
• Datos de Monetización via 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 cross-device tracking si una de tus forma de generar ingresos en app 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 marketers, como hemos visto por ahora hemos hecho gran parte del trabajo solo:

• Leyendo este artículo para entender sobre IDs suaves y fuertes, Identity Graphic, Identity Resolution, etc. 
• Eligiendo una herramienta que nos permita trackear 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 cross-device tracking. ¿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 digan ciertos gurús de la Analítica Web.

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

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

​​

• User ID: 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