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

Como preservar a origem original de marketing e agendamento após uma remarcação

cmsapointoo on August 16, 2026

Uma remarcação deve alterar horário e status sem reescrever como o agendamento foi conquistado nem por onde entrou na agenda. Preserve a origem original de marketing e a origem original do agendamento. Registre o canal da ação mais recente e o histórico de remarcações em campos separados.

Essa é uma regra editorial de desenho de dados, não uma promessa de fornecedor. A Zocdoc documenta a remarcação de um agendamento existente por meio do identificador da consulta. A Doctoralia descreve recursos para remarcar, confirmar e cancelar. Nenhuma das fontes afirma que preserva os campos de origem propostos aqui.

O que as fontes dos fornecedores comprovam?

A documentação Appointment Actions da Zocdoc mostra uma requisição de remarcação para um appointment_id existente, com um novo start_time. Ela lista os estados em que a ação pode ser solicitada e mantém cancelamento e atualização posterior como operações distintas.

Na página brasileira da Doctoralia, a empresa informa que a equipe pode remarcar, confirmar e cancelar horários na agenda. A página também descreve lembretes que permitem ao paciente remarcar ou cancelar quando necessário. São declarações do fornecedor sobre seus recursos.

As duas fontes não definem origem original de marketing, origem original do agendamento, canal da ação recente ou política de preservação de atribuição. O modelo abaixo é uma recomendação editorial para o relatório da clínica. Não o apresente como comportamento automático da Zocdoc ou da Doctoralia.

Quais fatos precisam permanecer imutáveis?

Preserve os fatos que descrevem a primeira aquisição sustentada e a entrada operacional. A origem original de marketing guarda a evidência aceita de canal ou campanha no momento da marcação. A origem original do agendamento registra por onde a reserva entrou, como site, marketplace, Perfil da Empresa ou recepção.

A remarcação responde a outra pergunta: por qual canal o horário mudou? Ela pode acontecer no portal do paciente, por telefone, na recepção ou no sistema do fornecedor. Essa ação merece um novo evento, não a substituição da origem.

Campo Significado Regra de atualização
origem_marketing_original Primeiro canal ou campanha com evidência sustentada Gravar uma vez; corrigir apenas com auditoria
origem_agendamento_original Rota que criou a primeira marcação Gravar uma vez
id_linhagem_agendamento Identificador opaco de uma linhagem Manter nas remarcações
horario_atual Horário vigente da consulta Atualizar após remarcação aceita
status_atual Estado operacional vigente Atualizar pela agenda
canal_ultima_acao Canal usado na alteração mais recente Atualizar a cada ação
historico_remarcacoes Sequência datada de mudanças Acrescentar sem substituir

O guia sobre origem de agendamento e origem de marketing mostra por que esses dois campos já respondem a perguntas diferentes antes de qualquer remarcação.

Como a remarcação deve atualizar o registro?

Atualize horário atual, status, momento da ação, categoria do responsável e canal mais recente. Acrescente um evento ao histórico. Mantenha a linhagem e as origens originais.

  1. Receba a remarcação pelo fluxo autorizado da agenda.
  2. Associe a atualização à linhagem estável.
  3. Registre horário anterior e novo horário.
  4. Atualize a projeção operacional atual.
  5. Acrescente canal e horário da ação ao histórico.
  6. Não altere as origens originais.
  7. Encaminhe eventos sem correspondência para revisão.

Uma ligação para mudar o horário não transforma uma reserva feita no site em aquisição por telefone. Ela registra uma ação posterior da recepção.

Por que sobrescrever a origem estraga o relatório?

A substituição move marcações entre grupos depois da aquisição. Uma campanha parece perder um agendamento quando a recepção muda o horário, enquanto o telefone parece ganhar uma aquisição que não produziu. O total continua igual, mas a explicação muda sem motivo.

O erro também esconde trabalho operacional. Quando o campo troca de site para telefone, a equipe não consegue separar aquisição online de atendimento posterior. O campo canal_ultima_acao conserva os dois fatos.

Relatórios por origem precisam de grupos estáveis. O artigo sobre funil da clínica por coorte original mostra por que o status atual não pode substituir o grupo que entrou no período analisado.

E se o fornecedor criar outro agendamento?

Alguns fluxos atualizam o registro existente. Outros podem cancelar o antigo e criar outro. Não presuma o comportamento. Teste a integração e escreva uma regra de linhagem que una os registros apenas quando existir evidência confiável de uma remarcação.

Preserve cada identificador do fornecedor. Crie um identificador opaco da clínica para a linhagem, sem alterar a chave externa e sem usar nome, telefone, tratamento ou observação como vínculo.

Se não for possível relacionar os registros com segurança, mantenha o caso pendente. Uma fila de revisão é melhor do que juntar automaticamente duas pessoas ou duas consultas diferentes.

Como separar status da agenda e atribuição?

A agenda responde pelo status atual. O registro aprovado de atribuição responde pela evidência de marketing. A integração informa por onde a marcação entrou. O relatório pode combinar os fatos sem dar autoridade total a um único sistema.

Use poucos estados e defina cada transição. Criado, remarcado, cancelado, comparecimento e falta precisam de significados próprios. A taxonomia de resultados de agendamento oferece uma base para esse dicionário.

Uma mudança de status não deve criar origem de marketing nem apagar uma origem existente. Quando a evidência de campanha não existe, a origem de marketing continua desconhecida, mesmo que a origem operacional seja conhecida.

Como diferenciar correção e remarcação?

Uma correção legítima pode mudar a origem original, mas exige motivo, responsável, valor anterior, valor novo e data. Esse é um fluxo diferente da remarcação comum. Restrinja o acesso e mostre correções em um relatório próprio.

Um defeito no parser pode ter classificado todas as reservas do Perfil da Empresa como site. Corrigir essa falha pode justificar uma atualização controlada. Mudar a consulta de terça para quinta não justifica.

Ofereça à recepção um campo adequado para o canal da ação. Assim, ninguém precisa usar a correção da origem para descrever a última conversa.

O que testar antes de confiar no modelo?

  • Criar uma marcação por cada rota operacional aceita.
  • Guardar origem de marketing somente quando houver evidência.
  • Remarcar pelo fluxo do paciente e pela recepção.
  • Confirmar a mudança de horário e canal da ação.
  • Confirmar que as origens originais permanecem iguais.
  • Testar cancelamento seguido de nova reserva conforme a regra de linhagem.
  • Repetir a mesma atualização e verificar que o histórico não duplica.
  • Revisar uma remarcação sem correspondência e impedir a união automática.

Registre data, configuração do fornecedor, versão da regra e resultado esperado. O teste comprova a implementação naquele momento. Não garante que uma futura versão do fornecedor terá o mesmo comportamento.

Perguntas frequentes

Uma remarcação por telefone muda a origem para telefone?

Não. Preserve a origem inicial e registre telefone como canal da ação mais recente. O relatório continua mostrando a aquisição e também o trabalho da recepção.

A Zocdoc garante a preservação da origem?

A documentação mapeada comprova recursos de remarcação e status. Ela não documenta o modelo de campos proposto aqui. A clínica precisa testar a integração e manter sua própria regra.

A equipe pode corrigir uma origem errada?

Sim, por um processo restrito com trilha de auditoria. A correção resolve uma evidência incorreta. Uma remarcação normal não deve acionar esse processo.

Uma remarcação conta como novo agendamento?

Não neste modelo editorial. Ela permanece na mesma linhagem. Se o fornecedor gerar um novo registro, relacione os dois apenas sob uma regra testada.

Referências

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

Link personalizado vs Reservar com o Google: quais dados de performance de agendamento o Google informa?

cmsapointoo on August 16, 2026

Um link personalizado e o Reservar com o Google podem levar o paciente a um fluxo de agendamento, mas o Google documenta relatórios diferentes para cada rota. Os dados de performance de agendamentos não ficam disponíveis para links personalizados. Quando a agenda é gerenciada por um provedor, o Perfil da Empresa pode mostrar a métrica Agendamentos, que conta ações de reserva concluídas.

Essa contagem não prova que a consulta aconteceu. Também não informa receita, falta, cancelamento ou origem de marketing. A clínica precisa escolher a rota de agendamento e o método de medição ao mesmo tempo, sem transformar uma ação concluída no site em um resultado clínico ou financeiro.

O que o Google documenta para cada rota?

A Ajuda do Perfil da Empresa descreve duas possibilidades. A empresa pode trabalhar com um provedor de agendamento por meio do Reservar com o Google ou adicionar o próprio link ao perfil. Na mesma página, o Google afirma que os dados de performance não estão disponíveis para links personalizados.

Outra página oficial define Agendamentos como o número de reservas concluídas pelas pessoas. Para receber dados dessa métrica, os agendamentos precisam ser gerenciados por um provedor. Esse é o limite factual da comparação.

A documentação não promete a mesma disponibilidade para toda categoria, região, conta ou fornecedor. Antes de escolher uma arquitetura, consulte o perfil verificado da clínica e confirme quais provedores aparecem no país e na categoria aplicável.

Comparação entre link personalizado e Reservar com o Google

Pergunta Link personalizado Agendamento gerenciado por provedor
A clínica pode indicar um destino? O Google permite adicionar um link próprio O Google permite configurar um provedor compatível
Há performance de agendamento no Google? Não, segundo a página de configuração A métrica Agendamentos pode ficar disponível
O que a métrica documentada conta? Não existe métrica de reserva documentada para o link próprio Ações de agendamento concluídas
Comprova comparecimento? Não Não
Mostra receita ou falta? Não documentado Não documentado nas páginas mapeadas
Traz atribuição por campanha? Não como relatório de agendamento do Google Não na definição da métrica

A comparação trata apenas do que as fontes oficiais confirmam. Um fornecedor pode oferecer relatórios próprios, e a clínica pode medir seu link em outra ferramenta. Nenhum desses casos amplia automaticamente a métrica do Perfil da Empresa.

O que uma ação de agendamento concluída comprova?

Ela comprova que o fluxo de reserva chegou ao estado de conclusão reconhecido pela integração do provedor. Não comprova que o paciente compareceu. Comparecimento, cancelamento, remarcação e falta acontecem depois e devem vir da agenda operacional.

A diferença evita um erro simples. O Perfil da Empresa pode registrar reservas concluídas, enquanto a agenda termina o período com consultas realizadas, canceladas, remarcadas e futuras. Chamar todas elas de “consultas concluídas” altera o significado da métrica do Google.

Receita também pertence a outro registro. A documentação não afirma que Agendamentos contém pagamento, valor de tratamento ou faturamento. Para separar resultados posteriores, use uma taxonomia de resultados de agendamento com definições explícitas.

Como medir um link próprio sem inventar um relatório do Google?

O link personalizado pode participar de uma medição controlada pela clínica. Esse desenho fica fora da métrica de performance de agendamentos do Google. A equipe pode preservar um parâmetro aprovado, registrar por onde a marcação entrou e reconciliar resultados agregados no ambiente interno.

Separe origem de agendamento e origem de marketing. A primeira mostra onde a marcação entrou na agenda. A segunda mostra a evidência sustentada de campanha ou canal antes da reserva. O artigo sobre origem de agendamento e origem de marketing explica por que o rótulo “Google” não responde às duas perguntas.

Um clique não é uma marcação, e uma marcação não é comparecimento. Quando a evidência de campanha faltar, registre desconhecido. Não envie detalhes da consulta ou contexto de saúde em parâmetros de URL para tentar completar a atribuição.

Qual rota atende melhor à necessidade da clínica?

Use a rota de provedor quando a integração atende à operação e a contagem de reservas do Perfil da Empresa é útil. Use o link personalizado quando a clínica precisa controlar o destino e consegue operar sua própria medição. A decisão depende da agenda real, não apenas do painel mais atraente.

Teste se a reserva chega à agenda usada pela recepção. Um relatório perde valor quando a marcação cai em um calendário paralelo ou precisa ser copiada manualmente. Controle da conta, exportação, cancelamento, remarcação e recuperação de acesso continuam na análise.

O Perfil da Empresa também pode combinar links cadastrados pela clínica e links enviados por provedores. O guia sobre controle do link no Perfil da Empresa mostra como essas responsabilidades se dividem.

Como escrever o contrato do relatório?

Defina nome, fonte, significado, exclusões e responsável por cada número. “Reservas concluídas no Perfil da Empresa” é melhor do que “consultas do Google”, pois não sugere comparecimento. Uma métrica do link próprio deve indicar qual sistema da clínica observou o clique ou a reserva.

Campo Definição Fonte
reservas_concluidas_perfil Ações concluídas mostradas pela métrica de provedor compatível Performance do Perfil da Empresa
cliques_link_proprio Cliques aprovados sob a regra interna Analytics da clínica
agendamentos_criados Marcações criadas na agenda operacional Sistema de agendamento
consultas_realizadas Marcações elegíveis finalizadas como comparecimento Sistema de agendamento
origem_marketing Evidência sustentada de canal ou campanha Registro de atribuição aprovado

Não some essas linhas sem uma regra de reconciliação. Sistemas podem atualizar em momentos distintos, usar fusos diferentes e contar ações diferentes. O nome da coluna precisa deixar essa diferença visível.

Como testar a rota escolhida?

  1. Confira se o perfil público mostra o destino pretendido.
  2. Crie um agendamento de teste pela rota visível.
  3. Verifique se ele aparece uma única vez na agenda operacional.
  4. Registre o que surge no Perfil da Empresa e em qual momento.
  5. Confira se a agenda preserva a origem operacional aprovada.
  6. Altere ou cancele a marcação e mantenha o novo status separado da reserva original.
  7. Documente lacunas sem preenchê-las com suposições.

Se um link de fornecedor indesejado continuar visível, use o processo específico e depois confira o resultado público. O passo a passo para remover um link de agendamento de terceiros cobre esse controle.

Perguntas frequentes

O Google mede reservas feitas por um link personalizado?

A página de configuração afirma que os dados de performance de agendamentos não ficam disponíveis para links personalizados. A clínica pode criar uma medição própria, mas deve nomeá-la pela fonte real e não pela métrica Agendamentos do Google.

A métrica Agendamentos conta consultas realizadas?

Essa conclusão não aparece nas fontes mapeadas. O Google fala em agendamentos concluídos. O comparecimento é um resultado posterior que precisa ser confirmado pela agenda da clínica.

A métrica mostra receita ou taxa de faltas?

As páginas oficiais usadas aqui não definem receita, pagamento, cancelamento ou falta dentro de Agendamentos. Esses resultados precisam de um relatório interno com denominadores claros.

O Reservar com o Google está disponível para toda clínica?

Não presuma disponibilidade universal. Categoria, país, perfil e suporte do provedor podem alterar as opções. Verifique o perfil da clínica e confirme o funcionamento com o fornecedor escolhido.

Referências

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

Onde devem ficar as ações de conversão da clínica: conta do cliente ou MCC?

cmsapointoo on August 16, 2026

Uma ação de conversão da clínica pode ficar na conta individual do cliente ou em uma conta de administrador do Google Ads usada para acompanhamento de conversões entre contas. Essa escolha não define quem é dono dos dados da clínica, quem pode acessar a conta, nem qual conta aparece em um destino da Data Manager. Tratar tudo como “propriedade” cria confusão justamente quando chega a hora de trocar de agência.

Para uma clínica com uma única conta, manter ações específicas ali costuma facilitar a portabilidade. Essa é uma recomendação editorial, não uma exigência do Google. Ações na MCC servem a grupos que precisam de acompanhamento compartilhado. A arquitetura de formulários e Data Manager cobre o gate anterior ao envio.

Qual decisão a clínica precisa tomar?

A primeira decisão é onde o Google Ads cria e gerencia a ação. A documentação apresenta dois modelos. A ação específica é criada na conta individual e só se aplica a ela. A ação entre contas é criada em uma MCC e pode ser usada por contas gerenciadas selecionadas. Uma conta cliente usa um modelo ou o outro, nunca os dois ao mesmo tempo.

Essa escolha convive com outras três: acesso durável da clínica, permissões limitadas da agência e destino correto na Data Manager. Um plano de saída deve dizer como o acompanhamento muda quando a relação termina.

Pergunta Objeto no Google Ads O que decide
Onde fica a ação? Conta cliente ou MCC Qual conta cria e gerencia a ação
Quem pode trabalhar na conta? Acesso de usuários e gerenciadores Quais pessoas e contas vinculadas podem administrá-la
Quem é dono dos dados? Conta cliente Direitos sobre dados e capacidade de desvincular
Para onde a API envia? Destino da Data Manager Conta receptora, ID da ação e caminho da credencial
O que acontece na saída? Desvinculação e configuração de conversões Qual caminho continua depois da mudança

O rótulo “da agência” é vago. A MCC pode ser dona da ação sem ser dona dos dados, ou estar vinculada sem propriedade administrativa. Nomeie conta, objeto e permissão.

Quando as ações devem ficar na conta do cliente?

Ações específicas funcionam bem para clínicas que precisam manter a configuração dentro de uma única conta. O Google informa que elas são criadas e gerenciadas na conta individual e só valem ali. Se a clínica trocar de agência, os objetos, as configurações e as estatísticas existentes continuam ligados à conta cliente. Essa portabilidade depende de a clínica manter acesso administrativo direto.

O modelo também simplifica a auditoria. A conta cliente é a conta de conversão, a ação pertence a ela e a conta operacional da Data Manager aponta para ela. A agência ainda pode trabalhar por uma MCC vinculada. Usar acesso de gerenciador não obriga a mover a ação para a MCC.

Um grupo com várias contas pode precisar de ações compartilhadas. Mesmo uma clínica perde a vantagem de portabilidade sem administrador próprio. Confirme esse acesso e mantenha um inventário das ações. O relatório de outbox de conversões offline separa entrega e configuração da conta.

Quando o acompanhamento entre contas na MCC faz sentido?

O acompanhamento pela MCC atende uma operação real com várias contas. O Google permite criar ações entre contas na conta de administrador e escolher quais contas gerenciadas as usarão. Isso centraliza definições e relatórios. Não é apenas um atalho para o acesso da agência, pois a conta gerenciada deixa de usar as próprias ações específicas enquanto a MCC estiver selecionada como conta de conversão.

Defina o escopo antes da mudança. Liste as contas que usarão a ação, as metas afetadas, os sites ou aplicativos com tags e a equipe responsável. O Google alerta que a troca de conta de conversão pode alterar as metas padrão usadas por campanhas. Campanhas configuradas para ações específicas precisam de revisão na ida e na volta.

Adote esse modelo por uma necessidade documentada, não porque a agência possui uma MCC. Contas gerenciadas não compartilham ações diretamente; a MCC é o ponto comum. Se um fornecedor externo a controla, documente dependência e saída antes da ativação.

A propriedade da MCC transfere os dados da clínica?

Não. O Google separa propriedade administrativa do gerenciador e propriedade dos dados do cliente. Uma MCC proprietária recebe amplos privilégios administrativos e de acesso a dados, que podem incluir informações pessoais na conta. Mesmo assim, o Google afirma que o cliente continua dono dos próprios dados, preserva direitos administrativos e pode remover o acesso de propriedade ao desvincular a MCC.

O simples vínculo não transforma automaticamente a MCC em proprietária administrativa. Um administrador do cliente precisa habilitar essa condição para uma conta já vinculada. O Google recomenda concedê-la somente quando o gerenciador precisa daqueles privilégios. A documentação da agência deve registrar separadamente se a MCC está vinculada, se tem propriedade administrativa e quais usuários possuem acesso administrativo.

Aplique o menor privilégio e mantenha um administrador da clínica. Não chame a MCC apenas de “dona”. O termo esconde permissões sobre usuários, segurança, outros gerenciadores e dados.

O que continua depois de desvincular a MCC?

A conta cliente mantém o próprio histórico de campanhas e o acesso aos recursos do Google Ads depois da desvinculação. A continuidade das conversões é mais limitada. Na documentação consultada em 16 de agosto de 2026, o Google informa que a tag entre contas deixa de registrar conversões de cliques ocorridos depois da desvinculação. Cliques anteriores ainda podem gerar conversões durante a janela restante, normalmente 30 dias.

Se uma tag antiga da conta cliente continuar instalada, ela pode voltar a registrar, salvo quando outra tag de gerenciador a substitui. A equipe ainda precisa confirmar nova ação, tag ou destino server-side, metas, janela e reconciliação.

Remover a MCC encerra o acesso daquele gerenciador. Isso não cria uma ação substituta, reescreve destinos ou valida metas. A taxonomia de resultados de agendamento mantém o significado do evento durante a troca.

Como a Data Manager separa propriedade e acesso?

Um Destination da Data Manager registra para onde os dados seguem e como a credencial alcança a conta. O operatingAccount é a conta que recebe os eventos. Para conversões offline do Google Ads, o guia Send Events exige que ela seja a conta dona da ação. O productDestinationId identifica a ação de conversão dentro dessa conta operacional.

O loginAccount cumpre outra função. Ele identifica a conta na qual o usuário da credencial possui acesso. Em um cenário com MCC, a conta de login pode ser o gerenciador enquanto a conta operacional é a conta filha dona da ação. O linkedAccount atende cenários documentados de vínculo com parceiro. Nenhum desses campos transfere a ação entre contas.

Mantenha um mapa por clínica com os dois IDs de conta, ação, origem, estado e última verificação. Não reutilize o destino de outra clínica porque ambas estão na mesma MCC. A API aceita vários destinos, mas o isolamento por clínica continua sendo recomendação editorial de segurança.

Um padrão prático de governança

Para uma conta principal, use ações na conta cliente como padrão e dê à agência acesso limitado pela MCC. Reserve ações entre contas para grupos que precisam da estrutura compartilhada e aceitam a dependência. Essa orientação é editorial.

  1. Confirme que a clínica possui acesso administrativo direto.
  2. Liste cada ação, conta proprietária, origem, meta e papel primário ou secundário.
  3. Escolha ações específicas ou entre contas e documente o motivo.
  4. Registre vínculo da MCC separadamente de propriedade administrativa.
  5. Mapeie conta operacional, conta de login e ID da ação na Data Manager.
  6. Isole credenciais, destinos, outbox e evidências de cada clínica.
  7. Escreva e teste a migração antes da troca de agência.

O inventário também deve dizer se a entrega externa é permitida. A localização da ação não corrige uso inelegível de dados de saúde. Consulte a fronteira de elegibilidade para formulários antes de enviar.

Perguntas frequentes

Toda clínica precisa manter ações na própria conta?

Não. O Google oferece ações específicas e ações entre contas na MCC. Para uma clínica com uma conta, manter a ação ali costuma facilitar a portabilidade. Um grupo com várias contas pode ter motivo válido para centralizar ações em uma conta de administrador.

A MCC pode acessar uma ação da conta cliente?

Sim, desde que vínculo e permissões forneçam o acesso necessário. Trabalhar por uma MCC não obriga a criar a ação nela. Registre vínculo, propriedade administrativa e acesso dos usuários como fatos diferentes.

Desvincular apaga o histórico da clínica?

Não. A conta individual mantém o histórico e o acesso aos recursos. O acompanhamento entre contas pode mudar depois da desvinculação, por isso a equipe precisa planejar ação substituta, tag, metas e destino da Data Manager.

A loginAccount é dona da ação?

Não necessariamente. Ela descreve o caminho de acesso da credencial. Nas conversões offline do Google Ads, a operatingAccount deve ser dona da ação e o productDestinationId identifica essa ação.

Referências

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

Reporte o funil da clínica por coorte original de leads, não pelos totais de hoje

cmsapointoo on August 16, 2026

O funil da clínica deve manter cada resultado ligado à coorte original de leads e mostrar o grau de maturidade dessa coorte na data do relatório. Totais de hoje misturam novos formulários, agendamentos de dias anteriores, consultas futuras e aceitações registradas depois. A comparação pode piorar ou melhorar apenas porque cada etapa acontece em um momento diferente.

A coorte original reúne os formulários elegíveis criados no mesmo período declarado. Agendamento, comparecimento e aceitação continuam ligados a esses leads, mesmo quando ocorrem mais tarde. O relatório precisa da data da coorte e de uma data de corte. Sem as duas, o leitor não distingue um resultado fraco de outro ainda incompleto.

Por que os totais de hoje distorcem o funil?

O gasto aparece cedo, mas os resultados da clínica amadurecem em ritmos diferentes. Um formulário pode virar agendamento depois. A consulta pode estar marcada para outra semana, e a aceitação pode ser registrada após o atendimento. Dividir as aceitações de hoje pelos formulários de hoje compara grupos diferentes.

O guia do Google sobre atraso de conversão mostra o mesmo problema dentro do Google Ads. O desempenho recente pode parecer pior porque o custo já foi contabilizado, enquanto algumas conversões ainda não chegaram. Conforme a janela configurada, a plataforma pode registrar conversões até 90 dias depois do clique. Esse é um fato sobre o Google Ads, não um prazo universal para a clínica.

Antes do relatório, adote uma taxonomia estável de resultados de agendamento. Os estados agendado, realizado e aceito precisam manter o mesmo significado no período analisado. A coorte organiza os dados, mas não corrige definições inconsistentes.

O que deve definir a coorte original de leads?

Escolha o primeiro evento elegível controlado pela clínica que possa ser reproduzido, normalmente o recebimento válido de um formulário. Atribua a coorte pela data e hora de criação desse evento. Não mova o lead para outra coorte quando houver agendamento, comparecimento, remarcação ou aceitação.

Campo Função Regra
ID opaco do lead Liga eventos posteriores sem exibir nomes no relatório Permanece estável no ciclo do lead
Data original do lead Define a coorte Não é substituída por uma etapa posterior
Período da coorte Agrupa leads comparáveis Usa fuso e calendário declarados
Data de corte Mostra quando as contagens foram observadas Fica guardada em cada execução
Datas das etapas Medem os atrasos operacionais Separam agendamento, comparecimento e aceitação

Registre as regras de elegibilidade. Testes, duplicidades, spam, unidades não atendidas e demais exclusões devem ter tratamento explícito. Quando uma regra mudar, crie uma nova versão. Não reescreva uma coorte antiga sem deixar rastro, pois ninguém saberá se o desempenho ou o denominador mudou.

Como o Google separa o tempo da consulta do anúncio e da conversão?

O Google Ads pode posicionar o mesmo resultado em datas diferentes. A documentação dos relatórios de atribuição informa que esses relatórios usam o momento da conversão. A página padrão de Campanhas costuma atribuir a conversão à consulta do anúncio anterior ao clique que levou ao resultado. A página também oferece colunas por tempo da conversão.

Essa diferença altera a data exibida sem alterar o evento subjacente. O relatório da clínica deve indicar qual base temporal do Google foi usada para gasto e conversões. Não chame uma tabela por tempo do clique de coorte de leads se as linhas internas não foram agrupadas pela data original do lead.

A clínica adota outro ponto de referência: o primeiro lead elegível. O tempo da consulta do anúncio localiza a interação anterior ao clique; o tempo da conversão localiza a ação rastreada. Nenhum deles reúne automaticamente agendamento, comparecimento e aceitação sob a coorte original. Essa junção pertence ao relatório interno.

Como ligar as etapas do funil?

Mantenha uma chave estável durante o fluxo interno. O agendamento aponta para o lead. O comparecimento aponta para o agendamento elegível, e a aceitação aponta para o atendimento conforme a definição da clínica. Preserve a primeira data válida de cada etapa e registre correções posteriores.

coorte original de leads
  -> formulário elegível recebido
  -> agendamento elegível criado
  -> consulta realizada
  -> caso aceito

A remarcação precisa de uma regra declarada. O lead continua na coorte original, embora a data atual da consulta possa mudar. Cancelar e agendar novamente não deve criar outro lead, salvo quando a regra documentada tratar o novo pedido como procura nova. A distinção entre origem do agendamento e origem de marketing também permanece sem trocar a coorte.

Quais taxas entram no relatório?

Mostre as contagens antes das taxas e dê nome a cada denominador. As fórmulas abaixo são orientação editorial para o relatório. Não são cálculos do Google Ads. Use somente registros elegíveis ligados à mesma coorte original e observados na mesma data de corte.

taxa de agendamento
= leads com agendamento elegível / leads originais elegíveis

taxa de comparecimento
= consultas realizadas elegíveis / agendamentos elegíveis

taxa de aceitação após comparecimento
= casos aceitos / consultas realizadas elegíveis

taxa de aceitação de ponta a ponta
= casos aceitos / leads originais elegíveis

Não compare taxas com filtros diferentes. Uma taxa de comparecimento de toda a agenda não explica uma campanha se a coorte contém apenas leads de formulário. O método de comparecimento por campanha mostra como preservar atribuição agregada sem enviar detalhes da consulta para uma plataforma publicitária.

Calcule cada taxa somente quando o denominador declarado for maior que zero. Mostre N/D quando a coorte não tiver leads, agendamentos ou consultas realizadas elegíveis para aquela taxa. Preserve a contagem zero, mas não apresente uma razão indefinida como 0%.

Como definir a maturidade da coorte?

A maturidade vem do tempo observado pela clínica até cada etapa. Meça o intervalo entre lead e agendamento, entre agendamento e consulta, e entre consulta e aceitação em coortes antigas já completas. Escolha uma janela documentada para a pergunta do relatório. Uma coorte pode estar madura para agendamento e imatura para comparecimento ou aceitação.

idade da coorte
= data de corte - fim do período original da coorte

maturidade da etapa
= comparação entre idade da coorte e janela documentada de atraso observado

O Google recomenda encerrar um relatório de atraso pelo menos 30 dias antes, ou usar um período maior quando a janela de conversão for maior. Essa instrução trata da completude no Google Ads. Ela não cria uma regra clínica de 30 dias. Prazo até a consulta e rotina de acompanhamento podem exigir outra janela, comprovada pelos registros locais.

O que a tabela final deve mostrar?

Dê a cada coorte uma linha por data de corte ou preserve um histórico de versões. Inclua leads originais, agendamentos, consultas realizadas, casos aceitos, taxas, idade da coorte e rótulos de maturidade. Acrescente gasto e dimensões de marketing apenas quando a base temporal e a atribuição estiverem claras.

Coorte Data de corte Leads Agendados Realizados Aceitos Maturidade
Período original do lead Fechamento do relatório Contagem elegível Contagem ligada Contagem ligada Contagem ligada Rótulos por etapa

Mantenha as linhas imaturas visíveis, mas não as classifique como completas. Rótulos como em desenvolvimento, madura para agendamento ou madura até aceitação são mais honestos que preencher resultados ausentes com suposições. Se houver previsão, coloque-a em colunas separadas e identifique o método.

Como revisar o relatório com a clínica?

Compare coortes depois de conferir versão das definições, cobertura das fontes, data de corte e maturidade. Investigue mudanças pelas contagens. Uma taxa menor pode nascer de menos eventos posteriores, denominador maior, importação atrasada ou alteração de regra.

Guarde cada relatório com horário de extração e estado das fontes. Atualize coortes anteriores quando resultados tardios chegarem, mas mantenha a fotografia antiga para auditoria. A conversa fica objetiva: a coorte madura gerou menos agendamentos, comparecimento menor ou aceitação menor sob as mesmas definições?

Perguntas frequentes

Coorte original de leads é igual à coorte de cliques do Google Ads?

Não. A coorte da clínica começa no evento elegível declarado. A página Campanhas pode usar o tempo da consulta anterior ao clique ou colunas por tempo da conversão. Registre a escolha separadamente e não substitua a data original do lead.

Posso dividir as aceitações de hoje pelos formulários de hoje?

Não. Esses grupos costumam reunir pessoas e idades de funil diferentes. Ligue cada caso aceito à sua coorte original de leads elegíveis e calcule a taxa dessa coorte na data de corte.

O Google exige maturidade clínica de 30 dias?

Não. O Google descreve uma verificação de 30 dias ou mais para relatórios de atraso de conversão da plataforma. A maturidade clínica vem dos atrasos observados entre agendamento, consulta e aceitação. Use janelas diferentes por etapa quando os dados justificarem.

Uma coorte imatura pode aparecer no relatório?

Sim. Mostre as contagens atuais e aplique um rótulo claro. Não compare as taxas incompletas com coortes maduras sem explicar a diferença. O histórico de datas de corte mostra como cada coorte evoluiu.

Referências

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

O relatório de outbox de conversões offline que toda agência deve mostrar aos clientes

cmsapointoo on August 16, 2026

Um relatório de conversões offline deve mostrar aquilo que a agência consegue provar, em vez de resumir tudo em um percentual tranquilizador de entrega. Um bom relatório separa o ledger local do outbox, a requisição inicial da Data Manager, os diagnósticos posteriores por destino, a observação no Google Ads e a atribuição. São evidências diferentes, coletadas em momentos diferentes.

Este formato é uma recomendação editorial. AWS e Google documentam os mecanismos, mas não prescrevem um relatório para clientes. A agência define a apresentação e limita cada conclusão à evidência disponível.

Por que o cliente precisa de evidências separadas?

O cliente precisa saber quais resultados offline estão aguardando, o que a agência enviou, o que o Google ainda processa e o que falhou. Uma contagem única de uploads esconde essas diferenças. Também pode transformar uma resposta HTTP em alegação sobre relatório ou atribuição que a resposta não comprova.

O relatório responde a quatro perguntas. A transação de origem criou um evento local durável? O worker recebeu uma resposta inicial bem-sucedida e guardou o ID da requisição Google? Qual estado terminal o Google devolveu para cada destino? Uma verificação separada encontrou a conversão na conta e janela esperadas do Ads?

A atribuição forma uma quinta camada. Um destino pode concluir o processamento sem produzir o crédito de campanha que a agência esperava. O guia de diagnósticos trata da saúde do upload e de problemas nos dados. Não transforma uma requisição processada em prova de atribuição, uso em lances ou impacto comercial.

Para entender a fronteira anterior ao relatório, consulte a arquitetura server-side para formulários e Data Manager. Ela mantém a saída bloqueada até a aprovação do uso exato. O relatório desta página documenta confiabilidade depois dessa aprovação. Ele não cria permissão para enviar.

Construa primeiro o ledger local do outbox

O AWS Prescriptive Guidance apresenta o transactional outbox como solução para o problema de escrita dupla. A aplicação grava o estado de negócio e o evento de outbox na mesma transação. Outro processo lê apenas registros confirmados e envia a mensagem. Se a transação de origem for revertida, a notificação não deve sair.

O relatório para o cliente não precisa do registro de origem. Dê a cada resultado elegível um ID local opaco e uma versão do resultado. Guarde horário de criação, estado local, número de tentativas, próxima tentativa, base de deduplicação e referência do destino. O payload operacional fica fora do relatório.

Campo local Significado Exibir ao cliente?
ID opaco do evento Referência estável criada pelo sistema da agência Sim
Versão do resultado Estado aprovado que originou o evento Sim
Estado local Na fila, enviando, enviado, nova tentativa, suprimido ou em quarentena Sim
Tentativa e próxima execução Atividade do worker local Sim
Payload de origem Dados do sistema operacional Não
Campos excluídos Conteúdo de saúde, identidade e texto livre Não

Defina enviado de modo estreito. Significa que o worker recebeu uma resposta inicial bem-sucedida da Data Manager e guardou o ID da requisição. Não significa que o Google terminou o processamento. Também não diz nada sobre presença no relatório do Ads ou atribuição.

Mantenha a requisição Google em outro ledger

O guia Send Events do Google informa que uma requisição inicial bem-sucedida devolve um requestId. O guia de diagnósticos descreve esse sucesso com código 0, enum OK e HTTP 200 OK. Guarde o ID. Não dê à resposta inicial um nome que sugira resultado final.

O ledger Google usa uma linha por requisição e destino, não uma linha por evento local. Guarde ID da requisição, referência do destino, horário do envio, primeira consulta, estado atual, contagem de registros, contagens de avisos e erros e último horário consultado. Se uma requisição tiver vários eventos ou destinos, preserve a estrutura do lote.

Camada de evidência Responsável O que ela comprova
Estado do outbox Agência O que o worker local registrou
Sucesso HTTP e request ID Data Manager API Sucesso da requisição inicial de ingestão
Diagnóstico do destino Data Manager API Processamento posterior da requisição naquele destino
Observação no Ads Verificação da agência O que apareceu no relatório e período escolhidos
Observação de atribuição Modelo do Ads Crédito observado sob configurações declaradas

O record_count dos diagnósticos inclui registros bem-sucedidos e com falha. Avisos e erros aparecem como contagens por motivo. Essa evidência é agregada. Se um lote de dez eventos chegar a PARTIAL_SUCCESS, mostre o total e as contagens de erro. Não marque um ID opaco específico como sucesso ou falha sem uma resposta do fornecedor que faça essa ligação.

Use os estados oficiais do destino

O Google documenta quatro estados: PROCESSING, SUCCESS, PARTIAL_SUCCESS e FAILURE. Preserve esses nomes no ledger do fornecedor. Não os comprima em um campo chamado aceito. A palavra pode significar resposta HTTP inicial, destino concluído ou conversão visível, três coisas diferentes.

Em PROCESSING, avisos e erros ainda não estão preenchidos. SUCCESS indica conclusão sem erros, mas ainda pode conter avisos sobre dados ignorados. FAILURE indica falha de todos os registros naquele destino. PARTIAL_SUCCESS reúne sucessos e falhas no lote.

Na documentação consultada em 16 de agosto de 2026, o Google recomenda esperar 30 minutos antes da primeira consulta de diagnóstico. Depois, a equipe deve usar intervalos crescentes, com backoff exponencial, até todos os destinos chegarem a um estado terminal. O processamento pode levar até 24 horas. O relatório deve exibir uma contagem datada de em processamento, sem classificar uma janela incompleta como falha.

Guarde códigos de motivo, contagens e horários de consulta. Não copie o conteúdo dos registros rejeitados. A contagem é suficiente no relatório recorrente. A investigação técnica pode usar logs controlados sem transformar a prestação de contas ao cliente em outro repositório de dados sensíveis.

Separe deduplicação e novas tentativas

A idempotência local e a deduplicação do Google resolvem problemas relacionados, mas não idênticos. O outbox local impede que o worker repita um efeito ao receber novamente o mesmo evento. O guia Send Events informa que o Google Ads usa transactionId, dentro da mesma ação de conversão, para deduplicar eventos enviados por fontes diferentes nos cenários documentados.

O relatório pode mostrar novo, duplicado suprimido ou revisão manual como resultado local. Também pode indicar se o evento aprovado recebeu um identificador de transação externo. Não mostre esse identificador se ele revelar informação do sistema de origem. Não prometa deduplicação universal fora do produto e da ação documentados.

Novas tentativas precisam de duas colunas. A tentativa de entrega é uma ação do worker após falha transitória. A consulta de diagnóstico verifica uma requisição que já teve sucesso inicial. Consultar nunca deve reenviar a conversão. Se a resposta inicial ficar desconhecida, coloque o evento em quarentena até o runbook definir se outra tentativa é segura.

Use a taxonomia de resultados de agendamento para manter a versão do resultado estável. Ela ajuda a distinguir mudança real do resultado, repetição da mesma entrega e correção operacional. Essa distinção deve acontecer antes de qualquer sincronização externa.

Monte o relatório mensal em duas tabelas

A primeira tabela contém os eventos locais: ID opaco, versão, criação, estado, tentativas, próxima ação e ID Google, quando existir. A segunda contém as requisições Google: request ID, destino, estado de processamento, total de registros, contagens de avisos e erros e último diagnóstico.

Acima das tabelas, apresente um resumo curto:

  • resultados locais elegíveis criados no período;
  • eventos na fila, enviados, suprimidos, aguardando tentativa ou em quarentena;
  • requisições iniciais ao Google com sucesso ou falha;
  • destinos processando, concluídos, parcialmente concluídos ou com falha;
  • registros, avisos e erros agregados pelos diagnósticos;
  • observações feitas separadamente no relatório do Ads;
  • diferenças de reconciliação e responsável por cada investigação.

Uma diferença não prova perda. Pode vir de lotes em processamento, tentativas, janelas de tempo, duplicados ou configurações do Ads. Informe o motivo ou marque a questão como não resolvida. Não infira resultados individuais.

O relatório de taxa de comparecimento sem detalhes da consulta aplica a mesma contenção. Contagens e estados bastam para operar a entrega.

Erros que tornam o relatório enganoso

  • Somar eventos locais e diagnósticos Google como se fossem a mesma unidade.
  • Chamar HTTP 200 de conversão concluída.
  • Marcar eventos individuais a partir de PARTIAL_SUCCESS agregado.
  • Confundir consulta de diagnóstico com nova tentativa de entrega.
  • Expor payload, identificadores de origem ou detalhes do atendimento.
  • Tratar presença no relatório do Ads como prova automática de atribuição.
  • Usar o relatório como justificativa para ativar um envio ainda não aprovado.

O relatório pode conter processamento em aberto e resultados ainda não observados no Ads. Nomeie o responsável e date a próxima verificação, sem misturar as camadas.

Perguntas frequentes

HTTP 200 significa que a conversão apareceu no Google Ads?

Não. Significa sucesso da requisição inicial e devolução de um request ID. Consulte o diagnóstico por destino e faça outra verificação no relatório do Ads. A atribuição exige observação separada.

O relatório pode marcar cada evento depois de PARTIAL_SUCCESS?

Não. O diagnóstico traz contagens agregadas para a requisição e o destino. Sem ligação individual fornecida pelo Google, mantenha o resultado no nível do lote.

Quais dados ficam fora do relatório?

Payloads de origem, campos de saúde, campos de identidade e texto livre. O relatório precisa de referências opacas, estados, contagens, datas e códigos de motivo.

Este relatório autoriza uma rota de conversão offline?

Não. Ele documenta a confiabilidade de uma rota previamente aprovada nas revisões necessárias. Sem aprovação válida, a saída permanece desativada.

Referências