Tu analítica dice que el sitio facturó 42 180 el mes pasado. Tu base de pedidos dice 39 650. Alguien pregunta cuál tiene razón, y la respuesta honesta suele ser ninguno de los dos, por motivos individualmente aburridos y colectivamente caros.
Aquí están las cinco causas, más o menos en el orden de la frecuencia con la que cada una resulta ser la culpable, con una forma de distinguirlas.
1. La página de confirmación se dispara más de una vez
Es con diferencia la causa más común, y siempre infla la cifra.
El evento de compra suele estar en la página de confirmación de pedido. Esa página se vuelve a cargar cada vez que alguien la refresca, le da a atrás y luego a adelante, la abre desde su correo, o se la restaura un navegador que reabre pestañas al arrancar. Cada uno de esos casos vuelve a disparar el evento con el mismo valor.
Lo reconoces por la forma de la discrepancia: la analítica da una cifra más alta que la base de pedidos, la diferencia es un múltiplo exacto en un puñado de pedidos grandes, y el efecto es peor en móvil, donde la navegación hacia atrás es más frecuente.
La solución es un identificador de transacción. Manda el número de pedido con el evento de compra y deja que la analítica elimine los duplicados con él. En GA4 el campo se llama transaction_id; la mayoría de las herramientas usan ese nombre porque la convención de GA ganó. Si la plantilla de tu gestor de etiquetas tiene un campo para eso y lo dejaste vacío, ese es tu fallo.
Vale la pena ser directo sobre lo que cuesta equivocarse aquí. Una página de compra que se vuelve a disparar y cuenta una sola venta cuatro veces no parece un error en un panel. Parece un buen mes.
2. Dos divisas sumadas
Si vendes en más de una divisa y tu analítica informa de un total único de ingresos, averigua qué está haciendo antes de fiarte de ella.
Algunas herramientas convierten a una divisa de referencia a un tipo fijado cuando llegaron los datos. Algunas convierten al tipo del día en que miras, lo que significa que un mes terminado cambia de valor según cuándo lo abras. Algunas simplemente suman los números y ponen un símbolo delante, produciendo una cifra que no es dinero en ninguna divisa.
La señal es un total que se sitúa entre la cifra convertida correcta y la suma ingenua, o un total que se mueve cuando reabres un informe de un mes cerrado hace tiempo.
Lo más seguro es que la divisa quede registrada en el evento cuando se guarda y que la herramienta no convierta nunca. Un informe con varias divisas o se divide por divisa, o se niega a dar un total único, y las dos cosas son más útiles que una cifra falsa presentada con aplomo.
3. Reembolsos, cancelaciones y cobros fallidos
Tu base de pedidos está siempre al día. Sabe que el pedido 8814 se reembolsó el día 14. Tu analítica registró la compra el día 2 y, salvo que le mandaras un evento de reembolso, sigue creyendo en ella.
En un mes con tasas de devolución normales, esto por sí solo puede explicar varios puntos porcentuales, y es la causa que hace que la analítica parezca alta frente a un informe financiero en vez de frente a una tabla de pedidos.
Relacionado, y más fácil de pasar por alto: un pedido creado pero nunca cobrado. Si el evento se dispara en la página de confirmación y el pago falla después, o el pedido se queda sin pagar y se cancela por expiración, la analítica tiene una venta que tu contabilidad no tuvo nunca.
4. Eventos bloqueados, perdidos y nunca enviados
Esta siempre resta, y es la razón de que la analítica suela dar una cifra más baja que la tabla de pedidos cuando no la están inflando las causas de arriba.
Los bloqueadores de contenido paran la petición. Algunas redes corporativas también, algunos filtros a nivel de DNS, y algunos navegadores centrados en la privacidad de serie. Si tu analítica necesita consentimiento, también faltan todos los que lo rechazaron. Y un evento de compra que se dispara al cargar la página echa una carrera contra el visitante que cierra la pestaña, cosa que hace muy a menudo en el instante en que se confirma el pedido.
El tamaño de la fracción bloqueada varía enormemente según el público (un sitio de herramientas para desarrolladores pierde muchísimo más que una floristería), así que cualquier porcentaje publicado no vale nada para tu caso. Mide el tuyo: cuenta los pedidos que registró tu base frente a los eventos de compra que registró la analítica, emparejados por identificador de pedido, en una sola semana limpia.
Si no puedes emparejar por identificador de pedido, esa es otra vez la causa número 1.
5. Los dos sistemas están contando momentos distintos
Por último, la causa aburrida, la que explica el pequeño residuo que queda después de haber arreglado todo lo demás.
La analítica fecha el evento dentro de la sesión del visitante, en la zona horaria configurada en el informe. Tu base de pedidos fecha la fila cuando el proveedor de pago confirmó, en UTC, quizá minutos después y a veces al otro lado de medianoche. Un cambio de mes convierte eso en una diferencia real: siempre en el mismo sentido, siempre pequeña.
La atribución se suma a ello. La analítica asigna los ingresos a la sesión que convirtió (o a alguna sesión anterior, según el modelo de atribución), mientras que tu tabla de pedidos no los asigna a nada. Comparar un total de ingresos de último clic con un total bruto de pedidos es comparar las respuestas a dos preguntas distintas.
Un cuadre que puedes hacer de verdad
- Elige una semana que haya cerrado.
- Exporta los pedidos: identificador, marca de tiempo en UTC, divisa, valor neto tras reembolsos.
- Exporta los eventos de compra con los mismos campos.
- Cruza los datos por identificador de pedido.
Los cuatro grupos que salen son el diagnóstico. Los eventos sin pedido son disparos dobles o tráfico de prueba. Los pedidos sin evento son bloqueo o una etiqueta rota. Los pares coincidentes con valores distintos son un problema de divisa, o un desajuste entre importes con y sin impuestos. Los pares coincidentes en días distintos son cosa de la zona horaria.
Haz esto una vez, apunta el residuo en porcentaje, y tienes algo mucho más valioso que un total que cuadre: una diferencia conocida y estable. Dos sistemas que difieren en un 4 % constante son los dos utilizables. Dos sistemas que coinciden por casualidad no lo son.
Dónde se sitúa Skomi
Skomi lee el identificador de pedido de order_id, y también del transaction_id de GA, así que un sitio ya etiquetado para GA4 no tiene que cambiar nada. Un evento que lleve un identificador que ya ha visto no se cuenta otra vez.
Los ingresos quedan registrados con su divisa en el momento en que se guardan, y Skomi no convierte nunca entre divisas: un informe que cubra dos divisas muestra dos cifras, porque la cifra única sería una ficción. Hay más en la página de Analytics, e instalar el fragmento cubre el envío del evento.
Dos definiciones hacen casi todo el trabajo aquí: los ingresos se atribuyen a la visita que los generó y no a la página en la que se pagaron, y la divisa de ingresos se fija en la ingesta y no se convierte nunca.