Yandex Direct leads but no sales: audit the path to CRM

When Yandex Direct generates enquiries but the sales team cannot turn them into orders, “change the audience” is a premature diagnosis. Someone may see a promise of a same-day visit, reach a page describing a different service, leave a number and hear entirely different conditions from a representative. Every tool can appear functional: the ad runs, the form submits and the CRM creates a record. The journey is still inconsistent.

The output of this audit is a defect record: where a promise or action was lost, what proves it, who owns the correction and which repeat test will demonstrate that it works. This is an advertiser’s guide for the Russian market, not a general Metrica reporting or statistics reconciliation tutorial. Russia remains the geography in every translation. Official sources were checked on 25 October 2026. Templates, thresholds and both worked examples are our editorial method, not Yandex requirements.

Define exactly what has stopped working

Select one combination: ad group, service, city, landing page and contact route. Search enquiries with an identifiable intent are convenient for the first pass. Keep them separate from Yandex Advertising Network traffic, returning customers and other services, whose context differs. Choose a completed period with unchanged offer conditions and record the observation cutoff. A long sales process still in progress is not a rejection.

You need access to ads and their destination URLs, Direct and Metrica reports, a developer able to test the form, anonymised CRM history and an accountable sales manager. Preserve versions of the ad, opening page section, form and first-conversation script. Also collect business hours, actual service coverage and product or technician availability. Without historical versions, today’s page cannot prove what yesterday’s visitor saw: record that limitation.

Define four levels. An event is an analytics signal. An enquiry is a record actually received by the business. An accepted lead meets the conditions in force when submitted and can be worked. A retained sale is a fulfilled, paid order after the example’s cancellation observation period. A later purchase refusal does not automatically make an accepted lead invalid. Affiliate remuneration depends on a separately agreed event.

If you are also preparing an affiliate channel, register as an AffiliateCore advertiser and prepare an offer description with a verified landing page. Our platform supports offer drafts with a name, description and landing URL. Product and source eligibility require separate review. Your Direct audit takes place in your advertising tools and CRM; this guide does not promise built-in synchronisation of that journey.

Check five transitions and collect evidence

1. Search query → ad promise

Direct’s official search query report shows queries that triggered impressions. Compare available queries with the promise: service, city, timing and exclusions. Do not substitute the targeting keyword for the actual query. Unless an individual link is established, do not assign a query to a particular person; analyse the available segment.

Make three columns: what the visitor expects, what the ad promises and what the business can deliver. “Repair today” is not satisfied by “we will call today”. An irrelevant query calls for a targeting review; a relevant query paired with an impossible promise calls for an offer correction. They are different defects even when both end in a representative rejecting the enquiry.

2. Ad → landing page

Open the saved destination directly instead of repeatedly clicking your own live ad. Check desktop and mobile browsers, the main destination and additional links, the form and telephone contact. Compare the opening section with the ad: a material exclusion should not first appear during a call. Record date, version, device and expected test outcome.

Yandex advises checking that URLs containing yclid work and correcting site errors they cause; see Direct and Metrica documentation. In this audit, also inspect the final destination after redirects and whether the service context survives. A missing tag warrants a measurement investigation, but does not by itself prove a lost sale.

3. Form → received enquiry

A form goal can include an unsuccessful attempt, as Metrica documents. Test an empty form, an invalid number, a valid submission and a second click separately. Record the visible response, receipt by the business and CRM record creation. A thank-you message cannot substitute for proof of storage.

Metrica supports goal events through reachGoal: official documentation. Our recommendation is to have a developer connect the intended event to confirmed enquiry storage, rather than a button click. This is work on your website, not a universal checkbox repair. Label test records and exclude them from commercial results.

Yandex describes _ym_debug=2 and a debugging panel for the newer tag code in its goal testing instructions. Evidence of a fix needs both the correct event and a business-side record. Never put phone numbers, email addresses or conversation text in diagnostic URLs or an open audit document.

4. Contact → accountable employee

A telephone click does not prove a conversation. Sending call information to Metrica requires a separate call-tracking service: official guidance. Without it, use the available telephone log and leave the connection to a specific advertising visit unknown. For forms, inspect receipt, assignment and the first substantive response time.

Check ownership at the end of a shift, when the usual representative is absent and when an uncommon service is selected. A notification in a shared chat is not an assigned owner. Follow several records: does the employee see the promised terms and requested service, and know the preferred contact method? A customer’s failure to respond does not prove a false number or bad traffic.

5. Response → proposal → outcome

Compare the first conversation with the advertisement. Was the promised action offered, was price explained before agreement, and was a next step arranged? Give each lost sale an evidence-based reason: no available appointment, different service, unsuitable proposal, customer refusal or unknown. Do not replace unknowns with the convenient label “unqualified”.

Trace template: internal ID; time and time zone; ad group; promise version; landing page; contact route; receipt evidence; owner; first response time; proposed next step; outcome; reason; accessible evidence reference; unknown fields. Keep personal contacts in the normal restricted system. A developer’s task usually needs a technical ID and reproducible conditions, not customer details.

Public case: Skillfactory and the meaning of a qualified enquiry

Yandex’s Skillfactory case (20 February 2024) describes CRM validation excluding duplicates. Qualified enquiries are not paid sales; the vendor account is not independently verified here. Yandex.

Our audit application is to inspect the boundary between receiving a record and accepting it for work. Write the qualification rule before reviewing outcomes: otherwise a team can quietly rename unsuccessful sales as bad leads. Ask for a restricted evidence trail linking the original enquiry, the reviewer’s decision and the subsequent order outcome. Without that trail, leave sales, cancellations and causal improvement unverified. This is our proposed test, not a reconstruction of Skillfactory’s internal workflow or a claim about its current setup. Do not copy a historical case’s integration settings into your account without checking current documentation.

Worked example 1: an urgent repair unavailable today

A fictional appliance repair company in Kazan advertises a visit today. Its page asks visitors to request a repair, but the next appointment is several days away. The audit isolates one search group and service. Collection lasts seven days; observation ends on day 21 from the start, with every example record closed by then. These are not client results or a universal recommended waiting period.

Before: ad “Technician today”, opening section without availability confirmation, telephone-only form and a call saying “we have no slots today”. After: ad “Repair by appointment — ask about availability”, a matching opening section, a form labelled “Check an appointment” and the response “You requested an appointment; let us check your area, fault and nearest available slot”. Promise urgency only where delivery supports it.

The test begins at the ad’s mobile destination. A staff member checks invalid and valid submissions, then exactly one working record, the requested service and the assigned representative. An end-of-shift enquiry is tested separately. Success means a stored record with context and an understandable next step. Test enquiries are neither paid results nor part of the commercial cohort.

In the educational ledger, separate repeated contacts about the same repair, requests for another service, unanswered contacts and accepted requests. Link a repeat to its original rather than erasing its history. A customer who cannot accept the offered appointment may still have submitted a valid lead. Record a fulfilled order separately from a later cancellation; an accepted enquiry must not silently disappear when the sale fails.

The evidence is the saved same-day promise and an authorised note showing that the proposed appointment was unavailable. Do not infer the reason from a falling conversion graph. If a customer declined for another reason, keep that distinction. Correct the promise and appointment discussion, then use the handoff worksheet to verify that the assigned employee sees the actual request.

Stop the affected route if a promise cannot be fulfilled or a valid form is lost. After correction, repeat the same route on desktop and mobile, including the end-of-shift handoff. Continue a limited pilot only when the promise, receipt and ownership checks pass and the team can deliver the offered appointments. Keep open orders pending until the agreed observation cutoff; a successful technical test is not proof of sales growth.

Worked example 2: the buyer requests a quote and receives another pitch

A fictional office equipment supplier in Yekaterinburg attracts requests for a small-office package. The ad and page offer a quote based on workstation count. The form stores a telephone number and the number of workstations, but the representative receives a notification without that context and starts selling one device. Delivery technically succeeds; the handover of the customer’s task fails.

Representative notification template: “Package quotation request; ID; workstation count; selected category; landing version; preferred contact; owner; next action”. First reply template: “You requested equipment for the stated number of workstations. Let us clarify the configuration and constraints, then agree when to send the quote”. Mark information the customer did not supply as unknown instead of guessing.

Test two valid requests with different categories and one repeated submission. The representative should see the original task, open the correct record and assign a next step. Link the repeat to the earlier enquiry under company rules. The CRM owner chooses how to transfer fields; no specific connector is assumed. Test assignment changes separately from page-copy changes.

Keep a separate educational record for a repeated quotation request, an unavailable product, an unanswered contact and an accepted package enquiry. An accepted request can later be lost or cancelled without becoming an invalid lead. Preserve the original qualification decision and append the commercial outcome. Review the first reply before attributing a lost order to missing context; other reasons must remain distinguishable.

The manager first compares form text, record contents and the initial proposal. If workstation count is present in the CRM but ignored, the fault is in handling. If it is missing from the stored enquiry itself, the form owner must investigate. That distinction determines the repair: training and ownership, or restoring field transfer.

Stop the affected route when the employee cannot see the required context or no owner accepts the handoff. Retest different categories, a repeat request and the backup assignment after correction. Continue only when the employee can describe the original task and record the promised next step. Expand the pilot only with capacity to prepare proposals and no unresolved delivery defects; keep a proposal distinct from a completed order.

For a separate affiliate offer, sign in to the AffiliateCore advertiser account and use the verified description and URL in your offer draft, if creation is available to your account. Put acceptance conditions in a working brief first. CRM, Direct and response times remain your operational responsibility. These illustrative orders are not presented as automatically supported payable platform events.

Copyable CRM handoff worksheet

Copy the worksheet below into a restricted working document. Agree the test window with the form owner and sales lead, use authorised test contacts kept outside this worksheet, and label every test. First fill the blank contract; then run each fixture and attach a redacted receipt or record reference. Use a test environment where available. A failed-delivery fixture must be simulated there or reviewed from an existing authorised incident; do not break a live integration to manufacture evidence. Test enquiries must not become payable conversions or train a commercial optimisation goal. The worksheet is an editorial document, not an AffiliateCore integration.

Download the worksheet as a text file

CRM HANDOFF — WORKING COPY
Scope: Russia / Yandex Direct; language does not establish availability.
No names, contact details, credentials or conversation transcripts here.

BLANK HANDOFF CONTRACT
Journey / service / landing version: ____
Ad promise / permitted exceptions: ____
Test environment / authorised test window: ____
Audit reference / received time and time zone: ____
Submission receipt / CRM record reference: ____
Required context / observed values: ____
Owner / backup owner / next action / due time: ____
Qualification rule and version: ____
Decision: accepted / rejected / duplicate / unknown: ____
Reason / evidence reference / reviewer / decision time: ____
Duplicate rule / original record reference: ____
Order outcome: open / lost / fulfilled / cancelled: ____
Outcome evidence / observation cutoff: ____
Unknowns / person responsible for checking: ____
Defect / correction version / retest evidence: ____
Decision: pass / fail / stop; decision owner: ____

FILLED EDUCATIONAL EXAMPLE — INVENTED, NOT CLIENT RESULTS
Journey: office equipment package; landing version B.
Reference: TEST-B; time: agreed test window, Europe/Moscow.
Promise: discuss a complete workstation package.
Required context: package category; preferred reply channel.
Receipt: TEST-RECEIPT-B; CRM reference: TEST-CRM-B.
Observed: category saved, but absent from the staff notification.
Owner: sales test lead; backup: shift lead.
Decision: accepted test enquiry; not a sale.
Reason: requested service is offered; receipt is confirmed.
Next action: open the full record and confirm the requested package.
Outcome: open; no fulfilment or cancellation evidence.
Unknown: whether other notification routes lose the category.
Defect owner: CRM administrator; correction: notification version C.
Retest: category visible to the assigned employee in the new version.
Decision: fail before correction; pass only after evidenced retest.

TEST FIXTURES — EXPECTED RESULTS
VALID: submit an authorised enquiry for an offered service.
Expect receipt, linked CRM record, context, owner and next action.
INVALID: omit a required field.
Expect visible validation; no accepted business enquiry.
REPEAT: repeat the same authorised request.
Expect a documented link to the original, no second accepted result.
DIFFERENT TASK: same test contact, different legitimate request.
Expect review under the duplicate rule, not automatic deletion.
REJECTED: request a service outside the stated offer.
Expect a reason tied to the offer version; preserve receipt evidence.
UNREACHABLE: review an authorised no-response fixture.
Expect unknown/contact not established, not invented fraud.
SHIFT END: test the agreed backup handoff.
Expect a named role, due time and acknowledgement.
DELIVERY FAILURE: simulate safely in a test environment.
Expect no false success; recoverable evidence and an assigned owner.

ACCEPTANCE CHECKLIST
[ ] Promise matches what the business can provide.
[ ] Receipt is proven separately from an analytics event.
[ ] Context, owner and next action survive handoff.
[ ] Duplicate and rejection decisions have reasons and evidence.
[ ] Unknown and open outcomes remain visible.
[ ] Tests are excluded from commercial results.
[ ] Retest evidence matches the corrected version.
PASS: every applicable fixture matches its expected result.
FAIL: record a mismatch and assign its correction; do not scale.
STOP: lost valid enquiry, false promise or missing owner; pause the affected route.
RESTART: correction, repeat test and sales-owner sign-off are recorded.

Document the correction and permission for another pilot

Defect card: transition; expected action; actual result; evidence; known impact; unknowns; correction owner; changed version; repeat test; traffic reopening decision. For example: “Landing page to handling: availability confirmation is promised, but the representative promises a visit without checking; revise the conversation script and verify three authorised test enquiries”. Choose test volume for risk and route diversity, not for a more impressive report.

Do not simultaneously replace audience, price, form and sales team if you want to understand the result. Correct the evidenced defect first, then run a comparable limited pilot. A before-and-after comparison alone does not establish causality: demand, seasonality and available capacity can change. Separate a reproducibly fixed defect from an increase in sales that is not yet causally established.

Your exercise: pick one journey and trace ten anonymised enquiries from promise to outcome, including refusals and cancellations. Complete the template, reproduce one defect, appoint an owner and cap the retest. Before continuing, check promise consistency, form receipt, record context, ownership, next action, mature outcomes, cancellations and evidence for each decision. Where evidence is missing, a precise unknown and a way to investigate it are useful audit outputs.

For adjacent tasks, see source analysis in Metrica, statistics reconciliation and reliable CRM delivery. This audit produces a different final document: an evidenced break in one journey and verifiable conditions for restarting it.