Proveedor
- referencias / identificadores
- títulos / descripciones
- precio / stock
- imágenes / categorías
Dromersland · 2019–2026
Me incorporé a Dromersland en 2019, después de realizar allí las prácticas de mi formación. Desde entonces sigo trabajando en la empresa, donde he desarrollado mi trayectoria profesional alrededor de los datos técnicos, la automatización, la calidad de la información y, progresivamente, Data Governance y Metadata Management.
Comencé trabajando con una web, un proveedor principal y un catálogo centrado en iluminación y componentes de automoción. Mis primeras responsabilidades estuvieron relacionadas con la gestión y publicación de producto, pero el crecimiento del catálogo hizo necesario automatizar procesos con Python, pandas, CSV y SQL y mejorar la calidad y estructura de los datos.
Utilicé Python y pandas para automatizar la transformación de catálogos CSV, realizar joins por SKU o referencia, normalizar atributos y preparar cargas masivas para WooCommerce.
Definí y apliqué reglas reproducibles para normalizar títulos, referencias, atributos, descripciones y campos derivados, conservando trazabilidad de origen hacia el SKU destino.
El catálogo partió de aproximadamente 15.000 artículos en 2019, alcanzó alrededor de 50.000 en 2021–2022 y terminó superando los 150.000, obligándome a adaptar progresivamente los procesos de carga, consulta y validación.
Consulta
Escritura
Validación
Estructuré el catálogo de iluminación modelando relaciones entre SKU, referencias, tecnología, posición, componentes y compatibilidades, y apliqué controles básicos de Data Quality.
El catálogo de automoción combinaba SKU, referencias internas y de fabricante, categorías, atributos técnicos, posición, lado, tecnología, stock, imágenes y compatibilidades. La información no podía mantenerse únicamente como fichas aisladas porque los productos dependían de relaciones entre componentes y vehículos.
Sobre estos datos apliqué controles de completitud, consistencia, unicidad, validez, exactitud y estandarización, especialmente sobre referencias, atributos obligatorios y compatibilidades.
Entidades
Implanté Universal Analytics para conectar datos operativos del e-commerce con tráfico, comportamiento, conversiones y ventas.
Trabajé en la implantación y mantenimiento de Universal Analytics para medir procedencia del tráfico, navegación, visualización de productos, comportamiento de usuario, conversiones y ventas asociadas a los distintos canales.
Preparé y mantuve el feed de producto hacia Google Merchant Center y Google Shopping, resolviendo errores de identificadores, títulos, precios y disponibilidad que afectaban a campañas.
Entrada / preparación
Proveedor
Transformación
Catálogo interno
Publicación
Web
Feed
Merchant Center
Google Shopping
Control de calidad / feedback
Diagnósticos / incidencias
Las incidencias detectadas se corregían en la transformación del dato o en el catálogo interno antes de regenerar y publicar el feed.
Entrada / preparación
Proveedor
Transformación
Catálogo interno
Publicación
Web
Feed
Merchant Center
Google Shopping
Control de calidad / feedback
Diagnósticos / incidencias
Las incidencias detectadas se corregían en la transformación del dato o en el catálogo interno antes de regenerar y publicar el feed.
Durante este periodo el número de proveedores aumentó progresivamente hasta aproximadamente cinco o seis. Los catálogos llegaban en distintos idiomas, formatos y niveles de calidad, por lo que asumí tareas de normalización, integración, definición de un modelo común de producto y aplicación de reglas de Data Quality.
Integré catálogos de cinco o seis proveedores con formatos, idiomas y calidad heterogéneos (CSV, Excel, APIs y estructuras propias).
Cómo llegaban los datos
Tarifa y disponibilidad
Recursos de producto
Ficha enriquecida
Información interna
Diferencias entre fuentes
Formato
Idioma
Identidad
Calidad
Mismo producto, distintas representaciones de origen
La integración exigía resolver diferencias de estructura, idioma, referencias y completitud antes de incorporar los datos al modelo interno.
Construí una representación común de producto para integrar fuentes heterogéneas y normalizar vocabulario técnico entre proveedores e idiomas.
La integración dejó de adaptarse individualmente a cada proveedor. Las distintas fuentes se transformaban hacia un modelo interno común, manteniendo el significado técnico de pieza, posición, lado, tecnología, fabricante, referencia, compatibilidad y características del vehículo o componente.
Ejemplo de normalización
ES
EN
PT
Normalización
Pieza
Vehículo
Matching con modelo interno
Modelo canónico
Representaciones resueltas
SEAT León 2 · SEAT Leon II · SEAT Leon MK2
Apliqué reglas comunes de Data Quality sobre campos obligatorios, formatos, categorías, referencias, duplicados, atributos y compatibilidades.
Ejemplo de registro recibido del proveedor
Datos de origen tal y como podían llegar del proveedor
Información inferida del dato recibido
Convención de referencia del proveedor
Sufijo L → posible lado izquierdo
Regla específica de esa fuente; no era una convención universal.
Problemas detectables
Resolución y enriquecimiento
Nombre
Interpretación de abreviaturas y nomenclatura del proveedor
Referencia
Convenciones de la fuente y contraste con equivalencias OEM
Vehículo
Resolución del modelo, generación y aplicación con TecDoc y fuentes internas
Tecnología / compatibilidad
Contraste técnico cuando el proveedor no aportaba información suficiente
Derivación y contraste
Nombre
PIL → Piloto
DEL → Delantero
Referencia proveedor
Sufijo L → posible lado izquierdo según convención de esa fuente
Equivalencia OEM
Contraste de la referencia con equivalencias de fabricante
TecDoc
Resolución de vehículo, generación, aplicación y compatibilidades
Tecnología
Obtención o validación mediante referencias y fuentes técnicas cuando no venía informada
Fuentes internas
Cotejo adicional cuando el dato de origen no era suficiente
Controles de Data Quality
Completitud y validez
Pregunta clave
¿Disponemos de los datos necesarios y tienen formatos y valores utilizables?
Clasificación y atributos
Pregunta clave
¿Hemos podido determinar correctamente qué pieza es y qué atributos técnicos le corresponden?
Identidad e integridad
Pregunta clave
¿Las referencias, equivalencias y compatibilidades resuelven contra la misma entidad sin duplicidades ni contradicciones?
Resultado del control
Datos conformes
El registro puede continuar hacia los procesos de integración o publicación.
Incidencias detectadas
El registro requiere revisión o corrección antes de continuar.
Gestioné requisitos de cookies y consentimiento: finalidad, scripts permitidos y condiciones bajo las que los datos podían enviarse a terceros.
El ecosistema creció hasta tres plataformas y los mismos productos comenzaron a depender de múltiples proveedores, referencias, tarifas y condiciones comerciales. Durante esta etapa trabajé en la normalización de Supplier Data, el desarrollo de lógica para seleccionar proveedor, la coherencia entre aplicaciones y la integración de TecDoc.
Mantuve la coherencia de referencias, productos, precios, stock, imágenes, eventos y compatibilidades entre dos WordPress y una aplicación Django.
El entorno creció hasta dos plataformas WordPress y una aplicación Django, con catálogos compartidos y datos específicos por aplicación. Una de las plataformas estaba orientada a clientes profesionales y añadía cuentas, condiciones comerciales y funcionalidades B2B.
Tres aplicaciones
WordPress
Catálogo y operativa e-commerce
WordPress B2B
Clientes profesionales y condiciones comerciales
Django
Aplicación con catálogo y lógica propia
Datos que debían conservar el mismo significado
Identidad de producto
Estructura de catálogo
Estado operativo
Coherencia entre plataformas
Aunque cada aplicación tuviera funcionalidades y datos específicos, las entidades compartidas debían conservar referencias, relaciones y significado consistentes.
Misma identidad
Una misma referencia o producto debía resolver contra la misma entidad independientemente de la aplicación.
Mismo significado
Categorías, relaciones y compatibilidades debían conservar la misma interpretación entre plataformas.
Estado coherente
Precio, stock y demás datos operativos debían mantenerse consistentes con las fuentes que los alimentaban.
Separé la identidad del producto de las ofertas de cada proveedor y normalicé sus tarifas para poder comparar coste, portes, disponibilidad y condiciones.
Un mismo producto podía estar disponible en varios proveedores con referencias, precios, portes, stock y condiciones diferentes.
Producto maestro
Product Master
Una única identidad de producto
Ejemplo
Un mismo faro para un SEAT Ibiza de 2005 podía disponer de varias ofertas internas mientras el cliente veía un único producto.
Ofertas de proveedor
Supplier Offer
Supplier Offer
Supplier Offer
Resolución de referencias
Referencia de proveedor
Identificador recibido en cada tarifa
Equivalencia
Relación entre la referencia del proveedor y la pieza correspondiente
Product Master
Resolución contra una única identidad interna de producto
Antes de comparar tarifas había que confirmar que las distintas referencias correspondían realmente a la misma pieza.
Normalización de tarifas
Las tarifas de cada proveedor se transformaban a una estructura común y se resolvían contra el Product Master antes de poder compararse.
Datos recibidos
Estructura normalizada
Ofertas comparables
Misma base de comparación
Coste
Precio de compra sobre una misma identidad de producto
Portes
Coste logístico asociado a la oferta
Disponibilidad
Stock o disponibilidad informada por el proveedor
Condiciones
Condiciones comerciales aplicables a esa oferta
Una vez resuelta la identidad y normalizados los datos, distintas alternativas de suministro podían compararse sobre el mismo producto.
Implementé lógica de selección de proveedor basada en matching, actualidad, coste real, portes, disponibilidad, margen y condiciones.
Oferta candidata
Cada Supplier Offer representaba una alternativa real de suministro para el mismo Product Master.
Validaciones previas
Matching
La referencia debía estar correctamente resuelta contra el Product Master para evitar comparar piezas diferentes o perder ofertas equivalentes.
Vigencia
Tarifa, stock y condiciones debían estar actualizados antes de utilizar una oferta en la decisión.
Comparación
Una vez validada la oferta, la decisión no se basaba únicamente en el precio de compra.
Coste real
Precio de compra más costes asociados a la oferta.
Portes
Coste de transporte asociado al suministro.
Disponibilidad
Stock disponible en el momento de la decisión.
Margen y condiciones
Impacto económico y condiciones comerciales aplicables.
Selección
La oferta seleccionada era la que mejor encajaba con las condiciones reales del pedido una vez resuelta la identidad y comprobada la vigencia de los datos.
Proveedor seleccionado
Resultado de comparar las alternativas válidas disponibles para ese Product Master.
Impacto de un dato incorrecto
Aseguré la capa técnica de feeds, eventos, conversiones y medición requerida por Smart Shopping, mientras la agencia definía la estrategia de campañas.
Distribución de responsabilidades
Agencia
Definía la parte estratégica de la captación.
Responsabilidad propia
Preparaba y mantenía la base técnica para que Smart Shopping pudiera operar correctamente.
Capa técnica implantada
Catálogo / feed
Merchant Center
Medición
Google Ads / Smart Shopping
Mi trabajo consistía en asegurar que el catálogo llegara correctamente a Merchant Center y que la medición de eventos y conversiones alimentara de forma fiable las integraciones con Google Ads y Analytics.
Resultado operativo
Feed operativo
El catálogo podía publicarse y mantenerse con incidencias controladas.
Medición activa
Eventos y conversiones quedaban disponibles para la capa publicitaria.
Soporte técnico estable
La agencia podía trabajar campañas sobre una base técnica mantenida y depurada.
Integré TecDoc resolviendo relaciones entre vehículos, fabricantes, motorizaciones, OE/OEM, equivalencias y compatibilidades con nuestro catálogo y aplicaciones.
Dominio incorporado por TecDoc
Vehículos
Entidad de aplicación y compatibilidad
Fabricantes / modelos
Jerarquía de vehículo
Motorizaciones
Variante técnica del vehículo
Referencias OE/OEM
Referencias de fabricante
Equivalencias
Relaciones entre referencias
Familias de producto
Agrupación técnica de pieza
Compatibilidades
Relación pieza–vehículo
Integración con nuestras aplicaciones
Referencias internas
Vinculación con el catálogo propio
Catálogos de proveedores
Cruce con referencias y equivalencias externas
WordPress / Django
Consumo del dato en las plataformas de catálogo
Filtros y búsquedas
Aplicación del dato a navegación, búsquedas y compatibilidades
Resolución de identidades
La parte crítica consistía en distinguir si una referencia apuntaba al mismo producto, a una equivalencia, a una alternativa compatible o a una pieza diferente.
Mismo producto
La referencia resolvía contra la misma pieza en nuestro catálogo.
Referencia equivalente
La pieza era la misma, pero la referencia procedía de otra nomenclatura.
Alternativa compatible
La pieza no era idéntica, pero podía aplicarse sobre el mismo vehículo o contexto.
Pieza diferente
La referencia no debía mezclarse con la identidad principal ni con sus equivalencias.
Ese trabajo permitía integrar TecDoc sin romper la identidad del catálogo, las compatibilidades ni la lógica de búsqueda de las aplicaciones.
Adapté feeds, conversiones, productos, eventos e integraciones durante la sustitución de Smart Shopping por Performance Max.
Cambio de entorno
Smart Shopping
Base anterior sobre la que ya existían feed, medición e integraciones.
Performance Max
Nuevo entorno al que hubo que adaptar la capa técnica existente.
La migración no consistía en rehacer la estrategia de campañas, sino en adaptar productos, señales y medición al nuevo modelo técnico.
Ámbitos adaptados
Feeds y producto
Conversión y señales
Integraciones
Base técnica reconfigurada
Catálogo / Merchant Center
Producto, feed y disponibilidad preparados para el nuevo entorno.
Medición
Eventos, conversiones y señales revisadas para mantener la continuidad técnica.
Integraciones
Conexiones con Google Ads y Analytics adaptadas a la nueva operativa.
Resultado de la migración
Feed adaptado
Los productos y su disponibilidad podían seguir utilizándose en el nuevo entorno.
Medición revisada
Conversiones, eventos y señales quedaban preparadas para la transición técnica.
Integración mantenida
Google Ads y Analytics seguían conectados sobre la base técnica adaptada.
La migración exigió ajustar la infraestructura existente sin perder coherencia entre catálogo, medición e integraciones.
La incorporación de TecDoc aumentó considerablemente el número de entidades, referencias y relaciones que había que mantener. Evaluamos Microsoft Purview y Collibra y finalmente adoptamos Collibra. Me encargué de buena parte de la implantación técnica, el modelado y la automatización del mantenimiento, mientras continuaba trabajando sobre GTM, dataLayer, GA4 y contratos de datos entre las tres plataformas.
La complejidad introducida por TecDoc llevó a formalizar el gobierno del dato; evaluamos Microsoft Purview y seleccionamos Collibra por madurez, profundidad, flexibilidad y adecuación.
Motivo de formalización
TecDoc multiplicó entidades, identificadores, equivalencias y relaciones hasta hacer insuficiente depender de scripts aislados, documentación dispersa y conocimiento implícito.
Evaluación
Microsoft Purview
Lo evaluamos mediante pruebas, pero para nuestro caso no ofrecía la profundidad, flexibilidad y madurez que necesitábamos en un entorno heterogéneo.
Collibra
Ofrecía una mejor adecuación al modelo que debíamos gobernar y a las relaciones que necesitábamos mantener.
Criterios de decisión
Madurez
Capacidad suficiente para sostener un modelo de gobierno real.
Profundidad
Nivel de detalle necesario para activos, relaciones y mappings.
Flexibilidad
Capacidad para adaptarse a fuentes y estructuras heterogéneas.
Adecuación
Encaje con el modelo de datos y las relaciones que necesitábamos mantener.
Decisión
Collibra
Seleccionada por su mejor adecuación al modelo y al nivel de gobierno que necesitábamos.
Me encargué de buena parte de la implantación y mantenimiento de Collibra, incluyendo mappings, relaciones, nomenclaturas, fuentes, consumidores y reglas del ecosistema real.
Conocimiento trasladado al modelo
Trasladé a Collibra una parte importante del conocimiento que antes estaba repartido entre sistemas, documentos y conocimiento operativo.
Modelo gobernado en Collibra
Estructura implantada
Modelo
Definición de estructuras y nomenclaturas para representar el ecosistema de datos.
Mappings y relaciones
Conexión entre campos, activos, productos, proveedores y referencias.
Gobierno
Documentación y reglas necesarias para mantener el significado del modelo.
Relaciones del modelo
Flujo del dato
Fuente
Campo / activo
Consumidor
Relaciones de producto
Producto
Proveedor
Referencia
El objetivo era convertir conocimiento operativo disperso en una estructura mantenible de activos, mappings, relaciones, fuentes, consumidores y reglas.
Desarrollé procesos reutilizables para preparar, validar y mantener datos de Collibra ante cambios de proveedores, TecDoc, catálogos y reglas.
Cuando el volumen hizo inviable mantener el modelo manualmente, desarrollé scripts para transformar estructuras, normalizar nombres, validar campos, comparar datasets, detectar diferencias y preparar incorporaciones o actualizaciones.
Los mismos procesos se reutilizaban cuando cambiaban proveedores, catálogos, atributos o relaciones, reduciendo tareas manuales y haciendo el mantenimiento más consistente y reproducible.
Entradas de cambio
Proveedores
Cambios en estructuras, referencias o datos recibidos.
TecDoc
Cambios en entidades, referencias o relaciones técnicas.
Catálogos
Cambios en productos, atributos y estructuras de catálogo.
Modelo
Cambios en atributos, relaciones o reglas.
Proceso de mantenimiento
Preparación
Validación
Revisión
Los cambios se revisaban antes de incorporarlos al modelo.
Actualización del modelo
Collibra
El modelo se actualizaba de forma más consistente y reproducible ante cambios del ecosistema.
Definí contratos de eventos consistentes entre WordPress y Django e implementé GTM y dataLayer como capa común de instrumentación.
Instrumentación común
Trabajé con etiquetas, triggers, variables, JavaScript, ecommerce, conversiones y consentimiento en Google Tag Manager. La dataLayer actuaba como interfaz entre las aplicaciones y las herramientas de medición.
Aplicaciones de origen
WordPress ×2
Dos plataformas WordPress generando eventos con la misma estructura contractual.
Django
Aplicación Django utilizando el mismo contrato de eventos.
Contrato de evento
Nombre del evento
Identificador común de la acción medida.
Campos requeridos
Datos mínimos que el evento debía proporcionar.
Identificadores
Valores necesarios para relacionar correctamente el evento.
Tipos y valores
Estructura y contenido esperado para cada campo.
Formatos
Representación consistente entre aplicaciones.
Condiciones de envío
Reglas que determinaban cuándo podía emitirse el evento.
Ejemplo: compra
Campos requeridos
Una compra debía proporcionar de forma consistente transaction_id, value, currency e items independientemente de la aplicación de origen.
Flujo de instrumentación
Aplicación
Origen del evento.
dataLayer
Interfaz común de datos.
Google Tag Manager
Procesamiento del etiquetado y las reglas de envío.
Analytics / Google Ads
Destinos de medición y conversión.
Con tres plataformas, estandaricé nombres de eventos, campos requeridos, identificadores, tipos, valores, formatos y condiciones de envío.
Reconstruí el modelo de medición en la migración a GA4: eventos, conversiones, ecommerce, tags, triggers, dataLayer, Ads y lógica JavaScript.
Modelo anterior
Universal Analytics
Modelo de medición que debía sustituirse.
Reconstrucción de la instrumentación
Eventos y ecommerce
Reconstrucción de las acciones de negocio y del modelo de ecommerce.
Etiquetado
Adaptación de la capa de instrumentación.
Objetivos y audiencias
Revisión de objetivos y audiencias vinculados al nuevo modelo.
Integraciones
Adaptación de las conexiones dependientes de la medición.
Modelo migrado
GA4
Eventos, conversiones e integraciones adaptados al nuevo modelo de medición.
La retirada de Universal Analytics obligó a revisar el modelo de instrumentación completo. Adapté eventos, conversiones, ecommerce, etiquetas, triggers, dataLayer, integraciones con Google Ads, objetivos y audiencias, además de revisar JavaScript específico de las diferentes plataformas.
Implementé la reconciliación de campañas, leads, clientes, ventas e identificadores para relacionar conversiones offline con su origen y mantener datos first-party consistentes.
Reconciliación de conversión offline
Campaña
Origen de adquisición.
Interacción
Acción previa registrada.
Lead
Contacto relacionado con la oportunidad.
Venta fuera del flujo web
Conversión completada fuera del recorrido online.
Registro interno
Registro utilizado para reconciliar la operación.
Conversión offline
Conversión devuelta a la plataforma con su contexto.
Datos utilizados para reconciliar
Parte de las ventas podía completarse fuera del flujo web. Para relacionarlas con su origen trabajé con identificadores, fechas, valores, leads, clientes, pedidos, deduplicación y validaciones.
Preparación de first-party data
Dato first-party preparado para integraciones externas.
Teléfono
Segundo identificador first-party preparado bajo las mismas reglas de calidad.
Preparación
Limpieza
Eliminación de formatos o caracteres no utilizables.
Normalización
Homogeneización de la representación del dato.
Deduplicación
Reducción de registros repetidos.
Validación
Comprobación de que el dato pudiera utilizarse correctamente.
Consentimiento
Control de las condiciones de uso del dato.
Destino
Integraciones externas
Datos first-party preparados y validados para su uso en las integraciones correspondientes.
También normalicé y preparé email y teléfono first-party para integraciones externas, aplicando limpieza, deduplicación, validación y controles de consentimiento.
Entre 2023 y 2025 amplié mis responsabilidades sobre Consent Mode, metadata de producto, búsqueda y compatibilidades, pricing profesional, Customer Master Data y Vehicle Data. En paralelo, el catálogo dejó de estar centrado principalmente en iluminación y se amplió a numerosas familias de carrocería y otros componentes: el volumen de producto creció aproximadamente por tres y la taxonomía pasó de unas cinco o seis categorías principales a más de treinta. Ese crecimiento obligó a revisar normalización, clasificación, feeds de Google, logística y reglas de selección de proveedor y transporte.
Implementé y depuré Consent Mode v2 sobre GTM, dataLayer y gtag, controlando señales, estados y orden de ejecución.
Estandaricé atributos necesarios para búsqueda, filtros, categorías y compatibilidades, de forma que los productos pudieran encontrarse y publicarse correctamente.
Implementé pricing B2B y controles de acceso para aplicar la tarifa correcta según cliente, segmento, volumen y condiciones comerciales.
En el área profesional el precio pasó a depender de la relación entre producto, cliente, segmento y condiciones comerciales. El modelo utilizaba datos como tipo de cliente, volumen, nivel de tarifa, descuentos, excepciones y vigencia.
Entradas de pricing
Producto
Pieza sobre la que debía calcularse la tarifa profesional.
Cliente / segmento
Contexto comercial utilizado para determinar el nivel de tarifa.
Condiciones comerciales
Reglas que podían modificar la tarifa aplicable.
Tarifa aplicable
Resultado de combinar producto, cliente o segmento y condiciones comerciales.
Producto + Cliente / segmento + Condiciones → Tarifa aplicable
Control de acceso
También restringí la visibilidad de precios y condiciones profesionales para reducir errores y evitar que una tarifa de otro cliente o segmento se mostrara o compartiera fuera de contexto.
Visibilidad de precios
La tarifa profesional debía mostrarse únicamente en el contexto correspondiente.
Condiciones profesionales
Las condiciones comerciales debían permanecer asociadas al cliente o segmento correcto.
Least Privilege
El acceso se limitaba a la información necesaria para cada contexto.
Data Access Governance
Las reglas de acceso reducían el riesgo de exposición de tarifas fuera de contexto.
Estos controles se aplicaban mediante la lógica existente del sistema, no mediante una suite DLP formal.
Modelé clientes y talleres como entidades de negocio relacionadas con contactos, cuentas, tarifas, pedidos, saldo y estado comercial.
Modelo de entidades
Persona / contacto
Persona que podía actuar como contacto de una cuenta o empresa.
Cuenta de usuario
Identidad utilizada para acceder a la plataforma.
Cliente comercial
Entidad sobre la que se aplicaban condiciones comerciales y operativas.
Taller / empresa
Organización profesional relacionada con contactos, pedidos y tarifas.
La separación entre estas entidades evitaba duplicados o asociaciones incorrectas.
Relaciones del taller
Taller / empresa
Contactos
Personas asociadas al taller.
Pedidos
Operaciones vinculadas al cliente profesional.
Tarifa y condiciones
Condiciones comerciales aplicables.
Estado comercial
Situación económica y operativa del cliente.
Un taller podía tener varios contactos, pedidos, una tarifa determinada, condiciones y una situación comercial propia.
Estado comercial
Saldo
Situación económica acumulada.
Deuda
Importes pendientes asociados al cliente.
Operaciones abiertas
Operaciones todavía no cerradas.
Estado de pago
Situación de pago utilizada en el contexto comercial.
La exactitud y, especialmente, la actualidad de esos datos podían condicionar nuevas operaciones comerciales.
Relacioné disponibilidad y lead time del proveedor con costes y plazos de transporte, seleccionando la agencia más adecuada según tamaño de la pieza, coste de envío y tiempo estimado de entrega.
Datos de suministro
Coste de compra
Precio de adquisición asociado a la oferta del proveedor.
Portes
Coste logístico asociado al suministro desde el proveedor.
Disponibilidad
Stock disponible en el momento de la decisión.
Margen
Impacto económico de la alternativa de suministro.
Lead time
Tiempo esperado hasta disponer de la pieza.
Condicionantes logísticos
Tamaño y volumen de la pieza
Dimensiones que podían limitar agencias o encarecer el transporte.
Coste de envío
Coste real asociado a transportar esa pieza.
Restricciones de la agencia
Condiciones de transporte aplicables según tipo y tamaño de producto.
Tiempo estimado de entrega
Plazo que podía comunicarse al cliente según proveedor y transporte.
Con la incorporación de piezas de carrocería, el tamaño y volumen del producto pasaron a condicionar también la logística: una pieza grande podía hacer que una oferta aparentemente más barata dejara de ser la opción óptima por el coste del transporte.
Decisión de suministro
Proveedor
Alternativa de suministro seleccionada según coste, disponibilidad y margen.
Agencia de transporte
Alternativa logística seleccionada según tamaño, restricciones, coste y plazo.
Decisión final
Coste total
Resultado económico de proveedor + transporte.
Entrega estimada
Plazo resultante de disponibilidad + transporte.
Cliente
Recepción de una fecha estimada coherente con la alternativa seleccionada.
Comparaba las alternativas de envío según dimensiones de la pieza, coste, restricciones de la agencia de transporte y tiempo estimado de entrega. La decisión final combinaba proveedor y transporte para reducir el coste total sin comprometer la fecha comunicada al cliente.
Integré Vehicle Master Data, matrícula/VIN y TecDoc para resolver identidad y compatibilidades de producto, controlando falsos positivos y falsos negativos en el catálogo mostrado.
Identificación del vehículo
Matrícula
Entrada utilizada para identificar el vehículo cuando estaba disponible.
VIN
Identificador utilizado para resolver el vehículo con mayor precisión.
Selección manual
Alternativa cuando el vehículo se seleccionaba directamente por sus características.
Vehicle Master Data
Fabricante
Marca del vehículo.
Modelo
Modelo identificado.
Versión
Variante concreta dentro del modelo.
Motorización
Configuración técnica del vehículo.
Año
Periodo utilizado para acotar compatibilidades.
Identificadores TecDoc
Identificadores utilizados para relacionar el vehículo con TecDoc.
La búsqueda pasó a identificar primero el vehículo mediante matrícula, VIN o selección manual y después consultar TecDoc para resolver productos compatibles. El dominio de Vehicle Data incluía fabricante, modelo, versión, motorización, año e identificadores TecDoc relacionados con referencias y equivalencias de producto.
Resolución con TecDoc
Referencias
Referencias relacionadas con la pieza.
OE/OEM
Referencias de fabricante utilizadas para resolver equivalencias.
Equivalencias
Relaciones entre referencias técnicamente equivalentes.
Compatibilidades
Relación final entre pieza y vehículo.
Catálogo contextual
Productos compatibles con el vehículo identificado.
Vehículos guardados
También permitimos guardar vehículos en la cuenta para reutilizarlos en búsquedas y filtros. Estas relaciones exigían asociación correcta entre usuario, vehículo e identificadores y controles sobre acceso, almacenamiento y minimización.
Usuario
Cuenta a la que se asociaba el vehículo.
Vehículo
Entidad de vehículo guardada.
Identificadores
Datos necesarios para mantener la asociación correcta.
Acceso
Control de quién podía consultar la información.
Almacenamiento
Persistencia de los datos necesarios para reutilizar el vehículo.
Minimización
Conservación únicamente de los datos necesarios para la funcionalidad.
Riesgo de compatibilidad
Falso positivo
Mostrar una pieza incompatible.
Falso negativo
Ocultar una pieza válida.
Goberné un catálogo que creció aproximadamente por tres, pasando de unas cinco o seis categorías principales a más de treinta e incorporando carrocería y otras familias, con impacto directo en taxonomía, feeds, búsqueda y calidad del dato.
Escala del catálogo
×3 aproximadamente
Volumen de producto
Crecimiento aproximado respecto al catálogo anterior.
5–6 → 30+
Categorías principales
Aumento de la taxonomía necesaria para clasificar el catálogo.
Iluminación → carrocería y otras familias
Ampliación del dominio
Entrada de nuevas familias de producto con requisitos de clasificación y logística distintos.
Entre 2023 y 2025 el catálogo dejó de estar centrado principalmente en iluminación y se amplió a numerosas familias de carrocería y otros componentes. Ese crecimiento multiplicó aproximadamente por tres el volumen de producto y obligó a mantener una taxonomía mucho más amplia, con más de treinta categorías principales y nuevas reglas de clasificación, atributos y compatibilidades.
Taxonomía
Iluminación
Familias históricas del catálogo.
Carrocería
Nuevas familias con mayor impacto en clasificación y logística.
Piezas de seguridad
Productos con categorización específica dentro del catálogo.
Otras familias de producto
Resto de grupos incorporados durante la ampliación.
Evolución de los feeds
Segmentación más simple
En una etapa anterior los feeds podían mantenerse más separados por marcas.
Segmentación más granular
El crecimiento del catálogo obligó a dividir y clasificar con mayor precisión los productos enviados.
La estructura de feeds de Google también tuvo que evolucionar. Los feeds que inicialmente podían mantenerse más separados por marcas pasaron a requerir una segmentación mucho más granular por grupos y familias de producto, manteniendo coherencia entre la clasificación interna, los atributos enviados y los requisitos de Merchant Center.
Automatización
Python / pandas
Base de los procesos de transformación masiva.
Joins y merges
Cruce de datasets por claves y referencias.
Deduplicación
Detección y reducción de registros repetidos.
Normalización
Homogeneización de campos, nombres y formatos.
Comparación de datasets
Detección de cambios entre distintas versiones o fuentes.
Procesamiento por chunks
Trabajo por lotes cuando el volumen hacía inviable procesar todo de una vez.
Validación
Comprobaciones antes y después de las transformaciones.
Source of Truth por atributo
Cuando varias fuentes ofrecían información diferente, definía la fuente fiable según el atributo.
Stock
Desde un proveedor
Imágenes
Desde otro proveedor
Compatibilidad
Desde TecDoc
Contenido
Desde información interna
Catálogo consistente
Resultado de combinar cada atributo desde la fuente considerada fiable para ese dato.
El mismo catálogo seguía alimentándose de proveedores, TecDoc e información interna. Para mantenerlo consistente seguí aplicando normalización, matching, deduplicación, validaciones y Source of Truth por atributo.
En 2025–2026 profundicé en la capa técnica de medición y first-party data, implementando conversiones mejoradas y server-side tagging con normalización, consentimiento, eventos, identificadores, validación y debugging. En paralelo, la empresa internalizó una parte mayor de la operativa de Google Ads; mi responsabilidad siguió centrándose principalmente en la calidad del dato, el etiquetado, los eventos, las conversiones y la medición, mientras la estrategia comercial y creativa correspondía a otra capa.
Integré conversiones mejoradas con datos first-party para reforzar la medición ante las restricciones crecientes del tracking tradicional.
Participé directamente en la implementación técnica de conversiones mejoradas utilizando datos first-party, eventos de conversión, normalización, validación, consentimiento, Google Tag Manager y Google Ads.
Datos first-party
Dato propio del cliente utilizado cuando estaba disponible y podía utilizarse bajo las condiciones de consentimiento correspondientes.
Teléfono
Segundo identificador first-party preparado bajo las mismas reglas de calidad y consentimiento.
Preparación del dato
Normalización
Homogeneización del dato antes de incorporarlo al flujo de medición.
Validación
Comprobación de que el dato tuviera una estructura utilizable antes de enviarlo.
Consentimiento
Control de las condiciones bajo las que el dato podía utilizarse en la medición.
Contexto de conversión
Evento
Interacción o acción de negocio que debía medirse.
Conversión
Resultado asociado al evento que se enviaba a la plataforma de medición.
Flujo de instrumentación
Datos first-party preparados
Email / teléfono normalizados, validados y sujetos a consentimiento.
Google Tag Manager
Instrumentación del flujo de medición.
Google Ads
Destino de la conversión y del dato asociado.
Enhanced Conversions
Refuerzo de la medición mediante datos first-party.
Responsabilidad técnica
Responsabilidad propia
Responsabilidad de la herramienta
El hashing era gestionado por las herramientas correspondientes; mi responsabilidad estaba en proporcionar y validar correctamente los datos y el flujo de medición.
En 2025, con una mayor internalización de Google Ads, mi especialización siguió centrada en calidad del dato, etiquetado, eventos, conversiones y medición, y obtuve certificaciones oficiales de Google relacionadas con publicidad y medición.
Cambio de contexto
Primeros años
La agencia concentraba estrategia, estructura de campañas, creatividades, presupuestos y optimización.
2025
La empresa asumió una parte mayor de la operativa de Google Ads.
Ese cambio amplió el contexto en el que trabajaba, pero mi responsabilidad principal continuó estando en la capa técnica de datos y medición.
Responsabilidad principal
Mi trabajo se concentraba en preparar, instrumentar, validar y depurar los datos que alimentaban la medición y las integraciones publicitarias.
Calidad del dato
Revisión de la consistencia del dato utilizado por las integraciones.
Etiquetado
Mantenimiento de la instrumentación técnica necesaria para la medición.
Eventos
Comprobación de las acciones y señales enviadas desde las aplicaciones.
Conversiones
Validación del recorrido desde el evento hasta la conversión registrada.
Medición
Depuración de discrepancias y continuidad entre aplicaciones y plataformas.
Google Ads
Integración técnica de datos y conversiones con la plataforma publicitaria.
Ecosistema técnico
Merchant Center
Producto, feeds y calidad del dato comercial.
GA4
Eventos, conversiones y medición.
Google Ads
Consumo de producto, señales y conversiones.
Separación de funciones
Capa estratégica
Decisiones comerciales y de campaña.
Capa técnica
Datos e instrumentación necesarios para medir y alimentar las plataformas.
Certificaciones
En 2025 obtuve certificaciones oficiales de Google relacionadas con publicidad y medición.
Formalizaban conocimientos que ya utilizaba en producción y también resultaban útiles dentro del contexto de Google Partners.
Implementé y mantuve la capa server-side de medición como responsabilidad técnica directa.
Las restricciones crecientes del navegador y de privacidad hicieron necesario trasladar parte de la instrumentación hacia una capa server-side, manteniendo una relación complementaria con la medición ejecutada en cliente.
Me encargué directamente de implementar y mantener esa capa, trabajando con eventos estructurados, payloads, identificadores, conversiones, first-party data, consentimiento, validación y debugging de los flujos hacia GA4 y Google Ads.
Arquitectura de medición
Origen
Browser / Web
Las aplicaciones generaban las interacciones y eventos de origen.
Procesamiento
Capa server-side
Recibía eventos estructurados y preparaba el procesamiento y envío posterior.
Destinos
GA4 / Google Ads
Plataformas de destino para medición y conversiones.
Datos y contexto
Payloads
Estructura de los datos enviados entre las capas del flujo.
Identificadores
Datos utilizados para relacionar eventos y conversiones.
Conversiones
Eventos de negocio que debían llegar correctamente a los destinos.
First-party data
Datos propios preparados para su uso dentro de las condiciones aplicables.
Consentimiento
Estado que condicionaba el tratamiento y envío del dato.
Operación técnica
Validación
Comprobaba la estructura de los eventos, los datos enviados y la llegada correcta a los destinos.
Debugging
Investigaba incidencias entre el origen, la capa de procesamiento y las plataformas de destino.
Client-side y server-side
Client-side
La instrumentación ejecutada desde el navegador seguía recogiendo parte de las interacciones y eventos.
Server-side
La capa adicional permitía procesar y reenviar determinados eventos reduciendo parte de la dependencia directa del navegador.
El modelo server-side complementaba la medición client-side; no la sustituía por completo.
Responsabilidad directa
Mi responsabilidad incluía la implementación, mantenimiento, validación y depuración de la capa server-side y de los flujos de medición asociados.
Esta implementación reducía la dependencia del navegador y complementaba la medición client-side dentro de las restricciones de privacidad.