Метрика: офлайн-конверсії з CRM та облік скасувань
Як підготувати підтверджені події CRM для Метрики, перевірити прив’язку й скасування: два навчальні пілоти з витратами та умовами зупинки.
У CRM уже є виконане замовлення, а вебаналітика бачить лише надіслану форму. Передавання офлайн-події допомагає поєднати ці спостереження, але саме по собі не перетворює кожен рядок файлу на знайдений візит, прибуткового клієнта чи схвалену партнерську виплату. Потрібен результат, який можна перевірити: яка дія відбулася, хто її підтвердив, коли саме та чому запис потрапив до експорту.
Цей матеріал описує роботу рекламодавця з російським ринком. Український переклад не змінює географію та не підтверджує доступність сервісу в Україні або іншій країні. Першоджерела перевірено 22 жовтня 2026 року. Робочі картки, пороги й обидва приклади — наша редакційна методика. Суми в UAH є незалежними навчальними припущеннями, а не перерахованими російськими цінами, тарифами Яндекса чи результатами клієнтів AffiliateCore.
1. Визначте підтверджений результат
Оберіть один продукт, посадкову сторінку та період залучення. Попросіть керівника продажів описати прийнятний результат звичайними словами. Номер телефону, який працює, ще не означає відповідну заявку; погоджена пропозиція не означає отриману оплату. Запишіть, який документ або факт підтверджує подію, хто перевіряє доказ і коли дозволяє експорт. Початкове надсилання форми залиште окремим етапом, не змішуючи його з рішенням менеджера.
У першому прикладі кінцевий результат — оплачений і виконаний сервісний виїзд після погодженої перевірки скасувань. У другому кваліфікація заявки є проміжною подією, а комерційний результат — оплачена виконана робота. Назва проміжної цілі не має створювати враження отриманого доходу. Не об’єднуйте різні етапи лише тому, що одна лінія на графіку виглядає простіше за кілька.
Підготуйте внутрішню картку події: ключ запису, етап, посилання на доказ, фактичний час із часовим поясом, тип і значення ідентифікатора, ціль, необов’язкові сума й валюта, стан скасування, пакет експорту та перевіряльник. Це ваш робочий документ, а не схема завантаження Метрики. Внутрішні коментарі, документи й контакти клієнта не потрібно автоматично переносити до аналітичного файлу. Для кожного поля має бути зрозуміле призначення.
Для партнерської програми AffiliateCore може бути першим варіантом підготовки власного офера та умов приймання. Метрика в цій схемі залишається зовнішнім інструментом аналітики. Ми не заявляємо автоматичний конектор AffiliateCore → Метрика, гарантовану прив’язку чи підтвердження виплати за досягненням цілі. Підготуйте профіль рекламодавця, коли сформулюєте продукт і прийнятну подію. Допустимість продукту та джерела перевіряється окремо.
2. Зберіть невеликий перевірюваний пакет
Відповідальному потрібні дозволений доступ до вибраного лічильника, потрібних записів CRM і спеціаліста, який підтримує сайт. Спочатку перевірте реальні можливості облікового запису: припущення про права не є підтвердженою назвою ролі. Паролі й токени не потрапляють до таблиць або прикладів. За наявності використовуйте окреме тестове середовище; спостережний робочий пілот спирається на справжні події бізнесу, без оплачуваних фіктивних конверсій.
Документація API вимагає ідентифікатор для прив’язки, Target і DateTime; Price та Currency необов’язкові. Візьміть точну схему вибраного способу передавання. Внутрішня картка навмисно ширша: її не можна цілком надсилати замість документованого файлу. Не припускайте, що різні варіанти написання ідентифікаторів у довідках однаково приймаються кожним інтеграційним маршрутом. Перевірте контракт саме вашого способу передавання.Для першого пакета виберіть один спосіб ідентифікації. Зберігайте реально отримане значення повністю як текст, без округлення. Номер угоди в CRM автоматично не стає ідентифікатором відвідувача аналітики. Попросіть розробника показати ланцюжок отримання та збереження на дозволеному перевірочному записі. Якщо значення немає, заявка переходить до списку винятків. Підстановка ідентифікатора іншого клієнта створює неправдивий зв’язок, навіть якщо покращує показник покриття.
Зробіть картку відповідностей із трьох рядків: доказ CRM → ділова подія; подія → точний ідентифікатор цілі; збережений ідентифікатор → поле документованої схеми. Додайте лічильник і відповідального. Зіставляйте картку з фактичним обліковим записом, а не чужим знімком екрана. Інструкція вебінтерфейсу описує створення цілі та завантаження офлайн-даних. Послідовність дій беріть звідти, не вигадуючи кнопок.
Час перевірте окремо. Подія датується фактичною підтвердженою дією, а не запуском експорту чи відкриттям картки аналітиком. Початковий часовий пояс має бути відомим. Після перетворення відновіть одну дату назад і порівняйте з CRM. Мілісекунди замість секунд, неоднозначний формат дати та округлення дають правдоподібні помилки. Створюйте CSV відповідним експортером, а не ручним склеюванням клітинок. Особливо уважно перевірте дані на межі календарних діб.
Огляд імпорту встановлює період доповнення візитів 21 день. Плануйте регулярне передавання та перевіряйте дати візиту, події й оброблення. Це не обіцянка прив’язати будь-який продаж протягом 21 дня після закриття угоди. Для тривалих переговорів потрібне окреме рішення; змінювати час старої події на сьогоднішній не можна. Правильна дата важливіша за штучно красиве покриття.Перед першим пакетом перевірте походження значень, а не лише заповненість полів. Однаковий ідентифікатор у всіх заявках може бути константою з тестової форми. Поле часу підтвердження іноді містить час створення ліда. Такий дефект змінює зміст усієї партії. Спочатку виправляється механізм формування даних, потім перевіряються нові приклади; ручне підлаштування рядків заради успішного контролю проблему не усуває.
Практичний каркас файлу
Для маршруту API почніть із заголовка нижче. Кожен заповнювач замінюється перевіреним значенням; цей каркас завантажувати не можна. У першому сценарії можна погодити ціль crm_service_net, у другому — окрему crm_qualified. Це запропоновані ідентифікатори для налаштування, а не наявні цілі. Внутрішній ключ запису до мінімального файлу не переноситься. Для кваліфікації пропустіть вартісні поля замість вигаданого доходу. Перед надсиланням другий працівник звіряє готовий файл із карткою відповідностей.
ClientId,Target,DateTime
ClientId = <captured_identifier>Target = <configured_target>DateTime = <verified_unix_seconds>
3. Розділіть доставлення, прив’язку та приймання
До надсилання порахуйте відповідні записи, винятки й унікальні внутрішні ключі подій. Призначте пакету номер і збережіть незмінну копію з обмеженим доступом. Запропонований внутрішній ключ поєднує бізнес-запис і етап: він захищає ваш експортер від повторного надсилання одного підтвердження. Це редакційна рекомендація, а не обіцянка автоматичного усунення дублів на стороні Метрики. Дві справжні різні події потрібно відрізняти від повтору одного запису.
Після надсилання збережіть відповідь і з’ясуйте стан оброблення до повторної спроби. Тайм-аут означає невідомий результат, а не доведену відмову. Спочатку звіряють уже надісланий пакет. Окремо ведіть помилки передавання, неприв’язані події та комерційні скасування: причини й подальші дії різні. Технічний повтор не має створювати нову покупку чи непомітно змінювати дату бізнес-події.
На дату перевірки є суттєве попередження Яндекса: статуси прив’язки у звітах можуть бути неправильними, актуальну частку слід дивитися в налаштуваннях завантаження даних. Воно міститься в поточній довідці. Не робіть остаточний висновок щодо кожного рядка лише за потенційно зачепленим звітом. За суперечності збережіть спостереження та отримайте уточнення, не призначаючи причину навмання.
Звіт про офлайн-конверсії документує діагностику прив’язки. Використовуйте її разом із доказами пакета та зазначеним обмеженням. У вашій звірці окремо мають стояти: підтверджено в CRM, передано, оброблено й прив’язано. Неприв’язане замовлення не зникає зі справжнього доходу. Прив’язана подія, своєю чергою, не скасовує пізніше повернення в комерційному обліку.Для скасувань безпечна межа цього посібника — виправити внутрішній комерційний реєстр і не вважати початкову подію актуальним чистим доходом. Не припускайте, що новий рядок звичайної офлайн-конверсії видалить попередній. Якщо потрібні зміни станів замовлень, вивчіть окремий документований маршрут імпорту замовлень CRM. Його ідентифікатори, умови й поведінку оновлення перевіряють до впровадження; готової інтеграції цього маршруту тут не обіцяємо.
4. Навчальний пілот: обслуговування обладнання
Умовний рекламодавець надає допустиму послугу обслуговування обладнання. Пілот обмежений територією, посадковою та завершеною когортою. Комплект матеріалів містить опис послуги, сценарій кваліфікації, картку відповідностей, таблицю експорту та реєстр скасувань. Менеджер уточнює обладнання, адресу в зоні обслуговування й погодження обсягу робіт. У тексті немає обіцянки, що кожне звернення обов’язково стане замовленням. Непридатні заявки отримують конкретну причину відмови.
Навчальна картка: S-017; послугу виконано; чек перевірив відповідальний; час записано з часовим поясом; збережений ідентифікатор присутній; ціль кінцевої послуги; перевірку скасувань завершено. Це внутрішній матеріал, не рядок для завантаження. Неповну картку повертають із причиною. Розробник простежує один дозволений шлях, після чого аналітик випускає інші відповідні події невеликим пакетом. Так команда спочатку перевіряє метод, а не масово розмножує помилку.
У когорті 100 звернень: 20 відхилено до запису, 80 прийнято для планування, 60 дійшли до оплаченого виконаного виїзду. Із цих 60 шість скасовано або повернено до остаточного відбору. Залишається 54 чистих результати. Ще 20 прийнятих звернень не стали оплаченими виїздами в періоді спостереження й обліковуються окремо. Фінальний пакет містить 54 події; умовно 48 прив’язано, шість після перевірки залишаються без атрибуції.
Витрати: реклама 48000 UAH, посадкова й матеріали 8000 UAH, налаштування ідентифікатора 7200 UAH, експорт і перевірка 4800 UAH, частка CRM 4000 UAH, оброблення звернень 8000 UAH. Разом 80000 UAH. Це всі призначені витрати залучення та вимірювання в моделі. Змінні витрати виконання послуги вже враховані у внеску, повторно віднімати їх не слід. Податки та постійні загальногосподарські витрати не моделюються; залишок не є чистим бухгалтерським прибутком.
Нехай чисте замовлення дає 7200 UAH доходу й 2400 UAH внеску після змінних витрат виконання. Дохід: 54 × 7200 = 388800 UAH. Внесок: 54 × 2400 = 129600 UAH. Після витрат пілота залишається 49600 UAH. Повна вартість чистого результату: 80000 ÷ 54 = 1481,48 UAH. Беззбитковість потребує щонайменше 34 замовлення: 80000 ÷ 2400 = 33,33 з округленням угору.
Частка скасувань дорівнює 6 ÷ 60 = 10%, покриття прив’язкою — 48 ÷ 54 = 88,89%. Різні знаменники відповідають різним запитанням. Економічний висновок використовує всі 54 підтверджені результати; порівняння джерел враховує шість неприв’язаних. Виправлення ідентифікатора не створює шість нових покупців. Не розподіляйте невідомі продажі пропорційно рекламним витратам без доказів: це може приховати проблему саме на найціннішому джерелі.
До тесту визначено стоп-умови: неправильний зв’язок із клієнтом, непояснений повтор, скасування понад 15% або прогноз вартості чистого замовлення понад 2400 UAH. Позитивний внесок не скасовує зупинку через якість даних. Тут покриття нижче обраного порога 90%, тому збільшення бюджету відкладають до розслідування. Після двох зіставних зрілих когорт без порушень дозволений невеликий наступний тест; збереження попередньої економіки не гарантоване.
5. Навчальний пілот: тривала B2B-угода
Другий умовний рекламодавець продає налаштування обладнання компаніям. Потрібні бриф вимог, критерії кваліфікації, версія пропозиції, історія етапів і журнал скасувань. Кваліфікація передбачає відповідну задачу, доступного відповідального з боку покупця та реалістичний обсяг впровадження. Це критерії конкретного бізнесу, не офіційне визначення якісної заявки Яндексом. Інший працівник повинен мати змогу перевірити рішення за збереженими доказами, а не лише повірити позначці менеджера.
Із 60 звернень 12 відхилено, 48 кваліфіковано. Тридцять отримали пропозиції. Дванадцять стали оплаченими проєктами, два скасовано, залишилося десять чистих результатів. Решта 18 пропозицій відкриті або програні та зберігають справжні стани. Не можна назвати 48 кваліфікацій продажами. Проміжний етап і кінцевий комерційний результат записуються окремо, навіть якщо менеджеру зручніше показувати одне число успіху замість кількох.
Відповідні події кваліфікації передаються своєчасно, пізні продажі залишаються в комерційному реєстрі CRM. Частина переговорів виходить за вікно доповнення візитів. Для них не підмінюють час продажу та не створюють штучний новий візит. Окремий маршрут замовлень досліджують, якщо він відповідає задачі; інакше визнають неповну атрибуцію фінального результату. У прикладі прив’язано 42 із 48 кваліфікацій: 87,50%. Це не частка прив’язки десяти чистих продажів.
Бюджет: реклама 72000 UAH, бриф і посадкова 12000 UAH, налаштування ідентифікаторів та експорту 8000 UAH, кваліфікація 10000 UAH, частка CRM 6000 UAH, підготовка пропозицій 12000 UAH. Разом 120000 UAH. Чистий проєкт дає 60000 UAH доходу та 16000 UAH внеску після змінних витрат. Десять проєктів дають 600000 UAH доходу, 160000 UAH внеску й 40000 UAH після пілота. Вартість результату 12000 UAH; беззбитковість потребує восьми проєктів, адже 120000 ÷ 16000 = 7,5.
Скасування: 2 ÷ 12 = 16,67%, вище заздалегідь вибраної межі 15%. Якщо скасуються ще два проєкти, залишиться вісім, внесок складе 128000 UAH, залишок після пілота — лише 8000 UAH. За семи проєктів виникне дефіцит 8000 UAH. Запас невеликий навіть без постійних витрат. Низька ціна кваліфікованого звернення не виправдовує збільшення реклами, коли виконання проєктів нестабільне й кінцеві результати продовжують скасовуватися.
Зупиніть розширення та зіставте причини скасувань із версіями пропозицій і обіцянками обсягу. Допустимий збір звернень може тривати лише в межах уже затвердженого бюджету, поки виправляється опис послуги. Наступний пілот змінює один елемент, наприклад зрозуміліший список перевірки впровадження, але зберігає визначення подій і вік спостереження. До масштабування повертаються після зрілих когорт, які пройшли економічний поріг і правило скасувань.
Для другого пілота внутрішня картка може містити: B-009; кваліфікацію завершено; бриф перевірено; відповідальний контакт підтверджено; фактичний час; збережений ідентифікатор; crm_qualified; номер пакета. Пізня оплачена робота отримує власні доказ і етап. В обох прикладах робота зі скасуваннями входить до оброблення звернень або пропозицій; додаткових невідшкодовуваних витрат виконання та платіжних комісій умовно немає. Якщо вони є, додайте їх до розрахунку внеску. Обмежте доступ до ідентифікаторів, визначте зберігання й підставу оброблення: ідентифікатор не є автоматично анонімним.
6. Передайте рішення разом із доказами
Підсумковий комплект: погоджене визначення події, карта полів, посилання на пакет з обмеженим доступом, числа винятків, розрахунок і зафіксоване рішення. Призначте відповідального за втрачені ідентифікатори та відповідального за комерційні скасування. Окремо вкажіть невідоме. Якщо попередження щодо статусів заважає надійній діагностиці, так і напишіть; відсутність доказів не замінюють упевненою версією про поганий трафік або неправильну роботу менеджера.
Для офера AffiliateCore погодьте формулювання приймання з подією, яку реально перевіряєте. Відкрийте кабінет рекламодавця, щоб підготувати чи перевірити пропозицію через доступний процес. Ціль сайту допомагає вимірюванню; партнерське приймання й розрахунки підпорядковані погодженим умовам та власним перевіркам. Автоматичне фінансове підтвердження через Метрику в цій схемі не передбачається.
Практичне завдання: до завантаження розберіть десять відповідних карток CRM. Відновіть докази, ідентифікатори, час і історію скасувань. Поясніть кожен виняток, розрахуйте вартість чистого результату й одним реченням дозволіть продовження або зупиніть пілот. Лише після цього надсилайте контрольований пакет. Повторіть звірку після оброблення та після дозрівання когорти: ці перевірки відповідають на різні запитання й не замінюють одна одну.
Додатково прочитайте матеріал про якість джерел і аудит шляху Директ → CRM. Вони присвячені порівнянню джерел і дефектам воронки. Тут результат — контрольоване передавання подій з окремим обліком скасувань, а не ще один загальний огляд звітів. Технічно успішне завантаження не повинно підміняти підтверджений результат бізнесу.