Як передача конверсій із CRM у рекламні кабінети допомагає покращити performance-рекламу

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

Під час мітапу «Analytics vs Reality: як синхронізувати рекламу з реальними продажами?» Олександр Конівненко, Head of Data Digital Department в Netpeak, розповів, як передача конверсій із CRM у Google Ads і Meta допомагає покращити якість сигналів і масштабувати performance-рекламу. Це текстова версія його виступу. 

Чому дані в CRM і рекламному кабінеті не збігаються

Рекламний кабінет і CRM часто показують різну кількість конверсій. Різниця іноді сягає 20–40%, і це напряму впливає на аналітику, оптимізацію кампаній і рішення про масштабування бюджету.

Проблема не завжди в неправильному налаштуванні реклами. Частина даних губиться через технічні обмеження браузерів, Consent Mode, складний шлях юзера між пристроями та різницю між «конверсією на сайті» і реальним бізнес-результатом.

Браузери обмежують cookies

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

Цей механізм працює лише тоді, коли cookies збереглися.

Браузери дедалі частіше обмежують збереження файлів кукі. Наприклад, Safari та Firefox уже мають такі обмеження на рівні браузера. В одних випадках cookies можуть не зберігатися взагалі, в інших — зберігаються лише короткий час.

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

Consent Mode зменшує обсяг доступних даних

Якщо користувач не дав згоду на трекінг, бізнес не може повноцінно відстежувати його дії. Відповідно, частина конверсій не потрапляє в рекламну систему або потрапляє не в тому обсязі, який потрібен для коректної оптимізації.

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

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

Користувачі переходять між пристроями

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

Що більше точок контакту, то складніше рекламній системі коректно зібрати весь шлях в одну історію.

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

Через це в рекламній аналітиці з’являється розрив між фактичними бізнес-результатами й тим, що бачить рекламна система.

Не кожна конверсія є бізнес-результатом

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

У lead generation ситуація складніша. На сайті цільовою дією часто є заповнення форми. Після цього з потенційним клієнтом зв’язується sales-менеджер і веде його далі по воронці. Проте не кожне заповнення форми стає кваліфікованим лідом, і лише частина лідів доходить до угоди.

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

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

Як рекламні системи зазвичай зараховують конверсії

Ланцюжок виглядає так:

1. Користувач клікає на рекламне оголошення.

2. Рекламна система передає ідентифікатор кліку на сайт.

3. Трекер на сайті зберігає цей ідентифікатор у cookie браузера.

4. Користувач одразу виконує цільову дію або повертається на сайт пізніше.

5. Коли конверсія відбулася, система перевіряє, чи є в браузері cookie з потрібним ідентифікатором.

6. Якщо cookie є, система зіставляє користувача з рекламною кампанією.

7. Конверсія зараховується цій кампанії.

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

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

У чому проблема стандартного трекінгу

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

Проблема 1. Рекламна система бачить менше конверсій, ніж є насправді

Частина конверсій не потрапляє в рекламний кабінет через технічні обмеження. CRM фіксує заявку, покупку або оплату, а рекламний кабінет не бачить повної картини. Це впливає на ключові рекламні показники:

• CPA може виглядати завищеним, бо система не врахувала частину конверсій;

• ROAS здається заниженим, бо система не отримала всі дані про дохід;

• кампанії можуть здаватися менш ефективними, ніж є насправді;

• маркетологу складніше зрозуміти, які кампанії варто масштабувати.

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

Проблема 2. Рекламна система бачить конверсії, але вони шумні

Конверсії в рекламному кабінеті є, але не всі вони призводять до бізнес-результату.

Показовий приклад: B2B-форма на сайті з широкою аудиторією. Її заповнювали звичайні користувачі, яким послуга не була потрібна. У результаті зі 100 форм на день лише одна ставала кваліфікованим лідом.

Для рекламної системи це 100 сигналів. Для бізнесу — один потенційно цінний лід і 99 шумних дій. 

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

Як передача конверсій із CRM допомагає рекламі

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

1. У CRM або ERP зберігається подія: підтверджене замовлення, кваліфікація ліда, угода чи інший важливий статус.

2. Бізнес формує запит із параметрами, які очікує рекламна система.

3. Дані передаються напряму в рекламний кабінет.

4. Рекламна платформа зіставляє ці параметри зі своїми кампаніями.

5. Якщо користувач взаємодіяв із рекламою, система зараховує конверсію відповідній кампанії.

Такі механізми є в основних рекламних платформах. У Meta це Conversions API, у Google Ads — імпорт offline conversions.

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

Передача більшої кількості даних допоможе, якщо:

• частина продажів відбувається офлайн після онлайн-взаємодії;

• у CRM є більше підтверджених конверсій, ніж у рекламному кабінеті;

• бізнес бачить втрати даних і хоче частково їх компенсувати;

• рекламній системі бракує обсягу сигналів для навчання.

Логіка проста: якщо система бачить більше релевантних конверсій, вона краще розуміє, яких користувачів потрібно приводити.

Передача чистіших конверсій допоможе, якщо:

• багато заявок не проходять кваліфікацію;

• частина замовлень не підтверджується;

• рекламний кабінет оптимізується на дію, далеку від продажу;

• бізнес хоче залучати не більше лідів, а кращих потенційних клієнтів;

• у CRM є статуси, які точніше показують якість користувача.

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

Підходи можна комбінувати: передавати більше конверсій і водночас робити їх якіснішими. Наприклад:

• додати офлайн-конверсії до онлайн-конверсій;

• передавати тільки підтверджені замовлення;

• обрати CRM-статус, який ближчий до продажу;

• тестувати різні типи конверсій окремо;

• створити комбіновану конверсію з кількох етапів воронки.

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

Базовий принцип такий: якщо подій достатньо і вони мають бізнес-сенс, систему можна навчати на них. Якщо логіка складніша — наприклад, комбінування кількох конверсій в одну, — впроваджуйте через тестування.

Як зрозуміти, які конверсії потрібно передавати

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

Наприклад, для lead generation етапи можуть виглядати так:

1. Користувач залишив заявку.

2. Менеджер призначив демозустріч.

3. Лід отримав статус SQL (Sales Qualified Lead).

4. Клієнт підписав договір і здійснив оплату.

Далі потрібно перевірити два параметри для кожного етапу.

1. Кількість подій. Алгоритмам потрібен достатній обсяг даних для навчання. Орієнтир — близько 50 конверсій на місяць. Якщо на етапі лише 10–12 подій, цього може бути замало.

2. Строк настання події. Важливо, через скільки днів після першої заявки або кліку настає потрібний етап. У Meta вікно конверсії коротке — до семи днів. У Google Ads воно може сягати 30 днів.

Оптимальна подія — та, що балансує між якістю і кількістю. Вона має бути ближчою до бізнес-результату, ніж первинна заявка, але водночас відбуватися достатньо часто, щоб рекламна система могла на ній навчатися.

Як оцінити потенціал інтеграції до впровадження

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

Для цього потрібно порівняти два показники:

• кількість конверсій у CRM;

• кількість конверсій у рекламному кабінеті.

Базова логіка розрахунку така:

Далі оцініть знак і розмір цього gap.

Якщо gap плюсовий, рекламна система бачить менше конверсій, ніж є в CRM. Це означає, що частину даних можна спробувати передати в рекламний кабінет і компенсувати втрати.

Якщо gap мінусовий, у рекламному кабінеті може бути більше конверсій, ніж реальних бізнес-результатів у CRM. Це сигнал, що реклама навчається на шумних подіях. У такому випадку варто передавати не більше конверсій, а якісніші: підтверджені замовлення, qualified leads, угоди або оплати.

Такий розрахунок допомагає зрозуміти:

• наскільки відрізняються дані CRM і рекламного кабінету;

• чи проблема в нестачі конверсій, чи в їхній якості;

• який сценарій обрати — передавати більше даних або чистіші сигнали;

• чи є сенс інвестувати в інтеграцію саме зараз.

Якщо рекламні кампанії уже оптимізовані, але масштабування зупинилося, цей аналіз варто зробити в першу чергу.

Які дані потрібно передавати в рекламні системи

Для передачі конверсій у рекламні системи потрібні дані, за якими Google Ads або Meta зможуть ідентифікувати користувача й зіставити його з рекламною взаємодією.

Основні типи даних:

• ідентифікатори кліку — GCLID для Google Ads, FBCLID для Meta;

• first-party дані — email і номер телефону;

• ідентифікатор конверсії — transaction ID для ecommerce або Lead ID для lead generation;

• дані про саму подію — тип конверсії, час, статус, цінність;

• value конверсії — revenue, маржа, середня вартість послуги або прогнозований LTV.

Для Google Ads бажано передавати GCLID, якщо він є. Якщо його немає, можна використовувати email і телефон для зіставлення користувача.

Для Meta логіка схожа: можна передавати FBCLID, хешований email, хешований телефон та додаткові параметри, які допомагають системі краще ідентифікувати користувача.

Щоб об’єднати дані з CRM і аналітики, зручно використовувати спільний ідентифікатор. Для ecommerce це може бути transaction ID, для lead generation — Lead ID. Його варто передавати і в CRM, і в Google Analytics.

У результаті формується dataset із повним набором конверсій. Для частини подій у ньому будуть GCLID або FBCLID, email, телефон і value. Для інших — тільки email, телефон і дані про конверсію. Далі цей dataset можна передавати через API в Google Ads і Meta.

Як працювати з value конверсій

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

Для ecommerce value найчастіше передають як:

• revenue — вартість покупки;

• маржу — якщо вона суттєво відрізняється між товарами.

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

У lead generation value складніше порахувати, тому що на етапі qualified lead бізнес часто ще не знає точну суму майбутньої угоди. У такому випадку можна використовувати наближені значення:

• середню вартість послуги, яка цікавить ліда;

• очікувану цінність угоди за типом послуги;

• внутрішню оцінку якості ліда.

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

Value має допомагати системі відрізняти цінніші конверсії від менш цінних. 

Якщо передане значення не дає такої різниці, воно не покращить навчання алгоритму.

Як побудувати технічну інфраструктуру для передачі конверсій

Для передачі конверсій потрібне середовище, де можна зібрати дані з CRM, аналітики та рекламних систем в один dataset. Підходящим (але не єдиним) варіантом є Google BigQuery. Таке сховище можна побудувати на будь-якому стеку, який уже використовує бізнес.

Далі — базова логіка інфраструктури.

1. Вивантажити дані з CRM

CRM дає інформацію про бізнес-результат: підтверджені замовлення, qualified leads, угоди, оплати, статуси лідів.

З бази насамперед потрібні first-party дані:

• email;

• номер телефону;

• ім’я;

• місто;

• статус конверсії;

• value, якщо він передається.

Email і телефон потрібно одразу хешувати через SHA-256. У такому вигляді ці дані приймають рекламні системи.

2. Додати дані з Google Analytics

З Google Analytics можна вивантажити технічні ідентифікатори, які допоможуть зматчити користувача з рекламною взаємодією:

• client ID;

• transaction ID;

• Lead ID;

• GCLID;

• FBCLID;

• інші вебідентифікатори.

Якщо йдеться про lead generation, краще заздалегідь передавати Lead ID і в CRM, і в Google Analytics. Так дані легше об’єднати.

3. Об’єднати дані в один dataset

Дані з CRM і Google Analytics можна співставити за transaction ID або Lead ID. У результаті формується таблиця з усіма конверсіями. У частини конверсій буде повний набір даних:

• email;

• телефон;

• GCLID або FBCLID;

• transaction ID або Lead ID;

• value;

• статус події.

У частини — тільки email, телефон і дані про конверсію. Це нормально: система все одно може використовувати ці параметри для matching.

4. Передавати конверсії через API

Із готового dataset дані передаються в рекламні системи:

• у Google Ads — через API;

• у Meta — через Facebook API.

У Google BigQuery є пряма інтеграція з Google Ads через Data Manager, але вона обмежує lookback window до 14 днів. Якщо підтвердження конверсії відбулося пізніше, вона може не зарахуватися.

Через API у Google Ads можна передавати конверсії в межах довшого вікна — до 30 днів. У Meta вікно коротше — сім днів, і передача також відбувається через API.

5. Налаштувати моніторинг

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

Варто перевіряти:

• які конверсії передалися;

• які не потрапили в рекламну систему;

• який match rate;

• де виникають помилки;

• чи потрібно дозавантажити історичні дані.

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

Як безпечно тестувати нові конверсії в рекламних кампаніях

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

Тестування потрібно проводити разом із PPC-спеціалістом. Він допоможе визначити:

• які кампанії можна перевести на нові конверсії;

• які конверсії залишити для аналітики;

• як довго тримати тест;

• коли переводити нову конверсію в primary;

• коли відключати старі конверсії.

Для Google Ads 

Безпечніший сценарій — спочатку налаштувати нову конверсію як secondary conversion. Вона не бере участі в навчанні кампаній, але дозволяє перевірити, чи коректно надходять дані.

На цьому етапі потрібно подивитися:

• чи наповнюється конверсія;

• який match rate;

• чи немає втрат у передачі даних;

• чи всі потрібні події доходять до рекламного кабінету.

Якщо дані передаються коректно, можна поступово змінити ролі: стару конверсію перевести в secondary, а нову — зробити primary. Стару конверсію не варто одразу видаляти. Краще залишити її для порівняння й подивитися, як кампанії проходять перехід.

Для Meta Ads

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

Головне правило — не змінювати все одночасно. Спочатку підготуйте dataset, перевірте передачу даних, узгодьте тест із PPC-спеціалістом і лише після цього переводьте кампанії на нові сигнали. Так інтеграція не зламає те, що вже працює в рекламному акаунті.

Кейси: як чистіші сигнали впливають на результат реклами

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

Кейс 1. Ecommerce: менше конверсій, але кращий результат

Що було не так

У проєкті приблизно 50% замовлень не підтверджувалися. Користувачі оформлювали замовлення на сайті, але після дзвінка менеджера частина з них відмовлялася від покупки.

Причини могли бути різними:

• користувач не хотів очікувати доставку;

• замовлення втрачало актуальність;

• виникали індивідуальні причини для відмови.

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

Що було ризиком

Команда розуміла: якщо передавати в рекламну систему тільки підтверджені замовлення, кількість конверсій у кабінеті скоротиться приблизно вдвічі.

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

Що зробили

Команда запустила тест разом із PPC-спеціалістом.

Для тесту обрали дві рекламні кампанії, схожі за параметрами. На одну з них поставили нову primary-конверсію — підтверджену конверсію, яку завантажували в рекламну систему.

Після цього результати кампаній порівнювали між собою.

Що отримали

Кампанія з чистішим сигналом спрацювала краще.

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

Потенційно, якщо масштабувати цей підхід на рекламний акаунт, ефект може сягати до 15 млн грн на рік. Це саме екстраполяція, а не гарантований результат, тому що від місяця до місяця показники можуть відрізнятися.

Висновок із кейсу

Іноді рекламній системі краще передавати менше конверсій, якщо ці конверсії точніше показують бізнес-результат. У цьому кейсі чистіший сигнал допоміг алгоритму краще зрозуміти, яких користувачів потрібно залучати.

Кейс 2. Subscription-бізнес: передача purchase із value у Meta CAPI

Що було не так

Користувачі проходили довгий шлях:

• реєструвалися в застосунку;

• проходили онбординг;

• переходили на форму оплати;

• оформлювали підписку.

Фінальна цільова дія відбувалася не одразу, а після кількох проміжних етапів. Тому для системи було важливо отримувати саме purchase-сигнал із сумою, а не тільки попередні дії користувача.

Що зробили

Команда налаштувала передачу конверсій у Meta CAPI.

У систему передавали підписки із сумами, тобто purchase-події з value. Так рекламний алгоритм отримував сигнал, ближчий до фінального бізнес-результату.

Що отримали

Після запуску передачі конверсій результати почали покращуватися:

• conversion rate від кліка до покупки зріс на 16%;

• cost per purchase знизився на 30%;

• CPM також суттєво впав.

Система почала краще орієнтуватися на користувачів, які з більшою ймовірністю доходять до оплати.

Висновок із кейсу

Передача purchase із value допомагає алгоритму оптимізуватися не просто на дію, а на цінну дію. У цьому кейсі Meta CAPI дав системі чистіший сигнал, і це покращило ефективність реклами.

Коли бізнесу варто впроваджувати передачу конверсій із CRM

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

Розглянути таку інтеграцію варто, якщо:

• дані в CRM і рекламному кабінеті суттєво відрізняються;

• рекламний кабінет бачить менше конверсій, ніж CRM;

• у рекламі багато конверсій, які не доходять до продажу, оплати або угоди;

• частина замовлень не підтверджується після дзвінка менеджера;

• бізнес працює з lead generation, де form submit не дорівнює qualified lead;

• є довгий шлях від заявки до фінального продажу;

• частина покупок відбувається офлайн після онлайн-взаємодії;

• рекламний акаунт уже оптимізований, але масштабування вперлося у стелю;

• бізнес хоче оптимізувати рекламу не на кількість заявок, а на якість клієнтів.

Окремо варто подивитися на цей підхід ecommerce-проєктам, сервісним бізнесам, B2B-компаніям, SaaS і subscription-продуктам. У них часто є проміжні етапи між першою конверсією і реальним доходом: підтвердження замовлення, кваліфікація ліда, демозустріч, оплата, оформлення підписки.

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

Перед впровадженням варто відповісти на три питання:

1. Яка подія в CRM найкраще показує бізнес-результат?

2. Чи достатньо таких подій для навчання рекламної системи?

3. Чи зможе команда безпечно протестувати нову конверсію разом із PPC-спеціалістом?

Якщо відповідь на ці питання позитивна, передача CRM-конверсій може стати наступним кроком у розвитку performance-реклами. Вона допоможе не просто «довантажити» дані в рекламний кабінет, а навчати алгоритми на сигналах, які ближчі до грошей, клієнтів і реального результату бізнесу.

Висновки

1. Рекламним системам потрібні не просто конверсії, а якісні сигнали.

2. CRM часто краще показує реальний бізнес-результат, ніж рекламний кабінет.

3. Передача конверсій напряму в Google Ads і Meta допомагає компенсувати втрати даних або очистити сигнали від шуму.

4. Подію для передачі потрібно обирати за трьома критеріями: кількість, строк настання, близькість до бізнес-результату.

5. Впроваджувати такі інтеграції потрібно разом із PPC-спеціалістами, через тестування, а не різке перемикання активних кампаній.

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