Yandex Metrica: confirmed CRM leads as offline conversions
Prepare CRM events for Yandex Metrica, check matching and cancellations, and evaluate two worked pilots with complete costs and clear stop conditions.
A CRM can show a completed sale while website analytics still shows only a submitted form. Uploading an offline event can connect those observations, but it does not turn every uploaded row into a matched visit, a profitable customer or an approved partner payment. The useful outcome is a traceable record: what happened, when it happened, which customer identifier accompanied it, and how the business decision was made.
This guide addresses advertisers working with Russian-market campaigns. Translations do not change that geography or establish availability elsewhere. Official documentation was checked on 22 October 2026. The workflow, worksheets, thresholds and two examples are our editorial method. All example amounts are independent assumptions in USD, not converted Russian prices, vendor fees or customer results.
1. Agree what a confirmed lead means
Start with one product, landing page and acquisition period. Ask sales to describe an accepted result in ordinary language. A phone number that rings is not necessarily a qualified request; a signed proposal is not necessarily a paid engagement. Write one sentence identifying the evidence required, its owner and the point at which the record becomes eligible for export. Keep the original form submission as a separate event.
For the service example below, the final result is a paid, completed visit after the agreed review period. For the B2B example, qualification is an intermediate milestone and paid delivery is the commercial result. An intermediate signal may help analysis, but its name must not imply collected revenue. Do not combine these stages into one target merely because a dashboard looks cleaner.
Use an internal event worksheet: record key; business stage; evidence reference; event time and timezone; identifier type; identifier value; target; optional value and currency; cancellation state; export batch; reviewer. This worksheet is your operational document, not the Metrica upload schema. Keep internal notes and evidence references out of the upload unless the documented destination actually requires them.
For a partner programme, AffiliateCore can be the place to prepare the offer and agreed acceptance terms. Metrica remains the external analytics tool in this workflow. We do not claim an automatic AffiliateCore-to-Metrica connector, matching guarantee or financial approval based on a Metrica goal. Prepare an advertiser profile once you have a clear event definition and product description; actual product and source eligibility still require checking.
2. Build a small, inspectable export
The accountable owner needs authorised access to the relevant counter, the selected CRM records and the website implementation. Check what the account actually permits before assigning work. Keep credentials outside spreadsheets and article examples. Choose a separate test environment where available; otherwise use documented real business events for a limited observational pilot, without manufacturing paid conversions or feeding artificial sales into bidding.
The official API guide requires a matching identifier plus Target and DateTime; Price and Currency are optional. Adopt its exact schema for the chosen route. Our worksheet is deliberately broader. Do not paste internal columns into an upload or assume the differently capitalised identifiers appearing across help pages are interchangeable in every integration.
Select one identifier route for the first batch. Preserve the identifier actually captured during the relevant customer journey as text, including its full value. A CRM record number is not automatically an analytics visitor identifier. Ask the developer to demonstrate the capture and storage path on a permitted test record. A missing identifier belongs in an exception list; borrowing one from another lead corrupts attribution.
Prepare a mapping card with three lines: CRM evidence → named business event; event → exact goal identifier; captured identifier → documented upload column. Add the counter reference and responsible reviewer. Compare the card with the real account rather than relying on a screenshot from another organisation. The interface instructions describe goal creation and offline-data upload. Use those current instructions instead of an invented button sequence.
Time deserves its own check. Record the actual business event, not the export time or the day the analyst opened the card. Convert from an explicitly known timezone and independently reconstruct one sample back into a readable date. Spreadsheet rounding, millisecond values and ambiguous local dates can all produce plausible-looking but incorrect data. Keep identifiers as text and use a proper CSV exporter rather than concatenating cells by hand.
The offline-data overview specifies a 21-day visit-enrichment period. Plan frequent delivery and inspect visit, event and processing dates. This is not a promise that any sale submitted within 21 days of closing will match. Long negotiations need a separate design; never change their timestamps to make them appear recent.
A practical file skeleton
For the API route, start with the header below. Replace every placeholder with a verified value; this skeleton must not be uploaded. The first scenario can use an agreed target named crm_service_net, the second a separate crm_qualified target. These are suggested identifiers you configure, not existing goals. Keep internal record keys outside this minimal file. Omit value fields for qualification rather than inventing revenue. Have a second person compare the completed file with the mapping card before submission.
ClientId,Target,DateTime
ClientId = <captured_identifier>Target = <configured_target>DateTime = <verified_unix_seconds>
3. Separate delivery, matching and business acceptance
Before submitting anything, count eligible records, excluded records and unique internal event keys. Assign a batch reference and retain an immutable copy of what was sent in restricted storage. Our recommended key combines the business record with the event stage; it prevents your own exporter from sending the same milestone repeatedly. It is not a claim about a server-side deduplication guarantee.
After submission, preserve the response and inspect processing before retrying. A timeout leaves an unknown outcome, not proof of rejection. Reconcile the batch first. Keep transport failures, unmatched identifiers and business cancellations in different lists because their remedies differ. Technical retries should not generate a new apparent purchase or silently move an event to another date.
There is an important current caveat: Yandex warns that report matching statuses may be inaccurate and directs users to the Data upload settings for the current matching share. Check this warning in the current help. Do not diagnose individual failures solely from a potentially affected report. Preserve the inconsistency and seek clarification when the available evidence is insufficient.
The offline-conversions report documents matching diagnostics. Use it alongside batch evidence, respecting that caveat. Your reconciliation should separately show CRM-confirmed results, submitted events, processed events and matched results. Never subtract unmatched sales from actual revenue merely because analytics cannot attribute them. Conversely, an attributed event does not overrule a later cancellation in the business ledger.
For reversals, the safe default in this guide is to correct the internal commercial ledger and stop treating the original event as current net revenue. Do not assume another ordinary offline-conversion row will delete or update it. If a project requires order-status changes, assess the separately documented CRM order-import route. Confirm its identifiers, update behaviour and limitations before adopting it; this article is not a ready-made integration for that route.
4. Worked pilot: completed equipment-service visits
This fictional advertiser offers a permitted equipment-maintenance service. The pilot covers one service area, one landing page and one completed cohort. The material pack contains the service description, a qualification script, an event mapping card, the restricted export worksheet and a cancellation ledger. The script asks what equipment needs attention, whether the location is covered and whether the customer accepts the stated scope. It makes no promise that every enquiry will become a booking.
A sample internal card reads: S-017; service completed; receipt checked by operations; event time recorded with timezone; captured visitor identifier present; final-service goal; cancellation review complete. It is a worksheet example, not a file to upload. The reviewer rejects an incomplete card before export and records the reason. The developer verifies one eligible journey end to end, then the analyst releases the remaining eligible batch.
The cohort contains 100 enquiries. Twenty are rejected before booking, 80 are accepted for scheduling, 60 become paid completed visits, and six of those are cancelled or refunded before final selection. Therefore 54 net results remain. The other 20 accepted enquiries did not become paid visits within the observation period and are reported separately. The final batch has 54 eligible events; assume 48 match and six remain unmatched after investigation.
The pilot budget includes USD 1,200 media, USD 200 landing-page and creative work, USD 180 identifier implementation, USD 120 export and review labour, USD 100 CRM allocation and USD 200 sales handling: USD 2,000 total. The model includes all assigned acquisition and measurement costs. Fulfilment costs are accounted for in the contribution per completed service, so they must not be deducted a second time. Taxes and fixed overhead are outside this planning contribution model; obtain the business's actual accounting basis before using it for profit reporting.
Assume each net service produces USD 180 revenue and USD 60 contribution after variable fulfilment costs. Revenue is 54 × 180 = USD 9,720; contribution is 54 × 60 = USD 3,240. After the USD 2,000 pilot cost, the planning surplus is USD 1,240. Fully loaded cost per net result is 2,000 ÷ 54 = USD 37.04. Break-even requires at least 34 net services because 2,000 ÷ 60 = 33.33, rounded up.
Cancellations are 6 ÷ 60 = 10%; matching coverage is 48 ÷ 54 = 88.89%. These fractions have different denominators and answer different questions. The commercial conclusion uses all 54 verified results; source-level conclusions must acknowledge the six unattributed results. Do not claim that fixing matching itself created six new customers or USD 1,080 of incremental revenue.
Our pre-agreed stop rules are any incorrect customer association, any unexplained repeat export, a cancellation rate above 15%, or projected cost above USD 60 per net result. Positive commercial contribution does not cancel a data-integrity stop. Here coverage below the pilot's 90% target pauses scaling while the identifier gaps are investigated. After two comparable clean cohorts meet the rules, test a small budget increase and review again; do not extrapolate the same unit economics indefinitely.
5. Worked pilot: a longer B2B implementation sale
The second fictional advertiser sells a lawful equipment-setup service to businesses. Its material pack includes a requirements brief, a qualification rubric, a proposal version, a stage-history sheet and a cancellation log. The qualification rubric requires a relevant need, a reachable decision contact and a realistic delivery scope. These are the advertiser's chosen criteria, not a Yandex definition of a quality lead.
From 60 enquiries, 12 are rejected and 48 qualify. Thirty receive proposals. Twelve become paid engagements within the observed cohort and two are cancelled, leaving ten net engagements. The remaining 18 proposals are still open or lost and must retain their actual states. Do not describe the 48 qualifications as 48 sales. Record an intermediate event and the eventual commercial outcome in separate ledger columns.
The pilot sends eligible qualification events promptly and keeps later sales in the CRM ledger. Some negotiations extend beyond the visit-enrichment window. For those, do not backdate a sale or manufacture a new visit. Investigate the separate CRM order workflow if it meets the real project requirements; otherwise accept that final-sale attribution is incomplete. For this example, 42 of 48 qualification events match: 87.50% coverage. This is not the matching rate of the ten net sales.
Costs are USD 1,800 media, USD 300 briefing and landing materials, USD 200 identifier and export setup, USD 250 qualification labour, USD 150 CRM allocation and USD 300 proposal work: USD 3,000. Each retained engagement provides USD 1,500 revenue and USD 400 contribution after variable delivery costs. Ten engagements yield USD 15,000 revenue and USD 4,000 contribution, leaving USD 1,000 after pilot costs. Net acquisition cost is USD 300; break-even requires eight engagements because 3,000 ÷ 400 = 7.5.
The cancellation rate is 2 ÷ 12 = 16.67%, above this pilot's independently chosen 15% limit. If two more engagements cancel, eight remain, contribution becomes USD 3,200 and the surplus shrinks to USD 200. At seven retained engagements it becomes a USD 200 deficit. The margin of safety is thin even before fixed overhead. A low cost per qualification cannot justify scaling when downstream delivery is unstable.
Stop expansion and examine cancellation reasons against proposal versions and delivery promises. Keep lawful lead collection only within the already approved budget while correcting scope communication. A new pilot should test one change, such as a clearer implementation checklist, while retaining the same event definitions and observation age. Resume scaling only after mature cohorts pass both the cancellation rule and the commercial threshold; this is a decision framework, not guaranteed future performance.
For the second pilot, the internal card can read B-009; qualification completed; requirements brief reviewed; responsible contact verified; actual event time; captured identifier; crm_qualified; batch reference. A later paid engagement receives its own evidence and stage. Both examples assume that cancellation handling is included in sales or proposal labour, with no additional nonrecoverable fulfilment or transaction charges. If such charges exist, add them before calculating contribution. Restrict access to exported identifiers, define retention and confirm the applicable data-processing basis; an identifier is not automatically anonymous.
6. Hand over a decision, not just an uploaded file
The handover pack should contain the event agreement, mapping card, restricted batch reference, exception counts, commercial worksheet and signed decision. Assign one owner to resolve missing identifiers and another to confirm business reversals. Record what remains unknown. If the current report warning prevents a trustworthy diagnosis, say so explicitly and keep scaling paused rather than replacing uncertainty with an invented explanation.
For an AffiliateCore offer, align the partner acceptance wording with the business event you actually verify. Open your advertiser account to prepare or review the offer through the available workflow. A website goal is supporting measurement; partner acceptance and payment follow the agreed conditions and their own checks.
Your practical task is to audit ten eligible CRM records without uploading them first. Reconstruct their evidence, identifiers, timestamps and cancellation history. Explain every excluded record, calculate cost per net outcome, and write one sentence authorising continuation or stopping the pilot. Only then release a controlled batch. Repeat the same reconciliation after processing and again when the cohort matures.
For background, read our guide to source quality and ad-to-CRM audit. They address source comparison and journey defects; this guide adds the event-export and cancellation-control procedure. Keep those questions separate so a successful upload never becomes a substitute for a verified business result.