No-Show Rate by Original Booking Source: An Internal Reporting Formula

cmsapointoo on August 16, 2026

Calculate no-show rate within each original booking-source cohort. Use finalized no-shows as the numerator and finalized attended appointments plus finalized no-shows as the denominator. Multiply by 100. Keep cancellations, reschedules, future appointments, and open records outside both sides of the formula, then report them separately.

This is an editorial measurement contract for clinic-owned reporting. Zocdoc documents no-show as a distinct post-appointment status and keeps cancellation and rescheduling as separate actions. NHS England publishes an outpatient DNA definition that excludes cancelled appointments from its denominator. Neither source defines the clinic’s booking-source segmentation.

What is the internal no-show-rate formula?

For one original booking source and one defined cohort, use this contract:

no_show_rate = finalized_no_shows / (finalized_attended + finalized_no_shows) * 100

The formula compares two terminal outcomes that answer the same attendance question. The patient either attended under the clinic’s rule or the appointment was finalized as no-show. Records without a final attendance answer stay outside the denominator.

Do not call the result a vendor metric unless the vendor documents the same numerator, denominator, exclusions, time window, and source grouping. This article defines an internal report. The booking system supplies states; the clinic supplies the measurement contract.

What do the official sources establish?

Zocdoc’s Appointment Actions page says a post-appointment status can be updated to arrived or no_show. It defines no_show as the patient not showing up for the scheduled appointment and limits that API action to a stated period after the appointment. The same page documents cancellation and rescheduling separately.

NHS England’s guidance uses specific national attendance codes for its outpatient DNA numerator. Its denominator is total outpatient appointments under the stated NHS scope, excluding cancelled appointments and specified administrative events. It also advises reading DNA rates beside other markers.

Those facts support separating attendance, no-show, cancellation, and rescheduling. The NHS code set is not a universal definition for private clinics, dental practices, or other jurisdictions. Copy the separation principle, then document the clinic’s own eligible population.

Which appointments enter the denominator?

Include only appointments whose scheduled time has passed and whose attendance outcome is final under the clinic’s rule. In the compact model used here, that means finalized attended and finalized no-show records.

Appointment state Numerator Denominator Separate report
Finalized no-show Yes Yes No-show count
Finalized attended No Yes Attended count
Cancelled No No Cancellation count and rate
Rescheduled placeholder or superseded slot No No Reschedule count
Future appointment No No Open pipeline
Past appointment with unresolved status No No Data-quality queue
Test or duplicate record No No Excluded-record audit

The clinic booking outcome taxonomy helps keep these states distinct. Adapt its terms to the operational schedule, then freeze the definitions for the reporting period.

Why group by original booking source?

Original booking source describes where the appointment first entered the schedule. It stays stable when the patient later calls, opens a portal, or asks reception to move the time. Grouping by latest action channel would shift rescheduled bookings into phone or portal cohorts and distort acquisition comparisons.

Marketing source is another field. A website scheduler can receive demand from paid search, organic search, email, or an unknown journey. Report no-show rate by booking source first. Add marketing source as a second approved dimension only when evidence and cohort size support it.

The guide to appointment source versus marketing source explains the two axes. Do not merge them into a broad label such as “Google” or “online.”

How should reschedules be counted?

A reschedule is not a final attendance outcome. Exclude a superseded time slot from both numerator and denominator, keep one booking lineage, and evaluate the final eligible appointment after its new time passes.

If the scheduling product updates one record, the lineage may be straightforward. If it cancels one record and creates another, use a tested clinic-owned rule to connect them. Do not count both records as independent attendance opportunities unless the operational facts show that they were separate appointments.

Preserve the original booking source across the lineage. The article on reporting by original lead cohort shows why later state changes should mature a cohort instead of moving records between acquisition periods.

Why report cancellations and open records separately?

Exclusion does not mean disappearance. A source with a low no-show rate may still have a high cancellation rate. Another may have many future appointments whose outcomes have not matured. Publishing only the no-show percentage can hide both conditions.

Place counts beside the rate: finalized attended, finalized no-show, cancelled, rescheduled, future, unresolved, duplicate, and total received. Readers can then see why the denominator differs from the booking total.

Use the same observation cutoff for every source. Late status updates should enter the next refresh or a documented restatement. Do not freeze favorable sources early while waiting longer for unfavorable ones.

How do you handle local status mappings?

Create a mapping from each scheduling status to the reporting states. Review it with operations because names can be misleading. “Completed” may mean that staff closed a record rather than that the patient attended. “Confirmed” is not an attendance outcome.

  1. List every source status observed in the period.
  2. Assign each to attended, no-show, cancelled, rescheduled, future, unresolved, test, or duplicate.
  3. Record who approved the mapping and when it takes effect.
  4. Reject unmapped statuses from the formula.
  5. Version the rule when the vendor or clinic workflow changes.

Never coerce an unknown status into attended to complete the report. An unresolved count is useful evidence about data quality.

What should the final report show?

Show source, cohort window, observation cutoff, numerator, denominator, rate, excluded counts, rule version, and last source update. Avoid rankings when one source has too few finalized records for a useful comparison.

Keep the report aggregate. Patient identifiers, appointment notes, visit reasons, treatment details, and free text do not belong in a marketing view. If the clinic needs to investigate a data-quality exception, route it to an authorized operational workflow.

No-show rate is one operational measure. Review it beside cancellations, reschedules, booking volume, and cohort maturity, as NHS England’s guidance also recommends using multiple markers when assessing DNA improvement.

A validation checklist before publication

  • The formula uses finalized no-show over finalized attended plus no-show.
  • Every row belongs to one original booking-source cohort.
  • Cancelled, rescheduled, future, and open records are excluded from both sides.
  • Excluded outcomes remain visible as separate counts.
  • Duplicate and test records are removed under a documented rule.
  • Unmapped statuses fail closed into a review queue.
  • All sources use the same cohort and observation cutoff.
  • The report names its rule version and system of record.

Frequently asked questions

Should cancellations count as no-shows?

No under this model. Report cancellations separately and exclude them from the no-show numerator and denominator. NHS England also excludes cancelled appointments from its national outpatient DNA denominator.

Should future appointments enter the denominator?

No. Their attendance outcome is not final. Keep them in an open-pipeline count and include them only after the scheduled time passes and the clinic records a final eligible status.

Does a rescheduled appointment create two denominator records?

Not when both records represent one appointment lineage. Exclude the superseded slot and count the final eligible appointment once. Document how the integration links vendor records.

Is the NHS formula mandatory for every clinic?

No. It is an institutional reporting example with a defined scope and code set. A clinic should document its own contract and avoid presenting a local method as a legal or universal standard.

References

How to Preserve Original Marketing and Booking Source After a Reschedule

cmsapointoo on August 16, 2026

A reschedule should change the appointment time and workflow status without rewriting how the booking was first acquired or where it first entered the schedule. Keep original marketing source and original booking source immutable. Record the latest action channel and reschedule history in separate fields.

This is an editorial data-design rule, not a claim about a vendor’s built-in attribution. Zocdoc documents rescheduling an existing appointment through its appointment identifier, while Doctoralia describes reschedule, confirmation, and cancellation capabilities. Neither source says it preserves the clinic’s original marketing or booking-source fields.

What do the vendor sources actually establish?

Zocdoc’s Appointment Actions documentation shows a reschedule request for an existing appointment_id with a new start_time. It lists appointment states in which a reschedule can be requested and treats cancellation and post-appointment status updates as separate actions.

Doctoralia’s Brazilian page says clinic staff can reschedule, confirm, and cancel appointments in its agenda. It also describes reminders that let patients reschedule or cancel when needed. These are product-capability statements from the vendor.

Neither page defines original marketing source, original booking source, latest action channel, or an attribution-preservation policy. The field model below is therefore an editorial recommendation for clinic-owned reporting. Do not present it as a feature that Zocdoc or Doctoralia supplies automatically.

Which facts should stay immutable?

Keep facts that describe the first supported acquisition and booking event unchanged. The original marketing source records the campaign or channel evidence accepted when the booking was created. The original booking source records where that booking entered the schedule, such as the clinic website, a marketplace, a Business Profile link, or staff entry.

A reschedule answers a different question: how did the appointment’s time change? It may happen through a patient portal, a phone call, the front desk, or a vendor workflow. That action belongs in a new field and event record.

Field Meaning Update rule
original_marketing_source First supported acquisition channel or campaign Write once; correct only through an audited data-quality process
original_booking_source Route that first created the booking Write once
booking_lineage_id Opaque identifier for one appointment lineage Stable across reschedules
current_start_time Latest scheduled time Update after an accepted reschedule
current_status Current operational state Update from the scheduling system
latest_action_channel Channel used for the latest change Update for each action
reschedule_history Dated sequence of approved changes Append, never replace

The distinction builds on the existing guide to appointment source versus marketing source. Those two sources already answer different questions before a reschedule occurs.

How should a reschedule update the record?

Update the current time, current status, action timestamp, actor class, and latest action channel. Append an event to the reschedule history. Keep the booking lineage and original-source fields unchanged.

  1. Receive the reschedule from the authoritative scheduling workflow.
  2. Match it to the stable booking lineage.
  3. Record the prior and new scheduled times.
  4. Update the current operational projection.
  5. Append the action channel and source timestamp.
  6. Leave original marketing and booking source untouched.
  7. Send ambiguous or unmatched events to review.

Do not create a second acquisition merely because the patient used a different channel to move the appointment. A phone reschedule does not turn an original website booking into a phone-acquired booking. It records a later phone action.

Why does overwriting the source damage reporting?

Overwriting moves bookings between cohorts after acquisition. A campaign may appear to lose a booking when reception reschedules it, while the phone channel appears to gain one it did not acquire. The total remains the same, but the source report changes for the wrong reason.

The error also hides operational work. If the source field changes from website to phone, the report can no longer distinguish online acquisition from a later reception action. Keeping latest_action_channel separate shows both facts.

Original-source reporting needs a stable cohort. The article on reporting the clinic funnel by original lead cohort explains why today’s status totals cannot replace the group that first entered during a defined period.

What if the vendor creates a new appointment?

Some workflows may update one appointment, while others may cancel an old record and create another. Do not assume the behavior. Test the actual integration and define a lineage rule that connects the records when the clinic has reliable evidence that they represent one reschedule.

Keep each vendor identifier as observed. Add a separate clinic-owned lineage identifier instead of changing the vendor key or using patient details as the join. The lineage should be opaque and should not encode a name, phone number, treatment, or appointment note.

If the new record cannot be linked safely, leave it unresolved. A queue for ambiguous cases is better than an automatic merge that combines two people or two unrelated appointments.

How do booking status and attribution stay separate?

The scheduling system owns current appointment status. The approved attribution record owns marketing evidence. The booking integration owns the observed operational entrance. A reporting job can combine these facts without giving one system authority over all three.

Use a small status vocabulary for reporting. Created, rescheduled, cancelled, attended, and no-show need separate definitions and transition rules. The clinic booking outcome taxonomy provides a starting point for those operational states.

A status update should never manufacture a marketing source. It also should not erase one. When the campaign link is unavailable, keep the marketing source unknown even if the appointment source remains known.

How should corrections differ from reschedules?

A genuine data correction can change an original source, but it needs a reason, reviewer, previous value, new value, and timestamp. That is different from the normal reschedule workflow. Restrict correction access and report corrections separately.

For example, a parser defect may have classified every Business Profile provider booking as website. Fixing that defect may justify a controlled backfill. A patient moving an appointment from Tuesday to Thursday does not.

Do not let staff use source correction as a convenient way to describe the latest conversation. Give them an action-channel field that fits the real task.

What should a source-preservation test cover?

  • Create a booking through each supported operational route.
  • Capture the original marketing source only where evidence exists.
  • Reschedule through the patient flow and through reception.
  • Confirm that current time and latest action channel change.
  • Confirm that original marketing and booking source do not change.
  • Check cancellation followed by a new booking under the documented lineage rule.
  • Replay the same vendor update and verify it does not duplicate history.
  • Review an unmatched reschedule and confirm it does not merge automatically.

Store the test date, vendor configuration, rule version, and expected values. A passing test proves the clinic’s implementation at that moment. It does not prove every future vendor release behaves the same way.

Frequently asked questions

Should a phone reschedule change the booking source to phone?

No. Keep the original booking source and record phone as the latest action channel. This preserves acquisition reporting while still showing reception workload.

Does Zocdoc guarantee original-source preservation?

The mapped API documentation establishes reschedule and status capabilities. It does not document the clinic field model proposed here. Test the integration and keep the preservation rule inside the clinic’s reporting contract.

Can staff correct an incorrect original source?

Yes, through a restricted correction process with an audit trail. A correction fixes bad evidence. It should not be triggered by a routine reschedule or later patient contact.

Should a reschedule count as a new booking?

Not in this editorial model. It remains one booking lineage. If a vendor creates a new record, connect it only under a tested rule and keep both vendor identifiers.

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

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

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