The Offline-Revenue Loop

The move that justifies the whole apparatus

Every capture decision documented in the preceding chapters exists to enable one outcome: teaching Google's bidding systems what a real booked job is worth, rather than what a form fill appears to be worth. For a business like {COMPANY}, a local pest-control operator across Monterey, Santa Cruz, San Benito, and Santa Clara counties in Central California, the online event and the money are separated in time and space. A homeowner clicks a Google Ads listing, reads a service page, and either calls (831)-area phone or submits a web form. Nothing is transacted online. Days or weeks later, a technician inspects the property, the office quotes a price, and some fraction of those quotes become paid work. Revenue lives in that offline gap. The offline-revenue loop is the set of mechanisms that carries the money back across the gap and stamps it onto the original click, so the ad platform can learn.

This chapter treats that loop as the culmination of the reconstruction. Chapter 7 (Conversion Architecture) established why raw form volume is the wrong optimization target and how a per-service value model assigns provisional worth to a lead at the moment of submission. Chapter 9 (Identity, Attribution, and Value) established how a click is identified and how credit flows to it. This chapter closes the circuit: it takes the identified click, waits for the offline outcome, attaches the realized job value, and sends the pair back to Google. Chapter 12 (Warehousing and Reporting) then consumes the same outcome data for analysis that does not depend on any ad platform at all.

The distinction that organizes the entire chapter is the difference between a lead and a booked job. A lead is a form submission or a call. It has a provisional, internal, estimated value: for {COMPANY} the estimate ranged from 100 for an ant or wasp-bee job to 500 for a fumigation, with 150 as the general default (see Chapter 7 for the full per-service map and the reasoning that GA lead value is never shown to a customer). A booked job has a real value, the dollar figure the office actually quoted and the customer actually agreed to pay. Bidding on the first number optimizes for the appearance of demand. Bidding on the second optimizes for revenue. The offline-revenue loop is how you migrate the optimization target from the first number to the second.

Why booked revenue, and not form fills, trains the bidder

Google's automated bidding strategies, whether Maximize Conversions, Target CPA, or the value-based Maximize Conversion Value and Target ROAS, all learn from the conversions the advertiser reports. If the reported conversion is a form submission, the algorithm learns to buy clicks that produce form submissions. That objective is systematically misaligned with the business in two ways. First, not all form submissions are equal: a fumigation lead and an ant lead both fire the same contact_form_submit event, but one is worth roughly five times the other. Second, and more corrosively, a form submission is not a sale. Some services close at high rates, some at low rates; some traffic segments fill forms and never answer the follow-up call. A bidder trained on form fills will happily spend to acquire tire-kickers because it cannot see that they never became jobs.

Reporting booked revenue changes the signal. When the conversion the advertiser uploads is the closed job with its actual dollar value and its actual close, the bidder learns to buy the clicks that become paid work, weighted by how much that work is worth. The keywords, geographies, times of day, and audiences that produce high-value closed jobs get more budget; the ones that produce cheap leads that never close get less. This is the mechanism, and it is the reason the entire data-capture chain earlier in this dissertation was built the way it was. The click identifiers, the client ID capture, the per-lead database row, the outcome columns: each one exists so that this upload can happen with fidelity.

The click identifier capture: gclid is not enough

The connective tissue of the loop is the click identifier. When a user clicks a Google Ads ad, Google appends a click identifier to the landing-page URL. The advertiser captures that identifier, stores it against the lead, and later uploads it together with the conversion. Google matches the identifier back to the auction, the keyword, and the campaign, and credits the conversion accordingly. Without the identifier, the offline conversion has nothing to attach to.

The historically canonical identifier is gclid, the Google Click Identifier. A gclid-only capture is the default that most tutorials describe, and for {COMPANY} it would have been a quiet, expensive mistake. The reason is the composition of the audience. This is a local, mobile-heavy audience: people searching "termite inspection near me" or "wasp nest removal Salinas" on a phone, frequently inside the Safari and iOS ecosystem, frequently under the privacy constraints that Apple's platform imposes. Under those conditions Google does not always emit a gclid. It emits wbraid or gbraid instead.

The two newer identifiers exist because of privacy-preserving measurement on iOS and in Safari, and because of consent-limited click states. gbraid accompanies clicks that land in an app-to-web or iOS context; wbraid accompanies web-to-web clicks where the user's state prevents the classic gclid from being set. They are aggregate, privacy-safe click identifiers rather than the granular user-level gclid, but for offline conversion import they play the same structural role: they let Google match the conversion back to the campaign. A capture that reads only gclid and ignores wbraid and gbraid silently discards exactly the mobile, Safari, and consent-limited slice of clicks, which for a local pest-control business is the majority of the paid audience. The lost conversions do not error; they simply never match, and the bidder never learns from them. The loss is invisible unless you know to look for it.

The Phase 2 reconstruction therefore widened the capture. The landing-page instrumentation now reads gclid, wbraid, and gbraid from the URL and persists all three onto the lead row. This runs alongside the existing capture of fbclid (the Meta click identifier) and the full UTM set (utm_source, utm_medium, utm_campaign, utm_content, utm_term) that the contact_submissions table already stored. The table also already carried ga_client_id, landing_page, and referrer, so the click-identifier widening slotted into an existing pattern rather than introducing a new one.

lead_id: the internal reconciliation key

The click identifiers belong to Google. The ga_client_id belongs to GA4. Neither is a stable, business-owned primary key for a lead as the business experiences it. The reconstruction added lead_id, a UUID generated once per lead at submission time, as that key. Its job is internal reconciliation. It gives the office, the database, the admin dashboard, and any future upload pipeline a single identifier that names one lead unambiguously, independent of whether that lead ever carried a gclid, answered a call, or matched at Google.

This matters because the identifiers that Google needs are frequently absent. Measured directly from the production database, of 29 leads, 20 carried a ga_client_id and 9 did not, a 69 percent capture rate (the missing 31 percent is ad-block and privacy-browser loss, not timing, since the client-level _ga cookie persists two years once gtag sets it). Click identifiers are absent even more often, because most traffic is not paid at all: over the audited 30 days, google/cpc accounted for 46 sessions against 234 direct, 192 organic, and the rest. A lead_id that is present on 100 percent of leads, generated server-side and never dependent on a cookie or a URL parameter, is the reconciliation backbone that lets the business reason about every lead while the Google-facing identifiers cover only the subset that will ever be uploaded. Chapter 9 develops the identity model in full; the lead_id is its business-owned anchor.

The database outcome model

An identifier without an outcome is useless to the loop. The lead row records who clicked and where they came from; it says nothing about whether the job closed or for how much. The reconstruction extended the schema to record the outcome.

Three columns were added to contact_submissions: stage, job_value, and closed_at. stage is the pipeline position (new, contacted, quoted, won, lost). job_value is the real booked dollar amount, the number that will eventually be uploaded, distinct from the provisional per-service estimate that Chapter 7 attaches at submission time. closed_at is the timestamp of the close, which the upload needs because Google requires a conversion time and because the 90-day match window (discussed below) is measured against it.

The change was made in two coordinated steps, which is the correct discipline for a schema managed by an ORM in front of a live database. The Drizzle schema definition was edited to declare the three new columns, so that application code and type generation see them. Then a psql ALTER TABLE migration added the columns to the production PostgreSQL database directly, so the running system's storage matched the code. Editing only the Drizzle schema would leave production out of sync and break inserts; altering only the production table would leave the application's types and queries unaware of the columns. Both are required, and the order (schema in code, then migration in the database) keeps the deploy safe.

ALTER TABLE contact_submissions
  ADD COLUMN stage text DEFAULT 'new',
  ADD COLUMN job_value integer,
  ADD COLUMN closed_at timestamptz;

The design keeps the outcome model in the same row as the acquisition data. One contact_submissions row now carries the click identifiers, the client ID, the lead_id, the provisional value, and the realized outcome. That colocation is what makes the eventual upload a single-row read rather than a join across systems, and it is what makes the native dashboard in Chapter 12 a straight query.

The admin lead-status editor, and why the Server Action guards itself

Outcome columns are only as good as the process that fills them. Nobody at {COMPANY} is going to write SQL to mark a job won. The reconstruction built an auth-guarded admin lead-status editor: a screen in the existing admin surface where the office sets a lead's stage and enters the booked job_value when a job closes. The write is performed by a Next.js Server Action.

The security decision embedded here deserves emphasis because it is a place where App Router applications routinely leak. The Server Action calls a requireAdmin() helper as its first step, and that helper verifies the signed admin_session cookie before any mutation runs. The reason it must do this itself is that a Server Action is a directly invokable server endpoint. It is not merely a function that a protected page calls; the framework exposes it as a POST target that any client can reach if it knows the action's identifier. Route middleware that guards the /admin page does not automatically guard the action, because the action can be invoked without navigating the protected route. A developer who reasons "the editor lives behind the admin login, so the action is safe" has left an unauthenticated write path open. The correct posture, and the one implemented here, is that every Server Action authenticates itself. Middleware is a convenience for page access; it is not the authorization boundary for mutations. The boundary is requireAdmin() at the top of the action.

The editor was verified end to end by driving it in headless Chrome with the admin session cookie present and confirming that the target database row changed. This is the same verification discipline applied throughout the reconstruction: exercise the real path and observe the real state change, rather than trusting that the code "should" work.

Enhanced Conversions for Leads: recovering the matches gclid misses

The click-identifier path matches a conversion to a click. It fails whenever the click identifier was never captured, which, as the capture-rate numbers show, is a large minority of leads. Enhanced Conversions for Leads is the second matching path, and it works on a different key entirely: the customer's own contact information.

The mechanism is a hashed identity match. When the lead converts offline, the advertiser sends the conversion together with the lead's email address and phone number, normalized and hashed with SHA-256, and Google matches those hashes against the hashed contact information of the signed-in Google user who clicked the ad. Because the match runs on the person rather than on a click token, it recovers conversions that the gclid, wbraid, and gbraid path missed: the click where no identifier survived, the cross-device journey where the identifier did not carry.

Two properties of this path are non-negotiable and both are already satisfied by the data the business holds. First, normalization before hashing: the email must be lowercased and trimmed, the phone must be reduced to E.164 form, before the SHA-256 digest is computed, because Google hashes its side the same way and two different normalizations of the same address produce two different, non-matching hashes. The contact_submissions row already stores the raw email and phone for exactly the lead the office is marking won, so the normalize-then-hash step has clean inputs. Second, consent gating: the identity match is a use of personal data, so it runs only when the user's consent state permits it. The Consent Mode v2 defaults established in Chapter 10 (a global default of granted for the US audience, a region-scoped default of denied for the 32 EEA, UK, and Switzerland region codes) are the gate. Enhanced Conversions inherit that posture: for the US-only local audience the match proceeds; for a European visitor under denied consent it does not.

It is worth stating plainly what the reconstruction did and did not do here. The data foundation for Enhanced Conversions is in place: raw email and phone on every lead, consent defaults configured, and the outcome columns that say which lead is a real conversion. The activation of Enhanced Conversions, like every upload described below, waits on the Google Ads link, which requires GA4 Administrator (now held) and an Ads account connection that is the owner's to grant. The engineering that the business controls is complete; the account linking is the remaining external step.

The upload path: Data Manager API, not the legacy OfflineConversionUpload

There are two ways to get an offline conversion into Google, and one of them is a dead end for this business. The legacy path is the Google Ads API OfflineUserDataJobService / OfflineConversionUpload flow. The current path is the Data Manager API. The reconstruction targets the Data Manager API deliberately, and the reason is a hard date.

On 2026-06-15, Google blocked the legacy Google Ads API offline-conversion upload path for developer tokens that had not previously been allowlisted for it. {COMPANY}'s account is a new integration; its developer token was not on the pre-existing allowlist. Any effort spent building against OfflineConversionUpload would therefore hit an access wall that cannot be waived after the cutoff. This is not a preference or a style choice. It is a foreclosed route. New offline-conversion work for this property, and for any property standing up its integration after mid-2026, must go through the Data Manager API. The adversarial audit's verify pass specifically corrected an earlier, plausible-sounding recommendation to use the legacy path, catching that the 2026-06-15 block made it unbuildable for this account.

The practical consequence is that the automated pipeline, when it is built, will authenticate to the Data Manager API and submit conversions there, carrying the click identifier (gclid, wbraid, or gbraid), the conversion time (closed_at), the conversion value (job_value), and, where consent permits, the hashed email and phone for the Enhanced Conversions match. The contact_submissions row already holds every one of those fields. The upload is a projection of one database row.

MVP first: the Google Sheets upload before the pipeline

The correct sequencing for this loop is not to build the automated Data Manager API pipeline first. It is to prove the loop with the lowest-effort mechanism that produces real learning, then automate once the loop has demonstrated value. For {COMPANY} that MVP is a scheduled Google Sheets upload of won jobs.

Google Ads supports offline conversion import directly from a Google Sheet on a schedule. The office, or a weekly export from the admin editor, populates a sheet with one row per won job: the click identifier, the conversion name, the conversion time, and the value. Google Ads reads the sheet on its schedule and imports the conversions. No API integration, no developer token allowlist question at the MVP stage, no pipeline to maintain. The loop runs end to end, the bidder starts receiving booked-revenue signals, and the business observes whether the match rates and the resulting optimization justify building the automated Data Manager API path.

This ordering follows the maturity logic of Chapter 3. The value of the loop is the learning it produces, and that learning starts flowing the moment the first sheet is imported. Deferring all value until a polished pipeline exists would trade weeks of real signal for engineering elegance that the volume does not yet justify. The sheet is the MVP; the Data Manager API pipeline is the graduation, taken when the sheet's manual burden or its latency becomes the binding constraint.

Match-rate realism

A practitioner who promises a clean one-to-one return of uploaded conversions will be embarrassed by the data. Offline conversion uploads that occur weeks after the click commonly match in the 20 to 50 percent range. That is the normal, expected outcome, not a defect in the implementation. Several mechanisms drive the gap. The click identifier may never have been captured. The user may not have been signed in to Google in a way that supports the Enhanced Conversions identity match. The conversion may fall outside the match window. And privacy states suppress a portion of matches structurally.

The single most important operational constraint is the 90-day gclid window. Google matches an uploaded conversion to a gclid only if the conversion time falls within 90 days of the click. For a pest-control business this is a live risk rather than a theoretical one. A homeowner who clicks in early spring during termite swarm season, schedules an inspection, deliberates on a fumigation quote, and finally books in mid-summer can easily cross the 90-day boundary. When they do, the gclid match is gone, and only the Enhanced Conversions identity path can recover the conversion. This is a second, independent reason the Enhanced Conversions hashed-identity path matters: it is not merely a supplement for missing click identifiers, it is the fallback when a slow-closing job outruns the gclid window. The operational implication for the office is concrete: upload won jobs promptly, weekly rather than quarterly, so that as many conversions as possible land inside the window while their gclid is still matchable.

Setting expectations at 20 to 50 percent up front also protects the loop politically. When the owner sees that half the uploaded jobs did not match, the reaction should be "that is the expected match rate, and the matched half is teaching the bidder," not "the tracking is broken." The chapter states the number so that the number does not later read as failure.

The volume caveat, honestly stated

This loop is being built for a small account, and honesty about scale is part of doing the work correctly. The audited property runs roughly 46 paid clicks per month and roughly 500 sessions per month. Both figures sit below the thresholds at which Google's most sophisticated machinery stabilizes. Data-driven attribution has historically wanted something on the order of 400 conversions per 28 days to model reliably. Value-based Smart Bidding wants roughly 15 to 30 conversions per month before it engages meaningfully. At 46 paid clicks a month, the number of those clicks that become won jobs will sit well under the value-based bidding floor, and the bidder will not fully engage its value optimization.

The honest conclusion is not that the loop is pointless at this scale. It is that the loop earns its place through a different benefit than automated bidding optimization. What the offline-revenue loop delivers immediately, at any volume, is cost-per-booked-job visibility. When won jobs with real values flow back and attach to the campaigns and keywords that produced them, the owner can finally read what each paid dollar returns in actual booked revenue, not in form fills. That visibility is decision-grade on its own: it tells the owner which services and which geographies pay back their ad spend and which do not, and it does so whether or not Smart Bidding ever reaches its stabilization threshold. If and when the account scales, the same loop that provided visibility becomes the training signal that drives value-based bidding, with no rework. Building it now buys the reporting benefit today and pre-positions the optimization benefit for later.

How the loop connects to the rest of the reconstruction

The offline-revenue loop is the point where three earlier threads meet. Chapter 7 supplied the value model: the per-service provisional estimate at submission time, replaced by the real job_value at close, with the reasoning that GA lead value is internal and never customer-facing. Chapter 9 supplied the identity and attribution model: the ga_client_id, the click identifiers, the session_id fix that keeps server conversions from misattributing to (direct)/(none), and the lead_id business key. This chapter takes those inputs, adds the outcome columns and the office workflow that fills them, and routes the result back to Google through the only path still open after 2026-06-15.

Chapter 12 (Warehousing and Reporting) then reads the exact same outcome data for a purpose that needs no ad platform at all. The stage, job_value, and closed_at columns that feed the upload also feed the native /admin/insights dashboard, which renders close rate, booked revenue, pipeline by stage, and leads by service, source, and month directly from the property's own PostgreSQL, with honest empty states until enough jobs are marked won or lost. The same three columns serve two masters: Google's bidder and the owner's own reporting. That dual use is not redundancy. It is the payoff of colocating acquisition and outcome in one row, and it is the reason the offline-revenue loop, once built, keeps earning its cost regardless of how far the paid account scales.

The loop is the highest-value move available to this property because it is the only mechanism that lets the business optimize on money instead of on the shadow of money. Everything upstream, the corrected server endpoint, the click-identifier capture, the client ID and session ID fidelity, the value map, existed in service of this final hop. Closing it converts a pile of correctly captured signals into a system that learns what a booked job is worth and buys more of them.