Яндекс Метрика: які джерела в Росії приводять заявки, що доходять до продажу

Кількість надсилань форми показує активність, але не відповідає на запитання, які джерела приводять заявки, що доходять до продажу. Для цього потрібно пов’язати звернення з результатами CRM, дати їм однаковий час на опрацювання й окремо порахувати втрати зіставлення. Інакше перевагу отримає джерело зі швидшими угодами або повнішими даними, а не обов’язково з кращими заявками.

Це практична інструкція середнього рівня для рекламодавця, який аналізує власний продукт на ринку Росії. Російська Федерація — географія завдання в усіх мовних версіях; російська мова інтерфейсу чи звернення не підтверджує місцеперебування клієнта. Перед аналізом перевірте допустимість конкретного продукту, території, каналу й обробки даних. Наявність країни в переліку вибору або пропозицій на платформі не підтверджує доступність пропозиції для вас.

Результат роботи — відтворювана відомість якості джерел: склад заявок, частка зіставлення, кваліфікація, підтверджений продаж і рішення з визначеним відповідальним. Офіційні сторінки перевірено 10 жовтня 2026 року. Приватний лічильник Метрики та CRM клієнта не відкривалися; обидві таблиці нижче навчальні, а не знімки екрана. Методика відомості — редакційна рекомендація, а не вбудований звіт AffiliateCore і не обіцянка готової інтеграції.

1. Визначте, яке рішення має підтримати звіт

Почніть з одного запитання: «Які джерела дають більше підтверджених продажів на зіставну заявку після однакового строку спостереження?» Виберіть один продукт і одну форму звернення, наприклад запит на демонстрацію робочого сервісу. Не змішуйте запит на консультацію з прямою купівлею: це різні наміри й процеси опрацювання. Для кількох продуктів підготуйте окремі розбори, перш ніж об’єднувати результати.

Зафіксуйте, що вважається заявкою: унікальне прийняте звернення зі сталим внутрішнім ідентифікатором. Винятки — погоджені тести та доведені дублікати. Невідповідна заявка, відмова й відсутність відповіді залишаються у вихідній сукупності, інакше джерело з великою кількістю проблемних звернень штучно покращить показники. Причини виключення мають бути однаковими для всіх джерел і зберігатися окремо.

Призначте відповідального за визначення з боку продажів і відповідального за звіряння з боку аналітики. Якщо команди досі сперечаються щодо статусів, спочатку скористайтеся інструкцією з перевірки заявок. Тут ми не перебудовуємо чергу перевірки: беремо погоджені результати й з’ясовуємо, наскільки коректно їх можна порівняти за джерелами.

2. Підготуйте доступ і перевірте придатність даних

Потрібні дозволений доступ до потрібного лічильника, знеособлене вивантаження CRM, історія зміни статусів і працівник, який знає чинний спосіб зіставлення. Запишіть домен, номер лічильника у внутрішній робочій нотатці, часовий пояс, дату вивантаження та відповідальних. Не копіюйте контактні дані, тексти листування та секретні дані доступу до публічної таблиці чи партнерського звіту.

До аналізу підтвердьте, що вибраний сервіс і спосіб використання доступні вашій організації для її продукту й території. Окремо перевірте права на перегляд звітів і погоджений порядок роботи з даними. Цю перевірку не замінює успішний вхід до кабінету. Якщо дозволеного зв’язку CRM з аналітикою немає, починайте з відомості CRM і позначте прогалину; точний рейтинг джерел Метрики поки що недоступний.

Передавання та прив’язування CRM-даних мають технічні умови; їх слід перевірити у відповідального за інтеграцію за офіційним описом. Не плутайте строки технічної прив’язки з вибраним вами строком оцінювання якості. Тривалий цикл продажу не означає, що первинне передавання даних можна відкласти до завершення угоди.

Для підготовки умов власної пропозиції можна створити профіль рекламодавця AffiliateCore. Реєстрація не підключає Метрику й не підтверджує допуск продукту, джерела чи географії; підготовлена пропозиція проходить передбачений розгляд і модерацію.

3. Розділіть ціль, заявку та продаж

Досягнення цілі, цільові візити й унікальні заявки — різні одиниці. За один візит ціль може досягатися кілька разів: це прямо відображено у визначеннях Метрики. Тому сто спрацювань цілі не можна автоматично записати як сто потенційних клієнтів. Потрібно перевірити фактичну умову цілі та прийняття звернення.

На дозволеному тесті перевірте, що саме фіксується: натискання кнопки, успішна відповідь форми чи інший крок. Для аналітичної відомості продаж має підтверджуватися заздалегідь вибраною подією CRM, наприклад оплатою, яка залишається чинною на контрольний момент. Домовленість про зустріч і виставлений рахунок не стають продажем лише тому, що працівник назвав етап «успішним».

Навчальна таблиця 1. Словник відомості; це не інтерфейс Метрики.

Опишіть критерії кваліфікації через ознаки, які можна спостерігати: чи відповідає запит продукту, чи підтверджено завдання, чи може команда його виконати. Не підміняйте якість суб’єктивним враженням менеджера. Досягнення етапу в минулому й поточний статус зберігайте окремо: звернення могло пройти кваліфікацію, а потім завершитися відмовою. Тому суми всіх «будь-коли досягнутих» етапів не обов’язково дорівнюють кількості заявок.

4. Зафіксуйте налаштування звіту Метрики

Відкрийте потрібний лічильник і звіт «Джерела замовлень із CRM» у розділі «Наскрізна аналітика», якщо передавання налаштоване. Його умови та визначення наведено в документації звіту. Якщо розділ не показує очікуваних даних, перевірте доступ, лічильник і стан передавання; порожній звіт не доводить відсутності продажів. У російськомовній довідці цей шлях має назву «Сквозная аналитика → Источники заказов из CRM»; українські назви вище є пояснювальним перекладом.

Запишіть період, групування джерел, фільтри, вибрані метрики й модель атрибуції. Не покладайтеся на попередню назву збереженого звіту. Керування групуваннями та метриками описано в налаштуваннях звітів. Почніть з одного рівня джерела, а деталізацію додавайте після перевірки загальних підсумків: поділ одразу за багатьма ознаками приховує невеликі групи й ускладнює звіряння.

Особливо важливо заново перевірити атрибуцію: з 20 травня 2026 року частину попередніх моделей вимкнено. Орієнтуйтеся на актуальні моделі, а не на старий знімок екрана. Запишіть точну назву вибраного варіанта. Після зміни моделі порівнюйте два розрахунки як різні представлення одного набору, а не як раптову зміну якості джерела.

У робочій нотатці перепишіть знаменник кожної використаної метрики з її визначення. Не вважайте, що будь-яке слово «конверсія» означає продажі, поділені на заявки. Для нашої зовнішньої відомості знаменник буде задано окремо. Розбіжність із відсотком в інтерфейсі допустима, якщо її пояснює різниця одиниць, періоду або складу даних, а не приховує округлення.

5. Звірте склад, перш ніж рахувати відсотки

Збережіть вихідне знеособлене вивантаження окремо від обробленої версії. Для кожного звернення потрібні внутрішній ключ, дата створення, продукт, країна за погодженою бізнес-ознакою, джерело з описом походження, історія статусів та ознака успішного зіставлення. Якщо надійного джерела немає, залиште «не встановлено». Не розподіляйте невідомі звернення пропорційно відомим: це створить уявну точність.

Спочатку порахуйте всю сукупність CRM, потім тести, дублікати й звернення, що залишилися. Після цього розділіть допустимі рядки на зіставлені та незіставлені. Отримайте рівність: вихідні рядки мінус задокументовані виключення дорівнюють заявкам в аналізі; заявки в аналізі дорівнюють зіставленим плюс незіставленим. Перевіряйте рівність окремо за продуктом і періодом, щоб помилки різних груп не компенсували одна одну.

Не з’єднуйте дві таблиці лише за днем і сумою. Збіг цих значень не доводить, що йдеться про одну заявку. Якщо на одне звернення припадає кілька замовлень, заздалегідь задайте правило: для частки продажів враховуємо не більше одного успішного результату на заявку. Аналіз кількості замовлень і виторгу при цьому залишається окремим завданням. Помилка з’єднання «багато до багатьох» здатна подвоїти угоди без появи жодного нового покупця.

Для перевірки цілей можна використати офіційну інструкцію звіту за ціллю. Але збіг агрегованих підсумків ще не підтверджує коректності кожного зв’язку. Перевірте дозволену знеособлену вибірку пов’язаних записів і кілька виключень; позначте випадки, де походження джерела CRM відрізняється від атрибуції Метрики. Загальні причини розбіжностей розібрано в матеріалі про звіряння звітів.

6. Дайте кожній заявці однаковий час

Когорта — група звернень, створених в одному заданому періоді. Вибирайте строк спостереження за власним розподілом часу до рішення, а не за красивим круглим числом. Подивіться, яка частина результатів з’являється швидко, а яка — пізно. Окремо оцініть затримку передавання статусів: продаж, що вже відбувся, може ще не потрапити до вивантаження. Єдиного придатного строку для всіх продуктів немає.

У нашому навчальному прикладі беремо звернення, створені 1–7 вересня 2026 року, й оцінюємо кожне рівно через 14 діб після створення. Вивантаження робимо після завершення всіх цих вікон та оновлення даних. Для цього потрібна історія подій: остання поточна картка на 21 вересня сама собою не відновить стан на чотирнадцяту добу кожної заявки. Без історії позначте обмеження й не називайте результат строго зіставною когортою.

Час створення, кваліфікації, оплати та скасування приводьте до одного погодженого часового поясу. Зберігайте вихідні часові позначки. Продаж на п’ятнадцяту добу не входить до результату чотирнадцятиденного вікна, але враховується в окремому пізнішому оцінюванні. Це не втрачений продаж і не причина переписувати вихідну дату звернення. Якщо повернення надійшло пізніше, оформте наступну версію результату з новим горизонтом.

Не змішуйте цей розрахунок за датою створення заявки з календарною добіркою візитів в інтерфейсі. Потрібен погоджений зв’язок рядків і дат; однакові дати у двох фільтрах його не гарантують. Сегмент також не перетворює автоматично один набір одиниць на інший. Обмеження перенесення сегментів між звітами зазначено в довідці із сегментації.

7. Порахуйте навчальну когорту й перевірте арифметику

Далі наведено вигадані дані, а не результати AffiliateCore, Яндекса чи конкретного каналу. A і B — дві групи з незалежно збереженою в CRM належністю до джерела; серед зіставлених рядків її узгодили з вибраним представленням аналітики. Це необхідна умова, щоб знати розмір групи навіть у разі втрати зв’язку з Метрикою. Якщо такої належності немає, незіставлені рядки залишаються спільною невідомою групою.

Навчальна таблиця 2. Результати на чотирнадцяту добу; одиниця — унікальна заявка.

Кваліфікація, оплата та скасування в цій таблиці стосуються лише зіставлених заявок. Скасування — підмножина раніше оплачених, усі події вкладаються у вибране вікно. Чинні продажі дорівнюють 27 − 3 = 24 для A та 18 − 0 = 18 для B. Етапи перетинаються; додавати рядки таблиці не можна.

Частка зіставлення становить 108 / 120 = 90% і 90 / 100 = 90%. Кваліфіковано 54 / 108 = 50% і 63 / 90 = 70% зіставлених заявок. Частка чинних продажів серед зіставлених — 24 / 108 ≈ 22,2% і 18 / 90 = 20%. У B вища кваліфікація, але це ще не перевага за кінцевим результатом; у A вища спостережувана частка продажів, але сама різниця не доводить стійкої переваги.

Перевіримо третю вигадану групу C без розширення таблиці: 80 заявок, зв’язок є у 40, кваліфіковано 28, оплата була у 12, дві скасовано. Отримуємо 10 чинних продажів, 50% зіставлення, 70% кваліфікації та 25% продажів серед зіставлених. Останнє число виглядає найкращим, однак половина звернень у цій частці не представлена. Не можна оголосити C переможцем або поширити її 25% на невідому половину.

Для наочної перевірки меж тимчасово вважаємо результати незіставлених невідомими. У A загальна частка продажів могла б перебувати від 24 / 120 = 20% до (24 + 12) / 120 = 30%; у C — від 10 / 80 = 12,5% до (10 + 40) / 80 = 62,5%. Це арифметичні крайні сценарії за умови максимум одного продажу на заявку, а не довірчі інтервали й не прогноз. Якщо CRM уже знає результати незіставлених, використовуйте їх для загального результату CRM; обмеження стосується розподілу за перевіреним джерелом Метрики.

8. Ухваліть рішення з урахуванням неповних даних

Починайте з якості вимірювання. За низького або нерівномірного зіставлення спочатку з’ясуйте причину: чи відрізняються форма, спосіб надходження звернення, версія інтеграції або заповнення джерела. Не запроваджуйте універсального порога на кшталт «90% завжди достатньо». Важливі масштаб пропуску та його зв’язок із результатом: навіть невелика систематична прогалина може змінити висновок.

Далі розглядайте кваліфікацію, чинні продажі, очікування й час опрацювання разом. Висока кваліфікація за слабкого кінцевого результату — привід розібрати пізній етап і зіставність критеріїв. Велика частка очікування — привід дочекатися результату або переглянути горизонт. Відмінності в завантаженні менеджерів, наявності продукту та швидкості відповіді можуть пояснювати ефект, помилково приписаний каналу.

Призначте для кожної групи одну дію: виправити вимірювання, дочекатися закриття вікна, перевірити опрацювання або продовжити спостереження до наступної зіставної когорти. Запишіть підставу, відповідального й дату перевірки. Якщо продажі поодинокі, не видавайте відсоток із десятковою точністю за надійний рейтинг. Для причинного висновку потрібен окремий коректно спланований експеримент; цей звіт описує спостережувані зв’язки.

Витрати додавайте лише за повного й сумісного обліку періоду, джерела та складу витрат. Дешеве надсилання форми не дорівнює дешевому підтвердженому продажу, але розрахунок бюджету не виправляє поганого зв’язку даних. Тут рішення насамперед стосується достовірності порівняння, а не налаштування закупівлі трафіку чи призначення ставок.

9. Виправте часті помилки до передавання звіту

Не видаляйте відмови заради покращення якості. Не зараховуйте незавершені звернення до відмов лише тому, що закінчився тиждень. Не переносьте пізні продажі до нових заявок. Не змішуйте повторних клієнтів із первинними без окремої ознаки. Не змінюйте критерій кваліфікації заднім числом лише для одного джерела. Кожна така операція змінює запитання, на яке відповідає відсоток.

Не об’єднуйте однаково названі джерела без перевірки їхнього походження. Поле, заповнене менеджером, мітка переходу й розрахована атрибуція можуть означати різні речі. Збережіть вихідні значення та окремий погоджений довідник відповідностей. Якщо довідник змінився, позначте нову версію й однаково перерахуйте порівнювані періоди, зберігши попередній результат для пояснення змін.

Записи поведінки й теплові карти допомагають шукати труднощі на сторінці; цьому присвячена окрема інструкція з Microsoft Clarity. Технічне передавання офлайн-конверсій також потребує окремого завдання. У цьому матеріалі немає коду завантаження, налаштування рекламних аудиторій або твердження про вбудоване передавання CRM з AffiliateCore.

10. Завершіть роботу відомістю, яку можна перевірити

Перед передаванням рішення перевірте цей список:

• Продукт, Росію як ринок, допустимість каналу та права доступу перевірено окремо.
• Заявку, кваліфікацію й чинний продаж визначено; тести та дублікати пояснено.
• Джерела CRM і Метрики узгоджено або різницю явно позначено.
• Часовий пояс, дати створення, історію статусів і строк спостереження збережено.
• Вихідні рядки сходяться з виключеннями та підсумковою сукупністю.
• Незіставлені заявки та заявки, що очікують рішення, видно поруч із відсотками.
• Модель атрибуції записано за фактичними налаштуваннями, а не взято зі старої інструкції.
• Числа, округлення, обмеження, відповідального й дату наступної перевірки зазначено.

Збережіть версію вивантаження, опис фільтрів і коротку записку: що відомо, що залишається невідомим, яку дію дозволяють дані. Колезі має бути зрозуміло, як повторити розрахунок без доступу до особистого листування клієнтів. Повторюйте його після погодженого строку й порівнюйте однакові за віком групи, позначаючи зміни продукту та опрацювання.

Якщо профіль уже створено, увійдіть до кабінету рекламодавця, щоб підготувати чернетку умов власної пропозиції до розгляду. Актуальні вимоги та модерацію перевірте окремо. Ця відомість допомагає сформулювати критерії якості; вона не гарантує схвалення пропозиції, доступності географії, підключення Метрики чи майбутніх продажів.