¿Cómo se identifica al mismo usuario entre dispositivos? User-ID
User-ID es tu propio identificador persistente de usuario logueado, enviado a Google Analytics 4 (GA4) junto con los eventos. Permite unir la actividad de una persona que empieza en el celular y termina en la notebook.
Dos requisitos que Google marca de forma explícita en su documentación:
- El ID tiene que ser real y único por usuario. Asignar el mismo ID a personas distintas mezcla sus recorridos y hace imposible diferenciar la actividad.
- Nunca mandes valores en blanco o de relleno. Google advierte que hacerlo repetidamente puede llevar a datos inexactos, incluida pérdida permanente de datos.
Además, la propiedad tiene que usar una identidad de informes que incluya la opción User-ID: en Admin → Visualización de datos → Identidad de informes, elige Combinada (evalúa user ID, device ID y datos modelados) u Observada (user ID y device ID). Si dejas una identidad que no contempla User-ID, lo estás recolectando sin usarlo.
Usa un hash o un ID interno como valor, nunca el email en claro ni un documento de identidad.
Qué resuelve realmente User-ID
Conviene tener claro para qué sirve, porque suele implementarse como un campo más y se subutiliza. User-ID es opcional, pero es la pieza que permite unir el recorrido del mismo usuario entre dispositivos y entre plataformas: la sesión en el celular, la de la notebook y la de la app dejan de contarse como tres usuarios distintos y pasan a ser un recorrido único.
Ese es el motivo por el que aparece en el paso de maximizar señales y no en el de conectar fuentes: no agrega una fuente nueva, corrige la unidad de análisis de todas las que ya tienes. Sin User-ID, el conteo de usuarios está inflado y el recorrido de conversión está fragmentado; con User-ID, el análisis de journey empieza a describir personas en lugar de navegadores.
Un requisito administrativo que se pasa por alto: para usar la función tienes que aceptar la política correspondiente —la Analytics SDK / User-ID Feature Policy—, que regula qué puedes enviar como identificador. La restricción de fondo es que el ID no puede contener información que un tercero pudiera usar para determinar la identidad del usuario. Por eso el valor correcto es un identificador interno o un hash, y por eso conviene resolverlo con el equipo legal antes que con el de desarrollo.
Datos proporcionados por el usuario y enhanced conversions
Los datos proporcionados por el usuario (user-provided data) son datos first-party consentidos —típicamente el email, y también nombre, dirección o teléfono— que se envían a Google hasheados con SHA256. En GA4 puedes implementarlo hasheando tú mismo o dejando que la funcionalidad aplique SHA256 antes de enviar; si lo implementas vía Measurement Protocol, el hasheo del lado tuyo es obligatorio.
Las tres vías de recolección
Google documenta tres formas de recolectar estos datos, y no son intercambiables: cada una corresponde a un punto distinto del stack.
| Vía | Cuándo corresponde | Hasheo |
|---|---|---|
| gtag.js | Si recolectas datos del sitio directamente con el Google tag | Puedes hashear tú o dejar que la función aplique SHA256 antes de enviar |
| Google Tag Manager (incluido el contenedor server-side) | Si ya usas GTM: se actualiza el contenedor con variables que capturan el dato | Igual que gtag.js, con la opción de resolverlo en el contenedor de servidor |
| Measurement Protocol | Si el dato viene de una interacción offline, fuera del navegador | Obligatorio de tu lado: hay que enviar el dato ya hasheado con SHA256 |
Una aclaración que evita confusiones con material de habilitación de Google de 2025: durante un tiempo, Measurement Protocol figuró como vía no soportada para datos proporcionados por el usuario. La documentación pública vigente sí la documenta, acotada al caso de interacciones offline, y Google recomienda enviar en esa llamada tanto los datos del usuario como el User-ID. Si tu implementación se diseñó con la premisa vieja, vale la pena revisarla.
Más puntos de dato, mejor match rate. No es un detalle de optimización: Google señala que incluir más de un campo —email, dirección, teléfono— aumenta la probabilidad de encontrar coincidencia con el cliente y, en consecuencia, de atribuir la conversión. Recolectar solo el email funciona, pero deja match sobre la mesa.
Según la documentación de Google Analytics, esta recolección habilita tres capacidades:
- Customer Match para las audiencias de Analytics exportadas a tus productos publicitarios de Google vinculados, aumentando la cobertura del remarketing cuando no hay otros identificadores disponibles.
- Enhanced conversions para las conversiones de Analytics, lo que permite completar los huecos de interacciones con anuncios de Google Ads que las cookies ya no observan y mejorar el modelado de conversiones, la optimización de pujas y la vista cross-channel.
- Datos demográficos e intereses basados en datos first-party y en datos consentidos de usuarios con sesión iniciada de Google.
Requisitos y límites que conviene tener presentes antes de proponerlo internamente:
- La propiedad de Analytics debe estar vinculada a una cuenta de Google Ads.
- Reconocer la política de la función es permanente, aunque después puedas desmarcar la casilla.
- La función no está disponible para propiedades cuya categoría de industria sea “Salud”.
- Al momento de escribir esta guía, la funcionalidad está documentada como beta abierta y sujeta a cambios.
Del lado de Google Ads, enhanced conversions cumple la misma lógica: suplementa la conversión existente enviando datos de conversión first-party hasheados desde los tags del sitio o desde eventos offline importados. Es una de las recomendaciones que Google repite en sus mejores prácticas de Performance Max. Profundizamos en la implementación en la guía de enhanced conversions. Para el caso específico de ventas que se cierran fuera del sitio, el flujo completo CRM → Google Ads está en medición de leads offline.
Recupera las señales que tu automatización necesita
Auditamos tagging, consentimiento y conversiones para priorizar la señal que hoy está limitando tus campañas.
- 1
Diagnóstico gratuito de tu stack GMP
Un especialista revisa tu implementación actual (GA4, GTM, DV360, Ads) y te dice qué priorizar primero.
- 2
Plan de acción a medida
Sales de la llamada con next steps concretos para tu cuenta, no con una plantilla genérica.
- 3
Sin compromiso, sin venta forzada
Hablas con un especialista técnico, no con un vendedor. Si no encajamos, te lo decimos.
Respuesta a la brevedad
Maximizar mis señales
Completa el form y coordinamos una asesoría sobre tu caso.
Cargando el formulario seguro de HubSpot…
No pudimos cargar el formulario. Puedes escribirnos a hola@leadaki.com .
Este formulario lo provee HubSpot y los datos que envíes se procesan allí. Consulta nuestra política de privacidad .
Sin compromiso · Google Marketing Platform Sales Partner
Señales de compra: transaction ID y valor
Google es explícito en el paso 2 de sus mejores prácticas: hay que agregar valores a las conversiones para poder optimizar por retorno de la inversión publicitaria (ROAS) y por rentabilidad. Una conversión sin valor obliga al algoritmo a tratar todas las ventas como equivalentes.
El transaction ID es la otra mitad. En la referencia de eventos recomendados de GA4, el evento purchase lleva transaction_id, value, currency e items como parámetros requeridos, y el evento refund también exige transaction_id.
Ese identificador es lo que permite a Google Analytics deduplicar compras repetidas y procesar reembolsos correctamente. Tiene reglas de implementación estrictas —valor dinámico, nunca vacío, y alcance limitado a streams web— que desarrollamos con el detalle de cada caso en la guía de medición para ecommerce y retail.
Eventos recomendados por vertical
GA4 recolecta algunos eventos automáticamente, pero los eventos recomendados son los que tienen nombres y parámetros predefinidos por Google: al usarlos, se activan dimensiones, métricas e informes que los eventos personalizados no habilitan. Google los publica agrupados por vertical de negocio.
| Vertical | Ejemplos de eventos recomendados |
|---|---|
| Todas las propiedades | login, sign_up, search, share, join_group |
| Retail y ecommerce | view_item_list, view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund |
| Viajes | Eventos específicos publicados por Google para el vertical de travel |
| Juegos | Eventos de progresión, moneda virtual y niveles |
La regla operativa: usa el nombre de evento recomendado siempre que exista uno para tu acción. Inventar compra_ok en lugar de purchase te deja fuera de los informes de ecommerce, de las métricas predictivas y de buena parte de la automatización.
Volumen y variedad también importan. La documentación de métricas predictivas de GA4 indica que recolectar una mayor variedad o volumen de eventos recomendados correspondientes al comportamiento del usuario ayuda a mejorar los modelos y las predicciones.
Si vendes online, la guía de medición para ecommerce y retail desglosa el detalle de cada evento y del array items.
Google Signals: qué cambia en 2026
Google Signals es la configuración de GA4 que gobierna el manejo de datos que Google pudo haber recolectado sobre usuarios de Google con Personalización de anuncios activada. Habilita reportes enriquecidos —datos demográficos e intereses— para usuarios que iniciaron sesión en su cuenta de Google.
Google anunció un cambio relevante en sus controles de datos. A partir del 15 de junio de 2026, Google Analytics pasa a usar Consent Mode (dentro de Google Ads) como control único de la recolección de cookies e IDs publicitarios. En consecuencia, desde esa fecha la configuración de Google Signals en el Admin de Analytics y la API de Google Signals solo controlarán la asociación de tus datos de Analytics con información de usuarios que iniciaron sesión, a efectos de reportes de comportamiento.
Google indicó además que actualizará más adelante en 2026 la forma en que se gestiona la personalización de anuncios, de modo que la configuración ad_personalization de Consent Mode controle exclusivamente si los datos se usan para personalización en tu cuenta de Ads.
Qué hacer con esto hoy:
- No trates Google Signals como tu palanca de activación publicitaria a futuro. Esa función migra a Consent Mode.
- Asegúrate de que tu implementación de Consent Mode v2 esté correcta y transmita señales reales de consentimiento. Verifícalo con la auditoría de tagging y Consent Mode v2.
- Refuerza los identificadores que controlas tú: User-ID y datos proporcionados por el usuario. Son los que no dependen de cookies de terceros.
Prioridades si tienes que elegir
Si el equipo de desarrollo te da una sola ventana de trabajo, este es el orden de impacto:
purchase(o el evento de conversión principal) convalue,currencyytransaction_idcorrectos.- Datos proporcionados por el usuario / enhanced conversions.
- User-ID en todos los flujos logueados.
- Cobertura completa del embudo con eventos recomendados.
Cómo medir la señal antes de llamarla “maximizada”
Maximizar señales no significa enviar más campos sin control. Para cada evento elegible, separa dato disponible, consentimiento, entrega válida y match. Un evento puede tener un hash bien formado y no hacer match; un match mejor no demuestra por sí solo más ventas.
Usa la guía de cobertura de datos proporcionados para construir la línea base. Si la decisión es qué campo o producto corresponde, compara primero User-ID, UPD, Enhanced Conversions y Customer Match. Así el score de señales no premia una recolección más amplia cuando el problema real es un trigger duplicado, un consentimiento ausente o una conversión sin valor.
Data Strength Uplift: una métrica de recuperación, no de causalidad
El anuncio de Google del 10 de septiembre de 2026 presenta Data Strength Uplift como una métrica de Google Ads que calcula las conversiones adicionales recuperadas por una configuración de datos first-party. Es una lectura de recuperación o medición dentro de la plataforma: no es evidencia de que la publicidad haya causado esas conversiones, no es ROI y no es el Data Strength Score 0-100 de este sitio.
La publicación anuncia la capacidad, pero no garantiza su habilitación concreta en una cuenta. No asumimos una pantalla, fórmula, período de observación ni disponibilidad por país: esos detalles deben verificarse en la cuenta y en la documentación pública vigente. Para analizar la actualización, sus fuentes y esta distinción, consulta las novedades de Data Strength de septiembre de 2026.
Cuando la pregunta sea “¿cuántas conversiones adicionales generó la inversión?”, pasa de la señal recuperada a un experimento de incrementalidad, Conversion Lift o Meridian GeoX. Son instrumentos de evidencia causal y responden una pregunta distinta.
Con las señales enriquecidas, ya puedes pasar al Paso 3: activar los datos en Google Ads, diseñar la prueba causal que corresponda y revisar el marco completo de Data Strength si quieres conectar datos, medición, evidencia y presupuesto.
Mide en qué punto estás con el Data Strength Score propio y, si necesitas ayuda para implementar identidad y valor sin romper la medición existente, habla con un especialista de Leadaki.