Analyse und Verlaufsdaten für Prognosen migrieren

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

Wenn mich jemand auf den Umzug von einer gemieteten Plattform anspricht, kommt die Frage nach den Analysedaten mit echter Sorge. Jahre an Dashboards, Heatmaps, Conversion Funnels und Zugriffskurven, und die leise Überzeugung, dass am Umstellungstag alles davon verschwindet. Die Sorge verstehe ich, nur zielt sie meist auf das Falsche.

Die ehrliche Fassung lautet 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.

Art der Daten	Beispiele	Wer sie wirklich hält	Was du mitnehmen kannst
Eigene Transaktionsdaten	Bestellungen, Positionen, Kunden, Produkte, Preise, Lager, Rückgaben	Du, in der Plattformdatenbank	Alles, in deine eigene Datenbank
Analytik von Drittanbietern	GA4, Heatmaps, Sitzungsaufzeichnungen	Der Anbieter des Werkzeugs	Das Werkzeug selbst plus Berichtsmomentaufnahmen, nicht die Rohhistorie
Plattformeigene Dashboards	Eingebaute Umsatz und Zugriffsberichte	Die Plattform	Nichts zu migrieren, du baust die Ansichten auf eigenen Daten neu

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.¹ Wenn du also eine Analyse in GA4 öffnest und auf drei Jahre Verhalten hoffst, 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: Wenn du den Export nach BigQuery nie eingerichtet hast, 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: Donaupfad Outdoor in Linz

Donaupfad Outdoor (donaupfadoutdoor.example) ist ein erfundener Laden in Linz, der Wanderschuhe, Regenjacken und Campingausrüstung verkauft. Theresa 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.

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

Datenquelle	Was es wirklich ist	Entscheidung	Ehrlicher Plan
Bestell und Kundendatenbank der Plattform	Eigene Transaktionsdaten	Behalten	Vollständig in den neuen Shop migrieren, das ist der Treibstoff der Prognose
GA4 Standard Property	Webanalyse eines Drittanbieters, 14 Monate Aufbewahrung, bei großen Abfragen gesampelt	Werkzeug behalten, Berichte sichern	Neuen Shop mit derselben Property versehen, die fünf genutzten Berichte exportieren, den Rest ziehen lassen
Heatmap und Sitzungswerkzeug	Verhaltenswerkzeug eines Drittanbieters, aggregiert	Werkzeug behalten	Das Skript in den neuen Shop einbauen, nichts zu migrieren
Umsatz Dashboard der Plattform	Eine aus ihren eigenen Bestellungen berechnete Ansicht	Neu bauen	Auf den migrierten Daten besser nachbauen, im eigenen Besitz
Eine Tabelle der Aktionen je Woche	Von Hand gepflegter Ereigniskalender	Behalten	Als die Aktionshistorie importieren, die die Prognose braucht

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 Theresa ihre erste Nachfrageprognose für die Winterstiefel. Sie fußt vollständig auf der migrierten Bestellhistorie, korrigiert um die drei Wochen im vergangenen Jänner, 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.

Wenn der Analyseteil eines Umzugs dich beschäftigt, 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.

Footnotes

1. Google, [GA4] Data retention (Standard Propertys behalten Ereignis und Nutzerdaten 2 oder 14 Monate, 26, 38 und 50 Monate nur in Analytics 360, und Daten zu Alter, Geschlecht und Interessen immer nur 2 Monate), Analytics Hilfe, 2026, https://support.google.com/analytics/answer/7667196 ↩ ↩²

2. Google, [GA4] Data sampling (das Kontingent für Abfragen auf Ereignisebene liegt bei 10 Millionen Ereignissen für Standard Propertys und bis zu 1 Milliarde für Analytics 360), Analytics Hilfe, 2026, https://support.google.com/analytics/answer/13331292 ↩

3. Google, [GA4] BigQuery Export (Standard Propertys auf 1 Million Ereignisse pro Tag im täglichen Export begrenzt, bis zu 20 Milliarden bei 360, während der Streaming Export keine Mengengrenze hat, aber bestmöglich ist und Lücken enthalten kann), Analytics Hilfe, 2026, https://support.google.com/analytics/answer/9358801 ↩

4. Google, [UA] Universal Analytics wurde durch Google Analytics 4 ersetzt (Standard Propertys stoppten die Verarbeitung am 1. Juli 2023, und der Zugang wurde entfernt und nicht exportierte Daten in der Woche des 1. Juli 2024 endgültig gelöscht), Analytics Hilfe, 2026, https://support.google.com/analytics/answer/11583528 ↩

5. Rob J Hyndman und George Athanasopoulos, Forecasting: Principles and Practice (3. Auflage), Abschnitt 1.1 What can be forecast, OTexts, 2021, https://otexts.com/fpp3/what-can-be-forecast.html ↩

6. Google, [GA4] Einwilligungsmodus (gibt die Einwilligung der Besucher über analytics_storage und ad_storage an die Tags weiter, und bei verweigerter Einwilligung für Analytik sendet GA4 cookielose Pings und modelliert die Lücke), Analytics Hilfe, 2026, https://support.google.com/analytics/answer/9976101 ↩

7. Google, Serverseitiges Tagging, Entwicklerdokumentation der Google Tag Platform, 2026, https://developers.google.com/tag-platform/tag-manager/server-side ↩