Measurement · Paid Media · Automation

Bidding algorithms are only as good as the conversion data feeding them.

Most agencies treat tracking as setup work that happens before the real campaign work begins. That is backwards. This practice concentrates on the seam where paid media meets measurement, because for a considered purchase that seam is usually the weakest part of the stack.

laurenmilligan.pro — SERVICES

Seven areas. They are listed in the order they tend to matter, not the order they are usually sold. Each one below is a mechanism, drawn, because a mechanism you can see is a mechanism you can argue with.

How to read the figures

Every chart on this page is a schematic of a mechanism, not a client result. Where numbers appear they are illustrative, chosen to make the shape of the problem legible, and labelled that way on the figure itself. This practice does not publish performance figures it has not measured, and does not quote industry-average recovery rates at prospects. What it will do is measure yours and show you the number.

01 Foundation

Most analytics problems are architecture problems that only show up in a report.

A measurement stack is a chain. It is worth exactly what its weakest link is worth, and the weak link is almost never the reporting tool everyone is looking at.

The measurement chain, source to destination Schematic
The measurement chain, source to destination Visitor surfaces feed a governed data layer and tag container, which resolves consent and taxonomy before routing events through a first-party endpoint to Google Analytics, Google Ads, reporting and the CRM. Each link is a place the chain commonly breaks. Surfaces Data layer and container First-party endpoint Destinations Storefront and checkout Location or partner finder Forms on a subdomain Phone and click-to-call Video and downloads Event taxonomy Naming convention Consent state resolved Custom dimensions Versioned publishing Governed data layer First-party endpoint validate · enrich · dedupe Google Analytics 4 Google Ads Looker Studio CRM and automation
Events start on surfaces nobody owns centrally (a storefront, a locator widget, a form living on a subdomain, a phone link). They pass through a data layer and a tag container, where taxonomy and consent are resolved, then out through a first-party endpoint to the tools that act on them. Break any link and the failure surfaces three steps downstream, in a dashboard, where it looks like a reporting problem.
What gets built
  • Container structure and a naming convention that a person who did not build it can read six months later.
  • An event taxonomy decided once, up front, rather than accreted one tag at a time.
  • Custom dimensions applied at the event level, so segments can be cut later without rebuilding reports.
  • Consent configuration that is correct for compliance and correct for conversion modelling, which are related but not the same job.
  • Versioned publishing with rollback, so a change to the container is a change you can undo.
  • Looker Studio dashboards built against your own sources. No license cost, no reporting platform to keep paying for.
What usually gets found
  • Legacy tags still firing. Properties from a previous agency, a previous platform, or a previous decade.
  • Debug and development artifacts left in production. Nobody put them there on purpose. Nobody removed them either.
  • Duplicate measurement. The same event counted twice through two paths, inflating everything downstream of it.
  • Untagged surfaces. Usually the highest-value one, because it is the one hosted somewhere else.
  • Defaults nobody revisited. Attribution windows, session timeouts, internal traffic filters, and cross-domain settings left as installed.
02 Design work

Decide what counts as a conversion before deciding what to bid on it.

Whenever the sale is assisted rather than instant, whether that means a showroom, a branch, a reseller, a clinic, or simply a sales team on the phone, online purchases alone rarely produce enough volume for Smart Bidding to work. The algorithm does not fail loudly when it is starved. It just quietly makes worse decisions.

Conversion volume by event, against the volume Smart Bidding needs Illustrative values
Monthly conversion volume by event type Seven measurable events ranked by monthly volume. Online purchase, the only event a default setup counts, sits below the volume band where Smart Bidding stabilises. Values are illustrative of a considered-purchase brand. 0 25 50 75 100 conversions per month Smart Bidding stabilises above roughly here Location or partner search 96 Location detail opened 58 Phone number tapped 41 Spec or pricing download 34 Contact form submitted 21 Online purchase 14 Quote request 9
Qualified engagement available to measure What a default setup counts
The same site, measured two ways. Counting online purchases only, this account produces 14 conversions a month and sits below the volume where automated bidding stabilises. Counting qualified engagement as the conversion currency, it produces 273, and the algorithm has something to learn from. Volumes here are illustrative. The point is the relationship between them, which holds for any business where most buyers do something other than check out.
View the values as a table
Monthly conversion volume by event
EventPer monthRole
Location or partner search96Primary
Location detail opened58Primary
Phone number tapped41Primary
Spec or pricing download34Secondary
Contact form submitted21Primary
Online purchase14Primary, and the only one a default setup counts
Quote request9Primary, highest value
Stability floor for automated bidding≈30Working threshold, per campaign, per 30 days
Primary conversions

Optimisation targets. Google Ads bids toward these, so each one has to represent a genuine business outcome. Someone searching for their nearest location is a real commercial event, and it happens far more often than a direct online purchase.

Secondary signals

Measured and reported, used for audience building and diagnostics, deliberately not bid targets. Optimising toward shallow engagement teaches the algorithm to buy cheap, low-quality traffic, which is a failure mode that looks like success for about six weeks.

Targets come after data, not before it. Proposing a cost per acquisition before anything has been measured is a sales tactic, not a strategy. The sequence is thirty days of clean baseline, then a joint target-setting session against known business economics, then quarterly review. See the full method.

03 Highest leverage

Running paid media without it means paying for conversions you cannot see.

Standard tracking runs entirely in the visitor's browser, and that environment has become progressively hostile to measurement. The longer someone takes to decide, the worse it gets, because the gap between the click and the conversion is exactly where the data goes missing.

What actually reaches the ad platform Schematic · magnitudes vary by account
The transit corridor: what actually reaches the ad platform Conversion signal leaves the site and travels along a corridor toward Google Ads. Four gates narrow that corridor in turn: ad and tracker blocking, cookie lifetime cut short, identity broken across contexts, and consent declined or tag failure. Signal riding the bands each gate closes strikes the gate and tumbles out of the corridor; signal on the inner lanes runs the whole route. Of 100 signals sent, 55 arrive. A first-party server route arcs over every gate, and how much wider it opens the mouth is measured per account rather than assumed. The first-party route, server to server no browser in the middle, so no gate to pass 100 89 71 62 55 of 100 arrive −11 Ad and tracker blocking −18 Cookie lifetime cut short −9 Identity broken across contexts −7 Consent declined or tag failure ? ? Signal leaves the site Arrives at Google Ads
Signal still in transit Gate, and the signal it turns away Widened by the first-party route, measured rather than assumed
Every conversion your site earns is a signal that has to travel to the ad platform before it counts for anything. Four gates stand in the corridor, and each one only lets a share through. Watch the outer lanes: signal riding the part of the corridor a gate is about to close runs straight into it and tumbles out. Nothing about that signal was wrong. It was simply travelling in the band that closed. Tags stripped before they fire. Cookie lifetimes cut to days, so a slow decision outlives its own record. Identity broken when someone crosses from one part of your site to another. Consent declined, or a tag that simply failed. What arrives is what Google Ads bids on, so a narrowed corridor does not merely under-report. It quietly reallocates your budget toward whatever happened to survive the trip. The first-party route arcs over every gate because a server-to-server handoff is not subject to any of them. How much wider it opens the mouth is drawn as a question mark on purpose: it is real, it is specific to your account, and we measure it against your own baseline in the first thirty days rather than quoting you an average.
View the values as a table
Corridor width along the route, indexed to 100 signals sent
Point on the routeTurned awayStill in transit
Leaving the site100
Gate 1, ad and tracker blocking−1189
Gate 2, cookie lifetime cut short−1871
Gate 3, identity broken across contexts−962
Gate 4, consent declined or tag failure−755
Arriving at Google Ads55
Widened by the first-party routemeasuredmeasured
What changes
  • More of the conversions you actually earned get reported and credited.
  • Attribution windows extend past what browser cookie lifetimes permit.
  • Smart Bidding optimises on a fuller dataset, so identical budget buys better allocation.
  • The setup is durable. It does not break with each browser privacy update.
  • Offline and CRM outcomes can be fed back in later, which is what section 04 is about.
What it does not fix
  • It is not a consent workaround. A visitor who declines is still not measured, by design.
  • It does not recover data from before it was installed.
  • It does not fix a conversion that was never defined. Section 02 has to come first.
  • It runs on infrastructure this practice pays for. If the subscription ends it is decommissioned, and reported conversions should be expected to fall. The full exit position.
04 Highest ceiling

A lead that goes nowhere and a lead that becomes a customer are worth very different amounts.

Google Ads treats them identically unless it is told otherwise. Offline conversion import sends the outcome back once it is known, so bidding optimises toward the enquiries that turn into revenue rather than toward raw form volume.

Identical to the algorithm, unequal to the business Illustrative proportions
Identical to the algorithm, unequal to the business Sixteen sales inquiries. The upper row shows how Google Ads values them without offline conversion import: all identical. The lower row shows the revenue each one actually produced: two became long-term customers, most produced nothing. Proportions are illustrative. Row 1 · what Google Ads bids toward by default 16 sales inquiries, weighted identically. Bidding learns to buy more submissions. Row 2 · revenue those same inquiries produced Long-term customer Long-term customer Two became long-term customers. Three produced a small order. Eleven produced nothing.
Weight Google Ads applies by default Revenue the enquiry actually produced
Sixteen sales inquiries in a month. To the bidding algorithm they are sixteen identical events, so it learns to buy more of whatever produced them, indiscriminately. To the business, two became long-term customers worth years of revenue, three produced a small order, and eleven produced nothing at all. Until the second row is sent back to Google Ads, every optimisation decision is made against the first row.
View the values as a table
Sixteen enquiries, as counted and as realised (revenue indexed to the largest)
EnquiryCounted by Google AdsRevenue produced
Enquiry 6, became a long-term customer1100
Enquiry 12, became a long-term customer172
Enquiry 3, small order16
Enquiry 8, small order14
Enquiry 15, small order13
The remaining 11 enquiries110
Total16185
Closing the loop Schematic
The offline conversion loop A five-stage loop: an ad click issues a click identifier, the identifier is stored on the lead record, the CRM stage reveals the outcome, a value is assigned to that outcome, and the result is uploaded back to Google Ads so bidding optimises toward outcomes rather than form volume. Bidding optimises toward outcomes not toward form volume 01 Ad click click id issued 02 Lead record click id stored on it 03 CRM stage the outcome becomes known 04 Value assigned a business decision, not a technical one 05 Uploaded back via Google Data Manager
The click identifier is the thread that ties the whole loop together. It is issued at the click, written onto the lead record at submission, carried through the CRM while the outcome is still unknown, and sent back with a value attached once it is known. Matching also works on a hashed email address, which means the loop still closes where identifier capture is imperfect.
The hard part is not technical

The engineering is a solved problem. The real work is agreeing which CRM stage counts as a conversion and what it is worth, which is a business decision with revenue consequences. That is why this is scoped as its own engagement rather than bolted onto a tracking build.

One current detail worth knowing

Google moved these uploads onto its Data Manager platform in June 2026, and the previous API path is closed. Much of the guidance still published online describes the older method, which no longer works. Any implementation has to target the current platform.

06 Operations

Changes you can read, review, and reverse.

Ongoing optimisation is where most accounts quietly become un-auditable. Someone changes something, performance moves, and nobody can reconstruct which of the eleven changes that week was responsible. The fix is process, and it is not complicated.

How a change reaches a live account Schematic
The plan and apply cycle Six stages run left to right: declare the spec, pull the live baseline, diff into an ordered operation list, dry-run it against the API, apply, and journal every operation with its inverse. A human approval gate sits between dry run and apply. The journal feeds the next baseline. 01 Spec the target state 02 Baseline live state, pulled 03 Diff ordered operations 04 Dry run validate only 05 Apply partial failure on 06 Journal plus its inverse Human approval The journal becomes the next baseline. Every change has a recorded way back.
The account is declared as a specification, the live state is pulled, and the difference between them becomes an ordered list of operations. That list is dry-run against the API before anything touches the account, presented as a readable changeset, and only then approved. Every applied operation is journaled alongside the operation that would undo it. Google's own change history is a thirty-day window, which is not long enough to answer questions that come up in a quarterly review.

The practical consequence. "What changed in the account last month, why, who approved it, and what would it take to put it back" is a question with a written answer, not a question that starts an archaeology project.

The same discipline, applied to search

Answer engines do not rank pages. They cite a handful of sources.

Which makes the optimisation target position-independent. It is not "be number three", it is "be the thing that gets quoted". Three mechanisms decide that, and they are not equally powerful.

What decides whether an answer engine cites you Ordinal · width is rank, not a measurement
The three mechanisms that decide citation, in descending leverage Answer engines cite rather than rank. Three mechanisms decide citation: entity clarity first and highest leverage, then extractable structure, then corroboration, which is slowest to move and most durable. Rung width shows relative leverage, not a measured quantity. Descending order of leverage. Width is ordinal, not measured. 1 Entity clarity The engine knows what the business is, and finds the same answer everywhere it looks. Fastest to fix 2 Extractable structure The claim is stated before the elaboration, so a passage can be quoted intact. Weeks 3 Corroboration The claim also appears in sources the engine already trusts. Slowest, most durable
Entity clarity comes first because it is both the highest leverage and the cheapest to fix. If the engine cannot resolve unambiguously what the business is, and find the same answer everywhere it looks, it has no reason to cite it confidently. Structure comes second: answers are assembled from passages, and a passage that buries its claim in paragraph four does not get quoted. Corroboration is slowest and most durable, and it shades into digital PR, which is a different service with a different cost base.
What can be promised
  • What the engines say about you today, verbatim, with the date and the prompt that produced it.
  • What was changed, and when.
  • Whether citation changed after the change, with the sample window stated on every figure.
  • Tracking on a fixed query set, so the result is a trend rather than an anecdote.
What cannot
  • That a ranking or citation position is achievable.
  • That any specific engine will cite you.
  • A percentage improvement, quoted before your own data exists.
  • Anyone who does promise those things is describing a mechanism that does not work the way they are saying it does.
07 Emerging, and load-bearing

The question is not what the API allows. It is what an agent should be trusted to do unattended.

Agents genuinely do useful work against a marketing stack. They also have a live credit card attached to the account, which is a category of mistake most software cannot make. So the interesting design work is authority, not capability.

Agent authority, by blast radius Design pattern
Agent authority by blast radius Four tiers of agent authority. Tier 0 reads and Tier 1 reversible optimisations run unattended and are journaled. Tier 2 structural changes are proposed and require human approval. Tier 3 covers billing, access and destructive actions, which the tool refuses outright. Blast radius increases downward. Authority decreases. Tier 0 Read Reports, search terms, change history, account structure. Agent acts. No confirmation. Tier 1 Reversible Negatives added, a keyword paused, a bid nudged inside a fixed band, an asset added. Agent acts. Journaled with its inverse. Tier 2 Structural Budgets, bidding strategies, targeting, new campaigns, conversion actions. Agent proposes. A human approves. Tier 3 Off limits Billing, payment methods, user access, deleting a conversion action, removing a serving campaign. The tool refuses. Not a prompt rule, a code path.
Agent acts unattended Agent proposes, a human approves Refused by the tool
Reads and reversible optimisations run unattended, because every one of them has a recorded way back. Anything that creates spend, changes a bidding strategy, or alters targeting is proposed and waits. Billing, user access, and destructive actions are not gated, they are absent. The tool has no code path to them, which is a stronger guarantee than an instruction not to use one.
Guardrails are code, not prompt text
  • Account allowlist. Anything not explicitly listed is refused before a request is even built.
  • Writes fail closed. The write path is off by default and has to be deliberately enabled.
  • Mandatory dry run. Every mutation validates first. Any validation error and nothing is applied.
  • Budget ceiling and delta cap. No single change can raise spend beyond a configured percentage, regardless of who asked for it.
  • Operation ceiling. Large changesets have to be split and re-approved rather than applied in one swing.
  • Provenance labels. Everything the agent creates is tagged with the run that created it, so it is findable and reversible in bulk.
  • Append-only journal. Every mutation recorded with its inverse operation.
Where this actually pays
  • Reporting and monitoring. The work that is genuinely repetitive, genuinely high-volume, and genuinely low-risk.
  • Search term and negative keyword hygiene. Continuous rather than monthly, which is the whole difference.
  • Anomaly detection. Noticing on the day, rather than in the monthly review.
  • Workflow automation across your own tools, configured against your data rather than a generic template.
  • Coaching your team, including the unfashionable half of the advice: where AI genuinely belongs in a marketing organisation, and where it does not.

The honest version. Most of what is sold as marketing AI right now is a wrapper with no audit trail and no way back. The value is not in letting an agent do more. It is in defining precisely what it may do, recording everything it did, and being able to undo any of it. That is unglamorous, and it is the part that makes the rest safe to use.

Build it, hand it over, stay reachable.

Engagements are shaped in three parts. Not every client needs all three, and the third one is designed so that it does not quietly become a permanent dependency.

1. A fast campaign, if there is a date to hold

A tightly scoped launch that gets brand, product, and competitor search live in days rather than weeks, with baseline conversion tracking pulled forward so the first traffic is measured rather than merely spent. Fixed fee, milestone billed.

2. The build

The real engagement. Account architecture, measurement infrastructure, dashboards, recorded training, and a written runbook. Fixed fee, three milestones: kickoff, infrastructure complete, training accepted. Deliverables are inspectable and inheritable. Nothing is built that only this practice can operate.

3. The subscription

After launch, a monthly base tier that holds the measurement infrastructure, keeps the dashboards current, runs a quarterly strategy workshop with a written plan, and keeps advisory access open. Campaign management is an add-on you choose, not a floor set for you.

The distinction matters. A build priced as counsel and a build priced as management look similar on paper and behave very differently after month three. If your team wants to run daily operations, the model should let them, and the price should reflect it.

Senior strategy, never delegated

Strategy is designed, approved, and directed by Lauren Milligan. That does not change partway through an engagement. Day-to-day execution may be supported by vetted subcontractors working under that direction, which holds delivery timelines during build phases without handing you to a junior team. laurenmilligan.pro remains fully liable for all work completed by any subcontractor, stated explicitly in the service agreement. Your contractual relationship is with this practice alone.

The handoff is the point.

A build you cannot inherit is not a deliverable, it is a subscription with extra steps. Everything below is yours from the day it is created, in your own accounts, and none of it is held back as leverage if the relationship ends.

Ownership at handoff
AssetWhere it livesYours
Campaigns, ad copy, keyword lists, audiencesYour Google Ads account, your billingPermanent
GA4 property and reporting configurationYour Google Analytics accountPermanent
Google Tag Manager containerYour GTM accountPermanent
Looker Studio dashboardsYour Google account, no license feePermanent
Strategy documentation and written runbookDelivered as filesPermanent
Recorded training sessionsDelivered as filesPermanent
Server-side tracking container and endpointOur infrastructure, our costWhile subscribed

The last row is the honest one, and it is stated here rather than discovered later. The server-side layer runs on infrastructure this practice pays for as part of the subscription. If the subscription ends, it is decommissioned and measurement reverts to standard browser-based tracking, which is what most accounts run on. Campaigns keep running. Nothing is switched off and nothing is deleted from your accounts. Reported conversions should be expected to fall, and that difference is precisely what the subscription pays for. The full exit position is here.

Boring, predictable billing.

A subscription model only works if the mechanics are dull. These are the mechanics.

  • One subscription, one invoice, one charge. The base tier and every active add-on bill together. You are not reconciling six line items from six agreements.
  • Charged on the 1st, in advance. A card or bank account on file, charged automatically. Nothing to route, approve, and pay each month, and therefore nothing to go past due.
  • Add or drop any add-on by the 25th, effective the following 1st. Mid-month additions are prorated to the portion actually used. Removals take effect at the period boundary.
  • Base subscription cancellable with 30 days written notice. No annual lock, no early termination fee.
  • Receipts and payment details are self-serve. Every invoice is available on demand and card details can be updated without going through us.
  • Build phases are separate. Invoiced at milestone, or converted to equal monthly payments over three or six months at the same total, with no financing charge. Ending one does not affect the other.
  • No hourly billing. Project work is quoted as a fixed amount before it starts. No open-ended engagements where the number is only known afterward.

Media spend is paid directly to the ad platform on your own card. It does not pass through this practice, which keeps the invoice clean and keeps the account in your name.

Fixed-fee builds Milestone billing Net 15 Monthly subscription, charged on the 1st 30 days notice No hourly rate

Start with the homework, not the pitch.

Most proposals are written without having looked. A preliminary technical review of your site, its tag configuration, and its conversion paths comes before any recommendation, and it is not billed.

Request a technical review