Yandex Direct: chegam leads, mas não vendas — auditoria até o CRM

Quando o Yandex Direct gera solicitações, mas a equipe comercial não fecha pedidos, sugerir “trocar o público” é uma conclusão precipitada. A pessoa pode ver uma promessa de visita no mesmo dia, acessar uma página com outro serviço, deixar o telefone e ouvir condições diferentes durante o contato. Cada ferramenta parece funcionar: o anúncio aparece, o formulário é enviado e o CRM cria uma ficha. O que falha é a continuidade do percurso.

O resultado desta auditoria é um registro concreto de defeito: em qual passagem uma promessa ou ação se perdeu, qual evidência comprova isso, quem corrige e qual novo teste demonstrará a correção. É um guia para anunciantes que trabalham com o mercado russo, não uma apresentação geral dos relatórios do Metrica ou da conciliação estatística. A Rússia permanece como geografia em todas as traduções. As fontes oficiais foram verificadas em 25 de outubro de 2026. Modelos, limites e os dois cenários são nossa metodologia editorial, não exigências do Yandex.

Defina exatamente o que deixou de funcionar

Selecione uma combinação: grupo de anúncios, serviço, cidade, página de destino e forma de contato. Solicitações de pesquisa com intenção identificável são úteis para começar. Separe-as do tráfego da rede de publicidade do Yandex, de clientes recorrentes e de outros serviços. Escolha um período encerrado com condições estáveis e registre a data de corte da observação. Uma negociação longa ainda em andamento não é uma rejeição.

Você precisa dos anúncios e URLs de destino, relatórios do Direct e Metrica, apoio técnico para testar o formulário, histórico anonimizado do CRM e um responsável comercial. Preserve versões do anúncio, do primeiro bloco da página, do formulário e do início da conversa. Reúna horários, área real de atendimento e disponibilidade de produtos ou técnicos. Sem histórico de versões, a página atual não comprova o que alguém viu ontem: registre essa limitação.

Defina quatro níveis. Evento é um sinal analítico. Solicitação é um registro realmente recebido pela empresa. Lead aceito atende às condições vigentes quando chegou e pode ser trabalhado. Venda mantida é um pedido executado e pago após a janela de cancelamento definida no exemplo. A desistência posterior da compra não invalida automaticamente o lead aceito. A remuneração de afiliados depende de um evento combinado separadamente.

Se também estiver preparando um canal de afiliados, cadastre-se como anunciante na AffiliateCore e prepare uma descrição da oferta com página verificada. Nossa plataforma permite rascunhos de ofertas com nome, descrição e URL de destino. A admissibilidade do produto e da origem é analisada separadamente. A auditoria do Direct ocorre nas suas ferramentas de publicidade e no seu CRM; não prometemos sincronização integrada desse percurso.

Examine cinco passagens com evidências

1. Consulta de pesquisa → promessa do anúncio

O relatório oficial de consultas do Direct mostra pesquisas que geraram impressões. Compare a consulta disponível com serviço, cidade, prazo e restrições da promessa. Não substitua a consulta pela palavra-chave configurada. Sem vínculo individual demonstrado, não atribua uma pesquisa a uma pessoa específica; trabalhe com o segmento disponível.

Monte três colunas: expectativa do visitante, promessa publicitária e capacidade real da empresa. “Conserto hoje” não significa “ligaremos hoje”. Uma consulta inadequada exige revisão de segmentação; uma consulta pertinente associada a promessa impossível exige correção da oferta. São falhas diferentes, mesmo quando ambas terminam com o atendente recusando a solicitação.

2. Anúncio → página de destino

Abra diretamente a URL salva, sem clicar repetidamente no próprio anúncio ativo. Confira computador e celular, destino principal e links adicionais, formulário e telefone. Compare o primeiro bloco com o anúncio: uma restrição essencial não deve surgir apenas na ligação. Registre data, versão, dispositivo e resultado esperado do teste.

O Yandex recomenda verificar URLs com yclid e corrigir erros do site causados por elas: documentação do Direct e Metrica. Examine também o destino após redirecionamentos e a preservação do contexto do serviço. A perda de uma marcação justifica investigar a medição, mas não comprova sozinha uma venda perdida.

3. Formulário → solicitação recebida

Uma meta de formulário pode contar uma tentativa malsucedida, conforme a ajuda do Metrica. Teste separadamente formulário vazio, número inválido, envio válido e segundo clique. Registre resposta visível, recebimento pela empresa e criação no CRM. Uma mensagem de agradecimento não substitui a confirmação de armazenamento.

O Metrica aceita eventos de meta por reachGoal: descrição oficial. Nossa recomendação é pedir ao desenvolvedor que associe o evento desejado ao armazenamento confirmado, não apenas ao clique. Trata-se de configuração do seu site, não de uma correção universal por uma caixa de seleção. Identifique os testes e exclua-os dos resultados comerciais.

O Yandex descreve _ym_debug=2 e o painel de depuração para o código mais recente do contador na verificação de metas. A evidência da correção exige tanto o evento correto quanto o registro na empresa. Telefones, emails e conversas não devem aparecer em URLs de diagnóstico ou documentos abertos de auditoria.

4. Contato → funcionário responsável

Clicar no telefone não comprova uma conversa. O envio de dados de chamadas ao Metrica depende de serviço separado de rastreamento: orientação oficial. Sem ele, use o registro telefônico disponível e deixe desconhecida a associação a uma visita publicitária específica. Nos formulários, verifique recebimento, atribuição e primeira resposta efetiva.

Confira quem recebe solicitações no fim do turno, na ausência do atendente habitual ou para serviços pouco comuns. Uma notificação em conversa coletiva não equivale a responsável designado. Acompanhe algumas fichas: o funcionário vê condições prometidas, serviço desejado e canal preferido? A falta de resposta do cliente não comprova telefone falso nem tráfego ruim.

5. Resposta → proposta → resultado

Compare a primeira conversa com a publicidade. A ação prometida foi oferecida, o preço foi explicado antes do acordo e o próximo passo foi combinado? Para cada venda perdida registre uma causa demonstrável: falta de horário, outro serviço, proposta inadequada, desistência ou desconhecido. Não substitua o desconhecido pelo rótulo conveniente de “não qualificado”.

Modelo de rastreio: ID interno; horário e fuso; grupo de anúncios; versão da promessa; página; canal de contato; evidência de recebimento; responsável; primeira resposta; próximo passo; resultado; motivo; referência de evidência acessível; campos desconhecidos. Mantenha contatos no sistema habitual com acesso restrito. Para a tarefa do desenvolvedor, normalmente bastam ID técnico e condições reproduzíveis.

Caso público Skillfactory: o significado de uma solicitação qualificada

O caso Skillfactory do Yandex (20-02-2024) descreve validação no CRM excluindo duplicatas. Solicitações qualificadas não são vendas pagas; não verificamos independentemente esse relato do fornecedor. Yandex.

Nossa aplicação à auditoria é examinar a passagem entre receber um registro e aceitá-lo para atendimento. Escreva a regra de qualificação antes de analisar os resultados; assim, uma venda perdida não vira retrospectivamente um lead ruim. Solicite uma sequência de evidências com acesso restrito: solicitação original, decisão do revisor e desfecho do pedido. Sem ela, mantenha vendas, cancelamentos e melhoria causal como não verificados. Esse é nosso teste proposto, não uma reconstrução do processo interno da Skillfactory ou descrição da configuração atual. Não copie ajustes históricos de integração sem consultar a documentação vigente.

Cenário didático 1: reparo urgente sem horário hoje

Uma empresa fictícia de conserto de eletrodomésticos em Kazan anuncia visita hoje. A página pede uma solicitação de reparo, mas o primeiro horário disponível é para dali a alguns dias. A análise isola um grupo de pesquisa e um serviço. A coleta dura sete dias e a observação vai até o dia 21 desde o início; todas as fichas estão encerradas nesse ponto do exemplo. Não são resultados de clientes nem uma janela universal recomendada.

Antes: anúncio “Técnico hoje”, primeiro bloco sem confirmar agenda, formulário com telefone e resposta “hoje não há vagas”. Depois: anúncio “Reparo agendado: consulte disponibilidade”, abertura da página coerente, formulário “Consultar horário” e conversa “Você solicitou um agendamento; vamos verificar região, defeito e primeiro horário livre”. Só prometa urgência onde for possível cumprir.

O teste começa na URL móvel do anúncio. Um funcionário verifica envios inválidos e válidos, depois uma única ficha operacional, o serviço solicitado e a pessoa designada. Uma solicitação ao fim do turno é testada separadamente. Sucesso significa registro salvo com contexto e próximo passo compreensível. Os testes não são remunerados nem entram na coorte comercial.

No registro didático, separe contatos repetidos sobre o mesmo reparo, solicitações de outro serviço, contatos não estabelecidos e pedidos aceitos. Vincule repetições ao original sem apagar o histórico. Quem não aceita a data oferecida pode ter enviado um lead válido. Registre execução e cancelamento posterior separadamente: a solicitação aceita não deve desaparecer porque a venda não foi mantida.

A evidência é a promessa preservada de atendimento hoje e uma anotação autorizada demonstrando a falta de horário. Não deduza a causa de uma curva de conversão em queda. Desistências por outros motivos continuam separadas. Corrija promessa e conversa sobre agenda; depois confira com a folha se o funcionário designado vê a tarefa original.

Pause o percurso afetado se a promessa for impossível ou um envio válido se perder. Após corrigir, repita o percurso no computador e no celular, incluindo a passagem de fim de turno. Continue um piloto limitado somente com promessa, recebimento e responsabilidade verificados e capacidade para atender os horários oferecidos. Mantenha pedidos pendentes em aberto até o corte acordado. Sucesso técnico não comprova crescimento de vendas.

Cenário didático 2: pede orçamento, recebe outra abordagem

Um fornecedor fictício de equipamentos de escritório em Ecaterimburgo atrai pedidos de conjuntos para escritórios pequenos. Anúncio e página oferecem orçamento conforme o número de postos. O formulário salva telefone e quantidade, mas o vendedor recebe uma notificação sem contexto e começa oferecendo apenas um aparelho. A entrega técnica funciona; a tarefa do cliente se perde na passagem para o atendimento.

Modelo de notificação: “Solicitação de conjunto; ID; quantidade de postos; categoria escolhida; versão da página; contato preferido; responsável; próxima ação”. Primeira resposta: “Você solicitou equipamentos para a quantidade informada de postos. Vamos esclarecer composição e restrições e combinar quando enviar o orçamento”. Dados não fornecidos devem ficar como desconhecidos, sem preenchimento por suposição.

O teste inclui duas solicitações válidas de categorias diferentes e um envio repetido. O vendedor deve ver o pedido original, abrir a ficha correta e definir a próxima etapa. A repetição é vinculada conforme as regras da empresa. O responsável pelo CRM escolhe como transferir os campos; nenhum conector específico é pressuposto. Teste mudanças de atribuição separadamente das alterações de texto da página.

Crie registros didáticos separados para uma solicitação repetida de orçamento, produto não oferecido, contato não estabelecido e pedido de conjunto aceito. O pedido aceito pode ser perdido ou cancelado depois sem virar lead inválido. Preserve a decisão inicial de qualificação e acrescente o resultado comercial. Examine a primeira resposta antes de atribuir uma perda à falta de contexto; outros motivos devem permanecer distinguíveis.

A liderança compara primeiro formulário, conteúdo da ficha e proposta inicial. Se a quantidade está no CRM mas foi ignorada, o problema está no atendimento. Se falta já no registro salvo, cabe ao responsável pelo formulário investigar. Isso determina a correção: treinamento e atribuição ou restauração da transmissão do campo.

Pause o percurso afetado se o funcionário não enxergar o contexto obrigatório ou ninguém assumir a passagem. Após corrigir, teste categorias diferentes, repetição e designação de substituto. Continue apenas quando o vendedor puder explicar o pedido original e registrar a próxima ação prometida. Amplie com capacidade para preparar propostas e sem defeitos de entrega pendentes. Proposta não equivale a pedido executado.

Para uma oferta de afiliados separada, acesse a conta de anunciante da AffiliateCore e use descrição e URL verificadas no rascunho, se a criação estiver disponível para sua conta. Documente primeiro as condições de aceitação em um briefing. CRM, Direct e prazos de resposta continuam sob sua responsabilidade. Os pedidos didáticos não são apresentados como eventos remuneráveis automaticamente compatíveis com a plataforma.

Folha de trabalho para passagem ao CRM

Copie a folha abaixo para um documento de acesso restrito. Combine a janela de teste com o responsável pelo formulário e a liderança comercial. Use contatos de teste autorizados, mantidos fora desta folha, e identifique cada teste. Preencha primeiro o acordo de passagem, execute os casos e anexe comprovantes anonimizados ou referências de registros. Use ambiente de testes quando disponível. Simule a falha de entrega nele ou examine um incidente existente autorizado; não interrompa uma integração ativa para fabricar evidências. Testes não devem gerar conversões remuneradas nem alimentar metas comerciais de otimização. A folha é um documento editorial, não uma integração da AffiliateCore.

Baixar a folha de trabalho em texto

PASSAGEM AO CRM — CÓPIA DE TRABALHO
Escopo: Rússia / Yandex Direct; idioma não comprova disponibilidade.
Não inclua nomes, contatos, credenciais ou transcrições.

ACORDO DE PASSAGEM EM BRANCO
Percurso / serviço / versão da página: ____
Promessa do anúncio / exceções permitidas: ____
Ambiente de teste / janela autorizada: ____
Referência da auditoria / recebimento e fuso: ____
Comprovante de recebimento / referência no CRM: ____
Contexto obrigatório / valores observados: ____
Responsável / substituto / próxima ação / prazo: ____
Regra de qualificação e versão: ____
Decisão: aceita / rejeitada / duplicada / desconhecida: ____
Motivo / evidência / revisor / momento da decisão: ____
Regra de duplicidade / referência original: ____
Pedido: aberto / perdido / executado / cancelado: ____
Evidência do resultado / data de corte: ____
Incógnitas / responsável pela verificação: ____
Defeito / versão corrigida / evidência do novo teste: ____
Decisão: aprovado / reprovado / parar; responsável: ____

EXEMPLO DIDÁTICO PREENCHIDO — INVENTADO, NÃO É RESULTADO DE CLIENTE
Percurso: conjunto de escritório; página versão B.
Referência: TEST-B; horário: janela combinada, Europe/Moscow.
Promessa: conversar sobre um conjunto completo para postos de trabalho.
Contexto obrigatório: categoria do conjunto; canal de resposta.
Comprovante: TEST-RECEIPT-B; referência CRM: TEST-CRM-B.
Observado: categoria salva, mas ausente da notificação ao vendedor.
Responsável: líder do teste comercial; substituto: líder de turno.
Decisão: solicitação de teste aceita; não é venda.
Motivo: serviço oferecido e recebimento confirmado.
Próxima ação: abrir a ficha completa e confirmar o conjunto desejado.
Pedido: aberto; sem evidência de execução ou cancelamento.
Incógnita: se outros caminhos de notificação perdem a categoria.
Responsável pelo defeito: administrador CRM; correção: notificação C.
Novo teste: funcionário designado vê a categoria na nova versão.
Decisão: reprovado antes da correção; aprovado só com novo teste comprovado.

CASOS DE TESTE — RESULTADOS ESPERADOS
VÁLIDA: enviar solicitação autorizada de serviço oferecido.
Esperam-se recebimento, ficha vinculada, contexto, responsável e próxima ação.
INVÁLIDA: omitir campo obrigatório.
Espera-se validação visível; nenhuma solicitação comercial aceita.
REPETIDA: repetir a mesma solicitação autorizada.
Espera-se vínculo documentado ao original, sem segundo resultado aceito.
OUTRA TAREFA: mesmo contato de teste, outro pedido legítimo.
Espera-se revisão da regra de duplicidade, não exclusão automática.
REJEITADA: pedir serviço fora da oferta.
Espera-se motivo ligado à versão das condições; preservar recebimento.
SEM RESPOSTA: revisar caso autorizado sem contato.
Espera-se desconhecido/contato não estabelecido, não fraude inventada.
FIM DE TURNO: testar passagem combinada ao substituto.
Esperam-se função responsável, prazo e confirmação de recebimento.
FALHA DE ENTREGA: simular com segurança em ambiente de testes.
Esperam-se ausência de falso sucesso, evidência recuperável e responsável.

CHECKLIST DE ACEITAÇÃO
[ ] A promessa corresponde à capacidade real da empresa.
[ ] O recebimento é comprovado separadamente do evento analítico.
[ ] Contexto, responsável e próxima ação são preservados.
[ ] Duplicatas e rejeições têm motivos e evidências.
[ ] Resultados abertos e desconhecidos permanecem visíveis.
[ ] Testes são excluídos dos resultados comerciais.
[ ] A evidência do novo teste corresponde à versão corrigida.
APROVADO: cada caso aplicável atende à expectativa.
REPROVADO: registrar divergência e atribuir correção; não ampliar.
PARAR: solicitação válida perdida, promessa falsa ou falta de responsável; pausar o percurso afetado.
RETOMAR: registrar correção, novo teste e aprovação da liderança comercial.

Registre a correção e a autorização para repetir

Ficha do defeito: passagem; ação esperada; resultado real; evidência; impacto conhecido; desconhecidos; responsável; versão da alteração; novo teste; decisão de reabrir tráfego. Exemplo: “Página para atendimento: promete-se consultar agenda, mas o atendente confirma visita sem verificar; corrigir roteiro e testar três solicitações autorizadas”. A quantidade de testes deve refletir risco e variedade de caminhos, não deixar o relatório mais bonito.

Não altere público, preço, formulário e equipe simultaneamente se quiser compreender o resultado. Primeiro corrija o defeito demonstrado, depois execute um piloto limitado comparável. Comparar dois períodos não demonstra causalidade: demanda, sazonalidade e capacidade mudam. Separe a correção reproduzível de um crescimento de vendas cuja causa ainda não foi comprovada.

Exercício: escolha um percurso e acompanhe dez solicitações anonimizadas da promessa ao resultado, incluindo recusas e cancelamentos. Preencha o modelo, reproduza uma falha, atribua responsável e limite ao novo teste. Antes de continuar, confira promessas, recebimento, contexto, responsável, próxima ação, maturidade, cancelamentos e evidências de cada decisão. Se faltarem evidências, uma incógnita precisa e uma forma de investigá-la são resultados úteis.

Para tarefas próximas, veja análise de fontes no Metrica, diferenças estatísticas e entrega confiável ao CRM. Aqui o documento final é outro: uma ruptura demonstrada em um percurso específico e condições verificáveis para reiniciá-lo.