apointoo.
Request access
Google Ads for Healthcare

Why Did a validateOnly Clinic Event Request Pass but No Conversion Appear?

cmsapointoo··9 min read

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.

The same evidence discipline appears in the guide to what an Enhanced Conversions for Leads audit can prove. A useful status describes its boundary, not the outcome an operator hoped to see.

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.

  1. Confirm that the event type and destination passed the clinic’s policy review.
  2. Use synthetic data that contains no patient identity, contact detail, appointment note, treatment, or free text.
  3. Run the validation-only request and resolve any returned errors.
  4. Check the release configuration that controls validation-only mode.
  5. Send a separate real request with the flag disabled.
  6. Inspect the real response, including warnings rather than only its HTTP status.
  7. Follow the executed request through diagnostics when available.
  8. 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.

References

Related articles