Según GA4, el mes pasado se registraron 4,180 compras. Sin embargo, la tabla de pedidos indica 4,690. Si se le pregunta cuál es la cifra correcta, la respuesta honesta es ninguna de las dos, hasta que pueda explicar adónde fueron los 510 pedidos que faltan. No se trata de un problema de organización. Cada resultado de experimento y cada puntuación de priorización que usted genera se calcula sobre una cifra errónea, cuyo error se desconoce.
Google trata una gran porción no medida como normal: el modelado de comportamiento para el modo de consentimiento no se activa hasta que se registra una propiedad. al menos 1,000 eventos por día con analytics_storage='denied' durante al menos 7 días. Debajo de eso, los datos faltantes permanecen faltantes.
Esto va dirigido a quienes se encargan del análisis de datos o de la optimización de la tasa de conversión (CRO) en un equipo de comercio electrónico. Al final, tendrás una tabla de conciliación, un desglose de la brecha en causas específicas con una prueba para cada una, y un valor de tolerancia que podrás justificar.
Lo que realmente mide una conciliación de compras
Una conciliación no consiste en "hacer que los números cuadren". Nunca coincidirán, y un equipo que lo intente suele haber hecho algo peor que dejar la discrepancia sin más. Responde a tres preguntas: ¿cuán grande es la discrepancia?, ¿qué mecanismos la producen? y ¿cuánto se puede recuperar y a qué coste? La realizamos antes de cualquier experimentación, porque una prueba basada en un evento de conversión que descarta silenciosamente una parte desconocida de los pedidos no es un experimento.
Paso 1: seleccione dos tablas que se puedan unir mediante el ID del pedido.
Necesitas una fila por pedido, de ambos sistemas, para el mismo rango de fechas del calendario, con una clave que exista en ambos lados.
- backend: ID del pedido, marca de tiempo de creación en la zona horaria de informes de la propiedad, valor del pedido en la misma base de impuestos y envío que configuró en GA4, método de pago, dispositivo, país, estado.
- GA4: La exportación de BigQuery, no la interfaz de usuario. Consulta
purchaseeventos conecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, categoría del dispositivo y fuente de tráfico.
Utilice BigQuery deliberadamente. Los datos modelados del modo de consentimiento aparecen en los informes estándar de GA4 y en algunas exploraciones, pero Google afirma que es No En la exportación de BigQuery, encontrará información sobre audiencias, explorador de usuarios, análisis de cohortes o retención, o métricas predictivas. Al comparar la interfaz de usuario con su tabla de pedidos, estará comparando una estimación con un hecho.
Luego, una unión externa completa por ID de pedido. Ahora tienes tres categorías: en ambas, solo en el backend, solo en GA4. La tercera es más pequeña, pero la más útil para el diagnóstico.
Paso 2: expresar la brecha de tres maneras, no de una.
Un único porcentaje mensual lo oculta todo. Calcula los tres:
- Brecha en el recuento de pedidos: (pedidos de backend menos compras coincidentes de GA4) / pedidos de backend. Esto aísla la pérdida de seguimiento.
- Brecha de ingresos: El mismo cálculo se aplica al valor. Si la diferencia en el recuento es del 3 % y la diferencia en los ingresos es del 11 %, no se trata de un problema de seguimiento, sino de un problema de definición de valor (impuestos, gastos de envío, descuentos, divisas, tarjetas regalo).
- Variación del intervalo diario: Grafica la diferencia diaria en el número de pedidos. Una línea plana indica una causa estructural, como el consentimiento o los bloqueos. Los picos indican despliegues, picos de campañas o un incidente con el proveedor de pagos.
Paso 3: descomponer la brecha en causas identificadas.
Siga esta tabla. Cada causa tiene una prueba que puede confirmarla o descartarla en menos de una hora.
| Causa | Cómo probarlo | Firma en los datos |
|---|---|---|
| Consentimiento denegado, la etiqueta nunca se activa. | Compare el registro de estado de consentimiento de su CMP con las sesiones de GA4 para el mismo período. | Porcentaje diario estable; concentrado en el tráfico de la UE y Turquía. |
| Bloqueadores de anuncios y rastreadores | Contar las solicitudes de registro del servidor para la URL de confirmación y compararlas con los eventos de compra de GA4 en esa URL. | Sesga los navegadores de escritorio, Firefox y los navegadores de privacidad; se mantiene estable con el tiempo. |
| La página de confirmación nunca carga. | Contabilizar los pedidos realizados únicamente en el servidor cuya URL de confirmación nunca se solicitó en los registros del servidor. | Especializados en métodos de pago de redireccionamiento bancario y 3DS. |
| Eventos de compra duplicados | Contar eventos de compra de GA4 por transaction_id | GA4 supera el rendimiento del backend algunos días; páginas con mucho uso del botón de actualización y retroceso. |
| El enlace entre dominios está roto. | Inspeccione si _gl sobrevive al viaje de regreso del proveedor de pagos. | Compra terrenos en nuevas sesiones atribuidas al dominio de pago como referencia |
| Restablecimiento de la duración de las cookies | Segmentar la tasa de nuevos usuarios por navegador | Aumento de nuevos usuarios y tráfico directo en Safari e iOS. |
| Modelado versus crudo | Comparar los totales de la interfaz de usuario de GA4 con los de BigQuery para un rango de fechas idéntico. | Las dos cifras de Google no coinciden incluso antes de abrir la tabla de pedidos. |
| Definición de valor | Recalcula los ingresos del backend con y sin impuestos, gastos de envío y descuentos. | Las cifras coinciden, pero los ingresos no. |
| Límite de zona horaria | Reagrupar a semanas completas | La brecha se reduce hacia cero con una granularidad semanal. |
Dos merecen cuidados especiales. transaction_id La deduplicación funciona solo en flujos web, no en flujos de aplicaciones, y Google advierte que enviar una cadena vacía hace que Analytics deduplique. todas evento de compra que lleva transaction_id=''Ese único error puede arruinar casi todo el día. Además, la lista de referencias no deseadas está limitada a 50 dominios por flujo de datos, lo cual resulta problemático si se utilizan varios adquirentes, monederos y páginas bancarias.
[DATOS INTERNOS NECESARIOS: la distribución observada de estas nueve causas en los procesos de reconciliación de Switas, para que los lectores puedan ver cuáles suelen predominar.]
Paso 4: establece una tolerancia que puedas defender.
Google no publica ninguna cifra de discrepancia aceptable, y la cita tan extendida de que "un 5 % está bien" no aparece en ninguna documentación de Google que hayamos podido encontrar. Establezca la suya propia, basándose en la descomposición y no solo en el número.
| Brecha en el recuento mensual de pedidos | Reading | Acción: |
|---|---|---|
| Hasta un 2% | límites de zona horaria y deduplicación normal | Registrar las causas, revisar trimestralmente. |
| 2% a 5% | Aceptable únicamente si cada punto se atribuye a una causa específica. | Documentar y luego proceder a la experimentación. |
| 5% a 10% | Al menos una causa estructural sigue sin resolverse. | Corrija antes de confiar en los números de conversión absolutos. |
| Por encima de 10% | No apto para experimentación | Deje de usar las compras de GA4 como métrica principal del experimento hasta que se solucione. |
Estos son nuestros umbrales operativos, no un estándar de la industria. La clave está en la aclaración: un 3% sin explicación es peor que un 8% con explicación.
Paso 5: corregir en el orden que recupera la mayor cantidad de pedidos por hora de trabajo.
- Definición de valor y zona horaria. Configuración, no ingeniería, y normalmente una tarde.
- Identificadores de transacción duplicados y vacíos. Una corrección de dataLayer.
- Referencias entre dominios y referencias no deseadas. Configure ambos y, a continuación, vuelva a probar la ruta de devolución de pago en tiempo real, no en un entorno de prueba.
- Evento de compra del lado del servidor. Envíe la compra desde su sistema de pedidos con el Protocolo de medición, utilizando el
client_idTu etiqueta web se generó. Google requiere que estos eventos se registren dentro de las 48 horas posteriores a la marca de tiempo del evento original del lado del cliente; de lo contrario, la atribución podría no procesarse correctamente. Esto permite recuperar los pedidos perdidos debido a bloqueos y páginas de confirmación que nunca se cargaron. - Arquitectura del consentimiento. El proceso más lento y político. El resto debe considerarse una brecha conocida, cuantificada y documentada.
¿Qué cambia si vendes en Turquía o en la UE?
Dos factores regionales influyen en las cifras.
En Turquía, el consentimiento también es opcional, pero sin la red de seguridad de Google. La autoridad turca de protección de datos multó a un operador de sitio web con 300,000 TL en la decisión 2022/1358 (23 de diciembre de 2022) por utilizar cookies publicitarias y de marketing sin una base legal, y exigió el consentimiento explícito para las cookies no esenciales. Muchos sitios turcos respondieron con un banner que bloquea directamente la etiqueta de Google en lugar de uno que envía señales de modo de consentimiento. Esa distinción es costosa: modelar las necesidades analytics_storage='denied' eventos para que existan. Un banner que no emite nada no le da a Google ningún modelo, por lo que los datos se pierden en lugar de estimarse.
Los flujos 3DS turcos devuelven el comprador por POST. Con iyzico, el comerciante genera una página 3DS decodificada y, después de la confirmación del OTP, iyzico redirige al comerciante. callbackUrl con status, paymentId y mdStatusUna respuesta basada en POST es exactamente lo que Google denomina medición cruzada de ruptura, ya que las redirecciones pueden eliminar _gl antes de que se cargue el destino. Si la diferencia se encuentra en los pagos con tarjeta y es casi cero para el pago contra entrega, esta es la razón.
Dos afirmaciones muy repetidas que no pudimos verificar.
"Safari limita las cookies de origen a 7 días." Impreciso. La documentación de WebKit dice que ITP elimina las cookies de JavaScript y otros almacenamientos escribibles por scripts después de 7 días de sin interacción del usuarioAdemás, limita la duración de las cookies de JavaScript a 24 horas cuando se accede a la página de destino mediante un enlace desde un dominio de anuncios clasificados. Las pruebas realizadas por Simo Ahava revelaron que el contador se basa en los días de uso del navegador, no en los días naturales, por lo que un cliente recurrente puede conservar un identificador durante más de una semana.
"Una discrepancia del 5% es aceptable." No encontramos ninguna fuente en Google para esta cifra. Circula en blogs de proveedores y respuestas en foros. Úsela como información general, no como un valor de referencia.
Dónde falla este método
No cubre flujos de aplicaciones, donde transaction_id La deduplicación no se aplica, ni a los modelos de suscripción y envío parcial, donde "un pedido" no es un solo evento. No puede recuperar la identidad de un usuario que ha denegado su consentimiento, solo estimar el volumen. No corrige la atribución de canales, un problema aparte y más complejo. Además, presupone que su tabla de pedidos está limpia: si los pedidos cancelados y bloqueados por fraude se contabilizan de forma inconsistente en ambos lados, estará intentando solucionar un problema que solo existe en su consulta.
Preguntas frecuentes
¿Con qué frecuencia deberíamos ejecutar esto? Realice el análisis completo una vez y, a continuación, genere un gráfico de brechas diarias. Vuelva a ejecutar el análisis completo después de cualquier cambio en el proceso de pago, la plataforma de gestión de contenido (CMP), el proveedor de pagos o el gestor de etiquetas.
¿Por qué no utilizar la interfaz de GA4 en lugar de BigQuery? La interfaz puede incluir usuarios y sesiones modelados que la exportación no contempla, por lo que las dos cifras de Google no coinciden. Compararlas con una estimación hace imposible desglosar la diferencia.
¿El etiquetado del lado del servidor solucionará por completo esta brecha? No. Recupera los pedidos perdidos debido a bloqueadores y a páginas de confirmación que nunca se cargaron. No recupera a los usuarios que rechazaron dar su consentimiento.
GA4 es superior a nuestro backend. ¿Es eso posible? Sí. Por lo general, eventos de compra duplicados por actualizaciones de página, un vacío o reutilizado transaction_ido bien, órdenes de puesta en escena que se dirigen a la propiedad de producción.
¿El modo de consentimiento soluciona la brecha de consentimiento en Turquía? En parte. Las señales rechazadas permiten la elaboración de modelos, sujetos a los umbrales de volumen de Google. No sustituyen a un banner legal según la normativa turca.
¿Qué se considera un buen intervalo? Un sistema donde cada punto porcentual tiene un nombre. Un 8% documentado supera a un 3% sin explicación.
¿Deberíamos reformular los informes históricos después de solucionar esto? No. Anote la fecha de corrección y trate los períodos como series separadas. Volver a registrar las conversiones rastreadas destruye el registro de auditoría.
¿Podemos realizar pruebas A/B mientras la diferencia sea superior al 10%? Ejecútelas con métricas relativas medidas dentro de la herramienta de prueba, pero no informe el impacto absoluto en los ingresos de GA4 hasta que se haya desglosado la brecha.
Realice esta conciliación en su propia tienda este mes, o Deja que nuestro equipo de análisis lo ejecute contigo. y le entregaremos la descomposición, la tolerancia y el orden de corrección.
Fuentes
- [GA4] Modelado de comportamiento para el modo de consentimiento, Ayuda de Google Analytics
- [GA4] Minimizar eventos de clave duplicados con ID de transacción, Ayuda de Google Analytics
- [GA4] Referencias no deseadas, Ayuda de Google Analytics
- [GA4] Medición entre dominios, Ayuda de Google Analytics
- Enviar eventos del Protocolo de medición a Google Analytics, Google para desarrolladores.
- Parámetros del modo de consentimiento, documentación de Google Tag Platform
- Prevención de rastreo en WebKit
- Simo Ahava elimina el límite de caducidad de las cookies JavaScript en los navegadores WebKit.
- KVKK Kurul karari 2022/1358, 23 de diciembre de 2022
- Implementación de 3DS, documentación para desarrolladores de iyzico
