Governance in der Retail-/Commerce-Landschaft

Einstieg

Retail-Governance startet nicht bei einem Produkteintrag im Data Catalog. Sinnvoll wird es mit Entscheidungen zu Sortiment, Preis, Verfügbarkeit, Auftrag und Retoure — und den Produkten, die diese Entscheidungen tragen.

Im Mittelpunkt stehen konkrete Fragen: Welche Produktvariante ist verkaufbar? Welcher Preis gilt in welchem Kanal und Zeitraum? Welche Menge kann tatsächlich zugesagt werden? Wann gilt ein Auftrag als geliefert oder retourniert? Und welche Einwilligung erlaubt eine erneute Marketingansprache?

Wenn Produktdatenstatus, Preisversion und verfügbare Menge auseinanderlaufen, nimmt der Shop Bestellungen an, die das Verteilzentrum nicht liefern kann. Finance bucht Bruttowarenwert, den Retouren später wieder auflösen. Merchandising pflegt den Produktstamm, Pricing überschreibt die aktuelle Preiszeile, Supply Chain hält ein paralleles Spreadsheet. Das Problem ist nicht das Channel-Dashboard. Es ist der fehlende Vertrag zwischen SKU, Preisversion, Verfügbarkeit und Auftrag.

Gute Retail-Governance macht Kanalversprechen ausführbar — Preis, Verfügbarkeit und Auftrag am selben SKU-Identifier, nicht am neuesten Shop-Feed.

Verwandte Landschaften: Sales, Marketing, Finance.

Die Serie Governance in der Retail-/Commerce-Landschaft gibt dir den Einstieg und den roten Faden. Die folgenden Teile vertiefen Product/Price, ATP, Order/Returns und Consent so, dass Zweck, Rollen, Entscheidungen und Nachweise im Alltag nachvollziehbar bleiben.

Ausgangslage

Der Shop zeigt die Variante als lieferbar. Das Verteilzentrum meldet aber keine verfügbare Menge, weil Sicherheitsbestand und Reservierungen fehlen. Die Pricing-Engine hat eine andere Preisversion als der Shop. Der Auftrag läuft durch, Finance übernimmt die erfüllte Bestellung als Umsatz, die Retoure kommt ohne Einwilligung für erneutes Marketing zurück. Ohne Produkt-/Preisvertrag, Verfügbarkeitsregel und Order-zu-Finance-Grenze stehen drei Wahrheiten nebeneinander. Teams kaufen dann ein Produktdaten- oder Auftragsmodul oder taggen den Katalog — und Channel-Reporting bleibt unverbindlich.

Was diese Serie klärt

• Orientierung: Product/Price, Verfügbarkeitsmeldung/Inventory-Wahrheit, Order/Fulfillment/Returns, Consent/Produktfreigabe — vier Schnitte, keine „Retail-Datenbank“
• Vertiefung: Produkt- und Preis-Vereinbarungen — Master, Status und Preisversion binden
• Bestand: Verfügbarkeitsmeldung-Zählebene an SKU, Location und Kanal, getrennt vom Display-Flag
• Auftrag: Fulfillment- und Returns-Evidenz, bevor Finance bucht
• Abschluss: Consent, Promo und Attribution als Handoff an Marketing und Finance

Begriffe vor dem Lesen

• SKU / Variante — eindeutig identifizierte verkaufbare Ausprägung eines Produkts, etwa ein T-Shirt in einer bestimmten Farbe und Größe. SKU steht für „Stock Keeping Unit“.
• Preisversion — wirksamer Betrag mit Kanal, Währung, Gültigkeit von/bis und Tax-Flag — nicht „der letzte Import“.
• On-hand — physisch gezählte Menge an einer Location. Verfügbar (Display) — was der Kanal anzeigt. Beides ist nicht Verfügbarkeitsmeldung.
• ATP / zusagefähige Menge — die Menge, die nach Reservierungen, Sicherheitsbestand und erwarteten Zu- und Abgängen einem Kunden versprochen werden kann. ATP steht für „Available to Promise“.
• Consent — nachweisbare Einwilligung für Zweck und Kanal (Tracking, Promo, Remarketing) — kein stilles Pixel.
• Produktfreigabe / Attribution — welche Aktion welchem Touch und welchem Consent zugeordnet wird, bevor Marketing oder Finance die Zahl übernimmt.
• PIM / OMS — Systeme für Produktinformationen beziehungsweise Auftragsverwaltung. PIM steht für „Product Information Management“, OMS für „Order Management System“.

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt SKU-, Kanal-, System- und Toolnamen durch eure Catalog-, PIM-, OMS- und Prozessquellen.

Konzept halten — Last-Säulen: KPI und Verantwortung tragen diese Kette; PII ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.

Orientierung — ATP und Preis ohne OMS zu übernehmen

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Produkte und Entscheidungen

Retail braucht nicht „eine Commerce-Datenbank“, sondern geschnittene Produkte.

Product- und Preis-Produkt

Dieses Produkt beschreibt:

• Product-/Variant-ID; Status (draft, active, seasonal, discontinued); Kanal-Publish getrennt vom fachlichen Lebenszyklus; Preisversion (Betrag, Währung, Kanal, Gültigkeit, Tax-Flag); Freigeber für Markdown und Override.

Entscheidungen:

• Welches Zählebene ist verkaufbar (SKU/Variant, nicht nur Style)?; Wer darf Master-Status und Preisversion schließen oder überschreiben?; Wann darf ein Kanal publishen — erst nach gültiger Preisversion?

ATP- und Inventory-Wahrheit

ATP ist kein Display-Flag. Es ist zusagefähige Menge plus Durchsetzung.

Es benötigt:

• SKU; Location (DC, Store, Dropship); Kanal; On-hand; Reservierung; Safety Buffer; Lead Time; Zeitpunkt der Wahrheit; verantwortliche Person für Overpromise-Stop.

Entscheidungen:

• Welche Quelle ist führend für On-hand gegenüber Verfügbarkeitsmeldung?; Welcher Buffer gilt je Kanal?; Wer darf Overpromise erlauben — und mit welchem Ablauf?

Order-, Fulfillment- und Returns-Produkt

Order-Status ist nicht gebuchter Umsatz. Fulfillment und Retoure brauchen eigene Evidenz.

Entscheidungen:

• Wann darf fulfilled, cancelled oder returned gesetzt werden?; Welche Evidenz (Pick, Ship, Proof of Delivery, Return-Reason) ist Pflicht?; Wie werden Teillieferung, Restock und Gutschrift vom Auftrag getrennt?

Consent- und Promotion-Produkt

Attribution ohne Consent ist Marketing-Theater. Der Handoff an Marketing und Finance braucht Zweck und Version.

Entscheidungen:

• Welcher Consent-Zweck gilt für Tracking, Promo und Remarketing?; Welche Produktfreigabe-ID und welches Attribution-Fenster sind verbindlich?; Wer darf eine Kampagnenzahl an Finance übergeben?

Wo Governance hängt

Zwischen PIM-Status und Shop-Publish

„Active im PIM“ ist nicht „sichtbar im Shop“. Ohne getrenntes Publish-Attribut entscheidet der letzte Import, was Kunden sehen.

Zwischen Listenpreis und Kanal-Preisversion

Brutto, Aktionsnetto und Analytics-Import dürfen nicht unter „Preis“ verschmelzen. Ohne Version und Gültigkeitsfenster ist Margin nicht auditierbar.

Zwischen Bestand, Anzeige und Verfügbarkeit

Ein Feld „verfügbar“ versteckt Sicherheitsbestand, Reservierung und Kanalregeln. Der Shop verspricht mehr, als das Verteilzentrum liefern kann.

Zwischen Auftragsstatus und Umsatz

Erfüllte Bestellung, Rechnung, gebuchter Umsatz und Zahlungseingang sind verschiedene Kennzahlen. Bruttowarenwert ohne Retourenreserve ist keine saubere Finance-Übergabe.

Zwischen Kampagnenzuordnung und Einwilligung

Ein Kampagnen-Tag ohne Einwilligungsnachweis und Zweck bindet weder Marketing-Automation noch Aufsichtsfragen.

Zwischen PIM/OMS-Admin und fachlicher Auslegung

Wer Validation Rules setzen kann, darf nicht Sortiment, Preispolitik oder ATP-Buffer entscheiden.

Rollen-Mapping

Data Owner (Category / Merchandising und Pricing)

Der Category- oder Merchandising-Owner ist accountable für Sortiment, Product-Zählebene und erlaubte Kanäle. Der Pricing Owner ist accountable für Preisversion, Markdown und akzeptables Margenrisiko. Beide entscheiden nicht die Warehouse-Modellierung und nicht die OMS-Konfiguration.

Data Steward

Retail Operations oder Merchandising Operations triagiert DQ-Issues, überwacht Preisversionen und ATP-Brüche, dokumentiert Overpromise-Ausnahmen und eskaliert Konflikte zwischen Shop-Feed und WMS.

Data Product Owner

Priorisiert Product/Price-Feed, ATP-Produkt, Order/Returns-Index und Consent-Handoff. Nutzen und Lieferbarkeit — nicht die Preispolitik.

Data Architect

Schützt SKU-/Variant-Zählebene, Join über Location und Kanal, Historie von Preis und ATP, Lineage Shop ← PIM/OMS/WMS und nicht abwärtskompatible Änderungs an Channel-Schnittstellen.

Data Custodian

PIM-Admin, OMS-Admin, WMS- und Integrationsbetrieb setzen Validierung, Publish-Jobs, Rechte und Feeds um. Konfigurationsmacht ist keine Sortiments- oder ATP-Hoheit.

Data Consumer

Shop und Marketplace, Supply-Chain-Planung, Store Operations, Marketing, Finance, Customer Service. Abweichungen laufen über denselben Intake — keine stillen Spreadsheet-ATP- oder Preislisten.

Supply Chain für ATP

Der Supply-Chain- oder Inventory-Owner ist fachlich accountable für ATP-Formel, Buffer und Overpromise-Stop. Der WMS-Admin bleibt Custodian.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

Mini-Fall

Alltagssituation: Während einer Rabattaktion steht eine Produktvariante im Shop auf „lieferbar“, obwohl das Verteilzentrum keinen verfügbaren Bestand meldet. Der Shop zeigt noch Preise der Vorwoche. Bestellungen laufen trotzdem durch, Finance bucht den Bruttowarenwert, und Retouren landen später wieder in Marketing-Auswertungen.

Was schiefläuft: Shop, Lager, Finance und Marketing nutzen dieselbe Bestellung für unterschiedliche Zwecke, aber ohne gemeinsame Version für Preis, Bestand und Zustimmung. Eine OMS-Lizenz löst das nur, wenn diese Übergaben sauber vereinbart sind.

Vereinbarung: Product-ID, Veröffentlichungsregel, Preisversion, Kanal und Gültigkeit werden zusammen geführt. Die Verfügbarkeitsmeldung beschreibt Standort, Kanal und Puffer. Bei null verfügbarem Bestand stoppt die Bestellung. Finance bekommt die erfüllte Bestellung, Marketing nur Daten mit passendem Consent-Zweck.

Kritische Übergaben

Anti-Patterns

• Catalog-Einträge als Governance-Nachweis behandeln
• PIM- oder OMS-Admin zum Data Owner machen
• „Verfügbar“ und Verfügbarkeitsmeldung unter einem Feld führen
• Order-Status still mit gebuchtem Umsatz gleichsetzen
• Produktfreigabe-Attribution ohne Consent-Vereinbarung
• Aktuelle Preiszeile überschreiben statt versionieren
• Channel-Alias ohne Mapping zu SKU und Location

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes
• Functions Hub — Retail & Commerce

Lege Tag 1–20 als ersten Slice in den Plan. Spätere Arbeiten bleiben in derselben Instanz. Erster Kontakt für Hüte: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Einen laufenden Kanal wählen (Shop oder Marketplace). SKU-Stichprobe, wirksame Preisversion, On-hand, Display-Flag und ATP aufnehmen. Vier Produkte benennen: Product/Price, ATP, Order/Returns, Consent/Promotion. Owner und Steward mappen — PIM/OMS-Admin nur als Custodian.

Schritt 2: Control und Nachweis umsetzen

Einen Preisversions-Contract und einen ATP-Contract produktiv schalten. Negativtest: Shop-Publish bei ATP null oder fehlender Preisversion muss fehlschlagen. Offene Orders und die wirksame Preisversion inventarisieren.

Schritt 3: Testen und Ausnahmen sichtbar machen

Order-zu-Finance-Handoff (fulfilled ≠ booked) und eine Returns-Evidenz durchspielen. Consent-Zweck an einer Promotion binden. Eine Overpromise-Ausnahme mit Ablauf und Freigeber dokumentieren.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Preisversion, ATP-Stop, Revenue-Grenze, Consent) auf einen zweiten Kanal oder eine zweite Brand übertragen.

Exit-Kriterien

• Product/Price hat Zählebene, Status, Preisversion und verantwortliche Person.
• Verfügbarkeitsmeldung nennt Location, Kanal und Buffer — nicht nur On-hand.
• Order-Status und gebuchter Umsatz sind getrennte Entscheidungen.
• Consent und Produktfreigabe-Attribution haben Zweck und Version.
• technischer Betreiber liefert Konfigurationsnachweis (Validierung, Feed, Job) ohne mündliche Brücke.

Weiterlesen

• Governance in der Sales-Landschaft
• Governance in der Marketing-Landschaft
• Governance in der Finance-Landschaft
• KPI-Definition, Verantwortung und Versionierung
• Governance über Funktionen hinweg
• Rollen-Hub

Ein PIM-Datensatz ist noch kein Vertrag. Pricing scheitert, wenn „Listenpreis“ in einem Kanal Bruttopreis, in einem anderen Aktionsnetto und in Analytics der letzte Import ohne Version bedeutet. Spätere Margin- und Promo-Fragen haben nichts zum Vergleichen.

Dieser Teil definiert den Mindestvertrag für Product Master und Preisversionen — bevor Verfügbarkeit und Orders darauf aufsetzen.

Ansatz

Jedes materielle Verkaufsprodukt erhält vor Channel-Publish und Preis-Reporting:

1. eine Product-/Variant-ID mit einer verbindlichen Zählebene (SKU/Variant, nicht nur Style);
2. einen Status-Contract (draft, active, seasonal, discontinued) mit erlaubten Übergängen;
3. einen Preisversions-Contract (Betrag, Währung, Kanal, Gültigkeit von/bis, Tax-Flag);
4. einen Data Owner für Sortiment/Preispolitik und einen Steward für Triage;
5. einen Freigabeweg für Preisänderungen inkl. Ausnahme und Ablaufdatum.

Kein Channel-Preis ohne referenzierbare Version.

Pricing-Workflow

1. Master-Zählebene festlegen

Owner beschließt, was verkaufbar ist: Variant mit Attributen, nicht ein Style-Aggregat als Pseudo-SKU. Bundles und Kits bekommen eigene Regeln.

2. Status und Publish trennen

„Active im PIM“ ist nicht „sichtbar im Shop“. Publish-Status und fachlicher Lebenszyklus bleiben getrennte Attribute mit Steward-Kontrolle.

3. Preisversionen schreiben

Jede wirksame Preiszeile trägt Version-ID, Gültigkeitsfenster und Kanal. Überschreiben der aktuellen Zeile ohne Historie zerstört Margin-Analysen und Audit.

4. Controls und Ausnahmen

Blockierend: Preis ohne Währung, überlappende Versionen im selben Kanal, Publish ohne Master-Status. Warnend: große Sprünge ohne Begründung. Ausnahmen brauchen Freigeber.

5. Custodian umsetzen

Custodian setzt Validation in PIM/Pricing-Engine um. Fachliche Semantik bleibt beim Owner — Konfigurationsmacht ist keine Accountability.

Handoffs

Anti-Patterns

• Aktuellen Preis überschreiben und Historie „später“ nachbauen
• Listenpreis, Aktionspreis und Cost unter einem Feld mischen
• Regionale Preise ohne Kanal- und Gültigkeitsattribut
• Catalog-Beschreibung als Freigabenachweis nutzen
• technischer Betreiber entscheidet fachliche Preispolitik

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Ein Kernsortiment wählen und Zählebene (Style vs. Variant) schriftlich fixieren.
2. Preisversionen für einen Kanal historisieren und Overlaps finden.
3. Publish-Status vom fachlichen Status trennen und Control scharf stellen.
4. Ausnahmeweg für Notfall-Preise mit Ablaufdatum testen.

Ein Bestandswert im WMS ist noch kein Vertrag. Availability scheitert, wenn „auf Lager“ physischen Stock, verkaufbare Menge und Channel-Anzeige vermischt. Spätere Fulfillment-, Oversell- und SLA-Fragen haben nichts zum Joinen.

Dieser Teil trennt Zählebene des Bestands, Availability und ATP — bevor Orders und Returns darauf zählen.

Ansatz

Jeder materielle Bestandsausschnitt erhält vor Channel-Anzeige und Order-Promise:

1. ein Zählebene des Bestands (SKU/Variant + Location + Stock-Type);
2. getrennte Maße für physischen Bestand, reserviert und ATP/Availability;
3. einen Channel-Truth-Contract (welche Quelle der Shop liest, Refresh-SLA);
4. einen Data Owner für Bestands-/Promise-Politik und einen Steward für Triage;
5. eine Oversell-/Ausnahme-Regel mit Freigeber und Ablaufdatum.

Kein „verfügbar = true“ ohne referenzierbares Zählebene.

Availability-Workflow

1. Zählebene und Stock-Types

Owner legt fest: Location (DC, Store, Dropship), Stock-Type (sellable, damaged, quarantine). Mischungen in einem Zähler sind verboten.

2. Availability vs. ATP

Availability kann Channel-Policy sein (Puffer, Cut-off). ATP ist die rechnerische verkaufbare Menge. Beide brauchen eigene Felder und Definitionen — siehe auch Order-Contracts.

3. Channel-Truth

Welches System ist autoritativ für den Shop? Steward dokumentiert Quelle, Latenz und Fallback. Catalog-Beschreibung ersetzt keinen Sync-Contract.

4. Controls

Blockierend: negative ATP ohne Ausnahme, Publish ohne Location-Zählebene, Channel liest Staging. Warnend: Drift zwischen WMS und OMS über Schwelle.

5. Custodian betreibt Sync

Custodian überwacht Jobs, Rechte und Monitoring. Promise-Politik bleibt beim Owner.

Handoffs

Anti-Patterns

• „Available“ und Verfügbarkeitsmeldung in einem Boolean
• Store- und DC-Bestand ohne Location addieren
• Channel-Cache als System of Record behandeln
• Oversell still in Excel korrigieren
• Catalog-Tag „in stock“ als Audit-Nachweis

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Ein Location- und Stock-Type-Modell für ein DC schriftlich fixieren.
2. ATP und Channel-Anzeige für 20 SKUe vergleichen und Drift messen.
3. Autoritative Quelle für einen Shop-Kanal benennen und SLA setzen.
4. Eine Oversell-Ausnahme mit Freigeber und Ablauf testen.

Ein OMS-Status ist noch kein Vertrag. Order-Governance scheitert, wenn „shipped“ Versandereignis, Kundennachricht und Revenue-Event vermischt. Spätere Finance-, Service- und Dispute-Fragen haben nichts zum Joinen.

Dieser Teil definiert Contracts für Order, Fulfillment und Returns — inkl. Evidenz und Abgrenzung zu Finance Close.

Ansatz

Jeder materielle Auftrag erhält vor Fulfillment-Reporting und Finance-Handoff:

1. eine Order-ID mit Zählebene (Order Header / Line klar getrennt);
2. einen Stage-Contract für Order, Fulfillment und Return (Bedeutung, Evidenz, erlaubte Vorgänger);
3. eine Statushistorie (wer wechselte wann welchen Status);
4. einen Data Owner für Order-Politik und einen Steward für Triage;
5. einen Übergabe-Contract an Payment/Finance (was ist kommerziell abgeschlossen vs. gebucht).

Kein Statuswechsel ohne die im Contract benannte Evidenz.

Order-Lifecycle-Workflow

1. Zählebene und Identitäten

Header und Line, Channel, Customer-Key und Payment-Reference müssen joinbar sein. Split-Shipments und Partial Captures brauchen eigene Regeln.

2. Stages und Evidenz

Evidenz ist prüfbar: Payment Auth, Pick Confirm, Carrier Scan, Delivery Proof, Return Receipt, Refund Instruction. Häkchen ohne Artefakt zählen nicht.

3. Returns binden

Return Line referenziert Original Order Line. Gründe, Disposition (restock, scrap) und Refund-Status bleiben getrennte Attribute.

4. Controls und Ausnahmen

Blockierend: Ship ohne Auth, Refund ohne Return-Evidence, Status ohne Historie. Stornos und Kulanz brauchen Freigeber und Ablauf.

5. Handoff zu Finance

OMS bestätigt operativen Abschluss. Finance entscheidet Recognition — analog Sales Closed Won. Catalog-Tags ersetzen keinen Contract.

Handoffs

Anti-Patterns

• „Shipped“ mit Revenue gleichsetzen
• Returns ohne Link zur Original Line
• Status nur aktuell speichern, Historie löschen
• Partial Fulfillment improvisieren ohne Zählebene
• technischer Betreiber entscheidet Kulanzpolitik

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Fünf kritische Gates mit je einem Evidenz-Artefakt definieren.
2. Statushistorie für Orders und Returns verifizieren.
3. Eine Refund-Kette Order→Return→Payment end-to-end nachziehen.
4. Finance-Handoff-Felder und Owner schriftlich freigeben.

Ein Promo-Code im Checkout ist noch kein Vertrag. Attribution scheitert, wenn Rabatt, Kampagnen-Credit und Consent in einem Freitextfeld landen. Spätere Marketing-ROI- und Finance-Margin-Fragen haben nichts zum Joinen.

Dieser Teil bindet Consent, Promotion und Attribution — mit Handoffs zu Marketing Consent und Finance.

Ansatz

Jede materielle Promo- und Attribution-Nutzung erhält vor Audience-Credit und Margin-Reporting:

1. eine Promo-ID (Code/Campaign) mit Gültigkeit, Kanal und Stacking-Regel;
2. einen Consent-/Zweck-Bezug, wenn personenbezogene Aktivierung oder Retargeting folgt;
3. einen Attribution-Contract (Modell, Fenster, Last-touch vs. vereinbarte Regel);
4. einen Data Owner für Promo-Politik und einen Steward für Triage;
5. getrennte Handoffs an Marketing (Credit) und Finance (Discount/Margin) — keine stille Doppelzählung.

Kein Attribution-Export ohne diese fünf.

Promo-Attribution-Workflow

1. Promo schneiden

Codes referenzieren Campaign/Purpose, nicht umgekehrt. Stacking, Ausschlüsse und Max-Discount stehen im Contract.

2. Consent vor Aktivierung

Wenn Order- oder Customer-Daten Marketing-Audiences speisen, gilt der Marketing-Consent-Contract. Retail erfindet keinen parallelen Opt-in — siehe Marketing-Landschaft.

3. Attribution versionieren

Modell und Fenster sind versioniert. Nachträgliche Neuberechnung braucht Owner-Freigabe und Snapshot der alten Version.

4. Finance-Abgrenzung

Discount auf Order Line ist operativ. Margin- und Revenue-Wirkung folgen Finance-Semantik — Catalog-Labels ersetzen keinen Handoff.

5. Controls

Blockierend: Attribution ohne Promo-ID, Marketing-Sync ohne Consent, doppelter Credit an zwei Owner. Ausnahmen mit Ablaufdatum.

Handoffs

Anti-Patterns

• Promo-Code als Consent behandeln
• Last-touch still überschreiben ohne Version
• Marketing und Finance denselben „Revenue from promo“-Wert ohne Vereinbarung teilen
• Catalog-Kampagnenseite als Freigabenachweis
• technischer Betreiber setzt Attribution-Modell fachlich fest

Erster Umsetzungsschnitt

Dieser Einstieg ist ein Arbeitsmuster, keine Kalenderübung und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für verantwortliche Personen, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Extended Domain Landscapes
• Lernpfad — Extended Domain Landscapes

Starte mit dem kleinsten echten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Zehn aktive Promo-Codes auf Contract-Felder mappen (Gültigkeit, Stacking).
2. Einen Marketing-Sync-Pfad auf Consent-Check prüfen und Lücken schließen.
3. Attribution-Modell und Fenster für ein Quartal versionieren.
4. Discount-Handoff-Felder mit Finance Owner abstimmen.

Weiterlesen

• Marketing-Landschaft
• DSGVO Foundations