Ein einziges Datumsfeld, mehr Ärger erspart als manche App. Mit der API-Version 2026-10 erhält das Customer-Objekt in Shopify Functions ein neues Feld: createdAt. Es liefert Datum und Uhrzeit, zu der ein Kundenkonto angelegt wurde. Keine Migration nötig, keine Breaking Changes — bestehende Functions laufen unverändert weiter. Wer das als Randnotiz abhakt, übersieht, was hier eigentlich passiert: Shopify verlagert einen zentralen Teil der Kundenlogik dorthin, wo er hingehört. In den Checkout.
Bisher war das Kontoalter für Functions praktisch unsichtbar. Eine Function sah im GraphQL-Input, wer der Kunde ist, welche Tags er trägt, in welchen Segmenten er steckt — aber nicht, seit wann es ihn gibt. Wer Rabatte davon abhängig machen wollte, ob ein Konto frisch oder alt ist, musste diese Information vorher als Metafield oder Tag einschleusen. Das bedeutete: eine App, ein Cronjob, ein Webhook auf customers/create, ein Schreibvorgang pro Kunde. Viel Infrastruktur für eine simple Frage.
Jetzt reicht ein Vergleich im Function-Code. createdAt gegen die aktuelle Zeit, Schwellwert definieren, fertig. Die Änderung ist additiv, der Aufwand minimal — die Implikationen für die Rabattstrategie sind es nicht.
Was bedeutet createdAt in Shopify Functions konkret?
Die Antwort in einem Satz: Functions können ab API-Version 2026-10 das Erstellungsdatum eines Kundenkontos direkt in ihrer Logik auswerten, etwa um Rabatte, Versandregeln oder Payment-Optionen vom Kontoalter abhängig zu machen.
Technisch ist das unspektakulär. Das Feld erscheint im Input-Schema des Customer-Objekts, lässt sich über die GraphQL-Query der Function abrufen und liefert einen Zeitstempel. Ausgewertet wird er innerhalb der üblichen Grenzen von Functions: wenige Millisekunden Laufzeit, keine Netzwerkaufrufe, deterministische Ausgabe. Ein Datumsvergleich passt perfekt in dieses Modell — er ist billig, schnell und braucht keinen externen State.
Spannend wird es einen Schritt weiter. Shopify baut die Functions-Plattform seit zwei Jahren konsequent zu dem Ort aus, an dem Preis- und Checkout-Logik nativ läuft: Discount Functions, Delivery Customizations, Payment Customizations, Cart Transforms. Jedes neue Feld im Input-Schema erweitert den Entscheidungsraum dieser Logik, ohne dass Händler eine zusätzliche App brauchen. createdAt ist ein weiteres Stück dieser Strategie — und ersetzt eine der häufigsten Workaround-Konstruktionen im App-Ökosystem.
Warum ist das Kontoalter im Checkout so wertvoll?
Weil es drei Probleme gleichzeitig adressiert, die deutsche Händler teuer zu stehen kommen.
Das erste heißt Gutschein-Arbitrage. Jeder Shop mit einem 10-Prozent-Newsletter-Code kennt das Muster: Kunde legt mit einer Wegwerf-Mail ein zweites, drittes, fünftes Konto an und löst den Neukundenrabatt mehrfach ein. Die Erkennung solcher Muster lief bislang meist nachträglich — über Fraud-Analysen, manuelle Listen oder App-Logik, die nach dem Kauf griff. Mit createdAt kann eine Discount Function den Rabatt schon im Checkout verweigern, wenn das Konto jünger ist als ein definierter Schwellwert. Die Entscheidung fällt vor der Bestellung, nicht danach.
Das zweite Problem ist die Treue-Logik. Viele Händler wollen Bestandskunden belohnen — Staffelpreise ab dem ersten Jahr, Sonderkonditionen für Kunden seit Tag eins. Bisher musste dieses „Kunde seit“ als Tag gepflegt werden, mit allen Fehlerquellen, die manuelle oder cron-gestützte Tag-Pflege so mit sich bringt. Ein Kunde, dessen Tag fehlt, bekommt seinen Rabatt nicht und beschwert sich. Ein Kunde, dessen Tag falsch gesetzt ist, bekommt ihn zu Unrecht. Beides kostet: Marge oder Vertrauen.
Das dritte Problem betrifft den DACH-Markt spezifisch: Kauf auf Rechnung. Payment Customizations können mit createdAt die Rechnungsoption für nagelneue Konten ausblenden. Angesichts dessen, dass Rechnungskauf hierzulande nach wie vor zu den beliebtesten Zahlarten gehört — und zugleich zu den ausfallanfälligsten — ist das ein Hebel, den Risk-Teams bisher nur über externe Bonitäts-Apps hatten. Eine einfache Regel wie „Rechnung erst ab 30 Tagen Kontobestand oder ab zweiter Bestellung“ lässt sich jetzt als Function formulieren, ohne dass ein externer Dienst jeden Checkout anfassen muss.
Welche Szenarien werden damit praktisch umsetzbar?
Drei Beispiele zeigen die Bandbreite — von einfach bis anspruchsvoll.
Ein Fashion-Händler mit aggressivem Neukunden-Rabatt begrenzt die Einlösung auf Konten, die maximal 48 Stunden alt sind und deren erste Bestellung im Warenkorb liegt. Der Rabatt wird zu dem, was er sein soll: ein Akquise-Instrument mit Verfallsdatum, kein Dauer-Abonnement für Serien-Anmelder.
Ein B2B-Händler auf Shopify kombiniert createdAt mit Company- und Metafield-Daten: Neukunden erhalten in den ersten 60 Tagen Vorkasse und Kreditkarte, danach öffnet sich der Rechnungskauf mit Zahlungsziel. Was bisher ein Vertriebsmitarbeiter manuell im Kundenkonto umstellte, läuft jetzt als Regel im Checkout.
Ein Beauty-Shop mit Replenishment-Modell staffelt seine Rabatte: Kunden im ersten Jahr bekommen fünf Prozent auf Nachbestellungen, ab dem zweiten Jahr acht. Die Function liest createdAt, berechnet das Kontojahr, wählt die Kampagne. Kein Segmente-Sync, keine veralteten Tags.
Der eigentliche Gewinn liegt nicht im Feld selbst, sondern darin, dass Entscheidungen über Rabatte und Zahlarten dort getroffen werden, wo sie hingehören: in Echtzeit, im Checkout, ohne externen Roundtrip.
Wo die Grenzen liegen — und was Händler falsch erwarten
So nützlich das Feld ist: Es ersetzt keine Kundenhistorie. createdAt sagt, wann das Konto angelegt wurde — nicht, wann der Kunde das erste Mal gekauft hat. Diese zwei Zeitpunkte können Monate auseinanderliegen. Ein Gast-Käufer, der drei Jahre bestellt und sich erst jetzt registriert, hat ein frisches Konto und eine lange Historie. Wer seine Treue-Logik allein auf das Kontoalter stützt, bestraft genau diese Kunden. Für echte Loyalitäts-Staffelungen bleibt die Bestellhistorie — über Order-Count-Felder oder Segmentierung — die verlässlichere Quelle. createdAt ergänzt sie, es ersetzt sie nicht.
Zweite Grenze: Guest Checkout. Ohne Kundenkonto gibt es kein Customer-Objekt und damit kein Datum. Ein erheblicher Teil des Traffics — je nach Branche 30 bis 60 Prozent — läuft daran vorbei. Regeln auf Basis von createdAt brauchen also immer ein sauberes Default-Verhalten für Gäste.
Dritte Grenze ist organisatorischer Natur. Functions laufen auf Shopify Plus nativ, über Apps auch auf kleineren Plänen. Händler ohne Plus sind auf App-Anbieter angewiesen, die das neue Feld in ihren Discount- oder Payment-Apps ausspielen. Das wird kommen — die Änderung ist trivial zu implementieren —, aber es dauert, bis es in den gängigen App-UIs als konfigurierbare Regel auftaucht.
Was Händler jetzt konkret tun sollten
Plus-Händler mit eigenen Functions haben den kürzesten Weg: API-Version in der Function-Konfiguration auf 2026-10 heben, das Feld ins Query-Schema aufnehmen, eine Regel bauen. Ein guter erster Kandidat ist die Neukunden-Rabatt-Absicherung, weil dort der Missbrauchsschaden direkt messbar ist.
Alle anderen sollten zwei Dinge prüfen. Erstens: Welche Logik in den eigenen Discount-Apps basiert heute auf Tags, die eigentlich Kontoalter abbilden? Diese Konstrukte sind Kandidaten für eine sauberere Lösung — sobald die App-Anbieter das Feld unterstützen, lohnt eine Nachfrage beim Support oder ein Blick in die Changelogs. Zweitens: lohnt es sich, die Rechnungskauf-Freigabe an das Kontoalter zu koppeln? Wer mit Zahlungsausfällen durch Neukunden kämpft, hat hier einen risikoarmen Hebel, der keine Bonitätsprüfung braucht und keinen Rechtsrahmen berührt.
Und der größere Kontext: Shopify rüstet das Function-Input-Schema Schritt für Schritt mit genau den Kundendaten aus, die Pricing-Logik braucht. Metafelder, Tags, Segmente, jetzt das Kontoalter. Die Richtung ist unmissverständlich — der Checkout wird zur programmierbaren Fläche, und die App-Schicht davor dünnt aus. Wer seine Rabatt- und Payment-Strategie heute noch als Sammlung von App-Konfigurationen denkt, sollte anfangen, sie als Regelwerk zu begreifen. Denn genau das ist es, was Functions am Ende abbilden: Regeln, versioniert, testbar, schnell. createdAt ist ein kleines Feld. Das Muster dahinter ist es nicht.