Як виглядає глибокий аудит Meta Ads (Facebook/Instagram) інтернет-магазину від UPLIFY?
Реальний (знеособлений) senior-аудит рекламного акаунта Meta (Facebook/Instagram) від UPLIFY: статус INTERIM, measurement-гейт, 16 знахідок, план дій. Підготовлено AI-оператором Nestor AI, підтверджує менеджер.
Глибокий аудит сайту інтернет-магазину.
Реальний аудит реального клієнта UPLIFY — повністю знеособлений. Нішу, бренди, домен і всі ID приховано; уся методологія, структура journey й фактичні спостереження збережені без змін. Незалежний senior-аудит UX / SEO / CRO / видимості, де кожна знахідка відтворювана: запит → сторінка → артефакт → метрика. Зверніть увагу на статус BROWSER-ONLY — це чесність, а не недоробка: ми не видаємо ризик-оцінку за доведену втрату виручки.
Аудит за 90 секунд.
- Примусова реєстрація вбиває кошик: guest checkout відсутній — щоб оформити замовлення, треба завести акаунт + підтвердити email. Це окремий revenue-risk блок (Baymard: ~70% покинутих кошиків).
- Вартість доставки прихована до кроку оформлення: Нова Пошта / Укрпошта зʼявляються тільки після введення міста — класичний «surprise cost» обрив.
- Фасетна навігація засмічує індекс: комбінації фільтрів (?color=&price=) індексуються без canonical/noindex → тисячі дублів їдять crawl-budget.
- Product JSON-LD відсутній на PDP → знижує eligibility для rich-сніпетів і машинну екстракцію price / availability / brand для Google та AI; повну Shopping-готовність підтверджує лише фід у GMC (T2). Visibility 45/100.
- INP на фільтрах і доданні в кошик >200 мс на мобільному — interaction lag на найгарячіших діях.
- Увімкнути guest checkout — акаунт пропонувати ПІСЛЯ покупки.
- Закрити фасетні URL від індексації (canonical + robots).
- Додати Product/Offer JSON-LD з price+availability на PDP.
- Конверсія: зняти тертя в checkout — найбільший важіль T1.
- Видимість: чистий індекс + schema → Google/AI розуміють товари.
- Швидкість: INP під поріг 200 мс на мобільному.
- Немає доступу до GA4 → реальний % відмов у кошику не доведений, лише friction-ризик.
- Немає GSC → індексацію оцінюємо через site: + SerpApi, не звіт покриття.
- Немає GMC/admin → feed↔admin parity не перевіряється (це T2).
- Усі journey-шаблони покрито: Home / Search / Category / PDP / Cart / Checkout / Login / Returns + 12 стратифікованих PDP + 12 пошукових запитів.
- Lighthouse median ×3 на шаблон · 3 конкуренти + 1 маркетплейс (Rozetka/Prom).
- Незалежна валідація: PASS (gpt-5.2). Перформанс-висновки чесно позначені як ризик, не доведена втрата.
Чи можна вірити цьому аудиту?
Питання №1 чесності: у нас немає доступу до GA4 / GSC / GMC / admin. Тому всі висновки про checkout і виручку — це тертя + ризик видимості (directional), а не доведена втрата грошей. Ми аудитуємо те, що спостерігається з публічного сайту + живого браузера + SerpApi. Поки доступи закриті — звіт чесно має скоуп T1 (browser-only).
| Перевірка | Стан | Що це означає |
|---|---|---|
| Публічний сайт + journey | OBSERVED | Усі шаблони пройдено живим браузером — UX/checkout/пошук відтворено |
| Структура й schema (rendered DOM) | OBSERVED | JSON-LD, canonical, robots, sitemap перевірено в rendered DOM (не curl) |
| Реальний % відмов у кошику (GA4) | НЕМАЄ ДОСТУПУ | Бачимо тертя, але не його ціну в грн → friction-ризик, не доведена втрата (T2) |
| Покриття індексу (GSC) | ПРОКСІ | Тільки site: + SerpApi — приблизна оцінка, не звіт покриття Google |
| Feed ↔ admin parity (GMC) | BLOCKER | Без Merchant Center / admin item-level disapprovals не звіримо — це T2 |
Стан магазину одним поглядом.
Головний висновок (directional): магазин має здорову основу (HTTPS, адаптив, робочий каталог), але системно тече у двох місцях: тертя на шляху до покупки і невидимість товарів для Google та AI. Найбільші важелі — guest checkout, прозорість доставки й Product schema; усі три дешеві у впровадженні й критичні за впливом. Платформа Horoshop накладає обмеження (частину фіксів треба позначати «потребує кастому»).
Примусова реєстрація
P0Guest checkout відсутній — оформлення вимагає акаунту + підтвердження email. Примусова реєстрація — одне з найсильніших джерел тертя в кошику. Окремий revenue-risk блок (Baymard ~70% abandonment).
Прихована доставка
P1Вартість Нової Пошти / Укрпошти зʼявляється лише після введення міста на кроці оформлення — «surprise cost». Видимих методів оплати до коміту немає.
Невидимість у Google/AI
P1Product JSON-LD відсутній, фасетний індекс роздутий, категорії тонкі — це знижує eligibility для rich-сніпетів і машинну екстракцію price/availability/brand для Google та AI. Повну Shopping-готовність підтверджує лише фід у GMC (T2). Visibility 45/100.
Шість шарів, де магазин тече.
Композит 55/100 — це rubric-оцінка (T1, browser-only), зважене середнє шести шарів за T1-вагами (Journey 25 · Visibility 25 · Mobile 15 · Trust&Compliance 15 · Search&Merch 10 · Measurement 10). Нижче — бал кожного шару, а далі його ключові знахідки + метрики.
- Guest checkout відсутній — примусова реєстрація + email-підтвердження перед оплатою (JCK-09).
- Доставка/оплата приховані до кроку оформлення — «surprise cost» на Новій Пошті (JCK-05, JCK-06).
- Чекаут просить зайві поля; при помилці телефону стирає введене (JCK-10, JCK-13).
- Out-of-stock PDP — глухий 200 без «повідомити»/аналогів (SRCH-12).
- Полів у чекауті: 9 (бейзлайн ≤3; 7+ → −25-50%).
- Кроків до видимої вартості доставки: 4.
- Sticky add-to-cart на моб.: немає.
- Promo-поле: є, але без live-перерахунку.
- INP >200 мс на фільтрах і add-to-cart — лаг на найгарячіших діях (MOB-03).
- CLS від банерів/слайдера на головній — стрибки макета при завантаженні (MOB-02).
- Зображення без WebP/AVIF, lazy-load частковий (MOB-09).
- Tap-таргети фільтрів <44 px і скупчені (MOB-07).
- LCP моб.: 3.4 с (поріг 2.5 с).
- CLS: 0.21 (поріг 0.1).
- INP (фільтр): ~260 мс (поріг 200).
- Лаб, не CrUX — орієнтир, бо сайт замалий для field-даних.
- Zero-results — глухий кут: «нічого не знайдено» без підказок/популярного (SRCH-03).
- Пошук не тримає транслітерацію й розкладку (iphone/айфон) (SRCH-02).
- Out-of-stock товари не приховані у видачі (SRCH-12).
- Хлібні крихти є візуально, але без BreadcrumbList-schema (SRCH-11).
- Запитів із 12 з релевантною видачею: 7.
- Zero-result сценаріїв: 3 глухі.
- Кліків до ключової категорії: 2-3 (ок).
- Фасети: AJAX, без reload (плюс).
- Product JSON-LD відсутній на PDP — Google/AI не бачать price/availability/brand (VIS-10).
- Фасетний індекс роздутий: ?-комбінації без canonical/noindex (SRCH-08, VIS-05).
- Тонкі категорії — голий грід без унікального вступу (SRCH-09, VIS-17).
- AI-ботів частково закрито в robots (GPTBot/ClaudeBot/PerplexityBot) (VIS-AI-01).
- Бренд відсутній у Google KG / Wikidata (VIS-AI-06).
- PDP з валідним Product-schema: 0 з 12.
- Дублі title/desc: є (фасети + пагінація).
- AI Overview за бренд+категорія: відсутній.
- HTTPS/сертифікат: ок (VIS-09 pass).
- Відгуки на PDP без фото й дат — слабкі authenticity-сигнали (TRU-04).
- Повернення/гарантія — лише у підвалі, не на PDP/кошику (TRU-03, JCK-19).
- Cookie-банер є, але opt-in передвибрано (TRU-07).
- Privacy/Terms, контакти, About — присутні (TRU-01, TRU-02, TRU-09 pass).
- Trust-сторінки досяжні: так.
- Reviews з фото: 0%.
- Keyboard-навігація чекауту: часткова (TRU-13).
- WHOIS/домен: стабільний, без аномалій (TRU-12).
- GA4/GTM-тег вантажиться, dataLayer заповнений (MEA-01, MEA-02 pass).
- begin_checkout не стріляє при старті оформлення — діра у воронці (MEA-05).
- Meta Pixel присутній; add_to_cart дублюється (двічі) (MEA-08, MEA-09).
- Consent Mode v2 не гейтить теги до згоди (MEA-07).
- Бачимо, що подія стріляє в браузері — не що дані коректні в GA4.
- view_item / purchase — присутні в network.
- Revenue-reconciliation GA4↔admin — це T2.
- PII у querystring подій: не виявлено (MEA-10 pass).
23 знахідки — кожна з доказом.
Кожна знахідка = шар + спостереження (запит → сторінка → артефакт) + серйозність. Нижче — повна таблиця з фільтром за серйозністю. Бакети roadmap (§7): P0/P1 → Fix this week/month · P2 → Test/validate · P3 → Backlog.
| # | Шар | Знахідка (спостереження) | Сер. |
|---|---|---|---|
| JCK-09 | Journey | Guest checkout відсутній — оформлення вимагає створення акаунту + підтвердження email перед оплатою. | P0 |
| JCK-05 | Journey | Вартість доставки (Нова Пошта/Укрпошта) прихована до введення міста на кроці оформлення — «surprise cost». | P1 |
| JCK-06 | Journey | Методи оплати (картка/LiqPay/mono/COD) не показані іконками до коміту в чекаут. | P1 |
| JCK-13 | Journey | При помилці телефону форма стирає введене; error-copy загальна («неправильне поле»), не fixable. | P1 |
| JCK-10 | Journey | Чекаут просить 9 полів, частина неістотні (бейзлайн ≤3 поля). Зовнішні дослідження чекауту пов'язують зайві поля з помітно нижчим завершенням; дроп саме цього магазину тут НЕ вимірювався (T1). | P2 |
| JCK-19 | Journey | Повернення/гарантія недосяжні з кошика/чекауту — лише у підвалі (regret-aversion). | P2 |
| VIS-10 | Видимість | Product JSON-LD відсутній на всіх 12 перевірених PDP — знижує eligibility для rich-сніпетів товару й машинну екстракцію (price/availability/brand) для Google та AI; повну Shopping-готовність підтверджує лише фід у GMC — T2. | P1 |
| SRCH-08 | Видимість | Фасетні URL (?color=&price=) індексуються без canonical/noindex/disallow — ризик роздування індексу (faceted-URL без canonical/noindex/disallow); масштаб підтверджується лише в GSC — T2. | P1 |
| VIS-05 | Видимість | Canonical не self-referencing на пагінації/фасетах — дублі title/description у видачі. | P1 |
| SRCH-09 | Видимість | Категорійні сторінки тонкі — голий грід без унікального вступного копірайту/мерчандайзингу. | P2 |
| VIS-11 | Видимість | BreadcrumbList + Organization/WebSite schema відсутні (rendered-DOM перевірка). | P2 |
| VIS-AI-06 | Видимість | Бренд відсутній у Google Knowledge Graph / Wikidata — AI не може верифікувати сутність. | P2 |
| VIS-AI-01 | Видимість | AI-ботів (GPTBot/ClaudeBot/PerplexityBot) частково заблоковано в robots.txt — мовчазний killer AI-цитованості. | P3 |
| MOB-03 | Mobile | INP >200 мс на застосуванні фільтрів і add-to-cart (median ~260 мс, моб. браузерна сесія, медіана 3 прогонів) — лаг на гарячих діях. | P1 |
| MOB-02 | Mobile | CLS 0.21 (моб. lab, медіана 3 прогонів) від банера/слайдера на головній — макет стрибає при завантаженні (поріг 0.1). | P2 |
| MOB-09 | Mobile | Зображення без WebP/AVIF, lazy-load частковий, без responsive srcset — LCP моб. 3.4 с (lab; не польові CrUX). | P2 |
| MOB-07 | Mobile | Tap-таргети чекбоксів фільтрів <44 px і скупчені на мобільному. | P3 |
| SRCH-03 | Пошук | Zero-results — глухий кут: «нічого не знайдено» без підказок/популярних товарів/корекції. | P2 |
| SRCH-02 | Пошук | Внутрішній пошук не тримає транслітерацію й розкладку (iphone/айфон, помилки розкладки). | P2 |
| SRCH-12 | Пошук | Out-of-stock товари не приховані/не понижені у видачі та категоріях. | P3 |
| MEA-05 | Вимірювання | begin_checkout не стріляє при старті оформлення (network/dataLayer) — діра у воронці подій. | P1 |
| MEA-09 | Вимірювання | add_to_cart дублюється (стріляє двічі) — два контейнери/подвійний тег; ризик подвійного підрахунку. | P2 |
| TRU-04 | Довіра | Відгуки на PDP без фото й дат — слабкі authenticity-сигнали. | P2 |
Cause-tag: JCK-05 (приховання доставки) + SRCH-08 (фасети) = platform-template (типова поведінка Horoshop — фікс позначено «потребує кастому»); VIS-10 (немає Product-schema), JCK-09 (немає guest checkout) = merchant-specific (рішення/налаштування магазину); MEA-09 (подвійний add_to_cart) = third-party (конфлікт пікселя й GTM).
Де гарячий попит не знаходить товар.
| Пошуковий запит (з 12) | Тип | Результат | Вердикт |
|---|---|---|---|
| точна назва товару | exact | релевантно | СИЛЬНО ок |
| бренд (кирилицею) | brand | релевантно | ок |
| iphone (латиницею) | translit | 0 результатів | ОБРИВ немає транслітерації |
| помилка розкладки | layout | 0 результатів | ОБРИВ глухий кут |
| категорійний запит | category | релевантно | ок |
| typo / друкарська | typo | 0 результатів | ОБРИВ без корекції |
| Visibility-перевірка | Стан | Деталі |
|---|---|---|
| Product JSON-LD на PDP | FAIL | 0 з 12 PDP — немає price/availability/brand для Google Shopping та AI |
| Фасетна індексація | FAIL | ?-комбінації індексуються; немає canonical/noindex → bloat |
| Тонкі категорії | PARTIAL | Голий грід без вступного копірайту на більшості |
| robots / sitemap | PASS | sitemap.xml є, ключові сторінки не disallow |
| HTTPS / canonical базовий | PASS | HTTPS валідний; canonical на PDP self-ref |
| AI-боти + llms.txt | FAIL | GPTBot/ClaudeBot частково disallow; /llms.txt 404 |
Патерн: сайт добре обслуговує користувача, який уже знає точну назву, але програє «майже-збіги» (транслітерація, розкладка, typo) — і невидимий машинам (Google Shopping, AI Overviews) через відсутність структурованих даних. Це два різні витоки одного попиту.
Де насправді обрив.
Без GA4 ми не маємо реальних % переходів — тому показуємо спостережуване тертя на кожному кроці (що ускладнює перехід) і явно позначаємо, де ризик найбільший. Це directional-карта, не виміряна воронка.
| Крок journey | Спостережуване тертя | Оцінка ризику |
|---|---|---|
| PDP → add to cart | Працює; мінікошик-підтвердження є, але немає sticky-кнопки на моб. | НИЗЬКИЙ |
| Кошик → перегляд | Редагування к-сті/видалення з live-перерахунком — ок | НИЗЬКИЙ |
| Кошик → старт оформлення | Примусова реєстрація + email-підтвердження; немає guest | ГОЛОВНИЙ РИЗИК |
| Оформлення → дані доставки | Вартість Нової Пошти зʼявляється тут уперше — «surprise cost» | ВИСОКИЙ |
| Доставка → оплата | Методи оплати показані лише тут; 9 полів; стирання при помилці | СЕРЕДНІЙ |
Дві найбільші точки тертя — примусова реєстрація (вхід у чекаут) і прихована доставка (крок даних). Обидві б'ють у момент найвищого наміру купити. begin_checkout-подія тут не стріляє (MEA-05) — отже навіть у T2 ця ділянка воронки буде сліпою, доки трекінг не полагоджено.
Три знахідки під ключ.
Формат методології §4: Проблема → Доказ → Рекомендація → Критерії приймання. Готові передати розробнику. Платформа-обмеження позначені.
1 · Guest checkout
JCK-09 · P0 · checkout · merchant2 · Фасетна навігація: canonical/robots
SRCH-08 · P1 · category · platform3 · Product schema на PDP
VIS-10 · P0 · PDP · merchantСпершу зняти тертя, потім видимість.
Чотири бакети за rubric-пріоритетом (severity × scope × confidence × effort). Жодних обіцянок «+X% конверсії» — лише directional-механіка й бенчмарк-смуги.
Fix this week (P0/P1)
Увімкнути guest checkout (JCK-09); показати вартість доставки + методи оплати до коміту (JCK-05/06); додати Product JSON-LD на PDP (VIS-10); полагодити begin_checkout (MEA-05). Найбільший важіль T1 — тертя в чекауті + базова видимість.
Fix this month
Закрити фасетну індексацію canonical+robots (SRCH-08, VIS-05); зменшити поля чекауту й зберігати введене при помилці (JCK-10/13); підняти INP фільтрів під 200 мс (MOB-03); прибрати CLS банера (MOB-02); прибрати дубль add_to_cart (MEA-09).
Test & validate (P2)
Унікальний вступ на тонких категоріях (SRCH-09); zero-results із підказками + транслітерація/розкладка (SRCH-03/02); відгуки з фото й датами (TRU-04); повернення/гарантія на PDP та біля CTA (JCK-19). Перевіряти на вибірці шаблонів.
Backlog (P3) + апселл T2
Відкрити AI-ботів у robots (VIS-AI-01); приховати out-of-stock у видачі (SRCH-12); tap-таргети фільтрів (MOB-07). Далі: дати доступ GA4/GSC/GMC → T2 доведе реальний revenue-leakage і feed-parity.
Моніторинг 24/7 — без запиту.
Аудит — це знімок. Далі магазин живе під щоденним наглядом нашої платформи: система сама перевіряє ключові шари сайту й показує менеджеру збої до того, як вони з'їдять продажі.
Checkout і тертя
Зник guest checkout · повернулась примусова реєстрація · доставка/оплата сховалися до коміту · виросли поля форми · begin_checkout перестав стріляти.
Видимість і schema
Product JSON-LD зник з PDP · фасети знову в індексі · canonical зламався · llms.txt/robots закрив AI-ботів · бренд випав з AI Overviews.
Швидкість і вимірювання
INP/CLS вийшли за поріг після релізу теми · add_to_cart задублювався · Consent Mode перестав гейтити · GA4-тег замовк на ключовому шаблоні.
Покриття + валідація.
| Що | Покриття (sampling-правило) |
|---|---|
| Journey-шаблони | усі: Home · Search · Category · PDP · Cart · Checkout · Login/Register · Returns/Shipping/Payment |
| Картки товару (PDP) | 12 стратифікованих: 4 бестселери · 4 звичайні in-stock · 2 promo · 2 variant-heavy/out-of-stock |
| Внутрішній пошук | 12 фіксованих запитів: exact · partial · SKU · бренд · категорія · uk · ru · translit · розкладка · typo · zero-result · атрибут |
| Швидкість | Lighthouse median ×3 на шаблон (Home/Category/PDP/Cart/Checkout) — лаб, не CrUX |
| Конкуренти | 3 прямих + 1 маркетплейс-бенчмарк (Rozetka/Prom) |
| Класифікація знахідок | journey (6) · visibility (7) · mobile (4) · search (3) · measurement (2) · trust (1) = 23, по 6 шарах |
| Store Health (T1, browser-only · rubric) | 55/100 = Journey 50 · Mobile 55 · Search 60 · Visibility 45 · Trust 70 · Measurement 65 (T1-ваги) |
Незалежна валідація (друга AI-модель, gpt-5.2): PASS із зауваженнями — coverage 88 · depth 82 · rigor 80 · client-safety 90. Перформанс- і revenue-висновки лишаються directional (friction + visibility risk) до отримання доступів GA4/GSC/GMC — і це позначено в кожному відповідному висновку, а не дрібним шрифтом. JSON-LD перевірено в rendered DOM (web_fetch ріже <script>); site: — лише проба індексації, не score сам по собі.
Як зроблено цей аудит.
Звіт підготував Nestor AI — наш AI-оператор у UPLIFY OS: senior-рівень аналізу за власною методологією аудиту інтернет-магазину, з незалежною валідацією. Зверніть увагу на скоуп T1 (browser-only): без доступу до GA4/GSC/GMC ми принципово не видаємо ризик-оцінку за доведену втрату виручки — кожна знахідка чесно позначена як тертя + ризик видимості, і це чесність, на якій будується довіра. Усі пропозиції змін підтверджує менеджер — нічого не застосовується автоматично, кожна зміна оборотна й залогована.