Adrián Martínez Martín

Dromersland · 2019–2026

Professional experience

I joined Dromersland in 2019 after completing my vocational training placement there. I have remained with the company ever since, building my professional experience around technical data, automation, information quality and, progressively, Data Governance and Metadata Management.

2019–2020

Catalog management, automation and analytics

I started working with one website, one main supplier and a catalog focused on lighting and automotive components. My first responsibilities were related to product management and publishing, but catalog growth made it necessary to automate processes with Python, pandas, CSV and SQL and improve data quality and structure.

Catalog automation with Python and pandas

I used Python and pandas to automate CSV catalog transformation, perform joins by SKU or reference, normalize attributes and prepare bulk loads for WooCommerce.

  • Python
  • pandas
  • CSV
  • WooCommerce
Inputs
WooCommerce CSV exports and catalogs received from suppliers
Responsibility
Instead of editing products one by one, I prepared reproducible processes to transform complete datasets.
  • Joins and merges by SKU or reference
  • Normalization of titles, attributes and formats
  • Cleaning and enrichment of descriptions
  • Detection of duplicates and unmatched records
  • Comparison across catalog versions
  • Generation of import-ready files
  1. Exportar CSV
  2. Python / pandas
  3. Validate
  4. Enriquecer
  5. Normalizar
  6. Importar

Product data normalization

I defined and applied reproducible rules to normalize titles, references, attributes, descriptions and derived fields, keeping source-to-destination SKU traceability.

  • Python
  • pandas
  • CSV
  • SKU
Responsibility
I turned corrections that were initially done manually into reusable rules: title reconstruction, reference normalization, nomenclature homogenization, format transformation, derived-field generation and separation of valid or incident records.
Systems
During transformations I kept enough identifiers to relate the final data to the supplier, the original reference and the applied transformation
Output
The SKU that had to be updated at the destination

Progressive catalog scaling to more than 150,000 items

The catalog started at about 15,000 items in 2019, reached around 50,000 in 2021–2022 and eventually exceeded 150,000, forcing me to progressively adapt load, query and validation processes.

  • SQL
  • MySQL
  • MariaDB
  • phpMyAdmin
Context
As volume grew, conventional importers started to fall short in execution time, memory, batch size and server load.
Systems
To work with those volumes I went deeper into MySQL/MariaDB, SQL, phpMyAdmin and bulk processes.

Read

  • SELECT and JOIN for querying and joining data

Write

  • UPDATE and INSERT for bulk operations
  • lookup by keys and references

Validation

  • detection of duplicates and orphan records
  • counts and integrity validations
  • checks before and after loads

Initial Product Data modeling

I structured the lighting catalog by modeling relationships among SKU, references, technology, position, components and compatibilities, and applied basic Data Quality controls.

  • WooCommerce
  • SKU
  • Manufacturer references
  • Compatibilities

The automotive catalog combined SKU, internal and manufacturer references, categories, technical attributes, position, side, technology, stock, images and compatibilities. Information could not be maintained only as isolated product sheets because products depended on relationships between components and vehicles.

On this data I applied controls for completeness, consistency, uniqueness, validity, accuracy and standardization, especially on references, required attributes and compatibilities.

Entities

Lighting system
Vehicle
Make
Model
Year
Headlamp / optic
Halogen
Xenon
OLED
Technology
Bulb
Ballast
Module / controller
Lighting system
  • Vehicle
    • Make
    • Model
    • Year
  • Headlamp / optic
    • Halogen
    • Xenon
    • OLED
  • Technology
    • Bulb
    • Ballast
    • Module / controller

Universal Analytics implementation

I implemented Universal Analytics to connect e-commerce operational data with traffic, behavior, conversions and sales.

  • Universal Analytics

I worked on the implementation and maintenance of Universal Analytics to measure traffic origin, navigation, product views, user behavior, conversions and sales associated with the different channels.

Google Merchant Center and Google Shopping integration

I prepared and maintained the product feed to Google Merchant Center and Google Shopping, resolving identifier, title, price and availability errors that affected campaigns.

  • Merchant Center
  • Google Shopping
  • WooCommerce
  • Product Feed
Responsibility
I prepared the catalog for Merchant Center ensuring fields such as identifier, title, description, brand, MPN/GTIN when applicable, image, URL, price and availability.
Inputs
I also investigated rejected products or warnings caused by price or stock discrepancies, incomplete identifiers, missing fields, images, categorization or differences between the web and the feed.

Input / preparation

Supplier

  • references / identifiers
  • titles / descriptions
  • price / stock
  • images / categories

Transformation

  • field normalization
  • title cleaning
  • attribute mapping
  • identifier validation
  • availability control

Internal catalog

  • SKU
  • standardized attributes
  • consolidated price / stock
  • product source of truth

Publishing

Web

  • product sheet
  • price and availability
  • category / visible content

Feed

  • id
  • title / description
  • brand / GTIN / MPN
  • price / availability
  • image_link / category

Merchant Center

  • feed validation
  • diagnostics
  • rejections / warnings

Google Shopping

  • catalog publication
  • product visibility
  • Google surfaces / eligible inventory

Diagnostics / incidents

  • price mismatch between web and feed
  • inconsistent stock
  • Incomplete GTIN / MPN
  • missing or poor image
  • incorrect categorization
  • mandatory attributes missing

Detected issues were corrected in the data transformation or in the internal catalog before regenerating and publishing the feed.

Input / preparation

  1. Supplier

    • references / identifiers
    • titles / descriptions
    • price / stock
    • images / categories

  2. Transformation

    • field normalization
    • title cleaning
    • attribute mapping
    • identifier validation
    • availability control

  3. Internal catalog

    • SKU
    • standardized attributes
    • consolidated price / stock
    • product source of truth

Publishing

  1. Web

    • product sheet
    • price and availability
    • category / visible content

  2. Feed

    • id
    • title / description
    • brand / GTIN / MPN
    • price / availability
    • image_link / category

  3. Merchant Center

    • feed validation
    • diagnostics
    • rejections / warnings

  4. Google Shopping

    • catalog publication
    • product visibility
    • Google surfaces / eligible inventory

Quality control / feedback

Diagnostics / incidents

  • price mismatch between web and feed
  • inconsistent stock
  • Incomplete GTIN / MPN
  • missing or poor image
  • incorrect categorization
  • mandatory attributes missing

Detected issues were corrected in the data transformation or in the internal catalog before regenerating and publishing the feed.

2020–2021

Supplier integration and data standardization

During this period the number of suppliers grew progressively to about five or six. Catalogs arrived in different languages, formats and quality levels, so I took on normalization, integration, definition of a common product model and application of Data Quality rules.

Integration of five or six suppliers

I integrated catalogs from five or six suppliers with heterogeneous formats, languages and quality (CSV, Excel, APIs and custom structures).

  • CSV
  • Excel
  • APIs

How the data arrived

Rate and availability

  • Reference
  • Price
  • Stock

Product resources

  • Reference
  • Images

Ficha enriquecida

  • Own reference
  • Description
  • Category

Internal information

  • Commercial text
  • Classification
  • Equivalences

Differences across sources

Formato

  • CSV
  • Excel
  • APIs
  • Own structures

Idioma

  • Spanish
  • English
  • Portuguese

Identity

  • Own references
  • Manufacturer references
  • Inconsistent identifiers

Quality

  • Missing attributes
  • Own categories
  • Incomplete texts
  • Poor translations

Same product, different source representations

Integration required resolving differences in structure, language, references and completeness before adding data to the internal model.

Canonical model and multilingual normalization

I built a common product representation to integrate heterogeneous sources and normalize technical vocabulary across suppliers and languages.

  • CSV
  • Excel
  • APIs
  • Canonical model

Integration stopped being adapted individually to each supplier. Different sources were transformed into a common internal model, preserving the technical meaning of part, position, side, technology, manufacturer, reference, compatibility and vehicle or component characteristics.

Normalization example

ES

Part
Piloto delantero
Vehicle
SEAT León 2

EN

Part
Seat Leon front light
Vehicle
SEAT Leon II

PT

Part
Farolim dianteiro
Vehicle
SEAT Leon MK2

Normalization

Part

  • Translate
  • Correct
  • Homogenize nomenclature

Vehicle

  • Resolve make / model
  • Resolve generation
  • Map equivalent designations
  • Preserve technical meaning

Matching to the internal model

  • Make
  • Model
  • Generation
  • Period

Canonical model

Part
Piloto delantero
Make
SEAT
Model
León
Generation
2nd generation
Period
2005–2012
Category
Lighting

Resolved representations

SEAT León 2 · SEAT Leon II · SEAT Leon MK2

Data Quality rules

I applied common Data Quality rules on required fields, formats, categories, references, duplicates, attributes and compatibilities.

  • CSV
  • Excel
  • References
  • Compatibilities

Example of a record received from the supplier

Source data as it could arrive from the supplier

Supplier reference
REF-XXXX-L
Supplier name
PIL DEL SEAT LEON 2
Supplier category
Lighting
Reported vehicle
SEAT Leon 2
Reported technology
Not reported

Information inferred from received data

  • Part namePIL → Piloto
  • PositionDEL → Delantero
  • VehicleSEAT LEON 2 → denomination pending resolution against the internal model

Supplier reference convention

Suffix L → possible left side

Source-specific rule; it was not a universal convention.

Detectable problems

  • Abbreviated nomenclature
  • Category too generic
  • Unreported attributes
  • Reference with own convention
  • Vehicle without period or variant
  • Compatibility pending cross-check

Resolution and enrichment

Name

Interpretation of supplier abbreviations and nomenclature

Reference

Source conventions and cross-check against OEM equivalences

Vehicle

Model, generation and fitment resolution with TecDoc and internal sources

Technology / compatibility

Technical cross-check when the supplier did not provide enough information

Derivation and cross-check

Name

PIL → Piloto

DEL → Delantero

Supplier reference

Suffix L → possible left side per that source’s convention

OEM equivalence

Cross-check of the reference against manufacturer equivalences

TecDoc

Vehicle, generation, fitment and compatibility resolution

Technology

Obtaining or validating via references and technical sources when it was not provided

Internal sources

Additional cross-check when source data was not enough

Data Quality controls

Completeness and validity

  • Required fields
  • Allowed values
  • Formats

Key question

Do we have the required data, and are formats and values usable?

Classification and attributes

  • Categories
  • Descriptions
  • Attributes

Key question

Have we correctly determined which part it is and which technical attributes belong to it?

Identity and integrity

  • Keys
  • References
  • Duplicates
  • Compatibilities

Key question

Do references, equivalences and compatibilities resolve against the same entity without duplicates or contradictions?

Control result

Compliant data

The record can continue into integration or publication processes.

Detected incidents

The record requires review or correction before continuing.

Privacy, cookies and consent

I managed cookie and consent requirements: purpose, allowed scripts and conditions under which data could be sent to third parties.

  • Cookies
  • Third-party scripts
  • Web forms
Responsibility
I took part in the technical adaptations of cookies, consent banners, third-party scripts, analytics, advertising and forms.
Control
The implementation had to control the purpose of collection and the existence of consent
Systems
Which tools could use the data and which scripts had to remain blocked before the user choice.

2021–2022

Platforms, suppliers, pricing and TecDoc

The ecosystem grew to three platforms and the same products started to depend on multiple suppliers, references, pricing and commercial terms. During this stage I worked on Supplier Data normalization, supplier-selection logic, consistency across applications and TecDoc integration.

Scaling from one to three platforms

I kept consistency of references, products, prices, stock, images, events and compatibilities across two WordPress sites and one Django application.

  • WordPress
  • Django

The environment grew to two WordPress platforms and one Django application, with shared catalogs and application-specific data. One platform targeted B2B customers and added accounts, commercial terms and B2B features.

Three applications

WordPress

Catalog and e-commerce operations

WordPress B2B

B2B customers and commercial terms

Django

Application with its own catalog and logic

Data that had to keep the same meaning

Product identity

  • References
  • Identifiers
  • Products

Catalog structure

  • Categories
  • Images
  • Compatibilities

Operational status

  • Prices
  • Stock
  • Events

Consistency across platforms

Even when each application had specific features and data, shared entities had to keep consistent references, relationships and meaning.

Same identity

The same reference or product had to resolve against the same entity regardless of the application.

Same meaning

Categories, relationships and compatibilities had to keep the same interpretation across platforms.

Consistent state

Price, stock and other operational data had to stay consistent with the sources feeding them.

Product Master, Supplier Offers and price-list normalization

I separated product identity from each supplier’s offers and normalized their price lists so cost, shipping, availability and terms could be compared.

  • Product Master
  • Supplier Offers
  • Supplier price lists
  • References

The same product could be available from several suppliers with different references, prices, shipping, stock and terms.

Master product

Product Master

A single product identity

  • Part
  • Internal reference
  • Description
  • Compatibility

Ejemplo

The same headlight for a 2005 SEAT Ibiza could have several internal offers while the customer saw a single product.

Supplier offers

Supplier Offer

  • Supplier reference
  • Purchase price
  • Shipping
  • Stock
  • Terms

Supplier Offer

  • Supplier reference
  • Purchase price
  • Shipping
  • Stock
  • Terms

Supplier Offer

  • Supplier reference
  • Purchase price
  • Shipping
  • Stock
  • Terms

Reference resolution

Supplier reference

Identifier received in each price list

Equivalence

Relationship between the supplier reference and the corresponding part

Product Master

Resolution against a single internal product identity

Before comparing pricing, it was necessary to confirm that the different references really corresponded to the same part.

Price-list normalization

Each supplier price list was transformed into a common structure and resolved against the Product Master before it could be compared.

Received data

FieldReference
FieldPurchase price
FieldShipping
FieldStock / availability
FieldTerms

Normalized structure

FieldProduct Master
FieldCoste
FieldShipping
FieldAvailability
FieldTerms

Ofertas comparables

Same comparison base

Coste

Purchase price on the same product identity

Shipping

Logistics cost associated with the offer

Availability

Stock or availability reported by the supplier

Terms

Commercial terms applicable to that offer

Once identity was resolved and data normalized, different supply alternatives could be compared on the same product.

Supplier selection, matching and Source of Truth

I implemented supplier-selection logic based on matching, freshness, actual cost, shipping, availability, margin and terms.

  • Supplier Offers
  • Matching
  • Stock
  • Rates
  • References

Candidate offer

Each Supplier Offer represented a real supply alternative for the same Product Master.

Supplier reference
Purchase price
Shipping
Stock
Terms

Pre-validations

Matching

The reference had to be correctly resolved against the Product Master to avoid comparing different parts or losing equivalent offers.

  • Product identity
  • Equivalent references
  • Correspondence with Product Master

Validity

Rate, stock and terms had to be up to date before using an offer in the decision.

  • Current rate
  • Updated stock
  • Applicable terms

Comparison

Once the offer was validated, the decision was not based only on purchase price.

Coste real

Purchase price plus costs associated with the offer.

Shipping

Transport cost associated with the supply.

Availability

Stock available at the time of the decision.

Margin and terms

Economic impact and applicable commercial terms.

Selection

The selected offer was the one that best matched the real order conditions once identity was resolved and data validity checked.

Selected supplier

Result of comparing the valid alternatives available for that Product Master.

Impact of incorrect data

  • Incorrect matching → comparison across different parts
  • Outdated rate → incorrect cost
  • Outdated stock → supply incident

Technical integration with Smart Shopping

I secured the technical layer of feeds, events, conversions and measurement required by Smart Shopping, while the agency defined the campaign strategy.

  • Merchant Center
  • Smart Shopping
  • Google Ads
  • Analytics

Responsibility split

Agency

It defined the strategic acquisition side.

  • Estrategia
  • Campaign structure
  • Creatives
  • Budgets
  • Optimization

Own responsibility

I prepared and maintained the technical base so Smart Shopping could operate correctly.

  • Merchant Center
  • Feeds
  • Tagging
  • Events
  • Conversions
  • Analytics
  • Google Ads
  • Incident debugging

Technical layer implemented

Catalog / feed

  • Product catalog
  • Titles and descriptions
  • Price and availability
  • Identifiers and images

Merchant Center

  • Feed validado
  • Diagnostics
  • Rejections and warnings
  • Quality of the data sent

Measurement

  • Tagging
  • Events
  • Conversions
  • Analytics

Google Ads / Smart Shopping

  • Cuenta conectada
  • Product Data
  • Conversion signals
  • Debugged incidents

My work was to ensure the catalog reached Merchant Center correctly and that event and conversion measurement reliably fed Google Ads and Analytics integrations.

Operational result

Operational feed

The catalog could be published and maintained with controlled incidents.

Active measurement

Events and conversions were available for the advertising layer.

Stable technical support

The agency could run campaigns on a maintained and debugged technical base.

TecDoc and automotive Master Data integration

I integrated TecDoc by resolving relationships among vehicles, makes, engines, OE/OEM, equivalences and compatibilities with our catalog and applications.

  • TecDoc
  • OE/OEM
  • WordPress
  • Django

Domain introduced by TecDoc

Vehicles

Fitment and compatibility entity

Makes / models

Vehicle hierarchy

Engines

Technical vehicle variant

OE/OEM references

Manufacturer references

Equivalences

Relationships between references

Product families

Technical part grouping

Compatibilities

Part–vehicle relationship

Integration with our applications

Internal references

Linking to the own catalog

Supplier catalogs

Cross-matching with external references and equivalences

WordPress / Django

Data consumption in catalog platforms

Filters and search

Applying the data to navigation, search and compatibilities

Identity resolution

The critical part was distinguishing whether a reference pointed to the same product, an equivalence, a compatible alternative or a different part.

Same product

The reference resolved against the same part in our catalog.

Equivalent reference

The part was the same, but the reference came from another nomenclature.

Alternativa compatible

The part was not identical, but could be applied to the same vehicle or context.

Different part

The reference must not be mixed with the primary identity or its equivalences.

That work made it possible to integrate TecDoc without breaking catalog identity, compatibilities or the applications' search logic.

Migration from Smart Shopping to Performance Max

I adapted feeds, conversions, products, events and integrations during the replacement of Smart Shopping with Performance Max.

  • Merchant Center
  • Performance Max
  • Google Ads
  • Analytics

Environment change

Smart Shopping

Previous base on which feed, measurement and integrations already existed.

Performance Max

New environment the existing technical layer had to be adapted to.

Migration was not about rebuilding campaign strategy, but about adapting products, signals and measurement to the new technical model.

Adapted scopes

Feeds and product

  • Feeds
  • Products
  • Merchant Center

Conversion and signals

  • Conversions
  • Objetivos
  • Signals
  • Audiencias
  • Events
  • Tagging

Integrations

  • Google Ads
  • Analytics

Reconfigured technical base

Catalog / Merchant Center

Product, feed and availability prepared for the new environment.

Measurement

Events, conversions and signals reviewed to maintain technical continuity.

Integrations

Connections with Google Ads and Analytics adapted to the new operating model.

Migration result

Feed adaptado

Products and their availability could continue to be used in the new environment.

Reviewed measurement

Conversions, events and signals were ready for the technical transition.

Maintained integration

Google Ads and Analytics remained connected on the adapted technical base.

Migration required adjusting the existing infrastructure without losing coherence among catalog, measurement and integrations.

2022–2023

Collibra, Data Governance and measurement architecture

Adding TecDoc substantially increased the number of entities, references and relationships that had to be maintained. We evaluated Microsoft Purview and Collibra and finally adopted Collibra. I handled a substantial part of the technical implementation, modeling and maintenance automation, while continuing to work on GTM, dataLayer, GA4 and data contracts across the three platforms.

Formalizing governance: Purview and Collibra

The complexity introduced by TecDoc led to formalizing Data Governance; we evaluated Microsoft Purview and selected Collibra for maturity, depth, flexibility and fit.

  • Microsoft Purview
  • Collibra

Reason for formalization

TecDoc multiplied entities, identifiers, equivalences and relationships until relying on isolated scripts, scattered documentation and implicit knowledge became insufficient.

More entities
More identifiers
More equivalences
More relationships

Evaluation

Microsoft Purview

We evaluated it through tests, but for our case it did not offer the depth, flexibility and maturity we needed in a heterogeneous environment.

Evaluated

Collibra

It offered a better fit for the model we had to govern and the relationships we needed to maintain.

Selected

Decision criteria

Maturity

Enough capacity to sustain a real governance model.

Depth

Level of detail needed for assets, relationships and mappings.

Flexibility

Ability to adapt to heterogeneous sources and structures.

Fit

Fit with the data model and the relationships we needed to maintain.

Decision

Collibra

Selected for its better fit to the model and the level of governance we needed.

Collibra implementation

I handled a substantial part of Collibra implementation and maintenance, including mappings, relationships, nomenclatures, sources, consumers and rules of the real ecosystem.

  • Collibra
  • Mappings
  • Assets
  • Relationships

Knowledge transferred into the model

I moved into Collibra a substantial share of the knowledge that previously lived across systems, documents and operational know-how.

SystemsDocumentationOperational knowledge

Model governed in Collibra

Implemented structure

Model

Definition of structures and nomenclatures to represent the data ecosystem.

  • Structures
  • Naming conventions
  • Adaptation to new sources

Mappings and relationships

Connection between fields, assets, products, suppliers and references.

  • Mappings between fields and assets
  • Product ↔ supplier
  • Supplier ↔ reference

Governance

Documentation and rules needed to preserve the meaning of the model.

  • Sources and consumers
  • Rules
  • Exceptions

Model relationships

Data flow

Source

Field / asset

Consumer

Product relationships

Product

Supplier

Reference

The goal was to turn scattered operational knowledge into a maintainable structure of assets, mappings, relationships, sources, consumers and rules.

Collibra automation and maintenance

I developed reusable processes to prepare, validate and maintain Collibra data through changes in suppliers, TecDoc, catalogs and rules.

  • Collibra
  • Scripts
  • Mappings
  • Datasets

When volume made it impractical to maintain the model manually, I developed scripts to transform structures, normalize names, validate fields, compare datasets, detect differences and prepare additions or updates.

The same processes were reused when suppliers, catalogs, attributes or relationships changed, reducing manual work and making maintenance more consistent and reproducible.

Change inputs

Suppliers

Changes in structures, references or received data.

TecDoc

Changes in entities, references or technical relationships.

Catalogs

Changes in products, attributes and catalog structures.

Model

Changes in attributes, relationships or rules.

Maintenance process

Preparation

  • Transform structures
  • Normalize names
  • Compare datasets

Validation

  • Validate fields
  • Detect differences
  • Prepare changes

Review

Changes were reviewed before being incorporated into the model.

Model update

Collibra

The model was updated more consistently and reproducibly as the ecosystem changed.

Data Contracts and instrumentation with GTM/dataLayer

I defined consistent event contracts between WordPress and Django and implemented GTM and dataLayer as a common instrumentation layer.

  • Google Tag Manager
  • dataLayer
  • JavaScript
  • WordPress
  • Django

Common instrumentation

I worked with tags, triggers, variables, JavaScript, ecommerce, conversions and consent in Google Tag Manager. The dataLayer acted as the interface between applications and measurement tools.

Source applications

WordPress ×2

Two WordPress platforms generating events with the same contractual structure.

Django

Django application using the same event contract.

Event contract

Event name

Common identifier of the measured action.

Required fields

Minimum data the event had to provide.

Identifiers

Values needed to correctly relate the event.

Types and values

Expected structure and content for each field.

Formats

Consistent representation across applications.

Shipping terms

Rules that determined when the event could be emitted.

Ejemplo: compra

Required fields

transaction_idvaluecurrencyitems

A purchase had to consistently provide transaction_id, value, currency and items regardless of the source application.

Instrumentation flow

Application

Event origin.

dataLayer

Common data interface.

Google Tag Manager

Processing of tagging and send rules.

Analytics / Google Ads

Measurement and conversion destinations.

Across three platforms, I standardized event names, required fields, identifiers, types, values, formats and send conditions.

Migration from Universal Analytics to GA4

I rebuilt the measurement model in the migration to GA4: events, conversions, ecommerce, tags, triggers, dataLayer, Ads and JavaScript logic.

  • GA4
  • Google Tag Manager
  • dataLayer
  • Google Ads
  • JavaScript

Previous model

Universal Analytics

Measurement model that had to be replaced.

Instrumentation reconstruction

Events and ecommerce

Reconstruction of business actions and the ecommerce model.

  • Events
  • Conversions
  • Ecommerce

Tagging

Adaptation of the instrumentation layer.

  • Etiquetas
  • Triggers
  • dataLayer
  • JavaScript

Goals and audiences

Review of goals and audiences linked to the new model.

  • Objetivos
  • Audiencias

Integrations

Adaptation of measurement-dependent connections.

  • Google Ads

Migrated model

GA4

Events, conversions and integrations adapted to the new measurement model.

The retirement of Universal Analytics forced a full review of the instrumentation model. I adapted events, conversions, ecommerce, tags, triggers, dataLayer, Google Ads integrations, goals and audiences, and also reviewed platform-specific JavaScript.

Data reconciliation, offline conversions and first-party data

I implemented reconciliation of campaigns, leads, customers, sales and identifiers to relate offline conversions to their origin and keep first-party data consistent.

  • Google Ads
  • Email
  • Phone
  • Order IDs

Offline conversion reconciliation

Campaign

Acquisition origin.

Interaction

Prior action recorded.

Lead

Contact related to the opportunity.

Sale outside the web flow

Conversion completed outside the online journey.

Registro interno

Record used to reconcile the operation.

Offline conversion

Conversion returned to the platform with its context.

Data used for reconciliation

IdentifiersDatesValuesLeadsCustomersOrdersDeduplicationValidations

Part of sales could be completed outside the web flow. To relate them to their origin I worked with identifiers, dates, values, leads, customers, orders, deduplication and validations.

First-party data preparation

Email

First-party data prepared for external integrations.

Phone

Second first-party identifier prepared under the same quality rules.

Preparation

Cleaning

Removal of unusable formats or characters.

Normalization

Homogenization of data representation.

Deduplication

Reduction of repeated records.

Validation

Verification that the data could be used correctly.

Consent

Control of the conditions of data use.

Destination

External integrations

First-party data prepared and validated for use in the corresponding integrations.

I also normalized and prepared first-party email and phone for external integrations, applying cleaning, deduplication, validation and consent controls.

2023–2025

Product Data, MDM, taxonomy and business rules

Between 2023 and 2025 I expanded my responsibilities across Consent Mode, product metadata, search and compatibilities, professional pricing, Customer Master Data and Vehicle Data. In parallel, the catalog stopped being mainly lighting-focused and expanded into many bodywork families and other components: product volume grew roughly threefold and the taxonomy went from about five or six main categories to more than thirty. That growth forced a review of normalization, classification, Google feeds, logistics and supplier/carrier selection rules.

Consent Mode v2 and state debugging

I implemented and debugged Consent Mode v2 on GTM, dataLayer and gtag, controlling signals, states and execution order.

  • Consent Mode v2
  • Google Tag Manager
  • dataLayer
  • gtag
  • CMP
  • JavaScript

I worked directly with Consent Mode, Consent Mode v2, GTM, dataLayer, gtag, JavaScript and the CMP.

Consent signals

analytics_storage

Control of storage associated with analytics.

ad_storage

Control of storage associated with advertising.

ad_user_data

Control of user-data use for advertising purposes.

ad_personalization

Control of advertising personalization.

Execution order

User choice / CMP

The CMP collected the user choice.

Consent state

The choice became a state usable by instrumentation.

dataLayer / gtag

State propagated into the data and configuration layer.

Google Tag Manager

GTM used that state to decide tag behavior.

Tags, events and conversions

Final execution depended on the state available at that moment.

Debugged incidents

Premature execution

Tags fired before consent was known.

Event loss

Events that failed to register correctly.

Missing conversions

Conversions that did not appear in the expected measurement.

Duplicates

Events or conversions recorded more than once.

Inconsistent states

Differences between the expected state and the one used by instrumentation.

The implementation had to control analytics_storage, ad_storage, ad_user_data and ad_personalization. I also debugged execution-order issues that could cause tags to fire before consent was known, event loss, missing conversions, duplicates or inconsistent states.

Metadata standardization for search and filters

I standardized attributes needed for search, filters, categories and compatibilities so products could be found and published correctly.

  • TecDoc
  • OE/OEM
  • Merchant Center

Publishing the product was not enough if data needed to search or filter it was missing. I normalized attributes such as part type, side, position, manufacturer, references, OE/OEM, technology, category and compatibility.

Standardized metadata

Identity

Data needed to identify the part and relate it to its references.

  • Manufacturer
  • References
  • OE/OEM

Classification

Data used to determine what type of product it was and where it should appear.

  • Part type
  • Category

Technical application

Attributes needed to resolve position, technology and compatibility.

  • Side
  • Position
  • Technology
  • Compatibility

Minimum set before consumption

Fields

Mandatory information for the product to be usable correctly.

Vocabularios

Values and nomenclatures normalized across products and sources.

Relationships

Links needed among product, references, vehicle and compatibilities.

Destinations

Search

Locating the product through its normalized data.

Filters

Filtering by attributes, category and technical characteristics.

Vehicle-based navigation

Catalog contextualization based on the selected vehicle.

Web

Consistent product publication across platforms.

Merchant Center

External catalog consumption under specific data requirements.

Each product had to meet a minimum set of fields, vocabularies and relationships before feeding search, filters, vehicle-based navigation, the web and Merchant Center.

B2B pricing and professional pricing controls

I implemented B2B pricing and access controls to apply the correct rate by customer, segment, volume and commercial terms.

  • B2B rates
  • Segments
  • Discounts
  • Permissions

In the professional area, price started to depend on the relationship between product, customer, segment and commercial terms. The model used data such as customer type, volume, pricing level, discounts, exceptions and validity.

Pricing inputs

Product

Part on which the professional rate had to be calculated.

  • Product identity

Customer / segment

Commercial context used to determine the pricing level.

  • Customer type
  • Volume
  • Pricing level

Commercial terms

Rules that could modify the applicable rate.

  • Discounts
  • Exceptions
  • Validity

Applicable rate

Result of combining product, customer or segment and commercial terms.

Product + Customer / segment + Terms → Applicable rate

Access control

I also restricted visibility of professional prices and terms to reduce errors and prevent a rate from another customer or segment from being shown or shared out of context.

Price visibility

The professional rate had to be shown only in the corresponding context.

Professional terms

Commercial terms had to remain associated with the correct customer or segment.

Least Privilege

Access was limited to the information needed for each context.

Data Access Governance

Access rules reduced the risk of exposing rates out of context.

These controls were applied through existing system logic, not through a formal DLP suite.

Customer Master Data and commercial status

I modeled customers and workshops as business entities related to contacts, accounts, rates, orders, balance and commercial status.

  • User account
  • Customer
  • Workshop
  • Orders
  • Balance / debt

Entity model

Person / contact

Person who could act as a contact for an account or company.

User account

Identity used to access the platform.

Business customer

Entity to which commercial and operational terms were applied.

Workshop / business

Professional organization related to contacts, orders and rates.

Separating these entities avoided duplicates or incorrect associations.

Workshop relationships

Workshop / business

Contacts

People associated with the workshop.

Orders

Operations linked to the B2B customer.

Rate and terms

Applicable commercial terms.

Commercial status

Customer financial and operational situation.

A workshop could have several contacts, orders, a given rate, terms and its own commercial situation.

Commercial status

Balance

Accumulated financial situation.

Debt

Outstanding amounts associated with the customer.

Open transactions

Operations not yet closed.

Payment status

Payment situation used in the commercial context.

Accuracy and, especially, freshness of those data could condition new commercial operations.

Stock, lead time and carrier selection

I related supplier availability and lead time to transport costs and timelines, selecting the most suitable carrier by part size, shipping cost and estimated delivery time.

  • Supplier Data
  • Stock
  • Lead Time
  • Carriers
  • Shipping cost

Supply data

Purchase cost

Acquisition price associated with the supplier offer.

Shipping

Logistics cost associated with supply from the supplier.

Availability

Stock available at the time of the decision.

Margen

Economic impact of the supply alternative.

Lead time

Expected time until the part is available.

Logistics constraints

Part size and volume

Dimensions that could restrict carriers or increase shipping cost.

Shipping cost

Actual cost of shipping that part.

Carrier restrictions

Transport terms applicable by product type and size.

Estimated delivery time

Lead time that could be communicated to the customer based on supplier and transport.

With the addition of bodywork parts, product size and volume also started to condition logistics: a large part could make an apparently cheaper offer stop being optimal because of shipping cost.

Supply decision

Supplier

Supply alternative selected by cost, availability and margin.

Carrier

Logistics alternative selected by size, restrictions, cost and lead time.

Final decision

Coste total

Economic result of supplier + transport.

Estimated delivery

Lead time resulting from availability + transport.

Customer

Receiving an estimated date consistent with the selected alternative.

I compared shipping alternatives by part dimensions, cost, carrier restrictions and estimated delivery time. The final decision combined supplier and transport to reduce total cost without compromising the date communicated to the customer.

Vehicle Master Data, license plate and VIN

I integrated Vehicle Master Data, license plate/VIN and TecDoc to resolve product identity and compatibilities, controlling false positives and false negatives in the displayed catalog.

  • TecDoc
  • VIN
  • License plate
  • OE/OEM

Vehicle identification

License plate

Input used to identify the vehicle when available.

VIN

Identifier used to resolve the vehicle with higher precision.

Manual selection

Alternative when the vehicle was selected directly by its characteristics.

Vehicle Master Data

Manufacturer

Vehicle make.

Model

Model identified.

Version

Specific variant within the model.

Engine

Technical vehicle configuration.

Year

Period used to bound compatibilities.

TecDoc identifiers

Identifiers used to relate the vehicle to TecDoc.

Search started by first identifying the vehicle via license plate, VIN or manual selection and then querying TecDoc to resolve compatible products. The Vehicle Data domain included make, model, version, engine, year and TecDoc identifiers related to product references and equivalences.

Resolution with TecDoc

References

References related to the part.

OE/OEM

Manufacturer references used to resolve equivalences.

Equivalences

Relationships among technically equivalent references.

Compatibilities

Final relationship between part and vehicle.

Contextual catalog

Products compatible with the identified vehicle.

Saved vehicles

We also allowed saving vehicles in the account to reuse them in search and filters. These relationships required correct association among user, vehicle and identifiers, plus controls on access, storage and minimization.

Usuario

Account the vehicle was associated with.

Vehicle

Saved vehicle entity.

Identifiers

Data needed to keep the correct association.

Access

Control of who could read the information.

Storage

Persistence of the data needed to reuse the vehicle.

Minimization

Keeping only the data needed for the functionality.

Compatibility risk

False positive

Showing an incompatible part.

False negative

Hiding a valid part.

Product Data Governance, taxonomy and feeds at scale

I governed a catalog that grew roughly threefold, moving from about five or six main categories to more than thirty and incorporating bodywork and other families, with direct impact on taxonomy, feeds, search and Data Quality.

  • Python
  • pandas
  • TecDoc
  • Merchant Center
  • CSV

Catalog scale

≈×3

Product volume

Approximate growth versus the previous catalog.

5–6 → 30+

Main categories

Increase in the taxonomy needed to classify the catalog.

Lighting → bodywork and other families

Domain expansion

Entry of new product families with different classification and logistics requirements.

Between 2023 and 2025 the catalog stopped being mainly lighting-focused and expanded into many bodywork families and other components. That growth roughly tripled product volume and required a much broader taxonomy, with more than thirty main categories and new classification, attribute and compatibility rules.

Taxonomy

Lighting

Historical catalog families.

Bodywork

New families with greater impact on classification and logistics.

Safety parts

Products with specific categorization inside the catalog.

Other product families

Remaining groups added during the expansion.

Feed evolution

Simpler segmentation

At an earlier stage, feeds could be kept more separated by brands.

  • Feeds by brand

More granular segmentation

Catalog growth forced a more precise split and classification of the products sent.

  • Product groups
  • Product families
  • Classification required by Google
  • Merchant Center

The Google feed structure also had to evolve. Feeds that could initially be kept more separated by brands started to require much more granular segmentation by product groups and families, while keeping consistency among internal classification, attributes sent and Merchant Center requirements.

Automation

Python / pandas

Foundation for bulk transformation processes.

Joins and merges

Joining datasets by keys and references.

Deduplication

Detection and reduction of repeated records.

Normalization

Homogenization of fields, names and formats.

Dataset comparison

Detection of changes across versions or sources.

Chunked processing

Batch processing when volume made it impractical to process everything at once.

Validation

Checks before and after transformations.

Source of Truth by attribute

When multiple sources offered different information, I defined the reliable source by attribute.

Stock

From a supplier

Images

From another supplier

Compatibility

From TecDoc

Contenido

From internal information

Consistent catalog

Result of combining each attribute from the source considered reliable for that data.

The same catalog continued to be fed by suppliers, TecDoc and internal information. To keep it consistent I kept applying normalization, matching, deduplication, validations and Source of Truth by attribute.

2025–2026

First-party data, server-side and measurement architecture

In 2025–2026 I went deeper into the technical measurement and first-party data layer, implementing Enhanced Conversions and server-side tagging with normalization, consent, events, identifiers, validation and debugging. In parallel, the company internalized a larger share of Google Ads operations; my responsibility remained focused mainly on Data Quality, tagging, events, conversions and measurement, while commercial and creative strategy belonged to another layer.

Enhanced Conversions and first-party data

I integrated Enhanced Conversions with first-party data to strengthen measurement amid growing restrictions on traditional tracking.

  • Enhanced Conversions
  • Google Ads
  • Google Tag Manager
  • Email
  • Phone

I took part directly in the technical implementation of Enhanced Conversions using first-party data, conversion events, normalization, validation, consent, Google Tag Manager and Google Ads.

First-party data

Email

Customer first-party data used when available and usable under the corresponding consent conditions.

Phone

Second first-party identifier prepared under the same quality and consent rules.

Data preparation

Normalization

Homogenization of data before adding it to the measurement flow.

Validation

Verification that the data had a usable structure before sending it.

Consent

Control of the conditions under which data could be used in measurement.

Conversion context

Event

Business interaction or action that had to be measured.

Conversion

Result associated with the event sent to the measurement platform.

Instrumentation flow

Prepared first-party data

Email / phone normalized, validated and subject to consent.

Google Tag Manager

Instrumentation of the measurement flow.

Google Ads

Destination of the conversion and associated data.

Enhanced Conversions

Strengthening measurement with first-party data.

Technical responsibility

Own responsibility

  • Data preparation
  • Normalization
  • Validation
  • Consent
  • Instrumentation
  • Flow verification

Tool responsibility

  • Data hashing when applicable

Hashing was handled by the corresponding tools; my responsibility was to provide and correctly validate the data and the measurement flow.

Technical Google Ads layer and certifications

In 2025, with greater internalization of Google Ads, my specialization remained focused on Data Quality, tagging, events, conversions and measurement, and I obtained official Google certifications related to advertising and measurement.

  • Google Ads
  • Merchant Center
  • GA4
  • Google Partners

Context change

Early years

The agency concentrated strategy, campaign structure, creatives, budgets and optimization.

2025

The company took on a larger share of Google Ads operations.

That change widened the context I worked in, but my main responsibility remained in the technical data and measurement layer.

Main responsibility

My work focused on preparing, instrumenting, validating and debugging the data that fed measurement and advertising integrations.

Data Quality

Review of consistency of the data used by integrations.

Tagging

Maintenance of the technical instrumentation needed for measurement.

Events

Verification of actions and signals sent from the applications.

Conversions

Validation of the path from the event to the recorded conversion.

Measurement

Debugging of discrepancies and continuity across applications and platforms.

Google Ads

Technical integration of data and conversions with the advertising platform.

Technical ecosystem

Merchant Center

Product, feeds and commercial Data Quality.

GA4

Events, conversions and measurement.

Google Ads

Consumption of product, signals and conversions.

Separation of duties

Strategic layer

Commercial and campaign decisions.

  • Estrategia
  • Creatives
  • Commercial decisions

Technical layer

Data and instrumentation needed to measure and feed the platforms.

  • Data
  • Tagging
  • Events
  • Conversions
  • Measurement

Certifications

In 2025 I obtained official Google certifications related to advertising and measurement.

They formalized knowledge I was already using in production and were also useful in the Google Partners context.

Server-side tagging and measurement

I implemented and maintained the server-side measurement layer as a direct technical responsibility.

  • Server-side tagging
  • Google Ads
  • GA4
  • First-party data

Growing browser and privacy restrictions made it necessary to move part of the instrumentation to a server-side layer, keeping a complementary relationship with client-side measurement.

I directly handled implementing and maintaining that layer, working with structured events, payloads, identifiers, conversions, first-party data, consent, validation and debugging of flows into GA4 and Google Ads.

Measurement architecture

Origin

Browser / Web

Applications generated the source interactions and events.

Processing

Server-side layer

It received structured events and prepared subsequent processing and sending.

  • Structured events
  • Processing

Destinations

GA4 / Google Ads

Destination platforms for measurement and conversions.

Data and context

Payloads

Structure of the data sent across flow layers.

Identifiers

Data used to relate events and conversions.

Conversions

Business events that had to arrive correctly at destinations.

First-party data

First-party data prepared for use within applicable conditions.

Consent

State that conditioned data processing and sending.

Technical operation

Validation

I checked event structure, the data sent and correct arrival at destinations.

  • Fields
  • Values
  • Payload
  • Destination

Debugging

I investigated incidents across the source, the processing layer and destination platforms.

  • Origin
  • Processing
  • Shipping
  • Reception

Client-side and server-side

Client-side

Browser-side instrumentation continued to collect part of the interactions and events.

Server-side

The additional layer made it possible to process and forward certain events while reducing part of the direct browser dependency.

The server-side model complemented client-side measurement; it did not fully replace it.

Direct responsibility

My responsibility included implementation, maintenance, validation and debugging of the server-side layer and associated measurement flows.

This implementation reduced browser dependency and complemented client-side measurement within privacy restrictions.