Сигнал і вимірювання

Вердикт

Що робити завтра вранці, коротко:

1. Перевірити в CRM, скільки реально заявок за 21.07. Піксель дає 2 події Lead, з них 1 серверна, а кабінет одночасно показує results = 1 і lead = 2 на тому самому оголошенні.
2. Перевести оптимізацію на InitiateCheckout. Lead дає 17-34 події на тиждень при $150/день, поріг виходу з навчання 50. IC дає 252.
3. Полагодити передачу fbc і fbp у події Lead. Код їх читає з cookie і шле в воркер, але в Meta вони не доходять: Event Match Quality на Lead 4.4 з 10, у списку ключів тільки ip, user_agent і phone.
4. Виключити Audience Network. 60 переглядів сторінки (14% усіх LPV) за 1.7% бюджету і нуль кошиків.
5. Не чіпати піксель Хорошопа як подію оптимізації. Він у чужому бізнес-менеджері і дає 775 покупок за 28 днів чужої воронки.

Чи можна взагалі довіряти цифрам кабінету

Коротка відповідь: у поточному стані ні. Нижче три розбіжності, кожна перевірена особисто через Meta MCP, і кожна змінює рішення про гроші.

Розбіжність 1. Одна кампанія, одна доба, чотири різні CPL

Знято на рівні оголошень:

Обидві заявки прийшли з одного оголошення, VD6.7. І на ньому Meta одночасно пише «результатів 1» і «лідів 2».

Тепер дивимось, що з цього виходить для рішення. Ціль замовника по заявці $10:

Розкид 5.2 раза, і на кінцях цього розкиду протилежні рішення.

Чому колонки різні, механічно: «Результати» рахують подію за налаштуванням атрибуції кампанії (7d_click) з дедуплікацією, «Ліди» це сира кількість дій типу lead. Рівень оголошення відносить тільки власну витрату, рівень кампанії всю. Обидві колонки самі по собі легітимні для різних питань.

Але results = 1 при lead = 2 на ТОМУ САМОМУ оголошенні означає, що сама Meta не визначилась, це одна подія чи дві. Найімовірніша причина: дедуплікація по eventID між браузерною і серверною копією не спрацювала, і одна заявка порахована двічі. Підтвердження або спростування коштує 5 хвилин: подивитись у CRM, скільки замовлень за 21.07.

Розбіжність 2. Purchase помер 10.07, за 11 днів до запуску

Це найважливіша знахідка звіту. Порівняння двох подій на пікселі 683420709301054 по днях:

Останній Purchase у датасеті: 10.07 о 03:00 за PDT. Після цього нуль, 11 днів поспіль.

І ще одна деталь, яка закриває питання остаточно. До 10.07 Lead і Purchase спрацьовували в одні й ті самі години і в однаковій кількості: 06.07 об 11:00 чотири Lead і чотири Purchase, 09.07 о 09:00 чотири і чотири, 09.07 о 10:00 чотири і чотири. Тобто людина проходила ланцюг з чотирьох сторінок за хвилини, всередині однієї години.

Падіння з 0.90 до 0.00 за одну ніч, з утриманням нуля 11 днів поспіль, не буває поведінкою. Це технічна поломка, а не обвал на апселах. І вона сталася ДО запуску реклами, тобто рекламу запустили в воронку, яка вже не вміла повідомляти про продажі.

Це також відповідає на питання про серверну копію. Воркер lpcrm-intake.notenot.workers.dev/event до Meta не доходить взагалі: за 7 днів у датасеті рівно одна серверна подія, і це Lead, а не Purchase.

Розбіжність 3. IC → Lead мінус 86%, і ось це правда

Тут, на відміну від Purchase, розбіжність не технічна, а справжня. Історичний коефіцієнт самого пікселя 21.9%, у день 1 вийшло 11.8-14.3%. Гірше, але того самого порядку. Тобто ми бачимо реальне вузьке місце воронки, а не поломку: холодний трафік конвертує з кошика в заявку приблизно вдвічі гірше за середній по сайту.

Для драбини це має пряме і неприємне значення: Lead завжди буде приблизно вп'ятеро рідший за IC. При 252 IC на тиждень це 30-55 Lead на тиждень, тобто рівно навколо порога 50. Саме тому Lead не можна брати як подію оптимізації сьогодні: він сидить на самій межі, і будь-яке дроблення бюджету по адсетах скидає його під поріг.

Що з цього випливає, головний висновок

Порядок, який з цього випливає, і він не переставляється:

1. Спершу навчитись рахувати подію: піксель зійшовся з CRM з точністю ±5%.
2. Потім переконатись, що кабінет дає по ній ОДНЕ число, а не два.
3. І тільки потім ставити її метою оптимізації.

Подієва драбина з розрахунком

Факт першого дня

Дані зняті з Meta MCP станом на 21.07 о 21:18 за київським часом. Витрата на момент зняття вже $62.45, не $58.43 як у брифі: доба ще не закрилась.

Останній рядок це головна цифра звіту. За весь тиждень 14-21.07 піксель 683420709301054 не записав жодної події Purchase, ні браузерної, ні серверної. Останній Purchase у датасеті датований 10.07, тобто механізм зламався за 11 днів до запуску реклами.

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

Скільки подій буде на тиждень при $150 на день

Рахуємо по фактичній ціні події за перший день. Тиждень при $150 на день це $1 050.

Контрольна перевірка з іншого боку. Історичний коефіцієнт пікселя Lead/IC = 21.9%, у день 1 вийшло 11.8-14.3%. Від 252 IC на тиждень це дає 30-55 заявок, що накриває обидва прочитання кабінету і сідає рівно на поріг. Оцінка стійка: скільки б не сперечались про колонки, Lead виходить на межу 50 або нижче.

Якщо ті самі $150 розбити на три адсети по $50, картина така:

Тобто при поточному бюджеті на подію Lead не виходить з навчання жоден варіант структури, ні один адсет на весь бюджет, ні три по $50. І це висновок, який не залежить від того, яку колонку кабінету вважати правильною.

Скільки треба грошей, щоб Lead запрацював

Правило просте: подія проходить поріг, коли бюджет адсета за день × 7 / ціна події ≥ 50. Звідси гранична ціна події:

Поточний CPL $31.23 за колонкою «Ліди». Щоб з ним вийти на 50 заявок за тиждень, треба $223 на день на один адсет. Якщо правильна колонка «Результати» і CPL насправді $62.45, треба $446 на день на один адсет. При цільовому CPL $10 вистачить $71 на день на адсет, тобто Lead запрацює навіть при трьох адсетах у межах $150 на день.

Висновок по драбині

Зараз оптимізуємось на InitiateCheckout. Переходимо на Lead за виконання будь-якої з двох умов: CPL опустився до $21 і нижче при $150 на день на одному адсеті, або бюджет на адсет піднявся до $223 і вище при поточному CPL. Purchase як подію оптимізації не розглядаємо взагалі, поки він фізично не спрацьовує.

Чому саме IC, а не ATC. ATC дає більше подій (306 проти 252), але IC глибший за наміром (спрацьовує після додавання, 82.4% від ATC) і несе більший value ($110.14 проти $71.68 середнього). Обидва проходять поріг з великим запасом, тому беремо глибший. ATC це запасний варіант, якщо після дроблення бюджету IC на адсет впаде нижче 60 на тиждень.

Важлива поправка. У коді лендинга перший клік по головному CTA не відкриває кошик, кошик відкривається лише якщо в ньому вже щось було. Тобто подія IC штучно занижена інтерфейсом. Це не мій розділ, але це прямо впливає на обраний сигнал: полагодження цього кліка підніме обсяг події оптимізації без жодної додаткової витрати.

Ціль кампанії і подія оптимізації

Що зараз стоїть

Знято фактом з MCP:

Що це означає для алгоритму

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

Друга особливість: OUTCOME_LEADS не відкриває оптимізацію по цінності на тих самих правах, що OUTCOME_SALES, і не відкриває каталог та динамічний ретаргет. Останнє зараз усе одно недоступне, бо в коді немає ViewContent і немає фіда.

Чим це відрізняється від цілі Продажі з подією Purchase

Тут ключова асиметрія: Purchase систематично занижує КІЛЬКІСТЬ і завищує СУМУ, Lead навпаки завищує кількість і занижує суму. Purchase не спрацьовує для тих, хто закрив вкладку на /tovar1/: за живий період 03-10.07 це зʼїдало 10% замовлень (44 покупки на 49 заявок), а з 13.07 зʼїдає всі 100%. Lead же не бачить апселів, які майже подвоюють чек (потенційно 7 540 грн проти базових 3 850).

Жодна з двох подій сама по собі не дає правди. Правда рахується так:

```

Реальний дохід = кількість Lead з Meta

× апрув 0.80

× викуп 0.80

× реальний зібраний чек з CRM (з апселами)

```

Що робити з нашою економікою

Ланцюг замовника: заявка $10 → апрув 80% → викуп 80% → покупець $15.6.

Останній стовпець тут найважливіший, і його не можна ані ховати, ані видавати за правду. Одне оголошення з трьох, VD6.7, зібрало обидві заявки на власні $23.83, тобто дало заявку по $11.92 при цілі $10. Це не привід святкувати на двох подіях, але це і не «в шість разів мимо цілі». Реальна відповідь десь між: два з трьох роликів витратили $38.93 і не дали жодної заявки, і саме вони тягнуть середню по кампанії вгору.

Рекомендація: ціль кампанії OUTCOME_LEADS не міняти. Вона правильна: наша грошова подія це саме заявка, а Purchase спрацьовує через три сторінки після того, як гроші вже фактично замовлені. Міняємо не ціль, а подію оптимізації всередині цілі на InitiateCheckout, це OUTCOME_LEADS дозволяє без переробки кампанії.

Перехід на OUTCOME_SALES це окреме рішення, і воно не моє. Виносжу його Назару як розвилку, а не роблю сам:

Розвилка для Назара. OUTCOME_SALES дає оптимізацію по цінності, каталог і динамічний ретаргет. Але вона потребує: (а) щоб Purchase взагалі спрацьовував, зараз 0 подій; (б) 50 покупок на тиждень на адсет, це при цільовому $15.6 за покупця близько $780 на тиждень на адсет; (в) реалізованого ViewContent і фіда. Умови не виконані жодна. Пропоную повернутись до цього питання на 30-й день, коли буде фактичний CPL і полагоджений Purchase. Рішення за вами.

Якість сигналу і сміттєвий трафік

Audience Network

Розшифровка по підплейсментах: rewarded_video 186 показів, CTR 29.57%, 37 LPV, нуль кошиків. an_classic 171 показ, CTR 25.73%, 22 LPV, нуль кошиків.

CTR 26.46% при нулі кошиків це не інтерес. Це промахи по екрану в іграх і застосунках з винагородою за перегляд.

Як саме це отруює навчання

Чотири канали шкоди, за спаданням важливості:

1. Ретаргетні аудиторії. Аудиторія Zarmilkas | Site Visitors 180d збирається за PageView. Кожен випадковий тап у грі потрапляє в неї назавжди на 180 днів. Ці ж люди стають сідом для LAL. Це найгірший канал, бо шкода накопичується і залишається після того, як AN вимкнули.
2. Спотворення базових метрик. Ціна LPV $0.14 у звіті це середнє між реальними $0.16 і фальшивими $0.017. Будь-яке порівняння креативів по ціні LPV бреше рівно настільки, наскільки нерівномірно AN розподілився між ними.
3. Проксі-сигнали в навчанні. На етапі навчання при 2 конверсіях за добу модель спирається на верхньофункціональні проксі. 14% сміттєвих LPV це 14% шуму саме в тому шарі, на який модель зараз дивиться.
4. Прямий ризик при зміні події. Якщо колись оптимізуватись на LPV або ViewContent, AN миттєво зʼїсть увесь бюджет.

Сміттєві години

Окремо від AN: години 05:00 і 06:00 разом дали 3 402 покази (25% усіх), 136 LPV (32% усіх) і нуль кошиків та checkout. Кошики і checkout зʼявляються тільки в діапазоні 10:00-17:00.

Це переоцінює всю воронку. Якщо прибрати ці дві години, реальна конверсія в кошик виглядає так:

Тобто воронка конвертує на 47% краще, ніж показує заголовна цифра. Це важливо для порогів прийняття рішень: якщо ставити стоп-лоси по «4% в кошик», ми зарубаємо звʼязки, які насправді дають 5.9%.

Що робити

1. Виключити Audience Network у плейсментах. Ціна питання 1.7% бюджету, віддача мінус 14% шуму в LPV.
2. Головне і безкоштовне: будувати ВСІ ретаргетні аудиторії на подіях ATC, IC, Lead, ніколи на PageView. Тоді сміттєвий трафік не потрапляє в аудиторії за визначенням, незалежно від плейсментів.
3. Не вимикати години 05:00-06:00 розкладом. Це лікування симптому: після виключення AN подивитись, чи блок зникне сам. Даних за одну добу замало, щоб різати розклад.

Два пікселі: рішення

Факт по обох

Розшифровка ключів збігу:

Дві знахідки, які треба назвати прямо

Перша. Фантомна покупка. У звіті кампанії onsite_conversion_purchase = 1, а offsite_conversion_fb_pixel_purchase = недоступно, тобто нуль. purchase_roas і website_purchase_roas теж недоступні. У коді broshky1 піксель ОДИН, і він за добу не записав жодного Purchase. Висновок однозначний: «1 покупка за $58.43» це не замовлення broshky1. Це покупка на майданчику Meta, вона не має жодного стосунку до нашої воронки і її не можна ставити в жоден розрахунок CPA.

Друга. fbc і fbp не доходять. У коді fbc і fbp читаються з cookie і додаються в кожен запит /lead і /event. Але в Event Match Quality на події Lead їх немає взагалі. Що це не артефакт API, доводить сусідній піксель: на Хорошопі Meta показує і fbp 97.8%, і fbc 41.3%. Отже параметри або не доходять до Meta, або передаються не в тому полі user_data. Це прямий баг і він коштує грошей: без fbc Meta не звʼязує заявку з кліком по конкретному оголошенню.

Три варіанти і рішення

Рекомендація: варіант А з двома добудовами. Кампанії broshky1 лишаються на власному пікселі 683420709301054. Історію Хорошопа беремо не як подію оптимізації, а двома безпечними способами:

1. Сід для lookalike. Аудиторія покупців Хорошопа за 180 днів як джерело LAL 1% по Україні. Це дає нам якість профілю без домішування чужих конверсій у навчання.
2. Аудиторія виключення. Хто вже купив на zarmilkas.com, виключається з холодного трафіку broshky1.

Плюс жорстке правило звітності:

Для broshky1 дивимось ТІЛЬКИ offsite_conversion.fb_pixel_lead, ATC та IC на пікселі 683420709301054. Колонку «Покупки» в кабінеті на цьому акаунті вважаємо непридатною, поки в акаунті видно два датасети одночасно.

Що НЕ робити: не ставити піксель Хорошопа в код broshky1. Це варіант Б в найгіршому виконанні: він одночасно перетягне оптимізацію і зіпсує аналітику головного магазину.

Value-based підхід

Що з value є фактом

Перша проблема: value стоїть не на всіх заявках

Кампанія показує lead = 2, а action_values:lead = $95.88 сумарно. $95.88 при курсі близько 40 це рівно одна класична брошка 3 850 грн. Тобто або друга заявка пішла без value, або заявка одна, а друга подія це недедуплікований дубль.

Ця одна відсутня цифра розвертає весь вердикт по дню 1, розрахунок нижче в розділі MER.

Друга проблема: value заявки завищений відносно грошей у касі

Value на Lead це оголошена сума замовлення. До каси доходить × апрув 0.80 × викуп 0.80 = 0.64. Тобто value, який ми шлемо в Meta, завищений у 1.56 раза відносно реального доходу.

Якщо колись увімкнути оптимізацію по цінності на цьому сигналі, Meta почне ганятись за великими оголошеними чеками, у тому числі за тими, які ніколи не підтвердяться. Це класична пастка для моделі накладеного платежу.

Третя проблема: value заявки занижений відносно апселів

Одночасно з попереднім, і в протилежний бік. Lead не бачить /tovar1/ і /500/, де докидається до 3 690 грн. Потенційний чек ланцюга 7 540 грн проти базових 3 850, тобто майже подвоєння. Скільки з цього реально беруть, кабінет не знає взагалі, знає тільки BI і CRM.

Що треба для value-based lookalike

Рекомендація по value-based, у порядку:

1. Value-based LAL 1% з датасета Хорошопа, джерело Purchase за 180 днів з value, гео Україна. Це єдине джерело, яке має і обсяг, і реальні гроші, і 100% телефонів. Створити зараз, дати аудиторії зібратись, у бій пускати окремим адсетом проти broad.
2. LAL на топ-чек з CRM. Вивантажити з CRM клієнтів верхнього квартилю за середнім чеком, телефон + сума, залити як customer list з value. Телефон це правильний ключ для України: на пікселі Хорошопа email всього 4.4%, а телефон 100%.
3. Оптимізацію по цінності на кампанії поки НЕ вмикати. Вона потребує близько 50 конверсій з value на тиждень на адсет. У нас 34 заявки на тиждень при повному бюджеті на один адсет, і навіть з них не всі несуть value.
4. Перед будь-яким value-підходом полагодити value: передавати на Lead суму, помножену на 0.64, або (краще) слати другу серверну подію зі стадії CRM з реальним зібраним чеком. Друге правильніше, бо закриває і апрув, і викуп, і апсели одним рухом.

Вікна атрибуції

Що стоїть зараз

Тобто на бойовому адсеті вікно перегляду вимкнене. У акаунті 28d_click не стоїть ніде, чи він взагалі доступний у налаштуваннях цього акаунта, треба подивитись очима в Ads Manager. Даних про це через API немає.

Що робить кожне вікно

Як вибір вікна змінює видиму кількість конверсій

Механіка однозначна і напрямок відомий точно:

```

1d_click ≤ 7d_click ≤ 7d_click + 1d_view ≤ 28d_click

```

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

Множник для нашої воронки я порахувати не можу, даних немає. Акаунту одна доба, розподілу лагу клік → заявка не існує. Те єдине, що ми знаємо фактом: обидві заявки дня 1 сталися в межах доби після старту показів, покупка на майданчику Meta о 17:00 при старті о 05:26. Тобто на день 1 весь лаг помістився всередину 24 годин, але один день це не розподіл.

Що заміряти і коли. На 14-й день зняти той самий період у трьох вікнах і записати три числа. Далі цей коефіцієнт стає константою для перерахунку:

Рішення

Ризик додавання 1d_view, який треба назвати вголос: вікно перегляду роздуває видиму кількість конверсій і може підштовхнути алгоритм у бік дешевого охоплення. Страховка одна і вона в наступному розділі: арбітром лишається MER з CRM, а не ROAS з кабінету.

MER і звірка з CRM

Три беззбиткові точки

Де ми зараз, чесно

У кабінеті purchase_roas і website_purchase_roas недоступні, тобто ROAS у кабінеті не існує взагалі. Є result_roas = 1.54, і це НЕ ROAS. Це відношення оголошеної суми заявок до витрати. Щоб не плутати, називаємо це окремим іменем: LVR, lead value ratio.

Переклад LVR у реальний MER:

```

LVR 1.54 × апрув 0.80 × викуп 0.80 = 0.986

```

Це та сама розвилка «1 чи 2», що і в розділі про довіру до кабінету, тільки виражена в MER. Плюс до неї MER рахований по базових 3 850 грн: апселів на /tovar1/ і /500/ кабінет не бачить взагалі, а вони можуть додавати до 3 690 грн зверху.

Система звірки: яку цифру де дивимось

Норми розбіжності

Логіка норм проста. CRM завжди бачить більше заявок, ніж Meta, бо ловить і органіку, і прямі дзвінки, і всіх, кого не змогла звʼязати атрибуція. Тому Meta більше за CRM це не «добре», це доказ, що в звіті чужі конверсії. Саме це ми і побачили в перший день.

За день 1 маємо: піксель 2 події Lead, Meta атрибутувала 2, CRM невідомо. Друга пара 100%, це підозріло добре при EMQ 4.4 і підсилює версію про недедуплікований дубль.

Пороги тривоги

Що доробити в трекінгу

Пріоритети виставлені за одним критерієм: наскільки правка міняє гроші або рішення, а не наскільки вона гарна.

Критично, робити зараз (день 0-2)

Важливо, тиждень 1

Потім, тиждень 2-4

Наскільки Purchase недорахований відносно Lead

Читати так. Поки подія була жива (03-10.07), вона працювала майже ідеально: 44 покупки на 49 заявок, у тих самих годинах, тобто ланцюг з чотирьох сторінок люди проходили за хвилини і губилось усього 10%. Це важливо: сама воронка апселів не обриває клієнтів, гіпотеза про поведінковий обвал знімається.

З 13.07 подія не спрацьовує зовсім. Чотири заявки, нуль покупок, 11 днів поспіль.

Висновок для закупівлі: на подію Purchase у цій воронці оптимізуватись не можна, поки вона не воскресне і не відпрацює 7 днів чисто. І показувати Назару CPA чи ROAS по Purchase не можна взагалі, у знаменнику зараз нуль.

Окремо: після фіксу Purchase не стане правильною подією оптимізації автоматично. Навіть у здоровому стані (коефіцієнт 0.90) він недорахує близько 10% замовлень і завищить value за рахунок апселів. Для оптимізації правильним лишається IC, для звірки грошей правильним лишається CRM.

План вимірювання на 30 днів

Дні 0-2, фундамент

Дні 1-7, перебудова сигналу

Дні 7-14, перші коефіцієнти

Дні 14-21, розширення

Дні 21-30, вердикт і підготовка інкрементальності

Коли можна робити geo-holdout по областях України

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

Щоб побачити підйом близько 20% з довірою, треба порядку 200 конверсій на групу за період тесту. Рахуємо:

Технічні передумови, без яких тест безглуздий:

1. CRM пише область доставки в кожне замовлення. Даних про це немає, треба перевірити.
2. Мінімум 4 тижні базової лінії по областях ДО тесту, інакше нема з чим порівнювати.
3. Розбиття областей робиться за історичною часткою замовлень з CRM, а не навпіл за списком. Дві групи мають бути збалансовані за обсягом, а не за кількістю областей.
4. Тривалість тесту 4 тижні, у holdout реклама вимикається повністю, міряються органічні і прямі замовлення з CRM по областях.
5. Meta Conversion Lift як альтернатива: перевірити доступність через ads_experiment_check_eligibility. Він не потребує гео-розбиття, але має власні пороги обсягу. Я його не перевіряв, це наступний крок.

Таблиця «Робимо / Не робимо»

Чого не робити

1. Не вважати цифри кабінету правдою про цю воронку. Три докази з одного дня: покупка в звіті це не наша покупка, CPL дає чотири різні значення з розкидом 5.2 раза, ROAS відсутній як поле. Кабінет тут це індикатор напрямку, а не бухгалтерія.

1-БІС. Не міняти прочитання колонки посеред тесту. Найлегший спосіб обдурити себе на цьому акаунті: у понеділок подивитись «Ліди» на оголошенні ($11.92), у пʼятницю «Результати» на кампанії ($62.45) і зробити висновок, що все обвалилось у 5 разів. Колонка фіксується один раз до старту тесту і не міняється до його кінця.

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

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

4. Не додавати конверсії з різних вікон. 7d_click = 10 і 1d_view = 4 це не 14. Це 10 і окремо 4, з перетином, який ми не бачимо.

5. Не приймати рішення про стоп по одному дню. При 2 подіях за добу довірчий інтервал ширший за саму метрику. Мінімум для рішення по звʼязці це 50 подій обраної події оптимізації, тобто при IC приблизно 1.5 доби на адсет, при Lead приблизно 10 діб.

6. Не оптимізуватись на утримання відео. VD6.9 має найкращий перегляд (1 102 з 4 535 дивляться 25%), а кошик у нього $5.56 проти $1.93 у VD6.7, який тримає гірше (638 з 3 865). Утримання і намір купити тут не корелюють, і на цьому продукті це закономірність, а не випадковість: людина, яка вирішила, зупиняє ролик і йде на сайт.

7. Не лікувати низький EMQ додаванням email. На пікселі Хорошопа email всього 4.4% при телефоні 100%. Україна це телефонна країна. Вкладатись треба в fbc, fbp, external_id і нормалізацію телефону, а не в збір пошти.

8. Не переносити пороги з інших ніш. «50 конверсій на тиждень» це поріг Meta, і він тут працює. А «CTR вище 2% це добре» тут не працює: у нас CTR 26.46% на плейсменті, який не дав жодного кошика.

Ризики

Чого я не зміг заміряти і що треба зняти вручну

Чесний список, щоб ніхто не подумав, що тут усе перевірено.