Custom Booking Link vs Reserve with Google: What Booking Performance Does Google Report?

cmsapointoo on August 16, 2026

A custom booking link and Reserve with Google can both help a patient reach an appointment flow, but Google documents different reporting for them. Business Profile booking-performance data is not available for custom links. Where bookings are managed through a provider, Google lists a Bookings metric that counts completed booking actions.

That count is narrower than it sounds. It does not establish that the patient attended, paid, generated revenue, or came from a particular marketing source. A clinic should choose the link and the measurement plan together, then keep operational outcomes in the system that actually observes them.

What does Google document for each booking route?

Google Business Profile Help describes two routes. A business can work with a supported booking provider through Reserve with Google, or it can add its own link to the Business Profile. The same page states that performance data is not available for custom links and directs provider-managed businesses to Reserve with Google for booking performance.

A second Google help page defines the Business Profile Bookings metric as the number of bookings people completed. It also says bookings must be managed through a booking provider for that metric to have data. These two statements are the documented comparison.

They do not turn every provider dashboard into a Google report. They also do not promise that every category, country, profile, or provider supports the same booking experience. Confirm availability on the clinic’s own verified profile before making a decision.

Custom link vs Reserve with Google at a glance

Question Custom booking link Provider-managed Google bookings
Can the clinic place a booking destination on its profile? Google documents that a business can add its own link Google documents setup through a booking provider
Does Google provide booking-performance data? No, according to the booking setup page The Bookings metric may be available where the provider route is supported
What does the documented metric count? No custom-link booking metric is documented Completed booking actions
Does it prove appointment attendance? No No
Does it report revenue or no-shows? Not documented Not documented in the mapped pages
Does it provide campaign attribution? Not as a Google booking-performance report Not documented in the Bookings metric

The table compares only what the mapped Google pages establish. A provider may offer its own reporting outside Business Profile, and a clinic may measure a custom link in its own analytics. Those are separate systems with separate definitions.

What does a completed booking action prove?

A completed booking proves that a booking flow reached its completion state under the provider’s integration. It does not prove that the appointment later occurred. Attendance, cancellation, rescheduling, and no-show status happen after the booking and belong to the operational schedule.

This distinction prevents a common reporting error. A dashboard may show ten completed booking actions while the schedule later contains attended visits, cancellations, reschedules, and open future appointments. Calling all ten “completed appointments” would change the meaning of Google’s metric.

Revenue is another separate fact. The Business Profile documentation does not say the Bookings metric contains collected revenue, treatment value, or payment status. Clinics that need outcome reporting should use the clinic booking outcome taxonomy to define each later state.

How can a custom link be measured without inventing a Google report?

A custom link can use a clinic-owned measurement plan, but that plan sits outside Google’s documented booking-performance metric. The clinic might preserve an approved source parameter, record the booking entrance in its scheduler, and reconcile aggregate outcomes inside its reporting environment. Each step needs a controlled test.

Start by separating appointment source from marketing source. The appointment source describes where the booking entered the schedule. The marketing source describes the supported campaign or channel evidence that preceded it. The guide to appointment source versus marketing source explains why a single label such as “Google” cannot answer both questions.

Do not treat a click as a booking. Do not treat a booking as attendance. Keep unknown marketing evidence as unknown, and avoid passing appointment details or clinical context through URL parameters. The result is a clinic report, not a hidden extension of Business Profile performance.

Which route fits a clinic’s reporting need?

Choose a provider-managed route when the supported provider workflow fits operations and the documented Google Bookings count is useful. Choose a custom link when the clinic needs direct control over the destination and can operate its own measurement. Neither option wins every category.

The booking flow still needs to reach the schedule the reception team uses. A reporting feature has little value if appointments land in a second calendar or require manual copying. Account ownership, export access, cancellation handling, rescheduling, and outage recovery remain part of the decision.

Review visible links before changing routes. A Business Profile can contain clinic-added links and provider-supplied links under different control paths. The article on who controls a Google Business Profile booking link sets out those responsibilities.

What should the reporting contract say?

Write the metric name, source, meaning, exclusions, and owner before building a dashboard. “GBP completed bookings” is clearer than “Google appointments” because it does not imply attendance. A custom-link measure should name the clinic system that observed the click or booking instead of presenting it as Google booking performance.

Report field Definition Source
gbp_completed_bookings Completed booking actions shown by the supported Business Profile provider metric Business Profile performance
custom_link_clicks Approved clicks observed under the clinic’s own measurement rule Clinic analytics
bookings_created Appointments created in the operational schedule Booking system
appointments_attended Eligible appointments finalized as attended Booking system
marketing_source Supported campaign or channel evidence Approved attribution record

Do not combine these rows without a reconciliation rule. Different systems can update at different times, apply different time zones, and count different events. The label should make that difference visible.

How should the clinic test the chosen route?

  1. Confirm the public profile shows the intended booking destination.
  2. Create a test booking through the visible route.
  3. Verify that the booking appears once in the operational schedule.
  4. Record what Business Profile reports and when it appears.
  5. Check whether the scheduler preserves the approved appointment source.
  6. Change or cancel the test booking and confirm that later status stays separate from the original booking count.
  7. Document gaps rather than filling them with assumptions.

If an unwanted provider link remains on the profile, follow the specific provider-removal path and verify the public result. The guide to removing one third-party booking link covers that control.

Frequently asked questions

Does Google report bookings from a custom link?

Google’s booking setup page says performance data is not available for custom links. A clinic can build separate analytics around its own link, but it should label that reporting by its actual source rather than call it the Google Bookings metric.

Does the Bookings metric count attended appointments?

No such claim appears in the mapped Google pages. Google defines the metric as bookings people completed. Attendance is a later operational outcome and needs confirmation from the scheduling system.

Can the metric show revenue or no-show rate?

The mapped Business Profile documentation does not define revenue, payment, cancellation, or no-show reporting inside the Bookings metric. Keep those outcomes in a separately defined clinic report.

Is Reserve with Google available to every clinic?

Do not assume universal availability. Google directs businesses to providers available in their country, and profile features can depend on category, region, and provider support. Check the clinic’s verified profile and provider before planning around the feature.

References

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

cmsapointoo on August 16, 2026

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

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

Which decision does the clinic need to make?

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

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

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

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

When should conversion actions stay in the client account?

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

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

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

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

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

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

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

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

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

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

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

What continues after a manager account is unlinked?

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

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

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

How does Data Manager represent account ownership and access?

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

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

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

A practical governance default for clinics

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

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

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

Frequently asked questions

Does every clinic need conversion actions in its own account?

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

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

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

Does unlinking erase the clinic’s Google Ads history?

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

Does loginAccount own the Data Manager conversion action?

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

References

Report the Clinic Funnel by Original Lead Cohort, Not Today’s Totals

cmsapointoo on August 16, 2026

A clinic funnel should group every downstream stage by the original lead cohort, then show how complete that cohort is on the report date. Today’s totals mix new forms with older bookings, later appointments, and treatment decisions. That mixture can make a campaign look better or worse simply because outcomes arrive on different days.

The original lead cohort is the set of eligible form submissions created in the same declared period. Booking, attendance, and acceptance remain attached to those leads even when they occur later. The report needs both the cohort start and a snapshot date, so readers can distinguish a weak result from one that is still developing.

Why do today’s funnel totals mislead?

Spend is available quickly, but clinic outcomes mature at different speeds. A form may become a booking later. The appointment may sit weeks ahead, and acceptance may be recorded after attendance. A dashboard that divides today’s accepted cases by today’s forms compares unrelated groups of people.

Google’s guide to conversion delay makes the same timing problem visible inside Ads. It says recent performance can appear weaker because cost is fully reported while some conversions have not arrived. Depending on the configured conversion window, conversions can be reported up to 90 days after the click. That is a Google reporting fact, not a universal clinic maturity period.

Before building a cohort report, use a stable clinic booking outcome taxonomy. A status such as booked, attended, or accepted must mean the same thing across the selected period. Otherwise, the cohort method preserves inconsistent definitions more neatly without fixing them.

What should define the original lead cohort?

Choose the earliest eligible clinic-owned lead event that the report can reproduce, usually an accepted form submission. Assign it a cohort period from its original creation timestamp. Do not move the lead into a new cohort when someone books, attends, reschedules, or accepts treatment.

Field Purpose Rule
Opaque lead ID Joins later events without using names in the report Stable for the lead lifecycle
Original lead time Assigns the cohort Never overwritten by a later stage
Cohort period Groups comparable leads Declared timezone and calendar rule
Snapshot time Shows when counts were observed Stored for every report run
Stage timestamps Measures operational delays Keep booking, attendance, and acceptance separate

State eligibility rules beside the cohort. Tests, duplicates, spam, unsupported locations, and other excluded records need explicit treatment. If the clinic changes a rule, version it. Do not rewrite an old cohort silently, because readers will not know whether performance changed or the denominator moved.

How do Google’s ad-query and conversion-time views differ?

Google Ads can show results against different event times. Its attribution-report documentation says attribution reports use conversion time, while standard Campaigns reporting commonly assigns a conversion to the ad query before the click that led to it. The Campaigns page also offers columns reported by conversion time.

This distinction can shift the date where a conversion appears without changing the underlying conversion. Exported clinic reports should label the Google time basis used for spend and conversion columns. Do not call a Campaigns table dated by the ad query preceding the click a clinic lead cohort unless internal rows use the original lead timestamp.

The clinic report has its own anchor: the original eligible lead. The Campaigns page’s ad-query time locates the interaction before the click; conversion time locates the tracked action. Neither automatically groups booking, attendance, and acceptance under the clinic’s original lead cohort. That join is an internal reporting method.

How should each funnel stage be joined?

Keep one stable lead key through the internal flow. A booking record points back to the lead. Attendance points to the eligible booking, and acceptance points to the attended case under the clinic’s definition. Preserve the first valid stage time and record later corrections instead of replacing the history without a trace.

original lead cohort
  -> eligible form submitted
  -> eligible booking created
  -> consultation attended
  -> case accepted

Rescheduling needs a declared rule. The lead remains in its original cohort, while the current appointment time can change. Cancellation and rebooking should not create a second lead unless the clinic’s documented business rule treats the later request as new demand. The appointment-source and marketing-source distinction also stays attached without changing the cohort anchor.

Which rates belong in the report?

Show counts before rates, then name every denominator. The following formulas are editorial reporting guidance, not Google Ads calculations. Apply them only to eligible records joined to the same original lead cohort and observed at the same snapshot.

booking rate
= eligible booked leads / eligible original leads

show rate
= eligible attended consultations / eligible bookings

acceptance rate after attendance
= accepted cases / eligible attended consultations

end-to-end acceptance rate
= accepted cases / eligible original leads

Do not multiply or compare rates that use different filters. For example, a show rate based on all clinic bookings cannot explain campaign performance if the cohort includes only form leads. The campaign show-rate method explains how to retain aggregate attribution without putting appointment details into an advertising payload.

Calculate a rate only when its declared denominator is greater than zero. Show N/A when a cohort has no eligible leads, bookings, or attended consultations for that rate. Keep the zero count visible, but do not present an undefined ratio as 0%.

How should the clinic define cohort maturity?

Maturity comes from the clinic’s observed time to each stage. Measure lead-to-booking, booking-to-appointment, and attendance-to-acceptance delays across older complete cohorts. Select and document a review window that matches the business question. A cohort can be mature for booking but still immature for attendance or acceptance.

cohort age
= snapshot time - end of original lead cohort period

stage maturity
= cohort age compared with the clinic's documented observed-delay window

Google recommends ending one conversion-delay report at least 30 days ago, or longer when the account uses a longer conversion window. That instruction concerns Google Ads data completeness. It must not become a blanket 30-day clinic rule. Appointment lead time and follow-up practice can require a different window, established from clinic records.

What should the finished cohort table show?

Give each cohort one row per snapshot or preserve a snapshot history. Include original leads, bookings, attended consultations, accepted cases, stage rates, cohort age, and maturity labels. Add spend and marketing dimensions only when their time basis and attribution rule are clear.

Cohort Snapshot Leads Booked Attended Accepted Maturity
Original lead period Report cutoff Eligible count Joined count Joined count Joined count Booking, attendance, and acceptance labels

Keep immature rows visible, but do not rank them as if they were complete. A simple label such as developing, mature for booking, or mature through acceptance is more honest than filling missing outcomes with assumptions. If forecasts appear, place them in separate columns and identify the method.

How should teams review the report?

Compare cohorts only after checking definition version, source coverage, snapshot date, and maturity. Investigate changes through counts first. A falling rate might come from fewer downstream events, a larger denominator, a late data import, or a status-rule change.

Save every report with its retrieval time and source status. Reopen prior cohorts when delayed outcomes arrive, but retain the earlier snapshot for audit. The most useful meeting question is specific: did the mature cohort produce fewer bookings, weaker attendance, or lower acceptance under the same definitions?

Frequently asked questions

Is an original lead cohort the same as a Google Ads click cohort?

No. The clinic cohort starts with its declared eligible lead event. The Campaigns page can use the ad-query time preceding the click or columns by conversion time. Record that choice separately and do not substitute it for the original lead timestamp.

Should today’s accepted cases be divided by today’s form leads?

No. The groups usually contain different people at different funnel ages. Join each accepted case back to its original eligible lead cohort, then calculate the rate for that cohort at a stated snapshot.

Does Google require a 30-day clinic maturity window?

No. Google describes a 30-day or longer date-range check for its conversion-delay reporting. Clinic maturity must come from observed booking, appointment, and acceptance delays. Document a separate window for each stage when needed.

Can an immature cohort remain in the report?

Yes. Show its current counts and label it clearly. Do not compare or rank its incomplete rates beside mature cohorts without explaining the difference. Keeping snapshots lets readers see how the cohort developed.

References

The Offline Conversion Outbox Report Every Agency Should Show Clients

cmsapointoo on August 16, 2026

An offline conversion report should show what the agency can prove, not one reassuring delivery percentage. A useful report separates the local outbox ledger, the initial Data Manager request, later diagnostics for each destination, Ads reporting, and attribution. Those are different observations made at different times.

This format is an editorial recommendation for agency operations. AWS documents the transactional outbox pattern, while Google documents request IDs, destination diagnostics, warnings, errors, and deduplication behavior. Neither provider prescribes a client report. The agency owns the presentation and must keep the claims inside the evidence each system returns.

Why clients need an evidence report, not a delivery claim

A client needs to know where offline outcomes are waiting, what the agency sent, what Google is still processing, and what failed. A single uploaded count hides those distinctions. It can also turn an HTTP response into a claim about Ads reporting or attribution that the response does not establish.

The report should answer four questions. Did the source transaction create one durable local event? Did the worker receive a successful ingestion response and capture its Google request ID? What terminal status did Google later return for each destination? Did a separate Ads reporting check observe the conversion in the expected account and time window?

Attribution belongs in a fifth, separate layer. A destination may finish processing without the conversion receiving the attribution an agency expected. The diagnostics guide covers upload health and data issues. It does not turn a processed request into evidence about campaign credit, bidding use, or business impact.

For the upstream measurement boundary, review the server-side Data Manager architecture. That design keeps outbound delivery disabled until the exact use has passed the required reviews. The report described here documents reliability after a route is approved. It does not grant permission to create that route.

Build the local outbox ledger first

AWS Prescriptive Guidance describes the transactional outbox as a solution to the dual-write problem. The application writes its business state and outbox record in the same transaction. A separate process reads committed outbox records and sends messages. If the source transaction rolls back, the notification should not leave.

The client report does not need the source record. Give each eligible outcome an opaque local event ID and an outcome version. Store a created time, current local state, attempt count, next retry time, deduplication basis, and destination reference. Keep the operational payload outside the report.

Local field Meaning Safe client display
Opaque event ID Stable reference generated by the agency system Yes
Outcome version Which approved state produced this event Yes
Local state Queued, dispatching, sent, retry due, suppressed, or quarantined Yes
Attempt and retry time Local worker activity Yes
Source payload Operational source data No
Excluded fields Health, identity, and free-text content No

Define sent narrowly. It means the worker received a successful Data Manager ingestion response and stored its request ID. It does not mean that Google finished processing the request. It also says nothing about Ads reporting or attribution.

AWS also warns that event delivery can produce duplicates and recommends idempotent consumers. The webhook idempotency guide applies the same rule to inbound events: repeat delivery should not create a second business result. The local deduplication key belongs to the agency ledger even when the provider has its own transaction identifier.

Keep Google request evidence in a second ledger

Google’s Send Events guide says a successful ingestion request returns a requestId. The diagnostics guide describes the same initial success as status code 0, enum OK, and HTTP 200 OK. Capture that request ID. Do not rename the response as a final conversion result.

The Google ledger should use one row per request and destination, not one row per local event. Store the Google request ID, destination reference, request time, first diagnostic check, current destination status, record count, warning counts, error counts, and last checked time. If one request contains several events or destinations, preserve that batch shape.

Evidence layer Provider or owner What it proves
Local outbox state Agency What the local worker recorded
HTTP success and request ID Data Manager API The initial ingestion request succeeded
Destination diagnostic Data Manager API Later processing status for that request and destination
Ads reporting observation Agency check in Ads What appeared in the selected report and window
Attribution observation Ads reporting model Credit observed under stated settings

The diagnostic record_count includes successful and failed records. Warning and error information is returned as reason counts. That is aggregate batch evidence. If a ten-event request reaches PARTIAL_SUCCESS, the report may show the request total and error counts. It must not mark a particular opaque event as successful or failed unless another provider response supplies that event-level link.

Use Google’s destination states without inventing another state

Google documents four destination states: PROCESSING, SUCCESS, PARTIAL_SUCCESS, and FAILURE. Preserve those names in the provider ledger. Do not compress them into an accepted field, because that word can mean the initial HTTP response, a completed destination, or a visible conversion.

PROCESSING means Google has not populated warnings and errors yet. SUCCESS means destination processing finished without errors, but the diagnostics guide still instructs teams to inspect warnings. A warning means Google did not reject the record but ignored part of its data. FAILURE means all records for that destination failed. PARTIAL_SUCCESS means some succeeded and others failed.

In the documentation retrieved on August 16, 2026, Google recommends waiting 30 minutes before the first diagnostic request. Teams should then poll with exponential backoff until every destination reaches a terminal state. Processing may take up to 24 hours. The client report should show a dated still processing count rather than treat an incomplete diagnostic window as failure.

Keep warning and error reason codes, counts, and retrieval times. Do not copy rejected record contents into the report. A reason count is enough for client-level monitoring. Technical staff can use controlled logs for investigation without turning a recurring report into another store of sensitive source data.

Report deduplication and retries at the correct layer

Local idempotency and Google deduplication solve related but different problems. The local outbox prevents the worker from creating repeated side effects when it sees the same event again. Google’s Send Events guide says Google Ads uses transactionId within the same conversion action to deduplicate events sent from different sources in the documented scenarios.

The report should show a local deduplication result such as new, duplicate suppressed, or manual review. It may separately show whether the approved outbound event had a transaction ID. Do not print that identifier if it reveals source-system information. Do not claim universal Google deduplication beyond the documented product and conversion-action behavior.

Retry state also needs two columns. Delivery retry describes a local worker sending a request again after a transient failure. Diagnostic polling describes status retrieval for a request that already succeeded initially. Polling must never resubmit the conversion. If a response is unknown, quarantine the event until the runbook resolves whether another send is safe.

The AWS SQS outbox design covers queue, dead-letter, and replay controls. Client reporting should summarize retry backlog, oldest pending age, quarantined count, and owner. It should not include message bodies or dead-letter payloads.

Use a two-table client report

The first table is the local event ledger. Show opaque ID, outcome version, created time, local state, attempts, next action, and Google request ID when present. The second table is the Google request ledger. Show request ID, destination, terminal or processing state, record count, warning counts, error counts, and last diagnostic time.

Above the tables, give the client a short reconciliation summary:

  • eligible local outcomes created during the period;
  • events queued, sent, suppressed, retry due, or quarantined;
  • initial Google requests that succeeded or failed;
  • destinations processing, successful, partially successful, or failed;
  • aggregate records, warnings, and errors returned by diagnostics;
  • Ads reporting observations performed separately;
  • unresolved reconciliation differences and named owner.

A reconciliation difference is not automatically data loss. It can reflect batches still processing, retries, timing windows, duplicate suppression, or separate reporting settings. State the reason when known and mark it unresolved when it is not. Never fill the gap with an inferred event-level result.

For outcome definitions that do not expose appointment detail, use the clinic booking outcome taxonomy. Keep the external eligibility decision outside the reliability report and review the Google Ads health conversion boundary before any route is enabled.

Frequently asked questions

Does HTTP 200 mean the conversion appeared in Google Ads?

No. It means the initial Data Manager request succeeded and returned a request ID. Check later diagnostics per destination, then inspect Ads reporting separately. Attribution requires another observation under the relevant reporting settings.

Can the report mark each event successful after PARTIAL_SUCCESS?

No. Google diagnostics provide aggregate record, warning, and error counts for the request and destination. Do not assign that aggregate result to individual local events without event-level provider evidence.

What should the report do with health fields?

Exclude them, along with source payloads and identity fields. The report needs opaque references, states, counts, dates, and reason codes. It does not need the operational content behind the outcome.

Does this report authorize an offline conversion route?

No. It documents reliability for a route that has already passed the required product, policy, privacy, security, and legal reviews. When approval is absent or expired, outbound delivery should remain disabled.

References

How to Calculate Break-Even Cost per Booked Dental Consultation

cmsapointoo on August 16, 2026

Break-even cost per booked dental consultation is the most a clinic can spend to acquire one eligible booking before the expected contribution from that booking falls to zero. The calculation needs clinic data, not an industry benchmark. It combines contribution margin per accepted case with the clinic’s own attendance and treatment-acceptance rates.

The denominator matters as much as the inputs. An acceptance rate measured from all bookings already includes missed appointments. An acceptance rate measured only from attended consultations does not. Mixing those definitions discounts the same missed appointment twice and understates the acquisition ceiling.

What does break-even cost per booked consultation mean?

This metric answers a narrow planning question: how much expected contribution does one eligible booking create before acquisition cost? It is not the patient’s bill, the dentist’s production target, or a published market average. The clinic defines what counts as an eligible booking and which costs sit inside contribution margin.

Google’s guide to estimating conversion value uses a fictional business example that combines deal revenue, profit margin, and the share of leads that become deals. That example supports the general principle of working backward from a completed outcome. It does not supply dental economics. A clinic must replace every input with its own collected and reviewed figures.

Start by aligning the booking definition with the clinic’s booking outcome taxonomy. Exclude tests, duplicates, spam, and records outside the agreed service scope. If teams count different events as a booking, the break-even figure will change even when the underlying operation has not.

Which clinic-owned inputs belong in the calculation?

Use one reporting period, one clinic or location, one accepted-case definition, and one cost policy. Pull financial inputs from clinic accounting and operational rates from the booking system or clinic-owned reporting layer. Do not copy values from another location, a vendor testimonial, or a paid-media account.

Input Definition to record Required denominator
Contribution margin per accepted case Collected value assigned to an accepted case minus the variable costs included by the clinic Accepted cases in the same scope
Show rate Eligible attended consultations divided by eligible booked consultations Booked consultations
Acceptance rate after attendance Accepted cases divided by eligible attended consultations Attended consultations
Acceptance rate from booking Accepted cases divided by eligible booked consultations Booked consultations
Cost per booked consultation Chosen acquisition cost divided by eligible booked consultations Booked consultations attributed under the same rule

Write down whether contribution margin excludes advertising cost. It normally must if the calculation is solving for the maximum acquisition cost. Also document refunds, payment failures, external laboratory costs, financing fees, and other variable items that the clinic chooses to include. This is an accounting decision, not a Google Ads setting.

Formula one: acceptance already uses bookings

Use the shorter formula when the clinic reports accepted cases as a share of all eligible bookings. Missed and cancelled consultations already remain in the booked denominator, so their effect is present in the rate.

expected contribution per booking
= contribution margin per accepted case
  × accepted cases / eligible booked consultations

break-even cost per booked consultation
= expected contribution per booking

Do not multiply this result by show rate. Doing so would reduce the value once through the accepted-per-booked rate and again through attendance. The error is easy to miss when a dashboard labels both figures as funnel percentages without displaying their denominators.

Calculate the accepted-per-booked rate only when eligible bookings are greater than zero. If the denominator is zero, display N/A and preserve the counts. Do not convert an undefined rate into 0%.

Formula two: acceptance starts with attended consultations

Use the expanded formula when treatment acceptance is calculated only among people who attended. In that case, show rate first converts a booking into expected attendance. Acceptance rate then converts expected attendance into an expected accepted case.

expected contribution per booking
= contribution margin per accepted case
  × attended consultations / eligible booked consultations
  × accepted cases / eligible attended consultations

break-even cost per booked consultation
= expected contribution per booking

The two formulas agree when they use the same eligible records and both denominators are greater than zero. The attended count then cancels algebraically. If no eligible consultation was attended, the acceptance-after-attendance rate is N/A, not 0%. Investigate any other difference in filters, time windows, status definitions, or joins. The clinic’s show-rate measurement should use the same booked and attended states.

How should the clinic compare acquisition cost with the ceiling?

Define acquisition cost before dividing it by bookings. A media-only view answers a different question from a view that includes agency fees, call handling, landing-page costs, or other chosen expenses. Label the scope in the report instead of presenting one unlabeled cost per booking.

observed cost per booked consultation
= acquisition cost in the declared scope
  / eligible booked consultations

Compare observed cost with expected contribution for the same cohort and attribution rule. A result below the arithmetic ceiling does not prove that the campaign is profitable. Fixed overhead, capacity, cash timing, cancellations, refunds, and uncertainty may still matter. Management can set a lower operating target or reserve after reviewing those factors.

Keep appointment source separate from marketing source. A scheduler may record the channel where the booking occurred, while the clinic’s attribution process records how demand was generated. The distinction in appointment source versus marketing source prevents the wrong bookings from entering the paid-media denominator.

Why does the cohort need to be mature?

A recent booking cohort may contain consultations that have not happened and attended consultations with no final acceptance status. Calculating from that partial cohort depresses the observed rates. Freeze a cohort by original booking period, apply a stated snapshot date, and label it immature until the clinic’s normal operational delay has passed.

Use the clinic’s observed delay distribution rather than a borrowed number of days. Recalculate early cohorts on a fixed schedule, but do not silently replace prior inputs. Save the source counts beside every result: booked, attended, accepted, contribution basis, cost scope, exclusions, and snapshot date.

What do the mapped sources prove?

Google’s page proves that conversion value can be estimated by combining an outcome’s financial value with the probability that an earlier conversion reaches that outcome. Its amounts belong to a fictional machinery company. They are not dental benchmarks, recommended margins, or suggested bids.

Doctoralia’s clinic page describes online booking, automated reminders through email, app and SMS, payments, and a waiting-list function. Those product claims explain why booking and attendance are separate operational states. The page does not provide a break-even formula, a dental contribution margin, or a dependable clinic-wide show-rate benchmark. Do not quote its dynamically rendered counters.

Frequently asked questions

Is break-even cost the same as a Google Ads target CPA?

No. Break-even cost is a clinic-owned financial estimate per eligible booking. A Google Ads target is a platform setting and may use a different conversion action. Translate between them only after documenting the event, attribution rule, denominator, and cost scope.

Should gross treatment revenue replace contribution margin?

No. Gross revenue ignores the variable costs included in the clinic’s delivery model. Finance should define contribution margin consistently. The calculator should preserve that definition and show which costs remain outside it.

What if the clinic only knows accepted cases per booking?

Use formula one. That rate already includes attendance loss because all eligible bookings remain in the denominator. Do not apply a separate show-rate multiplier unless acceptance is recalculated from attended consultations.

Can one rate be used across every location?

Only if clinic evidence shows the locations share the same scope and behavior. Keep location-level inputs when appointment handling, treatment mix, cost policy, or follow-up differs. A common formula is useful; a pooled benchmark can hide a weak unit.

References

Treatment Acceptance as an Internal Clinic Value Model, Not a Google Ads Payload

cmsapointoo on August 16, 2026

Treatment acceptance can inform a clinic’s internal economics without becoming a Google Ads conversion. The safe boundary is aggregate and clinic-owned: calculate acceptance rates across defined cohorts, use them in internal planning, and keep treatment acceptance, derived individual values, and related outcomes out of Google.

Removing the words “treatment acceptance” from an event does not remove its meaning. A generic label, numeric value, hash, consent record, legal basis, API route, or successful response cannot turn health-related conversion information into an eligible upload. This article contains no activation path because the model ends inside the clinic.

Why must treatment acceptance stay internal?

Treatment acceptance describes a healthcare business outcome. Google’s Customer data policies prohibit conversion information related to sensitive categories and identify health or medical information as sensitive. The restriction applies to enhanced conversions, including enhanced conversions for leads.

The policy looks at what the conversion relates to. Renaming the outcome “qualified lead,” “high value,” or another generic term does not change the underlying fact used to produce it. The same concern applies when the event contains only a number derived from acceptance.

Keep the source outcome in the clinic’s approved operational system. Marketing can receive aggregate reporting under a documented rule, but it should not receive the underlying treatment record or an individual event that represents acceptance. The clinic booking outcome taxonomy provides a separate set of generic operational stages.

What does Google’s conversion-value guide support?

Google’s guide to estimating conversion value uses a fictional machinery company. It combines business factors such as average revenue, profit margin, the share of leads that become deals, repeat business, and word of mouth. Google presents the example as a way to choose a value method that fits business objectives.

For internal planning, the useful idea is simple. A lead does not need to equal the final sale amount. A business can estimate expected value from aggregate rates and use conservative assumptions where direct tracking is difficult.

The example does not address healthcare-sensitive conversion uploads. It does not say that a clinic may send treatment acceptance or a value derived from it to Google. Use the estimation principle for clinic-owned analysis only, subject to the clinic’s financial and legal review.

How does the clinic-owned aggregate model work?

Define a cohort, an observation window, and a stable internal outcome rule. Count eligible leads and accepted outcomes within that cohort. Then calculate an aggregate acceptance rate. Separately, finance can maintain an approved average contribution or another internal economic measure.

To estimate internal value per eligible lead, multiply the aggregate acceptance rate by the approved average contribution. Keep the formula, inputs, and results in the clinic’s reporting environment. The resulting individual value must not be written back to an advertising event.

Model input Internal owner Boundary
Eligible lead count Approved first-party reporting Aggregate cohort count
Accepted outcome count Clinic operational system Aggregate only
Acceptance rate Clinic reporting model Calculated inside clinic environment
Average contribution assumption Finance Approved aggregate assumption
Expected internal lead value Planning report Never exported as an individual Google value

Version the definitions. If the clinic changes its eligibility rule, observation window, or financial assumption, label the new model and avoid comparing it with an older period as though nothing changed.

How can campaigns be compared without uploading the outcome?

Keep the join and calculation inside the approved environment. An approved campaign dimension comes from the marketing record, while the clinic system supplies aggregate outcome counts. The reporting job combines them into cohort totals without exposing individual treatment acceptance.

Use explicit denominators. An acceptance rate based on eligible attended cases answers a different question from one based on form submissions or created bookings. Report both the numerator definition and denominator definition beside the result.

Do not use small, identifying slices or free-text explanations in the marketing report. The report should answer planning questions with aggregate values. The guide to campaign show rate without appointment details uses the same separation between internal outcomes and media tools.

Why does a generic Google payload remain unsafe?

Google’s Data Manager documentation shows that an event can contain a timestamp, conversion action, conversion value, advertising identifiers, and user identifiers. The API can technically send offline conversions and enhanced conversions for leads. The send-events guide also describes formatting, hashing, encoding, and successful request IDs.

Those features describe transport. They do not establish policy permission. If an individual value was derived from treatment acceptance, changing its label to “lead value” does not erase the health-related source. A hash protects neither the meaning nor the event context from the policy analysis.

Zeroing, bucketing, rounding, delaying, or otherwise disguising the treatment outcome does not make it suitable for upload. There is no payload example, conversion action, value mapping, tag, or Data Manager workflow here. The boundary remains internal aggregation.

How does personalized advertising policy affect the model?

Google classifies health as a sensitive interest category for personalized advertising. Advertisers promoting sensitive products or services cannot use advertiser-curated audiences such as Customer Match and their own data segments. The policy exists separately from conversion measurement restrictions.

An internal value model should not feed a treatment-acceptance audience, remarketing list, lookalike input, or narrow targeting segment. Aggregation for clinic planning is not an excuse to activate audiences. The underlying information stays in the clinic environment.

The Customer data policies remain the controlling source for the enhanced-conversion question. The personalized advertising page adds an audience boundary. Both point away from repurposing health-related outcomes for advertising activation.

What decisions can the internal model support?

Used internally, the calculation can compare aggregate economics across approved campaign groups, forecast a planning range, and show whether a change in lead mix accompanied different internal outcomes. These are management uses, not instructions for Google bidding.

Keep uncertainty visible. Acceptance can mature after the initial reporting period, and the financial assumption can change. Label incomplete cohorts, record the observation date, and avoid presenting an estimate as collected revenue. Finance should own the economic input while operations owns the outcome definition.

Keep the calculation beside the basic funnel counts. Submissions, bookings, attendance, and accepted outcomes each need their own definition. The Data Manager architecture for clinic forms explains why an internal result and an outbound event require separate decisions.

An internal-only control checklist

  • Define the eligible cohort and observation window.
  • Define treatment acceptance inside the clinic’s approved system.
  • Calculate the acceptance rate from aggregate counts.
  • Keep the financial assumption owned and reviewed by finance.
  • Version the model when a definition or assumption changes.
  • Report only aggregate campaign groups inside the approved environment.
  • Do not create individual values from treatment acceptance for Google.
  • Do not rename, hash, bucket, or delay the outcome for upload.
  • Do not create audiences from the model.
  • Record the policy sources and review date.

Frequently asked questions

Can treatment acceptance set a Google Ads conversion value?

Not under this model. Treatment acceptance and individual values derived from it remain inside clinic-owned reporting. The article provides no Google activation or upload route.

Does aggregation make an individual upload safe?

No. An aggregate rate can support an internal model. Applying that rate to individual advertising events still creates individual values derived from a health-related outcome.

Can the clinic use a generic event name?

A generic name does not change the event’s meaning. If the outcome or value derives from treatment acceptance, keep it out of Google regardless of the label.

Does Data Manager success prove the event is allowed?

No. Technical success confirms request processing, not compliance with Customer data policies, personalized advertising rules, contracts, consent duties, or applicable law.

References

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

cmsapointoo on August 16, 2026

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

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

What does Google’s customer data policy prohibit?

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

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

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

Why is hashing not an eligibility test?

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

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

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

How should a clinic classify a form conversion?

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

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

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

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

What do the Data Manager documents establish?

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

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

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

Where does personalized advertising policy fit?

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

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

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

What should remain inside the clinic?

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

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

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

A publication and implementation stop checklist

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

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

Frequently asked questions

Does consent make a clinic form eligible?

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

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

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

Does a successful Data Manager request prove compliance?

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

Can the clinic rename the event to a generic lead?

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

References

AWS Lambda and DynamoDB vs Cloud Run and Firestore: Serverless Cost Drivers for a Health Data Island

cmsapointoo on August 16, 2026

AWS Lambda with DynamoDB and Google Cloud Run with Firestore can both support a small isolated health workload. Neither stack is the universal monthly cost winner. The result depends on region, request pattern, execution duration, memory, concurrency, document or item size, consistency, query shape, storage, backups, logs, and network paths.

A useful comparison converts the same observed workload into each provider’s billing units, applies current regional rates and allowances, and exposes excluded services. This produces a reproducible estimate without presenting a temporary rate as permanent.

Start with one normalized workload

Freeze the period, region, traffic, retention, and recovery policy. Use production telemetry when available. Otherwise, label low, expected, and burst cases as assumptions. Give both stacks equal durability and observability.

Input Unit to record Why it changes cost
Requests Monthly successful and failed invocations Runtime request charges and retry volume
Compute Duration, CPU, memory, concurrency GB-seconds or vCPU and GiB seconds
Database reads Items, documents, index entries, consistency Billing unit differs by database and query
Database writes Writes, deletes, transactions, replicated writes Size and mode can multiply units
Storage Data, metadata, indexes, monthly growth Stored shape can exceed logical payload size
Recovery Backup size, retention, restore frequency Optional recovery features have separate charges
Operations Log volume, retention, metrics, traces Verbose output can dominate a small workload
Network Origin, destination, direction, bytes Region and egress path determine treatment

If one design batches writes, caches reads, or uses higher concurrency, show it as a named architecture variant. For broader budgeting, compare the cloud bill with the operating program instead of mixing staff work into request rates.

Lambda and Cloud Run compute differently

AWS Lambda charges for requests and execution duration measured in GB-seconds. Allocated memory affects the duration charge and the compute resources available to the function. Architecture and region can change the applicable rate. As of August 16, 2026, the published free tier includes one million requests and 400,000 GB-seconds per month, but the estimate should still show gross usage before the allowance.

For Lambda, collect invocations, billed duration, memory, architecture, region, and retries. Multiply billed seconds by allocated memory in GB for each function class. Use provider billing metrics rather than wall-clock latency. Include provisioned concurrency only when used. The Lambda runtime boundary review distinguishes compute from adjacent services.

Cloud Run supports request-based and instance-based billing. Request-based billing charges CPU and memory during billable instance time, with idle charges possible for minimum instances. Instance-based billing charges for the container instance lifetime and has a minimum duration. Concurrency changes how many requests share an instance, so requests and latency alone cannot reproduce cost.

For Cloud Run, record billing mode, vCPU, memory, requests, billable instance seconds, concurrency, minimum instances, region, and retries. As of August 16, 2026, the request-based allowance uses active us-central1 pricing and corresponds to 180,000 vCPU-seconds, 360,000 GiB-seconds, and two million requests per month. The instance-based service allowance uses us-central1 pricing and corresponds to 240,000 vCPU-seconds and 450,000 GiB-seconds per month.

DynamoDB and Firestore operations are not equivalent

DynamoDB offers on-demand and provisioned capacity modes. On-demand bills read and write request units. Provisioned mode bills hourly capacity allocated, even when actual use is lower. For on-demand reads, item size and consistency matter: reads are calculated in 4 KB increments, with eventually consistent, strongly consistent, and transactional reads consuming different units. Writes use 1 KB increments, and transactional writes consume more units than standard writes.

“Ten million reads” is not yet a price input. Add item size, consistency, transactions, table class, region, replication, streams, and commitments. Large items can consume several units. Global tables add regional storage and replicated writes.

Firestore Standard edition charges document reads, writes, deletes, index-entry reads, stored data including indexes and metadata, and network bandwidth. Query shape matters. A query can incur document reads plus index-entry reads. Listeners may create reads when results change or clients reconnect. Offsets can charge for skipped documents. Security-rule evaluation can require dependent-document reads.

Do not translate one DynamoDB read unit into one Firestore document read. Model operations produced by each access pattern. Test indexes and authorization queries with synthetic data. The Firestore database proof connects access and billing behavior.

Free allowances need their own row

Free usage can hide boundaries. Lambda’s request and duration allocations are monthly. As of August 16, 2026, DynamoDB’s free tier for provisioned Standard tables applies per Region and payer account. It includes 25 write capacity units, 25 read capacity units, 25 replicated write capacity units for global tables across two Regions, 25 GB of storage, 2.5 million DynamoDB Streams read requests, and 1 GB of data transfer out per month, with 15 GB of transfer for the first 12 months. It does not apply provisioned capacity to on-demand mode.

Cloud Run allowances depend on billing mode and use a us-central1 price equivalent. A deployment in another region should apply the current regional mechanics from the pricing page. Firestore permits free quota for only one database per project. Its published free quota includes 1 GiB of storage, 50,000 document reads per day, 20,000 writes per day, 20,000 deletes per day, and 10 GiB of outbound transfer per month. Daily quotas reset around midnight Pacific time.

Firestore provides no free usage for point-in-time recovery data, backup data, restore, clone, and TTL deletes. Daily quota also does not protect a burst from limits. Show gross units, eligible allowance, and billable units separately. Confirm account eligibility, database count, region, mode, and cadence before subtraction.

Storage, backups, logs, and egress close the gap

Logical payload size is not total storage. DynamoDB storage depends on table class and region, while indexes, streams, backups, point-in-time recovery, and global replicas create additional surfaces. On-demand backup storage and recovery features are billed separately. Cross-region paths can add transfer charges.

Firestore storage includes document data, metadata, and indexes, calculated from daily storage over the month. Point-in-time recovery, backups, restore, and clone have separate treatment. An index-heavy model can grow faster than the visible records. Compare retention and restore objectives, not only live database size.

Logs, audit records, traces, metrics, and exports need explicit inputs. Estimate bytes per request and retention, then test a synthetic run. Keep record contents out of logs. For network, record source, destination, direction, and bytes. Internet egress, cross-region traffic, database responses, and external calls can follow different schedules.

Also list adjacent components that the architecture actually uses: API gateway or load balancer, queue, scheduler, object store, key service, secrets, DNS, monitoring, and support. Do not assign them to a runtime price line. The pooled regional stack model is useful when fixed resources are shared across isolated workloads.

Build a reproducible calculator

Create one input sheet, two translation sheets, and one comparison sheet. Save source URL, retrieval date, currency, region, architecture, billing mode, and rate beside every unit price. Rates should be replaceable without rewriting formulas.

AWS monthly usage =
  max(0, Lambda requests - eligible request allowance) * regional request rate
  + max(0, Lambda GB-seconds - eligible duration allowance) * regional duration rate
  + DynamoDB read units * selected read rate
  + DynamoDB write units * selected write rate
  + table and index storage * regional storage rate
  + backups + recovery + logs + network + adjacent services

Google Cloud monthly usage =
  billable Cloud Run requests * regional request rate
  + billable vCPU-seconds * regional CPU rate
  + billable GiB-seconds * regional memory rate
  + Firestore document and index reads * regional read rates
  + writes and deletes * regional operation rates
  + database and index storage * regional storage rate
  + backups + recovery + logs + network + adjacent services

For Lambda, compute GB-seconds = invocations × billed seconds × allocated memory in GB by function class. For Cloud Run, use provider billable instance metrics rather than deriving them from request latency when possible. For DynamoDB, translate each operation by item size, consistency, transaction type, and capacity mode. For Firestore, count document operations and index-entry reads by query.

Run low, expected, and burst rows. Add sensitivity for duration, item size, indexes, log retention, backup growth, and cross-region egress. This shows which measurement deserves engineering work.

How to interpret the result

Use the range that matches observed behavior. Lambda with DynamoDB may suit one spiky, item-oriented workload. Cloud Run with Firestore may suit another with favorable concurrency and document access. Change consistency, duration, index fan-out, region, or minimum instances and the ranking can reverse.

Keep cost and control claims separate. Service eligibility, configuration, isolation, backup proof, incident readiness, and contract review require their own evidence. Prefer the estimate that can be reproduced and operated within the required boundary.

Frequently asked questions

Which stack is cheaper for a small health data island?

There is no universal answer. Use the same region, traffic, duration, memory, read and write behavior, storage, backup, logging, and egress assumptions, then apply current provider rates.

Can I compare Lambda requests with Cloud Run requests directly?

Only one part maps directly. Compute also depends on Lambda GB-seconds or Cloud Run CPU and memory billable time, billing mode, concurrency, minimum instances, architecture, and region.

Can free allowances make the monthly bill zero?

They may reduce eligible usage, but they have different limits, cadence, regions, modes, and exclusions. Backups, logs, egress, extra databases, recovery features, and adjacent services can still generate charges.

How often should the calculator be refreshed?

Refresh rates before procurement and after a region, architecture, billing mode, workload, retention, or recovery change. Preserve the retrieval date and recalculate from observed metrics each month during early operation.

References

A Google Cloud BAA Does Not Cover Google Ads

cmsapointoo on August 16, 2026

A Google Cloud Business Associate Agreement applies to the Google Cloud services and conditions identified in that agreement. It does not travel with information when a workload sends an event to Google Ads. Google Ads is a separate product destination with its own terms, customer data policies, account configuration, and approval path.

This boundary matters because an architecture can be technically sound inside Google Cloud and still create an unapproved advertising disclosure at its final step. A covered runtime, database, queue, or secret store does not extend the provider agreement to an Ads API. Review each destination independently before connecting it.

What the Google Cloud BAA actually scopes

Google Cloud’s HIPAA compliance page states that customers subject to HIPAA who use Google Cloud with protected health information must review and accept Google’s BAA. The page describes coverage for Google Cloud’s infrastructure and the listed covered products. It also makes shared responsibility explicit: the agreement does not, by itself, make a customer’s application compliant.

That is a product boundary, not a corporate halo. Record the legal entity, billing account, organization, projects, named services, features, regions, support path, and agreement version. Then connect those provider facts to customer controls such as identity, tenant isolation, encryption, logging, backups, retention, incident response, and workforce access. The Google Cloud covered-product review explains how to preserve that evidence chain.

A useful statement is narrow: “This workload uses named Google Cloud services listed in the current provider scope under the accepted agreement.” It should not become “Anything this workload calls is covered.” Once information crosses to another product, the team must evaluate the new recipient and purpose.

Why Google Ads stays outside that boundary

Google Ads is an advertising platform, not a service added to the Google Cloud BAA because the same vendor operates both brands. The Google Cloud compliance page defines its own covered products. Google Ads publishes separate customer data policies. Procurement, credentials, support, data use, retention, and enforcement also follow different product systems.

Layer Question Evidence to preserve
Google Cloud Is the exact service in the current BAA scope? Agreement, covered-product page, project and feature list
Application Does configuration enforce the intended data boundary? Data-flow map, access tests, logs and retention settings
Google Ads Does policy permit this exact conversion use and field set? Current policy, destination configuration and written approval
Transfer What leaves Cloud, and why? Serializer allowlist, queue record and delivery evidence

Do not combine those rows into one compliance claim. A contract review can establish provider scope. A technical test can establish observed behavior. A policy review can establish whether an advertising use is permitted under the published rules at that date. Counsel can assess legal duties. None substitutes for the others.

Google Ads customer data policy changes the decision

Google’s customer data policy applies to features including enhanced conversions, store sales uploads, and other customer data uses identified on the page. It prohibits uploading conversion information related to sensitive categories. The policy lists health and medical information, including purchases of medical services, among those categories.

A generic event label does not necessarily remove the context. “Lead,” “booking,” or “qualified” may still represent a health-related interaction when joined to the source, campaign, account, timing, or destination. Hashing an email address does not change the purpose or sensitivity of the underlying conversion. An API success response proves transport, not policy permission.

This is why a health organization should start with internal measurement. Keep detailed outcomes inside the approved environment. Use aggregated reporting where it answers the business question. If any Ads conversion route is proposed, review the exact feature, event meaning, identifiers, timestamps, click references, consent state, account type, and current policy. The Google Ads health conversion policy review provides a focused checklist.

Where the Data Manager API fits

Google describes the Data Manager API as a way to send audience and conversion data to multiple Google advertising products. That makes it a transport and destination-management surface for advertising. It does not make Google Ads part of Google Cloud’s covered-product list, and it does not convert a Cloud BAA into permission for the event.

approved internal application
  -> explicit event decision
  -> minimum field allowlist
  -> policy and consent gate
  -> outbound queue
  -> Data Manager API
  -> named Google advertising destination

Every arrow after the internal application deserves its own owner. The event decision defines what the record means. The allowlist prevents a full operational object from leaking into advertising. The policy gate confirms a current written decision. The queue preserves suppression and retry state. The destination record shows where the API sent the event.

For a bounded implementation pattern, see the server-side clinic form architecture. Its central safeguard is fail-closed behavior: no external delivery when policy, approval, field eligibility, or destination is unknown.

A decision gate before any Ads connection

  1. Name the Google Cloud boundary. List services, features, projects, regions, agreement version, and administrative accounts.
  2. Name the advertising destination. Record the exact Google Ads customer, conversion action, API surface, data owner, and purpose.
  3. Describe the event in plain language. State what real-world action it represents. Do not rely on a generic technical label.
  4. Inspect every field. Include identifiers, hashes, click references, timestamps, values, URLs, metadata, logs, and retry payloads.
  5. Review current policy and law separately. Preserve retrieval dates, questions, approvals, and unresolved limits.
  6. Test suppression first. With synthetic events, prove that missing approval, unexpected fields, wrong destination, or denied consent stops before the outbound queue.
  7. Reconcile delivery. If the route is approved, distinguish queued, sent, accepted, rejected, suppressed, and reported states.

This gate should produce a bounded decision, not a permanent certificate. Reopen it when the form changes, an Ads feature changes, a new identifier is added, ownership moves, policy is revised, or the meaning of the conversion changes. The separate BAA scope evaluation method can be reused for the Cloud side without blurring the advertising side.

Common boundary failures

  • Treating “Google” as one product scope across Cloud, Analytics, Ads, support, and third-party integrations.
  • Assuming a Cloud Run or storage configuration controls what Google Ads does after receipt.
  • Sending the full form or operational record because the server already has it.
  • Calling hashed contact details anonymous without assessing linkability, purpose, and policy.
  • Using a successful Data Manager response as evidence of contractual or policy approval.
  • Leaving a browser tag active beside a reviewed server-side route.
  • Logging rejected payload contents instead of a safe reason code.

The smallest defensible design has one internal event definition, one explicit outbound gate, one allowed field set, one named Ads destination, and one reconciliation record. If the external use is not approved, stop at internal or aggregate measurement. Technical capability is not a reason to widen the flow.

What can be claimed after review?

Use evidence-specific language. You may be able to say that the provider page listed a Google Cloud service on a given date, that the organization accepted an agreement, or that a synthetic test blocked an unexpected field. You may separately document that counsel and the policy owner reviewed a named advertising use against current sources.

Avoid claiming that Google Cloud, Google Ads, the Data Manager API, or the architecture is compliant in the abstract. Product lists, policies, configurations, contracts, and uses change. Keep the source date beside the conclusion, preserve open questions, and make reapproval a deployment condition when the boundary changes.

Frequently asked questions

Does accepting Google Cloud’s BAA cover a Google Ads account?

No. The Google Cloud agreement applies to its stated Google Cloud scope. Google Ads is a separate destination with separate terms, policies, configuration, and review.

Does running the connector on Cloud Run change that answer?

No. The runtime may sit inside the reviewed Cloud boundary, but the API destination remains Google Ads. Assess the outbound event and recipient independently.

Does the Data Manager API approve health-related conversions?

No. Its documentation describes how data reaches advertising products. Eligibility depends on current product policy, the exact use, contracts, consent requirements, and applicable law.

What should happen when the policy answer is unclear?

Keep external delivery disabled. Measure internally or in aggregate while qualified policy, privacy, security, and legal reviewers assess the exact event and field set.

References

Appointment Source vs Marketing Source: Why a Practice Needs Both

cmsapointoo on August 16, 2026

Appointment source and marketing source answer different questions. One records where a booking entered the schedule. The other records which channel, campaign, or session influenced the visit beforehand. A practice needs both because one scheduler can receive demand from many campaigns, while a single campaign can produce bookings through several operational routes.

Putting both answers in one field creates false confidence. A booking made through the website scheduler does not automatically count as direct traffic, and staff entry does not prove offline marketing. Keep each source close to the system that observed it, then reconcile the results in an aggregate report.

What is an appointment source?

Appointment source is an operational field. Under a documented clinic rule, it identifies how the booking reached the scheduling system. Useful values might include website scheduler, Google Business Profile link, marketplace, staff-entered phone booking, referral workflow, or walk-in entry.

The scheduler or the integration that created the booking is usually authoritative for this field. Record observed system behavior rather than a staff member’s assumption about what prompted the call. If the schedule cannot distinguish two entry routes, use a broader category or unknown.

Google’s Business Profile guidance shows why this field matters. Google says selected third-party providers can place booking links on Search and Maps, while a business can also add its own local link. Both clicks may begin on Google, yet the bookings can enter different scheduling systems. The guide to booking-link control on Google Business Profile explains that shared surface.

What is a marketing source?

Marketing source describes an attributable interaction before the appointment was created. Depending on the approved measurement design, that may be paid search, organic search, email, referral, or direct traffic. A campaign field can hold a stable reference when the evidence survives the journey.

The source should come from the marketing session or another approved attribution record. It should not be reconstructed from the appointment source. A website booking can follow an advertisement, an organic result, an email, or a bookmarked page. The operational destination stays the same while the marketing path changes.

Marketing source also has limits. Browser restrictions, consent choices, cross-device behavior, and vendor handoffs can break the chain. Use unknown rather than filling a gap with the most likely channel. An honest unknown preserves the report’s meaning.

Why can the two sources disagree without either being wrong?

The fields observe different moments. Someone may find the practice through paid search, read the website, then use the Google Business Profile booking action later. The supported marketing record can point to paid search while the appointment source points to a provider link on Google. Both can be correct.

Another journey may begin with a marketplace listing and end later in the practice’s own scheduler. The appointment source is then the website scheduler. Depending on the available evidence and attribution rule, the marketing source may be direct, referral, marketplace, or unknown.

Zocdoc states that its Appointment Report shows booking source, appointment outcomes, and Marketplace activity. That is a vendor description of its own reporting, not a universal definition or an independent performance finding. It still illustrates that a booking platform’s source field and a practice’s wider marketing model occupy different scopes.

What fields should the practice store?

Keep the source dictionary small enough for staff and analysts to explain. The appointment record needs an operational source code created by the schedule or approved workflow. The marketing record needs separate channel and campaign fields, along with a rule version and capture time. Neither record needs sensitive or clinical detail.

Field Question answered Preferred owner Fallback
appointment_source Where did the booking enter the schedule? Scheduler or booking integration unknown
marketing_channel Which supported channel influenced the visit? Approved attribution record unknown
campaign_reference Which campaign evidence was retained? Marketing capture service not available
source_rule_version Which classification rule applied? Reporting model current documented version
captured_at When was the source observed? Source system source timestamp

Do not overload one field with labels such as “Google.” That could mean a paid campaign, an organic result, a Business Profile link, or a third-party provider shown on Google. Store the most specific supported value in the correct field and retain the broader reporting group separately.

How should booking vendors fit into the model?

A vendor may fill several roles. It can run the schedule, create the booking, generate discovery, or do more than one of these. Classify each role explicitly. A marketplace may generate discovery and create the booking, while a scheduler embedded on the practice website may create bookings without being the marketing source.

Doctoralia’s Brazilian page presents its free clinic offering as a way to simplify scheduling workflow and manage agendas. It also promotes reputation and other commercial benefits. These are vendor claims about its own product. They do not prove that every plan exposes the source fields a particular practice needs.

Ask each vendor to demonstrate source capture with a controlled journey. Check how it labels a website booking, a Google profile link, a marketplace booking, and a staff-entered appointment. Confirm export access and whether source values survive rescheduling. Practices comparing marketplace roles can use the Zocdoc alternatives guide for existing demand as a decision frame.

How do you reconcile source data with appointment outcomes?

Inside the approved reporting environment, join only the source facts needed for generic booking outcomes. The schedule remains authoritative for created, canceled, rescheduled, and attended states. The attribution record remains authoritative for the marketing evidence it captured.

  1. Freeze the source dictionaries and rule version for the reporting period.
  2. Deduplicate bookings under the scheduler’s stable lineage.
  3. Map each booking to its observed appointment source.
  4. Attach marketing source only when a supported link exists.
  5. Keep missing evidence as unknown or not available.
  6. Aggregate by source pair and outcome before sharing the report.

Do not make the advertising platform the appointment system of record. Delivery or attribution status does not prove that a booking occurred, remained scheduled, or was attended. The clinic booking outcome taxonomy provides a compact set of states for that reconciliation.

Which questions does a two-source report answer?

A cross-tab connects discovery with operations. Put marketing channels in the rows, appointment sources in the columns, and aggregate booking outcomes beneath the matrix. The practice can then see whether a channel tends to produce website bookings, marketplace bookings, profile-link bookings, or staff-entered calls.

The same report can show where measurement breaks. A campaign may create visits but leave few supported links between marketing and booking. A provider may receive many appointments whose marketing source is unknown. Those patterns suggest measurement gaps or handoff problems, not automatic campaign failure.

Treat the report as a guide for the next test, not a way to assign personal credit. Which booking routes serve demand the practice already creates? Which campaigns depend on staff entry? Where does source evidence disappear? Which provider produces outcomes the schedule can reconcile consistently?

Common classification mistakes

  • Calling every website booking direct traffic.
  • Calling every Google profile booking organic search.
  • Using a vendor name as both marketing and appointment source without evidence.
  • Replacing unknown values with the campaign that spent the most.
  • Changing source labels during a reporting period without versioning.
  • Counting a reschedule as a new acquisition.
  • Using advertising delivery as proof of an appointment outcome.

Review a sample of source pairs with reception and marketing staff. The goal is not to eliminate every unknown. It is to make each reported value traceable to a system, rule, and timestamp.

Frequently asked questions

Is a Google Business Profile booking a marketing source?

It can be an appointment source when the booking entered through that link. The supported marketing source may be organic, paid, direct, referral, or unknown. Do not infer it from the booking button alone.

Should staff choose a campaign when entering a phone booking?

Only when the practice has a clear, approved question and a documented answer rule. Otherwise record the appointment as staff-entered and leave marketing source unknown rather than encouraging guesses.

Can one appointment have more than one marketing source?

A journey can contain several interactions. The report should apply one documented attribution rule or present separate first-touch and last-supported fields. It should not mix models in one unlabeled column.

Does a vendor source report replace the practice’s attribution model?

No. A vendor report covers the interactions and bookings visible to that vendor. The practice still needs rules for its website, profile links, campaigns, calls, and unknown paths.

References