Como configurar horários exclusivos por convênio na integração Doctoralia e Feegow

Horários exclusivos por convênio na integração Doctoralia e Feegow devem ser configurados como blocos separados na grade padrão do profissional. Em cada bloco, a clínica limita os convênios aceitos nas configurações avançadas e marca Exibir na Doctoralia. Esse fluxo não deve usar Grade Livre ou Horários Personalizados, pois a documentação atual informa que essas opções não são refletidas no agendamento online integrado.

A clínica organiza a grade e os limites de atendimento dentro do Feegow. Quando inclui ou exclui um convênio da base integrada, também precisa solicitar ao suporte a atualização necessária para que a mudança apareça no marketplace. Editar a grade e atualizar o cadastro da integração não são a mesma ação.

Defina o resultado antes de editar a agenda

Comece pelo período que precisa de uma regra exclusiva. Registre profissional, unidade, local, dias, início, fim, intervalo, procedimentos e convênios aceitos. Se o período também aceita particular, isso deve ficar explícito. Se é exclusivo para determinados convênios, o bloco não deve herdar uma regra ampla que inclua atendimento particular.

A documentação de grade do Feegow permite limitar especialidades, procedimentos, convênios e programas de saúde nas configurações avançadas. Ela também mostra que grades diferentes podem representar regras diferentes no mesmo dia, como um período que aceita convênio e particular e outro apenas particular. Portanto, a exclusividade nasce da configuração de cada bloco, não do título visível da grade.

Antes da mudança, guarde uma lista curta do estado esperado. Ela será usada no teste final e evita que a recepção valide apenas um horário isolado.

Use blocos separados na grade padrão

No Feegow, acesse Agenda, escolha a visualização diária ou semanal, selecione o profissional e abra Grade. Crie ou edite um bloco padrão com o período desejado. Informe o local correto, o intervalo entre horários e a vigência quando ela for necessária.

Se a manhã atende dois convênios e a tarde atende somente particular, represente essas regras em blocos separados. Não tente expressar a divisão apenas com uma observação para a recepção. O agendamento externo depende da configuração estruturada da grade.

Essa orientação é específica para a integração Feegow e Doctoralia descrita nas fontes. Não presume comportamento idêntico em outro marketplace, outro sistema de gestão ou uma agenda sem integração.

Limite os convênios nas configurações avançadas

Dentro do bloco, abra Configurações Avançadas e use Limitar os convênios aceitos neste período. Selecione somente os convênios previstos para aquele período e confirme se particular deve ou não ser aceito. Revise também procedimentos e especialidade quando a clínica usa essas restrições na mesma grade.

O limite de convênio responde quem pode usar aquele bloco. A duração responde quanto tempo o atendimento ocupa. A documentação da integração informa que, quando o procedimento tem duração definida, esse tempo é refletido no agendamento; sem essa informação, vale a duração definida na grade. Confira as duas configurações para não publicar um horário cuja duração contradiz o procedimento oferecido.

Não use o nome do bloco como controle. Um título como “Convênio” ajuda a leitura interna, mas não substitui a seleção estruturada dos convênios aceitos.

Marque Exibir na Doctoralia na grade correta

A opção Exibir na Doctoralia compartilha a grade para agendamento online. Marque essa opção apenas nos blocos que devem aparecer no marketplace e salve a alteração. A página de configuração do Feegow também orienta verificar se a unidade está habilitada para exibição no agendamento online quando a grade não pode ser compartilhada.

Faça a revisão por profissional e local. Um bloco correto na unidade A não comprova a configuração da unidade B. Da mesma forma, publicar a tarde não confirma que o bloco da manhã recebeu os limites de convênio esperados.

Depois de publicar, compare a disponibilidade externa com a grade padrão. Se aparecer horário criado diretamente na Doctoralia, use o processo específico para identificar horários manuais fora da integração. Não apague disponibilidade apenas porque o resultado parece diferente.

Peça atualização ao suporte quando o cadastro do convênio mudar

A documentação da integração separa configurações feitas pela clínica de mudanças que exigem intervenção do suporte. A criação e edição da grade ficam no Feegow. Já a inclusão ou exclusão de um convênio da base deve ser feita no Feegow e comunicada ao suporte para atualização da integração no marketplace.

Não trate esse contato como uma etapa obrigatória após qualquer edição de horário. Ele é necessário quando o cadastro integrado de convênios muda. Ao abrir a solicitação, informe clínica, profissional, unidade, convênio incluído ou removido e qual resultado é esperado. Não envie dados de pacientes para explicar uma configuração de agenda.

Enquanto a atualização não estiver confirmada, mantenha o estado como pendente. Uma grade salva no Feegow não prova que o novo convênio já está correto no perfil externo.

Não confunda personalização da regra com Horários Personalizados

É possível personalizar um bloco padrão por período, procedimento e convênio. Isso é diferente da função Grade Livre, que usa Horários Personalizados. As fontes da Feegow informam que Grade Livre não é considerada no compartilhamento externo e que Horários Personalizados não são sincronizados com a Doctoralia.

Para este fluxo, mantenha a disponibilidade na grade padrão e aplique os limites no bloco. Se a operação exige horários que só podem ser representados em Grade Livre, registre a necessidade como não suportada pela integração atual e leve o caso ao suporte. Não prometa sincronização por semelhança visual entre as telas.

O guia de alternativas à Doctoralia pela origem do agendamento ajuda em decisões de plataforma, mas não altera o que a integração Feegow suporta hoje.

Teste por convênio, profissional e local

Após salvar a grade e concluir qualquer atualização de suporte, execute um teste controlado na jornada externa. Escolha um profissional, um local, um procedimento e um convênio incluído. Confirme se os períodos esperados aparecem. Repita com particular ou com um convênio não aceito e confirme que o bloco exclusivo não é oferecido para essa combinação.

Registre a data, a configuração testada e o resultado. Se houver divergência, volte à grade padrão, aos limites de convênio, à duração do procedimento, à opção Exibir na Doctoralia e ao estado da atualização solicitada ao suporte. Não invente uma causa técnica além dessas fontes. Se o estado continuar sem explicação, preserve a evidência e encaminhe ao suporte.

Use um agendamento sintético apenas quando a clínica puder concluí-lo e removê-lo com segurança. Ver disponibilidade não prova sozinho que o registro chegou ao fluxo operacional correto. Para manter relatórios consistentes depois do teste, preserve a diferença entre origem do agendamento e origem de marketing.

Documente a regra que a recepção precisa operar

A recepção precisa saber qual grade é padrão, quais convênios pertencem a cada bloco, se particular está incluído, quais procedimentos cabem no período e quem solicita atualização ao suporte. Uma tabela simples por profissional e local costuma bastar. Ela deve apontar para a configuração real, não substituir o Feegow como fonte operacional.

Quando um convênio muda, registre a alteração da base, o contato com suporte, a confirmação externa e o novo teste. Quando apenas o horário muda, registre a edição da grade e o teste correspondente. Essa separação mostra onde a mudança parou sem atribuir ao fornecedor um comportamento não documentado.

Se um paciente remarcar depois, a análise de atribuição é outra etapa. Veja como preservar a origem original após uma remarcação sem transformar a grade de convênio em campo de marketing.

Perguntas frequentes

Posso criar os horários exclusivos em Grade Livre?

Não para este fluxo integrado. A Feegow informa que Grade Livre ou Horários Personalizados não são refletidos no agendamento online da Doctoralia. Use blocos da grade padrão.

Basta limitar o convênio no Feegow?

Também é preciso marcar Exibir na Doctoralia na grade publicada. Se houve inclusão ou exclusão de convênio na base integrada, comunique o suporte para atualização.

Preciso chamar o suporte após mudar qualquer horário?

As fontes separam a edição da grade, feita pela clínica, da atualização de convênios na integração. Acione o suporte quando o cadastro integrado de convênios mudar ou quando uma divergência permanecer sem explicação.

O título da grade limita quem pode agendar?

Não é o controle documentado. Use a configuração Limitar os convênios aceitos neste período e revise se particular está incluído.

Como validar que a divisão funcionou?

Teste a jornada externa com um convênio incluído e outra combinação que não deveria acessar o bloco. Compare o resultado com a grade padrão por profissional e local.

Referências

How to Map Zocdoc Visit Reason IDs to EHR Appointment Types

A Zocdoc visit reason and an EHR appointment type solve different scheduling problems. Zocdoc uses a visit_reason_id to describe why a patient wants an appointment and to request eligible availability. An EHR may use its own code to select a template, duration, resource, or internal workflow. Matching labels do not prove that the two records mean the same thing.

Use a versioned, clinic-owned translation. Each admitted Zocdoc visit reason maps to one exact EHR scheduling code and duration for a defined provider, location, and patient type. If no active mapping matches, stop the booking path and send the case for review. Do not guess from the displayed name or fall back to a general appointment type.

Start with the Zocdoc identifiers the API actually defines

Zocdoc’s Reference Data guide says that several API endpoints require Zocdoc-specific IDs for specialties, visit reasons, and insurance plans. It provides endpoints to retrieve visit reasons and their IDs, optionally filtered by specialty_id, and to look up one visit reason by ID. That makes the returned ID the stable integration input. A copied label from a screen or spreadsheet is not an equivalent contract.

The glossary defines a visit reason as the purpose of the appointment. It also distinguishes the default visit reason, which determines duration and calculates availability when a specific reason is not selected. These are Zocdoc concepts. The documentation does not define the code your EHR should receive, so that second half belongs to the clinic and its integration owner.

Keep visit reason, visit type, and EHR type separate

The Zocdoc glossary lists appointment visit types such as in_person, zocdoc_video_service, and third_party_video_service. Those values describe how the appointment occurs. A visit reason describes its purpose. Your EHR appointment type may combine purpose, duration, staffing, or local billing workflow. Treating these three fields as synonyms creates silent errors.

Use distinct columns and names in code. For example, zocdoc_visit_reason_id, zocdoc_visit_type, and ehr_appointment_type_code should never share one generic variable called type. That naming scheme is editorial implementation guidance, not a Zocdoc-required database schema.

Build a versioned translation table

A small table is enough if its scope is explicit. Store only fields needed to decide whether one booking combination is admitted:

Field Purpose
mapping_version Identifies the approved translation used for a booking.
zocdoc_visit_reason_id Uses the ID returned by Zocdoc reference data.
provider_location_id Limits the rule to the provider and practice location represented by that API object.
patient_type Separates new and existing patient paths when the clinic schedules them differently.
ehr_appointment_type_code Names one exact destination code owned by the clinic.
ehr_duration_minutes Records the duration approved for that destination mapping.
state Allows only reviewed mappings to enter the booking path.

The version, EHR code, duration, and approval state are recommended architecture, not Zocdoc API fields. Keep that distinction visible in documentation and logs. It prevents a local operational decision from being misquoted as vendor behavior.

Match the scope used to request availability

The booking guide retrieves availability using a provider_location_id, visit_reason_id, and patient_type. The returned start time then becomes an input to the booking request, together with the visit reason and provider location. Your mapping lookup should use the same decision context rather than translating a visit reason globally.

One visit reason may legitimately map to different EHR codes for two providers or locations. New and existing patients may also follow different templates. Do not invent those differences from the API documentation. Obtain them from the clinic’s approved scheduling rules and represent them as separate rows. If a required scope value is absent, the mapping is unresolved.

This separation also keeps attribution data from changing scheduling meaning. The appointment source and marketing source answer reporting questions. They should not select an EHR appointment type.

Honor allowed and excluded visit reasons

Zocdoc defines allowed visit reason IDs as the reasons that can be scheduled for a given time slot. It defines excluded visit reason IDs as reasons that cannot be scheduled there, and an exclusion takes precedence over an allowance. Treat those fields as a slot-level eligibility check before applying the local translation.

A translation row cannot make an excluded reason bookable. Conversely, an allowed reason does not prove that the clinic has approved an EHR destination for it. Both conditions must hold: the Zocdoc slot permits the reason, and the active clinic mapping resolves the exact destination. If either condition fails, stop the request and record which gate failed.

Reject unresolved mappings without a generic fallback

Fail closed when no active row matches, more than one row matches, the EHR code is blank, the duration is missing, or the mapping version is not approved. Return a controlled unavailable or review state before creating the appointment. Do not silently use the default visit reason, a generic consultation code, the first search result, or a prior mapping from another provider.

The Zocdoc glossary explains what its default visit reason does inside Zocdoc. It does not authorize an integration to use a clinic’s general EHR type as a rescue path. A local fallback would be a new scheduling policy and needs explicit clinic approval. Until then, unresolved means not bookable through this route.

Log identifiers, mapping version, decision result, and an error code without copying patient notes. For downstream reporting, preserve the original booking source as described in the guide to keeping booking source after a reschedule.

Test the availability and booking contracts together

Use the documented sequence in a controlled environment. Retrieve the Zocdoc visit reason ID, select the intended provider location and patient type, request availability, and choose a returned start time. Confirm that the reason is not excluded for that slot. Then resolve the local mapping before sending a booking request with the same Zocdoc context.

The API documentation proves the Zocdoc side of this sequence. A separate clinic-owned test must prove what the integration writes to the EHR. Inspect the resulting appointment and compare its exact type code, duration, provider, location, and patient classification with the approved mapping row. This is a recommended acceptance check, not a promise that every EHR exposes the same fields or write-back behavior.

Include negative tests. Use an unknown visit reason, an excluded reason, a missing provider scope, and two competing active rows. Each case should stop before an EHR appointment is created. When the appointment later changes state, keep the original mapping evidence alongside the operational history. The article on no-show reporting by original booking source shows why stable historical context matters.

Change mappings without rewriting history

Publish a new version when a clinic changes an EHR code, duration, provider scope, location, or patient-type rule. Give the new row an effective point and stop using the old row for new requests. Existing appointments should retain the version used when they were created. That lets support staff explain an older booking after the current configuration has changed.

Refresh Zocdoc reference data on the review schedule defined for the integration. A retrieved ID can be compared with the active table before release. If the source set, provider roster, or clinic scheduling policy changes, rerun both positive and negative checks. Do not infer a vendor change solely from a label difference.

Frequently Asked Questions

Can I map by the displayed visit-reason name?

No. Retrieve and store the Zocdoc ID. Labels are useful to reviewers, but the documented API contract uses Zocdoc-specific identifiers.

Is an EHR appointment type the same as a Zocdoc visit type?

Not by definition. Zocdoc visit type describes in-person or supported video modes. The EHR destination code remains a clinic-owned value unless the exact integration documentation says otherwise.

Can one visit reason map to more than one EHR code?

Yes, when separate provider, location, or patient-type scopes make the result unambiguous. Two active matches for the same request should be rejected.

What happens when a visit reason is allowed but unmapped?

Stop the booking route and send the configuration for review. Slot eligibility and local destination approval are separate gates.

Should a reschedule use the latest mapping version?

Do not change historical meaning automatically. Preserve the version attached to the original appointment and define any remapping rule as a separate, approved workflow.

References

Clique inválido vs lead desqualificado: por que clínicas devem medir os dois separadamente

Um clique inválido e um lead desqualificado não são a mesma evidência. O Google define o clique inválido como uma interação sem interesse genuíno, incluindo fraude, automação e cliques acidentais ou duplicados. A clínica define a desqualificação segundo critérios comerciais e operacionais próprios.

Um lead pode ter clicado de forma legítima, preenchido o formulário e ainda não atender aos critérios da clínica. Isso não transforma o clique em fraude. Também não impede que um envio falso tenha começado em tráfego suspeito. A análise precisa separar validade do clique, qualidade do formulário, segmentação e qualificação.

O que o Google considera um clique inválido?

A Ajuda do Google Ads define cliques inválidos como cliques que não resultam de interesse genuíno. Os exemplos incluem ações manuais para aumentar custos, ferramentas automáticas, robôs, software fraudulento e o segundo clique de um clique duplo acidental.

A página sobre tráfego inválido amplia os exemplos para impressões e cliques de data centers conhecidos, indexadores, rastreadores e padrões irregulares identificados pelo monitoramento. Essa classificação pertence aos sistemas do Google. Uma planilha da clínica não consegue reproduzi-la apenas olhando nomes, telefones ou respostas do formulário.

Quando o Google detecta atividade inválida, informa que filtra os cliques e não cobra por eles. Se a detecção ocorre depois do fechamento da fatura, o ajuste aparece como crédito em faturas futuras. A documentação esclarece que isso é crédito ou ajuste, não reembolso.

O que significa lead desqualificado para uma clínica?

Lead desqualificado é uma categoria interna. Ela indica que um contato não cumpriu a regra comercial definida para avançar. O motivo pode ser área não atendida, serviço não oferecido, ausência de intenção de marcar, contato incorreto, duplicidade ou outro critério escrito pela operação.

Esses exemplos são uma proposta editorial de classificação, não categorias publicadas pelo Google. A clínica deve escolher motivos que possam ser aplicados de forma consistente e que não exponham diagnóstico, tratamento, prontuário ou texto clínico no relatório de mídia.

A taxonomia de resultados de agendamento ajuda a separar formulário, horário criado, comparecimento, cancelamento e resultado posterior. A qualificação do lead deve ocupar seu próprio campo, com fonte, responsável e data.

Como comparar as duas evidências?

Dimensão Clique inválido Lead desqualificado
Objeto avaliado Interação com o anúncio Contato ou oportunidade recebido pela clínica
Definição Regra e detecção do Google Regra comercial da clínica
Fonte Relatórios e investigação do Google Ads CRM ou sistema operacional aprovado
Efeito financeiro Filtragem, ajuste ou crédito quando o Google confirma Nenhum crédito automático
O que não prova Qualidade comercial do lead Fraude ou invalidade do clique

As categorias podem aparecer no mesmo caso, mas uma não implica a outra. Um bot pode gerar tráfego e um formulário falso. Uma pessoa real também pode preencher o formulário para um serviço que a clínica não oferece. O primeiro cenário pede evidência de tráfego; o segundo pede revisão de segmentação, mensagem e qualificação.

Por que uma taxa baixa de qualificação não prova tráfego inválido?

O Google apresenta cliques inválidos e envios de formulário de baixa qualidade como problemas distintos no caminho para solicitar uma investigação. Um formulário ruim pode resultar de promessa pouco clara, palavra-chave ampla, localização inadequada, campo insuficiente ou regra comercial restrita.

Uma taxa baixa mostra que poucos contatos passaram pela definição usada no período. Ela não identifica a causa. Antes de falar em fraude, confira se a regra de qualificação mudou, se a equipe aplicou os motivos da mesma forma, se o formulário continuou funcionando e se a campanha trouxe consultas coerentes com o anúncio.

Não use uma conversão de plataforma como sinônimo de resultado. O artigo sobre conversão de chamada versus agendamento mostra uma fronteira parecida: cumprir uma regra do Google não comprova que a agenda criou um horário.

Quais dados devem ficar em relatórios separados?

O relatório de mídia deve preservar os campos fornecidos pelo Google, como cliques e cliques inválidos. O relatório operacional deve guardar formulários válidos, duplicados, contatos alcançados, motivos de desqualificação e agendamentos, segundo regras aprovadas pela clínica.

Evite uma coluna única chamada “lead ruim”. Ela mistura problemas de naturezas diferentes e impede a correção certa. Use pelo menos quatro camadas:

  1. atividade publicitária reportada pelo Google;
  2. validade técnica do envio de formulário;
  3. qualificação comercial segundo regra escrita;
  4. resultado operacional registrado pela agenda.

Relacione as camadas apenas no ambiente aprovado e com identificadores mínimos. Não envie motivo de desqualificação, condição de saúde, procedimento procurado ou observação da recepção ao Google. O guia de origem do agendamento versus origem de marketing explica por que campos operacionais e publicitários não devem substituir um ao outro.

Como auditar um aumento de leads desqualificados?

Comece pela definição interna. Confirme quais motivos estavam ativos, quem os aplicou e se a regra mudou. Em seguida, verifique o formulário, os termos de pesquisa, os locais alcançados, os anúncios e as páginas de destino. Preserve o período e as alterações de campanha.

  • Compare cliques totais e cliques inválidos informados pelo Google.
  • Separe formulários vazios, quebrados, repetidos e tecnicamente válidos.
  • Reconte a qualificação com a mesma regra em uma amostra controlada.
  • Agrupe motivos comerciais sem incluir dados de saúde.
  • Compare campanhas, termos e locais antes e depois da mudança.
  • Registre hipóteses como hipóteses até encontrar evidência.

Uma diferença entre campanhas pode orientar a investigação, mas não prova intenção fraudulenta. Use o método de comparação por campanha para manter resultados agregados e fontes separadas, sem copiar detalhes da consulta para a plataforma de anúncios.

Quando solicitar uma investigação ao Google?

O Google oferece o formulário de qualidade do clique para problemas com cliques inválidos, envios de baixa qualidade, cliques fora da segmentação por local ou aumentos repentinos de custo. A existência do formulário não significa que todos esses problemas terão a mesma causa ou o mesmo ajuste.

Prepare período, conta, campanhas, dispositivos, locais, variação observada e passos já verificados. Não envie prontuário, diagnóstico, tratamento, conteúdo de conversa ou dados pessoais desnecessários. Descreva o padrão técnico e financeiro sem transformar a desqualificação comercial em acusação de fraude.

Monitore também a coluna de cliques inválidos. O Google afirma que os valores nela já representam tráfego detectado e filtrado. Um aumento nessa coluna comprova a classificação feita pelo sistema, mas não revela sozinho a origem de cada lead recebido.

Que correção corresponde a cada problema?

Se a evidência aponta para termos irrelevantes, revise palavras-chave e negativas. Se aponta para locais que a clínica não atende, revise opções e exclusões geográficas. Se o formulário aceita entradas incompletas, corrija sua validação. Se a qualificação varia por atendente, normalize os motivos e faça uma revisão amostral.

Essas ações tratam causas diferentes. Nenhuma delas deve ser usada para apagar registros ou reclassificar o passado sem evidência. Preserve a contagem original, a regra vigente e a data da correção. Depois, acompanhe um período comparável antes de concluir que a qualidade mudou.

Para resultados posteriores, use denominadores maduros. O método de taxa de faltas por origem do agendamento mantém cancelamentos, remarcações e casos abertos fora do resultado final. A mesma disciplina evita culpar tráfego por uma operação ainda incompleta.

Quais erros de linguagem devem ser evitados?

Não escreva “o Google mandou leads falsos” quando a evidência mostra apenas contatos desqualificados. Não prometa reembolso, pois a documentação fala em filtragem, ajustes e créditos. Não chame todo contato duplicado de robô sem verificar como o formulário e o CRM tratam repetições.

Uma origem legítima também não prova que todo envio foi humano ou útil. Mantenha a investigação aberta quando houver automação, padrões irregulares ou atividade suspeita. A conclusão deve citar a fonte e o limite da prova.

Uma frase segura para o relatório é: “A clínica classificou estes contatos como desqualificados segundo a regra comercial vigente; essa classificação não determina se o Google considera os cliques inválidos.” Depois, apresente as duas contagens em campos separados.

Perguntas frequentes

Todo lead desqualificado veio de um clique inválido?

Não. Uma pessoa real pode clicar com interesse genuíno e não cumprir a regra comercial da clínica. A desqualificação não prova fraude, automação ou cobrança indevida.

O Google cobra por cliques considerados inválidos?

O Google informa que filtra a atividade inválida e não cobra por ela. Detecções posteriores ao fechamento podem gerar créditos em faturas futuras, não reembolso.

Mais conversões do que cliques sempre indica erro?

Não necessariamente. O Google documenta casos raros em que remove um clique inválido, mas mantém a conversão associada. Investigue a configuração antes de corrigir números.

Um formulário falso deve ser enviado ao suporte como prova?

Registre o padrão técnico necessário, mas não envie dados pessoais ou de saúde desnecessários. Um formulário isolado também não prova a origem nem a classificação do clique.

Referências

How to Use Google Ads Data Exclusions After a Clinic Conversion-Tracking Outage

A Google Ads data exclusion can protect Smart Bidding from a verified conversion-tracking outage. It does not repair the tag, restore missing clinic records, or remove data from reports. The exclusion tells eligible bidding strategies to disregard affected click data when learning and setting bids.

The date range must follow clicks, not only the hours when conversions stopped arriving. Include earlier clicks whose conversions would normally have appeared during the outage. Apply the narrowest accurate campaign and device scope, preserve the incident evidence, and treat reporting backfill as a separate decision.

When does a clinic conversion outage qualify?

Google recommends data exclusions for conversion-data outages, including broken tracking, an incorrectly placed tag, a website outage, or a temporary failure to upload offline conversions. In each case, inaccurate conversion or conversion-value data could distort conversion-based Smart Bidding.

A sudden decline in appointments does not qualify by itself. Neither does a holiday, a normal change in demand, a small sample, or a disputed lead-quality definition. First prove that the measurement system reported incorrect data for a bounded period.

Keep the incident proof outside Google Ads: alert time, affected conversion actions, first bad observation, last known good event, repair time, missing or inflated records, affected devices, and affected campaigns. The conversion audit proof guide helps separate configuration, processing, reporting, and attribution evidence.

What does a data exclusion change?

A data exclusion changes the conversion and conversion-value data that Smart Bidding uses. Google says the tool is available only for conversion-based and value-based Smart Bidding strategies. It supports Search, Display, Shopping, and Performance Max campaigns, while Hotel and Travel campaigns are not supported.

The exclusion does not alter the Conversions columns or erase affected events from reports. Google states that excluded conversions remain visible in reporting. A report can therefore show conversions from the period even though Smart Bidding no longer uses the associated click data.

Describe the action accurately in an incident log: “Excluded affected clicks from Smart Bidding inputs.” Do not write “deleted bad conversions,” “fixed reporting,” or “restored attribution.” Those outcomes are outside what the feature does.

Why must the date range follow clicks and conversion delay?

Google applies data exclusions to clicks. When a click is excluded, conversions associated with it are also excluded from Smart Bidding. A conversion recorded during an outage may belong to a click from an earlier day, so selecting only the visible outage dates can miss affected learning data.

Measure the normal delay between click and reported conversion for the affected action. Then move the exclusion start back far enough to cover clicks whose conversions would have arrived during the broken period. Google recommends covering at least 90% of clicks associated with the affected conversion data.

Google gives a concrete example: if uploads failed from October 15 through October 18 and the conversion delay is five days, the exclusion should cover clicks from October 10 through October 18. Use the clinic account’s observed delay and incident window instead of copying the example dates.

The clinic funnel report by original lead cohort provides a related reporting principle. Later outcomes belong to the acquisition cohort that produced them. The exclusion uses the same temporal discipline because bidding connects reported conversions back to clicks.

How narrow should the exclusion scope be?

Scope should match the proven fault. Google’s setup allows selection of campaigns and devices, or an account-wide exclusion when the evidence supports it. Exclusions can be applied at manager-account or sub-account level. Start and end times use the account’s time zone.

Incident evidence Candidate scope Do not assume
One mobile tag failed Affected campaigns and mobile devices Desktop data was also wrong
One campaign used a broken page That campaign and proven dates Every account campaign was affected
Account-wide import stopped Campaigns using the affected imported action Unrelated conversion actions failed
Scope remains unknown Continue investigation A broad exclusion is safer

A broad exclusion discards more learning data. A narrow exclusion that misses affected clicks leaves bad data in the bidder. Choose the smallest scope supported by incident evidence, which may not be the smallest selectable option.

How should the team apply the exclusion?

Google’s current workflow places data exclusions under Adjustments in Google Ads. Before creating one, record the exact dates, times, time zone, campaigns, devices, conversion actions, and delay assumption. Google warns that exclusions can change bid-strategy performance, so the final review should happen before creation.

  1. Confirm the conversion data is wrong and identify the root measurement fault.
  2. Repair or contain the fault so the outage has a defensible end.
  3. Measure the normal click-to-conversion delay for the affected action.
  4. Translate the outage into an affected click-date range.
  5. Select only the proven campaigns and devices.
  6. Verify the account time zone and manager or sub-account scope.
  7. Save the evidence and approval before creating the exclusion.
  8. Monitor bidding and spend while the strategy stabilizes.

Apply the exclusion quickly once the scope is known. Google says planned outages can be configured in advance and typically take effect within a day. Do not use that guidance to guess at an uncertain incident. A wrong future window still sends the bidder inaccurate instructions.

What happens after the exclusion is applied?

Google advises against removing a data exclusion after application. Past-date exclusions should begin to stabilize after a few days, but an outage affecting a week or more of clicks can produce fluctuations for one or two conversion cycles.

Watch spend, bids, conversion volume, and conversion value without declaring immediate recovery. Google notes that bids and spending can fall temporarily. It also suggests keeping budgets near historical spend for a few cycles and adjusting CPA or ROAS targets when necessary. Any such change needs its own approval and rollback rule.

The value-based bidding readiness checklist explains why delay, mature observation windows, goals, and data quality still matter after the platform accepts a setting. An exclusion reduces one source of bad learning data. It does not make the remaining conversion feed accurate.

Should missing conversions be backfilled?

Google generally advises against backfilling data after an outage because late conversions can affect Search and Shopping bidding performance. If a data exclusion was applied, Google allows a reporting-only backfill after waiting at least five days. It says not to remove the exclusion.

Keep the two purposes separate. The exclusion protects bidding from affected clicks. A backfill may restore reporting completeness. It does not reverse the exclusion or recreate the learning sequence that would have existed if tracking had worked on time.

Before any backfill, reconcile source records, remove duplicates, preserve original conversion times, and document why reporting needs the late events. The offline conversion outbox report shows how to keep local event state, Google request state, Ads reporting, and attribution in separate evidence layers.

What should the incident record contain?

A useful record lets another operator reconstruct the decision without reading patient or appointment data. Include the incident ID, detection time, root cause, repair time, affected conversion actions, account time zone, measured delay, click-date range, campaign and device scope, approval, exclusion identifier, and monitoring window.

Record explicit non-claims as well:

  • the exclusion did not change Ads reporting;
  • the exclusion did not repair the source tracking system;
  • the exclusion did not prove attribution or business recovery;
  • any backfill was reporting-only and happened after the documented wait;
  • patient details and clinical data were not included in the incident artifact.

Review the incident after one or two observed conversion cycles when the affected period was long. Retire temporary target or budget adjustments through a separate approved decision. Do not remove the data exclusion to make a dashboard look consistent.

Frequently asked questions

Do data exclusions remove conversions from reports?

No. Google says data exclusions affect the data used by Smart Bidding, not conversion reporting. The excluded period can remain visible in the account’s conversion columns.

Should the exclusion cover conversion dates or click dates?

Use affected click dates. Extend the start date to account for normal conversion delay, because conversions reported during the outage may be attributed to earlier clicks.

Can the team remove an exclusion after fixing the data?

Google advises against removing an applied exclusion. Preserve it, document the repair separately, and let the strategy stabilize on accurate post-incident data.

Can missing conversions be uploaded later?

Google generally discourages backfills. When an exclusion was applied, a reporting-only backfill can occur after at least five days, without removing the exclusion. Review duplicates and original times first.

References

Google Ads Location Targeting for Clinics: Presence vs Presence or Interest

Presence and Presence or Interest answer different questions in Google Ads. Presence focuses on people likely to be in or regularly in a targeted area. Presence or Interest also includes people who have shown interest in that area. For a clinic, the right setting depends on where it can actually serve patients.

Neither option proves a person’s precise location. Google describes location targeting as a best-effort system based on several signals and says complete accuracy is not guaranteed. Choose a setting from the clinic’s service boundary, then audit matched locations and qualified booking outcomes instead of judging the decision by reach alone.

What is the difference between the two options?

Google’s advanced location documentation describes Presence or Interest as the default and recommended broad targeting option. It can reach people likely in or regularly in the selected locations and people who have shown interest in those locations. Presence removes the interest branch and retains the likely-in or regularly-in branch.

Option Who may be reached Clinic decision question
Presence or Interest People likely in, regularly in, or interested in the targeted area Can the clinic serve valuable demand from people who are not currently local?
Presence People likely in or regularly in the targeted area Does the clinic want to limit reach to likely local presence?

The wording matters. Presence does not mean confirmed residence, and Presence or Interest does not mean the user intends to travel. Both are platform classifications. The clinic still needs an operational definition of its service area and a separate way to measure whether enquiries become eligible bookings.

When does Presence fit a clinic’s service boundary?

Google says advertisers should consider Presence when they only want users in specific locations, or when the business is in a sensitive vertical with strict targeting limits. A clinic with a fixed in-person service area may therefore prefer the narrower option after checking the actual campaign and current policy.

This is not a universal prescription. A regional specialist, a clinic serving travellers, or an organization offering permitted remote services may have a reason to evaluate location interest. Write the service scenario first rather than copying a setting from another account.

Document every included location, excluded location, radius, and location option. Record why a person outside the immediate area can or cannot become an eligible patient. If the answer depends on the service, campaign, or location, separate those campaigns instead of relying on one broad rule.

When can Presence or Interest be useful?

Presence or Interest can reach someone outside the target area whose searches, past activity, visited locations, or viewed content indicate an interest in that place. Google notes that location of interest is not limited by the user’s country or the Google domain used for the search.

That broader reach is useful only when out-of-area interest has a credible path to service. For example, someone may plan care before moving to a new city or arrange an appointment for a future visit. Test those scenarios against the clinic’s booking process rather than inferring them from a search term.

Do not reuse Google’s conversion example for travel, real estate, and education as a clinic benchmark. The advanced-options page limits that result to named verticals and dates. It does not establish that broader targeting improves qualified patient acquisition for healthcare advertisers.

Why is neither option exact location proof?

Google uses signals such as IP addresses, device information, user settings, behavior, search terms, past locations, Maps activity, and page context to estimate physical location or location interest. Signal availability varies. The platform says location targeting is its best effort and does not guarantee full accuracy.

Google also documents related areas. Ads may show in nearby places that could not be targeted directly because of population, available data, or targeting granularity. A radius or city target is therefore a campaign setting, not a geometric proof of where every click occurred.

Do not classify a click associated with another place as invalid traffic automatically. It may reflect the selected Presence or Interest option, an estimated location, a related area, or a reporting limitation. Inspect the campaign and evidence before assigning a cause.

Which geographic reports should the clinic review?

Google’s geographic performance guide separates Targeted locations from Matched locations. Targeted locations shows performance for the areas configured in the campaign. Matched locations shows where ads appeared based on either a user’s physical location or a location of interest.

Start with the Matched locations view when investigating reach beyond the expected service area. Then compare it with the exact advanced location option, exclusions, campaign type, and date range. The report is aggregated, and Google notes that some rows can remain unspecified.

Distance reports add another perspective when location assets are present. Google warns that the displayed distance can be based on a place of interest rather than precise physical distance. Treat distance as a reporting dimension, not a patient-address field or evidence about an individual.

How should location data connect to clinic outcomes?

Google’s reports describe ad delivery and platform conversions. The clinic must define an eligible enquiry or booking in its own system. Join those layers only through an approved, minimized reporting process, then aggregate by a useful geographic level before sharing results.

A practical internal review separates:

  • targeted location and selected location option;
  • matched location category reported by Google;
  • valid form submissions or calls under a written rule;
  • eligible bookings recorded by the clinic’s source of truth;
  • cost and outcome rate for a mature period.

The clinic booking outcome taxonomy keeps form, booking, attendance, and later outcomes distinct. The guide to show rate by campaign explains how to use aggregate outcomes without turning appointment details into advertising payloads.

How should a clinic test a change?

Change one location option at a time and preserve the prior setting. Record the affected campaigns, locations, exclusions, date, approver, reason, and rollback condition. Avoid changing keywords, landing pages, bidding, and geographic settings together because the result will be hard to interpret.

  1. Write the service boundary and acceptable out-of-area scenarios.
  2. Capture the current targeted locations, exclusions, and advanced option.
  3. Review Matched locations for a mature period.
  4. Compare valid enquiries and qualified bookings under clinic-owned definitions.
  5. Choose Presence or Presence or Interest for the documented scenario.
  6. Monitor reach, cost, and outcome quality over the same reporting window.
  7. Revert if the agreed stop condition is met.

Do not promise that Presence will remove every out-of-area interaction. Google explicitly describes the system as best effort. The test should ask whether the narrower setting improves the clinic’s observed mix within acceptable reach, not whether every user appears inside a perfect boundary.

What should the decision record say?

The record should state the clinic’s service constraint before the chosen setting. It should also name what counts as a qualified booking, which report supplies location data, how unspecified rows are handled, and when the team will review the decision again.

Decision field Required entry
Service boundary Where and how the clinic can provide the advertised service
Google option Presence or Presence or Interest
Campaign scope Exact campaigns, locations, exclusions, and devices
Evidence Matched locations plus clinic-owned qualified outcomes
Review rule Date, owner, rollback threshold, and known limitations

Keep location targeting separate from acquisition attribution. The appointment source versus marketing source guide shows why the scheduler entry point and the campaign that influenced demand need different fields. Location is another dimension, not a replacement for either one.

Frequently asked questions

Is Presence always better for a local clinic?

No. It is narrower and may fit a fixed local service boundary, but Google recommends assessing the advertiser’s goals. A clinic that can legitimately serve some out-of-area demand may test the broader option with qualified booking evidence.

Does Presence guarantee every user is physically inside the target?

No. Google estimates location from several signals and calls its targeting best effort. It does not guarantee complete accuracy. Related areas and unspecified report rows also require review.

Does an out-of-area click prove invalid traffic?

No. Check the advanced location option, matched-location type, exclusions, related areas, and available signals first. Invalid traffic is a separate classification and needs its own evidence.

Should a clinic judge the setting by conversion count?

Not alone. Compare reach and cost with valid enquiries and eligible bookings under written clinic definitions. A larger platform conversion count may still include demand the clinic cannot serve.

References

Google Ads New Customer Acquisition Goal vs a Clinic’s New-Patient Definition

Google Ads can label someone a new customer without proving that the person is a new patient under a clinic’s operating rules. The platform label belongs to a bidding system. The clinic definition belongs to its appointment or patient system. They can inform the same review, but they are not interchangeable.

Before activating a customer lifecycle goal, review the acquisition mode, detection method, and campaign requirements. Google also restricts advertiser-curated audiences when ads promote content within a sensitive health category. A clinic should test eligibility first and keep its patient definition in the approved operational system.

What are the two definitions?

Google Ads uses customer lifecycle goals to change how campaigns bid toward new, high-value, existing, or lapsed customers. Its documentation describes the platform modes, eligible campaign types, bidding strategies, and signals used to detect customer segments. The resulting label answers a Google Ads optimization question.

A clinic’s new-patient definition answers an operational question. The clinic might need to distinguish a first recorded appointment, a first completed visit, a returning person after a chosen interval, or an existing patient visiting another location. Those are examples of definitions a clinic may choose, not definitions published by Google.

Write the clinic rule before comparing the two systems. Name the qualifying event, lookback period, source of truth, exclusions, effective date, and owner. The clinic booking outcome taxonomy shows why a form submission, booking, and attended visit require separate names.

How does Google Ads identify a new customer?

Google documents three broad signal paths for customer detection: Google autodetection, designated audience lists, and supported conversion-tag information. The exact path depends on the lifecycle mode and conversion setup. A user classified as new by one of those paths has met the platform’s detection logic, not the clinic’s patient-record rule.

Autodetection is activated for new customer acquisition when the advertiser tracks Google Ads purchase conversions. Google says it can build from up to 540 days of campaign activity and tracked purchases. The same documentation calls this method less comprehensive because users can delete cookies or opt out.

Audience lists can help Google identify existing customers, but access and policy eligibility are separate gates. A visible list control does not prove that a clinic may populate it with patient information. Even accurate platform detection would not establish clinical or billing status.

Why does the selected lifecycle mode matter?

The phrase “new customer acquisition goal” covers modes with different requirements. Google’s current lifecycle overview says New Customer Value mode and High-Value New Customer mode require at least one purchase conversion goal and use value-based bidding. New Customer Only mode can work without a purchase goal, although Google recommends one for more accurate new-versus-returning reporting.

New Customer Value mode bids higher for new customers while continuing to engage potential returning customers. New Customer Only mode bids only for customers the platform treats as new. A team must record which mode it means. Saying only “new customer goal is enabled” is too vague for review.

For a broader readiness check, use the clinic value-based bidding checklist. It separates business purpose, conversion goal, value quality, delay, and observation window rather than treating a switch in Google Ads as evidence that the underlying data is ready.

Where should the clinic define a new patient?

The clinic should define new-patient status in the system that owns the relevant appointment or patient history. That rule can then support internal acquisition reporting. It should not be rewritten around what Google happens to detect, because cookie loss, opt-out, list coverage, and conversion configuration can all change the platform result.

Use a small decision record with the following fields:

  • the event that qualifies a person, such as created booking or completed first visit;
  • the lookback period and whether it applies across locations;
  • the source system and stable internal identifier;
  • test, duplicate, cancelled, and migrated-record rules;
  • the owner, effective date, and change history.

This is an editorial governance model. Google does not prescribe a clinic’s patient definition. The guide to appointment source versus marketing source provides a related boundary: operational scheduling facts and advertising context answer different questions and should stay in separate fields.

What changes when the advertising falls into a sensitive health category?

Google’s health policy classifies personal health content as a sensitive interest category. Its examples include health conditions, treatments, invasive procedures, medical devices, pregnancy, infertility, and mental-health services. Whether a specific ad, site, or app falls within the policy requires review of the actual content.

When that sensitive-interest restriction applies, Google’s current policy says advertiser-curated audiences are not supported. The listed unsupported features include Customer Match, advertiser data segments, audience expansion, and lookalike segments. Predefined Google audiences and location targeting appear on the supported side of the policy table, subject to their own rules.

Do not respond by uploading a patient list under a broader label, hashing it, or turning an appointment outcome into an audience. This article does not recommend any health-data upload. If the chosen lifecycle mode depends on a customer signal that the policy does not support for the advertised content, stop the implementation and keep the new-patient analysis internal.

The enhanced-conversions audit proof guide applies the same evidence discipline to another Google feature: configuration, request processing, Ads reporting, and business outcomes remain separate proof layers.

How should a clinic decide whether to activate the goal?

Start with the advertised content, proposed campaign, lifecycle mode, conversion goal, and signal path. Do not start with a patient export. The team should be able to describe the full configuration without exposing names, contact details, appointment information, or medical context.

  1. Define the clinic’s new-patient rule in the operational system.
  2. Identify the exact Google lifecycle mode and eligible campaign type.
  3. List the conversion goal and detection signals the mode would use.
  4. Review whether the ads, site, or app fall within Google’s sensitive health category.
  5. Confirm each required signal is permitted under the current policy.
  6. Stop if activation would require an unsupported audience or patient-data upload.
  7. Document the approval, scope, owner, rollback step, and review date.

New Customer Only creates a specific conflict. Google’s configuration guide says advertisers using offline events need to upload existing customers through Customer Match because autodetection does not work with offline conversions. That instruction does not override the health-policy restriction. For sensitive health advertising, stop rather than upload the list anyway.

How should reporting keep the labels separate?

Use two columns with two sources. One column records the Google Ads lifecycle classification reported for the campaign. Another records whether the clinic’s written new-patient rule was satisfied in its approved system. Never fill the second column by copying the first.

Field Source What it proves What it does not prove
Google new-customer classification Google Ads Platform classification under the selected mode and available signals First appointment or completed visit
Clinic new-patient status Approved clinic system The clinic’s documented operational rule was met How Google classified the user
Original marketing source Approved attribution record Recorded acquisition context Patient status or appointment outcome

Compare counts only after stating each denominator, date basis, and maturity window. A difference is not automatically a tracking defect. It may follow from different definitions or incomplete platform signals. Investigate the rows without exporting the patient record to the advertising platform.

Which mistakes create the most risk?

Renaming a Google segment “new patients” overstates what the platform proves. Building an existing-customer list from patient data before checking sensitive-interest restrictions creates a separate policy risk.

New Customer Value and New Customer Only do not work the same way. Their conversion-goal requirements differ. Changing the clinic definition until it matches the Google count also destroys a stable operational metric and hides the disagreement that needs investigation.

Keep every decision reversible. Record screenshots without patient data, the source pages reviewed, the campaign and goal identifiers, and the reason for approval or rejection. Review the setup again when Google changes lifecycle features, the clinic changes its definition, or campaign content enters a different policy category.

Frequently asked questions

Does Google Ads know whether someone is a first-time patient?

Not from the new-customer label alone. Google classifies customers through the selected lifecycle mode and available platform signals. First-time patient status requires the clinic’s own documented rule and approved operational record.

Can a clinic upload its patient list to improve new-customer detection?

This article does not recommend that upload. When ads promote content within Google’s sensitive health category, Customer Match and other advertiser-curated audiences are unsupported. Review the actual content and current policy before any implementation.

Can New Customer Only mode use a non-purchase conversion?

Google’s current lifecycle documentation says a purchase goal is not required for New Customer Only mode, although it is recommended for reporting accuracy. Signal and policy eligibility still require separate review.

What should the clinic report if the two counts differ?

Report both counts with their definitions, sources, and date bases. Do not force them to match. Investigate configuration and coverage while keeping patient status in the clinic’s approved system.

References

Agendamento pediátrico online: como separar LGPD art. 14 e ECA Digital

Um formulário de agendamento pediátrico não deve partir da regra simplificada de que qualquer tratamento exige consentimento parental. O Enunciado CD/ANPD nº 1/2023 afirma que o tratamento de dados de crianças e adolescentes pode se apoiar nas hipóteses legais dos artigos 7º ou 11 da LGPD, desde que o melhor interesse seja observado e prevaleça na avaliação do caso concreto. Consentimento continua relevante em situações previstas pela lei, mas não é uma resposta universal.

O ECA Digital exige análise separada. A Lei nº 15.211/2025 alcança produtos ou serviços de tecnologia da informação direcionados a crianças e adolescentes ou de acesso provável por eles. Um formulário operado pelo responsável não fica automaticamente dentro ou fora desse escopo. Avalie público, linguagem, divulgação, desenho e uso esperado.

Comece pelo fluxo real de agendamento

Mapeie quem usa o formulário e o que acontece depois do envio. Em uma consulta pediátrica, o responsável pode pesquisar, preencher, receber mensagens e comparecer com a criança. Em outros serviços, o adolescente pode procurar atendimento, usar o próprio telefone ou conversar diretamente com a clínica. A interface precisa refletir o fluxo provável, não um modelo abstrato de família.

Separe dados do responsável, do menor, da agenda e campos clínicos. Nome, contato e vínculo do adulto podem organizar o atendimento; data de nascimento ou faixa etária pode orientar a agenda. Sintomas, documentos, histórico e observações exigem justificativa própria e talvez pertençam a um canal assistencial, não à primeira tela.

Também separe destinatários. A equipe de recepção pode precisar de identificação, horário e contato. Profissionais assistenciais podem precisar de informação adicional em sistema apropriado. Marketing não precisa receber o conteúdo do pedido. Uma taxonomia de resultados de agendamento permite medir estados operacionais sem reproduzir dados pediátricos.

O que a LGPD e o artigo 14 dizem

A LGPD trata dados de saúde como dados pessoais sensíveis e estabelece hipóteses legais específicas no artigo 11. O artigo 14 dispõe que o tratamento de dados pessoais de crianças e adolescentes deve ocorrer em seu melhor interesse. Seus parágrafos também contêm regras sobre consentimento específico e em destaque por pelo menos um dos pais ou responsável legal para dados de crianças, esforços razoáveis de verificação, transparência e limites à exigência de dados para participação em jogos, aplicações ou outras atividades.

Essas disposições não devem ser lidas isoladamente. O Enunciado CD/ANPD nº 1/2023 estabelece que o tratamento de dados de crianças e adolescentes pode ser realizado com base nas hipóteses legais dos artigos 7º ou 11, desde que o melhor interesse seja observado e prevaleça no caso concreto. Portanto, a equipe precisa identificar a hipótese apropriada para cada finalidade, além de demonstrar por que o desenho protege o menor.

Não transforme o enunciado em uma autorização geral. Ele não diz que qualquer base serve, nem elimina as demais obrigações do artigo 14. Também não transforme a menção a consentimento em regra para toda atividade pediátrica. Atendimento, obrigação regulatória, proteção da vida, tutela da saúde e marketing são finalidades diferentes e podem exigir análises diferentes.

Melhor interesse precisa aparecer nas decisões de produto

“Melhor interesse” não pode ficar apenas no aviso. Registre como cada escolha reduz risco: necessidade do dado, acesso, retenção, correção e possíveis expectativas diferentes entre responsável e adolescente.

Documente idade provável, vulnerabilidade, sensibilidade, impacto de erro, risco de exposição, autonomia progressiva, relação com o responsável e alternativa menos invasiva. A conclusão precisa ser específica. Repetir uma justificativa em cadastro, atendimento, pesquisa e campanha não demonstra avaliação real.

Para o primeiro contato, prefira um conjunto mínimo: identificação necessária, faixa etária quando suficiente, contato adequado, unidade, horário e tipo amplo de atendimento. Evite campo aberto obrigatório para descrever condição. Se a clínica precisa de triagem clínica antes da marcação, mova essa etapa para canal e equipe próprios, com controles compatíveis.

Essa é uma recomendação editorial de implementação. A lei não prescreve esse esquema de campos. A clínica deve ajustar o desenho ao serviço, à obrigação profissional e à avaliação jurídica aplicável.

Consentimento parental não é universal nem descartável

Duas simplificações falham. Exigir consentimento para tudo mistura finalidades e pode sugerir escolha inexistente em etapas necessárias. Concluir que o enunciado tornou consentimento sempre desnecessário também erra: o artigo 14 continua vigente, e certas finalidades podem depender de consentimento específico.

Construa uma matriz por finalidade. Para solicitar horário, indique dados, titular, hipótese considerada, necessidade e melhor interesse. Faça o mesmo para lembretes, documentos, triagem, pesquisa e marketing. Se houver consentimento, registre quem consentiu, vínculo declarado, versão do aviso, finalidade, momento e mecanismo de retirada. Avalie esforços razoáveis para verificar a pessoa responsável quando essa regra incidir.

Não use a autorização para agendar como licença para publicidade. Uma mensagem necessária sobre horário não equivale a campanha promocional. Da mesma forma, aceitar termos do serviço não torna dados de saúde elegíveis para uma plataforma de anúncios. O artigo sobre base legal e Customer Match em saúde explica essa separação.

Quando avaliar o ECA Digital

A Lei nº 15.211/2025, conhecida como ECA Digital, estabelece regras de proteção de crianças e adolescentes em ambientes digitais. Seu escopo inclui produtos ou serviços de tecnologia da informação direcionados a crianças e adolescentes ou de acesso provável por eles. A análise não depende só do texto “para maiores de 18 anos” ou de quem assina o formulário.

O parágrafo único do art. 1º indica três situações de acesso provável: suficiente probabilidade de uso e atratividade do produto ou serviço por crianças e adolescentes; considerável facilidade de acesso e utilização por esse público; e significativo grau de risco à privacidade, à segurança ou ao desenvolvimento biopsicossocial, especialmente em produtos ou serviços voltados à interação social e ao compartilhamento de informações em larga escala.

A partir desses critérios legais, verifique se adolescentes são convidados a acessar o serviço, se campanhas chegam a menores, se a linguagem fala com eles, se a jornada admite conta própria e se é provável o uso sem mediação. Um portal para responsáveis pode diferir de um aplicativo adolescente. A especialidade pediátrica, sozinha, não decide.

Se o produto for direcionado a menores ou provavelmente acessado por eles, avalie as obrigações atuais da lei e a regulamentação da ANPD. A lei enfatiza proteção integral, melhor interesse, prevenção, informação, privacidade, segurança e desenho compatível com o público. A página temática da ANPD reúne o material regulatório vigente e deve ser revisada porque orientações podem evoluir.

Este é um teste independente da base legal da LGPD. Um tratamento pode ter hipótese legal e ainda exigir ajustes de produto sob o ECA Digital. O inverso também vale: classificar o serviço fora do escopo específico do ECA Digital não encerra LGPD, regras profissionais, contratos ou proteção do consumidor.

Desenho recomendado para uma jornada pediátrica contida

Depois da análise jurídica, traduza o resultado em fronteiras técnicas. Um desenho editorial possível é:

  1. Identifique a pessoa usuária: responsável, adolescente ou outro contato autorizado, sem forçar uma resposta incompatível com o serviço.
  2. Separe titulares: não grave telefone do responsável como se pertencesse automaticamente à criança.
  3. Peça o mínimo: use categorias amplas e adie detalhes clínicos para o canal assistencial.
  4. Mostre aviso contextual: explique finalidade, destinatários e próximos passos perto da coleta.
  5. Controle mensagens: lembrete operacional e marketing têm preferências e templates separados.
  6. Limite integrações: envie a cada destino apenas os campos aprovados para sua finalidade.
  7. Defina retenção: trate pedidos abandonados, duplicados e não confirmados com regra própria.
  8. Registre mudanças: novo campo, canal ou público reabre a avaliação.

Mensuração pode usar contagens e estados sem detalhes da consulta. Veja como medir comparecimento sem conteúdo clínico. Também preserve a diferença entre origem do agendamento e origem de marketing, pois a mesma pessoa pode chegar por um canal e concluir o pedido em outro.

Controles de acesso, comunicação e evidência

O banco deve representar o vínculo sem acesso amplo. Recepção administra agenda; equipe assistencial acessa o necessário ao cuidado; marketing recebe apenas sinais aprovados e não clínicos. Logs registram acesso e mudança de estado sem copiar texto sensível. Exportações seguem a autorização da tela.

Em mensagens, evite revelar especialidade, condição ou procedimento na notificação de bloqueio de tela. Confirme o canal antes de enviar detalhes. Quando o contato pertence ao responsável, deixe isso explícito no cadastro. Quando o adolescente usa contato próprio, avalie segurança, expectativa de confidencialidade e regras profissionais do caso.

Guarde evidência suficiente para explicar a decisão: versão do fluxo, matriz de finalidade e base, avaliação do melhor interesse, teste de escopo do ECA Digital, campos publicados, destinatários, retenção e aprovações. Evidência não significa acumular todos os dados enviados. Significa provar a regra e sua execução.

Perguntas frequentes

O agendamento de criança sempre exige consentimento parental?

Não como regra universal. O Enunciado CD/ANPD nº 1/2023 admite hipóteses dos artigos 7º e 11, desde que o melhor interesse prevaleça no caso concreto. Consentimento e demais requisitos do artigo 14 ainda precisam ser avaliados para a finalidade específica.

O ECA Digital se aplica a toda clínica pediátrica?

Não automaticamente. Teste se o produto ou serviço digital é direcionado a crianças e adolescentes ou provavelmente acessado por eles. Especialidade, marketing, interface e uso esperado são fatos relevantes, não atalhos conclusivos.

Posso usar a mesma autorização para agendamento e marketing?

Não presuma. São finalidades diferentes. Separe necessidade assistencial, comunicação operacional e promoção; identifique a hipótese, o aviso e a escolha apropriados para cada uma.

É adequado pedir o motivo detalhado da consulta no primeiro formulário?

Somente se houver necessidade demonstrada e canal compatível. Uma categoria ampla ou etapa assistencial posterior pode reduzir exposição. A decisão depende do serviço e das obrigações profissionais.

Como provar que o melhor interesse foi considerado?

Documente riscos, alternativas, necessidade de campos, acesso, retenção, transparência, autonomia e impacto sobre a criança ou adolescente. Depois teste se o produto implementa a decisão registrada.

Referências

Uma conversão de chamada no Google Ads não prova que a clínica agendou uma consulta

Uma conversão de chamada no Google Ads não prova que a clínica agendou uma consulta. Nos tipos de acompanhamento baseados em duração, ela confirma que a ligação alcançou ou superou o limite configurado. O agendamento só existe quando a agenda cria um horário válido. O comparecimento exige outro registro, feito depois.

Essa separação evita que uma métrica da plataforma receba um significado que ela não tem. Duração não comprova intenção, qualidade do lead, marcação, presença ou receita. O relatório pode usar todos esses estados, mas precisa mostrar a fonte de cada um.

O que o Google chama de conversão de chamada?

O Google documenta cinco formas de acompanhar conversões de chamada. Em chamadas feitas a partir de anúncios e em ligações para um número no site, o anunciante define uma duração mínima. A plataforma conta como conversão cada chamada que atinge ou supera esse limite, desde que a configuração necessária esteja ativa.

Há outros comportamentos. Em cliques num número da versão móvel do site, o Google informa que pode acompanhar somente o clique, não a ligação. Em cliques em recursos e anúncios de chamada sem número de encaminhamento, a conversão pode usar uma estimativa de que ocorreu uma ligação significativa.

Esses são os fatos documentados: cada método tem uma regra técnica de contagem. Nossa recomendação editorial é não traduzir essa contagem como “consulta agendada”. A taxonomia de resultados de agendamento mantém formulário, chamada, marcação e presença como estados distintos.

Por que o limite de duração não mede qualidade do lead?

O limite responde a uma pergunta estreita: a duração chegou ao valor configurado? A documentação não afirma que esse tempo comprova a identidade da pessoa, o motivo da ligação, a adequação à clínica, a disponibilidade de horário, a criação de uma marcação ou o resultado posterior.

No exemplo do próprio Google, um limite de 30 segundos e uma ligação de 26 segundos produzem uma chamada e zero conversão de chamada. Se a ligação durasse o suficiente para cruzar o limite, a regra técnica mudaria a contagem. Ela não acrescentaria, por si só, um registro de agendamento.

Não use duração como nota de qualidade. Uma equipe pode testar limites para reduzir ruído na métrica, mas precisa nomear esse trabalho corretamente. A configuração ajusta o critério do Google Ads. Ela não consulta a agenda nem confirma interesse clínico.

Qual sistema confirma o agendamento e o comparecimento?

A agenda confirma o agendamento porque é nela que o horário ganha existência operacional. O estado deve seguir a definição adotada pela clínica, como horário criado e válido. Uma ligação pode anteceder esse evento, ocorrer depois dele ou terminar sem que nenhum horário seja criado.

O comparecimento pertence a uma etapa posterior. A agenda ou outro sistema operacional aprovado registra o resultado segundo uma regra local. Nem a duração da chamada nem a conversão exibida no Google Ads substituem esse registro.

Nossa recomendação de mensuração é preservar a fonte oficial de cada estado. Essa não é uma definição publicada pelo Google. O artigo sobre como medir comparecimento por campanha mostra como manter o resultado no ambiente aprovado e apresentar apenas o agregado necessário.

Como separar as quatro etapas no relatório?

Use colunas distintas para chamada, conversão de chamada, agendamento e comparecimento. Não some os quatro estados como se fossem versões do mesmo evento. Também não use um nome genérico, como “conversão final”, sem explicar qual fonte e regra sustentam a contagem.

Estado Regra Fonte O que não prova
Chamada Ligação registrada no relatório aplicável Relatório de chamadas do Google Ads Duração mínima, qualidade ou agendamento
Conversão de chamada Regra do método de acompanhamento, como duração mínima Google Ads Qualidade, marcação ou presença
Agendamento criado Horário válido criado segundo a regra da clínica Agenda Comparecimento
Comparecimento Presença finalizada segundo a regra da clínica Agenda ou sistema operacional aprovado Receita ou aceitação de tratamento

A tabela é um modelo editorial. O Google documenta as métricas de chamada e o limite de duração; não publica esta taxonomia completa para clínicas. Cada operação precisa mapear os estados reais da própria agenda antes de usar o relatório.

Para comparar períodos, registre a duração mínima vigente e a data de cada alteração. Uma mudança no limite pode alterar a quantidade de conversões de chamada sem que o volume de ligações, agendamentos ou comparecimentos tenha mudado na mesma proporção.

Por que as datas podem divergir?

O Google informa chamadas na data em que elas ocorrem. Já as conversões de chamada aparecem na data do clique no anúncio. A própria documentação mostra uma pessoa que clica em 5 de agosto e liga em 7 de agosto: a chamada fica no dia 7, enquanto a conversão volta ao dia 5.

A agenda pode acrescentar outra data. A consulta talvez seja marcada no dia da ligação para um horário futuro, e a presença só será conhecida depois. Um painel que agrupa tudo pela mesma data pode criar diferenças difíceis de reconciliar entre Google Ads, recepção e agenda.

A recomendação é manter pelo menos a data do clique atribuída pela plataforma, a data da chamada, a data de criação do agendamento e a data do resultado operacional. O relatório por coorte original de leads explica por que resultados tardios devem voltar à coorte de aquisição sem apagar o calendário operacional.

Quando a importação de conversões de chamada muda a análise?

O Google também documenta a importação de conversões de chamada acompanhadas em outro sistema. A página usa vendas como exemplo de um resultado que o anunciante pode selecionar e valorizar. Isso oferece mais controle sobre quais ligações entram na ação importada, mas não transforma duração em resultado comercial.

Para clínicas, qualquer desenho de importação exige uma revisão separada de política, privacidade e legalidade. A documentação de chamadas descreve capacidade técnica. Ela não autoriza o envio de dados de pacientes, conteúdo da ligação, detalhes de consulta ou informação médica.

Este artigo não recomenda importar agendamentos ou comparecimentos para o Google Ads. A recomendação editorial é manter esses resultados no relatório interno por padrão e revisar qualquer destino externo antes de criar o payload. Veja onde governar ações de conversão da clínica para separar propriedade da conta, acesso e mudança operacional.

Como auditar uma discrepância entre chamadas e agenda?

  1. Confirme qual tipo de acompanhamento de chamada está ativo.
  2. Registre a duração mínima configurada no período analisado.
  3. Compare chamadas com conversões de chamada sem exigir igualdade entre elas.
  4. Separe a data da ligação da data do clique usada pela conversão.
  5. Conte agendamentos apenas na agenda e segundo uma definição escrita.
  6. Conte comparecimentos somente após o estado ficar finalizado.
  7. Investigue a junção entre fontes sem copiar dados clínicos para o Google.

Esse roteiro é uma recomendação editorial. O Google documenta os campos e regras da plataforma, enquanto a clínica controla as definições de agendamento e comparecimento. O relatório deve dizer qual parte vem de documentação oficial e qual parte é um contrato interno.

Se o objetivo for avaliar faltas, use coortes maduras e denominadores definidos. Não tente deduzir presença pela duração da ligação. O método de taxa de faltas por origem do agendamento trata cancelamentos, remarcações e consultas abertas fora do denominador final.

Perguntas frequentes

Uma chamada acima do limite significa que o lead é qualificado?

Não. Ela significa que a ligação cumpriu a regra de duração da ação, quando esse é o método configurado. A documentação não atribui qualidade, agendamento ou valor clínico ao tempo. A qualificação precisa de uma definição e uma fonte separadas.

Uma chamada curta nunca gera agendamento?

Essa conclusão também não é válida. Uma ligação abaixo do limite pode deixar de ser contada como conversão de chamada e ainda assim produzir um agendamento na agenda. O Google Ads e a agenda estão medindo fatos diferentes.

Por que há mais chamadas do que conversões de chamada?

O Google explica que chamadas não têm requisito de duração, enquanto uma conversão pode depender do limite definido na conta. Chamadas abaixo desse limite entram como chamadas, mas não como conversões de chamada.

A recepção deve editar o Google Ads após cada ligação?

Não como rotina derivada deste artigo. A recepção deve registrar o resultado no sistema aprovado da clínica. Qualquer integração ou importação exige desenho técnico, política vigente e revisão qualificada antes de enviar dados.

Referências

Como encontrar horários manuais na Doctoralia que ficaram fora da integração com o Feegow

Um horário visível na Doctoralia não prova, por si só, que ele foi criado manualmente e ficou fora da integração com o Feegow. A verificação precisa comparar profissional, local, data, intervalo e origem da disponibilidade antes de qualquer alteração.

A documentação do Feegow reconhece que podem existir disponibilidades criadas diretamente na Doctoralia, sem integração com o Feegow, e orienta a identificação do local e dos horários ativos. A decisão editorial segura é auditar primeiro, desativar somente o excedente confirmado e repetir um agendamento sintético antes de liberar a agenda.

O que a documentação do Feegow registra

O artigo do Feegow sobre disponibilidades da Doctoralia informa que alguns horários podem ter sido criados diretamente na plataforma externa, sem integração com o Feegow. Para esse caso, a orientação publicada passa pelo acesso às configurações de agendas da Doctoralia, pela identificação do local que não está integrado e pela identificação e inativação dos horários ativos correspondentes.

O guia de integração determina que os horários externos partam da grade padrão do profissional no Feegow. Os Horários Personalizados não são sincronizados com a Doctoralia.

Essas são descrições publicadas pelo fornecedor. Elas não mostram a configuração atual de uma clínica, não identificam automaticamente qual horário é excedente e não substituem a conferência do ambiente real. Os dois links exatos estão em Referências e devem ser revistos antes de executar o procedimento, pois telas e regras podem mudar.

O que não deve ser presumido

Uma disponibilidade visível apenas na Doctoralia pode ser horário direto sem integração, grade padrão do profissional no Feegow, Horário Personalizado sem sincronização ou diferença entre duração do procedimento e intervalo da grade. Se a comparação não resolver o estado, não altere o horário e encaminhe a evidência ao suporte.

Dois horários parecidos não provam duas vagas. Compare a duração do procedimento na Doctoralia com o intervalo da grade padrão do Feegow e confirme com teste controlado.

Por fim, não trate a orientação do fornecedor como prova de que a integração está saudável. A documentação explica o comportamento esperado. A verificação editorial segura confirma configurações, executa um agendamento sintético e observa os registros produzidos em ambos os lados.

Prepare uma auditoria por profissional e local

Escolha um período curto e sem alterações concorrentes. Avise as pessoas responsáveis pelas agendas para que ninguém crie ou remova disponibilidades durante a coleta. Se isso não for possível, registre o horário exato de cada captura e todas as mudanças conhecidas.

Monte uma planilha operacional sem dados de pacientes. Uma linha deve representar uma disponibilidade candidata e conter:

  • profissional e identificador interno aprovado;
  • local e sala quando essa distinção afetar a agenda;
  • data, hora inicial, hora final e duração;
  • tipo de atendimento quando ele controlar a disponibilidade;
  • estado exibido no Feegow;
  • estado exibido na Doctoralia;
  • origem informada pela configuração, quando disponível;
  • evidência de vínculo ou ausência de vínculo;
  • decisão, responsável, data e forma de reversão.

Use os mesmos filtros de profissional, local e período nos dois sistemas. Se o nome de um local for diferente, confirme o mapeamento antes de comparar. Não corrija nomes ou vínculos durante a coleta, pois isso mudaria a evidência que a auditoria tenta explicar.

Compare a grade do Feegow com a disponibilidade da Doctoralia

Comece na grade padrão do profissional no Feegow, origem documentada dos horários externos. Exclua Horários Personalizados, que não sincronizam com a Doctoralia. Compare os blocos da mesma combinação de profissional e local nas configurações de agendas da Doctoralia.

Classifique cada intervalo em uma destas situações:

Situação observada Interpretação segura Próxima verificação
Corresponde à grade padrão do Feegow O horário externo encontra correspondência na grade padrão do profissional Confirmar com teste sintético
Criado diretamente na Doctoralia Horário ativo sem integração com o Feegow Confirmar profissional e local antes de inativar
Horário Personalizado no Feegow Esse tipo de horário não é sincronizado com a Doctoralia Não tratá-lo como grade externa integrada
Duração do procedimento diferente da grade O intervalo da grade e a duração configurada na Doctoralia não coincidem Comparar procedimento e grade antes de alterar
Estado incerto Evidência insuficiente Não alterar e encaminhar para suporte

Um intervalo vira excedente confirmado somente quando a equipe consegue mostrar que ele está ativo diretamente na Doctoralia sem integração, não corresponde à grade padrão do profissional no Feegow, não é um Horário Personalizado e não resulta da diferença entre a duração do procedimento e o intervalo da grade. Até lá, mantenha a classificação como candidata ou incerta.

Se a análise também precisa preservar atribuição, consulte como comparar alternativas à Doctoralia sem perder a origem do agendamento. A origem operacional do horário e a origem de marketing não são o mesmo campo, como explica o guia de origem do agendamento versus origem de marketing.

Desative somente o excedente confirmado

Antes da alteração, registre a configuração atual, o responsável pela aprovação e o passo exato para reativar o horário. Confirme com a administração da clínica e com o profissional quando houver dúvida sobre uma exceção de agenda. A própria orientação do Feegow recomenda alinhamento para que as agendas sejam geridas pelo sistema integrado.

Na Doctoralia, navegue até a área de configuração de agendas indicada pela documentação e filtre o local correto. Desative somente o intervalo que corresponde à linha aprovada na auditoria. Não use uma ação em massa quando a evidência cobre apenas um profissional, local ou período.

Depois da alteração, atualize a linha com o estado final e a hora da mudança. Não apague a evidência anterior. Se o resultado for diferente do esperado, reverta o mesmo item e interrompa a sequência. Uma alteração ambígua não deve ser compensada com outras desativações.

Essa abordagem também preserva a comparação entre canais. O artigo sobre alternativas à Doctoralia para agenda e lembretes ajuda a separar aquisição, disponibilidade e comunicação, sem presumir que trocar de ferramenta resolve uma configuração local.

Repita um agendamento sintético

Crie um cenário de teste dentro do processo autorizado pela clínica, sem usar dados de paciente. Escolha um profissional, local e intervalo controlados. Use um contato de teste aprovado ou um destino que não alcance terceiros. Registre cada etapa e o identificador técnico permitido.

  1. Confirme no Feegow que o horário está ativo na grade padrão do profissional e não é um Horário Personalizado, que não sincroniza com a Doctoralia.
  2. Confirme na Doctoralia que apenas a disponibilidade esperada está pública.
  3. Faça um agendamento sintético pelo caminho externo.
  4. Verifique se o agendamento aparece no profissional e local corretos no Feegow.
  5. Confirme que o mesmo intervalo deixou de aceitar outro agendamento.
  6. Use o botão amarelo Remarcar e verifique a atualização nos dois sistemas. Não altere apenas o status para remarcado, pois essa mudança de status não é refletida pela integração.
  7. Cancele o registro e confirme o estado final conforme a regra documentada.

O teste precisa preservar a linhagem quando a remarcação gera outro identificador. O guia para preservar a origem após uma remarcação mostra por que o novo horário não deve ser contado como nova aquisição.

Um teste bem-sucedido comprova apenas o cenário executado. Repita para outras combinações quando profissional, local, duração ou tipo de atendimento usam regras diferentes. Não declare toda a integração validada a partir de uma única combinação.

Defina critérios de parada e escalonamento

Interrompa a alteração se não for possível distinguir horário direto da Doctoralia, grade padrão do Feegow, Horário Personalizado ou diferença entre duração do procedimento e intervalo da grade. Se o estado continuar sem explicação ou a tela atual não corresponder à documentação, preserve capturas sem dados pessoais, horários, identificadores técnicos permitidos e passos de reprodução para o suporte.

Encaminhe o caso ao suporte responsável pela integração com uma descrição objetiva: profissional, local, período, configuração esperada, estado observado, teste executado e diferença encontrada. Não envie prontuário, conteúdo clínico ou dados pessoais que não sejam necessários ao atendimento.

Após a correção, repita o teste que falhou. Só libere a agenda quando o cenário controlado produzir a disponibilidade, reserva, remarcação e cancelamento esperados. Registre quem aprovou a liberação e a data da próxima revisão.

Mantenha a verificação recorrente

Repita uma amostra da auditoria depois de mudanças na integração, inclusão de profissional, novo local, alteração de duração ou edição direta na Doctoralia. Uma checagem curta e documentada reduz o tempo entre uma divergência e sua identificação, sem prometer que conflitos nunca ocorrerão.

Relatórios devem separar disponibilidade, agendamento e resultado final. Para revisar faltas e cancelamentos sem confundir as ações, consulte lembretes versus lista de espera. A existência de um horário externo não explica, sozinha, o motivo de uma falta, cancelamento ou conversão.

Perguntas frequentes

Todo horário visível apenas na Doctoralia deve ser desativado?

Não. Ele é um candidato à investigação. Confirme profissional, local, duração, origem, vínculo e exceções aprovadas. Desative somente o excedente confirmado e mantenha um passo de reversão.

Posso criar na Doctoralia o horário que não apareceu após a integração?

O guia citado orienta que os horários destinados ao agendamento externo partam da grade padrão do profissional no Feegow. Os Horários Personalizados não são sincronizados com a Doctoralia. Se um horário esperado não aparece, compare a grade padrão, a duração do procedimento e a configuração da Doctoralia antes de criar uma disponibilidade paralela.

Um agendamento sintético prova que toda a integração funciona?

Não. Ele valida a combinação testada de profissional, local, duração, tipo e caminho. Repita o teste quando outras combinações usam regras diferentes e registre o escopo aprovado.

Referências

Outside HIPAA Does Not Make Health Conversion Tracking Low Risk

A finding that HIPAA does not apply to a particular actor or activity answers only the HIPAA question. It does not establish that health conversion tracking is low risk. The same flow may still require a separate assessment under the FTC Health Breach Notification Rule, a state consumer health law such as Washington’s My Health My Data Act, and the policy for the specific Google Ads feature receiving the data.

Each test has its own definitions, exemptions, and duties. Do not turn “not a HIPAA covered entity” into a release gate. Map actor, data, action, recipient, jurisdiction, and advertising product, then record evidence and an owner for each branch.

Build four gates, not one compliance label

A conversion flow can begin with a booking form, pass through a CRM or server, and end in an advertising product. Each step can change the relevant actor, purpose, and disclosure. A clinic, wellness app, software vendor, agency, and ad platform should not be grouped under one label. Nor should every value called a “conversion” be treated alike.

Create one record per flow: source, fields, identifiers, transformations, recipients, purpose, retention, population, jurisdiction, and exact destination feature. A generic destination like “Google” is too broad for a policy decision. A branch may be applicable, exempt, prohibited, conditional, or unresolved, but evidence from one branch does not prove another.

Gate 1: HIPAA asks who is acting and in what role

45 CFR 160.103 defines covered entities through categories including health plans, clearinghouses, and providers that transmit health information electronically in covered transactions. It defines business associate through specified functions and services involving protected health information on behalf of a covered entity or another business associate, with stated exceptions.

A company outside the covered-entity definition for one product may be a business associate elsewhere. A provider can also have activities outside a HIPAA-regulated flow. Assess the specific actor, service, activity, and information. Medical vocabulary or a health-related audience does not decide status.

If HIPAA does not govern the examined flow, record that narrow scope. Do not write “HIPAA does not apply to the company” when the analysis covered one app or marketing pathway, and do not infer that the data is safe to disclose.

When a cloud product is involved, remember that contract coverage is also product specific. The article on why a Google Cloud BAA does not cover Google Ads illustrates why a contract for one service cannot authorize a separate advertising use.

Gate 2: FTC HBNR has its own coverage and breach analysis

The FTC Health Breach Notification Rule appears in 16 CFR Part 318. It applies to covered vendors of personal health records, PHR related entities, and third-party service providers rather than using the HIPAA covered-entity test. The current rule and the 2024 final rule define key terms, including PHR identifiable health information, personal health record, covered health care provider, and breach of security.

The 2024 rulemaking clarified the FTC’s view of health apps and similar technologies, including certain unauthorized disclosures. That does not make every tracking event a reportable breach. Coverage, authorization, recipient, event, and exceptions still require fact-specific review.

Ask whether the product offers a personal health record under the rule, whether it has the technical capacity to draw information from multiple sources, what role each vendor plays, and whether an acquisition or disclosure was unauthorized. Assess notice duties only if the preceding elements hold. Use the Federal Register preamble for agency interpretation and the eCFR for current regulatory text.

Do not close this branch with “outside HIPAA.” The HBNR was designed for a different coverage boundary. Conversely, do not assume that using a health app proves HBNR applicability. Document the definition analysis.

Gate 3: Washington consumer health data law is a separate test

Washington RCW 19.373, commonly associated with the My Health My Data Act, defines consumer health data, regulated entities, processors, consumers, collection, sharing, and sale for its own purposes. It contains jurisdictional provisions and exemptions that must be reviewed before applying an obligation to a particular organization or dataset.

Where the law applies, its requirements include a consumer health data privacy policy and specific rules for collection, sharing, sale, access, deletion, processors, and security. Consent for collection or sharing and a separate signed authorization for sale are distinct concepts in the statute. An ordinary cookie banner should not be assumed to satisfy either without comparing its wording and interaction to the applicable requirement.

Start with person and geography, then classify entity and data. Check statutory exemptions. Determine whether the flow is collection, sharing, or sale under the statute, then test the matching notice, consent or authorization, processor, rights, and security provisions.

Neither “the user lives in Washington” nor “the company is a clinic” completes the statutory analysis. Preserve the facts and section supporting the conclusion.

Gate 4: Google policies depend on the exact advertising feature

Google’s Customer Data policies apply to enhanced conversions for web, enhanced conversions for leads, store sales uploads, and Google-engaged audiences. The policy prohibits uploading conversion information related to sensitive categories, including health or medical information, for the covered Customer Data products. This is a product-policy test, not a HIPAA definition or a determination that every health advertiser is prohibited from measuring any result.

Google’s personalized advertising policy separately treats health as a sensitive interest category and limits advertiser-curated audiences for that content. Customer Match belongs in this separate personalized-advertising and Customer Match policy branch, not in the four-product scope stated above. This policy does not ban all health advertising, but consent, hashing, or a lawful source cannot be assumed to make an audience or upload eligible.

Test the current product and configuration. Review every field and derived value, including URL parameters, event labels, list names, variables, and free text. A neutral event name can carry sensitive meaning when combined with its page or source. Hashing changes representation, not the underlying category or product rule.

For a narrower data design, see the clinic booking outcome taxonomy. If the proposed route uses a server or data manager, the Google Ads Data Manager clinic-form architecture helps identify boundaries, but architecture alone cannot make a prohibited payload eligible.

Consent is not a bridge across independent gates

Consent is not a universal override. The FTC branch may ask whether an acquisition or disclosure was authorized. Washington law specifies consent and sale authorization for covered activities. Google policy can prohibit a use even when the advertiser believes it has valid consent.

Keep booking consent separate from advertising choices. A person may request care without agreeing to a health-related conversion upload. Preserve notice, choice, version, time, and purpose instead of only a boolean called consent.

This is an editorial implementation recommendation. Determine the relevant consent standard under each law; this does not replace legal review or current platform terms.

A safer implementation review for health conversions

After the four gates, review the data path. Many reports can measure booking requested, confirmed, attended, or canceled without diagnosis, treatment, clinician notes, page titles, or free text. The internal treatment-value model explains why internal value and an advertising payload should remain separate.

  • Allowlist fields: reject unexpected values instead of forwarding the full form.
  • Separate destinations: do not reuse a clinical event object as an advertising event object.
  • Remove free text: keep symptoms, procedures, notes, and detailed URLs out of marketing connectors.
  • Log decisions: store gate results, policy version, owner, and evidence without logging health content.
  • Fail closed: pause transmission when classification, consent evidence, or product eligibility is unresolved.
  • Recheck changes: review new fields, destinations, jurisdictions, and policy revisions before release.

A clean technical payload does not cure an inapplicable consent or an unauthorized disclosure. Equally, a valid legal basis does not cure a product-policy prohibition. The implementation review reduces exposure after the independent decisions; it does not merge them.

Document a decision matrix that can be audited

For each flow, create four rows: HIPAA, FTC HBNR, Washington law, and Google policy. Record definitions, facts, conclusion, unresolved questions, source version, approver, and review date. Add other states when needed. “Compliant” alone is not an auditable result.

Require every relevant row to be resolved. HIPAA can be out of scope while HBNR remains open. Law may permit an activity that Google policy prohibits, or policy may allow an approach that lacks required legal authorization. In each case, keep the upload blocked.

Frequently Asked Questions

If a clinic is not a HIPAA covered entity, can it send health conversions to Google Ads?

That conclusion is insufficient. Test FTC HBNR, applicable state consumer health laws, other duties, and the exact Google Ads policy. Any one branch can stop or change the proposed flow.

Does hashing make a health conversion non-sensitive?

No general conclusion follows from hashing. It can transform an identifier, but the event, source, and combination may still relate to health, remain identifiable, or be prohibited by the selected product policy.

Does the FTC HBNR apply to every health app?

No. Apply the rule’s definitions to the product, data sources, actors, and event. The 2024 final rule provides relevant interpretation, but the facts still determine coverage and duties.

Is Washington consent the same as a cookie banner choice?

Do not assume so. Compare the interaction to the statute’s requirements for the classified collection, sharing, or sale, including the separate authorization provisions where applicable.

Does Google’s sensitive-interest policy ban all healthcare ads?

No. It restricts specified personalized advertising uses and targeting for sensitive interests. The Customer Data policy separately governs covered uploads. Review the exact feature and current policy.

References