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 Dealer locator 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.

For brands that route buyers to dealers, distributors, or a sales conversation, ecommerce 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 dealer-network brand. 0 25 50 75 100 conversions per month Smart Bidding stabilises above roughly here Dealer locator search 96 Dealer detail opened 58 Phone number tapped 41 Technical download 34 Contact form submitted 21 Online purchase 14 Trade inquiry 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 of a dealer-network brand. The point is the relationship between them, which holds across accounts of this shape.
View the values as a table
Monthly conversion volume by event
EventPer monthRole
Dealer locator search96Primary
Dealer detail opened58Primary
Phone number tapped41Primary
Technical download34Secondary
Contact form submitted21Primary
Online purchase14Primary, and the only one a default setup counts
Trade inquiry9Primary, 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. A dealer locator search is a real commercial event for a brand that sells through dealers, 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. Brands with long consideration cycles are hit hardest, because the gap between the click and the conversion is exactly where the data gets lost.

Where browser-measured conversions go Schematic · magnitudes vary by account
Where browser-measured conversions are lost A waterfall from conversions earned down to conversions reported by browser-only tracking, through four named loss mechanisms. The final bar, the share recovered by a first-party server endpoint, is drawn open because it is measured per account rather than assumed. 0 25 50 75 100 100 Conversions the account earned −11 Tag blocked at the source −18 Cookie lifetime truncated −9 Identity broken across contexts −7 Consent or tag failure 55 Reported by browser-only tags ? measured Recovered by the first-party endpoint %
Conversion count Loss mechanism Recovered, and measured rather than assumed
Four separate mechanisms take a bite, and they compound. Tags stripped before they fire, cookie lifetimes cut to days, identity broken when a visitor crosses from the storefront to a form on another subdomain, and consent or tag failures. What reaches Google Ads is what it bids on, so an incomplete picture does not just under-report. It reallocates budget toward whatever happened to survive the trip. The last bar is drawn open on purpose: the recovery is real, its size is specific to your account, and we benchmark it against your current baseline in the first thirty days rather than quoting you an average.
View the values as a table
Attrition from earned to reported, indexed to 100 conversions earned
StageChangeRunning total
Conversions the account earned100
Tag blocked at the source−1189
Cookie lifetime truncated by the browser−1871
Identity broken across contexts−962
Consent or tag failure−755
Reported by browser-only tags55
Recovered by a first-party endpointmeasuredmeasured
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 conversions 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 applications that turn into real relationships 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 trade 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 dealer relationships, the rest produced nothing. Proportions are illustrative. Row 1 · what Google Ads bids toward by default 16 trade inquiries, weighted identically. Bidding learns to buy more submissions. Row 2 · revenue those same inquiries produced Signed dealer Signed dealer Two produced a dealer relationship. Thirteen produced nothing. One produced a small order.
Weight Google Ads applies by default Revenue the inquiry actually produced
Sixteen trade 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 of them became dealer relationships worth years of revenue and thirteen 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 inquiries, as counted and as realised (revenue indexed to the largest)
InquiryCounted by Google AdsRevenue produced
Inquiry 6, became a dealer1100
Inquiry 12, became a dealer172
Inquiry 3, small order16
Inquiry 8, small order14
Inquiry 15, small order13
The remaining 11 inquiries110
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