Fire Pixel

Ecommerce Google Ads management

Products and first orders flowing into a data warehouse, through margin and customer value segments, and back to a shopping auction.
Merchant Center, campaigns, transactions, order lines and product margin meet in one ecommerce management loop.

Ecommerce is not lead generation with a purchase tag substituted for a form.

I manage the Google Ads account, the Merchant Center product feed and the commercial evidence behind the bidding as one system. Brand and non-brand demand, new and returning customers, and products with different margins should not disappear into one blended ROAS number.

This is the ecommerce counterpart to lead generation Google Ads management. It is best suited to UK and Irish businesses spending about £5,000 a month or more. Smaller or uncertain accounts can start with the fixed-fee diagnostic.

One blended ROAS can hide five different businesses

The account total can look healthy while the mix underneath gets worse. Brand demand can subsidise non-brand acquisition. Returning customers can make a new-customer campaign look efficient. High-revenue products can absorb spend despite contributing less profit after discount, fulfilment and refunds.

The economics are therefore worked out separately before the campaign structure is decided.

Commercial cutEvidence usedManagement decision it supports
Brand searchCampaign and search-term classification, with brand controls documentedHow much existing demand the account is harvesting, and whether it should sit apart from acquisition
Non-brand searchGeneric queries, Shopping traffic and campaign costWhat it costs to win demand that did not begin with the business name
New customersCustomer status from the commerce system, eligible first-party lists and the purchase signalAn allowable new-customer acquisition cost or additional customer value
Returning customersOrder history, recency and realised repeat valueRetention, reactivation and reporting decisions without presenting repeat orders as new acquisition
Product or margin groupOrder-line revenue, discounts, refunds, product cost and contribution where suppliedProduct inclusion, custom labels, listing groups, budgets and value rules that reflect what is actually worth selling

These dimensions do not automatically require five campaigns. They require five readable economics. The account is split only where the volume, bidding objective or control gained justifies the extra structure.

The ecommerce management loop

  1. Feed. Keep the eligible catalogue accurate in Google Merchant Center and expose the product attributes the campaigns need.
  2. Reconcile. Join spend and platform conversions to transactions, order lines, refunds and customer status without turning a multi-item order into several orders.
  3. Value. Calculate the useful commercial view by brand and non-brand, new and returning, and product margin.
  4. Activate. Apply the approved structure, product groups, customer lifecycle settings and bidding values at the level Google Ads can use.
  5. Verify. Check feed health, spend, product mix, customer mix and realised commercial outcomes every week. The system flags movement. I decide what changes.

Merchant Center is a control surface, not a feed checkbox

The commerce catalogue is supplied to Google Merchant Center through the route that fits the store: an app integration, a scheduled file, an automated source or an API data source. For larger or less standard catalogues, the Merchant API can manage product inputs and data sources programmatically.

I audit titles, descriptions, GTINs, brand, product type, Google category, images, price, sale price, availability and landing-page consistency. Supplemental data can add controlled attributes without overwriting the store's product record. Custom labels can group products by fields such as margin band, stock position, seasonality or selling rate for reporting and campaign subdivision.

The processed Merchant Center product state matters too. Product eligibility, warnings and disapprovals can be pulled into the monitoring layer, so a fall in eligible inventory is visible before it is mistaken for a bidding problem.

The feed is targeting for Shopping inventory. It also becomes a shared product key between Merchant Center, Google Ads and the warehouse.

Those identifiers can also support product-level advertising reporting. Where conversions with cart data are eligible and correctly implemented, Google Ads can report item, order, revenue and supplied cost or margin metrics. I still reconcile that platform view with the store's transactions and order lines rather than treating it as the financial record.

The warehouse starts with transactions and order lines

The commerce platform remains the record for money. The reference layer keeps separate tables at their real grain:

  • One row per transaction or order.
  • One row per item sold, with product, quantity, discount and supplied cost or contribution.
  • Payment and refund events without silently rewriting the original order.
  • A customer key and a documented new, returning or lapsed definition where the source can support it.
  • Product catalogue and Merchant Center status data keyed to the same SKU or offer identifier.

Google Ads, Merchant Center, GA4, Microsoft Advertising, Meta Ads and Klaviyo can then sit beside those commercial records in a client-owned BigQuery project. Each platform's attributed result remains labelled under its own rules. The warehouse does not force several channels that claim the same order to agree.

From that reference layer I build three useful views: acquisition by brand versus non-brand, customers by new versus returning and later cohort value, and products by SKU, category and margin group. That is the level at which the blended account total becomes actionable.

The warehouse is the plumbing, not merely a dashboard project. Once the sources and definitions are maintained, new analysis and reporting can reuse them instead of rebuilding the joins. See what an ecommerce data warehouse unlocks for those secondary benefits.

Use the simplest customer-value rule that wins

A complicated lifetime-value model is not the starting point.

The first test is deliberately plain: does value visible on the first order, or net value accumulated in the first 90 days, predict revenue or contribution over the later window well enough to make the same commercial decision? For many catalogues, a simple early-value rule may be all the account needs. If it holds up on later customer cohorts, it is cheaper to explain, monitor and maintain than a model.

When the simple rule does not hold, the warehouse can test what adds signal. Facts known by the scoring date, such as first-order product mix, order value, discount and acquisition route, can be evaluated against later outcomes. Training and validation are split by time, the result is compared with the simple rule, and later purchases are not allowed to leak into a score claimed to exist earlier.

Predictions begin in reporting. Only a result that holds up out of sample may inform an approved customer segment or value input. If the model cannot beat the simple rule, it is redundant and does not reach the account.

What I can change in the campaigns

The exact build follows the evidence, but ecommerce management can include:

  • Separate brand Search from non-brand acquisition, using current brand controls where Performance Max would otherwise mix the traffic.
  • Structure Performance Max, Standard Shopping and Search around the role each one needs to perform, rather than importing a generic template.
  • Divide listing or product groups by category, product type, brand, item ID or Merchant Center custom label where the economics justify it.
  • Exclude products that cannot support the acquisition cost, or place them in a different budget and bidding treatment.
  • Supply a truthful new-customer signal and an evidence-based additional customer value before using customer acquisition or lifecycle goals.
  • Use net revenue, contribution or an approved value proxy instead of treating gross checkout revenue as profit.
  • Keep Standard Shopping where query visibility or product-level control is worth more than consolidation.
  • Stage changes so feed, bidding, customer classification and landing-page changes are not all judged as one intervention.

Google's bidder still makes the auction-time decision. My job is to give it a catalogue, value and constraint that correspond to the business, then check what the system actually bought.

What the weekly review checks

  • Spend, budget and value against the agreed commercial constraint.
  • Brand and non-brand traffic mix.
  • New, returning and unknown customer mix, with the platform view compared with the commerce record.
  • Revenue, refunds and contribution by product or margin group.
  • Product coverage, price and availability mismatches, warnings and disapprovals in Merchant Center.
  • Search terms, product groups, listing groups and products absorbing or losing material spend.
  • Source freshness, duplicate transaction IDs, order-total reconciliation and refund lag in the warehouse.
  • Any approved audience, customer-list or value-feed output that has stopped refreshing or changed unexpectedly.

The first 90 days of management

Days 1 to 30: establish the commercial truth

I inventory Google Ads, Merchant Center, GA4, the store, payment and refund routes, and the product and customer identifiers available in each. The baseline separates brand from non-brand, new from returning, and revenue from supplied contribution. It records feed coverage, disapprovals, transaction duplication and the current campaign mix.

Days 31 to 60: repair the feed and value route

I fix or specify the agreed Merchant Center route, product attributes and labels, then reconcile purchase values and customer status against the store. Separately scoped warehouse or tracking work is built and tested here where it is needed.

Days 61 to 90: stage the account decisions

Once the inputs are credible, I stage the campaign, product-group, customer-value and bidding changes over at least one or two conversion cycles. The weekly reconciliation then becomes the steady operating loop.

What you get

  • Ongoing Google Ads, Shopping and Performance Max management.
  • Merchant Center feed and product-status decisions at the agreed level.
  • A readable unit-economics model for brand, non-brand, new, returning and product or margin groups.
  • Weekly checks across account, feed and commercial outcomes.
  • A change log with the business reason for material decisions.
  • Quarterly re-derivation of the value rules, or more often where the volume and commercial change justify it.

Store integration repair, a new warehouse, historical backfill, custom feed engineering, creative production and third-party connector costs are scoped separately after the existing system is mapped.

Evidence you can inspect

For a UK ecommerce business, historical first-order characteristics showed a useful relationship with later customer value. The result was validated on later cohorts before the segments informed reporting and audience inputs. That relationship is account-specific and needs continued out-of-sample checks.

Anonymised value calculations, feed QA records, warehouse reconciliation checks and model validation outputs are available on request. They show whether the system was implemented. They do not guarantee that another account will produce the same result.

Matching an order to an ad click is attribution hygiene. It is not proof that the ad caused the order. Holdout or geo tests answer incrementality where the volume justifies them.

Who this is not for

This is not a fit if the store cannot expose reliable transaction and product identifiers, nobody can explain product costs and refunds, or the order volume is too low to evaluate a change. A simpler feed repair or account diagnostic may be the right first job.

It is also not a fit if you want one blended platform ROAS treated as profit, guaranteed short-term performance, or unattended software changing the account.

Sources checked

Related: Data warehouse · Targets from unit economics · Shopping CSS

Pricing

Management starts at £1,000 a month or 10 per cent of media spend, whichever is higher. Setup and warehouse work are scoped separately. The initial term is three months, followed by rolling monthly management.

See pricing and ways to work.

Discuss ecommerce management

FAQ

Is this just Performance Max management?

No. Performance Max, Shopping and Search are the activation layer. The management product also covers Merchant Center feed decisions, product economics, new-versus-returning customer measurement, transaction reconciliation and the weekly decisions that reach the account.

Do you take over the product feed?

I audit and manage the Merchant Center route at the level the account needs. That can mean fixing the store integration, managing primary or supplemental data sources through the Merchant API, or briefing your developer. The store remains the source for product, price and stock facts.

Do we need a lifetime-value model?

Often, no. The first test is whether first-order value or value accumulated in the first 90 days already predicts the later commercial outcome well enough. If a simple rule holds up on later cohorts, I use it. A model is introduced only when it adds useful out-of-sample signal.

Can Google Ads distinguish new and returning customers?

Google provides customer lifecycle goals and new-customer reporting, but the business still needs a reliable customer definition and maintained first-party data. I reconcile the platform classification with the commerce system rather than assuming every platform label is correct.

What spend does this suit?

As a guide, ongoing management is designed for businesses spending about £5,000 a month or more, with enough orders to evaluate changes. Smaller or uncertain accounts can start with the fixed-fee diagnostic.

Ask an AI about this page: ChatGPTClaudeGoogle AI ModePerplexity