Analytics-Änderungen vom August 2026 nachprüfen: BigQuery-Abrechnung, Adobe-API und Shopify-Tracking

Im August 2026 lagen drei Analytics-Änderungen dicht beieinander: ein BigQuery-Abrechnungslabel am 11. August, die Shopify-Frist für neue Danke- und Bestellstatusseiten ohne Plus am 26. August und das Ende der Adobe Analytics API 1.4 am 31. August. Die Termine sind inzwischen vergangen. Entscheidend sind jetzt funktionierende Reports, korrekt migrierte Integrationen und nachgewiesene Messungen. Historische Abrechnungsdaten verschwinden nicht allein durch einen Labelwechsel.

1. BigQuery: Labelwerte statt SKU-Namen prüfen

Die BigQuery Release Notes vom 8. Mai nennen die Werte ausdrücklich: Beim Schlüssel goog-bq-feature-type wechselt DATA_TRANSFER_SERVICE zu data_transfer_service. Ab dem 11. August soll das Label außerdem Orchestrierung, Lade- und Merge-Vorgänge des Data Transfer Service abdecken. Ein Label ist eine zusätzliche Kennzeichnung einer Abrechnungsposition; die SKU bezeichnet die abgerechnete Leistung. Die Mitteilung belegt keine allgemeine SKU-Umbenennung oder Preiserhöhung.

Ein Filter nur auf den alten Großbuchstabenwert kann neue Positionen übersehen. Gleichzeitig ist der erweiterte Labelumfang für Vorher-Nachher-Vergleiche relevant: Ein Anstieg kann aus zusätzlich erfassten Vorgängen entstehen. Eine reine Umwandlung in Kleinbuchstaben macht den Arbeitsumfang nicht vergleichbar.

2. Billing-Historie bleibt auswertbar

Bereits exportierte und aufbewahrte Daten lassen sich auch nach dem Stichtag abfragen. Ein früher gespeichertes Ergebnis verbessert die Nachvollziehbarkeit, ist aber keine Voraussetzung für jeden späteren Vergleich. Fehlt die Exporthistorie, hängt eine rückwirkende Erstbefüllung von den Cloud-Billing-Regeln und dem Dataset-Standort ab. Eine beliebig lange Nachlieferung ist nicht zugesichert; Löschung und Tabellenablauf können vorhandene Historie begrenzen.

Das folgende Beispiel nutzt das Schema des Standard-Cloud-Billing-Exports. Der Tabellenname ist ein Platzhalter. Zwei gleich lange UTC-Fenster umfassen jeweils 14 Tage. EXISTS sucht den Schlüssel in Labels und Systemlabels, ohne Abrechnungszeilen bei mehreren Treffern zu vervielfachen. Währungen und SKUs bleiben getrennt; Gutschriften werden zusätzlich zu den Kosten ausgewiesen.

-- Standard Cloud Billing export; table identifier is a placeholder.
-- Two 14-day UTC windows: [2026-07-28, 2026-08-11) and [2026-08-11, 2026-08-25).
WITH selected AS (
  SELECT DATE(b.usage_start_time, 'UTC') AS usage_day,
         b.currency, b.sku.id AS sku_id, b.sku.description AS sku_description,
         b.cost,
         COALESCE((SELECT SUM(c.amount) FROM UNNEST(b.credits) AS c), 0) AS credits
  FROM `PROJECT.DATASET.gcp_billing_export_v1_ACCOUNT` AS b
  WHERE b.usage_start_time >= TIMESTAMP('2026-07-28', 'UTC')
    AND b.usage_start_time < TIMESTAMP('2026-08-25', 'UTC')
    AND EXISTS (
      SELECT 1 FROM UNNEST(ARRAY_CONCAT(b.labels, b.system_labels)) AS label
      WHERE label.key = 'goog-bq-feature-type'
        AND LOWER(label.value) = 'data_transfer_service'
    )
)
SELECT IF(usage_day < DATE '2026-08-11', 'before', 'after') AS phase,
       currency, sku_id, sku_description,
       ROUND(SUM(cost), 2) AS cost_before_credits,
       ROUND(SUM(credits), 2) AS credits,
       ROUND(SUM(cost + credits), 2) AS cost_after_credits,
       COUNT(*) AS line_items,
       COUNT(DISTINCT usage_day) AS observed_usage_days
FROM selected
GROUP BY phase, currency, sku_id, sku_description
ORDER BY currency, sku_id, phase;

Vor der Nutzung muss der tatsächliche Export den Schlüssel enthalten. Unbeschriftete Positionen fehlen in dieser Auswahl; keine Ergebniszeile bedeutet daher nicht automatisch keine Kosten. Auch observed_usage_days beweist keine vollständige Lieferung. Nutzungstage können vom Rechnungsmonat abweichen, verspätete Positionen oder Korrekturen spätere Ergebnisse verändern. Der konkrete Datenstand und die Abfrage gehören zum gespeicherten Vergleich.

Für eine Ursachenanalyse bleiben dieselben Transfers, vergleichbare Datenmengen und Laufhäufigkeiten nötig. Die Abfrage zeigt Kostenpositionen, misst aber weder eine Preisänderung noch den vollständigen früheren Umfang aller neu beschrifteten Vorgänge. Für einen fairen Vergleich müssen in beiden Zeiträumen dieselben Transfers und Vorgänge einander zugeordnet werden. Danach lassen sich deren Datenmengen und Anzahl der Läufe vergleichen.

3. Adobe: API-Aufrufe und Authentifizierung migrieren

Adobe bestätigt die Stilllegung der Analytics API 1.4 und der WSSE-Authentifizierung zum 31. August 2026. Betroffen sind Reporting- und Verwaltungs-APIs. Die Data Insertion API zur Datenerfassung ist von dieser API-Migration ausgenommen. Daraus folgt kein allgemeines Abschalten der Analytics-Datensammlung.

Die Bestandsaufnahme umfasst geplante Jobs, SDK-Versionen, Endpunkte und Authentifizierung. Die folgende Suche gibt nur Dateinamen aus, damit Quellzeilen mit möglichen Zugangsdaten nicht unnötig im Terminalprotokoll landen. Die drei Verzeichnisse sind Platzhalter. Ein Suchfehler bleibt von einem Ergebnis ohne Treffer unterscheidbar.

#!/usr/bin/env bash
# Source directories are placeholders; filenames only, no credential contents.
grep -rIilE 'wsse|/1\.4/|api[-_ ]?1\.4|api\.omniture\.com' ./src ./jobs ./config
status=$?
case "$status" in
  0) printf '%s\n' 'Potential legacy references found; manual review required.' ;;
  1) printf '%s\n' 'No textual matches; this is not migration proof.' ;;
  *) printf '%s\n' 'Search failed or was incomplete.' >&2; exit "$status" ;;
esac

Ein Treffer ist ein Hinweis, kein Beweis eines aktiven Aufrufs. Umgekehrt können Hilfsbibliotheken mit indirekten API-Aufrufen, automatisch erzeugte Konfigurationen oder externe Dienste die Suchbegriffe verbergen. Die Migration benötigt deshalb eine Prüfung der tatsächlich aufgerufenen Clients und einen erfolgreichen fachlichen Vergleich der neuen Reports. Ein Endpunkt ist die Adresse, an die eine API-Anfrage gesendet wird. API 2.0 verändert unter anderem diese Adressen, die Abfragestruktur und verfügbare Verwaltungsfunktionen. Ein bloßer Austausch der Versionsnummer reicht nicht.

Für unbeaufsichtigte Serverintegrationen ist OAuth Server-to-Server ein dokumentierter Weg. Zugeordnete Produktprofile bestimmen den Datenzugriff; ein gültiges Token allein garantiert keine Report-Suite-Berechtigung. Fehlgeschlagene Jobs bleiben anhand konkreter HTTP-Antworten, Berechtigungen und Endpunkte zu untersuchen, statt jede Störung pauschal dem Stichtag zuzuordnen.

Der Legacy Report Builder hat einen eigenen Ablauf: Die Produktdokumentation nennt das Ende im Juni 2026, keine geplanten Workbook-Zustellungen mehr ab 1. Juli und eine Migrationsfrist bis 12. August. Für danach benötigte Originalarbeitsmappen verweist Adobe an den Support.

4. Shopify: die tatsächlichen Seiten und Pixel prüfen

Die Non-Plus-Frist vom 26. August betrifft die bestehenden Danke- und Bestellstatusseiten. Gemeint ist nicht pauschal der gesamte Checkout. checkout.liquid war eine Plus-spezifische Anpassungsmöglichkeit; zusätzliche Skripte und Apps mit alten Einbindungen sind gesondert zu erfassen. Der vergangene Termin allein beweist keine erfolgreiche Migration eines konkreten Shops.

Unter Einstellungen → Checkout zeigt der Konfigurationsbereich den tatsächlichen Stand. Ein verbleibender Upgradehinweis bedeutet laut Shopify noch veraltete Seiten. Der persönliche Upgradeguide erfasst vorhandene Anpassungen, kompatible und inkompatible Apps sowie Tracking. Seit dem 28. August 2025 ist der Bereich für zusätzliche Skripte nur noch lesbar; diese frühere Änderung ist von der Seitenfrist 2026 zu unterscheiden.

Ein Theme-Export allein ist keine vollständige Inventur. Zusätzliche Skripte aus den Checkout-Einstellungen, App-Pixel und ein separat verwalteter Tag-Manager-Container benötigen eigene Prüfungen. Ein Tag-Manager-Container bündelt Messskripte und Regeln für deren Auslösung. Dieser Container hilft nur, wenn das Laden auf der neuen Bestätigungs- oder Bestellstatusseite tatsächlich funktioniert. Shopify sieht passende Blöcke, Web-Pixel und App-Pixel für die jeweiligen Aufgaben vor; vorhandener Browsercode lässt sich nicht grundsätzlich unverändert übertragen.

Zum Abschluss gehört ein kontrollierter Testkauf mit dokumentierter Einwilligungssituation. Bestellkennung, Währung, Wert und Kaufereignis müssen im vorgesehenen Ziel nachvollziehbar sein; erneutes Laden der Statusseite darf keine unerwünschte zweite Conversion erzeugen. Eine Bestellung in Shopify und ein gemessener Kauf in einer Werbeplattform sind verschiedene Nachweise.