![\"Acht](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/containerversion-finden-de.png\")
Was die Versionsliste zeigt und was sie verbirgt<\/h2>\n
Jede Ver\u00f6ffentlichung erzeugt eine Version, und diese Version ist eine vollst\u00e4ndige, unver\u00e4nderliche Kopie des Containers zu diesem Zeitpunkt. Die Liste davon zeigt vier Dinge: eine Nummer, einen Namen, wer ver\u00f6ffentlicht hat und wann.<\/p>\n
Nicht zeigt sie den Inhalt. Zwei Versionen k\u00f6nnen sich in einem Zeichen einer Variablen unterscheiden, und die Liste sieht so oder so gleich aus. Die \u00c4nderungszahl neben einer Version hilft ein wenig und f\u00fchrt viel in die Irre, denn sie z\u00e4hlt die \u00c4nderungen im Arbeitsbereich und nicht den Unterschied zur vorigen Version – ein Arbeitsbereich, in dem etwas ge\u00e4ndert und wieder zur\u00fcckgenommen wurde, erh\u00f6ht die Zahl, ohne etwas zu ver\u00e4ndern.<\/p>\n
Das eine Feld, das die Frage unmittelbar beantworten w\u00fcrde, sind die Versionsnotizen. Es ist freier Text, es wird beim Ver\u00f6ffentlichen geschrieben, und es ist in nahezu jedem existierenden Container leer. Es auszuf\u00fcllen ist die billigstm\u00f6gliche Verbesserung dieses ganzen Problems – und sie hilft erst ab jetzt.<\/p>\n
Die Versionen \u00fcber die API holen<\/h2>\n
Die Tag-Manager-API liefert dieselben Versionen, die die Oberfl\u00e4che zeigt, und den vollst\u00e4ndigen Inhalt jeder einzelnen. Lesezugriff gen\u00fcgt.<\/p>\n
# Umfang: https:\/\/www.googleapis.com\/auth\/tagmanager.readonly\n\nBASIS=\"https:\/\/tagmanager.googleapis.com\/tagmanager\/v2\"\nPFAD=\"accounts\/6000000001\/containers\/7000000002\"\n\n# 1 die Liste der Versionen - kurz, ohne Inhalt\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n \"$BASIS\/$PFAD\/version_headers\" | jq -r \\\n '.containerVersionHeader[] | [.containerVersionId, .name] | @tsv'\n\n# 2 eine vollstaendige Version\ncurl -s -H \"Authorization: Bearer $TOKEN\" \\\n \"$BASIS\/$PFAD\/versions\/41\" > version-41.json<\/code><\/pre>\nZwei Dinge zum ersten Aufruf lohnen sich zu wissen. Er liefert K\u00f6pfe statt Inhalt, was ihn g\u00fcnstig macht und der richtige Weg zum Aufz\u00e4hlen ist. Und er ist seitenweise: Ein Container mit vielen Versionen liefert ein nextPageToken<\/code>, und ein Skript, das es \u00fcbergeht, arbeitet stillschweigend nur mit der neuesten Seite.<\/p>\nDer zweite Aufruf ist der teure, denn er liefert den ganzen Container. Das ist der Grund f\u00fcr den n\u00e4chsten Abschnitt: vierzig vollst\u00e4ndige Versionen zu holen, um ein Tag zu vergleichen, sind viele Daten f\u00fcr eine Frage.<\/p>\n
Die Pr\u00fcfsumme, die eine \u00c4nderung anzeigt<\/h2>\n
Jedes Element eines Containers tr\u00e4gt eine fingerprint<\/code>-Angabe, und sie \u00e4ndert sich, sobald dieses Element bearbeitet wird. Die Pr\u00fcfsumme eines Tags \u00fcber die Versionen zu vergleichen beantwortet die Frage deshalb, ohne sonst irgendetwas zu vergleichen.<\/p>\nimport json, glob\n\nGESUCHT = \"25\" # tagId: GA4 - Event - purchase\n\nvorher = None\nfor datei in sorted(glob.glob(\"version-*.json\"),\n key=lambda d: int(d.split(\"-\")[1].split(\".\")[0])):\n daten = json.load(open(datei))\n tags = {t[\"tagId\"]: t for t in daten.get(\"tag\", [])}\n tag = tags.get(GESUCHT)\n\n if tag is None:\n print(f\"{datei:16s} nicht vorhanden\")\n else:\n marke = tag[\"fingerprint\"]\n hinweis = \"GEAENDERT\" if vorher and marke != vorher else \"\"\n print(f\"{datei:16s} {marke} {hinweis}\")\n vorher = marke<\/code><\/pre>\nDie Ausgabe ist eine Zeile je Version, und die interessanten melden sich von selbst. Ein Tag, das drei\u00dfig Versionen lang unber\u00fchrt blieb und sich dann einmal \u00e4nderte, erzeugt genau eine markierte Zeile – und diese Zeile ist die Antwort.<\/p>\n
Zwei Eigenschaften der Pr\u00fcfsumme verdienen eine Anmerkung. Sie ist undurchsichtig – sie sagt, dass sich etwas ge\u00e4ndert hat, nicht was -, und f\u00fcr diesen Schritt gen\u00fcgt das. Und sie \u00e4ndert sich bei jeder Bearbeitung einschlie\u00dflich einer Umbenennung: Ein umbenanntes Tag erscheint als ge\u00e4ndert, ohne sich anders zu verhalten. Ein Abgleich \u00fcber die tagId<\/code> statt \u00fcber den Namen \u00e4ndert daran nichts, \u00fcbersteht aber die Umbenennung, die das Element \u00fcberhaupt erst schwer auffindbar gemacht hat.<\/p>\nDie Version finden, dann zwei vergleichen<\/h2>\n
Ist die Version bekannt, findet der Vergleich zwischen zwei Dateien statt und nicht zwischen vierzig – und er lohnt sich auf einer vereinheitlichten Kopie statt auf dem rohen Export.<\/p>\n
# nur das gesuchte Tag aus beiden Versionen, sortiert\nfor v in 43 44; do\n jq -S --arg n \"GA4 - Event - purchase\" \\\n '.tag[] | select(.name == $n)' version-$v.json > tag-$v.json\ndone\n\ndiff -u tag-43.json tag-44.json<\/code><\/pre>\nDas -S<\/code> macht das Ergebnis lesbar. Ohne es kommen die JSON-Schl\u00fcssel in der Reihenfolge zur\u00fcck, die die API erzeugt hat, und ein Vergleich zweier bedeutungsgleicher Objekte kann dutzende Zeilen lang sein. Die Schl\u00fcssel zu sortieren beseitigt das vollst\u00e4ndig, und \u00fcbrig bleibt die eigentliche \u00c4nderung.<\/p>\nDrei Felder lohnen sich im Vergleich zu \u00fcbergehen, weil sie sich von allein \u00e4ndern: fingerprint<\/code>, das hier zum Finden der Version dient und nicht zu ihrer Beschreibung, sowie jedes Zeitstempel- oder Pfadfeld, das die Versionsnummer tr\u00e4gt. Alles andere, was sich unterscheidet, ist ein echter Unterschied.<\/p>\nKontingent und die \u00f6rtliche Kopie<\/h2>\n
Die Tag-Manager-API ist je Minute und je Tag begrenzt, und eine Schleife \u00fcber vierzig vollst\u00e4ndige Versionen l\u00e4uft schnell dagegen. Der Fehlschlag ist eine 429-Antwort, und ein Skript ohne Pause macht aus einer Untersuchung eine f\u00fcr den Rest der Stunde gesperrte API.<\/p>\n
for v in $(cat versionen.txt); do\n [ -f \"version-$v.json\" ] && continue # schon vorhanden\n curl -s -H \"Authorization: Bearer $TOKEN\" \\\n \"$BASIS\/$PFAD\/versions\/$v\" > \"version-$v.json\"\n sleep 2\ndone<\/code><\/pre>\nDas \u00dcberspringen einer vorhandenen Datei ist die wichtige Zeile. Versionen sind unver\u00e4nderlich, eine einmal geholte Version muss also nie erneut geholt werden – und ein Verzeichnis davon wird zu einem Archiv, das die n\u00e4chste Frage beantwortet, ohne die API \u00fcberhaupt anzufassen.<\/p>\n
Dieses Archiv lohnt sich absichtlich anzulegen statt als Nebenprodukt. Eine w\u00f6chentliche Aufgabe, die die neuesten Versionen holt, kostet nichts – und damit steht der Verlauf auch f\u00fcr einen Container zur Verf\u00fcgung, dessen Zugang sp\u00e4ter jemandem abhandenkommt.<\/p>\n
Die Frage, die die API nicht beantwortet<\/h2>\n
Drei Dinge bleiben au\u00dfen vor, und zu wissen, welche das sind, erspart eine lange Suche nach etwas, das nicht da ist.<\/p>\n
Das erste ist, wer ein bestimmtes Element ge\u00e4ndert hat. Eine Version h\u00e4lt fest, wer sie ver\u00f6ffentlicht hat, und eine Ver\u00f6ffentlichung kann die Arbeit mehrerer Personen aus mehreren Wochen enthalten. Eine Urheberschaft je Element hat die API nicht, und die Oberfl\u00e4che auch nicht.<\/p>\n
Das zweite ist alles, was nie zu einer Version wurde. Eine \u00c4nderung, die in einem Arbeitsbereich gemacht und vor der Ver\u00f6ffentlichung zur\u00fcckgenommen wurde, hinterl\u00e4sst keine Spur, und ein gel\u00f6schter Arbeitsbereich ebenso wenig. Der Verlauf ist ein Verlauf von Ver\u00f6ffentlichungen, nicht von Bearbeitungen.<\/p>\n
Das dritte ist die Wirkung. Zwei Versionen k\u00f6nnen sich in einer Ausl\u00f6sebedingung unterscheiden, die zehn Prozent h\u00e4ufiger zutrifft, und nichts im Container sagt das – der Unterschied ist eine Zeile Konfiguration, und seine Folge steht in den Daten. Deshalb ist dieses ganze Verfahren die erste H\u00e4lfte einer Untersuchung: Es liefert den Zeitpunkt und die \u00c4nderung, und die zweite H\u00e4lfte ist die Pr\u00fcfung, ob sich die Zahlen zu diesem Zeitpunkt ebenfalls bewegt haben.<\/p>\n
\nFragen und Antworten<\/h2>\nFindet der Vergleich der Pr\u00fcfsumme auch eine \u00c4nderung an einem Trigger oder einer Variablen, die das Tag benutzt?<\/h3>\n
Nein, und das ist die wichtigste L\u00fccke dieses Verfahrens. Die fingerprint-Angabe eines Tags \u00e4ndert sich nur, wenn das Tag selbst bearbeitet wird. Das Tag verweist auf seine Trigger \u00fcber deren IDs und auf Variablen \u00fcber ihren Namen in doppelten geschweiften Klammern. \u00c4ndert jemand die Ausl\u00f6sebedingung eines Triggers oder den Wert einer Variablen, bleibt das Tag Zeichen f\u00fcr Zeichen gleich und mit ihm seine Pr\u00fcfsumme, obwohl es sich nun anders verh\u00e4lt.<\/p>\n
Die Schleife aus dem Artikel l\u00e4sst sich deshalb auf die Abh\u00e4ngigkeiten ausdehnen: Aus dem Tag werden die IDs in firingTriggerId und blockingTriggerId gelesen und die Namen aller {{\u2026}}-Verweise gesammelt; danach werden die Pr\u00fcfsummen dieser Trigger in daten[\"trigger\"]<\/code> und dieser Variablen in daten[\"variable\"]<\/code> \u00fcber die Versionen genauso verglichen wie die des Tags.<\/p>\nAuch das reicht nicht ganz, denn Variablen k\u00f6nnen auf andere Variablen verweisen. Gr\u00fcndlich ist es, die Verweise zu verfolgen, bis keine neuen mehr hinzukommen; einfacher ist es, bei der Suche nach der Version gleich die Pr\u00fcfsummen aller Elemente des Containers zu vergleichen.<\/p>\n
Was passiert, wenn ein Abruf in der Schleife mit 429 scheitert?<\/h3>\n
Dann entsteht trotzdem eine Datei. curl -s schreibt ohne weitere Option auch eine Fehlerantwort in die Ausgabe, und version-44.json enth\u00e4lt dann die JSON-Fehlermeldung der API statt eines Containers. Beim n\u00e4chsten Lauf gilt die Datei als vorhanden und wird \u00fcbersprungen, und genau die Zeile, die das Archiv wertvoll macht, h\u00e4lt den Fehler fest.<\/p>\n
Das Auswertungsskript meldet das nicht, sondern f\u00fchrt in die Irre: daten.get(\"tag\", [])<\/code> liefert f\u00fcr die Fehlermeldung eine leere Liste, und die Version erscheint als \u201enicht vorhanden\u201c, als w\u00e4re das Tag darin gel\u00f6scht worden.<\/p>\nDie Option -f allein gen\u00fcgt nicht, denn die Umleitung mit > legt die Datei schon an, bevor curl antwortet; dann bliebe eine leere Datei liegen, die ebenso \u00fcbersprungen w\u00fcrde. Sicher ist der Weg \u00fcber eine tempor\u00e4re Datei, die erst umbenannt wird, wenn curl erfolgreich war und jq -e .containerVersionId<\/code> einen Wert findet.<\/p>\nIst die Version, in der sich das Tag ge\u00e4ndert hat, auch die, die am fraglichen Tag live war?<\/h3>\n
Nicht zwingend. Jede Ver\u00f6ffentlichung erzeugt eine Version, aber nicht jede Version wird ver\u00f6ffentlicht: Eine Version l\u00e4sst sich auch anlegen, ohne sie live zu schalten, und eine \u00e4ltere Version l\u00e4sst sich sp\u00e4ter erneut ver\u00f6ffentlichen, etwa um eine \u00c4nderung r\u00fcckg\u00e4ngig zu machen. Die Versionsnummer gibt deshalb die Reihenfolge der Entstehung an, nicht die der Ver\u00f6ffentlichung.<\/p>\n
F\u00fcr den Abgleich mit dem Bericht z\u00e4hlt, wann welche Version live ging. Findet der Vergleich die \u00c4nderung in Version 44, ist zu kl\u00e4ren, ob und wann Version 44 ver\u00f6ffentlicht wurde und ob danach wieder eine \u00e4ltere Version galt.<\/p>\n
Welche Berechtigung braucht die w\u00f6chentliche Archivaufgabe?<\/h3>\n
Lesezugriff gen\u00fcgt, wie im Artikel angegeben, mit dem Umfang tagmanager.readonly. L\u00e4uft die Aufgabe \u00fcber ein Dienstkonto, muss dessen E-Mail-Adresse im Tag Manager als Nutzer mit Leseberechtigung f\u00fcr das Konto oder den Container eingetragen sein; der Umfang allein gew\u00e4hrt keinen Zugriff. Mit blo\u00dfer Leseberechtigung kann die Aufgabe nichts ver\u00f6ffentlichen, ein abhandengekommener Schl\u00fcssel legt dann den Inhalt des Containers offen, ver\u00e4ndert ihn aber nicht.<\/p>\n<\/div>\n