Checkout-Extensibility-Migration
Weg von Additional Scripts, ohne Ihr Conversion-Tracking zu verlieren.
Shopify hat Additional Scripts für Nicht-Plus-Shops am 26. August 2026 abgeschaltet, Ruby-Skripte laufen am 30. Juni 2026 aus. Jedes Skript wird seinem Ersatz zugeordnet, ob Web Pixel, UI-Extension oder Function, danach wird das Order-Reporting durchgängig geprüft.
Projektpreis
Angebot auf Basis des Umfangs, mit nach Teilen aufgeschlüsselter Schätzung.
Schicken Sie die Beschreibung, Sie bekommen eine Zahl zurück.
Projekt beschreibenDie Frist ist vorbei und das Tracking stimmt bereits nicht mehr
Additional Scripts liefen auf Nicht-Plus-Shops am 26. August 2026 zum letzten Mal, Shopify Scripts auf Ruby enden am 30. Juni 2026. Sichtbar bricht dabei nichts, und genau das ist das Problem. Bestellungen kommen weiter herein, die Dankeseite lädt, und das einzige Signal ist, dass Google Ads, Meta und Ihr Affiliate-Netzwerk still aufhören, mit Ihren Shopify-Zahlen übereinzustimmen. Bis jemand es bemerkt, haben die Gebotsalgorithmen wochenlang gegen unvollständige Daten optimiert.
Was die Migration umfasst
Eine Inventur dessen, was drinstand
Jedes Skript im Feld wird gelesen und eingeordnet: Analytics, Werbepixel, Affiliate-Postbacks, Abo-Logik, eigene Felder. Manche haben einen offensichtlichen Ersatz, manche sind toter Code einer längst entfernten App, und die Unterscheidung ist der größte Teil der Arbeit.
Der Ersatz, Skript für Skript
Jedes verbleibende Skript wandert dorthin, wo die Plattform es heute erwartet: eine Web-Pixel-Extension fürs Tracking, eine Checkout-UI-Extension für Oberflächenänderungen, eine Function für Rabatt- und Versandlogik, oder ein serverseitiges Ereignis, wenn dem Browser nicht zu trauen ist.
Beleg, dass die Zahlen zurück sind
Eine echte Testbestellung wird ausgelöst und bis zum Ende verfolgt: die Conversion in Google Ads, genau ein nicht doppeltes Kaufereignis in Meta, der Verkauf im Affiliate-Dashboard. Der Checkout läuft jetzt in einer Sandbox, die alten Browser-Tricks greifen nicht mehr, also wird am Ziel geprüft.
Warum es so gemacht wird
Zuordnen statt umkopieren
Altes JavaScript in eine Pixel-Extension zu kleben funktioniert nicht: Die Sandbox hat ein anderes Datenmodell, ein anderes Ereignis-Timing und keinen DOM-Zugriff. Jedes Skript muss gegen die heute existierenden Checkout-Ereignisse neu geschrieben werden, und die genutzten Liquid-Variablen brauchen ihr Gegenstück im neuen Payload.
Am Ziel geprüft, nicht an der Quelle
Ein Pixel, das feuert, ist keine Conversion, die ankommt. Doppelte Kaufereignisse, fehlende Bestellwerte und Währungsabweichungen sehen von der Shop-Seite gut aus und im Werbekonto falsch. Das Ergebnis hier ist die Bestätigung im empfangenden System, denn nur dort steht die Antwort.
Wie es abläuft
Sie schicken den Inhalt des Feldes Additional Scripts oder geben Zugriff, damit er direkt gelesen werden kann. Ein kostenloses Prüfwerkzeug auf dieser Seite gibt Ihnen den ersten Blick im Browser, wenn Sie selbst schauen möchten.
Sie bekommen einen schriftlichen Plan je Skript: was es tat, was es ersetzt, was nicht ersetzbar ist und was Sie das kostet.
Der Ersatz entsteht auf einem Entwicklungsshop oder einer Theme-Kopie, am Live-Shop ändert sich währenddessen nichts.
Testbestellungen werden ausgelöst, und jedes Zielsystem wird auf das Ereignis geprüft, in der richtigen Währung, genau einmal.
Die Änderung geht live, danach laufen dieselben Prüfungen einige Tage gegen echten Traffic.
Hintergrund
Was sich im Shopify-Checkout tatsächlich geändert hat
Von einem Textfeld zu einem Extension-Modell
Jahrelang war das Feld Additional Scripts der Ort für alles: Analytics, Pixel, Affiliate-Tags, kleine Oberflächenänderungen. Es lief als reines JavaScript auf der Bestellstatusseite, mit Zugriff auf Liquid-Variablen und den DOM. Checkout Extensibility ersetzt das durch ein Sandbox-Modell, in dem jedes Anliegen seinen eigenen Platz hat: Web Pixels fürs Tracking, UI-Extensions für die Oberfläche, Functions für Logik. Der Gewinn ist, dass ein fremdes Skript den Checkout nicht mehr kaputt machen kann. Der Preis ist, dass alles für das alte Modell Geschriebene neu gebaut und nicht verschoben werden muss.
Warum der Ausfall lautlos ist
Als Additional Scripts aufhörten zu laufen, gab es keinen Fehler, kein Warnbanner und keine sichtbare Änderung im Shop. Bestellungen liefen normal weiter. Das einzige Symptom lag außerhalb von Shopify: weniger Conversions in Google Ads, fehlende Kaufereignisse in Meta, nicht zugeordnete Verkäufe in Affiliate-Dashboards. Smart Bidding und ähnliche Algorithmen geben weiter aus, egal welche Daten sie bekommen, deshalb wird aus einer Tracking-Lücke verbranntes Budget, lange bevor jemand beides verbindet.
Die Stellen, an denen es schiefgeht
Drei Fehler wiederholen sich über Shops hinweg. Kaufereignisse feuern doppelt, weil App und handgeschriebenes Pixel dieselbe Bestellung melden. Der Bestellwert kommt als null an, weil das Umsatzfeld im neuen Payload nie zugeordnet wurde. Währungsabweichungen in Mehrmarkt-Shops, wo der Checkout in der Präsentationswährung meldet und die Werbeplattform die Shopwährung erwartet. Alle drei sehen von innerhalb Shopifys korrekt aus, weshalb die Prüfung im empfangenden System stattfinden muss.
Was eine Migration hinterlassen sollte
Sie bekommen funktionierendes Tracking und eine schriftliche Aufzeichnung dazu: welches Skript was tat, was es ersetzt hat, welche gestrichen wurden und warum. Die meisten Shops haben dieses Feld über Jahre und mehrere Agenturen gefüllt, und niemand im Haus weiß mehr, wofür die Hälfte davon war. Das aufzuschreiben verhindert, dass dieselbe Prüfung in zwei Jahren erneut bezahlt wird.
Verwandte Leistungen
Eigene Bestellformulare und Checkout-Flows
Ein Checkout in der Form, in der Ihre Kunden tatsächlich bestellen.
Shopify Functions
Rabatt-, Versand- und Zahlungslogik, die die Plattform selbst ausführt.
Analytics und Tracking
GA4, GTM und Pixel, die melden, was wirklich passiert ist.
86 Leistungen
Projekt beschreiben
Sagen Sie, was vorhanden ist und was sich ändern soll. Sie bekommen Umfang und Preis zurück, kein Kennenlerngespräch.
Fragen
Checkout-Migration, gefragt und beantwortet
Nein. Die Skripte laufen nicht mehr, der Verlust ist also laufend statt bevorstehend, gelöscht wurde jedoch nichts. Das Feld lässt sich weiterhin lesen und jedes Skript hat weiterhin einen Ersatzweg.
Oft ja, und wo eine App Ihren Fall abdeckt, hören Sie das, statt eine Umsetzung verkauft zu bekommen. Apps decken die üblichen Analytics- und Pixel-Fälle gut ab. Nicht abgedeckt sind eigene Logik, Affiliate-Postbacks mit eigenen Parametern und alles, was eine shopspezifische Variable gelesen hat.
Vergangene Daten bleiben, wie sie sind. Neu ist, dass ab dem Livegang wieder Ereignisse ankommen. Wo für einen Zeitraum Ereignisse fehlten, bleibt diese Lücke in der Werbeplattform sichtbar und sollte annotiert werden, damit niemand sie als Leistungseinbruch liest.
Die enden am 30. Juni 2026 und wandern zu Shopify Functions, was eine andere Aufgabe ist als die Pixel-Migration: Rabatt-, Versand- und Zahlungslogik in der Plattform-Laufzeit neu geschrieben, mit Admin-Oberfläche zur Konfiguration. Oft ist es dasselbe Projekt, also wird beides zusammen kalkuliert.
Ein Shop mit einer Handvoll üblicher Skripte braucht meist Tage. Shops mit Abo-Logik, mehreren Affiliate-Netzwerken oder eigenem Checkout-Verhalten brauchen länger, und die Schätzung kommt mit der Prüfung statt davor.