11 de septiembre de 2026 · Germán Muñoz Moreno, Co-fundador
Cómo saber si la misma compra se está contando dos veces

Creo que mis conversiones se están contando dos veces. ¿Cómo lo reviso y cómo lo pruebo?
El doble conteo es la sospecha a la que todos llegan tarde o temprano, normalmente después de sumar lo que reclaman las plataformas y encontrar un número más grande que las ventas que hicieron. La sospecha muchas veces es correcta. Lo que la vuelve difícil de accionar es que tres problemas genuinamente distintos comparten el nombre, y cada uno necesita una revisión distinta, en un lugar distinto, con evidencia distinta.
Tres problemas que se ven iguales en una gráfica
El primero es una plataforma contando tu evento dos veces, porque mandas la misma compra desde el navegador y desde el servidor y no pudo darse cuenta de que eran la misma. El segundo es dos plataformas reclamando cada una la misma orden, que no es un error de ninguna. El tercero es tu propio reporte metiendo una orden bajo dos canales.
Producen el mismo síntoma, un total inflado, y no tienen nada más en común. Averiguar cuál tienes es la mayor parte del trabajo.
Uno: la misma plataforma contando tu evento dos veces
Éste es el que sí es un defecto de verdad, y la buena noticia es que la plataforma normalmente te lo va a decir.
Pasa porque mandar las compras dos veces es la práctica correcta. El evento del navegador se pierde cada vez que se interpone un bloqueador, la protección de rastreo o un checkout fuera del dominio, así que la mayoría de las tiendas manda además la compra del lado del servidor desde el webhook de la orden. Lo que vuelve segura esa redundancia en vez de dañina es que los dos eventos llevan el mismo ID de evento, que es la llave con la que la plataforma los colapsa en uno.
Cuando los dos lados generan sus IDs por separado, o uno lo omite, la plataforma recibe dos compras sin manera de saber que son la misma. En Meta, mira los diagnósticos de Purchase en el Administrador de eventos buscando eventos de compra redundantes, y lee la retroalimentación de deduplicación, que reporta qué parte de los eventos se colapsó de verdad y sobre cuál llave. Ésa segunda es la revisión más fuerte: confirma que el mecanismo está funcionando en vez de solo avisar cuando no lo hizo.
Google no tiene una red equivalente de ID de evento para las subidas de conversiones offline, pero sí rechaza un id de orden repetido, y esos rechazos aparecen en los diagnósticos de subida. Una racha de errores de id de orden duplicado es tu candado fallando, lo que normalmente significa que los webhooks de orden están reintentando y nada está registrando que la venta ya se mandó.
Dos: dos plataformas reclamando la misma orden
Un comprador hace clic en un anuncio de búsqueda de Google el martes, ve un anuncio de Meta el jueves, y compra el viernes. Las dos plataformas tienen un reclamo defendible sobre esa única orden, y las dos la reportan como una conversión. Ninguna puede ver el contacto de la otra, así que ninguna es capaz de ajustar por él.
Esto no es un error que haya que arreglar en ninguna de las dos. Es una propiedad de cómo están construidas, y se vuelve un error de conteo solo en el momento en que las sumas. Ese momento ocurre constantemente, en cada hoja de cálculo que pone las plataformas como filas y totaliza la columna.
Tres: tu propio reporte partiendo una orden en dos
Éste es el más fácil de que se te pase, porque nada lo rechaza y no existe ningún diagnóstico para él. Ocurre de dos formas: un modelo multi-touch asigna crédito fraccionado y algo más abajo redondea o lee las fracciones como órdenes enteras, o una taxonomía de canales mete la misma orden bajo dos etiquetas porque empató con dos reglas.
La revisión es aritmética y toma un minuto. Tus conteos de órdenes por canal tienen que sumar tu total de órdenes, con una línea explícita para las órdenes que no se pudieron atribuir a nada. Si no existe esa línea, eso ya vale la pena investigarlo por sí solo, porque en todo conjunto de datos hay órdenes no atribuibles y un reporte que nunca las muestra las está escondiendo en algún lado.
La prueba que demuestra el segundo tipo
El primero y el tercero se encuentran inspeccionando. El segundo no se puede, porque las dos plataformas están reportando bien y ninguna tiene la información que revelaría el traslape. Hace falta una referencia externa, y hay exactamente una disponible.
Una plataforma puede resolver legítimamente a un comprador que tú nunca viste: alguien que bloqueó tu pixel, alguien que convirtió desde una vista sin hacer clic nunca. Así que una plataforma que reclama más de lo que tú mediste no es por sí sola evidencia de nada. Pero ninguna plataforma puede resolver una orden que no existe. El conteo de órdenes liquidadas de tu tienda en una ventana es un techo duro sobre lo que todas las plataformas juntas pueden reclamar con verdad sobre ella.
Toma una ventana. Suma lo que reclama cada plataforma conectada para ella. Compáralo contra las órdenes que tu tienda liquidó de verdad en la misma ventana. Debajo del techo no se prueba nada y la descripción honesta es que parte del reclamo no es verificable. Por encima, el exceso es aritmética que no puede ser verdad, y se puede probar sin saber cuál plataforma lo causó.
Cuatro cosas que rompen la prueba
Cada una de éstas produce una respuesta equivocada con toda confianza, que es peor que ninguna respuesta.
Usa la acción de compra, no el conteo total de conversiones de una plataforma. La métrica de conversiones de Google suma todas las acciones de conversión configuradas, así que compararla con órdenes mide tu configuración y puede dar varios cientos por ciento en una cuenta perfectamente sana.
Empareja cada cuenta publicitaria con las tiendas para las que realmente anuncia. Comparar una cuenta entera contra una marca de varias es la causa más común de un techo que se ve roto sin estarlo.
No la corras sobre una ventana cuyos últimos días siguen abiertos. El retraso de liquidación por sí solo va a fabricar ventas imposibles, porque la plataforma ya reclamó conversiones de órdenes que tu tienda no ha terminado de registrar.
Apaga cualquier filtro de clientes nuevos. Angosta tu lado de la comparación a compradores de primera vez mientras el lado de la plataforma queda entero, lo que fabrica una diferencia de la nada.
Qué hacer con la respuesta
Si encuentras el primer tipo, arregla el ID de evento y el candado, y espera que tus conversiones reportadas bajen. Esa caída es la corrección, no una pérdida.
Si encuentras el segundo tipo, probaste que la suma de tus reportes de plataforma no es una cifra de ventas. El arreglo no es discutir con una plataforma. Es dejar de sumarlas y anclar tu reporte en las órdenes, para que cada número de plataforma se lea como un reclamo sobre una lista que existe en vez de como una fila que hay que sumar.
Preguntas frecuentes
¿Dónde encuentro los eventos de compra redundantes en Meta?
En el Administrador de eventos, abre el conjunto de datos, ve a los diagnósticos del evento Purchase y busca la entrada de eventos de compra redundantes. Aparece cuando Meta recibió un evento de navegador y uno de servidor que no pudo colapsar. Meta además publica retroalimentación de deduplicación por llave, que te dice qué parte de tus eventos se colapsó de verdad y sobre cuál identificador, y ésa es la señal más fuerte porque confirma el mecanismo en vez de solo marcar el síntoma.
¿Es doble conteo si Meta y Google reclaman la misma orden?
No de parte de ninguna de las dos. Cada una vio un contacto real dentro de su propia ventana y lo reportó bien; ninguna puede ver a la otra. Se vuelve un error de conteo solo cuando sumas sus números y lees la suma como ventas totales, que es exactamente lo que te invita a hacer una hoja de cálculo con las plataformas en filas.
Los reclamos de mis plataformas están por debajo de mi conteo de órdenes. ¿Eso significa que no hay nada mal?
Significa que no hay nada demostrablemente mal. Debajo del techo, el doble conteo y el reporte honesto se ven idénticos desde fuera, porque una plataforma puede resolver legítimamente a un comprador que tú nunca viste. Lo que sí puedes decir es cuánto del reclamo está verificado contra una orden real y cuánto no, que es una frase más útil que un veredicto en cualquier dirección.
¿La misma orden puede contarse dos veces dentro de mi propio panel?
Sí, y es el tipo más fácil de que se te pase porque nada lo rechaza. Pasa cuando un modelo multi-touch asigna crédito fraccionado y algo más abajo lee esas fracciones como órdenes enteras, o cuando una taxonomía de canales mete una orden bajo dos etiquetas. La revisión es aritmética: tus conteos por canal tienen que sumar tu total de órdenes, con una línea explícita para lo que no se pudo atribuir.
¿La prueba del techo funciona en un solo día?
No, y correrla así es la forma más común de sacar un falso positivo. Las plataformas reportan en la fecha del clic o de la impresión mientras tu tienda reporta en la fecha de la orden, así que un solo día compara dos bases distintas y puede romper un techo que la ventana entera no rompe. Usa una ventana lo bastante larga para absorber el desfase, y excluye los días que todavía no liquidan.
