Міграція чекауту на Checkout Extensibility
Піти з Additional Scripts, не втративши відстеження конверсій.
Shopify вимкнув Additional Scripts для магазинів поза Plus 26 серпня 2026 року, а Ruby-скрипти згортає 30 червня 2026. Кожен скрипт зіставляється зі своєю заміною: Web Pixel, UI-розширення або Function, після чого звітність за замовленнями перевіряється наскрізно.
Проєктна ціна
Ціна за обсягом, з оцінкою, розкладеною на частини.
Надішліть опис і отримайте цифру у відповідь.
Описати проєктТермін минув, і відстеження вже неправильне
Additional Scripts перестали виконуватися в магазинах поза Plus 26 серпня 2026 року, а Shopify Scripts на Ruby згортаються 30 червня 2026. Помітно при цьому нічого не ламається, і в цьому проблема. Замовлення далі надходять, сторінка подяки далі вантажиться, а єдиний сигнал це те, що Google Ads, Meta й ваша партнерська мережа тихо перестають сходитися зі звітами Shopify. Поки хтось помітить, алгоритми ставок уже тижнями оптимізуються на неповних даних.
Що входить у міграцію
Інвентаризація того, що там було
Кожен скрипт у полі прочитується й класифікується: аналітика, рекламні пікселі, партнерські постбеки, логіка підписок, власні поля. У частини є очевидна заміна, частина це мертвий код застосунку, знесеного роки тому, і розрізнити їх це більшість роботи.
Заміна для кожного скрипта
Кожен уцілілий скрипт переїжджає туди, де його тепер чекає платформа: розширення Web Pixel для відстеження, UI-розширення чекауту для змін інтерфейсу, Function для логіки знижок і доставки або серверна подія там, де браузеру довіряти не можна.
Доказ, що цифри повернулися
Робиться справжнє тестове замовлення і проводиться до кінця: конверсія в Google Ads, одна недубльована подія покупки в Meta, продаж у панелі партнерської мережі. Чекаут тепер працює в пісочниці, старі браузерні хитрощі не чіпляються, тому перевірка йде на боці отримувача.
Чому саме так
Зіставлення, а не перенесення як є
Вставити старий JavaScript у піксельне розширення не вийде: у пісочниці інша модель даних, інший час подій і немає доступу до DOM. Кожен скрипт треба переписати під ті події чекауту, що існують зараз, а використані змінні Liquid зіставити з їхніми відповідниками в новому payload.
Перевірка на боці отримувача, а не джерела
Піксель, який спрацював, це ще не конверсія, яка дійшла. Дубльовані події покупки, відсутня сума замовлення й розбіжність валют з боку магазину виглядають нормально, а в рекламному кабінеті неправильно. Результат тут це підтвердження в системі-отримувачі, бо тільки там і живе відповідь.
Як це відбувається
Ви надсилаєте вміст поля Additional Scripts або даєте доступ, щоб його прочитали напряму. Безкоштовний інструмент аудиту на цьому сайті дає перший погляд просто в браузері, якщо хочете подивитися самі.
Ви отримуєте письмовий план щодо кожного скрипта: що він робив, що його заміняє, що замінити не вийде і чого це вам коштує.
Заміни збираються на магазині розробки або дублі теми, тож на живому магазині під час роботи нічого не змінюється.
Робляться тестові замовлення, і кожна система-отримувач перевіряється на подію, у правильній валюті, рівно один раз.
Зміна виходить наживо, після чого ті самі перевірки кілька днів ідуть на справжньому трафіку.
Передісторія
Що насправді змінилося в чекауті Shopify
Від одного текстового поля до моделі розширень
Роками поле Additional Scripts було місцем, куди йшло все: аналітика, пікселі, партнерські теги, дрібні правки інтерфейсу. Воно виконувалося як звичайний JavaScript на сторінці статусу замовлення, з доступом до змінних Liquid і DOM. Checkout Extensibility замінює це моделлю пісочниці, де в кожної задачі своє місце: Web Pixels для відстеження, UI-розширення для інтерфейсу, Functions для логіки. Виграш у тому, що сторонній скрипт більше не може зламати чекаут. Ціна в тому, що все написане під стару модель треба перебудувати, а не перенести.
Чому поломка тиха
Коли Additional Scripts перестали виконуватися, не було ні помилки, ні попереджувального банера, ні видимої зміни у вітрині. Замовлення йшли як звичайно. Єдиний симптом був поза Shopify: менше конверсій у Google Ads, відсутні події покупки в Meta, неатрибутовані продажі в партнерських панелях. Smart Bidding і подібні алгоритми продовжують витрачати бюджет на тих даних, які отримують, тому прогалина у відстеженні перетворюється на змарнований бюджет задовго до того, як хтось повʼяже одне з іншим.
Місця, де найчастіше помиляються
Три поломки повторюються з магазину в магазин. Подія покупки спрацьовує двічі, бо і застосунок, і написаний вручну піксель звітують про одне замовлення. Сума замовлення приходить нулем, бо поле з виручкою так і не зіставили в новому payload. Розбіжність валют у мультиринкових магазинах, де чекаут звітує у валюті показу, а рекламна платформа чекає валюту магазину. Усі три зсередини Shopify виглядають нормально, тому перевірка має відбуватися в системі-отримувачі.
Що має лишитися після міграції
Ви отримуєте робоче відстеження і письмовий запис до нього: який скрипт що робив, що його замінило, які прибрали й чому. Більшість магазинів набивали це поле роками і руками кількох агенцій, і з тих, хто лишився, ніхто вже не знає, для чого була половина. Записати це і є те, що не дасть оплатити той самий аудит удруге через два роки.
Суміжні послуги
Описати проєкт
Розкажіть, що є і що має змінитися. У відповідь отримаєте обсяг робіт і ціну, а не запрошення на дзвінок.
Питання
Міграція чекауту: запитання й відповіді
Ні. Скрипти перестали виконуватися, тож втрата вже триває, а не насувається, але нічого не видалено. Поле досі можна прочитати, і в кожного скрипта досі є шлях заміни.
Часто так, і там, де застосунок закриває ваш випадок, вам це скажуть, а не продадуть розробку. Застосунки добре закривають типову аналітику й пікселі. Не закривають вони власну логіку, партнерські постбеки з вашими параметрами і все, що читало змінну, специфічну для вашого магазину.
Минулі дані лишаються як є. Змінюється те, що з дня запуску заміни події знову починають надходити. Там, де події не приходили якийсь період, ця прогалина лишається видимою в рекламній платформі, і її варто підписати, щоб ніхто не прочитав її як падіння результатів.
Вони згортаються 30 червня 2026 і переїжджають у Shopify Functions, а це вже інша робота, ніж міграція пікселів: логіка знижок, доставки й оплати, переписана в середовищі платформи, з адмінкою для налаштування. Часто це той самий проєкт, тому обидві частини оцінюються разом.
Магазин із кількома типовими скриптами зазвичай дні. Магазинам із логікою підписок, кількома партнерськими мережами чи нестандартною поведінкою чекауту потрібно більше, і оцінка приходить разом з аудитом, а не до нього.