¿Te generan dudas los datos de Google Analytics?

1) Conectá Tag Assistant y confirmá que tu navegador aparezca en DebugView. 2) Completá el recorrido de prueba y anotá el ID del pedido. 3) Revisá el evento purchase y las etiquetas que lo envían a cada destino. 4) Recargá la confirmación y volvé a ella desde el historial: registrá cualquier nuevo envío. 5) Si hay reintentos previstos, pedí la evidencia de deduplicación para cada destino. Para comparar el total con la tienda, usá el control de conciliación: no hay un margen universal del 5% que valide la implementación.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: El pedido tiene un identificador estable y no genera compras adicionales en los destinos revisados. Cualquier reenvío previsto tiene un mecanismo de deduplicación comprobado.

Conviene investigar si: Una acción activa dos etiquetas para el mismo destino, cambia de ID al recargar o genera reenvíos cuya deduplicación no está comprobada.

Dejá DebugView abierto en una pestaña y navegá el sitio en otra como un visitante nuevo: Home, una categoría, un artículo del blog. En el flujo de eventos no tiene que aparecer ningún add_to_cart, begin_checkout, add_shipping_info ni purchase. Después entrá a un producto A y agregalo al carrito: tiene que aparecer un solo add_to_cart, justo cuando tocaste el botón. Hacé clic en ese evento y, en el detalle de la derecha, abrí el parámetro items (o la pestaña de artículos): el nombre o ID tiene que ser el del producto A. Sin vaciar el carrito, navegá a Home y a otra categoría: no tiene que aparecer ningún add_to_cart nuevo. Entrá a un producto B distinto y agregalo: aparece un segundo add_to_cart y sus items tienen que traer el producto B, no el A. Por último, andá al carrito y tocá el botón que lleva al checkout: begin_checkout tiene que aparecer una sola vez; volvé a la Home y fijate que no se repita.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Ninguna página de contenido dispara eventos de carrito o checkout; cada add_to_cart aparece una sola vez y con el producto que acabás de agregar; begin_checkout aparece solo al entrar al checkout y no se repite al navegar.

Conviene investigar si: Un add_to_cart o begin_checkout aparece al cargar la Home, se repite al navegar, o trae los datos del producto anterior.

1) Listá las acciones que existen en tu tienda: ver producto, agregar o quitar artículos, abrir carrito, iniciar checkout, informar envío o pago y confirmar una compra. 2) Con la depuración activa, realizá esas acciones y verificá sus eventos: view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info y purchase, según corresponda. 3) Repetí los recorridos relevantes por dispositivo y medio de pago. 4) Usá los informes históricos para detectar cortes o diferencias y contrastalos con el volumen de actividad. Un cero aislado o un paso omitido por diseño no demuestra una falla.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Los eventos previstos aparecen al realizar sus acciones y los pasos que no aplican están documentados.

Conviene investigar si: Realizás una acción prevista y su evento no llega, se repite o trae datos incorrectos. El contraste entre dispositivos o medios de pago muestra una diferencia que todavía no pudiste explicar.

1) Pedí el inventario de contenedores y destinos autorizados. 2) Recorré inicio, producto y checkout con Tag Assistant. 3) Compará los IDs detectados con ese inventario. 4) Para cada etiqueta adicional, verificá su propósito, responsable y destino. Puede haber varios IDs válidos o una etiqueta con varios destinos: la cantidad por sí sola no demuestra duplicación. 5) Si un ID es desconocido, documentalo antes de proponer su retiro.

Abrir en tu propiedad: Flujos de datos

Podés darlo por verificado si: Cada contenedor y destino tiene un propósito conocido y los eventos llegan a las propiedades previstas, sin duplicación no intencional.

Conviene investigar si: Hay un destino sin responsable, una propiedad anterior sigue recibiendo datos por error o dos implementaciones envían la misma acción al mismo destino.

1) Listá qué parámetros necesita cada evento según el plan de medición, por ejemplo tipo de página o estado de sesión iniciada. 2) En Tag Assistant, seleccioná el evento que activa la etiqueta y revisá los valores de sus variables en ese momento. 3) Contrastá los parámetros recibidos en DebugView. 4) No exijas datos que todavía no existen en ese paso, como la identidad de alguien que aún no inició sesión. Un valor configurado en una etiqueta no demuestra por sí solo su recepción: si no se puede comprobar en la interfaz, pedí revisar la solicitud enviada o el registro correspondiente.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Los parámetros requeridos para esa acción tienen valores correctos al enviarse y existe evidencia de su recepción.

Conviene investigar si: Faltan datos que deberían estar disponibles, llegan valores de una acción anterior o la variable se completa recién después de enviar el evento.

1) Definí qué páginas y vistas virtuales cuenta tu plan de medición. 2) Navegá una muestra que incluya producto, carrito y checkout con la depuración activa. 3) Verificá un page_view por cada vista prevista, con page_location y page_title correctos. 4) Si hay duplicados, revisá si coinciden una medición automática y una etiqueta manual sobre la misma vista. Pueden coexistir mecanismos para recorridos distintos; lo que hay que evitar es enviar dos veces la misma vista.

Abrir en tu propiedad: DebugView · Flujos de datos

Podés darlo por verificado si: Cada vista prevista genera un page_view con la URL y el título correspondientes.

Conviene investigar si: Una vista se duplica, una vista prevista no se registra o el evento conserva la URL o el título anterior.

1) Compará los nombres enviados con los recomendados para las acciones implementadas, respetando mayúsculas y guiones bajos. 2) En DebugView revisá items y la identificación de los productos; en purchase, también transaction_id, value y currency cuando se informa valor. 3) Contrastá productos y métricas en Compras de comercio electrónico. 4) Si un evento no figura en una lista reciente, reproducí su acción o ampliá el período antes de concluir que falta. Un informe vacío requiere revisar configuración, filtros y datos disponibles.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Las acciones implementadas usan los nombres previstos, sus parámetros identifican los productos y los informes reciben los datos necesarios.

Conviene investigar si: Hay nombres que no corresponden a los eventos recomendados, productos sin identificar o parámetros requeridos que no llegan en una prueba comprobable.

1) Confirmá cómo distingue tu equipo las pruebas del tráfico de clientes: propiedad separada, reglas de tráfico interno u otro criterio documentado. 2) Revisá que cubra los entornos y redes usados para probar. 3) Comprobá el estado de los filtros y su efecto antes de activarlos; la exclusión activa afecta los datos procesados de forma permanente. 4) Revisá los nombres de host y explicá los que no pertenecen a producción. No toda empresa tiene una IP fija de oficina y un filtro en pruebas puede ser una etapa deliberada de validación.

Abrir en tu propiedad: Flujos de datos · Filtros de datos

Podés darlo por verificado si: Existe un criterio documentado y validado para separar o reconocer las pruebas sin excluir tráfico de clientes por error.

Conviene investigar si: Los entornos de prueba contaminan los reportes usados para decidir, o un filtro excluye tráfico válido. Todavía no hay un método definido o no se comprobó su efecto.

1) Realizá una compra de prueba coordinada y anotá su ID. 2) Verificá el transaction_id enviado en purchase. Puede ser el número visible del pedido u otro identificador estable con correspondencia documentada. 3) Recargá la confirmación y comprobá que cualquier reenvío conserve el ID y se trate correctamente en cada destino. 4) Revisá una muestra de pedidos históricos. No descartes un ID solo por su formato ni uses el informe agregado como única prueba de que no hubo reenvíos.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Cada pedido se relaciona con un ID único que no cambia al reenviar la misma compra y que no contiene datos personales.

Conviene investigar si: El ID está vacío, cambia entre envíos de una misma orden, se reutiliza en compras distintas o no puede relacionarse con un pedido.

1) Coordiná una compra de prueba y verificá que se vea en DebugView. 2) Comprobá que value sea numérico y currency sea el código de la moneda enviada, como ARS, USD o BRL. 3) Según la definición de Google Analytics, value corresponde a la suma de price × quantity de los artículos, sin envío ni impuestos: shipping y tax se informan por separado. 4) Compará contra esos mismos componentes del comprobante. 5) Para comparar reportes, revisá la moneda de la propiedad y si la métrica descuenta reembolsos o incluye otros ingresos. No compares Ingresos totales con facturación sin revisar su composición.

Abrir en tu propiedad: DebugView · Detalles de la propiedad

Podés darlo por verificado si: El importe, la moneda y los componentes del pedido son consistentes con la definición del evento y la comparación usa la misma base.

Conviene investigar si: value llega como texto, usa centavos en lugar de unidades, tiene moneda incorrecta o incorpora componentes que no corresponden a su definición.

1) Anotá el precio de lista y el descuento de un producto. 2) Activá la depuración y completá la prueba. 3) Contrastá price, quantity y discount con el detalle de la operación. El precio enviado debe reflejar el descuento aplicado al artículo. 4) Revisá view_item y add_to_cart si están disponibles: una diferencia puede ser válida cuando se aplica un cupón o cambia la variante después. 5) Si purchase no aparece, comprobá el modo de depuración y si el envío ocurre desde el servidor antes de concluir que el evento falta.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: price corresponde al precio unitario vendido y cualquier variación durante el recorrido tiene una causa documentada.

Conviene investigar si: Se envía el precio de lista aunque se cobró otro, se resta dos veces el descuento o el precio no se relaciona con el artículo comprado.

1) Coordiná pruebas que cubran los descuentos y cargos de tu tienda. 2) Anotá value, shipping, tax y los price y quantity de los artículos. 3) Comprobá que value sea la suma de los importes de artículos después de descuentos, sin envío ni impuestos. 4) Revisá cómo esos componentes reconstruyen el comprobante, incluyendo cualquier recargo que deba tratarse por separado. 5) Si price ya refleja el descuento, no vuelvas a restarlo. Los descuentos de carrito necesitan una asignación coherente entre artículos; documentá diferencias de redondeo. Una regla que se repite de forma consistente también puede estar mal definida.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Los componentes permiten conciliar la operación con descuentos aplicados una vez y un criterio documentado para impuestos, envío, cargos y redondeos.

Conviene investigar si: Se duplica un descuento o un cargo, value incluye componentes incorrectos o los artículos no permiten explicar el valor de la compra.

1) En una prueba coordinada, agregá y quitá un producto; luego comprá otros dos, uno con más de una unidad. 2) Revisá que items contenga solo los productos comprados, con identificadores y cantidades correctas. 3) Contrastá una muestra de unidades por producto con la tienda usando iguales períodos, estados de pedido y criterios de reembolso. Un orden distinto entre los productos más vendidos es una señal para investigar, no una prueba automática de error.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Los artículos de la compra de prueba coinciden con el pedido y las diferencias históricas tienen una explicación o una investigación documentada.

Conviene investigar si: Aparece un producto retirado, faltan artículos, las cantidades no coinciden con la orden o existen diferencias de unidades todavía sin explicar.

1) Confirmá si tu implementación mide listas de productos y cómo conserva su contexto. Si no aplica, dejá el punto pendiente con esa explicación fuera del checklist. 2) Entrá desde una categoría o recomendación y seguí el recorrido de un producto. 3) Revisá item_list_name en los eventos e items donde el plan indica que debe enviarse. 4) Contrastá con los informes de listas usando métricas compatibles. No todas las compras vienen de una lista y una fila (not set) requiere contexto.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: La lista se conserva en los pasos definidos y las compras sin lista tienen una explicación acorde al recorrido.

Conviene investigar si: La lista cambia o desaparece donde el plan exige conservarla, o el informe no permite interpretar el origen de las compras que sí partieron de una lista.

1) Documentá qué estado del pedido representa purchase en tu negocio y cuándo se confirma una venta; contemplá medios de pago diferidos si existen. 2) Compará una muestra de IDs y estados con los eventos enviados. Un clic en pagar no alcanza para demostrar una compra. 3) Revisá reembolsos totales y parciales y el transaction_id de sus refund, si esa medición forma parte del alcance. 4) Para probar rechazo o cancelación, usá el entorno y los medios de prueba autorizados por la pasarela junto con tu equipo. No uses tarjetas de prueba en producción. 5) Una diferencia en los totales exige revisar fechas, estados, filtros y duplicación antes de atribuirle una causa.

Podés darlo por verificado si: Las compras corresponden al estado definido y los reembolsos que se miden se pueden vincular con la orden y el importe correspondiente.

Conviene investigar si: Se envía purchase por un intento fallido, un reembolso previsto no se registra o su ID o importe no corresponde al pedido.

1) Compará la cuenta vinculada con la que usa tu negocio, incluida la vinculación mediante una cuenta administradora si corresponde. 2) Revisá el etiquetado automático y cualquier plantilla o sufijo de seguimiento. 3) Confirmá que esas opciones respondan al plan de campañas. 4) Contrastá un período con actividad real y datos de campaña disponibles. Ver google / cpc no demuestra por sí solo que la vinculación funcione, y un nombre de campaña faltante puede tener varias causas. Si no tenés permisos, pedí la comprobación a quien administra las cuentas.

Abrir en tu propiedad: Vinculación con Google Ads

Podés darlo por verificado si: La vinculación y el etiquetado corresponden a las cuentas previstas, y su funcionamiento se respalda con configuración y datos.

Conviene investigar si: La cuenta vinculada no corresponde, el etiquetado previsto está desactivado o falta información de campañas que todavía no pudiste explicar.

1) Tomá la URL final de una campaña y probá si sus redirecciones conservan un parámetro de prueba, por ejemplo gclid=PRUEBA123; agregalo con ? o & según la URL. Esta prueba comprueba el transporte del parámetro, no valida un clic publicitario real. 2) Revisá con tu equipo la etiqueta de Google y el mecanismo de vinculación de conversiones que corresponda a la instalación. 3) Contrastá campañas con datos reales en Analytics. 4) Si el parámetro desaparece, investigá en qué paso y si la información fue capturada antes; no concluyas solo por la URL final. Clics y sesiones no son métricas equivalentes.

Podés darlo por verificado si: El recorrido conserva o procesa correctamente los identificadores previstos y la comparación con campañas reales respalda la implementación.

Conviene investigar si: Una redirección elimina información antes de capturarla o faltan datos de campaña sin una explicación comprobada.

1) Revisá la convención acordada para cada plataforma y tipo de campaña. 2) Contrastá una muestra de enlaces publicados con esa convención. 3) Buscá variantes por mayúsculas, abreviaturas o errores de escritura en los informes. 4) Diferenciá cambios accidentales de combinaciones válidas, como tráfico pago y orgánico desde una misma red. No hace falta reducir un canal a una sola fila. 5) En Google Ads revisá que las UTMs y el seguimiento no contradigan el etiquetado automático ni las reglas de tu implementación.

Podés darlo por verificado si: Las fuentes, medios y nombres permiten identificar las campañas sin fragmentación accidental, con las excepciones documentadas.

Conviene investigar si: La misma campaña usa variantes por error, faltan parámetros previstos o los nombres impiden comparar sus resultados.

1) Identificá los dominios de pago que intervienen en tus recorridos. 2) Revisá cuáles pueden generar referencias no deseadas y si su tratamiento está configurado correctamente. No excluyas socios o medios que sí aportan visitas. 3) Contrastá un recorrido antes y después del regreso de la pasarela y revisá el origen de la sesión. 4) Analizá datos posteriores a los cambios, porque una exclusión no reescribe el histórico. La exclusión de referencias no sustituye la medición entre dominios propios.

Abrir en tu propiedad: Flujos de datos

Podés darlo por verificado si: Las pasarelas no reciben crédito de adquisición por el solo regreso del pago, y el tratamiento está respaldado por pruebas.

Conviene investigar si: Una pasarela figura como origen por el regreso del checkout o el recorrido pierde información de sesión que todavía no se pudo explicar.

1) Listá los dominios que controlás y donde funciona la medición del mismo recorrido. No agregues una pasarela ajena donde no podés instalar tu etiqueta. 2) Si cruzás dominios distintos, revisá la configuración y la transmisión del parámetro _gl cuando corresponda. 3) Verificá la continuidad de los identificadores y de la sesión con tu equipo; la barra de direcciones o la ausencia de referrals no alcanzan como única prueba. 4) Los subdominios también necesitan una configuración de cookies compatible. Si el caso no aplica, dejalo pendiente y documentá el motivo fuera del checklist.

Abrir en tu propiedad: Flujos de datos

Podés darlo por verificado si: Las pruebas muestran continuidad de medición en los dominios previstos, sin referencias propias inesperadas.

Conviene investigar si: La configuración omite un dominio necesario, los identificadores se pierden o aparecen referencias propias que no se pueden explicar.

1) Anotá el peso de (not set) en Fuente/medio y Página de destino, y de Unassigned en el grupo de canales. 2) Revisá también Direct y compará períodos equivalentes. 3) Relacioná los cambios con campañas, consentimiento, checkout y publicaciones de etiquetas. No hay un umbral universal del 5% que determine si la medición está bien. 4) Para investigar, revisá el orden de configuración de la etiqueta, los parámetros de sesión y el contenido de los eventos. Un evento que no se ve en DebugView requiere comprobar primero las condiciones de depuración y consentimiento.

Podés darlo por verificado si: Conocés la evolución de estas filas, sus causas comprobadas y las diferencias que todavía requieren investigación.

Conviene investigar si: Hay una variación relevante sin explicar o una prueba muestra pérdida de información de origen, sesión o página.

1) Confirmá con tu equipo qué estados deben aplicarse al visitante y a la región de prueba. 2) Iniciá una sesión de prueba sin preferencias previas. 3) En Tag Assistant comprobá cuándo se establece el estado inicial y cuándo lo usan las etiquetas. 4) Probá aceptar, rechazar y no interactuar. 5) Revisá analytics_storage, ad_storage y los demás tipos configurados. El estado debe estar disponible antes de que una etiqueta actúe sobre él; la prueba no consiste solamente en contar eventos del banner.

Podés darlo por verificado si: Las etiquetas utilizan el estado previsto desde su primera ejecución y los cambios reflejan las elecciones del visitante.

Conviene investigar si: Una etiqueta usa un estado incorrecto o actúa antes de que esté disponible el consentimiento que necesita.

1) Confirmá si la implementación es básica o avanzada. 2) Probá el recorrido sin aceptar y después con aceptación. En modo básico las etiquetas de Google pueden permanecer bloqueadas hasta que haya consentimiento. En modo avanzado pueden enviar señales sin cookies bajo consentimiento denegado. 3) Contrastá el comportamiento con el modo acordado. 4) Revisá las condiciones adicionales de cada etiqueta antes de proponer cambios. Bloquear una etiqueta no es automáticamente un error; habilitar el modo avanzado tampoco garantiza acceso al modelado.

Podés darlo por verificado si: Las etiquetas se comportan según el modo documentado y respetan los estados de consentimiento en las pruebas.

Conviene investigar si: La configuración real contradice el modo acordado, el bloqueo impide un envío previsto o se envían datos o identificadores que no corresponden al estado de consentimiento.

1) Probá aceptar, rechazar y cambiar una elección anterior. 2) Comprobá que el estado actualizado refleje cada elección antes de los envíos que dependan de ella. Una actualización de Granted a Denied es válida cuando la persona retira el consentimiento. 3) Revisá si hay actualizaciones repetidas que reinician identificadores o contradicen la elección. 4) Con una campaña de prueba identificable, contrastá los datos de adquisición respetando filtros y tiempos de procesamiento. Una prueba filtrada o no consentida puede no verse en el informe; su ausencia no basta para diagnosticar la causa.

Podés darlo por verificado si: Cada elección deja el estado correcto y no se detectan cambios de identidad o de origen provocados por actualizaciones inconsistentes.

Conviene investigar si: El estado no refleja la elección, se sobrescribe sin una acción que lo explique o la prueba muestra pérdida de información que coincide con una actualización incorrecta.

1) Coordiná una compra de prueba con un ID conocido. 2) Identificá si purchase se envía desde el navegador, el servidor o ambos. 3) Revisá los IDs y los reintentos en los registros de cada origen. 4) Comprobá el resultado en Analytics cuando los datos estén procesados. Una fila agregada no revela todos los envíos que pudieron deduplicarse. 5) Si la compra no aparece, investigá filtros, consentimiento, depuración y procesamiento; no cambies la identidad de informes solo para completar el checklist.

Abrir en tu propiedad: DebugView

Podés darlo por verificado si: Los envíos del mismo pedido se relacionan con un identificador estable y el resultado no incorpora compras duplicadas.

Conviene investigar si: El mismo pedido usa IDs distintos, hay reenvíos sin tratamiento comprobado o el resultado registra una compra adicional.

1) Confirmá qué eventos deben pasar por el servidor y a qué propiedad llegan. 2) Realizá una acción de prueba y seguí sus solicitudes desde el navegador hasta el destino. 3) Revisá si además existe una instalación independiente que envía la misma acción directamente a la misma propiedad. 4) Identificá el propósito de cada solicitud: las señales auxiliares de la plataforma no equivalen necesariamente a eventos duplicados. Si no podés distinguirlas, pedí esa comprobación al equipo técnico.

Podés darlo por verificado si: El recorrido coincide con la arquitectura documentada y no hay una segunda implementación enviando el mismo evento por error.

Conviene investigar si: La misma acción se envía por dos instalaciones independientes sin un diseño que lo justifique, o parte del tráfico usa rutas de identidad incompatibles.

1) Usá un perfil de prueba sin cookies previas y probá rechazo, aceptación y retiro del consentimiento. 2) Comprobá que el estado recibido por el servidor corresponda al del navegador. 3) Revisá con tu equipo si las respuestas escriben cookies de Analytics, incluidas FPID si la implementación las usa, bajo analytics_storage denegado. 4) Contrastá las etiquetas que se ejecutan y los datos enviados con el modo básico o avanzado acordado. Ver solicitudes de red bajo rechazo no basta por sí solo para afirmar incumplimiento: hay que revisar qué se envía y cómo está configurado.

Podés darlo por verificado si: Los estados se transmiten y las etiquetas del servidor adaptan su comportamiento; no escriben cookies de Analytics cuando su almacenamiento está denegado.

Conviene investigar si: El servidor recibe un estado incorrecto, lo sobrescribe o una etiqueta escribe cookies o envía identificadores contrarios a la configuración de consentimiento.

1) Confirmá cuándo se activó el cambio y qué parte de la medición modificó. 2) Guardá períodos comparables de usuarios, sesiones, compras e ingresos antes y después. 3) Registrá también campañas, promociones, cambios del sitio y del consentimiento. 4) Contrastá con pedidos y ventas de la tienda. 5) Explicá qué variaciones tienen evidencia y cuáles siguen abiertas. Que una métrica cambie el día de la activación no demuestra por sí solo que la causa sea la nueva medición.

Podés darlo por verificado si: Existe una comparación documentada con fechas, definiciones, contexto y límites de interpretación.

Conviene investigar si: Se presenta una variación como crecimiento del negocio o recuperación de medición sin haber contrastado esas explicaciones.

1) Confirmá qué acciones se envían por navegador y servidor. Si la implementación usa un solo origen, documentá que este punto no aplica. 2) Coordiná una prueba e identificá sus copias por event_name y event_id. 3) Para ver envíos de servidor en la herramienta de prueba, puede hacer falta un código de prueba configurado por quien administra la integración. 4) Revisá las señales de deduplicación disponibles y los registros de envío. Una diferencia entre Meta y la tienda, o un porcentaje agregado mayor que cero, no comprueba por sí solo la deduplicación de esa compra.

Podés darlo por verificado si: Las copias de una misma acción comparten los identificadores previstos y existe evidencia de que se tratan como un único evento.

Conviene investigar si: Las copias usan IDs diferentes, falta el identificador necesario o se observan duplicaciones sin explicar.

1) Abrí el detalle de Purchase y buscá la evaluación de calidad de coincidencia de los eventos de servidor. 2) Revisá las recomendaciones y los parámetros faltantes o inválidos. 3) Contrastá con los datos que tu negocio puede enviar de forma válida y con el consentimiento correspondiente. No todos los identificadores están disponibles en todas las visitas. 4) Documentá el estado y las mejoras pertinentes con el responsable de la integración. El puntaje no valida el monto de compra, la deduplicación ni un resultado comercial.

Podés darlo por verificado si: La evaluación está revisada y no quedan errores de formato sin atender en los parámetros que corresponde enviar.

Conviene investigar si: Hay datos con formato inválido o recomendaciones relevantes sin revisar. Si no hay datos suficientes para evaluar, dejá el punto pendiente.

1) Coordiná una compra de prueba con un pedido identificable. 2) Revisá value y currency y, cuando corresponda a la integración, contents o content_ids. 3) Contrastá importe, moneda, productos y cantidades con el comprobante y la definición de valor usada por la cuenta. 4) Si el evento se envía solo desde el servidor, pedí el registro o una prueba de ese origen. La ausencia de avisos en Diagnóstico no demuestra que el importe sea correcto, y una diferencia de ROAS entre plataformas no identifica la causa.

Podés darlo por verificado si: Los datos enviados representan el pedido y el criterio de valor está documentado para la comparación.

Conviene investigar si: Faltan parámetros necesarios, la moneda o la unidad es incorrecta, aparecen otros productos o el importe no se puede conciliar.

1) Identificá las acciones que las campañas usan para optimizar. 2) Revisá su estado, el último dato recibido y cualquier aviso de diagnóstico. 3) Contrastá con un período en el que esperabas conversiones y considerá el tiempo de procesamiento. 4) Si no hay datos recientes, investigá la actividad y el origen de medición antes de concluir que está roto. 5) Anotá las alertas sin resolver y quién debe revisarlas.

Podés darlo por verificado si: Las acciones relevantes reciben los datos esperados o existe una explicación comprobada para la falta de actividad.

Conviene investigar si: Se interrumpe una acción con actividad esperada, hay alertas sin resolver o nadie puede explicar su estado.

1) Identificá el origen de la conversión. 2) Si usa una etiqueta de Google Ads en Google Tag Manager, compará su ID y etiqueta de conversión con los de la acción prevista; resolvé el valor de las variables si los campos no son literales. 3) Si proviene de Analytics, revisá la propiedad, el evento y la cuenta vinculada. 4) Considerá la medición mediante una cuenta administradora si tu organización la usa. 5) Comprobá el envío en una prueba coordinada. No cambies IDs durante el autodiagnóstico.

Abrir en tu propiedad: Vinculación con Google Ads · Eventos clave

Podés darlo por verificado si: La configuración apunta a la acción y la cuenta previstas y la prueba respalda ese destino.

Conviene investigar si: El ID, la etiqueta o la vinculación corresponden a otra acción, cuenta o propiedad sin una razón documentada.

1) Listá las acciones que representan la misma venta, por ejemplo una etiqueta de Ads y una importación de Analytics. 2) Revisá cuáles son principales y qué objetivos usa cada campaña. 3) Comprobá que dos copias de la misma compra no entren a la optimización por error. 4) Revisá también objetivos personalizados: pueden usar acciones secundarias para pujar. 5) Documentá por qué una campaña usa compras, leads u otras acciones. Puede haber varias acciones válidas cuando representan resultados distintos; no se decide contando cuántas son principales en toda la cuenta.

Podés darlo por verificado si: Cada campaña usa los resultados definidos para su objetivo, sin sumar dos veces la misma venta por fuentes duplicadas.

Conviene investigar si: Dos copias de la misma compra alimentan la optimización o se incluyen acciones que no corresponden al objetivo de esa campaña.

1) Abrí cada acción relevante y anotá si cuenta Una o Todas/Cada conversión, según la etiqueta de la interfaz. 2) Para ventas, comprobá si necesitás contar cada compra. Para leads, evaluá si tiene sentido contar uno por interacción o cada resultado. 3) Documentá el criterio con quien administra las campañas. 4) Revisá la identificación de pedidos por separado: elegir Una no reemplaza la deduplicación de compras y puede ocultar compras distintas válidas.

Abrir en tu propiedad: Eventos clave

Podés darlo por verificado si: El recuento responde a la definición de negocio y su configuración está documentada.

Conviene investigar si: La configuración descarta resultados válidos, suma repeticiones sin valor o se usa como sustituto de corregir duplicados.

1) Confirmá si la implementación usa conversiones avanzadas y desde qué origen las administra. Si no aplica, documentalo sin marcar una verificación que no hiciste. 2) Revisá los avisos de datos faltantes, formato y actividad reciente. 3) Contrastá cualquier falta de datos con el volumen esperado y el consentimiento. 4) Si hay importaciones, revisá el resultado y una muestra de filas rechazadas. Un aviso de clic no encontrado necesita investigación; no demuestra por sí solo que la venta venga de otro canal.

Podés darlo por verificado si: La configuración prevista funciona y las alertas relevantes o los errores de carga tienen una explicación y tratamiento documentados.

Conviene investigar si: Hay errores de formato, envíos fallidos o una interrupción de datos esperados que todavía no se pudo explicar.

1) Revisá quién tiene acceso a la cuenta y quién puede leer, editar, aprobar o publicar en el contenedor. 2) Confirmá que cada permiso responda al trabajo actual de esa persona o equipo. 3) Identificá quién autoriza y quién publica cambios. 4) Verificá que la organización conserve acceso administrativo y una alternativa si una persona deja de estar disponible. 5) Documentá accesos a revisar; no retires permisos durante el checklist.

Podés darlo por verificado si: La organización conserva el control, hay responsables de publicación y los permisos corresponden a funciones actuales.

Conviene investigar si: Hay publicadores sin responsable conocido, accesos de colaboradores anteriores o dependencia de una única persona para administrar la cuenta.

1) Revisá varias versiones recientes, incluida la publicada. 2) Comprobá que puedas identificar qué cambió, por qué, quién lo aprobó y qué pruebas se hicieron. 3) Revisá si el registro enlaza la evidencia correspondiente cuando está en otra herramienta. 4) Confirmá que el equipo sepa qué versión restaurar y cómo validar una reversión. El detalle no tiene que estar íntegramente en el nombre de la versión, pero debe ser localizable.

Podés darlo por verificado si: Cada publicación revisada tiene un cambio comprensible, responsable y evidencia de pruebas.

Conviene investigar si: No se puede reconstruir qué se publicó, quién lo autorizó o cómo se comprobó su funcionamiento.

1) Compará las etiquetas activas con el inventario vigente. 2) Revisá las que están pausadas, apuntan a cuentas anteriores o tienen nombres ambiguos. 3) Pedí su propósito y responsable; una etiqueta pausada puede tener una razón válida. 4) Documentá cuáles conviene retirar y qué dependencias hay que comprobar antes. No borres una etiqueta por su nombre ni porque esté pausada.

Podés darlo por verificado si: Las etiquetas tienen un propósito y destino conocidos; las que ya no se usan cuentan con una decisión documentada.

Conviene investigar si: Quedan destinos desconocidos, etiquetas activas de instalaciones anteriores por error o elementos sin propósito que dificultan el mantenimiento.

1) Elegí un período cerrado con tiempo suficiente para que se procesen los datos. 2) Documentá fechas, estados del pedido, moneda, zona horaria, reembolsos y tratamiento de envío e impuestos. 3) Usá métricas de compras e ingresos compatibles; Recuento de eventos, Transacciones e Ingresos totales no son intercambiables. 4) Compará totales y una muestra de IDs cuando esté disponible. 5) Si calculás (Analytics − tienda) / tienda × 100, hacelo por métrica y solo cuando el denominador sea distinto de cero. 6) Registrá la revisión semanal y las diferencias abiertas. Estabilidad no equivale a corrección ni un mayor total demuestra duplicación por sí solo.

Podés darlo por verificado si: La comparación tiene una base común, una revisión periódica y explicaciones respaldadas o investigaciones abiertas identificadas.

Conviene investigar si: Se comparan métricas incompatibles, cambian los criterios sin registro o hay diferencias relevantes que nadie revisa.

1) Identificá qué control vigila compras, ingresos u otros eventos relevantes. 2) Revisá la condición, frecuencia, segmento y destinatarios. En Analytics las estadísticas personalizadas pueden enviar avisos por email. 3) Contrastá el umbral con el volumen y la estacionalidad del negocio. 4) Revisá una alerta anterior o una prueba controlada del sistema de monitoreo, sin generar compras falsas en producción. 5) Documentá quién investiga y en qué plazo. Una alerta indica una variación; su causa puede ser de medición o del negocio.

Podés darlo por verificado si: El control tiene una condición útil, destinatarios vigentes y evidencia de funcionamiento o de una prueba controlada.

Conviene investigar si: No existe un control, los avisos no llegan al responsable o las condiciones generan alertas que el equipo no puede interpretar.

1) Revisá qué necesidad cubre cada dimensión y cuántos valores distintos puede generar. 2) Identificá IDs únicos o marcas de tiempo registrados sin una necesidad justificada; pueden aumentar la cardinalidad. 3) Revisá si aparece (other) y cuánto detalle agrupa en el informe. Esa fila puede tener más de una causa y no demuestra que una dimensión concreta sea responsable. 4) Para analizar pedidos individuales, evaluá las dimensiones estándar y, cuando haga falta, datos exportados con tu equipo.

Abrir en tu propiedad: Definiciones personalizadas

Podés darlo por verificado si: Las dimensiones tienen un propósito documentado y el nivel de detalle disponible alcanza para el análisis previsto.

Conviene investigar si: Se consume capacidad con valores únicos sin una necesidad clara o la agregación impide responder la pregunta del informe.

1) Abrí los informes que usás habitualmente. 2) Leé el indicador de calidad y registrá si informa umbrales, muestreo, modelado u otra limitación. 3) Evaluá cómo afecta la pregunta que querés responder. 4) Si corresponde, compará un rango más amplio o quitá una dimensión que no sea necesaria. 5) No cambies la identidad de informes como arreglo automático: puede cambiar la lectura de usuarios y requiere una decisión documentada. Usar todos los datos disponibles no demuestra que se hayan observado todas las acciones reales.

Abrir en tu propiedad: Identidad de informes

Podés darlo por verificado si: Los informes permiten el análisis previsto y sus limitaciones están identificadas y consideradas en las conclusiones.

Conviene investigar si: Se toman decisiones sobre un detalle oculto o incompleto sin haber revisado el aviso de calidad.

1) Listá los parámetros personalizados que necesitás usar en informes. 2) Revisá si requieren una dimensión o una métrica personalizada, o si ya existe un campo estándar que los cubre. No registres cada parámetro enviado por defecto. 3) Comprobá nombre y alcance: evento, usuario o artículo, según corresponda. 4) Contrastá su recepción y analizá datos posteriores al registro, dejando tiempo de procesamiento. El registro no reconstruye el histórico. 5) Si no aparece información, revisá la compatibilidad de la exploración, filtros y datos disponibles antes de asignar una causa.

Abrir en tu propiedad: DebugView · Definiciones personalizadas

Podés darlo por verificado si: Los campos necesarios para el análisis están registrados cuando corresponde, con nombre, tipo y alcance correctos, y muestran datos compatibles.

Conviene investigar si: Un parámetro necesario llega pero no puede usarse por una definición ausente o incorrecta, o se registran campos redundantes sin propósito.