apointoo.
Request access
HIPAA

What a Generic Offline Conversion Payload Can Contain

cmsapointoo··8 min read

A generic offline conversion payload should contain only the approved click signal, generic action, event time, approved value and currency, and an opaque deduplication reference. That shape is a technical minimum, not an automatic permission to upload a health-related booking outcome. Tenant-specific legal review and current Google policy review must approve the exact purpose, destination, and fields before a queue can send anything.

Keep the source booking record separate from the outbound event. The booking system can remain the operational authority while a narrow conversion worker receives a derived event. The worker should reject names, email addresses, phone numbers, hashed identifiers, service or treatment details, and free-text notes. A hash does not make an identity field safe by itself.

What belongs in a generic payload

The Google Ads API documentation describes offline conversion workflows and the sample shows common fields such as a click identifier, conversion action, conversion date and time, value, currency, and order identifier. For a healthcare booking integration, the implementation should select only the subset approved for the tenant and destination. The presence of a field in an API does not authorize its use.

Field class Use Boundary
Click signal Connects an approved interaction to a campaign Review linkage and retention
Generic action Names an approved measurement event No service or treatment label
Event time Orders the conversion Use only the precision needed
Value and currency Measures approved business value Document calculation and consent basis
Opaque dedupe reference Prevents repeat upload Must not encode a person or clinical detail

Use a schema that rejects additional properties. This is stronger than a serializer that ignores unknown values because it stops a caller from silently expanding the payload. Validate tenant identity and destination server-side. Browser-supplied tenant, policy, or region values cannot authorize an outbound action.

The safest local record contains the event reference, allowlist result, approval version, delivery status, attempt count, and provider response code. It does not need the full booking message. Store a reference to the source event only when the retention and access path are approved.

Why a click signal is not a blank check

A click identifier can look opaque while remaining connected to a person’s interaction with a service. The risk comes from linkage and context. If an event describes a completed health appointment, an observer may infer sensitive information from timing, action name, campaign, or account context even when no name is attached.

Google’s Customer Data Policies say conversion information related to sensitive categories cannot be used for enhanced conversions or store sales uploads. The policy also identifies health or medical information, including medical services, as sensitive. Therefore, a proposed payload must be reviewed as a complete event and destination, not approved because it contains no obvious contact field.

Separate three questions:

  1. Technical: can the API accept the field combination?
  2. Platform: does the current Google product policy permit this use?
  3. Legal and contractual: can this tenant disclose the event for this purpose?

Only a positive answer to all three supports activation. If one is unknown, stop the route and use internal aggregate reporting. The Google Ads health conversion policy article provides the policy classification gate.

How to build an allowlist and rejection path

Define the payload as a small value object with required fields, permitted types, and bounded lengths. Reject nulls, unexpected keys, invalid timestamps, unsupported currency codes, and values outside the approved range. Do not coerce arbitrary strings into a generic action. A conversion name must be selected from a fixed, reviewed set.

source event verified
  -> tenant approval active
  -> destination policy version accepted
  -> consent state permitted
  -> exact fields allowlisted
  -> one primary source confirmed
  -> outbound event queued
  -> delivery result recorded

A rejected event should produce an operational reason code such as approval_missing, policy_expired, field_not_allowed, consent_unavailable, or duplicate_reference. It should not include the rejected payload in logs. The queue must not retry a policy or validation rejection as though it were a network failure.

Use an outbox or equivalent durable queue only after the allowlist gate passes. If the booking status is written locally and the worker crashes before sending, the approved event can be retried. If the event is rejected, there is no approved outbound intent to retry. This distinction keeps technical reliability from overriding a privacy decision.

How to handle value, time, and deduplication

Document how a generic value is calculated. It might be a fixed approved value or a permitted aggregate amount, but it should not encode the price of a treatment or disclose a clinical category unless counsel and policy review expressly approve that context. Use the least precise time that still supports the approved measurement goal.

Deduplicate with an opaque event reference that is stable across retries. Keep the reference separate from a patient record identifier. A duplicate upload is a reporting problem, while a reused identifier can become a linkage problem. Store terminal result, provider response, and timestamp so a reviewer can distinguish accepted, rejected, and unknown outcomes.

Delivery state Action Retry rule
Accepted Mark terminal and do not resend No automatic retry
Duplicate Reconcile existing result No new side effect
Temporary failure Keep approved event in bounded queue Retry with backoff
Policy or validation rejection Quarantine reason code Requires new approval
Unknown provider result Check status before retry Prevent blind duplication

The companion article one primary conversion source covers the reporting choice. The source-of-truth boundary is described in booking pipeline versus CRM.

Consent should be modeled as a decision, not a boolean copied from a convenient form field. Record the purpose, channel, jurisdiction, policy version, timestamp, and withdrawal state needed to enforce the approved route. Advertising consent and analytics consent can have different scopes. A booking confirmation permission does not automatically authorize advertising measurement.

Before activation, the tenant should approve what outcome is being measured and why. Qualified counsel should review the event context, applicable health-data and privacy rules, contract chain, and Google Ads policy. Engineering should prove that a missing or revoked approval prevents new queue entries and cancels pending work where appropriate.

  • Destination and product named.
  • Generic action name approved.
  • Exact field allowlist reviewed.
  • Excluded fields tested and rejected.
  • Consent source and withdrawal path documented.
  • Retention and access roles defined.
  • Primary conversion source selected.
  • Approval expiry and policy recheck implemented.

Use the consent and booking attribution checklist before enabling a route. If the decision is uncertain, keep a campaign-level report inside the approved environment instead of sending a booking-level event.

Schema review: Keep the external schema smaller than the internal event. The internal record may need a source reference, tenant, approval version, and delivery result. The external object should contain only fields needed by the approved product. Reject a caller that adds a field even if that field is harmless in another tenant or campaign.

Run a contract test against a fake provider response. Check that accepted, duplicate, temporary failure, permanent rejection, and unknown result states are distinct. A timeout must not cause a blind resend when the provider may have accepted the event. A policy rejection must not enter a retry schedule that waits for a network recovery.

Review retention at both ends. The local queue, dead-letter store, provider diagnostics, campaign report, and backup may each retain a copy for different periods. Record the shortest approved purpose and remove data from paths that do not need it. If retention cannot be verified, do not call the payload minimum necessary.

FAQ

What is the first verification step for a generic offline conversion payload?

Identify the exact Google Ads product and read its current policy and API documentation. Then write the complete event context and field allowlist. Do not start from a copied booking payload.

Which source or configuration detail could change this answer?

Google can change API fields, retention windows, diagnostics, and sensitive-category policy. The tenant’s service, jurisdiction, consent, contract, and purpose can also change whether an event is appropriate.

What must be approved before a production claim or outbound action?

The tenant, qualified counsel, and policy owner should approve the destination, purpose, fields, consent, retention, deduplication, and rollback behavior. A successful test upload alone is not approval.

References

Related articles