English
Deutsch
PolskiKey Events und Conversions in GA4: Zwei Zähler und was die Data-API-Freigabe vom Mai 2026 zeigt
Inhalt
- Was die Umbenennung von 2024 wirklich getan hat
- Die Folge, die in der Oberfläche auftaucht
- Was die API-Freigabe hinzugefügt hat
- Die Dokumentation bestätigt die Trennung, indem sie zurückfällt
- Welche Zahl wohin gehört
- Ein Vorbehalt zum Alpha-Stand
- Fragen und Antworten
- Quellen
- Praxiskontrolle: Konfiguration vor und nach einer Änderung vergleichen
Am 4. Mai 2026 wurden kanalübergreifende Conversion-Daten über die Analytics Data API verfügbar, im Alpha-Stand und für Properties mit verknüpftem Google Ads. Als Release Note gelesen ist das ein bescheidener Posten: ein Bericht, den es in der Oberfläche gab, lässt sich jetzt auch programmgesteuert abrufen.
Als Beleg gelesen ist er ergiebiger. Um Conversions herauszugeben, muss die API sagen, was eine Conversion ist, und diese Antwort legt eine Trennung offen, die die Oberfläche seit 2024 still mitführt. In jeder GA4-Property laufen zwei Zähler nebeneinander. Nur einer davon ist immer da.
Was die Umbenennung von 2024 wirklich getan hat
Bis 2024 hiess das, was GA4 zählte, Conversion. Die Umbenennung hat dieses Wort aus Analytics heraus und nach Google Ads hinein verschoben: Was Analytics markiert, ist seither ein Key Event, und Conversion wurde zum Begriff für das, was Ads zählt und worauf Ads bietet.
Verbreitet wurde das als Kosmetik gelesen, ein Wort gegen ein anderes getauscht, um den Sprachgebrauch zweier Produkte aufzuräumen. Das war es nicht. Die Umbenennung hat zwei Zählungen getrennt, die sich einen Namen geteilt hatten, und dieses Teilen hatte verdeckt, dass sie nicht übereinstimmen.
Die Folge, die in der Oberfläche auftaucht
Innerhalb von Analytics bezeichnet Conversion jetzt genau ein Key Event, das nach Google Ads importiert wurde. Diese Festlegung hat eine harte Kante: Ohne verknüpftes Ads-Konto hat eine Property überhaupt keine Conversions. Nicht null Conversions — keine Spalte. Es gibt nur die Key-Event-Spalte, und ihr fehlt nichts.
Wo beide vorhanden sind, lassen sie sich vergleichen, und sie werden selten übereinstimmen. Der Grund liegt darin, dass sie nach verschiedenen Modellen zugeordnet werden, sich auf verschiedene Datenbestände beziehen und nach verschiedenen Regeln zählen — genau deshalb war ein gemeinsames Wort irreführend genug für eine Umbenennung.
Was die API-Freigabe hinzugefügt hat
Der Alpha-Stand gibt dieselben Zahlen heraus, die der Bericht zur Conversion-Leistung in der Oberfläche zeigt: bezahlte und organische Conversion-Leistung über Kanäle hinweg, erstmals im Code abrufbar. Drei Angaben in der Anfrage verdienen Beachtung, weil an ihnen die Unterschiede zu Key Events greifbar werden.
Conversion-Aktion alle Conversions auf einmal oder
gefiltert auf bestimmte Aktions-IDs
Attributionsmodell datengetrieben oder letzter Klick
Zeitbezug Conversion-Zeit - der Bericht wird um
den Zeitpunkt der Conversion gebaut
Interaktionszeit - der Bericht wird um
die vorausgegangene Anzeigeninteraktion gebautKeine dieser drei Angaben existiert für Key Events, und darum geht es. Ein Key Event ist ein Vorfall mit einem Zeitstempel. Eine Conversion ist ein Vorfall plus ein Modell, das entscheidet, welcher Kontaktpunkt sie verdient hat und unter welcher Uhr sie abgelegt wird. Zwei Zahlen aus derselben zugrundeliegenden Handlung können weit auseinanderliegen, ohne dass eine davon falsch wäre.
Die Dokumentation bestätigt die Trennung, indem sie zurückfällt
Der deutlichste Beleg dafür, dass hier zwei getrennte Systeme laufen, ist keine Definition, sondern eine Ausnahmeliste. An mehreren Stellen hält die Dokumentation zur kanalübergreifenden Conversion-Messung fest, dass Conversions nicht verfügbar sind und stattdessen Key Events verwendet werden.
App-Conversions stattdessen Key Events
Search-Ads-360-Dimensionen stattdessen Key Events
Display-&-Video-360-Dimensionen stattdessen Key Events
Campaign-Manager-360-Dimensionen stattdessen Key Events
Bericht zu Attributionspfaden stattdessen Key EventsEine Rückfallliste dieser Form ergibt nur Sinn, wenn beides tatsächlich verschiedene Grössen sind. Nichts fällt auf sich selbst zurück. Wer einen Bericht liest, der Web und App mischt oder SA360- und DV360-Dimensionen trägt, liest eine Mischung aus beiden Zählungen, und die Spaltenüberschrift sagt das nicht.
Welche Zahl wohin gehört
Die Arbeitsteilung ist sauber genug, um sie einmal aufzuschreiben und dann einzuhalten.
Key Events beantworten Fragen zur Website. Wie viele Personen das Formular abgeschlossen haben, ob das nach dem Relaunch gestiegen ist, welche Seite am häufigsten davorliegt. Die Zählung ist unmodelliert, überall vorhanden und mit sich selbst über die Zeit vergleichbar — deshalb ist sie die richtige Grundlage für alles Interne.
Conversions beantworten Fragen zur Werbung. Was eine Kampagne eingebracht hat, was zu bieten ist, welchem Kanal gutzuschreiben ist. Diese Zählung ist von Bauart her modelliert, denn die Entscheidung, was ein Klick wert war, ist eine Modellfrage und kann nichts anderes sein.
Schwierig wird es, wenn die eine Zählung für die Aufgabe der anderen verwendet wird: ein Kampagnenbericht, der mit Key Events begründet wird, oder ein Relaunch, der anhand von Conversions beurteilt wird, obwohl sich deren Zahl durch ein geändertes Attributionsfenster statt durch die Seite verändert hat. Beide Zählungen beschreiben unterschiedliche Dinge; für die jeweils andere Aufgabe liefern sie deshalb eine irreführende Bewertungsgrundlage.
Ein Vorbehalt zum Alpha-Stand
Alpha heisst in der Data API, dass sich die Schnittstelle ohne die Ankündigung ändern kann, die eine stabile Fassung bekäme. Das ist kein Grund, sie zu meiden — sie ist der einzige programmgesteuerte Weg zu diesen Zahlen —, aber ein Grund, die Abholung dünn zu halten. Eine Strecke, die Conversions zieht und roh ablegt, übersteht eine Feldumbenennung mit einer Änderung an einer Stelle. Eine Strecke, die auf dem Weg hinein verbindet, umformt und verdichtet, muss bei jeder Formänderung von Grund auf neu verstanden werden.
Fragen und Antworten
Wird ein Key Event automatisch zur Conversion, sobald Google Ads verknüpft ist?
Nein. Die Verknüpfung stellt nur die Verbindung her; zur Conversion wird ein Key Event erst, wenn es in Google Ads als Conversion-Aktion importiert ist. Bis dahin zählt die Conversion-Spalte dieses Ereignis nicht, auch wenn die Key-Event-Spalte daneben Zahlen trägt.
Welche Einstellungen bestimmen, wie weit Key Events und Conversions auseinanderliegen?
Der Artikel nennt Modelle, Datenbestände und Zählregeln; im Betrieb stecken dahinter vor allem vier Stellschrauben, die sich einzeln prüfen lassen:
- Die Zählmethode. Ein Key Event lässt sich in GA4 einmal je Ereignis oder einmal je Sitzung zählen, eine Conversion-Aktion in Google Ads zählt jede Conversion oder eine je Interaktion. Stehen beide Seiten verschieden, entstehen Abweichungen schon ohne jedes Modell.
- Das Attributionsmodell. Datengetrieben verteilt eine Conversion auf mehrere Kontaktpunkte, letzter Klick gibt sie einem einzigen.
- Das Fenster. Google Ads zählt eine Conversion nur, wenn sie innerhalb des eingestellten Conversion-Fensters nach der Anzeigeninteraktion liegt; ein Key Event kennt keine solche Frist.
- Der Zeitbezug. Nach Interaktionszeit steht eine Conversion am Tag des Klicks, das Key Event am Tag der Handlung. Tageswerte weichen dann auch dort ab, wo die Summen über einen längeren Zeitraum zusammenpassen.
Wer beide Zahlen vergleichen will, stellt diese vier zuerst nebeneinander. Was danach an Abstand bleibt, ist der Teil, der tatsächlich einer Erklärung bedarf.
Warum können die Conversions eines vergangenen Tages nachträglich steigen?
Weil nach Interaktionszeit jede Conversion dem Tag der vorausgegangenen Anzeigeninteraktion zugeschrieben wird. Ein Kauf heute nach einem Anzeigenklick vor einer Woche erhöht die Zahl jenes Tages. Eine Abholung, die jeden Tag nur den Vortag zieht, friert deshalb Werte ein, die noch wachsen.
Wie sieht eine dünne Abholung der Alpha-Daten konkret aus?
Eine dünne Abholung legt die Antwort so ab, wie sie kommt, und schreibt die Anfrage daneben. Zu jeder Zeile gehören das Attributionsmodell, der Zeitbezug und die gefilterten Aktions-IDs, denn dieselbe Kombination aus Tag und Kanal ergibt unter anderen Angaben eine andere Zahl, und ohne diese Angaben lässt sich später nicht mehr sagen, welche Fassung einer Zahl vorliegt. Dazu kommt der Abrufzeitpunkt, weil sich Werte nach Interaktionszeit nachträglich ändern.
Aus demselben Grund holt die Strecke nicht nur den Vortag, sondern einen zurückliegenden Zeitraum immer wieder ab und ersetzt die abgelegten Tage, statt sie zu ergänzen. Wie weit dieser Zeitraum reichen muss, ergibt sich aus den Conversion-Fenstern in Google Ads. Verbinden, Umformen und Verdichten geschehen erst danach, in Views über den Rohdaten; ändert die Alpha-Schnittstelle ein Feld, betrifft das eine Stelle beim Abholen und nicht jede nachgelagerte Tabelle.
Metadaten und Kontingente einer Berichtsantwort lassen sich mit dem GA4-API-Antwortprüfer untersuchen. GA4-API-Antwortprüfer
Praxiskontrolle: Konfiguration vor und nach einer Änderung vergleichen
Der GA4-Property-Konfigurationsvergleich erfasst einen definierten Satz von Einstellungen über die lesende Admin API. Damit wird beispielsweise eine geänderte Zählmethode eines Key Events oder eine andere Aufbewahrungsfrist sichtbar, ohne die Änderung mit einem neuen Berichtsergebnis zu verwechseln.
- Snapshot A vor der geplanten Änderung auslesen und als JSON lokal speichern.
- Nach der Änderung Snapshot B derselben Property erfassen. Alternativ eine zweite Property für den Vergleich zweier Implementierungen verwenden.
- Snapshots vergleichen. Das Ergebnis zeigt hinzugefügte, entfernte und geänderte Felder. Erfassungszeitpunkte und Property-IDs bleiben sichtbar.
- Key Events, Aufbewahrung, Zeitzone, Währung, Streams und eigene Definitionen innerhalb des dokumentierten Umfangs prüfen.
Dies ist keine vollständige Sicherung und kein rückwirkender Verlauf. Ein Snapshot kann Einstellungen vor seinem Erfassungszeitpunkt nicht rekonstruieren. Streams werden anhand von Typ und Name zugeordnet, eigene Definitionen anhand von Geltungsbereich und Parametername. Eine Umbenennung dieser Schlüssel erscheint als Entfernen und Hinzufügen. Ressourcen-IDs, Erstellungszeiten, Mess-IDs und Secrets sind ausgeschlossen. Ein Vergleich ohne Unterschiede beweist daher weder identisches Tagging noch identische Messdaten. Schlägt ein API-Abschnitt fehl, wird kein Teil-Snapshot als vollständig ausgegeben.
Gespeicherte Dateien lassen sich ohne Google-Anmeldung lokal vergleichen. Grundlage ist die Analytics Admin API, einschließlich Key Events und Aufbewahrungseinstellungen.
Passend dazu
