Auto bidding on your own data: feeding margin, lead quality and stock into Google and Meta

Automated bidding is only as clever as the values you hand it

Smart Bidding is the name Google gives to the bid strategies that set a price for every single auction from its own prediction of how likely a click is to convert and how much that conversion will be worth. At the moment of the auction it looks at the device, the location, the time of day, the search query, the browser, the language and whether the person is on one of your audience lists.¹ Two of the strategies, Target ROAS (return on ad spend) and Maximise conversion value, bid on value rather than on the count of conversions, and both need a value attached to every conversion before they will run.²³

That last sentence is the whole article. The machine has signals you will never see. It does not have the one thing you see every day: what a conversion was actually worth. It cannot see the margin on the order, the refund a fortnight later, the lead that turned out to be a student asking for a sample, or that the product it just sold was the last one on the shelf. Tell it every lead is worth €1 and it will buy you the most leads. Tell it a lead from a food manufacturer asking for 5,000 boxes is worth 90 times a lead from a free email address asking for 20, and it will go and find the manufacturers.

So the job is not to replace the optimiser. I tried that in my early days, and the old version of this article still carried some of that bravado. The job is to feed it. Your data goes in through five doors, and this piece walks through each, with the arithmetic, the consent rules in front of all of them, and one invented business from Cork as the running example.

Worked example: a packaging supplier in Cork

Shandon Packaging is an invented business to business supplier in Cork. It sells cardboard boxes, food trays and printed sleeves to small food producers, bakeries and a few online shops. The owner is Dónal. Nobody real, every number made up so that every step can be shown. Dónal sells through a quote form: a visitor says what they need and how many, Dónal or his colleague Aisling reply with a price, and a share of those quotes become orders.

Dónal spends €2,000 a week on Google Ads with a Target CPA (cost per acquisition) of €50 a lead. He gets about 40 leads a week, about ten become customers, and a new customer's first order carries on average €180 of margin. So the paid channel produces around €1,800 of first order margin for €2,000 of spend. Repeat orders eventually make it worthwhile, but on the first order it loses money, and Dónal suspects the optimiser is finding him a good few people who want 20 boxes for a wedding.

He is right, and the fix is not a cleverer bid. It is a truer value.

The five doors your data can go through

Google gives first party data five routes into bidding. The names change every couple of years, but the ideas are stable.

The first is the offline conversion import. When someone clicks an ad, Google appends a click identifier, the GCLID, to the landing page address. You store it with the lead or the order. Days or weeks later, when the lead becomes a sale, you send the GCLID back with a conversion action, a time and a value, and Google attaches the real outcome to the original click.⁴ The upgraded form is enhanced conversions for leads, which also sends a hashed email address or phone number from the form, so the match survives when the click identifier is lost. Google recommends it over the plain import and reports a median 10% increase in measured conversions for advertisers who use first party data alongside click identifiers.⁴⁵ Through the Google Ads API each record is a ClickConversion with the conversion action, a time later than the click, a value, a currency, an order_id to stop duplicates, up to five hashed identifiers, and a consent field Google strongly recommends you fill.⁶ If the sale is refunded or the value changes, you send a retraction or a restatement against the same order_id.⁷ One note for anyone building this in 2026: Google is moving these uploads to its Data Manager API, and the old UploadClickConversions call now fails for developer tokens that had not used it before June 2026.⁶⁸

The second door is conversion value rules. These tell Smart Bidding that a conversion from a certain audience, location or device is worth more or less than the value you recorded, for example "multiply by 1.5 for anyone on the existing customers list". The adjusted value is used for bidding and reporting, and it applies to Target ROAS and Maximise conversion value.⁹ Rules are blunt next to a real uploaded value, but they are the right tool for something you know in advance about a group rather than something you learn later about one order.

The third door is Customer Match. You upload hashed emails, phone numbers or postal details of your own customers and Google builds an audience list from the matches. Lists work across Search, Shopping, YouTube, Gmail and Display, and any campaign on Smart Bidding includes your Customer Match lists as a signal unless you opt out.¹⁰ Google wants at least 5,000 uploaded members for a list to stand a realistic chance of being large enough to target.¹¹

The fourth door is the seasonality adjustment. You tell Smart Bidding that for a short, dated event, a three day sale say, you expect conversion rates to move by a stated percentage, and it bids as if that were already true rather than spending two days learning it. Google is explicit that this is for events of one to seven days, that it works less well beyond 14, and that the ordinary seasonal pattern is already in the model.¹²

The fifth door is code. Google Ads scripts are JavaScript programs that run inside your account on a schedule, hourly if you like, and can change bids, budgets, keywords and status from performance or from an outside data source.¹³ The Google Ads API does the same from your own servers. Under Smart Bidding the useful thing to change from code is rarely a bid, because Smart Bidding ignores your manual bid adjustments apart from a device adjustment of minus 100%.²³ What you change from code is what you feed it: the values, the rules, the lists, the budgets, and whether a product group is on at all.

Meta has the same idea with different names. The Conversions API lets your server send events to Meta directly, alongside or instead of the browser pixel, with a value and a currency in the payload, and value optimisation then weights delivery towards the conversions you report as more valuable.¹⁴¹⁵ If you run pixel and server together, each event needs a shared event_id so Meta can drop the duplicate, and it only does that within 48 hours.¹⁶ Meta also now accepts a net_revenue field on the Purchase event, or an estimated_margin per product in the catalogue, so delivery can be optimised for profit rather than revenue, once you have at least three distinct profit values and 100 conversions a week.¹⁷ The rest of this article talks Google, because that is where the examples are, but every principle carries straight across.

An example: Dónal's quote form stores the GCLID in a hidden field and the business email on the lead record. When Aisling marks a quote as won in the CRM and enters the margin, a nightly job sends the GCLID, the hashed email, the margin and an order_id to Google. That is door one. Every six months Dónal uploads the emails of customers who ordered twice: door three. Before his January trade show he schedules a three day adjustment: door four. The script that does the upload and switches off a product group when stock drops below a week's cover: door five. Door two he uses once, to mark the trade show audience up by 20%.

Consent comes before any of it

Here is the rule I will not bend, and the one I would like you to take away even if you skip the maths. Nothing from a visitor who refused tracking ever feeds a bidding audience or a value upload. Measurement, yes, within what the law allows. Personalisation, no.

The legal footing is plain, and in Ireland it is the EU's. Google's EU user consent policy requires that for end users in the European Economic Area, the UK and Switzerland you obtain consent for cookies and similar storage where the law requires it, and for "the collection, sharing, and use of personal data for personalization of ads", keep records, and give clear instructions for withdrawing it.¹⁸ The Customer Match policy allows only data you collected yourself, in a first party context, with consent for sharing where the law requires.¹⁹ In Ireland the rule on storing or reading anything on a device is Regulation 5 of the ePrivacy Regulations 2011, which allows it only with the user's consent and after clear and comprehensive information about the purpose.²⁰ The Data Protection Commission (DPC), which enforces those Regulations alongside the GDPR, says in its guidance on cookies and other tracking technologies that the same rule covers pixels, local storage, SDKs and device fingerprinting, not just cookies, and that the ePrivacy rules apply first, with the GDPR governing whatever personal data flows afterwards.²¹

Google has built the consent state into the plumbing. Every conversion upload and every Customer Match job carries ad_user_data and ad_personalization fields. A Customer Match job with either set to denied is rejected outright. For EEA users with no consent value at all, Google treats the record as not consented and does not use it for personalisation.⁶¹¹ So for an Irish business the machinery enforces part of this for you. It does not enforce all of it. Google only sees what reaches the upload, so whether a refuser's click identifier was ever stored, and which event is wired to which conversion action, is a discipline that has to live in your own code.

In my own setups the discipline is a renaming rule. The event a consenting visitor fires is called, say, quote_requested. The event a refusing visitor fires from the server, stripped of identifiers, is called quote_requested_anon, and it is attached to no audience, no bidding conversion action and no upload. It counts, so I know how many quotes the site produced. It never personalises anything. The two names make it impossible to wire the wrong one into a Customer Match list by accident six months later, which is exactly the accident that happens when both events share a name and differ only in a flag. The plumbing is in the articles on event tracking and consent mode and server side tracking.

An example: of Dónal's 40 weekly leads, nine arrive from visitors who declined. Those nine have no GCLID stored and no hashed email sent anywhere. Aisling quotes them like everyone else, and when one becomes a customer the margin is booked like everyone else. The nightly upload simply skips them. Dónal's bidding learns from 31 leads a week rather than 40, which is a cost, and it is the cost of doing it properly. The other way round costs more.

Value means margin, never revenue

The most common mistake with value based bidding has nothing to do with the technology. It is sending revenue. Revenue tells the optimiser that a €1,000 order of printed sleeves at 12% margin is worth four times a €250 order of plain boxes at 55% margin. In euro that stay in the business, the plain boxes are worth more. Send revenue, and the machine will dutifully fill your order book with the thin stuff.

The value I send for an order is the margin on that order, and where the customer is likely to come back, the margin on the first order plus the discounted margin of the repeat business:

$$V_{\text{order}} = M_1 + M_{\text{repeat}} \times \frac{r}{1 + d - r}$$

Here $V_{\text{order}}$ is the value uploaded for the order, $M_1$ is the gross margin on the first order (revenue less cost of goods, packaging, delivery and payment fees), $M_{\text{repeat}}$ is the margin you expect from that customer in a typical later year, $r$ is the share of such customers who are still ordering a year later, and $d$ is the discount rate that makes a euro next year worth less than a euro today. The fraction is the customer lifetime value multiplier, explained from scratch in Foundations: lifetime value, including the section on why revenue in place of margin is the thing that goes wrong.

Two cautions. Google's guidance on conversion values is neutral about what the number represents, and describes per transaction values as "more representative" than a flat value per conversion.²² Nothing stops you sending a profit figure, and Meta has gone as far as adding a dedicated profit field.¹⁷ The second caution: a value that is a fixed percentage of revenue teaches the optimiser nothing, because the ranking of conversions is unchanged. Meta says this in so many words.¹⁷ The value only helps when margins genuinely differ between products, customers or channels, which, in every shop and supplier I have worked on, they do.

Worked example: what one order is worth to Shandon Packaging

A bakery in Kinsale orders 2,000 printed food trays. Revenue €1,400. Cost of goods €910, delivery €45, card fees €25. First order margin:

$$M_1 = 1{,}400 - 910 - 45 - 25 = 420$$

In this equation $M_1$ is the first order margin in euro and the four numbers are revenue, cost of goods, delivery and payment fees in that order. Dónal's CRM shows that bakeries who order printed trays come back about every eight weeks, spend a similar amount each time, and about 60% are still ordering a year later. Their typical later year margin $M_{\text{repeat}}$ is roughly six orders at €420, which is €2,520. With $r = 0.6$ and a discount rate $d$ of 10%:

$$V_{\text{order}} = 420 + 2{,}520 \times \frac{0.6}{1 + 0.1 - 0.6} = 420 + 2{,}520 \times 1.2 = 3{,}444$$

Each symbol is as above: $V_{\text{order}}$ the uploaded value, $M_1$ the first order margin of €420, $M_{\text{repeat}}$ the later year margin of €2,520, $r$ the retention of 0.6 and $d$ the discount rate of 0.1. The multiplier comes to 1.2, so the value Dónal uploads is €3,444, not €1,400 of revenue and not €420 of first order margin. The arithmetic is from Foundations: lifetime value, and the warning about not extrapolating a retention figure from 30 customers is from Foundations: sampling.

Compare the wedding order: 20 plain boxes, revenue €38, margin €19, never seen again. $V_{\text{order}} = 19$. The optimiser now knows the two orders differ by a factor of 180, not by the factor of 37 that revenue would have suggested.

A lead is worth its probability times its margin

Dónal does not have orders at the moment of the click. He has leads, and a lead is a maybe. The value of a maybe is the chance it comes good multiplied by what it is worth if it does:

$$V_{\text{lead}} = p_{\text{win}} \times M$$

Here $V_{\text{lead}}$ is the value you attach to the lead on the day it arrives, $p_{\text{win}}$ is the probability that this kind of lead becomes a paying customer, and $M$ is the margin you expect once it does, calculated exactly as $V_{\text{order}}$ above. This is expected value, the first idea in Foundations: expected value, applied to one lead instead of one campaign.

Where does $p_{\text{win}}$ come from? Not from a model, at least not at first. It comes from counting. Take every lead from the past year, put each in a bucket by the two or three things you knew about it on day one, and divide the customers in each bucket by the leads in it:

$$p_{\text{win} \mid \text{bucket}} = \frac{\text{leads in the bucket that became customers}}{\text{all leads in the bucket}}$$

In this fraction $p_{\text{win} \mid \text{bucket}}$ is the conditional probability of winning given the bucket, and the two counts come from your own CRM. It is a rate, as in Foundations: ratios and rates, and a conditional probability, as in Foundations: probability. You need enough leads in each bucket to trust the rate. Thirty is a floor, not a comfort, and the article on how much data you actually need has the sums. When a bucket is thin, merge it with its neighbour.

Upload this value on the day the lead arrives, as a provisional figure, and again when the outcome is known, as a restatement against the same order_id.⁷ The provisional value lets Smart Bidding react this week. The restatement keeps it honest next quarter. Waiting until deals close sounds purer, but Dónal's sales cycle is three weeks and the import window on some data sources is 14 days, so by the time the truth arrives the click may be too old to credit.²³ Meta gives the same advice: never hold back an event waiting for a number you cannot compute in real time.¹⁷

Worked example: how Dónal scores the four buckets of leads

Dónal exports 600 leads from the past twelve months. On day one he knew three things about each: whether the email was a business domain or a free one, the quantity requested, and whether the company described itself as a food producer. He makes four buckets and counts.

Free email address, any quantity: 210 leads, 11 became customers. $p_{\text{win}} = 11 / 210 = 0.052$. Average first order margin €60, almost never a repeat. $M = 60$. So $V_{\text{lead}} = 0.052 \times 60 = 3.12$. Call it €3.

Business email, under 500 units: 180 leads, 36 customers. $p_{\text{win}} = 0.20$. Average $M$ including repeat business €120. $V_{\text{lead}} = 0.20 \times 120 = 24$.

Business email, 500 to 5,000 units: 150 leads, 53 customers. $p_{\text{win}} = 0.353$. $M$ of €260. $V_{\text{lead}} = 0.353 \times 260 = 91.8$, call it €92.

Business email, over 5,000 units or a food producer: 60 leads, 27 customers. $p_{\text{win}} = 0.45$. $M$ of €600. $V_{\text{lead}} = 0.45 \times 600 = 270$.

Four buckets, four values: €3, €24, €92, €270. The last bucket has only 60 leads, so its 45% carries a standard error of about six percentage points, and Dónal is grand with that. He writes the four values into a small table in his CRM, the quote form fills them in on arrival, and the nightly job uploads each consenting lead with its provisional value. Target CPA at €50 a lead goes, Maximise conversion value with a target ROAS comes in. Google wants at least 15 conversions in the past 30 days before Target ROAS will run on Search, and suggests judging it on 50 or more, so Dónal's 120 or so consenting leads a month clear the bar, no bother.¹²

Stock and seasonality are multipliers, not new values

Margin and lead quality are facts about the conversion. Stock and seasonality are facts about the moment. I treat them as multipliers on top of the value rather than as new values, because that keeps the uploaded number honest and the adjustment visible:

$$V' = V \times k_{\text{stock}} \times k_{\text{audience}}$$

Here $V'$ is the value Smart Bidding ends up using, $V$ is the margin based value from the sections above, $k_{\text{stock}}$ is a factor that falls towards zero as cover runs out, and $k_{\text{audience}}$ is a conversion value rule multiplier for a group you know to be worth more or less, such as existing customers. A multiplier of 1.2 is a 20% increase and a multiplier of 0.5 is a 50% cut, as in Foundations: percentages. Google's value rules are exactly this: a multiplier on the recorded value by audience, location or device.⁹

For stock the honest version is often binary. When a product has less than a week's cover and the next delivery is three weeks away, a sale of it is worth close to nothing, because it will become a cancellation and a disappointed customer. The cleanest signal is to pause that product group, or set its custom label in the feed so the campaign excludes it. A script can do that hourly off the stock table.¹³ A softer version scales the value down, so a half full warehouse still bids and a nearly empty one bids gently.

Seasonality is the one place I reach for Google's own switch rather than my own data, and only for short, sharp events. The model already knows about Christmas and the bank holidays. Seasonality adjustments are for a sale or a show of one to seven days, not for long stretches, and they are a statement about conversion rate, not value: "for these three days, expect conversion rates 40% higher than normal".¹²

An example: Dónal's stock of white food trays runs low every year in the week before Easter, when every bakery in Munster is making hot cross buns. His script checks cover each morning. Below seven days it pauses the tray product group and sets the uploaded value for any tray order to zero until the delivery lands. For the Cork food trade show in January, where his stand takes orders on the spot, he schedules a three day adjustment of plus 40% on conversion rate and gives the show's registered attendees, uploaded as a Customer Match list, a value rule of 1.2. Nothing else changes.

The loop, once a week, in that order

Everything above is a one way street unless something closes the loop. The loop is the part most setups skip, and it is why the old version of this article was wrong to talk about building a bidding brain. The brain is Google's. What you build is the nervous system that tells it what happened.

The diagram runs from the click at the top to the weekly review at the bottom. Each box is one hand off, owned by a system you control until the upload and by the platform after it. The decision in the middle is the consent check, and the "no" branch is the renaming rule in practice: the lead is counted and nothing else. The bottom box feeds back to the value rule box, which is what makes this a loop rather than a pipeline.

The weekly review is 30 minutes and four questions. Did every won deal get a value uploaded, and every refund a restatement? Is the value uploaded last week divided by last week's spend moving the right way? Has any bucket drifted, with a win rate ten points away from the table? Did anything run out of stock that the script should have caught? Once a quarter I re count the buckets from scratch, because the mix of leads changes as the bidding changes, and a lead score built on last year's mix slowly goes stale.

An example: in week three Aisling notices that food producers asking for under 500 units are winning at 38%, far above the 20% their bucket carries, because small producers test before a big order. Dónal splits the bucket, gives the food producer half a value of €120, and uploads the change on Thursday. Nothing else is touched. Fair play to Aisling, and that is the whole loop doing its job.

Prove the uplift with arithmetic, not a feeling

Before and after is the weakest evidence there is, because something else always changed too. The honest way to test a new value scheme is a Google Ads experiment, which splits the campaign's traffic and budget between the current setup and the trial so both run in the same weeks against the same seasonality.²⁴ Where that is not practical, a before and after with the sums written down still beats a feeling, and the sums are these.

The uplift in the outcome you care about is a percentage change:

$$\text{uplift} = \frac{V_{\text{after}} - V_{\text{before}}}{V_{\text{before}}}$$

In this fraction $V_{\text{after}}$ is the weekly margin from paid leads in the test period, $V_{\text{before}}$ the same in the base period, and the result is the proportional change, as in Foundations: percentages.

Then, because the point of the exercise was never to spend less but to make the next euro work harder, the marginal return:

$$\text{marginal return} = \frac{\Delta \text{margin}}{\Delta \text{spend}}$$

Here $\Delta \text{margin}$ is the change in weekly margin and $\Delta \text{spend}$ the change in weekly spend. When spend is held constant the denominator is zero and the measure is simply the margin per euro in each period. Why margin per euro and not average cost per lead is laid out in Foundations: marginal versus average.

Finally, because a change from ten won deals a week to eleven could easily be noise, the two proportion z test on the win rate:

$$z = \frac{p_1 - p_2}{\sqrt{p(1-p)\left(\frac{1}{n_1} + \frac{1}{n_2}\right)}}$$

Here $p_1$ and $p_2$ are the win rates in the two periods, $n_1$ and $n_2$ the number of leads in each, and $p$ the pooled win rate, all customers won divided by all leads. A $z$ above 1.96 means the difference would arise by chance less than 5% of the time. The test is explained step by step in Foundations: hypothesis tests, and the article on statistical testing, sample size and lift goes further.

Worked example: Shandon Packaging, six weeks before and six weeks after

Dónal holds spend at €2,000 a week throughout. Six weeks of Target CPA at €50, then six weeks of Maximise conversion value with the four bucket values. Here is what the weeks look like.

The horizontal axis is the week, with the switch after week six. The vertical axis carries three series on one scale: leads a week, won deals a week, and weekly margin in hundreds of euro so it fits the same chart. The takeaway is the shape. Leads fall by about a third, won deals barely move, and margin nearly doubles, because the optimiser stopped buying the €3 leads and started paying more for the €270 ones.

The totals. Before: 240 leads, 60 customers, average first order margin €180, so €10,800 of margin over six weeks, €1,800 a week, on €12,000 of spend. After: 168 leads, 66 customers, average first order margin €310, so €20,460 over six weeks, €3,410 a week, on the same €12,000.

The uplift:

$$\text{uplift} = \frac{3{,}410 - 1{,}800}{1{,}800} = \frac{1{,}610}{1{,}800} = 0.894$$

The symbols are as defined above: $V_{\text{after}}$ is €3,410, $V_{\text{before}}$ is €1,800, and the result is an 89% increase in weekly margin from the paid channel. Margin per euro of spend went from $1{,}800 / 2{,}000 = 0.90$ to $3{,}410 / 2{,}000 = 1.71$. The channel that lost €200 a week on first orders now makes €1,410 a week on them before a single repeat order.

Is the win rate change real? Before, 60 of 240 leads: $p_1 = 0.25$. After, 66 of 168: $p_2 = 0.393$. Pooled, 126 of 408: $p = 0.309$.

$$z = \frac{0.393 - 0.25}{\sqrt{0.309 \times 0.691 \times \left(\frac{1}{240} + \frac{1}{168}\right)}} = \frac{0.143}{\sqrt{0.2135 \times 0.01012}} = \frac{0.143}{0.0465} = 3.07$$

Here $p_1$ and $p_2$ are the two win rates, $n_1 = 240$ and $n_2 = 168$ the lead counts, $p$ the pooled rate of 0.309, and $z$ the test statistic. A $z$ of 3.07 is well past 1.96. The chance of a gap this size from noise alone is about two in a thousand. The change in who was coming through the door is real, and the margin per deal, where most of the money is, is not a sampling question at all but a bookkeeping one.

What Dónal does not get to claim is that the change caused the whole 89%. Six weeks of January and February are not six weeks of November and December, and his competitor in Limerick may have cut their budget. That is why his next change to the value scheme will run as a 50/50 experiment, and why I give you the before and after with that caveat attached.

What I would do in your position

If you take one thing from this: stop sending the optimiser a count or a revenue figure and start sending it a margin. Everything else is refinement.

Then, in order. Store the click identifier and the consent state on every lead and order, and keep the refusers' events under a different name so they can never wander into an audience. Count the win rate in four or five buckets from a year of CRM history, in a spreadsheet, before anyone says the word model. Upload a provisional value the day a lead arrives and restate it when the truth is known. Switch to a value strategy once you clear Google's minimum conversion counts. Treat stock and seasonality as multipliers. Review the loop for half an hour a week, re count the buckets every quarter, and test the next change as an experiment.

None of this is the cleverest thing you can do with first party data. Lifetime value models and lookalike audiences have their own articles. It is the thing that pays first, because it changes what the machine is trying to buy. In my experience the gap between an account that uses Smart Bidding and one that feeds Smart Bidding its margins is the largest single improvement available in most accounts, and it costs a nightly job and a weekly half hour.

Footnotes

1. Google, About Smart Bidding, Google Ads Help, 2026, https://support.google.com/google-ads/answer/7065882

2. Google, About Target ROAS bidding, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6268637

3. Google, About Maximise conversion value bidding, Google Ads Help, 2026, https://support.google.com/google-ads/answer/7684216

4. Google, About offline conversion imports, Google Ads Help, 2026, https://support.google.com/google-ads/answer/2998031

5. Google, About enhanced conversions, Google Ads Help, 2026, https://support.google.com/google-ads/answer/9888656

6. Google, Import conversions from clicks with enhanced conversions for leads, Google Ads API documentation, Google for Developers, 2026, https://developers.google.com/google-ads/api/docs/conversions/upload-clicks

7. Google, Adjusting conversions, Google Ads API documentation, Google for Developers, 2026, https://developers.google.com/google-ads/api/docs/conversions/upload-adjustments

8. Google, Data Manager API, Google for Developers, 2026, https://developers.google.com/data-manager/api

9. Google, About conversion value rules, Google Ads Help, 2026, https://support.google.com/google-ads/answer/10518330

10. Google, About Customer Match, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6379332

11. Google, Customer Match, get started, Google Ads API documentation, Google for Developers, 2026, https://developers.google.com/google-ads/api/docs/remarketing/audience-segments/customer-match/get-started

12. Google, About seasonality adjustments, Google Ads Help, 2026, https://support.google.com/google-ads/answer/10369906

13. Google, Google Ads scripts, get started, Google for Developers, 2026, https://developers.google.com/google-ads/scripts/docs/start

14. Meta, Conversions API, Meta for Developers, 2026, https://developers.facebook.com/docs/marketing-api/conversions-api

15. Meta, Integration guidance: value optimisation, Meta for Developers, 2026, https://developers.facebook.com/documentation/ads-commerce/conversions-api/guides/value-optimization

16. Meta, Handling duplicate Pixel and Conversions API events, Meta for Developers, 2026, https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events

17. Meta, Value optimisation for profit: overview, Meta for Developers, 2026, https://developers.facebook.com/documentation/ads-commerce/conversions-api/guides/value-optimization-for-profit/overview

18. Google, EU user consent policy, Google, 2026, https://www.google.com/about/company/user-consent-policy/

19. Google, Customer Match policy, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6299717

20. Government of Ireland, European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, S.I. No. 336 of 2011, Regulation 5, electronic Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

21. Data Protection Commission, Guidance note: cookies and other tracking technologies, DPC, April 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf

22. Google, About conversion values, Google Ads Help, 2026, https://support.google.com/google-ads/answer/3419241

23. Google, Import conversions from ad clicks, Google Ads Help, 2026, https://support.google.com/google-ads/answer/7012522

24. Google, About experiments, Google Ads Help, 2026, https://support.google.com/google-ads/answer/6261395