Los 10 errores más comunes en el comercio electrónico (implementado a través de GTM)
El Comercio Electrónico Mejorado (EE) es probablemente la característica de rastreo web más poderosa del conjunto de herramientas de Google Analytics (intencionadamente añadí la palabra «probablemente» para tener más o menos razón #graciasCarlsberg). Permite rastrear no sólo el objetivo final (compra o algo similar) sino también todo el embudo (a partir de la impresión del producto).
Sin embargo, con un gran poder viene una gran responsabilidad (léase: para implementar correctamente EE se enfrentarán muchos desafíos, problemas, matices, una documentación bastante extensa (para un ojo inexperto), y algunos requisitos no tan intuitivos). No siempre es así. Cuantas más implementaciones de EE hagas, mejor lo harás. Sin embargo, los pasos iniciales están llenos de trampas y probablemente aprenderás las lecciones de la manera más difícil.
Aunque hay algunos recursos muy útiles relacionados con EE en línea, la gente todavía tiende a cometer los mismos errores una y otra vez (al menos eso es lo que se siente cuando veo otra entrada en la comunidad GTM sobre el problema del Comercio Electrónico Mejorado que se discutió hace una semana o dos).
Pero lo entiendo perfectamente. El tema es complejo, hay muchas cosas que hay que entender y tener en cuenta, algunas guías pueden parecer demasiado complicadas, y, al final, los mejores maestros resultan ser nuestros propios errores. Sin embargo, esos errores pueden costar mucho tiempo y dinero. Por eso decidí añadir también mis dos céntimos al ecosistema de entradas de blog/guías sobre EE. UU. En este artículo, compartiré los errores de EE. UU. que más a menudo observo en las implementaciones de Google Tag Manager de otros (o en las preguntas de las comunidades de Google Tag Manager).
Antes de continuar: La implementación de EE (a través de GTM) se explica detalladamente en mi curso Intermedio
El GTM es uno de los ingredientes más importantes. Descubriré y explicaré muchas de las características subutilizadas del Tag Manager pero, lo más importante, abordaré algunos de los mayores dolores que los vendedores y analistas digitales enfrentan en el seguimiento web:
- iFrames y el seguimiento entre dominios
- Cooperación con los desarrolladores
- Pruebas y depuración adecuadas
- Mejora del comercio electrónico, etc.
Los errores más comunes en el comercio electrónico mejorado
No todos estos elementos de la lista se consideran errores críticos. Algunos pertenecen a la zona de «sería mejor que hicieras esto».
Si ves que faltan algunos errores muy comunes en esta lista (lo cual es totalmente posible), házmelo saber en los comentarios y los añadiré aquí.
Error número 0. No estudiar suficientemente bien los recursos relacionados con la EE y tratar de apostar por tu intuición
La mayoría de los errores que se mencionan a continuación se deben (creo) a que la gente no lee los recursos disponibles en línea(los documentos oficiales).
Mi opinión es que rápidamente se rozan algunas partes y tratan de averiguar el resto a lo largo del camino. ¿El resultado? Bueno, esta entrada del blog se considera una de ellas.
Error # 1. Usar la etiqueta de transacción de Universal Analytics
Si estás familiarizado con la implementación del Comercio Electrónico Estándar GA, ya sabes que la compra debe ser rastreada con una etiqueta de transacción.
Sin embargo, este tipo de etiqueta de Análisis Universal funciona sólo con el Comercio Electrónico Estándar. En el caso del comercio electrónico mejorado, la información sobre todos los pasos del embudo (incluida la compra) debe enviarse ya sea con una vista de página o con una etiqueta de evento (con las características del comercio electrónico mejorado habilitadas). La etiqueta de transacción no funcionará.
Error 2. No seguir la estructura (y la convención de nombres) de los fragmentos de dataLayer.push
Así que aquí está el principio principal de cómo funciona la implementación del Comercio Electrónico Mejorado a través de GTM. Un desarrollador empuja los datos de comercio electrónico a la Capa de Datos (por ejemplo, impresión del producto, clic del producto, añadir al carrito, compra, etc.), luego dispara la etiqueta de Analítica Universal (con características de Comercio Electrónico Mejorado habilitadas) que envía los datos de EE (de la Capa de Datos) a Google Analytics.
Pero aquí está la trampa: un desarrollador no puede simplemente empujar algunos datos aleatorios de comercio electrónico a la Capa de Datos. Los datos deben ser formateados (y usar la misma convención de nombres) como se describe estrictamente en la documentación oficial del GTM (para el Comercio Electrónico Mejorado).
En el dataLayer.push siempre debe haber un objeto de comercio electrónico que contenga ciertos datos relacionados con un paso de embudo en particular. Luego debe haber el nombre de la acción (por ejemplo, añadir, eliminar , comprar, pasar por caja, etc.) y luego algunos datos relacionados con esa acción en particular.
dataLayer.push no tiene que incluir todos los campos relacionados con la compra que se muestran en la documentación (porque algunos son opcionales), sin embargo, si decide incluir un parámetro en particular, asegúrese de que un desarrollador utilice la clave del atributo tal y como se muestra en los documentos oficiales.
Además, los tipos de datos de esos atributos deben ser los que requiere Google. Si los productos que se muestran en la documentación son un array, entonces debe ser un array.
Error 3. No ser consistente
No hay casi ninguna atribución en Enhanced Ecommerce. Esto significa que si se hace un seguimiento de los productos y, por ejemplo, se envía el nombre del producto a la AG (en el paso del embudo «añadir al carrito»), esos datos no estarán disponibles automáticamente en los informes de la AG de los pasos del embudo posteriores (por ejemplo, la caja o la compra). Olvídese de los alcances de la sesión o del usuario aquí. La única forma de asegurarse de que los datos (por ejemplo, el nombre del producto) persisten en todos los pasos del embudo es pedir a un desarrollador que introduzca esa información del producto (dimensiones y métricas) en la capa de datos en cada paso del embudo EE.
La consistencia es clave aquí y tienes que pedirle a un desarrollador que empuje las dimensiones no sólo una vez (en un solo paso del embudo) sino que lo haga en cada paso del embudo. De esta manera podrás ver, por ejemplo, las estadísticas de ese producto en particular a través de todo el embudo.
P.D. Los pasos de comprobación son una exclusión de la regla aquí (es suficiente con pasar los datos del producto sólo con el primer paso de comprobación).
Consejo: lee sobre la atribución en Enhanced Ecommerce.
Error 4. Introducir todo el embudo de Ecommerce en la configuración de Ecommerce de la vista de GA (o incluir la ‘compra’ allí)
Las funciones mejoradas de comercio electrónico deben estar habilitadas en el nivel de la vista de Google Analytics (yendo a Admin > View > Ecommerce settings > Toggle Enable Ecommerce > Tog gle Enabled Enhanced Ecommerce Reporting.
Una vez que lo haga, opcionalmente, puede etiquetar los pasos del embudo de pago. Pero aquí hay una parte que, aparentemente, es difícil para aquellos que sólo hojean rápidamente las guías de Ecommerce Mejorado. El embudo de pago incluye sólo aquellos pasos que se dan después de que el producto o productos se añaden al carrito (por ejemplo, el cliente hace clic en el botón Iniciar pago ) y antes de la compra real.
El embudo de pago NO es el embudo completo de Ecommerce. No es necesario introducir todos los pasos del embudo aquí (empezando por las impresiones de productos y terminando con la compra). No es así como funciona.
En esta sección, sólo tienes que introducir pasos como «Introducir información de facturación», «Introducir información de envío», «Revisión del pedido» o algo similar. Un cliente completa estos pasos sólo cuando está listo para pagar por lo que se añade a un carrito. Sin embargo, la compra (como un paso) no debe ser ingresada aquí también, porque hay una acción de comercio electrónico separada llamada compra que la rastrea.
Si abrimos los informes de Comercio Electrónico Mejorado de la cuenta demo oficial de Google Analytics, verá que hay dos informes de visualización de embudo:
- Comportamiento de compra
- Comportamiento en la caja
El comportamiento decompra incluye todos los pasos del embudo de Ecommerce (comenzando con las vistas de los productos (si se rastrean esos datos) y terminando con una compra). Una de las columnas de ese embudo es » Sesiones con salida».
Sin embargo, si va a otro informe llamado Comportamiento de compra, verá que consta de varios pasos (como Facturación y envío, Pago (también conocido como «introducir información de pago»), Revisión y Sesiones con transacciones). Este embudo es una vista más detallada en la columna Sesiones con salida de la captura de pantalla anterior.
Estas columnas (excepto la última) son las que se configuran en la configuración de Comercio Electrónico de la vista de GA.
Error 5. Tratar de pasar las dimensiones personalizadas del producto a nivel de la etiqueta (o de la configuración GA Variable)
Si está familiarizado con la forma de establecer las dimensiones personalizadas de GA a través de GTM, ya sabe que se pueden establecer en el nivel de una etiqueta de Análisis Universal, o en el nivel de la Variable de Configuración de GA.
Pero esto se aplica sólo a las dimensiones de usuario, de sesión o de hit-scoped (no de producto). Imagine una situación: está rastreando productos que tienen una dimensión personalizada llamada tamaño (valores posibles: S, M, L, XL, XXL, etc.). Ahora quieres pasar esa dimensión con cada producto a Google Analytics.
Hay muchos casos en los que un solo hit de Ecommerce Mejorado puede incluir varios productos (por ejemplo, una compra). Cada producto de esa carga útil puede tener diferentes tamaños. Si se establece el tamaño de la dimensión personalizada en el nivel de una etiqueta de Universal Analytics, ¿cómo se supone que GTM sabrá qué productos deben tener qué tamaño? Bueno, GTM simplemente no lo sabrá.
Por lo tanto, la dimensión personalizada del producto (y lo mismo se aplica a las métricas personalizadas) debe ser incluida en el objeto de comercio electrónico que es empujado a la capa de datos y esa dimensión/métrica debe ser colocada justo al lado de otras dimensiones/métricas del producto.
Basado en el índice (por ejemplo, la dimensión2…métrico…1) El GTM sabrá qué definición personalizada se está utilizando aquí.
Error 6. No pasar el ID o el nombre del producto
Si echa un vistazo a los documentos oficiales de Enhanced Ecommerce para GTM, verá que sólo se requiere uno de estos dos parámetros cuando se pasa la información del producto a GA.
Sin embargo, recomiendo encarecidamente usar ambos.
Si no incluyen el nombre del producto, verán (no establecido) en la columna de productos de sus informes de GA.
Si no incluye el ID del producto, entonces la atribución de la lista de productos no funcionará (por supuesto, si está haciendo un seguimiento del rendimiento de la lista de productos en primer lugar).
Error 7. Tratar de enviar múltiples acciones con un solo dataLayer.push
Aunque Enhanced Ecommerce en Google Tag Manager permite enviar más de un tipo de datos en un solo golpe de Enhanced Ecommerce, existen algunas limitaciones. Pero antes que nada, aquí hay un ejemplo de un dataLayer.push() totalmente aceptable que incluye múltiples tipos de datos de Ecommerce (impresiones de productos e impresiones de promociones).
Por ejemplo, un solo dataLayer.push (que contiene el objeto de comercio electrónico) no puede contener al mismo tiempo un clic en el producto y un detalle del producto (cuando se ve la información detallada sobre el producto).
window.dataLayer = window.dataLayer || [];window.dataLayer.push({ evento: 'ecommerce', ecommerce: { click: { actionField: { lista: 'Productos relacionados' }, productos: [{ id: '123456abc', nombre: 'Algún producto',marca: 'Analytics Mania' }] }, detalle: { productos: [{ id: '123456abc', nombre: 'Algún producto', marca: 'Analytics Mania' }] }});¿Una solución para esto? Pídele a un desarrollador que haga dos dataLayer.push separados (uno para el Clic de Producto y otro para el Detalle de Producto) y luego envía esta información como dos hits separados a Google Analytics. Como esto:
window.dataLayer = window.dataLayer || [];window.dataLayer.push({ evento: 'eec.productClick', ecommerce: { click: { actionField: { lista: 'Productos relacionados' }, productos: [{ id: '123456abc', nombre: 'Algún producto',marca: 'Analytics Mania' }] }, }});window.dataLayer.push({event: 'eec.productDetail',ecommerce: {detalle: { productos: [{id: '123456abc',nombre: 'Algún producto',marca: 'Analytics Mania' }]} }});Error 8. Un malentendido con la opción de compra y la opción de pago
Cuando se mide el rendimiento del proceso de compra, hay dos tipos de datos que se pueden enviar a GA: checkout y checkout_option.
¿Cuál es la diferencia, se pregunta?
Elcheckout debe ser empujado a la capa de datos cuando un visitante/usuario/cliente entra en un determinado paso del proceso de checkout (por ejemplo, al abrir la página «Introducir información de facturación»).
window.dataLayer = window.dataLayer || [];window.dataLayer.push({ event: 'eec.checkout', comercio electrónico: { checkout: { actionField: {paso: 1 }, productos: { id: '123456abc', nombre: 'Algún producto', marca: 'Analytics Mania', cantidad: 1
}]
}
}
});Si ya sabe qué método de pago se ha elegido (porque quizá no sea la primera compra de un cliente), también puede enviar la clave de opción que contiene alguna información adicional sobre ese paso del proceso de compra, por ejemplo, el método de pago.
window.dataLayer = window.dataLayer || [];window.dataLayer.push({ event: 'eec.checkout', comercio electrónico: { checkout: { actionField: {paso: 1,opción: 'Paypal' }, productos: { id: '123456abc', nombre: 'Algún producto', marca: 'Analytics Mania', cantidad: 1
}]
}
}
});Alternativamente, un desarrollador puede empujar primero sólo el objeto de salida con el número de paso (a la Capa de Datos) y después de eso, un desarrollador puede activar un .push adicional que contiene la opción_de_salida (con el método de pago elegido).
window.dataLayer = window.dataLayer || [];window.dataLayer.push({ event: 'eec.checkoutOption', comercio electrónico: { checkout_option: { actionField: { paso: 1, opción: 'Paypal' } }});Si eliges implementar tanto el checkout como el checkout_step, recuerda esto: un golpe de la opción Check out siempre se envía después de que el correspondiente Paso Checkout ya ha sido enviado. Así que no puedes enviar un acierto de opción de pago para el paso 2 si no has enviado primero un acierto de pago normal para el paso 2. Aquí es donde algunas personas se quedan atascadas.
Una vez más:
- El paso 1 de la Caja debe ser empujado primero
- Entonces la opción de salida para el paso 1 puede ser empujada
(lo mismo se aplica al resto de los pasos del embudo de salida)
Por otro lado, no es necesario enviar el hit de opción de compra (porque algunos pasos de compra pueden no tener ninguna opción).
Error 9. Enviar los mensajes portadores de EE. UU. antes de la vista de página (como mensaje de no interacción: falso)
Este error no afectará a sus datos de Ecommerce Mejorado, sin embargo, algunas otras partes de los informes de GA se verán afectadas. La tasa de rebote, en particular. Lo hará realmente bajo (lo cual no es algo bueno
Primero, vamos a refrescar rápidamente lo que es un rebote en GA. En resumen, un porcentaje de rebote es el porcentaje de sesiones de una sola interacción en su página web. En otras palabras, un visitante aterrizó en su sitio, no hizo nada (es decir, no interactuó con el contenido), y luego se fue. En resumen:
- 1 interacción (por ejemplo, vista de página) = rebote.
- 2+ interacciones = sin rebote.
Ahora, volvamos al Comercio Electrónico Mejorado. Está perfectamente bien enviar los datos de EE no a través de la etiqueta Pageview (sino con una etiqueta de Evento GA). De hecho, esta es la forma que siempre implemento. Sin embargo, hay un problema. ¿Qué pasa si:
- Primero envío los datos de EE de la impresión del producto con una etiqueta de evento (lo que significa que se muestra un producto)
- Y luego por separado seguir una vista de página regular (con una etiqueta de vista de página y sin nada relacionado con EE)?
El resultado: se envían dos resultados a Google Analytics. Dos aciertos = dos interacciones = sin rebote.
¿Qué pasa si un visitante acaba de aterrizar en una lista de productos, no hizo nada, y se fue? En este caso, habríamos enviado dos hits (una vista de página y un evento que transporta los datos de impresión del producto), por lo tanto, tal sesión no se contaría como un rebote (aunque se trate de un rebote claro). No es bueno.
¿Cuál es la solución?
Elegir eventos de Google Analytics que estén enviando datos de EE y que se disparen juntos, antes o justo después de la etiqueta de vista de página de GA. Configura esos eventos como «golpe de no interacción: verdadero». Tales eventos no afectarán la tasa de rebote (porque se envían como no-interacciones). Todavía puedes ver sus datos en los informes de la AG.
Por ejemplo, si los datos de Add to cart EE se envían justo después de que se cargue la página del carrito, debes establecer el evento como golpe de no interacción : true.
Error 10. Exceder el límite de 8kb por solicitud a GA
La analítica universal tiene una cierta limitación que puede llegar a ser muy molesta para aquellos que han implementado el Comercio Electrónico Mejorado y están enviando una gran cantidad de datos con cada solicitud a Google Analytics.
Esa limitación es de 8kb. Una sola solicitud enviada a Google Analytics no puede exceder el límite de 8 kilobytes. Si lo hace, la solicitud no será enviada a la AG.
¿Cómo es posible alcanzar ese límite?
Si está rastreando cosas como el detalle del producto, añadir al carrito, pagar, comprar Y por lo general, los visitantes no están comprando muchos productos al mismo tiempo, usted está (muy probablemente) seguro. Sin embargo, si está rastreando activamente las impresiones de la lista de productos, si la gente suele comprar, digamos, 50 productos (o tal vez esté enviando muchos parámetros con cada producto, es probable que ya esté alcanzando ese límite.
¿Qué se puede hacer al respecto? En primer lugar, deberías comprobar si tienes este problema en primer lugar. En esta guía se explica la idea de cómo se pueden registrar las solicitudes que superan el límite de tamaño de la solicitud. Puede resultar bastante difícil, pero definitivamente vale la pena intentarlo.
Enviará el tamaño de la solicitud a GA como una dimensión personalizada. Desafortunadamente, si la solicitud es demasiado grande, entonces la dimensión será enviada en absoluto. Sin embargo, podrá ver aquellas solicitudes que estuvieron bastante cerca de alcanzar el límite. Por lo tanto, si ya están bastante cerca, es una advertencia de que deben hacer algo al respecto.
¿Qué es ese algo? ¿Qué puedes hacer con las solicitudes que son demasiado grandes? Sí se puede:
La mayoría de los errores más comunes del Comercio Electrónico Mejorado (vía GTM): Palabras finales
Lo repetiré una vez más. El Comercio Electrónico Mejorado en Google Analytics es una característica asombrosa que te da una gran visión de cómo se comportan los visitantes/clientes en tu sitio web/tienda online y dónde se quedan atascados en el viaje hacia la conversión final.
Sin embargo, no todo es tan fácil. Para obtener estos informes tan ricos, necesitas trabajar duro mientras lo implementas junto con un desarrollador. Con sólo mirar esta lista de errores de Ecommerce Mejorado puedes darte cuenta de que hay muchos matices en los que los vendedores digitales y los analistas luchan.