Qué buscamos y con qué alcance
Buscamos evaluar la factibilidad de construir un sistema personalizado de marketing e inteligencia de negocios para Grupo Axo, que integre información de publicidad, analítica digital, e-commerce y gestión comercial.
La solución buscaría entregar una visión consolidada de la operación, facilitar el análisis por marca, canal, campaña, categoría y producto, y transformar los datos disponibles en alertas, hallazgos y recomendaciones accionables. La inteligencia artificial se incorporaría como una capa de apoyo para detectar anomalías, identificar oportunidades, explicar cambios de desempeño y orientar la toma de decisiones, siempre sobre datos verificables y con resultados trazables.
En esta primera etapa necesitamos conocer la estructura y consistencia de las fuentes, y definir cuál es el sistema oficial para cada indicador. Con ello podremos determinar el alcance de un piloto y de una futura implementación.
- Una marca piloto, con suficiente volumen, información histórica y equipos disponibles para acompañar la evaluación.
- Entre 13 y 24 meses de historia, priorizando datos completos y consistentes.
- Accesos acotados y de solo lectura, sin acceso directo al ERP ni datos personales de clientes.
Primer paso: validar la llave
Una muestra de 20 pedidos, antes que cualquier otra cosa
La pregunta que condiciona todo el proyecto es si existe un identificador de pedido compartido entre Magento y Oracle. Si existe y es estable, el análisis puede llegar a nivel de pedido y producto. Si no, solo puede llegar a nivel agregado, y eso cambia sustancialmente lo que se puede afirmar.
Pedimos veinte pedidos de la marca piloto en dos archivos: su registro en Magento y el de esos mismos veinte en Oracle. No buscamos una muestra estadística, sino técnicamente diversa. Sujeto a lo que esté disponible, sería ideal que incluyera pedidos completados, al menos uno cancelado, al menos uno con devolución total o parcial, alguno con descuento o cupón aplicado, alguno con más de un producto y, si la modalidad existe, alguno con retiro en tienda.
Con esa muestra podremos verificar si la llave existe, si es estable, qué campo la contiene y cómo se reflejan los distintos estados y movimientos del pedido entre ambos sistemas. Es la validación de menor costo y mayor consecuencia del proceso.
Accesos de lectura solicitados
| Plataforma | Qué necesitamos revisar | Prioridad |
|---|---|---|
| Google Ads | Cuenta de la marca piloto: estructura de campañas, presupuestos y pujas, configuración de acciones de conversión, rendimiento por campaña y por producto, detalle de términos de búsqueda en la medida en que el tipo de campaña lo exponga, y estado de vinculación con GA4 y Merchant Center. | Indispensable |
| Google Ads | Historial de cambios de los últimos 12 meses. | Recomendable |
| Merchant Center | Cuenta de la marca y exportación del feed vigente con sus atributos: id de oferta, item_group_id, SKU, GTIN, marca, categoría, precio, disponibilidad y etiquetas personalizadas. Más el origen del feed y su frecuencia de actualización. | Indispensable |
| Merchant Center | Diagnóstico: productos rechazados, limitados y con advertencias. | Recomendable |
| Meta | Cuenta publicitaria de la marca piloto y acceso de lectura al dataset o píxel: estructura de campañas, configuración y priorización de eventos, y estado de la Conversions API con su deduplicación. | Indispensable |
| Meta | Catálogo de productos vinculado y dominios verificados. | Recomendable |
| GA4 | Propiedad de la marca, rol de lector o analista: implementación de e-commerce, eventos y conversiones, parámetros de producto, configuración de atribución, canales y UTM. | Indispensable |
| GA4 | Retención configurada en la propiedad y si existe exportación a BigQuery. Define hasta dónde podemos mirar hacia atrás. | Recomendable |
| Tag Manager | Contenedor web y server-side si existe: etiquetas de compra, data layer y Consent Mode. Es lo que permite explicar el origen de las diferencias entre plataformas. | Recomendable |
El parámetro transaction_id del evento de compra de GA4 es clave: es el candidato natural para unir la sesión con el pedido de Magento. Si efectivamente corresponde al identificador del pedido, y cómo se relaciona con el del ERP, es justamente parte de lo que debemos verificar.
Acceso a Magento y datos a exportar
Aquí pedimos dos cosas distintas. En Magento nos interesa un acceso de solo lectura además de las exportaciones: entender cómo está construida la instancia es lo que permite leer correctamente cualquier archivo que salga de ella. Sobre Oracle, su ERP, no solicitamos ningún acceso; solo reportes que su equipo pueda generar en CSV o Excel, con los campos que el sistema efectivamente permita exportar.
Acceso solicitado a Magento
Un usuario de administración con un rol restringido de solo lectura, acotado al scope de la marca piloto.
Qué necesitamos poder ver
- Estructura de websites, stores y store views, con la configuración de moneda, zona horaria y locale de cada uno.
- Ficha de pedido completa: estados, facturas, despachos y notas de crédito, para saber qué campos se pueblan realmente.
- Catálogo: tipos de producto, sets de atributos, relación entre producto configurable y sus variantes, y estructura de categorías.
- Reglas de precio, cupones, fuentes de inventario y stocks.
- Integraciones activas y su alcance.
Qué no necesitamos
- Permisos de creación, edición, cancelación, reembolso o eliminación.
- Acceso al módulo de clientes ni a ninguna vista con datos personales.
- Acceso a configuración de sistema, usuarios, roles ni medios de pago.
Entendemos que el sistema de roles de Magento no siempre separa la visualización de la edición en todos los módulos. Si en algún caso la única alternativa fuera un permiso más amplio del que necesitamos, preferimos que ese módulo quede excluido.
Si un usuario sobre producción no es viable, un ambiente de staging o una réplica reciente sirve igual o mejor. Y si tampoco, una sesión guiada de una o dos horas compartiendo pantalla con alguien de su equipo cubre lo esencial. El acceso vía API REST o GraphQL no es necesario en esta etapa: corresponde a una eventual integración posterior.
| Origen | Archivo | Campos | Prioridad |
|---|---|---|---|
| Magento | Pedidos | ID de pedido, fecha, estado, marca, store view, país, moneda, subtotal, descuentos, cupón, despacho, impuestos, total, medio de pago, forma de entrega, ID de cliente anonimizado. | Indispensable |
| Magento | Líneas de pedido | ID de pedido, SKU, producto, categoría, talla, color, cantidad, precio de lista, precio de venta, descuento, total de línea, cantidad cancelada y devuelta. El SKU padre, si no está en la línea, lo reconstruimos desde el catálogo. | Indispensable |
| Magento | Catálogo | SKU, SKU padre, nombre, marca, categoría, atributos de variante, precio, habilitación, visibilidad. | Indispensable |
| Magento | Devoluciones y cancelaciones | ID de pedido, SKU, fecha, cantidad, monto y motivo si está tipificado. El motivo es uno de los datos de mayor valor del conjunto, porque distingue una devolución por talla de una por producto defectuoso; si vive en el sistema de atención al cliente y no en Magento, nos sirve igual desde donde esté. | Indispensable |
| Oracle | Ventas por pedido | ID compartido con Magento, fecha de pedido y de facturación, marca, canal, tienda, venta bruta, descuentos, monto facturado, cancelaciones, devoluciones con su propia fecha, venta neta, impuestos, estado final. | Indispensable |
| Oracle | Ventas por SKU | ID de pedido, SKU, producto, marca, categoría, cantidad, precio de lista, precio de venta, descuento, cantidad cancelada y devuelta, venta neta de línea. | Indispensable |
| Oracle o Magento | Inventario | Fecha del snapshot, marca, SKU, bodega o tienda, stock disponible y reservado, precio vigente. Permite detectar inversión dirigida a producto sin stock y sobrestock sin inversión. | Recomendable |
| Oracle | Margen | Banda de margen por SKU (alto, medio, bajo) o índice relativo sin unidad. No solicitamos costo absoluto: cualquiera de esos dos formatos habilita el análisis sin exponer la estructura de costos. | Recomendable |
Preguntas por resolver
Pueden responderlas por correo, con lo que tengan a mano. Si alguna no tiene respuesta todavía, no es problema: saber qué está definido y qué no también nos orienta.
- ¿Qué campo permite relacionar un pedido de Magento con sus documentos en Oracle? ¿La integración es en tiempo real o por lotes? ¿Un pedido puede generar varios documentos por despachos parciales, cancelaciones o notas de crédito?
- ¿Cuál es el sistema oficial para determinar una venta válida y su monto neto: Magento u Oracle? ¿Dónde se registran finalmente las cancelaciones, devoluciones y reembolsos cuando existen diferencias entre ambos sistemas?
- ¿Cada marca opera en una instancia independiente de Magento o existe una estructura multi-store compartida? ¿Las marcas comparten catálogo, configuraciones o integraciones?
- ¿Cómo está estructurado el catálogo a nivel de SKU? ¿Se distingue entre producto padre y variantes —por ejemplo, talla o color— y qué campo permite relacionarlos?
- ¿El catálogo de Merchant Center se genera directamente desde Magento o mediante otro sistema o herramienta intermedia? ¿Con qué frecuencia se actualizan precio, disponibilidad y stock?
- ¿Cómo registra GA4 el ingreso de una compra? ¿Incluye o excluye impuestos, despacho y descuentos? ¿Se envían eventos de reembolso cuando una compra es devuelta?
Privacidad y seguridad
- No solicitamos datos personales de clientes finales: nombre, correo, teléfono, RUT ni dirección. Un identificador seudonimizado y estable es suficiente para analizar recurrencia.
- Todos los accesos son de solo lectura, nominativos y revocables en cualquier momento. Ninguno de los solicitados permite modificar campañas, configuraciones, contenidos ni registros.
- No solicitamos acceso directo al ERP ni a públicos construidos con datos personales.
- El almacenamiento, tratamiento, conservación y eliminación de la información se realizará conforme al NDA y al protocolo de seguridad que acordemos entre ambas partes.
- Nada de lo anterior se ejecuta antes de la firma del NDA.
Próximos pasos
Si algún acceso o extracto demora, seguimos avanzando con el resto y lo declaramos como pendiente. Preferimos un diagnóstico honesto sobre lo disponible antes que detener el proceso esperando información completa.
El diagnóstico cierra esta etapa. Sobre él se elabora después la propuesta de implementación, dimensionada según lo que los datos efectivamente permitan. Si el piloto resulta sólido, servirá para validar la metodología, identificar qué componentes son replicables y estimar el esfuerzo de incorporar otras marcas, que pueden tener configuraciones, integraciones y niveles de medición distintos entre sí.