Yandex Direct: hay solicitudes, pero no ventas. Auditoría hasta el CRM

Cuando Yandex Direct genera solicitudes pero el equipo comercial no consigue pedidos, recomendar «cambiar de audiencia» es precipitado. Una persona puede ver la promesa de una visita hoy, llegar a una página con otro servicio, dejar su teléfono y escuchar condiciones distintas durante la llamada. Cada herramienta parece funcionar: el anuncio se muestra, el formulario se envía y el CRM crea una ficha. Lo que falla es la coherencia del recorrido.

El resultado de esta auditoría es una ficha de incidencia concreta: en qué transición se perdió una promesa o una acción, qué lo demuestra, quién lo corrige y qué prueba confirmará la reparación. Es una guía para anunciantes que trabajan con el mercado ruso, no un repaso general de Metrica ni de conciliación estadística. Rusia sigue siendo la geografía en todas las traducciones. Las fuentes oficiales se comprobaron el 25 de octubre de 2026. Las plantillas, los umbrales y los dos casos son nuestra metodología editorial, no requisitos de Yandex.

Define exactamente qué ha dejado de funcionar

Selecciona una combinación: grupo de anuncios, servicio, ciudad, página de destino y vía de contacto. Para empezar resultan útiles las solicitudes de búsqueda con una intención reconocible. Sepáralas del tráfico de la red publicitaria de Yandex, de clientes recurrentes y de otros servicios. Elige un periodo cerrado con condiciones estables y fija la fecha de corte de la observación. Una operación larga que continúa abierta no equivale a un rechazo.

Necesitas acceso a anuncios y direcciones de destino, informes de Direct y Metrica, un desarrollador que compruebe el formulario, historial anonimizado del CRM y un responsable comercial. Conserva versiones del anuncio, del primer bloque de la página, del formulario y del guion inicial. Añade horarios, zona real de servicio y disponibilidad de productos o técnicos. Sin historial de versiones, la página actual no demuestra qué vio una persona ayer: deja constancia de esa limitación.

Define cuatro niveles. Un evento es una señal analítica. Una solicitud es un registro recibido realmente por la empresa. Un lead aceptado cumple las condiciones vigentes al llegar y se puede gestionar. Una venta conservada es un pedido realizado y pagado tras el periodo de observación de cancelaciones del ejemplo. Un rechazo posterior de compra no invalida automáticamente un lead aceptado. La remuneración de afiliados depende de un evento acordado por separado.

Si también preparas un canal de afiliados, regístrate como anunciante de AffiliateCore y prepara la descripción de tu oferta con una página verificada. Nuestra plataforma permite crear borradores de ofertas con nombre, descripción y URL de destino. La admisibilidad del producto y de la fuente se revisa por separado. La auditoría de Direct se realiza en tus herramientas publicitarias y CRM; aquí no prometemos una sincronización integrada de ese recorrido.

Comprueba cinco transiciones y reúne pruebas

1. Consulta de búsqueda → promesa del anuncio

El informe oficial de consultas de Direct muestra las búsquedas que originaron impresiones. Contrasta la consulta disponible con servicio, ciudad, plazo y restricciones del anuncio. No confundas la consulta con la palabra clave configurada. Si no existe una vinculación individual demostrada, no atribuyas una búsqueda a una persona: trabaja con el segmento disponible.

Prepara tres columnas: qué espera el visitante, qué se promete y qué puede cumplir la empresa. «Reparación hoy» no equivale a «te llamamos hoy». Una consulta irrelevante exige revisar la segmentación; una consulta pertinente con una promesa imposible exige corregir la oferta. Son incidencias distintas, aunque ambas terminen con el comercial descartando la solicitud.

2. Anuncio → página de destino

Abre directamente la dirección guardada, sin hacer clic repetidamente en tu propio anuncio activo. Comprueba navegadores de ordenador y móvil, destino principal y enlaces adicionales, formulario y teléfono. Compara el primer bloque con el anuncio: una exclusión importante no debería aparecer por primera vez durante la llamada. Anota fecha, versión, dispositivo y resultado esperado.

Yandex recomienda comprobar que las URL con yclid funcionan y corregir los errores del sitio que provoquen: documentación de Direct y Metrica. Revisa además el destino final tras las redirecciones y si se conserva el contexto del servicio. Una etiqueta perdida justifica investigar la medición, pero no demuestra por sí sola una venta perdida.

3. Formulario → solicitud recibida

Un objetivo de formulario puede incluir un intento fallido, según la ayuda de Metrica. Prueba por separado un formulario vacío, un número inválido, un envío correcto y una segunda pulsación. Registra respuesta visible, recepción por la empresa y creación de la ficha. Una pantalla de agradecimiento no sustituye la confirmación del guardado.

Metrica admite eventos de objetivo mediante reachGoal: descripción oficial. Nuestra recomendación es encargar al desarrollador que vincule el evento al guardado confirmado de la solicitud, no solo al clic. Es una adaptación de tu sitio, no una solución universal mediante una casilla. Marca los registros de prueba y exclúyelos de los resultados comerciales.

Yandex documenta _ym_debug=2 y el panel de depuración para el código de contador más reciente en la comprobación de objetivos. Demostrar una corrección exige tanto el evento correcto como el registro en la empresa. No introduzcas teléfonos, correos ni conversaciones en URL de diagnóstico o documentos abiertos.

4. Contacto → persona responsable

Un clic en el teléfono no demuestra una conversación. Para transmitir datos de llamadas a Metrica hace falta un servicio separado de seguimiento: ayuda oficial. Sin él, utiliza el registro telefónico disponible y deja como desconocida la asociación a una visita publicitaria concreta. Para formularios, comprueba recepción, asignación y primera respuesta sustancial.

Revisa quién recibe solicitudes al terminar el turno, cuando falta el comercial habitual o cuando se pide un servicio poco frecuente. Una notificación en un chat común no equivale a un propietario asignado. Sigue varias fichas: ¿la persona ve las condiciones prometidas, el servicio solicitado y el contacto preferido? La falta de respuesta del cliente no demuestra un teléfono falso ni tráfico de mala calidad.

5. Respuesta → propuesta → resultado

Contrasta la primera conversación con la publicidad. ¿Se ofreció la acción prometida, se explicó el precio antes del acuerdo y se fijó el siguiente paso? Para cada venta perdida registra un motivo demostrable: falta de horario, otro servicio, propuesta inadecuada, rechazo del cliente o desconocido. No sustituyas lo desconocido por la etiqueta cómoda de «no cualificado».

Plantilla de trazabilidad: ID interno; hora y zona horaria; grupo de anuncios; versión de la promesa; página; vía de contacto; prueba de recepción; responsable; primera respuesta; siguiente paso; resultado; motivo; referencia a prueba accesible; campos desconocidos. Conserva los contactos en el sistema habitual con acceso restringido. Para el desarrollador suelen bastar el ID técnico y las condiciones reproducibles.

Caso público de Skillfactory: definir una solicitud cualificada

El caso Skillfactory de Yandex (20-02-2024) describe validación CRM sin duplicados. Son solicitudes cualificadas, no ventas pagadas; no verificamos independientemente este relato del proveedor. Yandex.

Nuestra aplicación a la auditoría consiste en examinar el paso de recibir un registro a aceptarlo para trabajar. Escribe la regla de cualificación antes de mirar los resultados; así evitarás reclasificar retrospectivamente una venta fallida como un mal lead. Solicita una cadena de pruebas con acceso restringido: petición original, decisión del revisor y desenlace del pedido. Sin ella, deja sin verificar ventas, cancelaciones y mejora causal. Esta es nuestra prueba propuesta, no una reconstrucción del proceso interno de Skillfactory ni una descripción de su configuración actual. No copies ajustes históricos de integración sin consultar la documentación vigente.

Caso didáctico 1: reparación urgente sin cita para hoy

Una empresa ficticia de reparación de electrodomésticos en Kazán anuncia una visita hoy. La página invita a solicitar una reparación, pero la primera cita disponible es dentro de varios días. Se aísla un grupo de búsqueda y un servicio. La captación dura siete días y la observación termina el día 21 desde el inicio; todos los registros del ejemplo están cerrados entonces. No son resultados de clientes ni un plazo universal recomendado.

Antes: anuncio «Técnico hoy», primer bloque sin confirmar disponibilidad, formulario de teléfono y llamada «hoy no tenemos hueco». Después: anuncio «Reparación con cita: consulta disponibilidad», bloque inicial coherente, formulario «Consultar cita» y respuesta «Has solicitado una cita; revisaremos zona, avería y primer horario disponible». Promete urgencia solo cuando realmente puedas cumplirla.

La prueba empieza en la dirección móvil del anuncio. Una persona comprueba envíos inválidos y válidos, después una única ficha operativa, el servicio pedido y el responsable asignado. Se prueba aparte una solicitud al final del turno. El éxito es un registro guardado con contexto y un siguiente paso comprensible. Las pruebas no se remuneran ni forman parte de la cohorte comercial.

En el registro didáctico, separa contactos repetidos por la misma reparación, otros servicios, contactos no establecidos y solicitudes aceptadas. Vincula la repetición al original sin borrar el historial. Quien rechaza el horario disponible puede haber enviado un lead válido. Registra por separado un pedido ejecutado y su cancelación posterior: la solicitud aceptada no debe desaparecer porque no se conserve la venta.

La evidencia es la promesa guardada de atención hoy y una nota autorizada que documenta la falta de cita. No deduzcas el motivo de una curva de conversión descendente. Una negativa por otra razón debe seguir diferenciada. Corrige la promesa y la conversación sobre disponibilidad; después comprueba con la hoja que el comercial asignado ve la tarea original.

Pausa la vía afectada si la promesa es imposible o se pierde un envío válido. Tras corregir, repite el recorrido en ordenador y móvil, incluida la entrega al final del turno. Continúa un piloto limitado solo si pasan las comprobaciones de promesa, recepción y responsable y el equipo puede atender las citas ofrecidas. Mantén abiertos los pedidos pendientes hasta el corte acordado. Un éxito técnico no demuestra crecimiento de ventas.

Caso didáctico 2: pide un presupuesto y recibe otra propuesta

Un proveedor ficticio de equipamiento de oficina en Ekaterimburgo recibe solicitudes de conjuntos para oficinas pequeñas. El anuncio y la página ofrecen un presupuesto según el número de puestos. El formulario guarda teléfono y cantidad, pero el comercial recibe un aviso sin ese contexto y empieza vendiendo un solo aparato. La entrega técnica funciona; falla la transmisión de la tarea del cliente.

Plantilla de aviso: «Solicitud de conjunto; ID; número de puestos; categoría; versión de página; contacto preferido; responsable; siguiente acción». Primera respuesta: «Has solicitado equipamiento para el número de puestos indicado. Aclaremos la composición y las restricciones y acordemos cuándo enviar el presupuesto». Los datos no facilitados se marcan como desconocidos, no se inventan.

La prueba incluye dos solicitudes correctas de categorías distintas y una repetición. El comercial debe ver la petición original, abrir la ficha correcta y asignar el siguiente paso. La repetición se vincula según las reglas de la empresa. El responsable del CRM decide cómo trasladar campos; no se presupone ningún conector específico. Comprueba la reasignación por separado de los cambios de texto.

Prepara registros didácticos separados para una petición de presupuesto repetida, un producto no ofrecido, un contacto no establecido y una solicitud de conjunto aceptada. Esta última puede perderse o cancelarse sin convertirse en un lead inválido. Conserva la decisión inicial y añade el desenlace comercial. Revisa la primera respuesta antes de atribuir una pérdida a la falta de contexto; otros motivos deben seguir distinguiéndose.

El responsable compara primero formulario, contenido de ficha y propuesta inicial. Si la cantidad de puestos está en el CRM pero se ignora, el problema es la gestión. Si falta en la solicitud almacenada, debe revisarla el responsable del formulario. Esto determina la reparación: formación y responsabilidad, o recuperación de la transmisión del campo.

Pausa la vía afectada si el comercial no ve el contexto obligatorio o nadie asume la entrega. Tras corregir, prueba distintas categorías, una repetición y la asignación al sustituto. Continúa solo cuando el comercial pueda explicar la petición original y registrar el siguiente paso prometido. Amplía con capacidad para preparar propuestas y sin fallos de entrega pendientes. Una propuesta no equivale a un pedido realizado.

Para una oferta de afiliados separada, entra en la cuenta de anunciante de AffiliateCore y utiliza descripción y URL verificadas en el borrador, si la creación está disponible para tu cuenta. Documenta primero las condiciones de aceptación en un briefing. CRM, Direct y tiempos de respuesta siguen bajo tu responsabilidad. Los pedidos del ejemplo no se presentan como eventos remunerables automáticamente compatibles con la plataforma.

Hoja de trabajo para la entrega al CRM

Copia esta hoja en un documento de acceso restringido. Acuerda la ventana de prueba con el responsable del formulario y el equipo comercial. Utiliza contactos de prueba autorizados, conservados fuera de la hoja, y marca cada prueba. Completa primero el acuerdo de entrega, ejecuta los casos y añade comprobantes anonimizados o referencias de registros. Utiliza un entorno de pruebas si existe. Simula allí el fallo de entrega o revisa un incidente existente autorizado; no rompas una integración activa para obtener evidencias. Las pruebas no deben generar conversiones remuneradas ni alimentar objetivos comerciales de optimización. Esta es una plantilla editorial, no una integración de AffiliateCore.

Descargar la hoja de trabajo en texto

ENTREGA AL CRM — COPIA DE TRABAJO
Ámbito: Rusia / Yandex Direct; el idioma no demuestra disponibilidad.
No incluyas nombres, contactos, credenciales ni transcripciones.

ACUERDO DE ENTREGA EN BLANCO
Recorrido / servicio / versión de página: ____
Promesa del anuncio / excepciones permitidas: ____
Entorno de pruebas / ventana autorizada: ____
Referencia de auditoría / hora de recepción y zona: ____
Comprobante de recepción / referencia de ficha CRM: ____
Contexto obligatorio / valores observados: ____
Responsable / sustituto / siguiente acción / plazo: ____
Regla de cualificación y versión: ____
Decisión: aceptada / rechazada / duplicada / desconocida: ____
Motivo / evidencia / revisor / hora de decisión: ____
Regla de duplicados / referencia original: ____
Pedido: abierto / perdido / realizado / cancelado: ____
Evidencia del resultado / fecha de corte: ____
Incógnitas / responsable de comprobarlas: ____
Fallo / versión corregida / evidencia de repetición: ____
Decisión: aprobado / no aprobado / parar; responsable: ____

EJEMPLO DIDÁCTICO COMPLETADO — INVENTADO, NO SON RESULTADOS DE CLIENTES
Recorrido: conjunto de oficina; página versión B.
Referencia: TEST-B; hora: ventana acordada, Europe/Moscow.
Promesa: hablar de un conjunto completo para puestos de trabajo.
Contexto obligatorio: categoría del conjunto; canal de respuesta.
Comprobante: TEST-RECEIPT-B; ficha CRM: TEST-CRM-B.
Observación: categoría guardada, pero ausente del aviso al comercial.
Responsable: coordinador de prueba comercial; sustituto: jefe de turno.
Decisión: solicitud de prueba aceptada; no es una venta.
Motivo: servicio ofrecido y recepción confirmada.
Siguiente acción: abrir la ficha completa y confirmar el conjunto solicitado.
Pedido: abierto; sin evidencia de ejecución o cancelación.
Incógnita: si otras vías de aviso pierden la categoría.
Responsable del fallo: administrador CRM; cambio: aviso versión C.
Repetición: el comercial asignado ve la categoría en la nueva versión.
Decisión: no aprobado antes de corregir; aprobar solo con repetición demostrada.

CASOS DE PRUEBA — RESULTADOS ESPERADOS
VÁLIDA: enviar una solicitud autorizada de un servicio ofrecido.
Se esperan recepción, ficha vinculada, contexto, responsable y siguiente paso.
INVÁLIDA: omitir un campo obligatorio.
Se espera validación visible; ninguna solicitud comercial aceptada.
REPETIDA: repetir la misma petición autorizada.
Se espera vínculo documentado al original, sin segundo resultado aceptado.
OTRA TAREA: mismo contacto de prueba, otra petición legítima.
Se espera revisión de la regla de duplicados, no eliminación automática.
RECHAZADA: solicitar un servicio fuera de la oferta.
Se espera motivo ligado a la versión de condiciones; conservar recepción.
SIN RESPUESTA: revisar un caso autorizado sin contacto.
Se espera desconocido/contacto no establecido, no fraude inventado.
FIN DE TURNO: probar la entrega acordada al sustituto.
Se esperan función responsable, plazo y confirmación de recepción.
FALLO DE ENTREGA: simular de forma segura en pruebas.
Se esperan ausencia de falso éxito, evidencia recuperable y responsable.

LISTA DE ACEPTACIÓN
[ ] La promesa coincide con lo que puede prestar la empresa.
[ ] La recepción se demuestra aparte del evento analítico.
[ ] Se conservan contexto, responsable y siguiente acción.
[ ] Duplicados y rechazos tienen motivos y pruebas.
[ ] Siguen visibles los resultados abiertos y desconocidos.
[ ] Las pruebas se excluyen de resultados comerciales.
[ ] La repetición corresponde a la versión corregida.
APROBADO: cada caso aplicable cumple lo esperado.
NO APROBADO: registrar discrepancia y asignar corrección; no ampliar.
PARAR: solicitud válida perdida, promesa falsa o falta de responsable; pausar la vía afectada.
REINICIAR: documentar corrección, repetición y visto bueno comercial.

Documenta la reparación y el permiso para repetir

Ficha de incidencia: transición; acción esperada; resultado real; prueba; impacto conocido; incógnitas; responsable; versión del cambio; nueva prueba; decisión de reabrir tráfico. Ejemplo: «Página a gestión: se promete consultar disponibilidad, pero el comercial confirma visita sin comprobar; corregir guion y revisar tres solicitudes de prueba autorizadas». El número de pruebas responde al riesgo y a la variedad de recorridos, no a embellecer el informe.

No cambies audiencia, precio, formulario y equipo a la vez si quieres entender el resultado. Corrige primero el defecto demostrado y ejecuta después un piloto limitado comparable. Comparar dos periodos no demuestra causalidad: demanda, estacionalidad y capacidad pueden variar. Separa una reparación reproducible de una mejora comercial cuya causa aún no está demostrada.

Ejercicio: selecciona un recorrido y sigue diez solicitudes anonimizadas desde la promesa hasta el resultado, incluidas negativas y cancelaciones. Completa la plantilla, reproduce un fallo, asigna responsable y límite de repetición. Antes de continuar, revisa promesas, recepción, contexto, responsable, siguiente paso, madurez, cancelaciones y pruebas de cada decisión. Si faltan pruebas, el resultado útil es una incógnita precisa y una forma de resolverla.

Para cuestiones relacionadas: análisis de fuentes en Metrica, diferencias estadísticas y entrega fiable al CRM. Aquí el documento final es distinto: una ruptura demostrada en un recorrido concreto y condiciones verificables para volver a ponerlo en marcha.