Analyse und Verlaufsdaten für Prognosen migrieren

Die meiste Angst vor dem Verlust der Analytics ist unbegründet

Spricht mich jemand auf den Umzug von einer gemieteten Plattform an, kommt die Frage nach den Analysedaten fast immer mit echter Sorge. Jahre an Dashboards, Heatmaps, Conversion Funnels und Zugriffskurven, dazu die leise Überzeugung, am Umstellungstag verschwinde alles davon. Die Sorge kann ich gut verstehen, nur zielt sie meist auf das Falsche.

Die ehrliche Fassung geht so: Die Daten, die wirklich die Nachfrage prognostizieren und Entscheidungen tragen, sind deine Transaktionsdaten, also Bestellungen, Kunden und Katalog. Diese Daten gehören dir, sie wandern sauber in einen eigenen Shop, und sie sind der eigentliche Treibstoff jeder Prognose. Das meiste, was Leute "unsere Analytics" nennen, liegt in Werkzeugen von Drittanbietern, ist aggregiert, gesampelt oder in der Aufbewahrung begrenzt und war nie wirklich übertragbar. Die Aufgabe ist nicht, alles davon zu migrieren. Die Aufgabe ist, für jede Quelle zu entscheiden, was du behältst, was du als Momentaufnahme für die Akte sicherst und was dir künftig egal sein darf.

Dieser Artikel ist genau diese Sortierarbeit. Er ist ein Speichenartikel zur Säule was sich übertragen lässt und was nicht, und er stützt sich auf die Speiche zur Bestell und Kaufhistorie, weil dort der Treibstoff für die Prognose tatsächlich liegt.

Drei Arten von Daten, und wie übertragbar jede ist

Fast alles, was ein Shop "Daten" nennt, fällt in einen von drei Töpfen, und die drei verhalten sich beim Umzug völlig unterschiedlich.

Der erste Topf sind deine eigenen Transaktionsdaten: Bestellungen mit ihren Positionen und Datumsangaben, Kunden und ihre Adressen, Produkte, Preise, Lagerbewegungen, Rückgaben. Die gehören ganz dir. Heute liegen sie in der Datenbank der Plattform, morgen in deiner eigenen Datenbank im neuen Shop. Das ist der Topf, der prognostiziert und entscheidet, und ausgerechnet um ihn sorgen sich die Leute am wenigsten, was verkehrt herum ist.

Der zweite Topf ist die Analytik von Drittanbietern: Webanalyse wie Google Analytics 4, dazu Heatmaps und Werkzeuge zur Sitzungsaufzeichnung. Die Berichte fühlen sich an wie deine, aber der rohe Ereignisstrom dahinter gehört dem Werkzeug, nicht deinem Shop, und bis du ihn erreichst, ist er meist aggregiert, gesampelt oder in der Aufbewahrung begrenzt. Diese Historie migrierst du nicht. Du behältst das Werkzeug über den Umzug hinweg und richtest es auf den neuen Shop, und von den wenigen Berichten, auf die du dich verlässt, machst du eine Momentaufnahme.

Der dritte Topf ist die plattformeigene Analytik: die eingebauten Dashboards von Shopify, WooCommerce, Magento und dem Rest. Das sind bequeme Ansichten, berechnet aus deinen Transaktionsdaten. Ein Dashboard migrierst du nicht. Sobald deine Transaktionsdaten im eigenen Shop liegen, baust du bessere Ansichten darauf neu auf, und die gehören dir.

Wer diese drei Töpfe auseinanderhält, für den hört die Migration auf, beängstigend zu sein, und wird zu einer Liste von Entscheidungen.

Was Webanalyse wirklich enthält, und was du mitnehmen kannst

Google Analytics 4 ist das klarste Beispiel, weil die eigene Dokumentation genau sagt, wie wenig davon wirklich deins zum Mitnehmen ist.

Fang bei der Lebensdauer an. In einer Standard Property von GA4 kannst du die Aufbewahrung von Ereignis und Nutzerdaten auf 2 Monate oder 14 Monate stellen, länger nicht. Die Fenster von 26, 38 und 50 Monaten gibt es nur im kostenpflichtigen Produkt Analytics 360.¹ Manches ist noch kürzer: Daten zu Alter, Geschlecht und Interessen werden immer nur 2 Monate behalten, egal was du einstellst, und Propertys, die Google als Large oder XL einstuft, sind unabhängig von der Einstellung auf 2 Monate begrenzt.¹ Öffnest du also eine Analyse in GA4 und hoffst auf drei Jahre Verhalten, sind die rohen Nutzerdetails älter als 14 Monate schlicht weg.

Dann das Sampling. Deckt eine Analyse oder eine Abfrage mehr Ereignisse ab als das Kontingent, zählt GA4 nicht alle. Es wertet einen Teil aus und rechnet das Ergebnis hoch. Das Kontingent für Abfragen auf Ereignisebene liegt bei 10 Millionen Ereignissen in einer Standard Property, gegenüber bis zu 1 Milliarde bei 360.² Ein stark besuchter Shop, der eine detaillierte Frage über einen langen Zeitraum stellt, liest also oft eine Schätzung, keine Zählung. Für das Erkennen eines Trends reicht das, für ein genaues Modell ist es falsch.

Der einzige Weg, auf dem der vollständige, ungesampelte Ereignisstrom Zeile für Zeile wirklich deins wird, ist der Export nach BigQuery, und selbst der hat in der kostenlosen Stufe Grenzen. Eine Standard Property von GA4 kann im täglichen Export bis zu 1 Million Ereignisse pro Tag ausspielen, bei 360 sind es bis zu 20 Milliarden. Der Streaming Export hat keine Mengengrenze, aber Google beschreibt ihn als bestmöglich ohne Vollständigkeitsgarantie, er kann also Lücken haben.³ Die praktische Folge ist nüchtern: Hast du den Export nach BigQuery nie eingerichtet, liegt nirgends eine vollständige Rohhistorie, die du migrieren könntest. Was GA4 hält, ist in der Aufbewahrung begrenzt, bei großen Abfragen geschätzt und deckt immer nur Daten ab, die nach dem Einrichten der Property erfasst wurden.

Wie zerbrechlich eine gemietete Analysehistorie ist, zeigt der Vorgänger des Produkts. Universal Analytics hat am 1. Juli 2023 aufgehört, neue Daten zu verarbeiten, und in der Woche des 1. Juli 2024 hat Google jeden Zugang dazu entfernt und alles, was nicht exportiert war, endgültig gelöscht.⁴ Jedes Unternehmen, das diese Dashboards für sein Gedächtnis gehalten hatte, verlor dieses Gedächtnis an einem Datum, das Google bestimmt hat. Das ist das ehrliche Argument dafür, das Nötige als Momentaufnahme zu sichern und die Daten, die zählen, selbst zu besitzen.

Du behältst das Werkzeug, du migrierst nicht seine Historie

Das Denkmodell, das viel Ärger erspart, ist dieses: Analysewerkzeuge sind Instrumente, die du neu ausrichtest, keine Archive, die du umziehst.

Beim Umstieg behältst du deine GA4 Property und versiehst den neuen Shop mit ihrem Tag, damit die Messung ohne Lücke weiterläuft. Du gießt die Historie der alten Property nicht in eine neue, und das geht auch nicht. GA4 berichtet immer nur über Daten, die es nach dem Einrichten selbst erfasst hat, und es gibt keinen unterstützten Weg, eine neue Property mit den Ereignissen einer anderen rückwirkend zu füllen. Sei an dieser Stelle genau mit jedem, der dir etwas anderes verspricht.

Stattdessen machst du Momentaufnahmen. Exportiere vor dem Umzug die paar Berichte, die du wirklich nutzt, also die, die eine wiederkehrende Frage beantworten, als datierte Dateien oder in eine Tabelle, und lege sie zur Projektakte. Fragt in einem Jahr jemand, wie der Verkehr im Herbst vor der Migration aussah, hast du eine Antwort, die nicht von einem Aufbewahrungsfenster abhängt. Alles andere, die Berichte, die seit einem Jahr niemand geöffnet hat, lässt du ziehen.

Was für die Prognose wirklich zählt

Hier dreht sich die Angst um. Eine Nachfrageprognose entsteht fast ausschließlich aus deiner Transaktionshistorie, nicht aus deiner Webanalyse. Gute Prognosen, wie es das Standardwerk zum Thema sagt, erfassen die echten Muster und Zusammenhänge in den historischen Daten, und wie vorhersehbar etwas ist, hängt davon ab, wie gut du die Treiber verstehst, wie viele Daten du hast und wie ähnlich die Zukunft der Vergangenheit ist.⁵ Keiner dieser drei Punkte hängt an Heatmaps.

Was eine Prognose konkret braucht, sind lauter eigene Daten, die du bereits besitzt:

• Die Bestellhistorie auf Positionsebene mit Datum, die die Nachfragereihe selbst ist, eine Zeile je Produkt je Bestellung.
• Die Verlaufsdaten zu Lager und Verfügbarkeit, damit du einen ausverkauften Artikel nicht mit nachlassender Nachfrage verwechselst und den Einbruch fortschreibst.
• Die Historie zu Preisen und Aktionen, damit jede Schätzung von Preiselastizität oder Aktionshebung gegen den Preis gemessen wird, der tatsächlich galt.
• Rückgaben, damit die Nachfrage netto ist, abzüglich dessen, was zurückkam.
• Ein Kalender vergangener Ereignisse: Launches, Kampagnen, Ausfälle, der Tag, an dem das Lager unter Wasser stand, damit dem Modell gesagt werden kann, welche Ausschläge echt waren und welche Einmaleffekte.

Jeder dieser Punkte liegt in der Transaktionsdatenbank und wandert mit ihr. Die Mechanik des Übertragens und des sauberen Neustarts der Bestellnummern gehört in die Speiche zur Bestell und Kaufhistorie. Liegt alles erst im neuen Shop, haben die Methoden aus Nachfrageprognosen mit Autokorrelation und Saisonalität und aus der KI gestützten Bedarfsprognose alles, was sie brauchen.

Was eine Prognose nicht braucht, ist jeder Klick. Du brauchst nicht den vollen Ereignisstrom, um zu wissen, wie viele Stück eines Produkts du pro Woche verkauft hast. Die ehrliche Faustregel zur Menge lautet schlicht, dass du genug saubere Historie brauchst, damit das Muster sichtbar wird, und genug Ereignisse je Segment, das du getrennt prognostizieren willst, bevor ein Modell dein Vertrauen verdient. Eine Wunderzahl erfinde ich hier nicht, denn die echte Antwort hängt von Saisonalität und Rauschen deiner Reihe ab. Diese genaue Frage hat einen eigenen Artikel: wie viele Daten du wirklich brauchst.

Der Umzug ist der Moment, die Messung richtig aufzusetzen

Weil du einen neuen Shop von Grund auf mit Tags versiehst, ist ein Umzug die beste Gelegenheit, die Messung zu reparieren, statt ihre Fehler weiterzutragen.

Drei Dinge lohnen sich an dieser Stelle. Erstens, versieh den neuen Shop mit Tags, die first party und einwilligungsbewusst sind, damit die erhobenen Daten tragfähig sind. Der Einwilligungsmodus von Google gibt die Wahl einer Besucherin über Einstellungen wie analytics_storage und ad_storage an die Tags weiter, und wird die Einwilligung für Analytik verweigert, sendet GA4 cookielose Pings und modelliert die Lücke, statt Cookies zu setzen.⁶ Ein echtes Einwilligungsbanner davor brauchst du trotzdem. Zweitens, denk über serverseitiges Tagging nach, das die Tags aus dem Browser auf einen Server verlagert, den du kontrollierst, für bessere Datenqualität und feinere Datenschutzkontrollen.⁷ Drittens, weil dir der Shop jetzt gehört, kannst du eine saubere Kopie der Transaktionsdaten direkt in dein eigenes Berichtswesen einspeisen, statt alles aus dem Browser abzuleiten.

Das ist derselbe Faden, der sich durch wem deine Geschäftsdaten eigentlich gehören zieht: Je mehr deiner Messung auf einer Infrastruktur sitzt, die du kontrollierst, desto weniger davon kann durch eine Entscheidung abgeschaltet, gesampelt oder gelöscht werden, die nicht deine war.

Data Warehouse und BI

Hat der Shop schon ein Warehouse gespeist, BigQuery oder Ähnliches, dann gehört dieses Warehouse dir und es bleibt. Die Shopmigration rührt nichts daran, außer dass du die Ladeprozesse auf den neuen Shop richtest, sobald er live ist.

Hatte der Shop nie ein Warehouse, macht der eigene Shop ein sauberes Warehouse zu etwas Geradlinigem statt Exotischem. Deine Transaktionsdaten liegen in deiner eigenen Datenbank, also ist ein geplanter Export in ein Warehouse und ein ordentliches Berichtswesen darauf eine Sache der Konfiguration, keine Bitte an eine Plattform um Zugang, den sie vielleicht nicht gewährt. Du mietest den Blick auf deine eigenen Zahlen nicht länger.

Der praktische Weg

Zusammengenommen ist die ganze Analytics Migration ein Weg aus fünf ehrlichen Schritten.

1. Inventarisiere jede Datenquelle: jedes Analysewerkzeug, jedes Dashboard, die Transaktionsdatenbank, jedes Warehouse, jede Tabelle, die jemand von Hand pflegt. Benenne für jede einen Verantwortlichen.
2. Entscheide für jede Quelle: behalten, Momentaufnahme oder neu bauen. Behalte die Werkzeuge, die du mitnimmst, sichere als Momentaufnahme die Berichte, die du als Beleg brauchst, baue die Dashboards auf eigenen Daten neu.
3. Exportiere die Transaktionshistorie, abgewickelt in den Speichen zu Bestellungen und Kunden, denn das sind die Daten, die prognostizieren.
4. Exportiere vor dem Umzug Berichtsmomentaufnahmen aus den Werkzeugen der Drittanbieter, datiert, in die Projektakte.
5. Versieh den neuen Shop mit Tags, einwilligungsbewusst und idealerweise serverseitig, und stell ein sauberes Berichtswesen direkt auf deine eigenen Daten.

Das Gewicht der Arbeit liegt in Schritt drei und fünf, die um deine eigenen Daten gehen. Die Analysewerkzeuge, Schritt zwei und vier, sind ein Nachmittag voller Exporte und die Entscheidung, den Rest ziehen zu lassen.

Ein durchgerechnetes Beispiel: Auwald Outdoor in Leipzig

Auwald Outdoor (auwaldoutdoor.example) ist ein erfundener Laden in Leipzig, der Wanderschuhe, Regenjacken und Campingausrüstung verkauft. Katrin führt ihn. Er läuft seit fünf Jahren auf einer gemieteten Plattform und zieht auf einen eigenen Solidus Shop um. Jede Zahl hier ist erfunden, um die Methode zu zeigen.

Katrin beginnt damit, ihre Datenquellen aufzulisten und neben jede eine einzige Entscheidung zu schreiben. Ihre Liste sieht so aus.

Die Sortierung kostet sie einen Nachmittag. Der einzige echte Verlust, den sie findet, sind die Nutzerdetails in GA4 älter als 14 Monate, die schon vor dem Start weg waren und die sie kein einziges Mal für eine Entscheidung gebraucht hatte.

Die Transaktionsmigration, erledigt über die Bestellspeiche, bringt fünf Jahre Bestellpositionen mit Datum, ihre Lagerbewegungen, ihre Preisänderungen und ihre Rückgaben herüber. Die Aktionstabelle fügt sie als Tabelle von Ereignissen hinzu. Zum ersten Mal liegt alles davon in einer Datenbank, die sie kontrolliert.

Sechs Wochen nach dem Umstieg baut Katrin ihre erste Nachfrageprognose für die Winterstiefel. Sie fußt vollständig auf der migrierten Bestellhistorie, korrigiert um die drei Wochen im vergangenen Januar, in denen die Stiefel ausverkauft waren, damit das Modell den Ausfall nicht als schwache Nachfrage liest, und ist darüber informiert, welche vergangenen Ausschläge Aktionen waren. Es ist die erste Prognose, der sie vertraut, und sie nutzt keine einzige Zeile aus irgendeinem Analysewerkzeug. Das, dessen Verlust sie gefürchtet hatte, war das, was sie nie gebraucht hat.

Was dir künftig egal sein darf

Ein Umzug ist auch die Erlaubnis, Zahlen fallen zu lassen, die immer nur Rauschen waren. Eitelkeitskennzahlen, die keine Entscheidung bewegt haben, Dashboards, die gebaut wurden, weil die Plattform sie anbot, und nicht, weil jemand danach fragte, Funnels, nach denen niemand handelte. Wenn du die Entscheidung nicht benennen kannst, die ein Bericht ändert, braucht er keinen Platz im neuen Shop. Das eigene Berichtswesen zu besitzen heißt, nur die Ansichten zu bauen, die sich lohnen.

Der ehrliche Schluss

Die meiste Panik um verlorene Analysedaten ist unbegründet. Die Daten, die Nachfrage prognostizieren und echte Entscheidungen treiben, sind deine Transaktionsdaten, also Bestellungen, Kunden und Katalog, und die wandern sauber in einen Shop, der dir gehört. Der Rest sind Werkzeuge, die du neu ausrichtest, und Berichte, die du als Momentaufnahme sicherst, keine Historie, die du migrierst. Halte die drei Töpfe auseinander, entscheide je Quelle behalten, Momentaufnahme oder neu bauen, trag die Transaktionsdaten mit Sorgfalt herüber, und du kommst aus dem Umzug mit besseren Zahlen heraus, als du hineingegangen bist, auf einer Infrastruktur, die niemand abschalten kann.

Beschäftigt dich der Analyseteil eines Umzugs, lässt sich diese Sorge meist an einem Nachmittag des Sortierens lösen. Bring deine Liste der Datenquellen zu einem kostenlosen Workshop mit, und wir markieren jede gemeinsam mit behalten, Momentaufnahme oder neu bauen. Ich zeige dir die erste Prognose, die deine eigene Bestellhistorie tragen kann, und die ersten zwei Wochen Arbeit gehen auf mich.