Google Ads Location Targeting for Clinics: Presence vs Presence or Interest

cmsapointoo on August 16, 2026

Presence and Presence or Interest answer different questions in Google Ads. Presence focuses on people likely to be in or regularly in a targeted area. Presence or Interest also includes people who have shown interest in that area. For a clinic, the right setting depends on where it can actually serve patients.

Neither option proves a person’s precise location. Google describes location targeting as a best-effort system based on several signals and says complete accuracy is not guaranteed. Choose a setting from the clinic’s service boundary, then audit matched locations and qualified booking outcomes instead of judging the decision by reach alone.

What is the difference between the two options?

Google’s advanced location documentation describes Presence or Interest as the default and recommended broad targeting option. It can reach people likely in or regularly in the selected locations and people who have shown interest in those locations. Presence removes the interest branch and retains the likely-in or regularly-in branch.

Option Who may be reached Clinic decision question
Presence or Interest People likely in, regularly in, or interested in the targeted area Can the clinic serve valuable demand from people who are not currently local?
Presence People likely in or regularly in the targeted area Does the clinic want to limit reach to likely local presence?

The wording matters. Presence does not mean confirmed residence, and Presence or Interest does not mean the user intends to travel. Both are platform classifications. The clinic still needs an operational definition of its service area and a separate way to measure whether enquiries become eligible bookings.

When does Presence fit a clinic’s service boundary?

Google says advertisers should consider Presence when they only want users in specific locations, or when the business is in a sensitive vertical with strict targeting limits. A clinic with a fixed in-person service area may therefore prefer the narrower option after checking the actual campaign and current policy.

This is not a universal prescription. A regional specialist, a clinic serving travellers, or an organization offering permitted remote services may have a reason to evaluate location interest. Write the service scenario first rather than copying a setting from another account.

Document every included location, excluded location, radius, and location option. Record why a person outside the immediate area can or cannot become an eligible patient. If the answer depends on the service, campaign, or location, separate those campaigns instead of relying on one broad rule.

When can Presence or Interest be useful?

Presence or Interest can reach someone outside the target area whose searches, past activity, visited locations, or viewed content indicate an interest in that place. Google notes that location of interest is not limited by the user’s country or the Google domain used for the search.

That broader reach is useful only when out-of-area interest has a credible path to service. For example, someone may plan care before moving to a new city or arrange an appointment for a future visit. Test those scenarios against the clinic’s booking process rather than inferring them from a search term.

Do not reuse Google’s conversion example for travel, real estate, and education as a clinic benchmark. The advanced-options page limits that result to named verticals and dates. It does not establish that broader targeting improves qualified patient acquisition for healthcare advertisers.

Why is neither option exact location proof?

Google uses signals such as IP addresses, device information, user settings, behavior, search terms, past locations, Maps activity, and page context to estimate physical location or location interest. Signal availability varies. The platform says location targeting is its best effort and does not guarantee full accuracy.

Google also documents related areas. Ads may show in nearby places that could not be targeted directly because of population, available data, or targeting granularity. A radius or city target is therefore a campaign setting, not a geometric proof of where every click occurred.

Do not classify a click associated with another place as invalid traffic automatically. It may reflect the selected Presence or Interest option, an estimated location, a related area, or a reporting limitation. Inspect the campaign and evidence before assigning a cause.

Which geographic reports should the clinic review?

Google’s geographic performance guide separates Targeted locations from Matched locations. Targeted locations shows performance for the areas configured in the campaign. Matched locations shows where ads appeared based on either a user’s physical location or a location of interest.

Start with the Matched locations view when investigating reach beyond the expected service area. Then compare it with the exact advanced location option, exclusions, campaign type, and date range. The report is aggregated, and Google notes that some rows can remain unspecified.

Distance reports add another perspective when location assets are present. Google warns that the displayed distance can be based on a place of interest rather than precise physical distance. Treat distance as a reporting dimension, not a patient-address field or evidence about an individual.

How should location data connect to clinic outcomes?

Google’s reports describe ad delivery and platform conversions. The clinic must define an eligible enquiry or booking in its own system. Join those layers only through an approved, minimized reporting process, then aggregate by a useful geographic level before sharing results.

A practical internal review separates:

  • targeted location and selected location option;
  • matched location category reported by Google;
  • valid form submissions or calls under a written rule;
  • eligible bookings recorded by the clinic’s source of truth;
  • cost and outcome rate for a mature period.

The clinic booking outcome taxonomy keeps form, booking, attendance, and later outcomes distinct. The guide to show rate by campaign explains how to use aggregate outcomes without turning appointment details into advertising payloads.

How should a clinic test a change?

Change one location option at a time and preserve the prior setting. Record the affected campaigns, locations, exclusions, date, approver, reason, and rollback condition. Avoid changing keywords, landing pages, bidding, and geographic settings together because the result will be hard to interpret.

  1. Write the service boundary and acceptable out-of-area scenarios.
  2. Capture the current targeted locations, exclusions, and advanced option.
  3. Review Matched locations for a mature period.
  4. Compare valid enquiries and qualified bookings under clinic-owned definitions.
  5. Choose Presence or Presence or Interest for the documented scenario.
  6. Monitor reach, cost, and outcome quality over the same reporting window.
  7. Revert if the agreed stop condition is met.

Do not promise that Presence will remove every out-of-area interaction. Google explicitly describes the system as best effort. The test should ask whether the narrower setting improves the clinic’s observed mix within acceptable reach, not whether every user appears inside a perfect boundary.

What should the decision record say?

The record should state the clinic’s service constraint before the chosen setting. It should also name what counts as a qualified booking, which report supplies location data, how unspecified rows are handled, and when the team will review the decision again.

Decision field Required entry
Service boundary Where and how the clinic can provide the advertised service
Google option Presence or Presence or Interest
Campaign scope Exact campaigns, locations, exclusions, and devices
Evidence Matched locations plus clinic-owned qualified outcomes
Review rule Date, owner, rollback threshold, and known limitations

Keep location targeting separate from acquisition attribution. The appointment source versus marketing source guide shows why the scheduler entry point and the campaign that influenced demand need different fields. Location is another dimension, not a replacement for either one.

Frequently asked questions

Is Presence always better for a local clinic?

No. It is narrower and may fit a fixed local service boundary, but Google recommends assessing the advertiser’s goals. A clinic that can legitimately serve some out-of-area demand may test the broader option with qualified booking evidence.

Does Presence guarantee every user is physically inside the target?

No. Google estimates location from several signals and calls its targeting best effort. It does not guarantee complete accuracy. Related areas and unspecified report rows also require review.

Does an out-of-area click prove invalid traffic?

No. Check the advanced location option, matched-location type, exclusions, related areas, and available signals first. Invalid traffic is a separate classification and needs its own evidence.

Should a clinic judge the setting by conversion count?

Not alone. Compare reach and cost with valid enquiries and eligible bookings under written clinic definitions. A larger platform conversion count may still include demand the clinic cannot serve.

References

Google Ads New Customer Acquisition Goal vs a Clinic’s New-Patient Definition

cmsapointoo on August 16, 2026

Google Ads can label someone a new customer without proving that the person is a new patient under a clinic’s operating rules. The platform label belongs to a bidding system. The clinic definition belongs to its appointment or patient system. They can inform the same review, but they are not interchangeable.

Before activating a customer lifecycle goal, review the acquisition mode, detection method, and campaign requirements. Google also restricts advertiser-curated audiences when ads promote content within a sensitive health category. A clinic should test eligibility first and keep its patient definition in the approved operational system.

What are the two definitions?

Google Ads uses customer lifecycle goals to change how campaigns bid toward new, high-value, existing, or lapsed customers. Its documentation describes the platform modes, eligible campaign types, bidding strategies, and signals used to detect customer segments. The resulting label answers a Google Ads optimization question.

A clinic’s new-patient definition answers an operational question. The clinic might need to distinguish a first recorded appointment, a first completed visit, a returning person after a chosen interval, or an existing patient visiting another location. Those are examples of definitions a clinic may choose, not definitions published by Google.

Write the clinic rule before comparing the two systems. Name the qualifying event, lookback period, source of truth, exclusions, effective date, and owner. The clinic booking outcome taxonomy shows why a form submission, booking, and attended visit require separate names.

How does Google Ads identify a new customer?

Google documents three broad signal paths for customer detection: Google autodetection, designated audience lists, and supported conversion-tag information. The exact path depends on the lifecycle mode and conversion setup. A user classified as new by one of those paths has met the platform’s detection logic, not the clinic’s patient-record rule.

Autodetection is activated for new customer acquisition when the advertiser tracks Google Ads purchase conversions. Google says it can build from up to 540 days of campaign activity and tracked purchases. The same documentation calls this method less comprehensive because users can delete cookies or opt out.

Audience lists can help Google identify existing customers, but access and policy eligibility are separate gates. A visible list control does not prove that a clinic may populate it with patient information. Even accurate platform detection would not establish clinical or billing status.

Why does the selected lifecycle mode matter?

The phrase “new customer acquisition goal” covers modes with different requirements. Google’s current lifecycle overview says New Customer Value mode and High-Value New Customer mode require at least one purchase conversion goal and use value-based bidding. New Customer Only mode can work without a purchase goal, although Google recommends one for more accurate new-versus-returning reporting.

New Customer Value mode bids higher for new customers while continuing to engage potential returning customers. New Customer Only mode bids only for customers the platform treats as new. A team must record which mode it means. Saying only “new customer goal is enabled” is too vague for review.

For a broader readiness check, use the clinic value-based bidding checklist. It separates business purpose, conversion goal, value quality, delay, and observation window rather than treating a switch in Google Ads as evidence that the underlying data is ready.

Where should the clinic define a new patient?

The clinic should define new-patient status in the system that owns the relevant appointment or patient history. That rule can then support internal acquisition reporting. It should not be rewritten around what Google happens to detect, because cookie loss, opt-out, list coverage, and conversion configuration can all change the platform result.

Use a small decision record with the following fields:

  • the event that qualifies a person, such as created booking or completed first visit;
  • the lookback period and whether it applies across locations;
  • the source system and stable internal identifier;
  • test, duplicate, cancelled, and migrated-record rules;
  • the owner, effective date, and change history.

This is an editorial governance model. Google does not prescribe a clinic’s patient definition. The guide to appointment source versus marketing source provides a related boundary: operational scheduling facts and advertising context answer different questions and should stay in separate fields.

What changes when the advertising falls into a sensitive health category?

Google’s health policy classifies personal health content as a sensitive interest category. Its examples include health conditions, treatments, invasive procedures, medical devices, pregnancy, infertility, and mental-health services. Whether a specific ad, site, or app falls within the policy requires review of the actual content.

When that sensitive-interest restriction applies, Google’s current policy says advertiser-curated audiences are not supported. The listed unsupported features include Customer Match, advertiser data segments, audience expansion, and lookalike segments. Predefined Google audiences and location targeting appear on the supported side of the policy table, subject to their own rules.

Do not respond by uploading a patient list under a broader label, hashing it, or turning an appointment outcome into an audience. This article does not recommend any health-data upload. If the chosen lifecycle mode depends on a customer signal that the policy does not support for the advertised content, stop the implementation and keep the new-patient analysis internal.

The enhanced-conversions audit proof guide applies the same evidence discipline to another Google feature: configuration, request processing, Ads reporting, and business outcomes remain separate proof layers.

How should a clinic decide whether to activate the goal?

Start with the advertised content, proposed campaign, lifecycle mode, conversion goal, and signal path. Do not start with a patient export. The team should be able to describe the full configuration without exposing names, contact details, appointment information, or medical context.

  1. Define the clinic’s new-patient rule in the operational system.
  2. Identify the exact Google lifecycle mode and eligible campaign type.
  3. List the conversion goal and detection signals the mode would use.
  4. Review whether the ads, site, or app fall within Google’s sensitive health category.
  5. Confirm each required signal is permitted under the current policy.
  6. Stop if activation would require an unsupported audience or patient-data upload.
  7. Document the approval, scope, owner, rollback step, and review date.

New Customer Only creates a specific conflict. Google’s configuration guide says advertisers using offline events need to upload existing customers through Customer Match because autodetection does not work with offline conversions. That instruction does not override the health-policy restriction. For sensitive health advertising, stop rather than upload the list anyway.

How should reporting keep the labels separate?

Use two columns with two sources. One column records the Google Ads lifecycle classification reported for the campaign. Another records whether the clinic’s written new-patient rule was satisfied in its approved system. Never fill the second column by copying the first.

Field Source What it proves What it does not prove
Google new-customer classification Google Ads Platform classification under the selected mode and available signals First appointment or completed visit
Clinic new-patient status Approved clinic system The clinic’s documented operational rule was met How Google classified the user
Original marketing source Approved attribution record Recorded acquisition context Patient status or appointment outcome

Compare counts only after stating each denominator, date basis, and maturity window. A difference is not automatically a tracking defect. It may follow from different definitions or incomplete platform signals. Investigate the rows without exporting the patient record to the advertising platform.

Which mistakes create the most risk?

Renaming a Google segment “new patients” overstates what the platform proves. Building an existing-customer list from patient data before checking sensitive-interest restrictions creates a separate policy risk.

New Customer Value and New Customer Only do not work the same way. Their conversion-goal requirements differ. Changing the clinic definition until it matches the Google count also destroys a stable operational metric and hides the disagreement that needs investigation.

Keep every decision reversible. Record screenshots without patient data, the source pages reviewed, the campaign and goal identifiers, and the reason for approval or rejection. Review the setup again when Google changes lifecycle features, the clinic changes its definition, or campaign content enters a different policy category.

Frequently asked questions

Does Google Ads know whether someone is a first-time patient?

Not from the new-customer label alone. Google classifies customers through the selected lifecycle mode and available platform signals. First-time patient status requires the clinic’s own documented rule and approved operational record.

Can a clinic upload its patient list to improve new-customer detection?

This article does not recommend that upload. When ads promote content within Google’s sensitive health category, Customer Match and other advertiser-curated audiences are unsupported. Review the actual content and current policy before any implementation.

Can New Customer Only mode use a non-purchase conversion?

Google’s current lifecycle documentation says a purchase goal is not required for New Customer Only mode, although it is recommended for reporting accuracy. Signal and policy eligibility still require separate review.

What should the clinic report if the two counts differ?

Report both counts with their definitions, sources, and date bases. Do not force them to match. Investigate configuration and coverage while keeping patient status in the clinic’s approved system.

References

A Value-Based Bidding Readiness Checklist for Clinics

cmsapointoo on August 16, 2026

A clinic is ready for value-based bidding only when its values, conversion goal, reporting flow, and observation window tell one consistent story. A large conversion count cannot repair identical values, mixed funnel stages, delayed uploads, or a campaign optimizing toward the wrong action. Readiness is a checklist, not one universal threshold.

Google’s current Search and Shopping guidance recommends at least 15 conversions in the last 30 days at conversion-tracking level for Target ROAS. That is a scoped platform recommendation, not a rule that every clinic must meet before using any value strategy. This checklist keeps volume in its proper place beside value variation, goal configuration, delay, maturity, and data quality.

What does ready mean for a clinic?

Ready means the proposed bidding signal is allowed, measurable, stable enough to interpret, and connected to the campaign that will use it. It does not mean every data point is perfect. It does mean the team can explain where each value came from, which action receives it, how late it arrives, and what Google Ads will optimize.

This assessment starts after a separate policy review clears the proposed conversion and value for Google Ads. It does not authorize treatment acceptance, appointment details, or other health-related outcomes as advertising events. The internal treatment-acceptance value model shows how sensitive clinic economics can stay in first-party reporting without becoming a Google payload.

Gate Ready evidence Stop condition
Business objective Value matters more than raw conversion volume Team only wants more conversions
Value variation Two or more defensible values Every event has the same arbitrary number
Funnel stage One selected stage for bid optimization Several stages compete for the same campaign
Goal and actions Campaign goal and primary actions agree Primary label does not match campaign goal
Data flow Regular, reconciled uploads Missing, duplicated, or sporadic batches
Maturity Delay and observation window documented Recent cohorts are treated as complete

Does the business need value-based bidding?

Google distinguishes value-based bidding from conversion-based bidding. Maximize conversion value and Target ROAS optimize toward reported value. Maximize conversions and Target CPA optimize toward conversion volume. A clinic should choose value only when two eligible conversions or outcomes can be worth meaningfully different amounts under a documented business objective.

If the practical goal is simply to generate more submissions under a budget, conversion-based bidding may fit better. Assigning decorative values to an otherwise identical lead does not create useful variation. It changes the unit that the bidder sees without adding business information.

Are the reported values meaningfully different?

Google says value-based bidding requires two or more different values for the conversion goals. Those can be real economic values, such as revenue, or proxy values, such as a lead score. The source supports variation. It does not validate a clinic’s formula or declare a particular proxy accurate.

A defensible model has a named owner, formula, input sources, currency or scale, effective date, and correction rule. The same operational event should receive the same value under the same version. If values change because a spreadsheet owner made an undocumented judgment, the bidder receives noise rather than a stable business preference.

Do not confuse a conversion value with collected revenue. The break-even cost per booked consultation uses explicit assumptions for planning. That internal estimate is not automatically a conversion value that can or should be uploaded. Eligibility and measurement design still need their own review.

Which funnel stage should bidding use?

Google recommends selecting a single stage in the lead-to-sale journey for bid optimization. A later stage may be more accurate but arrive slowly. An earlier stage, such as a qualified lead, may provide faster feedback but can be less closely tied to final economics. The clinic has to choose that trade-off deliberately.

“Single stage” does not mean the Google Ads account may contain only one conversion action. The account may track several actions for observation or other campaigns. It means this campaign should have one coherent optimization stage instead of bidding simultaneously toward form submission, booking, attendance, and a later result as if they were interchangeable.

Document the stage definition outside the interface. State its entry condition, exclusions, source system, counting rule, value rule, and normal reporting delay. The clinic funnel report by original cohort helps prevent later outcomes from moving into the wrong acquisition period.

Do campaign goals and primary actions match that stage?

Google organizes conversion actions inside conversion goals. A primary action can be used for bidding and appears in the Conversions columns when the campaign optimizes toward the goal that contains it. A primary label alone is insufficient. The campaign must also use the associated goal.

Secondary actions normally remain observational in All conversions. Google documents an important exception: a secondary action included in a custom goal is used for bidding when that custom goal is assigned to the campaign. An audit must inspect the actual campaign goal, not infer behavior from the Primary or Secondary label alone.

List every action inside the selected goal and identify its source. Remove accidental competition between duplicated web, import, and analytics actions before changing bidding. The guide to conversion-action ownership in client and manager accounts explains why the action should normally live with the clinic that owns the first-party outcome.

Is the value feed accurate and regular?

Google recommends sending conversion data as soon as it is available and says daily offline uploads are optimal. Regular inflow gives the bidder information over time. Large, occasional batches and delayed backfills change both volume and value patterns, which makes the period harder to interpret.

Check completeness before strategy selection. Reconcile source records with accepted imports, verify action names, timestamps, currencies, values, and identifiers, and separate duplicates from corrections. A technically accepted upload is not proof that the source cohort was complete or that the value formula was applied consistently.

How do delay and maturity affect readiness?

Conversion delay is the time between the ad click and the conversion reported to Google. Google recommends shorter delays, under seven days, for value-based bidding, while acknowledging that longer average delays can work when some data arrives earlier. If no data arrives for seven days, or all conversions take at least seven days, initial ramp-up may take months.

Delay is not the same as cohort maturity. Delay describes when the signal reaches Google. Maturity describes whether enough time has passed for the clinic’s chosen outcome and value to settle. A feed can upload daily while recent records remain incomplete. Mark open cohorts instead of comparing them with mature ones.

Before activation, Google’s guidance says to upload values for three weeks or one to two conversion cycles, whichever is longer. It also recommends waiting one to two full conversion cycles before judging average Target ROAS against actual performance. Record the clinic’s observed cycle rather than assuming seven days fits every workflow.

How should the 15-conversion recommendation be used?

Google currently says Target ROAS should have at least 15 conversions in the last 30 days at conversion-tracking level. Lower volume can make performance assessment noisier. Preserve all parts of that statement: the strategy is Target ROAS, the window is 30 days, and the scope is conversion tracking level.

Do not turn it into “every clinic needs 15 conversions” or “15 conversions guarantees readiness.” Maximize conversion value without a target is a different strategy. Other campaign types may publish different guidance. Even within Target ROAS, 15 conversions cannot fix identical values, an incorrect goal, late data, missing records, or a value model that changes every week.

Record the current count at the configured conversion-tracking level, then list the actions and campaign goals included in that scope. Do not recast it as a per-action, per-campaign, or per-clinic threshold. Below the recommendation, describe the assessment as noisier; above it, continue through the other gates.

What does the activation decision look like?

Approve activation only when every gate has an owner and evidence. A conditional approval should name the remaining condition and leave the strategy unchanged until it passes. “Monitor after launch” is not a substitute for fixing a known duplicate, wrong goal, unstable formula, or immature cohort.

  1. Confirm the proposed event and value passed the separate policy review.
  2. State why value, rather than volume, matches the campaign objective.
  3. Verify two or more distinct values under one documented model.
  4. Select one funnel stage for bid optimization.
  5. Inspect the campaign goal and every primary or custom-goal action.
  6. Reconcile regular uploads and data-quality exceptions.
  7. Measure conversion delay and define the mature observation window.
  8. Apply current volume guidance only within its documented scope.
  9. Upload values for the recommended pre-activation period.
  10. Set a review date at least one to two conversion cycles after activation.

Frequently asked questions

Does a clinic need 15 conversions before any value-based bidding?

No universal rule appears in the mapped sources. Google currently scopes the 15-in-30 recommendation to Target ROAS at conversion-tracking level. Treat it as current strategy guidance, not eligibility for every value-based bidding option.

Can every conversion have the same value?

That does not meet Google’s guidance for value-based bidding, which calls for two or more different values. If the business only cares about conversion volume, assess Maximize conversions or Target CPA instead.

Does one funnel stage mean one conversion action?

No. One stage can have several primary actions. In a custom goal, included secondary actions also drive bidding. “One stage” is a semantic choice, not a one-action limit.

When should performance be evaluated?

Google recommends uploading values for three weeks or one to two conversion cycles before activation, whichever is longer, and waiting one to two full cycles before comparing Target ROAS performance. Extend the observation window when the clinic’s data matures later.

References

Standardize the Formula, Not the Value: Multi-Location Clinic Bidding

cmsapointoo on August 16, 2026

A multi-location clinic group can standardize how it estimates conversion value without forcing every location to use the same number. A documented formula, shared definitions, and a fixed review process provide the common ground. Each location then supplies its own observed show rate, acceptance rate, and chosen margin basis.

This is an Apointoo editorial governance recommendation, not a Google Ads requirement. Google explains how conversion values can represent business impact and how value-based bidding uses those reported values. It does not prescribe a clinic formula, require location-specific coefficients, or decide whether separate organizations may be combined in a benchmark.

What should be standardized across clinic locations?

Standardize the question that the value is meant to answer. A group might estimate expected contribution per eligible booked consultation. Every location should then use the same event definitions, denominator rules, accounting period, exclusions, attribution policy, and formula version. The resulting values can differ because the underlying operation differs.

A shared formula is only comparable when the inputs mean the same thing. Define an eligible booking before counting it. Define attendance, cancellation, duplicate, test, and accepted case. State whether the margin basis uses collected revenue and which variable costs it subtracts. The clinic booking outcome taxonomy provides a practical starting point for those states.

Shared across the group Supplied by each location
Eligible booking definition Eligible booking count
Attendance and acceptance rules Observed show and acceptance rates
Formula and version Chosen local financial inputs
Reporting window and maturity rule Local cohort dates and sample size
Exclusion and quality checks Local exceptions and corrections

A reporting tool’s need for one number is not a reason to standardize the number itself. Copying a group average into every account hides operational differences and makes the value hard to defend. A formula should expose those differences rather than smooth them away.

How can one formula use local show rate and acceptance rate?

Use a formula whose denominators are explicit. When acceptance is measured among attended consultations, the expected contribution of an eligible booking can be written as follows:

expected contribution per eligible booking
= local show rate
  × local acceptance rate among attended consultations
  × local contribution margin per accepted case

All three inputs belong to the location and reporting period being evaluated. Show rate uses eligible attended consultations divided by eligible bookings. Acceptance uses accepted cases divided by eligible attended consultations. The margin basis comes from the clinic group’s documented accounting policy, applied to that location’s records.

If the clinic already calculates accepted cases divided by all eligible bookings, that rate already includes attendance loss. Do not multiply by show rate again. The break-even cost guide explains how the denominator determines which form is valid. A dashboard should display source counts beside every rate so reviewers can detect a double reduction.

Zero denominators need an explicit unavailable state. A new location with no mature eligible bookings does not have a measured 0% rate. Mark the input as unavailable, retain the counts, and keep it out of bidding until the group approves a temporary method. Do not silently replace missing evidence with another location’s rate.

Why should each location keep its own inputs?

Locations can share a brand and still have different operating conditions. Staffing, scheduling intervals, reminder processes, capacity, payment timing, and accepted-case definitions can change the path from booking to financial outcome. Local inputs preserve that variation. They also show whether a bidding result changed because media improved or because clinic operations changed.

Use mature cohorts. A recent booking may not have reached its appointment date, and an attended consultation may not have a final acceptance status. Freeze each cohort by original booking period, record a snapshot date, and apply the same maturity rule across the group. The clinic’s show-rate measurement method keeps appointment details out of campaign reporting while preserving the counts needed for the rate.

Small samples also need visible treatment. Do not turn a handful of bookings into a confident location benchmark. Show the numerator, denominator, reporting window, and whether the value is provisional. The group can choose a longer window or withhold the value. That choice is internal governance, not a Google threshold.

Local does not mean improvised. Finance should define the permitted margin basis. Operations should own booking-state definitions. Marketing should document the attribution scope and conversion action. One person should approve the final mapping before it affects bidding.

What does Google actually require for value-based bidding?

Google’s conversion-value documentation says values can measure business impact and can differ by transaction. It also lets a conversion action use a static value when transaction-specific values are unavailable. That does not establish value-based bidding readiness by itself. Google’s separate value-based bidding guidance requires two or more distinct values. The documentation describes sales revenue and profit margins as examples, but it does not choose a clinic’s accounting basis or supply location benchmarks.

Google’s value-based bidding guidance explains that Smart Bidding can optimize toward business value through Maximize conversion value or a target return on ad spend. It says advertisers may use real economic values or proxy values such as lead scores. For lead generation, it recommends choosing a single lead-to-sale stage for bid optimization and reporting values consistently and promptly.

Those platform facts support a value strategy. They do not convert the formula in this article into a Google mandate. Show rate, treatment acceptance, contribution margin, cohort maturity, and local approval remain editorial and business choices. Keep that distinction in reports, training, and client communication.

Can a clinic group pool location data?

A group may compare locations inside the same authorized organizational scope when its access, purpose, definitions, and approvals support that use. Even then, keep location-level inputs visible. A pooled figure can hide a low show rate at one unit or a different cost basis at another.

Independent clients should remain isolated by default. An agency should not move detailed records, rates, or financial assumptions from one client into another client’s model merely because both accounts sit under the same manager account. The conversion-action placement guide explains why manager access, action placement, client data ownership, and tenant isolation are separate decisions.

Google’s cited value documentation neither authorizes nor prohibits cross-tenant benchmarking. It is silent on that agency governance question. Do not cite it as permission to pool clients, and do not cite it as a legal ban. Any broader benchmarking program needs its own contractual, privacy, security, and statistical review.

Aggregating a number does not settle every concern. A narrow cohort, unusual amount, location label, or attached operational detail may still reveal information that the receiving party should not have. Minimize fields and access even when the report contains no names.

How should the group govern formula and value changes?

Version the formula separately from the inputs. A formula change affects the meaning of the series. A local input refresh should preserve the formula while updating a defined reporting window. Store the effective date, approver, source counts, margin definition, conversion action, and reason for each change.

  1. Choose one business outcome and one conversion stage.
  2. Define eligible booking, attendance, acceptance, and exclusions.
  3. Approve the financial basis and treatment of variable costs.
  4. Calculate local inputs from mature cohorts.
  5. Check denominators, missing values, and sample size.
  6. Map the approved value to the correct account and action.
  7. Monitor upload delay, bidding behavior, and operational changes.

Historical values need an audit trail. If a location changes its accounting definition or booking workflow, start a new version and mark the break in comparability. Consistency means applying a declared rule faithfully, not preserving a number after its meaning has changed.

Frequently asked questions

Does Google require one conversion-value formula for every location?

No. Google documents conversion values and value-based bidding, but it does not require the formula described here. Using one documented formula with local inputs is an editorial recommendation for internal consistency and auditability.

Should every location receive the same lead value?

Not automatically. A shared value can be defensible only when the underlying outcome and economics are genuinely equivalent. Otherwise, use the same definitions and formula while allowing observed local rates and approved financial inputs to produce different values.

Can an agency use an average from all clinic clients?

Keep independent clients isolated by default. Google’s value-bidding pages do not grant permission for cross-client pooling. Any broader use requires separate authority and review, and the result must not be presented as a Google requirement or benchmark.

What if one location has too little data?

Mark the local value as provisional or unavailable. Preserve the counts and apply the group’s documented small-sample rule. Do not silently substitute another client’s data or present an unsupported estimate as an observed location result.

References

What an Enhanced Conversions for Leads Audit Can and Cannot Prove

cmsapointoo on August 16, 2026

An enhanced conversions for leads audit can prove several technical and reporting facts, but only when each fact keeps its own label. Configuration, request acceptance, destination processing, Ads-side diagnostics, platform attribution, and business lift are different proof layers. Passing one layer does not pass the next.

For clinics, policy eligibility comes before this ladder. Google’s Customer data policies say conversion information related to sensitive categories cannot be measured with enhanced conversions, and the examples include health or medical information. A successful audit cannot make a health-related clinic event eligible. When that restriction applies, stop the outbound workflow and keep the measurement inside the clinic’s approved environment.

What is the proof-layer ladder?

The ladder is a reporting discipline. It stops an auditor from turning a narrow observation into a broader conclusion. A visible setting proves configuration. An HTTP success proves initial request acceptance. A destination status describes later processing. Ads diagnostics describe setup and matching. Reporting describes what Google attributed. None of those observations creates a counterfactual for revenue lift.

Layer Evidence Permitted conclusion Conclusion it cannot support
0. Policy gate Current policy review for the exact event Continue or stop the technical audit Legal advice or permanent eligibility
1. Configuration Account and conversion-action settings Feature appears enabled for the reviewed scope Data was accepted or attributed
2. Request API response and request ID Data Manager accepted the ingestion request Every record reached Google Ads
3. Destination Final destination status, warnings, and errors Processing result for that request Ads reporting or policy approval
4. Ads diagnostics Conversion-action diagnostics and alerts Observed setup or matching condition Incremental business impact
5. Reporting Attributed conversions and values in Google Ads Platform-reported measurement result Revenue caused by the implementation

The distinction follows the same containment rule used in the Data Manager architecture for clinic forms. Transport, policy, and reporting remain separate decisions even when one team owns all three.

Why does a clinic audit start with a policy gate?

Google’s policy applies to enhanced conversions for leads and prohibits conversion information related to sensitive categories. Health or medical information is one of those categories. This is a use restriction, not a formatting warning. Hashing, generic event names, consent records, accepted account terms, and API access do not create an exception.

Describe the proposed conversion in plain language before opening the Ads interface. State what happened, which page or workflow captured it, what service it concerns, and what information the event represents. If it is related to health or medical information, the audit records a stop. It should not proceed to a test upload.

The detailed guide on hashing and clinic-form eligibility explains that boundary. An audit may still review an eligible non-sensitive use in the same organization, but it must not generalize that result to consultation requests, treatment outcomes, appointment details, or other health-related events.

What can configuration evidence prove after the 2026 transition?

Google’s current settings documentation says enhanced conversions for web and leads use a unified on/off setting. It also says that, from April 2026, Google Ads accepts user-provided data from website tags, Data Manager, and API connections at the same time. A screenshot of that setting can prove what the account displayed on the audit date.

The upload path needs a separate check. Google states that from June 15, 2026, offline conversion imports and enhanced conversions for leads uploads moved to the Data Manager API and were blocked in the Google Ads API. Limited legacy access may remain for allowlisted developer tokens with qualifying request history. Do not describe Google Ads API upload access as the general current route.

Configuration evidence should name the account, conversion action, audit time, visible setting, and uploader. It should also state whether the observed setup is legacy, Data Manager, a website tag, or a combination. A green toggle does not prove that a later request arrived, matched, or appeared in reporting.

What does Data Manager request acceptance establish?

The Data Manager diagnostics guide separates the initial response from destination processing. A successful ingestion request has status code 0, enum value OK, and HTTP 200 OK. It returns a request_id. That evidence proves the service accepted the request envelope for processing.

It does not prove that every record succeeded at the Google Ads destination. Google says diagnostics can be retrieved only for successful requests that were not sent with validate_only set to true. An audit should preserve the request ID, submission time, destination, expected record count, and initial response without storing sensitive payload content in the report.

Keep this evidence in a reconciliation log, as described in the offline conversion outbox report. A retry should retain its event identity so the team can distinguish another delivery attempt from another business conversion.

Why must destination diagnostics be reviewed separately?

Google recommends waiting 30 minutes before the first request-status check and polling with backoff until each destination reaches SUCCESS, PARTIAL_SUCCESS, or FAILURE. Processing may take up to 24 hours. An audit closed at the initial HTTP response ends too early.

A final SUCCESS still requires a warning review. Google defines an error as a complete record rejection and a warning as a case where the record was not rejected but part of its data was ignored. PARTIAL_SUCCESS means some records succeeded and others failed. Record counts must be reconciled against what the clinic expected to send.

This layer answers whether the selected destination processed the request and what it ignored or rejected. It does not answer whether the conversion was eligible under policy, whether matching worked in Ads, or whether the platform later attributed a conversion.

What can Ads-side diagnostics prove?

The enhanced conversions for leads diagnostics report evaluates setup health and identifies implementation problems. Google currently describes four data-quality states: Excellent, Good, Needs attention, and Urgent. Alerts can cover missing tag activity, absent user-provided data, no attempted imports, and no matches.

These statuses are time-bounded observations. Google says alerts normally use the past day of data and may use the past seven days when one day is insufficient. An auditor should record the date range, conversion action, alert text, and any change made in response. A status without its observation window is weak evidence.

“Excellent” means Google sees the setup recording enhanced conversions as expected under its diagnostics. It is not a certificate of policy eligibility, legal compliance, complete CRM capture, accurate revenue, or causal impact. Likewise, “no matches” identifies a measurement problem, not proof that the underlying clinic process produced no leads.

How is Ads attribution different from business causality?

Google describes enhanced conversions for leads as matching hashed customer data from offline conversions with website data and signed-in Google accounts, then attributing matched conversions to ad events. The result can change conversion reporting, including engaged-view and cross-device measurement. That is a platform-attribution result.

Business lift asks a different question: what happened because the implementation or advertising treatment existed? A before-and-after increase can also reflect spend, demand, seasonality, sales follow-up, delayed outcomes, definition changes, or recovered measurement. An implementation audit has no untreated counterfactual, so it cannot assign the increase to one cause.

Report the narrow result honestly. For example: “Google Ads reported more attributed conversions after the reviewed setup became active.” Do not rewrite that sentence as “the setup generated more patients” or “revenue increased because matching improved.” The aggregate show-rate reporting method also keeps observed operational outcomes separate from claims about media causality.

What should the final audit report contain?

A useful report is reproducible. It names each claim, its evidence, its time window, the system that produced it, and what remains unknown. It also records the policy classification before any technical result. Screenshots alone are not enough when their account, date range, or conversion action is missing.

  1. Describe the exact event and record the policy decision.
  2. Capture current enhanced-conversions settings and upload route.
  3. Record initial request status and request ID for synthetic or otherwise approved data.
  4. Retrieve destination status, record counts, warnings, and errors.
  5. Capture Ads diagnostics with their action and observation window.
  6. Reconcile attributed reporting under a fixed date range and definition.
  7. List business outcomes separately and avoid causal language.
  8. Assign an owner and review date to every unresolved item.

Use synthetic test records wherever possible. Do not place patient details, form text, appointment notes, treatment data, or rejected payload content in an agency audit. The report should prove the control without becoming another copy of the clinic record.

Frequently asked questions

Does an HTTP 200 response mean the conversions reached Google Ads?

No. It means Data Manager accepted the ingestion request. Retrieve the later destination status, then review record counts, warnings, and errors. Ads-side diagnostics and reporting are additional layers.

Does an Excellent diagnostic status prove the clinic event is eligible?

No. The status describes setup health observed by Google. It does not override the prohibition on enhanced-conversion measurement for conversion information related to health or medical categories.

Can increased attributed conversions be called revenue lift?

No. Increased Google-attributed conversions describe a reporting result. Revenue lift is a causal business claim and needs a design that addresses the counterfactual and other changes during the period.

Can the audit use a real patient event as a test?

Do not use a health-related event to test eligibility or transport. Start with the policy gate. For a separately approved eligible use, prefer synthetic data and keep the audit record free of patient information.

References

Where Should Clinic Conversion Actions Live: Client or Manager Account?

cmsapointoo on August 16, 2026

A clinic conversion action can live in the individual client account or in a Google Ads manager account used for cross-account conversion tracking. That placement decision is not the same as deciding who owns the clinic’s data, who can access the client account, or which account a Data Manager request names. Treating all four questions as “ownership” makes offboarding harder than it needs to be.

For most clinics with one advertising account, keeping clinic-specific actions in the client account is the simpler portability default. This is editorial guidance, not a Google requirement. Manager-level actions suit groups that need shared tracking. The clinic Data Manager architecture covers the policy gate before any event is sent.

Which decision does the clinic need to make?

The first decision is where Google Ads creates and manages the conversion action. Google documents two models. An account-specific action is created in an individual client account and applies only there. A cross-account action is created in a manager account and can be used by selected managed accounts. A client account can use one model or the other, not both simultaneously.

Placement sits beside three other decisions: durable clinic access, limited agency permissions, and the correct Data Manager destination. A written offboarding plan explains how tracking changes when the relationship ends.

Question Google Ads object What it decides
Where does the action live? Client account or manager account Who creates and manages that conversion action
Who can work in the account? User and manager access Which people and linked accounts can administer it
Who owns client data? Client account The client’s continuing data rights and ability to unlink
Where does the API send? Data Manager destination The receiving account, action ID, and credential path
What happens at exit? Unlink and conversion configuration Which tracking path continues after the relationship changes

An “agency-owned” label is too vague. A manager may own a cross-account action without owning client data, or be linked without administrative ownership. Name the account, object, and permission instead.

When should conversion actions stay in the client account?

Account-specific conversion actions fit clinics that need a durable setup inside one client account. Google says these actions are created and managed in the individual account and apply only there. If the clinic changes agencies, the conversion objects, settings, and existing conversion statistics remain attached to the same client account. That supports a cleaner handoff, provided the clinic has direct administrative access.

This model also keeps the action boundary easy to audit. The client account is the conversion account, the action ID belongs there, and the Data Manager operating account points there. The agency can still work through a linked manager account. Access through an MCC does not require moving the action into that manager account.

A group with several serving accounts may need cross-account actions. Even one clinic loses the portability benefit without direct administrative access. Confirm a clinic-controlled administrator and a current action inventory. The offline conversion outbox report keeps delivery evidence separate from account configuration.

When does manager-level cross-account tracking make sense?

Manager-level tracking fits a real multi-account measurement design. Google lets a manager account create cross-account conversion actions and select managed accounts that will use them. This can centralize action definitions and reporting across a group. It is not simply a convenience switch for agency access, because the managed accounts stop using their own account-specific actions while the manager conversion account is selected.

The design needs an explicit scope. List every managed account that uses the action, the goal settings affected, the sites or applications carrying the relevant tags, and the team responsible for changes. Google warns that switching conversion accounts can change which default conversion goals campaigns use. Campaigns targeting specific actions need a review after either direction of change.

Choose this model for a documented shared-tracking need, not because an agency has an MCC. Managed accounts cannot share actions directly; the manager is the sharing point. If an external agency controls it, document that dependency and exit path first.

Does MCC ownership mean the agency owns the clinic’s data?

No. Google distinguishes manager administrative ownership from ownership of client data. An owner manager receives broad administrative and data-access privileges, which can include access to personally identifiable information in the client account. Google also states that this status does not take data ownership or administrative rights away from the client account. The client keeps its data and can remove manager ownership access by unlinking.

Linking alone does not automatically make a manager the administrative owner. A client administrator must enable that status for an existing linked account, and Google recommends granting it only when the manager needs those privileges. Agency operating documents should therefore record three facts separately: whether the MCC is linked, whether it has administrative ownership, and which individual users have administrative access.

Use least privilege and keep a clinic-controlled administrator active. Do not call the MCC “the owner” without naming the Google status. That shorthand hides permissions over users, security, manager links, and data.

What continues after a manager account is unlinked?

The client account keeps its own campaign history and access to Google Ads features after unlinking. Conversion tracking continuity is narrower. In documentation reviewed on August 16, 2026, Google says a cross-account tag stops recording conversions for clicks that occur after unlinking. It can continue recording conversions from earlier clicks for the remaining conversion window, typically 30 days.

If an older client-account tag remains, Google says it may resume unless another manager tag replaces it. Teams still need to identify the replacement action, confirm its tag or server destination, review goals, respect the conversion window, and reconcile both paths.

Removing the MCC ends that manager’s access. It does not create replacement actions, rewrite destinations, or validate bidding goals. The clinic booking outcome taxonomy keeps event meanings stable while account objects change.

How does Data Manager represent account ownership and access?

A Data Manager Destination records where data goes and how credentials reach it. Its operatingAccount is the account that receives the events. For Google Ads offline conversions, Google’s Send Events guide says this must be the Google Ads account that owns the conversion action. The productDestinationId is the conversion action ID within that operating account.

The loginAccount has a different job. It identifies the account where the credential’s Google user has access. In a manager-access scenario, this can be the manager account while the operating account is a child account that owns the action. A linkedAccount applies to documented partner-link scenarios. None of these fields transfers a conversion action between accounts.

Store a destination map per clinic with both account IDs, the action ID, source, status, and verification time. Never reuse another clinic’s destination because both sit under one MCC. Google supports several destinations per request, but per-clinic isolation remains an editorial security recommendation.

A practical governance default for clinics

For one clinic account, default to client-account actions and give the agency limited manager access. Use cross-account actions when several accounts need one framework and the clinic accepts the dependency. This remains governance guidance, not platform policy.

  1. Confirm the clinic has direct administrative access to the client account.
  2. List every conversion action, its owning account, source, goal, and primary or secondary role.
  3. Choose account-specific or cross-account tracking and document why.
  4. Record MCC link status separately from administrative ownership.
  5. Map each Data Manager operating account, login account, and action ID.
  6. Keep each clinic’s credentials, destination map, outbox, and audit evidence isolated.
  7. Write and test the unlink migration before the agency relationship changes.

The inventory must also say whether outbound delivery is permitted. Account placement cannot cure an ineligible health-data use. Review the clinic form eligibility boundary before sending.

Frequently asked questions

Does every clinic need conversion actions in its own account?

No. Google supports both account-specific actions and manager-level cross-account actions. For a clinic with one account, client-account placement is often the simpler editorial default for portability. A multi-account group may have a valid reason to centralize actions in a manager account.

Can an agency MCC access a client-owned conversion action?

Yes, if the manager link and user permissions provide the required access. Access through a manager does not mean the conversion action must live in the manager account. Record link status, administrative ownership, and user access as separate facts.

Does unlinking erase the clinic’s Google Ads history?

No. Google says the individual account keeps its campaign history and access to features. Cross-account conversion tracking can change after unlinking, so the team still needs a planned action, tag, goal, and Data Manager destination migration.

Does loginAccount own the Data Manager conversion action?

Not necessarily. It identifies the account used by the credential path. For Google Ads offline conversions, operatingAccount must be the account that owns the conversion action, and productDestinationId identifies that action.

References

Why Hashing Does Not Make Clinic Forms Eligible for Enhanced Conversions for Leads

cmsapointoo on August 16, 2026

Hashing a clinic form does not make it eligible for enhanced conversions for leads. Google prohibits enhanced-conversion measurement for conversion information related to sensitive categories, including health or medical information. That policy decision comes before tag setup, identifiers, consent records, account terms, or API configuration.

Google also publishes a detailed implementation checklist for businesses that are eligible to use enhanced conversions for leads. It covers data capture, SHA-256 hashing, imports, and diagnostics. Clinics should not read that technical checklist as permission to upload a health-related form. When the conversion falls within the sensitive category, the correct implementation is to keep it out of Google.

What does Google’s customer data policy prohibit?

Google’s Customer data policies apply to enhanced conversions for web, enhanced conversions for leads, store sales uploads, and Google-engaged audiences. The policy says advertisers may not upload conversion information related to sensitive categories. It then states that conversions related to those categories cannot be used for measurement in enhanced conversions or store sales uploads.

Health or medical information appears in Google’s list of sensitive categories. The examples include purchases of medical services, prescription drugs, and medical devices. The wording focuses on what the conversion information relates to. It does not create an exception for a neutral event name, a short form, or a technically valid payload.

A clinic should therefore assess the real action and context. A label such as “lead” or “contact” may still represent a request for a medical service. Changing the label does not change the underlying conversion. The server-side clinic form architecture explains why collection and external delivery need separate decisions.

Why is hashing not an eligibility test?

Google’s implementation checklist tells eligible advertisers to hash personally identifiable information with SHA-256 before sending it. That step helps Google match submitted identifiers. It does not remove the event’s business context or turn health-related conversion information into an unrestricted category.

Hashing appears under data preparation in Google’s checklist, which can make the order seem less important than it is. Preparation explains how eligible data is formatted. Eligibility decides whether the advertiser may use the conversion information at all. Clinics need that answer first.

Condition What it establishes What it does not establish
SHA-256 hashing Technical representation for matching Permission to upload a health-related conversion
Consent record Evidence of a recorded choice under the clinic’s process An exception to Google policy
Legal basis A conclusion under the applicable legal review Eligibility for a Google advertising product
Customer Data Terms accepted An account prerequisite in Google’s checklist Approval of the clinic’s exact event
Generic conversion name A display label A change to the event’s sensitive meaning

How should a clinic classify a form conversion?

Start with a plain description of the action. State what the person is asking for, where the form appears, what service the page concerns, and what operational record the submission creates. Do this internally, before adding a tag or creating an import.

Next, compare that description with the current Customer data policies. If the conversion information relates to health or medical information, stop the enhanced-conversion review. Do not continue to identifier selection, hashing, testing, or activation. An accurate stop decision is more useful than a completed technical checklist for an ineligible event.

Date the classification and keep its scope narrow. A general newsletter form and a consultation request may sit on the same domain while representing different actions. Neither becomes eligible because of that example. The point is that a domain-wide assumption is unreliable, so each proposed conversion needs a current policy analysis.

The classification also needs an owner. Marketing can describe the campaign use, engineering can describe the transport, and a qualified reviewer can assess the applicable policy and legal context. None of those roles should infer approval from another team’s completed setup.

What do the Data Manager documents establish?

Google’s Data Manager API documentation says the service can send offline conversions, enhanced conversions for leads, and conversion events to Google Ads. The send-events guide describes a destination, event objects, formatted and hashed data, and a request that returns a request ID on success.

Those pages describe technical capability. They do not replace Customer data policies. Encryption, hashing, a supported destination, or a successful response cannot make prohibited health-related conversion information eligible. A request ID is evidence that Google accepted the request at the transport layer, not that the clinic passed a policy or legal review.

A test upload cannot answer whether policy permits the event. Even if the transport accepts it, the clinic still has no policy approval. Make the decision before constructing a payload, and keep Data Manager delivery disabled for healthcare forms that fall within the sensitive category.

Where does personalized advertising policy fit?

Google’s Personalized advertising policy classifies health as a sensitive interest category. Advertisers promoting sensitive products or services cannot use advertiser-curated audiences, including Customer Match and their own data segments. Predefined Google audiences follow a different rule because Google excludes sensitive user signals from them.

That policy governs targeting. It should not be used as the sole source for a measurement decision. The Customer data policies provide the direct restriction for enhanced-conversion measurement. A clinic must follow both boundaries where they apply and should never turn form submissions into an audience workaround.

This means a blocked conversion cannot be repurposed as remarketing, Customer Match, or another advertiser-curated segment. It remains inside the clinic’s approved systems. The policy names may sound related, but measurement and audience activation are separate uses.

What should remain inside the clinic?

The original form, its operational status, the clinic’s classification record, and any later appointment outcome should remain in the approved clinic environment. Internal systems may need those records to respond, schedule, reconcile, and report. Their operational need does not create permission to send them to Google.

Marketing can still use aggregate internal reporting. A clinic may count valid submissions, bookings, cancellations, and attendance under documented definitions, then compare totals by an approved campaign dimension inside its own reporting boundary. The clinic booking outcome taxonomy keeps those stages distinct.

Aggregate reporting must not become a disguised event export. Keep individual form content, identifiers, appointment details, treatment context, and free text outside advertising platforms. The guide to measuring show rate by campaign without appointment details describes an internal method for later outcomes.

A publication and implementation stop checklist

  • Write the exact conversion action in plain language.
  • Record whether it relates to health or medical information.
  • Use the current English Customer data policies as the controlling Google source.
  • Stop if the conversion falls within the sensitive category.
  • Do not treat hashing, consent, legal basis, or accepted terms as an exception.
  • Do not create a test upload to ask the API for a policy answer.
  • Keep advertiser-curated audiences outside the clinic-form flow.
  • Store the decision date, sources reviewed, scope, and owner.
  • Recheck when the form purpose, page context, service, or Google policy changes.

This stop checklist contains no tag instructions, identifier mappings, payload examples, or activation steps. None would change the controlling answer: technical preparation does not make a health-related clinic conversion eligible.

Frequently asked questions

Does consent make a clinic form eligible?

No. Consent may be relevant to a clinic’s legal and operational duties, but it does not override Google’s prohibition on enhanced-conversion measurement for health or medical conversion information.

Can a clinic hash email or phone details and then upload them?

Hashing is part of Google’s technical process for eligible uses. It does not remove health context or establish eligibility. Do not upload identifiers for a conversion that falls within the sensitive category.

Does a successful Data Manager request prove compliance?

No. A successful response confirms transport processing. It does not confirm that the event complies with Customer data policies, personalized advertising rules, contracts, or applicable law.

Can the clinic rename the event to a generic lead?

No. Google policy concerns what the conversion information relates to. A generic label does not change a health-related consultation request into a non-sensitive event.

References

How to Measure Clinic Show Rate by Campaign Without Sending Appointment Details

cmsapointoo on August 16, 2026

Clinic show rate by campaign should be calculated inside the clinic’s approved reporting environment. It does not require patient names, appointment notes, treatment labels, or booking records in Google Ads. The useful output is a campaign-level ratio built from an opaque local join between attribution data and an allowlisted appointment outcome.

This distinction matters because Google Ads attribution reports explain advertising conversion paths, while the clinic’s scheduling system owns attendance status. Combining both sources locally answers the management question without turning a patient appointment into an advertising payload. Start with a written metric definition, then prove every row follows the same rule.

Define clinic show rate before querying any data

A clinic needs one documented denominator before it compares campaigns. A practical definition is attended eligible appointments / all eligible booked appointments × 100. “Eligible” is a local operating rule. The clinic must decide how to handle reschedules, duplicates, cancellations, staff test bookings, and appointments whose final status is still unknown.

Do not let each dashboard author improvise that rule. Store a metric version with the report so a later policy change does not rewrite history silently. For example, the clinic may exclude appointments cancelled before a documented cutoff while retaining late cancellations in the denominator. That is an operating choice, not a universal industry standard.

Local status class Typical reporting treatment Required check
Attended Numerator and denominator Final source-system status
No-show Denominator only Allowlisted status mapping
Cancelled Include or exclude under written rule Timing and policy version
Rescheduled Prevent duplicate denominator rows Stable booking lineage
Pending or unknown Exclude until final Report completeness flag

Doctoralia’s product page says its clinic agenda includes online booking, automated reminders, and operational reporting. Zocdoc says its provider reporting includes booking sources and appointment outcomes. Those are vendor descriptions of their own products. They support the need for source and outcome fields, but they do not define your clinic’s show-rate formula.

Keep the join inside the approved reporting boundary

The safe design has three layers. The scheduling system keeps the appointment record. A local attribution table keeps an opaque booking reference and allowlisted campaign dimensions. An aggregate report groups final outcomes by campaign. Only the aggregate report reaches managers. No row in this workflow needs to be sent to Google.

Layer May contain Must not become
Scheduling source Appointment status under the clinic’s controls An advertising export
Local join table Opaque reference, tenant, campaign key, bounded outcome A copied patient record
Campaign report Eligible count, attended count, show rate, completeness A row-level appointment list

The opaque reference must not encode a name, phone number, email address, treatment, or appointment time. It exists to reconcile two local records. Apply tenant scope on every read and write. A valid reference from another clinic must fail, even if an operator can guess or copy it.

For the field boundary behind this design, use the clinic booking outcome taxonomy. If form data also enters the measurement flow, review the server-side clinic form architecture before joining anything.

Build the campaign mapping with an opaque local reference

Capture campaign attribution at the lead or booking boundary, but store it separately from the clinical record. The minimum useful campaign key may be a campaign identifier plus a source classification and capture time. Keep only dimensions the reporting question needs. A keyword, ad group, or device dimension should not be retained merely because an advertising platform exposes it.

  1. Create an opaque internal reference for the attribution record.
  2. Associate that reference with the scheduling record through an approved server-side workflow.
  3. Resolve the clinic tenant from authenticated server context, not from a browser field.
  4. Map source statuses into the versioned outcome taxonomy.
  5. Remove or reject names, contact details, service labels, free text, and full appointment payloads.
  6. Aggregate by campaign and reporting period before displaying the result.

Make the join one-directional for reporting. Analysts should be able to calculate campaign totals without opening the source appointment. If support needs to investigate a mismatch, use a separate, audited reveal path with a defined purpose. Routine dashboard access should not expose appointment detail.

Zocdoc’s provider page describes booking-level detail in its own Appointment Report and summaries in invoices. That is a description of Zocdoc’s marketplace controls, not a reason to reproduce booking-level detail in a separate campaign dashboard. Your report can stop at counts and ratios.

Create a campaign report that managers can audit

Each campaign row should show the eligible appointment count, attended count, resulting show rate, reporting period, metric version, and completeness status. Add a minimum display threshold if small groups could reveal an individual outcome. The threshold must come from the clinic’s approved reporting policy, not from an invented universal number.

Google’s “About attribution reports” documentation says advertisers can review dimensions such as campaigns, ad groups, and keywords after conversion tracking is configured. It also warns that attribution reports and standard Campaigns reporting can differ because of counting, timing, networks, and conversion sources. Use those reports to understand ad interactions. Do not treat them as the clinic’s attendance ledger.

A useful reconciliation view compares aggregate campaign totals across systems. It should identify unmatched attribution references, appointments without final outcomes, duplicated lineage, and late status changes. It should not display the patient behind any mismatch. If managers need context on marketplace reporting, the Zocdoc alternatives guide explains the difference between demand generation and internal scheduling needs.

Validate the metric before using it for budget decisions

Test the calculation with synthetic appointments covering attendance, no-show, cancellation, reschedule, duplicate delivery, and pending status. Confirm that one booking cannot appear twice after a reschedule. Confirm that a late-arriving final status updates the correct reporting period under the written rule.

Then test the privacy boundary. Search the local join, logs, exports, error messages, cached queries, and dashboard responses for prohibited fields. Verify that campaign grouping runs without names, contact data, treatment details, or appointment notes. Attempt a cross-tenant reference and confirm denial. Export the report and confirm it contains only aggregate campaign rows.

Finally, reconcile the result against source-system totals for the same date range and taxonomy version. A mismatch should produce an operational reason, such as unknown status or missing campaign mapping. It must not trigger an automatic upload to Google. The calculation remains useful even when every booking-linked outbound route is disabled.

Frequently asked questions

Does Google Ads need appointment status to calculate clinic show rate?

No. Calculate the metric internally by joining an opaque attribution reference to an allowlisted final outcome, then aggregate by campaign. Google Ads can remain a source of campaign dimensions and advertising reports without receiving appointment status or appointment detail.

Should cancelled appointments remain in the denominator?

The clinic must document that rule before reporting. Cancellation timing, duplicate bookings, and reschedules can change the denominator. Keep a metric version so reports remain comparable and reviewers can see which policy produced each result.

Can managers drill down to individual appointments?

The routine campaign report should not require that access. If an approved support purpose needs a drill-down, place it behind a separate audited reveal path with tenant checks and a bounded retention rule. Do not include it in ordinary exports.

References

A Booking Outcome Taxonomy for Clinic Google Ads

cmsapointoo on August 16, 2026

A clinic booking funnel needs distinct outcome names before it needs another dashboard. A submitted form, a created booking, an attended appointment, a cancellation, and an accepted treatment are different facts. Combining them under “conversion” makes campaign reports easy to read and hard to trust.

The taxonomy below is a recommended healthcare boundary, not a description of every current Apointoo tenant configuration. Keep booking states inside the clinic’s approved environment by default. Do not send patient identifiers, PHI, appointment details, clinical text, or treatment detail to Google. If current platform policy and qualified review permit an external measurement route, use one generic action as the primary source and keep later stages internal.

Why does a clinic need a booking outcome taxonomy?

A taxonomy prevents one label from carrying several incompatible meanings. Marketing may call every form submission a booking. Reception may call a reserved slot a booking. A clinician may care only about attendance. Finance may care about an accepted plan. Each team is reasonable, but the shared report fails unless the terms are fixed.

Booking vendors expose different operational states. Doctoralia describes online scheduling, confirmations, reminders, cancellations, and payments. Zocdoc describes booking sources, appointment outcomes, and spend reports. These product descriptions show why a clinic cannot treat all scheduling activity as one event. They do not supply a universal taxonomy, legal permission, or a Google Ads configuration.

Write the definitions before mapping fields. The related guide on booking system versus CRM ownership explains why the scheduling platform should remain authoritative for appointment state.

A practical five-state taxonomy

The following stages are intentionally small. A clinic can add internal operational states, but advertising and agency reports should not inherit every status available in a scheduling product. Each extra state creates another definition, transition, and reconciliation case.

State Business definition System of record Default Google role
form_submitted The server accepted a valid consultation request form First-party form service Candidate for one approved generic primary action
booking_created The scheduling system created a bookable appointment Booking platform Internal or secondary observation
appointment_attended The booking platform records attendance under the clinic’s rule Booking platform Internal aggregate by default
booking_cancelled The appointment no longer occupies the slot under the source state Booking platform Internal reconciliation
treatment_accepted The clinic records a generic accepted business outcome Approved clinic system Internal value model only, with no treatment detail

The names describe business states, not payload instructions. A clinic must not send treatment_accepted with a procedure name, diagnosis, plan, patient reference, or appointment note. It may use an aggregate acceptance rate inside its own value model without exporting the underlying record.

How should the clinic choose its primary conversion?

Choose the earliest stage that is both meaningful and reliably proven, then keep that choice stable enough to compare periods. For a forms-focused measurement design, the server-confirmed submission is the clearest internal candidate. A later booking state can improve internal reporting, but it should not silently become a second primary source.

Google Ads documents primary actions as eligible for bidding when the campaign uses their conversion goal. Secondary actions remain available for observation in the relevant reporting columns, although custom goal choices can change that behavior. Review the live account configuration instead of assuming that a label called “secondary” can never influence bidding.

The clinic should record the selected action, source system, evidence, effective date, owner, and rollback. Read why one primary conversion source prevents double counting before adding a second delivery path.

How do you join outcomes without copying the appointment?

Use an opaque join reference that carries no patient meaning. The form service stores the campaign context and its event ID. The booking system keeps appointment truth. A bounded mapping relates the two inside the approved environment. The reporting job reads only the status and dimensions required for an aggregate.

  1. Create an opaque reference for the valid form submission.
  2. Associate it with a booking through an approved server workflow.
  3. Read the current booking state from the authoritative source.
  4. Project only the generic state and reporting dimensions.
  5. Aggregate by campaign before sharing the report.

Do not use a patient name, email, phone number, record number, treatment, or free text as the join key. Do not place those fields in URLs, conversion action names, order IDs, logs, or support tickets. The appointment outcome linking guide covers the broader privacy boundary.

How should status changes and duplicates behave?

Booking states change. A person can book, cancel, reschedule, and attend later. Treat each source update as a version of the same booking projection, not a new marketing conversion. The source event key stays stable, while the version and source timestamp advance.

The system should reject impossible transitions or send them to review. A cancellation received before a delayed booking event may be valid but out of order. A repeated webhook may be a normal retry. The consumer needs idempotency, ordering rules, and a reconciliation read from the booking source. It should never repair the schedule from an advertising report.

Keep the Google delivery contract separate. One primary form conversion uses one stable event reference. Later internal states update the clinic report. They do not fire another competing primary conversion. For implementation details, see booking webhook idempotency and audit evidence.

What should an agency report show?

An agency report should show a funnel with explicit denominators and source dates. Form submissions come from the first-party form service. Bookings, attendance, and cancellations come from the scheduling system. Accepted outcomes come from the clinic’s approved business record. Google Ads delivery status is a separate column, not proof that the source outcome occurred.

Metric Numerator Denominator Source
Form to booking rate Bookings linked to valid forms Valid form submissions Form and booking systems
Show rate Attended appointments Eligible booked appointments Booking system
Cancellation rate Cancelled appointments Eligible booked appointments Booking system
Acceptance rate Generic accepted outcomes Eligible attended cases under the clinic’s rule Approved clinic system

Define “eligible” in the report. Exclude test records and document how reschedules affect the denominator. Do not invent a benchmark. Compare the clinic with its own prior mature cohorts. The article on campaign show rate without appointment details gives a focused calculation method.

What must stay out of Google Ads?

The taxonomy is an internal operating tool. It does not authorize every state for advertising upload. Keep PHI, patient identifiers, appointment details, treatment names, diagnosis, procedure, clinician notes, and free text out of Google. Do not hide them in a hash, event label, custom variable, URL, value field, or deduplication key.

Do not create health audiences from the booking states. Do not add direct gtag or fbq calls to the form or confirmation page. Do not track calls as a substitute for form events. If the clinic has an approved Data Manager route, use the server-side clinic form architecture and keep it as the sole primary delivery source.

When the policy or legal answer is unresolved, keep all later outcomes inside aggregate reporting. An internal count can help the clinic make decisions without becoming an external conversion event.

Frequently asked questions

Is a submitted form the same as a booking?

No. A submitted form proves that the server accepted a request. A booking exists only when the scheduling system creates an appointment under its own rules.

Should attendance be the primary Google Ads conversion?

Not automatically. Attendance occurs later and belongs to the booking source. For this forms-only architecture, keep the approved server-confirmed form as the sole primary candidate and use attendance in internal aggregate reporting unless a separate review approves otherwise.

Can treatment acceptance appear in the report?

It can appear as an aggregate business metric under a clinic-defined rule. The report should not expose the treatment, diagnosis, patient, clinician note, or appointment record.

How are rescheduled appointments counted?

Keep one booking lineage and document the denominator rule. A reschedule should not become a second form conversion. The booking source remains authoritative for the current appointment state.

References

Google Ads Data Manager API for Clinic Forms: A Server-Side Architecture

cmsapointoo on August 16, 2026

A clinic form should not feed Google Ads automatically. A controlled design starts with first-party internal measurement: the browser submits a form-shaped event to the clinic’s endpoint, and the server keeps it inside the approved environment unless a separate external-use review passes. Calls, chat messages, direct gtag or fbq requests, and audience uploads stay outside this design.

Google’s customer data policy says advertisers may not upload conversion information related to sensitive categories and lists health or medical information among those categories. A generic event name does not settle whether the underlying event is health-related. This article therefore describes a target healthcare control pattern, not controls already enabled for every Apointoo tenant. Keep outbound delivery disabled unless current Google policy and qualified legal and privacy review permit the clinic’s exact event and fields.

What does the server-side clinic form architecture do?

The architecture separates collection, decision, delivery, and reporting. The form posts to the clinic’s approved application. That application creates a bounded internal event and checks whether it may leave the first-party environment. Only an independently cleared event can proceed to a configured Google Ads conversion destination. The browser never calls an advertising endpoint directly.

clinic form
  -> first-party endpoint
  -> tenant and consent checks
  -> field allowlist
  -> durable event record
  -> default stop unless external use is cleared
  -> Data Manager conversion destination, if permitted
  -> delivery reconciliation

Google’s Data Manager documentation says its event path supports online and offline conversion data and requires a destination plus event objects. That is a transport contract, not permission to send health-linked data. Google’s customer data policy supplies a separate restriction for conversion information related to sensitive categories. Review the Google Ads health conversion policy boundary before enabling any clinic route.

Step 1: define one form-shaped conversion

Start with an internal definition that a clinic owner and engineer interpret the same way. For example: “The measured event is a successfully submitted consultation request form confirmed by the server.” The sentence identifies the user action, the technical proof, and the system that owns it. It does not make the event eligible for external upload or claim that an appointment happened.

Keep the event narrow. A booking button click is not a completed form. A page view is not a lead. A phone call is outside this product boundary. If a later booking outcome matters, store that state internally and map it through a separate approved decision. The clinic booking outcome taxonomy provides the stage definitions.

If the external route is independently cleared, Google Ads allows conversion actions to be primary or secondary. Only one source should own the primary action used for bidding and headline reporting. Do not keep a direct browser conversion and a server conversion active as competing primary sources. The one primary conversion source guide explains the reporting consequence.

Step 2: collect only what the first-party endpoint needs

The form endpoint needs enough information to validate the submission, enforce consent, and create an event reference. It does not need to copy the full form into the advertising pipeline. Clinical questions, symptoms, treatment requests, appointment notes, and free-text messages must remain outside the Google event.

Separate the operational form record from the conversion record. The operational system may need contact details to respond to the person. The conversion record should contain only an opaque event ID, tenant-owned status, approved timestamp, consent decision metadata, and the limited advertising fields approved for the destination. Do not reuse email, phone number, a medical record number, or a booking ID as the event ID.

Reject unknown fields at this boundary. A permissive serializer can leak a new form field into an outbound payload after a routine form update. An allowlist makes that failure visible. It also keeps logs and retry queues from becoming shadow copies of clinic records.

Step 3: test eligibility before building a Data Manager event

The Data Manager API can technically accept conversion events for a configured destination. That capability is not an eligibility decision. Google’s customer data policy restricts conversion information related to sensitive categories, while its personalized advertising policy separately restricts advertiser-curated health audiences. Do not use Customer Match, remarketing, or audience activation as a workaround.

Field class Default decision Reason
Opaque internal event reference Keep internal Supports first-party deduplication without identifying a patient
Generic action Keep internal until cleared A generic label does not remove health context
Timestamp and numeric value Keep internal until cleared They still describe a conversion event
Ad click reference Keep internal until cleared Requires a valid purpose and current policy analysis
Name, email, phone, treatment, diagnosis, or free text Blocked from this route Outside the clinic conversion boundary

A hash does not change the field’s meaning. Do not hash a patient identifier and treat it as anonymous. If the approved route cannot work without a prohibited field, keep the outcome in internal aggregate reporting instead of weakening the boundary.

Step 4: enforce consent and policy before queueing

The final API call is too late for the first policy check. A future healthcare route needs a gate before an event enters an outbound queue. Resolve the tenant on the server, confirm the exact destination, check a dated approval record, apply the field allowlist, and verify the required consent state. Missing or conflicting state should stop delivery. Do not infer that this control exists merely because Google credentials are configured.

  1. Resolve the authenticated tenant and approved form.
  2. Confirm that the server received a valid form-shaped event.
  3. Load the tenant’s current destination and policy decision.
  4. Reject prohibited or unexpected fields.
  5. Confirm that this route owns the single primary conversion.
  6. Create the outbound record only after every check passes.

Consent does not override a Google policy restriction. An API success response does not prove legal permission either. Keep the approval dated and name the source pages reviewed. Recheck the route when the clinic changes services, form fields, consent text, account ownership, or conversion goals.

Step 5: reconcile delivery instead of trusting HTTP success

Keep an internal delivery record with queued, sent, failed, and intentionally suppressed states. Treat transport success only as evidence that the request left your system, not as proof of legal permission or later reporting. A retry must keep the same event reference so it cannot create another primary conversion.

When external delivery is permitted, reconciliation answers a practical question: did the cleared event reach the intended destination once? It should not expose the original form or patient record. Store error classes and counts, not rejected sensitive content. Use synthetic form submissions for testing, then confirm that no browser request goes directly to Google or Meta.

Reporting should also separate form submissions from later clinic outcomes. The guide to measuring show rate without appointment details describes an aggregate approach for that later stage.

Common design mistakes

  • Sending the full form object because the server already has it.
  • Keeping an old direct conversion tag active beside the server event.
  • Calling a button click, phone call, or message a form submission.
  • Using email, phone, booking reference, or treatment text as a deduplication key.
  • Enabling Data Manager audience features because the API also supports them.
  • Treating a successful request as proof of policy, consent, or legal approval.

The smallest correct design has one form contract, one server decision point, one outbound destination, and one reconciliation ledger. Add another path only when a documented business need cannot be met by the existing one.

Frequently asked questions

Does this architecture use a Google tag on the clinic form?

No. The browser submits the form-shaped event to a first-party endpoint. The approved server route handles Data Manager delivery. There is no direct gtag or fbq conversion call from the form page.

Can the same route upload clinic audiences?

No. This design is limited to approved conversion events. It does not create or update advertiser-curated audiences, Customer Match lists, or remarketing segments.

Can a clinic send hashed patient contact data?

Not under this boundary. Hashing does not make patient contact data harmless or remove the surrounding health context. Keep patient identifiers out of Google payloads and seek qualified review for the clinic’s exact facts.

What happens when policy or consent is unclear?

Do not enable the outbound route. The clinic can still use first-party aggregate reporting while the owner, privacy reviewer, and qualified counsel assess current policy and the intended use.

References