Tu analítica dice que el sitio hizo 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 buena, 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.
El evento de compra suele vivir 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 está más alta que la base de pedidos, el hueco es un múltiplo limpio 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 desduplique por é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 redispara 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.
Algunas herramientas convierten a una divisa de reporte 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.
La disposición más segura es que la divisa se estampe 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 dicha con confianza.
3. Reembolsos, cancelaciones y cobros fallidos
Tu base de pedidos es un registro vivo. 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 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 libro mayor no tuvo nunca.
4. Eventos bloqueados, perdidos y nunca enviados
Esta siempre desinfla, y es por lo que la analítica suele estar 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 falta todo el que rechazó. 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 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 en la que esté puesto 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. Una frontera 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.
- Haz la unión por identificador de pedido.
Los cuatro cajones 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. Las parejas emparejadas con valores distintos son un problema de divisa, o un desajuste entre importes con y sin impuestos. Las parejas emparejadas en días distintos son de 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 se estampan con su divisa en el momento en que se guardan, y Skomi no convierte nunca entre divisas: un informe que cubra dos divisas enseña 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 ganó y no a la página en la que se pagaron, y la divisa de ingresos se estampa en la ingesta y no se convierte nunca.