A booking page on another domain can report zero or incomplete Google Ads conversions when the click identifier is not carried across the handoff. A browser does not automatically make a GCLID, GBRAID, or WBRAID available to a different domain. The Google tag domain linker, redirects, and server-side booking flow must preserve the attribution data deliberately.
Why does the domain change matter?
A patient may click an ad on clinic.example and then book on book.vendor.example or a completely different provider domain. The first page can see a click identifier while the second page has no trustworthy way to connect the request to that click unless the measurement setup passes it.
Google’s cross-domain guidance describes the linker as a mechanism for decorating links and carrying measurement information between domains. The domains must be configured intentionally. A subdomain and a separate registrable domain are not interchangeable assumptions.
The owned booking link reporting comparison helps separate the route a patient uses from the attribution contract. The route can work for scheduling while measurement still fails.
What can drop the identifier?
Common loss points include a redirect that keeps only a small allowlist of query parameters, a link generated by a booking widget, a consent decision that prevents the tag from writing its state, a server request that accepts only an appointment payload, and a confirmation page that is outside the configured linker domains.
Some systems also rewrite URLs for campaign tracking, remove unknown parameters for security, or create a new browser session. Those behaviors can be correct for other reasons and still break attribution. The fix is to trace the real request path rather than adding another tag to the confirmation page.
How should a clinic configure the linker?
Start with the domains that appear in the patient journey. Configure the Google tag or Google Tag Manager implementation according to Google’s current cross-domain instructions. If the booking vendor requires an allowlist or a specific integration setting, apply that setting as well. Do not assume that a tag on the marketing site can control a vendor-hosted page it never loads.
List the landing page, booking page, payment or confirmation page, and any redirect host.
Configure the linker for each participating domain.
Preserve approved click parameters through redirects and server handoffs.
Store an opaque internal attribution record before creating the appointment.
Trigger the conversion only after the selected booking state is reached.
When the clinic has a lawful and policy-compliant reason to retain an advertising identifier, storing it on the server can make the conversion pipeline more reliable. Use a tenant-scoped record, strict access control, a retention rule, and an opaque appointment reference. Do not store patient details in the advertising record just because the booking API sends them.
A server record does not cure a consent refusal or a prohibited healthcare payload. It only prevents a technical handoff from discarding a value that the approved design permits. If the policy decision is uncertain, keep the event blocked and record the reason.
How can a team diagnose zero conversions?
Check
Evidence
Likely conclusion
Landing click
Test URL contains the expected identifier
Ad click reached the first host
Domain handoff
Redirect and destination URL preserve approved fields
Linker or redirect is carrying data
Server intake
Attribution record has source and timestamp
Booking API did not discard it
Conversion event
Outbox row has stable transaction ID
Event can be reconciled without a browser cookie
Use a synthetic click and a test appointment. Avoid putting a patient’s name, phone, treatment, or medical detail into browser console logs or tickets. A clean technical test proves the handoff for that configuration; it does not prove every live campaign conversion is valid.
FAQ
Does using a subdomain automatically preserve the GCLID?
No. Treat every domain boundary as a handoff that needs configuration and testing.
Can UTM parameters replace the Google click identifier?
UTMs describe campaign context, but they do not automatically provide the click-level identifier Google uses for some conversion workflows.
Why does the browser test pass but production report zero?
Production may use a different redirect, consent state, booking domain, or server path. Compare the exact request chain.
Should the confirmation page fire the conversion?
Only after the clinic defines the conversion state and confirms that the event and payload are permitted.
Not legal advice: This article explains an implementation boundary. It does not decide consent, healthcare advertising eligibility, or a clinic’s legal obligations.
Usually no, not as an observed conversion built from consented advertising identifiers. When a patient in the EEA refuses the consent required by the clinic’s setup, the clinic cannot measure that person as though consent had been granted. Consent mode can provide limited cookieless signals for modeling when configured within the applicable policy, but modeled reporting is not the same as observing or storing a consented conversion.
What does a consent refusal change?
A refusal means the clinic must not load or use measurement storage in a way that requires the missing permission. Google describes consent mode as a way for tags to adjust behavior according to the user’s consent state. The state is sent to Google so tags and related services can apply the configured behavior.
That does not mean every click disappears from every report. It means the clinic must distinguish an observed conversion, a modeled estimate, and an event blocked by the consent decision. Combining those states into one number makes the report look more certain than the evidence allows.
The healthcare consent and Google Ads permission guide covers the boundary between a privacy permission and an advertising setting. The product setting cannot replace the clinic’s notice, choice, record, or legal analysis.
How do basic and advanced consent mode differ?
In a basic implementation, Google tags are blocked until the user grants the required consent. This produces less directly observed data, because the tag does not send the normal event before consent. In an advanced implementation, tags can load with consent denied and send limited cookieless signals designed to support modeling. The exact tags, consent types, and regional behavior need to be tested in the clinic’s implementation.
Advanced mode is not a shortcut around a refusal. It changes what limited signal may be sent and how Google may model gaps. It does not permit the clinic to store an advertising cookie, read a denied identifier, or disclose a patient detail that the privacy design forbids.
Do not add a claim that advanced mode recovers every conversion. Google publishes no universal guarantee for a specific clinic, treatment, region, or traffic volume. A dashboard should show whether a number is observed, modeled, or unavailable.
What is Google’s consent policy asking the clinic to do?
Google’s EU User Consent Policy requires consent for the use of cookies or other local storage where the policy applies and for personalized advertising in the circumstances described by Google. The clinic still needs a consent experience that matches its own legal duties and the services it operates.
The Google tag consent documentation explains that consent signals are passed to tags and services. It does not make Google the clinic’s privacy officer. The clinic must identify the controller, processor, vendor, purpose, retention, and transfer facts for the actual booking journey.
Can the clinic send the conversion later after the patient refuses?
Do not treat later offline confirmation as automatic permission to reuse a denied online identifier. A later event may be measured only if the clinic has a lawful and policy-compliant path for that event, with the required notice, consent, contract, and eligible payload.
For a healthcare booking, the internal system can still record that an appointment occurred when the clinic is allowed to use that information for its operational purpose. Sending a separate event to Google is a new disclosure and needs its own review. The health conversion tracking risk analysis explains why an internal outcome and an advertising upload are not the same record.
If the policy decision is unresolved, hold the event in an internal queue with a status such as needs-review. Do not hash a name or email and assume that hashing solves the refusal.
How should a reporting dashboard label the result?
Use separate fields. A useful minimum is consent_state, observed_event, modeled_event, upload_allowed, and reason_blocked. Never replace a denied state with an empty string that looks like a technical outage.
State
What the dashboard may say
What it must not say
Granted
Observed event, subject to tag and policy checks
Guaranteed attribution
Denied, basic mode
Tag event blocked or unavailable
Patient did not convert
Denied, advanced mode
Limited signal may support modeled reporting
Observed consented conversion
Unknown
Measurement needs review
Consent granted by default
What should engineering test before launch?
Run a granted and denied journey in an EEA test region.
Inspect whether storage, tags, redirects, and server events follow the state.
Confirm that no patient name, service detail, or treatment note enters the advertising payload.
Check that a later appointment outcome cannot bypass the blocked state without a reviewed rule.
Verify that reports label modeled and observed results separately.
Keep screenshots, tag logs, consent version, and test timestamp in the release record.
Not legal advice: This is technical information, not legal advice or a promise that a clinic’s consent and advertising setup complies with every applicable rule.
Starting August 17, 2026, Google Ads says eligible clinic campaigns that are limited by budget and use a target-based bid strategy can perform more consistently toward their stated target. A Target ROAS campaign that has historically exceeded its target may therefore experience performance changes if it remains in scope. Google does not automatically change the campaign’s budget or target. The advertiser must decide whether the existing target still represents the current business goal.
Which clinic campaigns are in scope
The announcement applies to campaigns that are limited by budget and use a target-based bid strategy, such as Target CPA or Target ROAS. Eligible campaign types listed by Google are Search, Shopping, Performance Max, Demand Gen, and Travel. A campaign must meet the relevant conditions; simply using Target ROAS does not place every clinic campaign in scope.
App, Video reach, and Video view campaigns continue with their previous behavior. Hotel and Display campaigns already use the newer behavior. Multichannel Performance Max and Demand Gen campaigns may also see changes in how spend is distributed across channels as the system works toward the selected target.
Google says notifications can be triggered for campaigns that were limited by budget at any point during the prior 12 months and use an impacted strategy. A campaign appearing in the review tool does not necessarily mean it is currently affected.
Operational inference: check current campaign status rather than relying only on an email, notification, or tool listing.
What more consistent performance toward target means
A bidding target is an instruction to the strategy, not merely a reporting benchmark. Google says the updated systems will behave more predictably around that instruction, including when a campaign’s budget changes. If actual historic performance has been materially better than the configured target, the system may move performance closer to the target after the rollout.
Operational inference: for Target ROAS, compare the campaign’s configured target with the actual return produced over a representative period. A large gap can indicate that the written target no longer expresses the outcome the business expects. The rollout does not itself determine which return is commercially acceptable for a clinic.
Google’s announcement warns that campaigns historically overachieving their targets may see performance volatility if no action is taken. It does not promise a specific increase in spend, conversion volume, value, or profitability. Those outcomes depend on auctions, budget, conversion inputs, campaign mix, market conditions, and the target chosen by the advertiser.
Google will not change the target or budget automatically
The official guidance is explicit: Google will not automatically change campaign targets or budgets as part of this update. If the current target accurately reflects the advertiser’s goal, Google says no change is required. If an overperforming campaign should preserve its current performance level, the advertiser can review the target and use Google’s Target Adjustment Tool where available.
The tool is available in Google Ads for eligible campaigns. For campaigns managed by Search Ads 360, Google says the tool is not available in Google Ads and adjustments should be made in Search Ads 360. Tool availability is not an instruction to change a setting. It provides a review path for the advertiser’s own decision.
Operational inference: do not accept a suggested target merely because it appears in an interface. The accountable decision is whether the target represents the clinic’s current value model, capacity, margin, and growth objective. The clinic value-based bidding readiness guide provides a broader checklist for that decision.
Decide whether the existing Target ROAS is still truthful
Operational inference for this section: start with the business constraint, then evaluate the setting. Document the target currently configured, actual ROAS over a representative period, conversion value definition, budget status, lag, and any material changes in service mix or capacity. Compare those facts with the return the clinic now needs.
Keep the target when it is still the intended operating goal and the clinic accepts that bidding may move closer to it. Consider changing it when the historic target is stale, was set as a loose floor, or conflicts with the current economic requirement. Do not use a short period with unusual volume as the sole basis for a new target.
ROAS also depends on the value supplied to Google Ads. Revenue, expected revenue, and contribution margin are different measures. A campaign can appear to meet a revenue-based target while failing a margin-based constraint. For a practical distinction, see revenue versus contribution margin in dental lead values.
Capture a clean baseline before August 17
Operational inference for this section: before changing any setting, export or record a baseline with campaign ID, campaign type, bid strategy, target ROAS, daily budget, current limited-by-budget status, recent spend, conversion value, ROAS, conversion volume, and the date range used. Record conversion lag and major tracking incidents beside the figures.
Use a period long enough to represent ordinary demand and the clinic’s conversion cycle. Segment only where it helps explain the campaign’s actual operating state. For Performance Max or Demand Gen, capture available channel distribution because Google notes that multichannel allocation can shift under the new behavior.
Keep the baseline free of person-level lead or appointment information. Campaign totals, configuration values, dates, and aggregate outcomes are sufficient. If the report’s conversion columns disagree, resolve the goal and inclusion settings first with the guide to missing clinic bookings from the Conversions column.
Make one governed change at a time
Operational inference for this section: if the business approves a target change, record the old target, new target, reason, approving owner, timestamp, and expected observation window. Avoid changing target, budget, conversion actions, value rules, and creative simultaneously. Multiple concurrent changes make the rollout’s effect difficult to distinguish from the advertiser’s own intervention.
A budget increase deserves separate approval. The platform update may make target behavior more consistent when budgets change, but it does not authorize additional spend. Capacity also matters for clinics: extra eligible demand is not useful if appointment availability, follow-up, or service delivery cannot absorb it.
If no target change is approved, record that the current setting was reviewed and intentionally retained. That creates a clearer operational history than silence and prevents a later assumption that Google changed the value automatically.
Monitor performance after the rollout
Operational inference for this section: compare post-rollout performance with the saved baseline at consistent intervals. Review budget status, actual ROAS versus target, spend, conversion value, conversion count, and channel distribution where relevant. Allow for normal conversion delay before drawing conclusions.
Do not attribute every movement after August 17 to the bidding update. Auction demand, seasonality, clinic capacity, creative changes, landing pages, tracking outages, and conversion-definition changes can produce the same symptoms. Annotate those events and investigate material deviations against campaign change history.
If a measurement outage occurred, do not compensate by changing the bidding target without first addressing the data issue. Google’s data exclusion feature has narrow documented uses; the clinic conversion tracking outage guide explains how to separate incident response from ordinary bidding decisions.
Check the conversion value before judging Target ROAS
Target ROAS can only optimize against the conversion values available to the strategy.
Operational inference for this section: confirm which actions are primary, which appear only in All conversions, and whether the value model reflects the outcome named in the campaign goal. A booking request, attended appointment, and collected revenue are not interchangeable.
Operational inference: reconcile the reporting cohort before comparing Google Ads ROAS with a clinic finance report. Use the original lead or event cohort consistently, account for conversion lag, and document exclusions. The original lead cohort reporting guide explains why mixing event-date and lead-date totals can create a false performance change.
Do not upload medical details or person-level context to make values more precise. The bidding review needs an approved aggregate or generic business value model that complies with applicable Google policies, privacy duties, and internal governance.
A decision checklist for August 17
Operational inference: use this checklist to separate Google’s announced scope from the clinic’s own target and budget decision.
Is the campaign currently limited by budget, and was it limited during the prior 12 months?
Does it use Target ROAS or another target-based strategy covered by the update?
Is its campaign type listed as eligible, already transitioned, or continuing previous behavior?
Does the configured target still represent the clinic’s approved current goal?
Is actual historic performance materially better than that target?
Are conversion values, goal inclusion, lag, and recent tracking incidents understood?
Has any proposed target or budget change received explicit approval?
Is a dated baseline available for post-rollout comparison?
Frequently asked questions
Will Google raise my clinic’s daily budget on August 17?
No. Google says it will not automatically change campaign budgets or targets as part of this update. Any budget increase remains an advertiser decision.
Must every Target ROAS clinic campaign change its target?
No. The change concerns eligible campaigns that are limited by budget. Google says no action is required when the current target accurately reflects the advertiser’s goal.
Why could an overperforming campaign change?
The system will work more consistently toward the stated target. If actual historic performance was materially better than that target, performance may move closer to the configured instruction and may be volatile during the transition.
Does appearing in the Target Adjustment Tool prove the campaign is currently affected?
No. Google says the list can include campaigns that were limited by budget at any point in the previous 12 months and use an impacted strategy. Confirm current status and settings directly.
Use a RETRACTION conversion adjustment when a previously uploaded clinic conversion was canceled and should no longer count. A retraction removes the conversion count and sets its value to zero. Use RESTATEMENT only when the conversion remains valid but its value must change. Prefer the original order_id, submit the adjustment through the Google Ads account that manages the conversion action, and treat a retraction as final. The ability to send an API request does not make health-related data eligible for upload.
What a retraction changes in Google Ads
Google Ads supports two distinct conversion adjustment types. A retraction tells Google Ads that the original conversion should be removed. Google sets its value to zero and removes it from the conversion count. That change can affect reporting fields based on conversion count, conversion value, cost per acquisition, and return on ad spend.
A restatement keeps the conversion but replaces its value. It is appropriate when the business outcome still happened and only the reported value was wrong. It does not reduce the conversion count. Choosing between the two is therefore an accounting decision about the original event, not a cosmetic reporting preference.
For a canceled booking that was previously counted as a completed offline conversion, retraction is the matching operation if the clinic’s defined conversion no longer occurred. If the booking remained valid but its commercial value changed, restatement may be the matching operation. The conversion definition should be documented before either adjustment is sent.
Confirm that the cancellation is final before retracting
Google warns that a retracted conversion cannot later be adjusted. A conversion restated to zero is also closed to later adjustment. Subsequent attempts are ignored without an error, so an operator should not assume that a successful request means a second correction was applied.
Operational inference: retract only after the clinic’s source system has reached a final administrative state under its own documented rules. A temporary reschedule, pending review, duplicate flag, or payment dispute is not automatically the same as a final cancellation. The Ads operator should receive a simple approved status and an opaque event identifier, not clinical notes or other sensitive details used to reach that status.
Operational inference: keep the cancellation reason in the clinic’s internal record and send only the fields Google Ads needs to locate and adjust the original conversion. This separation supports reconciliation without expanding the advertising payload. For a durable implementation pattern, see the offline conversion outbox reporting guide.
Prefer the original order ID
The Google Ads API documentation recommends identifying the original conversion with order_id. It is more durable than matching a Google click identifier and conversion time. The order ID must be the same opaque identifier sent with the original conversion, not a newly generated ID for the cancellation.
If the original conversion did not contain an order ID, an eligible offline conversion can be matched with its GCLID and conversion time. GBRAID adjustments require an order ID, and the documented adjustment flow does not support WBRAID. For a WEBPAGE conversion action, an order ID is required. It is also required whenever the original conversion was uploaded with one.
Operational inference: use an opaque order ID that does not encode a person’s name, phone number, email address, diagnosis, treatment, appointment notes, or procedure. It should function only as a stable reconciliation key. If the original pipeline cannot produce that key reliably, fix the identifier contract before automating cancellations.
Submit through the account managing the conversion action
The adjustment must be uploaded by the Google Ads account that manages the conversion action. In cross-account conversion tracking, that may be a manager account rather than the individual clinic account. Sending through the wrong account can produce NO_CONVERSION_ACTION_FOUND even when the action is visible elsewhere in the account hierarchy.
The API documentation limits adjustments to conversion actions whose type is SALESFORCE, UPLOAD_CLICKS, or WEBPAGE. The conversion must already have been recorded. A newly created action can also need four to six hours before uploads are accepted. A CONVERSION_NOT_FOUND response can mean the original conversion was never imported, was discarded, or cannot be matched with the supplied identifier and time.
Operational inference: before changing the pipeline, compare the conversion action owner, action type, original identifier, and original upload result. The offline conversion diagnostics guide covers the account-boundary checks that commonly explain an empty client view.
A minimal retraction workflow
Operational inference: the following sequence turns the documented adjustment requirements into a reviewable clinic workflow.
Confirm that the original event appears as an accepted conversion and record the managing customer ID and conversion action.
Confirm that the cancellation is final according to the clinic’s approved administrative definition.
Retrieve the original opaque order_id. Use GCLID plus conversion time only where the documented rules permit that match.
Create a RETRACTION adjustment with the adjustment time and the original conversion reference.
Upload from the account managing the conversion action and keep partial failure enabled so individual row errors are returned.
Store the request result and reconcile the adjusted reporting after Google Ads processing time.
Operational inference: make the operation idempotent in the clinic’s outbox. One approved cancellation should create one adjustment attempt record, with retries tied to the same event and identifier. This reduces duplicate requests and preserves an audit trail without copying sensitive source-system fields into advertising logs.
Verify the adjustment instead of trusting the request alone
The API requires partial failure mode for these uploads.
Operational inference: inspect each returned result and error rather than treating the HTTP response as proof that every row succeeded. Keep the Google request ID, managing customer ID, conversion action reference, opaque order ID, adjustment type, adjustment time, and per-row outcome. Those fields are enough for most technical reconciliation and do not require clinical context.
Google says adjustment reporting generally appears on a timing similar to regular conversion data.
Operational inference: after processing, confirm that the specific conversion is no longer counted and that its value is zero. Then verify the expected effect in the reporting columns used by the campaign. If an event appears under All conversions but not Conversions, review action inclusion and goal configuration using the clinic conversion-column troubleshooting guide.
Operational inference: do not test a retraction against a real conversion that might need to be restored. Use a controlled eligible test event and document its expected lifecycle. Because retraction is effectively irreversible, a production proof should focus on the final accepted cancellation, request result, and reporting reconciliation.
Platform capability does not decide health-data eligibility
The Google Ads API documents how eligible conversions can be adjusted. That technical capability is not permission to upload health or medical information. Google’s Customer data policies prohibit conversion information related to sensitive categories, including health and medical information, for the products covered by that policy, such as enhanced conversions, store sales uploads, and Google-engaged audiences.
The mapped sources document conversion adjustment through Google Ads tools and the Google Ads API. They do not establish that Data Manager supports this adjustment operation, so this article does not recommend or claim a Data Manager adjustment path. It also does not conclude that every administrative clinic conversion is eligible. Eligibility depends on the exact product, event definition, data fields, consent and legal basis, account configuration, and current Google policy.
Operational inference: use a generic business event only after that separate review, and exclude medical details from identifiers, values, labels, logs, and upload payloads. Hashing does not change the nature of sensitive data. See how to audit enhanced conversions for leads without overclaiming proof for a related measurement boundary.
Common failure modes
Wrong adjustment type: a restatement changes value but leaves the conversion count in place.
Wrong account: the upload runs from a client account while a manager account controls the action.
New identifier: the cancellation receives a different order ID and cannot match the original conversion.
Missing original conversion: the source event was rejected, discarded, or never uploaded.
Unsupported action type: the action is outside the API’s documented adjustment types.
Premature retry: an operator retries before checking row-level errors and creates a misleading local state.
Sensitive payload: an implementation copies clinical or identifying fields that are unnecessary for reconciliation.
Frequently asked questions
Can a retracted conversion be restored?
No documented adjustment restores it. Google says a retracted conversion cannot be adjusted further, and later attempts are ignored without an error. Treat approval of the retraction as a final control point.
Should a canceled booking be restated to zero?
Use retraction when the conversion should no longer count. Restatement changes value only. Google also says a conversion restated to zero cannot be adjusted again, so zero is not a reversible holding state.
Is order ID always required?
It is required for WEBPAGE actions, for GBRAID adjustments, and when the original conversion used an order ID. Some eligible offline conversions without an order ID can be matched by GCLID and conversion time.
Does a successful API call prove policy compliance?
No. It proves only that the request met the technical processing rules reported by the API. Product eligibility, sensitive-data restrictions, privacy duties, and the clinic’s own governance require separate review.
An empty offline conversion diagnostics result in a Google Ads client account does not prove that the clinic’s import process stopped. Google returns these API summaries only when the customer ID used for the query matches the customer recently used to import the conversions. With cross-account conversion tracking, that customer may be the manager account rather than the serving client.
Trace the conversion account and import request before changing code or sending events again. Another account may contain the recent summaries. Keep diagnostics, Ads reporting, business outcomes, and conversion policy eligibility separate.
Which customer ID returns offline diagnostics?
Google’s API documentation sets a specific restriction. The customer_id supplied to a search or searchStream request must be the same customer recently used to import conversions. A query under another linked account does not inherit the summaries merely because the login can access both accounts.
The credential path answers who may issue the request. The customer ID selects the account resource being queried. Access to a manager and its clients does not combine their diagnostics.
The API exposes an account-level resource, offline_conversion_upload_client_summary, and a conversion-action resource, offline_conversion_upload_conversion_action_summary. The second narrows the view to one action. Both use the same customer scope.
Why can cross-account tracking leave the client account empty?
Cross-account conversion tracking lets a manager create conversion actions and share them with managed accounts. Google shows the selected conversion account in the managed account settings. A client can use its own account-specific actions or a manager’s cross-account actions, but it cannot use both arrangements at the same time.
When the manager is the conversion customer used for the import, a search under the serving client may return no offline diagnostics. Google’s developer guide gives this exact example and directs the operator to send the diagnostic query with the manager account’s customer ID.
Do not respond by copying the conversion action into the client. That changes ownership and can change campaign goal behavior. Google warns that switching between client and manager conversion accounts can affect which default goals campaigns use. Diagnose the existing arrangement before proposing a migration.
Operational inference: record three IDs in the incident note: the serving account, the selected Google Ads conversion account, and the customer used by the import request. If those values are not documented, retrieve configuration evidence first. Do not guess from the account name.
What should a valid summary contain?
The account-level summary reports a status plus total, successful, and pending event counts. It also includes alerts grouped by offline conversion error. Google says these top-level fields cover the most recent full calendar day of imports, so they are not a permanent ledger of everything the clinic has ever sent.
The resource also contains daily and job summaries. Daily summaries give successful, failed, and pending counts for the last seven days. Job summaries cover the seven most recent import requests, grouped by job_id. Rows are separate for import clients such as the API and web interface.
Pending events need time. Google’s documentation says they may take up to 24 hours to complete. A pending count inside the correct account is therefore a different condition from an empty result under the wrong account. Preserve those states instead of turning both into a generic “missing conversions” alert.
The offline conversion outbox reporting guide describes the local evidence that should sit beside Google’s aggregate diagnostics. A local event ledger and Google’s account summary answer different questions. Neither should expose clinic payloads to make troubleshooting easier.
Can the import client create another false lead?
Yes. Google returns separate summary rows for different import clients. Recent imports through the API and the web interface can therefore appear under different client values. Looking only at one row may make the other path seem inactive.
A NO_RECENT_UPLOADS status for the API client can indicate that the API process stopped recently. It does not say that no one imported through another supported client. Compare the expected sender with the client field, last upload time, daily summaries, and job summaries before assigning a cause.
Operational inference: monitor the expected customer ID, conversion action, and import client. Accepting any recent row can hide a stopped integration behind a manual upload. Querying only the child can report failure while the manager holds the data.
Keep this monitoring tenant specific. A manager may serve several clients, but a successful row for one conversion action is not evidence for another clinic. Use account and action identifiers, not patient details, to bind each check to the intended tenant.
What is the safest troubleshooting sequence?
Start with read-only evidence. The goal is to locate the summary, not to produce another upload. Another request does not correct a diagnostic query aimed at the wrong customer and makes the timeline harder to interpret.
Record the serving client account and the affected conversion action.
Check the Google Ads Conversion Account setting for that client.
Identify the customer ID used by the recent import process.
Query the account-level summary under that same customer ID.
Query the conversion-action summary for the exact action.
Compare the returned import client with the expected sender.
Inspect alerts, daily summaries, job summaries, and pending counts.
Wait for pending processing where applicable before escalating.
If the manager query returns the expected summary, the empty client result has been explained by scope. If neither account returns a row, check whether the customer ID, conversion action, import client, and recent time window are correct. Only then investigate the sender process.
Do not change goals, move conversion actions, or upload another event solely to make a diagnostic query return data. Those actions alter system state and answer a different question. The smallest safe correction may be changing the monitoring query to use the existing import customer.
What does an empty diagnostic result fail to prove?
An empty result does not prove that no request reached Google. It may reflect the wrong customer, action, client, or recent-history window. Use request records and the approved local ledger to establish transport history.
It also does not prove that a conversion appeared in Google Ads reporting. Diagnostics describe import health. Reporting depends on other processing and attribution behavior. The article on what an Enhanced Conversions for Leads audit can prove separates request acceptance, diagnostics, reporting, and business effect.
Finally, a nonempty result is not proof of a booking or an attended appointment. Counts in an import summary concern processed events. The clinic’s operational system remains responsible for the meaning and status of an appointment, while Ads reports its own configured conversion actions.
The same distinction applies to columns. A conversion can be present in All conversions but absent from Conversions because of goal and action settings. That reporting configuration is separate from whether the diagnostic summary exists.
How is diagnostics scope different from conversion policy eligibility?
The two manifest sources explain diagnostic retrieval and cross-account conversion tracking. They do not determine whether a clinic may upload a particular event or data field. Finding the correct manager summary establishes where Google exposed recent import health. It does not grant permission to send healthcare data.
Run eligibility review before implementation and whenever the event, destination, data fields, consent path, or campaign changes. Keep medical conditions, treatment details, appointment notes, patient identifiers, and clinical free text out of diagnostic logs. If the proposed conversion is not approved for the selected Google product and applicable obligations, stop the upload path even if the API configuration works.
Policy boundary: diagnostics answer whether Google reports recent processing information for a scoped import. Eligibility answers whether the organization may collect and send that event to that destination. Evidence for the first question cannot answer the second.
This distinction also prevents a dangerous shortcut. An operator should not move an ineligible event to another account, rename it, or hash its fields to make the diagnostic problem disappear. Account scope changes visibility and ownership. It does not change the underlying data or its permitted use.
What evidence should the operator retain?
Keep the serving, conversion, and import customer IDs, plus action ID, import client, query time, status, counts, alerts, and relevant job IDs. Record whether the query returned no row, zero counts, or pending counts.
Do not retain raw payloads in the incident report. Use opaque local event references where correlation is necessary. Restrict access to account configuration and diagnostic evidence, and remove screenshots that expose unrelated clients in a manager account.
Operational inference: close the scope diagnosis only after the same documented query can be repeated under the correct customer and returns the expected recent summary or a clearly explained no-data state. Close reporting and eligibility reviews under their own acceptance criteria.
Frequently asked questions
Does an empty client-account query mean imports stopped?
No. Under cross-account conversion tracking, the manager used for imports may contain the diagnostics. Query the customer ID used by the import before investigating the sender.
Can I retrieve manager diagnostics while querying the child customer ID?
Google’s restriction says the query customer must match the customer recently used for imports. Access to both accounts does not make their diagnostic resources interchangeable.
Should I resend the conversion to create a diagnostic row?
No. First inspect local request evidence, account scope, import client, and pending state. Another upload does not fix a query aimed at the wrong customer.
Do healthy diagnostics make a clinic conversion eligible?
No. Diagnostics describe recent import processing within a Google Ads account scope. Policy, privacy, consent, contractual, and healthcare eligibility require a separate review of the actual event and data.
A clinic event request can pass with validateOnly=true and still produce no conversion because Google validates the request without executing it. That response is a dry-run result. It does not ingest the event, start destination processing, create diagnostics, or establish that Google Ads will report a conversion.
Move to a real submission deliberately. Keep the approved test fixture, send a separate request with validation-only mode disabled, capture the new control evidence, and follow diagnostics and Ads reporting as separate stages. Technical validation also says nothing about whether a healthcare event is eligible for an advertising destination.
What did the successful validateOnly response actually prove?
It proved that Google accepted the request for validation and did not return a blocking validation error at that gate. The Data Manager API reference states that when validateOnly is true, the request is validated but not executed. No changes are applied. That is the whole promise.
This mode is useful before a release because it can reveal request problems without applying the event. It is not a preview of a future conversion row. A valid shape can still be ineligible for the selected advertising use, fail later processing after a real submission, or never meet the reporting conditions of a conversion action.
Do not label the dry run as sent, uploaded, delivered, or converted. Use a state such as validation passed. The distinction should also appear in the server-side Data Manager architecture for clinic forms, so dashboards cannot combine a test with actual outbound work.
How do validation, execution, diagnostics, and reporting differ?
Validation checks the submitted request without applying its changes when validation-only mode is enabled. Execution begins only when the integration sends a real request. Diagnostics describe downstream processing for eligible successful requests. Reporting is the later Google Ads outcome. Each stage answers a different operational question.
A clean validation response answers, “Did this dry-run request pass the checks applied at this gate?” A real ingestion response answers, “Did Google accept this request for execution?” Diagnostics answer, “What happened while the named destinations processed it?” Google Ads reporting answers whether a corresponding conversion became visible under that product’s settings and attribution rules.
These stages should have separate timestamps and statuses. If a team uses one green badge called API success, a dry run can look identical to an executed request. That is how a technically accurate response becomes an operationally false success.
Why are there no diagnostics for the validation-only request?
Google’s diagnostics guide excludes requests sent with validate_only=true. Diagnostics exist for requests that succeeded and were actually submitted for processing. A dry run creates no destination work to follow, so repeatedly querying diagnostics cannot turn it into an executed event.
This absence is expected behavior, not evidence that the diagnostics service is delayed. Check the original outbound control record. If the flag was true, stop waiting for a downstream result. Correct any issues found during validation, then create a separate real request under the approved release path.
Do not reuse the dry-run state as proof for the real call. The executed request needs its own response and identifiers. If a library, job runner, or deployment environment sets validation-only mode by default, make that setting visible in the release checklist. An invisible default is easy to leave enabled.
Compare this case with a fast-fail Data Manager request. Fast-fail rejects the request because validation found a blocking error. Validation-only success intentionally stops before execution even though the validation gate passed.
How should the team move from dry run to real submission?
Start with the exact request builder and synthetic fixture that passed validation. Review the outbound configuration, then send a new request with validateOnly false or omitted. Treat this as a separate operation. Record its time, environment, destination, sender version, response status, and request identifier when provided.
Confirm that the event type and destination passed the clinic’s policy review.
Use synthetic data that contains no patient identity, contact detail, appointment note, treatment, or free text.
Run the validation-only request and resolve any returned errors.
Check the release configuration that controls validation-only mode.
Send a separate real request with the flag disabled.
Inspect the real response, including warnings rather than only its HTTP status.
Follow the executed request through diagnostics when available.
Check Google Ads reporting under the correct action, goal, and date interpretation.
Do not mutate a failed source record merely to make it pass. Fix the serializer or approved mapping at its source, rerun the synthetic check, and rebuild the outbound request. A production event should not be repaired by adding health-related values that the destination never needed.
What evidence belongs in the outbox and monitoring logs?
Keep control evidence, not event contents. Useful fields include operation type, validation-only state, sender version, destination, attempt time, response class, warning codes, request identifier, diagnostic state, and final reporting reconciliation. That record lets an operator distinguish dry run, execution, processing, and reporting without opening the payload.
Do not paste request bodies into logs, tickets, chat, or screenshots. Avoid names, email addresses, phone numbers, appointment times tied to a person, visit reasons, treatment details, and free text. Synthetic fixtures should be visibly artificial and isolated from real schedules or CRM records.
An offline conversion outbox report can expose these technical stages to agencies and clinic operators. It should never imply that a request was delivered simply because validation passed. A useful report makes the missing execution step obvious.
Keep retry controls separate too. A dry run should not enter the delivery retry queue because it did not attempt delivery. A real request with a client error needs correction before retry. A request accepted for processing follows the diagnostic path instead.
Why is policy eligibility separate from API validation?
Data Manager validates the technical request contract. It does not issue legal advice or decide that a clinic may use a particular event for advertising. A request can be structurally valid while the event remains disallowed, unapproved, excessive, or unsuitable for the chosen destination.
Place the eligibility decision before serialization. Define which generic events may leave the clinic system, which destination may receive them, and what fields are permitted. If that review has not approved the event, do not use validateOnly as a safe harbor. Even a dry run sends a request to an external API.
Hashing does not convert an ineligible clinic event into an eligible one. The article on why hashing does not establish eligibility explains that technical transformation and permission are different questions.
Document the policy gate outside the transport code, then enforce it in the live call path. Validation tests the format of an event that has already cleared that gate. It must never become the process that decides whether sensitive clinic data can be sent.
How do you troubleshoot “passed but no conversion” without guessing?
Read the actual outbound record first. Confirm whether validateOnly was true. If it was, the immediate cause is complete: the request was not executed. Do not spend time changing attribution windows, goals, or tags until a real request exists.
If the flag was false or omitted, move to the next evidence layer. Inspect the real response, then diagnostics for that request. Only after destination processing should the team reconcile Google Ads reporting. Keep conversion action, account, goal inclusion, and reporting date in scope, but do not use those settings to explain a request that never executed.
Check every place that can set the flag: configuration, environment variables, request wrapper, test harness, scheduled job, and retry path. One wrapper may force validation-only mode even when application code asks for a real submission. Prove the value at the final API call without logging the event body.
End the incident with a focused regression check. It should show that a dry run remains nonexecuting and that the approved real path disables the flag. Keep the test synthetic. The goal is to prove control behavior, not create a clinic conversion for a real person.
Frequently asked questions
Does HTTP 200 on validateOnly mean the event was ingested?
No. With validation-only mode enabled, Google validates the request but does not execute it. The response can be successful while no event is ingested and no conversion can result from that call.
Can I retrieve diagnostics for the dry-run request?
No. Google’s diagnostics guidance excludes requests sent with validate_only=true. Send a separate real request after approval and use the evidence from that executed operation.
Should the production request reuse the dry-run result?
No. It may reuse the reviewed request builder and synthetic test logic, but the real submission is a new operation. Capture its own response, request identifier, diagnostics, and reporting outcome.
Does passing validation prove the clinic event is allowed in Google Ads?
No. Validation checks the API request, not legal permission or product-policy eligibility. Complete those reviews before the event enters the outbound pipeline, then test only the approved generic data contract.
A clinic booking conversion can appear in All conversions but be missing from Conversions because the action is secondary, or because the campaign is not using the goal that contains that primary action. Secondary actions normally remain observation-only. Primary actions influence a campaign only when that campaign optimizes toward their associated goal.
There is an important exception: a secondary action included in a selected custom goal is used for bidding. Audit both conversion action optimization and campaign goal settings before changing the signal. Do not treat column membership as proof that a booking occurred, that the event is eligible for healthcare advertising, or that the campaign should optimize toward it.
What do Conversions and All conversions include?
The main Conversions column is the focused reporting and bidding view. Google describes primary actions as actions reported there and used for bidding when the standard goal they belong to is used for bidding. All conversions is broader. It includes the data in Conversions plus actions that were not included in that main column and certain other conversion sources.
That design lets an account observe useful actions without asking Smart Bidding to optimize toward every tracked signal. A booking-related action in All conversions is therefore not automatically missing or broken. It may be working exactly as configured as a secondary observation.
Segment All conversions by conversion action before diagnosing the total. A combined number can contain signals with different meanings and optimization settings. Compare the named action across columns, then inspect its goal and campaign scope.
This semantic discipline matters in a clinic booking outcome taxonomy. A form submission, booking request, confirmed slot, and later operational outcome should not share one vague label simply because they all appear in an advertising report.
How do primary and secondary actions behave?
A primary conversion action is eligible for the main Conversions reporting and bidding path, subject to the campaign’s goal selection. A secondary action is normally observation-only. Google reports it in All conversions and does not use it for bidding even when its standard goal is used.
Check the action itself in the conversion summary. The setting is commonly presented as Primary or Secondary, with secondary described as observe only. Do not infer it from the action name. Two actions called booking can have different optimization settings, owners, sources, or goals.
Imports from Google Analytics are secondary by default when created, according to Google’s current guidance, and the setting can be updated to primary in Google Ads when the action supports that change. That is one plausible reason a newly imported action appears in All conversions first. Verify the actual source and setting instead of assuming that explanation applies.
Why can a primary action still be absent from campaign Conversions?
Primary is necessary but not sufficient. Google states that a campaign uses a conversion action for bidding when two conditions are met: the action is Primary, and the campaign uses the goal that contains it. A primary action under a goal the campaign does not optimize toward will not drive that campaign.
Campaigns can use account-default goals or campaign-specific goals. This means a conversion configuration can look correct at account level while a particular campaign follows a different goal set. Audit the affected campaign rather than extrapolating from another campaign that shows the action in Conversions.
Build a small evidence matrix with the action name, action source, primary or secondary setting, containing goal, account-default status, campaign goal selection, and observed columns. This separates configuration facts from assumptions. Do not include contact details, appointment notes, treatment information, or event payloads in that matrix.
How does the custom goal exception change the answer?
Custom goals can contain a combination of primary and secondary conversion actions. Google states that conversion actions inside a custom goal are used for reporting and bidding regardless of whether each action is labeled primary or secondary. Its conversion-goals documentation also warns that a secondary action included in a custom goal is used for bidding when that custom goal is set in campaign settings.
This exception is easy to miss. An operator may mark an action Secondary expecting observation-only behavior, then add it to a custom goal selected by a campaign. The action can become a bidding input even though the action page still says Secondary.
Therefore, an audit cannot stop at the action-level setting. Open the campaign, identify whether it uses account-default goals, campaign-specific standard goals, or a custom goal, and inspect every action inside the selected goal. Record the current state before editing it.
Do not use a custom goal merely to force a column to look complete. Custom goals change what the campaign optimizes toward. They should reflect an approved measurement design, not serve as a reporting workaround.
What is the safest troubleshooting sequence?
Begin with the exact campaign, date range, and conversion action. Add both Conversions and All conversions, then segment by conversion action. Confirm that the discrepancy belongs to the booking action rather than a broader aggregate.
Record the conversion action’s exact name, source, and status.
Check whether action optimization is Primary or Secondary.
Identify the standard goal containing the action.
Check whether the campaign uses account-default or campaign-specific goals.
Confirm whether the associated standard goal is selected.
Inspect any selected custom goal and every action it contains.
Compare action-level results in Conversions and All conversions.
Document the finding before changing reporting or bidding configuration.
If the action is secondary and no selected custom goal contains it, appearing only in All conversions is expected. If it is primary but the campaign does not use the associated goal, the campaign will not optimize toward it. If a selected custom goal includes it, the custom-goal exception applies.
Do not delete and recreate the action as a first response. That can fragment history and introduce another source or ownership problem. Fix the smallest incorrect setting after confirming the intended campaign behavior.
What should be checked before changing Smart Bidding inputs?
First ask whether the event means what the team thinks it means. A conversion labeled booking might be a form submit, a scheduling-page visit, or an actual slot creation. Validate the trigger and deduplication path with synthetic tests. Preserve the operational result in the clinic’s system of record.
Then review data quality and volume over an appropriate window. A signal that arrives late, duplicates, changes definition, or mixes locations can mislead bidding even if it appears in the desired column. The audit proof limits for Enhanced Conversions for Leads show why a successful diagnostic should not be expanded into a claim about business accuracy.
Finally, obtain the campaign owner’s approval for an optimization change. Moving an action from secondary to primary, selecting a new standard goal, or adding it to a custom goal can change bid decisions. Reporting convenience is not enough reason.
Keep the old configuration, change time, approver, intended effect, and rollback condition in the account change record. Monitor the named action and the business outcome separately after the change.
Why are reporting, bidding, and eligibility separate boundaries?
Conversions and All conversions describe Google Ads reporting and optimization configuration. They do not decide whether a clinic may collect an event, disclose it, or use it in advertising. A technically tracked action can still be inappropriate for the selected customer data feature or destination.
Run the eligibility review before configuring the action as a bidding input. Google’s health and customer-data policies, contracts, consent or other lawful basis where applicable, and the clinic’s privacy controls need their own evidence. Do not send patient identifiers, treatment details, appointment notes, or clinical free text merely because the interface offers a conversion action.
The page on hashing and clinic-form eligibility explains this policy boundary. Hashing is a technical transformation. It does not turn an otherwise ineligible event into an eligible one.
Keep three conclusions separate in the audit: the action is being received, the campaign is or is not optimizing toward it, and the event is or is not approved for that use. Evidence for one conclusion cannot substitute for the others.
Frequently asked questions
Is a conversion broken if it appears only in All conversions?
No. It may be a correctly tracked secondary action intended for observation. Check the action optimization setting and the campaign’s selected goals before treating it as a tracking failure.
Does setting the booking action to Primary make every campaign bid on it?
No. A campaign must also optimize toward the goal containing that primary action. Campaign-specific goal settings can differ from account-default goals.
Can a Secondary action affect bidding?
Yes. Google documents an exception when the secondary action is included in a custom goal selected by the campaign. Inspect custom-goal membership before calling any action observation-only.
Is Primary versus Secondary the same as One versus Every?
No. Primary versus Secondary controls reporting and optimization behavior. One versus Every controls how conversions are counted after an eligible interaction. Audit them as separate settings.
One invalid clinic event can reject the entire Google Data Manager API request because the API uses fast-fail validation. If the request has a structural error, or any record fails validation for a required field, Google rejects the request and processes none of its data. Read the structured Status details, correct the defect, and resend the complete batch.
That synchronous failure is different from an HTTP 200 response containing field warnings, and both are different from the destination diagnostics available after successful ingestion. Keep those evidence layers separate. Also keep event payloads out of logs, tickets, and screenshots. A transport success does not establish that a healthcare event is eligible for a Google advertising product.
What does fast-fail mean for a clinic event batch?
The Data Manager API documentation draws a clear boundary. Structural errors can prevent the service from understanding a request. A missing or invalid required field in any record can also stop the request. In either case, the entire request fails and the API does not process any of the data in it.
This differs from a partial-failure model in which valid records continue while invalid records are rejected. Do not infer partial acceptance from a large batch or from the fact that most records look correct. For a synchronous fast-fail response, the unit of recovery is the complete request.
Suppose batch A contains records built by the same mapping function, and one record has a required timestamp in an invalid format. The safe conclusion is not that every other record arrived. The documented conclusion is that none were processed. Use a synthetic fixture to reproduce the shape, fix the shared mapping or source validation, and send the complete corrected batch.
This request boundary should be designed into the server-side Data Manager architecture for clinic forms. Validation before transmission reduces avoidable failures, but the sender must still treat Google’s response as authoritative.
Which error details should the integration inspect?
Start with the standard Status response. The REST error exposes a status and a corresponding HTTP code. Do not stop at the human-readable message. The structured details can identify the class of failure and the affected request field more reliably than string matching.
For an invalid argument, inspect the BadRequest payload and its fieldViolations. Each violation can identify a field and provide a description or reason. The ErrorReason reference includes terms such as INVALID_ARGUMENT, REQUIRED_FIELD_MISSING, and INVALID_FORMAT. Preserve these official values in operational logs rather than inventing a private translation that hides the original error.
ErrorInfo can add machine-readable context. RequestInfo contains the request_id that uniquely identifies the failed API request. Capture that identifier with the response code, Status, field path, reason, sender version, and batch control record. This is enough for most triage without storing the clinic event body.
The same evidence discipline applies to a broader Enhanced Conversions for Leads audit: a useful audit states exactly what a diagnostic proves and what remains outside its scope.
Why should the sender fix and resend the full batch?
Google’s guidance for a failed fast-fail request is explicit: fix the error and resend the entire request. Removing the record that triggered the visible violation may hide a defect shared by other records. It can also turn a technical validation decision into an undocumented business decision about which events deserve processing.
Trace the field back to its producer. If the same serializer supplied the field for every record, correct the serializer and rerun the preflight check. If only one upstream value violated the contract, quarantine that input from the outbound workflow under an approved rule, correct it at the source when appropriate, and rebuild the requested batch. Do not edit health-related source records merely to make an advertising request pass.
A failed request should retain a safe control state such as rejected, with a reason code and attempt metadata. It should not advance records to sent or delivered. An offline conversion outbox report can make this boundary visible to operators and clients without exposing the event payload.
Retry classification matters. Google advises correcting client errors before retrying them. Transient server errors can use exponential backoff. A retry loop that resends the same invalid argument only creates noise and may obscure the original cause.
How is an HTTP 200 field warning different?
Fast-fail validation performs a limited set of checks for basic issues that prevent further processing. Optional-field validation can behave differently. A successful ingestion response with HTTP 200 may include a field_warnings list. Those warnings do not fail the request, so the sender must examine the response rather than treating the status code as the whole result.
A warning means the request crossed the synchronous ingestion gate with a documented concern. It does not mean the field was accepted exactly as sent. Store the warning type and field reference in the batch control record, then decide whether the integration needs a mapping correction. Keep the actual field value out of the log.
Do not combine failed and warning states into a label such as uploaded with issues. A failed request processed no data. An HTTP 200 response may have accepted the request while flagging optional-field concerns. Those states lead to different recovery actions and deserve separate counters.
What do later destination diagnostics prove?
Diagnostics are available only for requests that succeeded and were not sent with validate_only set to true. The sender uses the captured request_id to retrieve request status. Each destination can progress through processing and reach SUCCESS, PARTIAL_SUCCESS, or FAILURE, with warning and error information available at the destination layer.
This later evidence does not rewrite the synchronous response. A fast-fail request has no successful ingestion to diagnose. Conversely, an HTTP 200 does not promise that every destination will finish successfully. Model the flow as distinct gates: request validation, successful ingestion, destination processing, and destination result.
An error in destination diagnostics means a record was rejected at that later stage. A warning can indicate that some portion was ignored while processing continued. The outbox reporting guide explains why agencies should expose these stages instead of collapsing them into a single upload count.
How can the team troubleshoot without logging clinic payloads?
Use two records with different purposes. The protected business system retains its own approved event data. The integration log retains only technical control evidence needed to operate the pipeline. Do not copy names, contact details, free text, appointment notes, treatment information, or full request bodies into monitoring tools.
Stop the failed batch from advancing to a delivered state.
Capture the HTTP code, Status, typed detail, field path, reason, and request_id when present.
Reproduce the request shape with synthetic data that contains no patient or contact identifiers.
Trace the invalid field through every caller of the shared mapping code.
Correct the root mapping or approved source value.
Run local required-field and format checks on the rebuilt batch.
Resend the full request and inspect field_warnings even when it returns HTTP 200.
For successful non-validation requests, follow the request_id through destination diagnostics.
Access to control logs should be limited, retained for an approved period, and reviewed for accidental payload capture. Screenshots used in support cases should show the smallest useful structured error. If Google support needs a request identifier, RequestInfo provides it without requiring a copy of every clinic event.
Why does successful transport not establish policy eligibility?
The Data Manager API error model describes whether a request can be accepted and processed technically. It does not decide whether the organization may send a particular healthcare event to a particular Google advertising destination. That question requires a separate review of Google’s product terms and customer data policies, the clinic’s data governance, and applicable law.
Hashing does not change that boundary. The article on why hashing does not make clinic forms eligible for Enhanced Conversions for Leads explains why technical transformation is not policy permission. Likewise, a destination marked SUCCESS proves processing status, not lawful collection, valid consent, or advertising eligibility.
Keep an eligibility gate before serialization. Only events already approved for the named destination should reach the batch builder. Then apply the technical controls described here. The order matters: policy eligibility determines whether an event may enter the transport path; validation and diagnostics determine what happened after an eligible event was submitted.
Frequently asked questions
Did Google process the valid records when one required field failed?
No. Under the documented fast-fail model, a structural error or required-field validation failure causes the entire request to fail, and none of its data is processed.
Should the integration delete the bad record and resend the rest?
Not as an automatic recovery step. Inspect the structured violation, correct the root cause, rebuild the request, and resend the complete batch. Any decision to exclude an event needs its own approved rule.
Does HTTP 200 mean every field and destination succeeded?
No. A successful ingestion response can contain field_warnings, and later destination diagnostics can report SUCCESS, PARTIAL_SUCCESS, or FAILURE. Check each evidence layer separately.
Can the team paste the failed clinic request into a support ticket?
Avoid it. Capture the request_id and the smallest useful structured error, reproduce with synthetic data, and follow approved disclosure procedures if additional evidence is genuinely required.
A clinic may see no Store visits conversion action in Google Ads even when patients regularly reach its physical location. Google makes this measurement available automatically only to eligible accounts. Eligibility depends on verified locations, active location assets, supported countries, sufficient ad and foot-traffic volume, and Google’s rules for sensitive locations.
For healthcare advertisers, the sensitive-location rule is especially important. Google states that locations related to certain health issues are ineligible for Store visits. More traffic or a different report column cannot override that restriction. Diagnose eligibility first, then decide which privacy-safe operational outcome the clinic can measure independently.
What does Google Ads mean by a Store visit conversion?
Store visits estimate how ad interactions influence later visits to physical locations. Google describes the reported numbers as modeled. It connects eligible ad engagement with later location activity in a privacy-safe process, then uses anonymous, aggregated statistics and extrapolation to represent a broader customer population.
This is different from a click on Directions. A Store visit represents Google’s modeled estimate of visits after eligible ad interactions. A Directions action records an interaction that helps someone find the location. Neither event identifies a patient, confirms a scheduled appointment, or records revenue from care.
The distinction matters in a clinic report. A modeled aggregate can help compare campaigns that influence physical traffic, but it cannot reconcile a reception roster. Conversely, the appointment ledger can count attended visits, but it should not send patient-level health details back to an ad platform.
Teams that need campaign-level attendance should use a separate privacy review and a bounded internal method. The guide to measuring clinic show rate without appointment details keeps operational outcomes separate from sensitive appointment data.
Which eligibility requirements should the clinic check?
Google lists several account and location requirements. The physical locations must be in a country where Store visits measurement is available. The account must use active location assets or affiliate location assets, and campaigns must be opted in to show them. Locations connected through a Business Profile must be set up and verified there.
The account also needs enough ad clicks or impressions and enough foot traffic to pass Google’s privacy thresholds. Google does not publish one universal number because the required volume varies by advertiser. A nearby clinic account with similar campaigns can qualify at a different time, so its status is not proof for another account.
Eligibility is assessed separately by network. Google says an account with multiple campaign types may report Store visits for one network but not another. At manager-account level, each child account still has to meet the requirements on its own. Manager reporting does not transfer eligibility to an ineligible clinic account.
Check the practical setup before assuming a privacy threshold is the only cause. Confirm that the intended Business Profile locations are verified, the link to Google Ads uses the right account, location assets are active, and the campaigns actually run those assets. The article on clinic location-targeting settings covers a different control and should not be used as evidence of Store visits eligibility.
Why can a healthcare location remain ineligible?
Google excludes locations it considers sensitive. Its examples include locations related to religion, sexual interests, children, and certain health issues. This is an eligibility boundary for Store visits, not a technical error the clinic can repair by changing a tag, increasing a bid, or requesting patient records.
The source does not define every healthcare category that Google will classify as sensitive. Do not infer that all clinics qualify or that all clinics fail. Read the account’s actual state and request platform support if the location seems eligible under the published criteria. Describe the business and setup without sending patient names, diagnoses, appointment records, or visit histories.
Editorial inference: a clinic should not rename, recategorize, or misrepresent a location to obtain Store visits reporting. Business Profile and ad assets should describe the real organization. A measurement feature is not worth introducing inaccurate public information or undermining a platform privacy control.
A Google Cloud healthcare agreement does not change this Ads rule. Google Ads and Google Cloud have separate product terms and data boundaries. See why a Google Cloud BAA does not cover Google Ads before treating an infrastructure contract as advertising permission.
Where should the team look for diagnostics?
If the account already has an active Store visits conversion action, open its Diagnostics page from the Goals summary. Google says this page reports current status, linked locations, campaigns running location assets, location verification, data thresholds, conversion-tracking setup, and whether a custom conversion value exists.
The Diagnostics page is unavailable when the account does not have the Store visits conversion action. That absence is itself a boundary. The team should review eligibility and contact its Google representative if it believes every requirement is met. Creating a website conversion with the same name will not create Google’s modeled Store visits measurement.
Capture diagnostics as account-level evidence. Record the review date, affected network, status, whether locations are linked, number of campaigns running location assets, percentage of verified locations, and whether the data-threshold check passes. Do not attach screenshots showing user lists, search terms tied to health concerns, customer uploads, or unrelated account secrets.
Apointoo can surface this eligibility state as a reporting note. It should not present “not eligible” as “zero visits,” because those statements mean different things. One describes unavailable measurement. The other claims a measured count of none.
Could Store visits exist but be missing from the report?
Yes. Google says Store visits are reported under All conversions by default. The standard Conversions column includes them when the Store visits goal is configured as an account-default goal. Store-visit-specific columns are not included in every report by default, so a column choice can hide existing data.
First look for the conversion action, then add the Store visits and All conversions columns at the campaign level. Check the same network and date range used in Diagnostics. Do not compare a manager total with one child account without confirming where conversion tracking is configured and how Google deduplicates visits across child accounts.
Google also says reporting can fluctuate or stop after customer-behavior changes or account-setup changes. Business Profile edits, location assets, conversion status, conversion window, and location targeting can affect results. Use the Diagnostics page to distinguish a setup issue from a seasonal change rather than explaining every drop as campaign performance.
Operational inference: annotate the date of any location-asset, Business Profile, conversion-goal, or tracking-account change in the clinic’s reporting ledger. The official sources list those settings as possible causes, but only a dated record can show which change preceded the local account’s reporting shift.
What should the clinic use when Store visits are unavailable?
Do not relabel Directions clicks, call clicks, website clicks, or booked appointments as Store visits. Each event answers a different question. Local actions can show engagement with a location. The scheduling system can show appointments. Reception or the EHR can show attendance under the clinic’s approved controls.
Build a small measurement ladder. Report ad delivery and clicks first. Report local actions with their platform definition. Report privacy-safe booking outcomes only where the clinic has a lawful and technically bounded path. Keep attended visits and revenue in the internal system unless a separately reviewed aggregation or conversion workflow allows a narrower signal.
When comparing acquisition channels, preserve marketing source independently from booking and attendance states. Appointment source and marketing source are not interchangeable, and neither becomes more accurate because Store visits reporting is missing.
For bidding, use only conversion actions whose meaning the team can defend. If a campaign optimizes toward calls or directions, label those actions exactly. Do not assign them an attended-visit value merely to fill an eligibility gap. A modeled feature’s absence is a measurement limitation, not permission to invent a substitute.
How should Store visits appear in a clinic report?
State the metric as “Google Ads modeled Store visits” and include the reporting window, eligible network, account, and source column. Add an eligibility note when the action is unavailable. Keep modeled visits separate from booked appointments, attended appointments, new patients, treatments, and revenue.
When Store visits are available, avoid patient-level reconciliation. The official method is aggregate and privacy centered. A mismatch between the modeled number and reception count does not reveal which person Google counted. It also does not prove either system is wrong, because the two measures have different definitions and attribution windows.
Use the metric for decisions that fit its scope, such as comparing eligible campaigns on modeled physical-visit influence. Use internal operational data for staffing, capacity, and care delivery. The framework for booking outcome definitions in Google Ads helps prevent one label from carrying several incompatible meanings.
Frequently asked questions
Can I manually enable Store visits for a clinic?
No manual tag creates this conversion action. Google says eligible accounts begin reporting automatically. If the action is absent, check country availability, location sensitivity, verified locations, active location assets, campaign use, and sufficient ad and foot-traffic volume.
Does no Store visits data mean nobody visited?
No. Missing data may mean the account is ineligible, has not passed privacy thresholds, lacks the correct setup, or is viewing the wrong columns. It is not a measured count of zero and should not be reported as one.
Can a Directions click replace a Store visit conversion?
No. Directions is a local engagement action, while Store visits is Google’s modeled estimate of physical visits after eligible ad interactions. A Directions click does not prove arrival, appointment completion, or revenue.
Should patient attendance records be uploaded to fix eligibility?
No. The published Store visits eligibility process does not instruct clinics to upload patient attendance or health information. Review the account and location requirements, use Diagnostics when available, and keep identifiable or sensitive care data out of Ads.
A Google Ads data exclusion can protect Smart Bidding from a verified conversion-tracking outage. It does not repair the tag, restore missing clinic records, or remove data from reports. The exclusion tells eligible bidding strategies to disregard affected click data when learning and setting bids.
The date range must follow clicks, not only the hours when conversions stopped arriving. Include earlier clicks whose conversions would normally have appeared during the outage. Apply the narrowest accurate campaign and device scope, preserve the incident evidence, and treat reporting backfill as a separate decision.
When does a clinic conversion outage qualify?
Google recommends data exclusions for conversion-data outages, including broken tracking, an incorrectly placed tag, a website outage, or a temporary failure to upload offline conversions. In each case, inaccurate conversion or conversion-value data could distort conversion-based Smart Bidding.
A sudden decline in appointments does not qualify by itself. Neither does a holiday, a normal change in demand, a small sample, or a disputed lead-quality definition. First prove that the measurement system reported incorrect data for a bounded period.
Keep the incident proof outside Google Ads: alert time, affected conversion actions, first bad observation, last known good event, repair time, missing or inflated records, affected devices, and affected campaigns. The conversion audit proof guide helps separate configuration, processing, reporting, and attribution evidence.
What does a data exclusion change?
A data exclusion changes the conversion and conversion-value data that Smart Bidding uses. Google says the tool is available only for conversion-based and value-based Smart Bidding strategies. It supports Search, Display, Shopping, and Performance Max campaigns, while Hotel and Travel campaigns are not supported.
The exclusion does not alter the Conversions columns or erase affected events from reports. Google states that excluded conversions remain visible in reporting. A report can therefore show conversions from the period even though Smart Bidding no longer uses the associated click data.
Describe the action accurately in an incident log: “Excluded affected clicks from Smart Bidding inputs.” Do not write “deleted bad conversions,” “fixed reporting,” or “restored attribution.” Those outcomes are outside what the feature does.
Why must the date range follow clicks and conversion delay?
Google applies data exclusions to clicks. When a click is excluded, conversions associated with it are also excluded from Smart Bidding. A conversion recorded during an outage may belong to a click from an earlier day, so selecting only the visible outage dates can miss affected learning data.
Measure the normal delay between click and reported conversion for the affected action. Then move the exclusion start back far enough to cover clicks whose conversions would have arrived during the broken period. Google recommends covering at least 90% of clicks associated with the affected conversion data.
Google gives a concrete example: if uploads failed from October 15 through October 18 and the conversion delay is five days, the exclusion should cover clicks from October 10 through October 18. Use the clinic account’s observed delay and incident window instead of copying the example dates.
The clinic funnel report by original lead cohort provides a related reporting principle. Later outcomes belong to the acquisition cohort that produced them. The exclusion uses the same temporal discipline because bidding connects reported conversions back to clicks.
How narrow should the exclusion scope be?
Scope should match the proven fault. Google’s setup allows selection of campaigns and devices, or an account-wide exclusion when the evidence supports it. Exclusions can be applied at manager-account or sub-account level. Start and end times use the account’s time zone.
Incident evidence
Candidate scope
Do not assume
One mobile tag failed
Affected campaigns and mobile devices
Desktop data was also wrong
One campaign used a broken page
That campaign and proven dates
Every account campaign was affected
Account-wide import stopped
Campaigns using the affected imported action
Unrelated conversion actions failed
Scope remains unknown
Continue investigation
A broad exclusion is safer
A broad exclusion discards more learning data. A narrow exclusion that misses affected clicks leaves bad data in the bidder. Choose the smallest scope supported by incident evidence, which may not be the smallest selectable option.
How should the team apply the exclusion?
Google’s current workflow places data exclusions under Adjustments in Google Ads. Before creating one, record the exact dates, times, time zone, campaigns, devices, conversion actions, and delay assumption. Google warns that exclusions can change bid-strategy performance, so the final review should happen before creation.
Confirm the conversion data is wrong and identify the root measurement fault.
Repair or contain the fault so the outage has a defensible end.
Measure the normal click-to-conversion delay for the affected action.
Translate the outage into an affected click-date range.
Select only the proven campaigns and devices.
Verify the account time zone and manager or sub-account scope.
Save the evidence and approval before creating the exclusion.
Monitor bidding and spend while the strategy stabilizes.
Apply the exclusion quickly once the scope is known. Google says planned outages can be configured in advance and typically take effect within a day. Do not use that guidance to guess at an uncertain incident. A wrong future window still sends the bidder inaccurate instructions.
What happens after the exclusion is applied?
Google advises against removing a data exclusion after application. Past-date exclusions should begin to stabilize after a few days, but an outage affecting a week or more of clicks can produce fluctuations for one or two conversion cycles.
Watch spend, bids, conversion volume, and conversion value without declaring immediate recovery. Google notes that bids and spending can fall temporarily. It also suggests keeping budgets near historical spend for a few cycles and adjusting CPA or ROAS targets when necessary. Any such change needs its own approval and rollback rule.
The value-based bidding readiness checklist explains why delay, mature observation windows, goals, and data quality still matter after the platform accepts a setting. An exclusion reduces one source of bad learning data. It does not make the remaining conversion feed accurate.
Should missing conversions be backfilled?
Google generally advises against backfilling data after an outage because late conversions can affect Search and Shopping bidding performance. If a data exclusion was applied, Google allows a reporting-only backfill after waiting at least five days. It says not to remove the exclusion.
Keep the two purposes separate. The exclusion protects bidding from affected clicks. A backfill may restore reporting completeness. It does not reverse the exclusion or recreate the learning sequence that would have existed if tracking had worked on time.
Before any backfill, reconcile source records, remove duplicates, preserve original conversion times, and document why reporting needs the late events. The offline conversion outbox report shows how to keep local event state, Google request state, Ads reporting, and attribution in separate evidence layers.
What should the incident record contain?
A useful record lets another operator reconstruct the decision without reading patient or appointment data. Include the incident ID, detection time, root cause, repair time, affected conversion actions, account time zone, measured delay, click-date range, campaign and device scope, approval, exclusion identifier, and monitoring window.
Record explicit non-claims as well:
the exclusion did not change Ads reporting;
the exclusion did not repair the source tracking system;
the exclusion did not prove attribution or business recovery;
any backfill was reporting-only and happened after the documented wait;
patient details and clinical data were not included in the incident artifact.
Review the incident after one or two observed conversion cycles when the affected period was long. Retire temporary target or budget adjustments through a separate approved decision. Do not remove the data exclusion to make a dashboard look consistent.
Frequently asked questions
Do data exclusions remove conversions from reports?
No. Google says data exclusions affect the data used by Smart Bidding, not conversion reporting. The excluded period can remain visible in the account’s conversion columns.
Should the exclusion cover conversion dates or click dates?
Use affected click dates. Extend the start date to account for normal conversion delay, because conversions reported during the outage may be attributed to earlier clicks.
Can the team remove an exclusion after fixing the data?
Google advises against removing an applied exclusion. Preserve it, document the repair separately, and let the strategy stabilize on accurate post-incident data.
Can missing conversions be uploaded later?
Google generally discourages backfills. When an exclusion was applied, a reporting-only backfill can occur after at least five days, without removing the exclusion. Review duplicates and original times first.
