El contrato que debe pasar cada evento
| Control | Pregunta de QA | Evidencia segura |
|---|---|---|
| Propósito | ¿Qué función necesita este campo? | Registro de objetivo, evento y destino sin valores |
| Consentimiento | ¿El evento respeta el estado de ad_user_data? | Matriz de estados y resultado del test |
| Formato | ¿El campo está normalizado y hasheado como exige la función? | Fixture sintético y resultado booleano |
| Disparo | ¿Ocurre una sola vez en la conversión correcta? | Conteo de eventos y trigger |
| Transporte | ¿Sale por la ruta esperada y no a destinos extra? | Lista de requests redactada |
| Retención | ¿Se eliminan payloads, logs y fixtures cuando ya no hacen falta? | Evidencia de limpieza y acceso |
Secuencia de validación
1. Prueba en local con datos sintéticos
Construye un fixture que use valores que no pertenezcan a ninguna persona real. Mantén separado el fixture de producción y marca los datos como prueba. El objetivo es verificar:
- normalización de espacios, mayúsculas y teléfono;
- aplicación de SHA-256 donde corresponda;
- tratamiento de campos ausentes;
- no envío de valores vacíos o de relleno;
- un solo disparo por conversión.
No necesitas que el dato sintético haga match con una cuenta de Google para probar el contrato técnico.
2. Prueba estados de consentimiento
Repite el evento con cada combinación necesaria para tu implementación. Como mínimo, verifica que UPD no se envíe para publicidad cuando ad_user_data está denegado y que el tag no adelante la captura antes del estado por defecto. Si tu implementación regionaliza defaults, prueba una región donde aplica el banner y otra donde no.
Consent Mode controla el permiso para la señal; no reemplaza el inventario de propósitos y retención. Consulta la guía de gobierno de consentimiento.
3. Revisa el navegador sin guardar PII
En Preview o DevTools, confirma nombres de eventos, estados, destino y ausencia de valores en texto plano. No pegues el payload entero en un ticket. Si necesitas evidencia, conserva una captura anonimizada con:
- email, teléfono, nombre, dirección y hashes redactados;
- GCLID,
client_id,user_idy parámetros de URL redactados; - cookies y headers omitidos;
- timestamp y URL reducidos a la mínima precisión necesaria.
4. Usa los diagnósticos del producto
El informe de diagnóstico de Enhanced Conversions puede señalar dato ausente, formato incorrecto o problemas de código. Trátalo como una señal operativa: un estado “activo” no demuestra que todos los eventos sean válidos ni que las conversiones hagan match.
5. Valida aguas abajo
Comprueba que el evento llega a la propiedad o acción correcta, que no se duplica y que la latencia está dentro de la ventana esperada. Para CRM y eventos offline, valida la relación entre el registro interno y el evento sin poner el dato original en el reporte.
Valida tu señal sin poner datos personales en riesgo
Diseñamos un proceso de QA con datos sintéticos, estados de consentimiento y diagnósticos que tu equipo pueda repetir.
- 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
Auditar mi validación de 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
Controles que deben fallar
Configura una prueba que falle explícitamente si:
- aparece PII en claro en una request destinada a publicidad;
- un usuario sin consentimiento produce un evento UPD;
- se envía un campo vacío, de ejemplo o igual para todos;
- el mismo evento se dispara dos veces;
- un log retiene payload o hashes completos;
- un cambio de contenedor agrega un destino no aprobado.
Lo que esta validación no demuestra
Un QA técnico no demuestra cumplimiento legal, match rate futuro, atribución total ni incremento de ventas. La evaluación jurídica y las decisiones de retención dependen de tu organización y jurisdicciones. Aquí se valida que la implementación respete el contrato técnico y la política de datos que hayas definido.
Siguiente paso
Convierte esta secuencia en un checklist de release y mide su resultado con la guía de cobertura de señal. Si no tienes claro qué campo necesita cada destino, vuelve a la matriz de elección de UPD.