Die Migration von Adobe Analytics zu Customer Journey Analytics bietet eine Chance, Ihre Daten-Workflows zu modernisieren. Durch die Verwendung der CJA-API mit Python und Databricks automatisierte unser Team die SDR-Erstellung, überwachte die Akzeptanz von Dashboards und optimierte die Verwaltung freigegebener Metriken.

Einer der wichtigsten Meilensteine auf unserer Digital-Analytics-Journey ist die Migration von Adobe Analytics (AA) zu Customer Journey Analytics (CJA). Dies ist nicht nur ein technisches Upgrade, sondern auch ein strategischer Schritt in eine flexiblere, abfragbare Echtzeit-Analysewelt, die auf Adobe Experience Platform aufbaut.

Die Migration bietet die Möglichkeit, nicht nur einen bestehenden Analyse-Stack in CJA zu replizieren, sondern ihn auch besser zu überdenken und neu aufzubauen. Eine der Stützen dieser Migration ist die CJA-API, insbesondere bei Verwendung in Kombination mit dem hervorragenden, von Adobe entwickelten Python-Wrapper cjapy.

Dieser Blogpost beleuchtet drei reale Anwendungsfälle, bei denen die API zur Skalierung, Automatisierung und Verbesserung eines Analyse-Setups beigetragen hat. Alle Beispiele verwenden Databricks, um Python-basierte Workflows auszuführen.

Anwendungsfall 1: Generieren einer neuen Solution Design Reference (SDR)

Eine Migration ist der perfekte Zeitpunkt, um die Solution Design Reference (SDR) zu überdenken. Anstatt die alte SDR 1:1 zu kopieren, kann diese Phase verwendet werden, um eine saubere, moderne SDR zu erstellen, die mit der Logik von CJA und neuen Funktionen wie schemabasiertem Tracking im Einklang ist.

Der cjapy-Wrapper hat den Prozess erheblich vereinfacht, da er vorgefertigte Funktionen zum Abrufen von Metadaten aus unseren CJA-Datenansichten (z. B. Metriken und Dimensionen) bereitstellt. Diese Informationen können dann in eine SDR-Vorlage formatiert werden, was einen schnellen und präzisen Ausgangspunkt bietet.

Anwendungsfall 2: Überwachung von Auditprotokollen für Dashboard-Nutzung

Wir glauben fest an Self-Service-Analysen. Aber Self-Service funktioniert nur, wenn die Menschen tatsächlich das nutzen, was verfügbar ist – und wenn sie es wertvoll finden.

Um die Akzeptanz zu überwachen, verwenden wir die CJA-Auditprotokoll-API, um Nutzungsdaten in Databricks abzurufen.

basic request for audit logs
audit_logs = cja.getAuditLogs(

Abbildung 1: Datenrahmen aus Auditprotokollen

Mit diesem Setup können wir Folgendes verfolgen:

• Welche Dashboards (also „Projekte“) geöffnet werden
• Von wem
• Wie oft

Abbildung 2: Nutzungs-Dashboard in Databricks

Dieses Dashboard bietet uns klaren Einblick in Akzeptanz-Trends und hilft uns zu verstehen, welche Dashboards regelmäßig aufgerufen werden. So zeigt es Bereiche an, in denen das Self-Service-Angebot funktioniert.

Diese Protokolle geben uns jedoch nur eine quantitative Ansicht und kein qualitatives Verständnis des Werts. Nur weil ein Dashboard häufig geöffnet wird, bedeutet das nicht, dass es verstanden wird bzw. vertrauenswürdig oder hilfreich ist. Ebenso kann ein Dashboard mit weniger Öffnungen einen wichtigen Zweck für eine kleine Zielgruppe erfüllen.

Um qualitative Verbesserungen zu erzielen, setzen wir auf Folgendes:

• Kurze Umfragen zu wichtigen Dashboards oder freigegebenen Metriken
• Benutzer-Interviews oder zielgerichtete Feedback-Runden mit Business-Teams
• Regelmäßige interne Überprüfungen mit Dashboard-Verantwortlichen, um Daten im Kontext zu interpretieren

Beachten Sie außerdem, dass Adobe Analysen zur Produktnutzung in der CJA-Benutzeroberfläche selbst bietet (siehe Überblick über die Produktnutzung).
Diese Funktion ist zwar hilfreich, wird derzeit jedoch nicht in CJA verwendet. Die Auditprotokoll-API erfüllt unsere Anforderungen besser, insbesondere aus folgenden Gründen:

• Datenminimierung
• Die (über CJA) abgerufenen Nutzungsdaten werden nicht zu den vertraglich vereinbarten Zeilenbeschränkungen in AEP (Gesamtdatenvolumen) gerechnet, da dadurch ein zusätzlicher Datensatz in AEP erstellt wird

Dieser API-basierte Ansatz ist zwar nicht perfekt, bietet aber eine skalierbare, kostengünstige Grundlage, um die Akzeptanz von Self-Service-Funktionen zu überwachen und Verbesserungen im Laufe der Zeit zu priorisieren.

Anwendungsfall 3: Verwalten freigegebener Dimensionen und Metriken sowie Abhängigkeitsprüfungen

Die Funktion freigegebene Dimensionen und Metriken von CJA ist ein wichtiger Vorteil für Data Governance und Konsistenz. Damit können wir die Bausteine für die Analyse definieren und so eine Abstimmung über Geschäftseinheiten und Dashboards hinweg sicherstellen.

Um sie jedoch korrekt und sauber über mehrere Datenansichten hinweg einzurichten, benötigen wir zunächst umfassende Erkenntnisse dazu, was tatsächlich verwendet wird.

Hier spielt die CJA-API in Kombination mit Databricks eine zentrale Rolle. Mithilfe der API extrahieren wir Metadaten auf Projektebene einschließlich:

• Welche Dimensionen und Metriken verwendet werden
• Auf welche Filter und berechneten Metriken verwiesen wird
• Alle verknüpften Komponenten, die die oben genannten verbinden

Dadurch erhalten wir ein detailliertes Verständnis dessen, was aktiv und notwendig ist.

Aktueller Prozess für die Planung freigegebener Komponenten

Derzeit sind freigegebene Dimensionen und Metriken noch nicht vollständig eingerichtet. Im Rahmen unserer Migration von Adobe Analytics (AA) zu Customer Journey Analytics (CJA) verfolgen wir einen strukturierten, API-basierten Ansatz:

1. Dashboards werden von AA zu CJA migriert, beginnend mit einer zentralen primären Datenansicht.
2. Nach Abschluss jeder Dashboard-Migration verwenden wir die CJA-API (über cjapy), um alle relevanten Metadaten abzurufen:
3. • Verwendete Dimensionen
   • Verwendete Metriken
   • Verwendete Filter und berechnete Metriken
   • Alle Komponenten sind über Ebenen verbunden Diese Metadaten werden dann in Databricks verarbeitet, wo wir Suchen und Normalisierung durchführen.
4. Das Ergebnis: eine konsolidierte Liste aller verwendeten Komponenten pro Dashboard.
5. Diese Liste wird in Excel exportiert, was uns einen klaren, manuellen Überblick gibt:
6. • Welche Dashboards welche Komponenten verwenden
   • Welche Komponenten von Kandidatinnen und Kandidaten als freigegeben gelten
   • Zu welcher Datenansicht jedes Dashboard gehört Nachdem alle Dashboards migriert und analysiert wurden, gehen wir folgendermaßen vor:
   • Wir geben die relevanten Dimensionen und Metriken mit den zugehörigen Datenansichten frei
   • Wir ordnen Dashboards von der primären Datenansicht zu den endgültigen, zielgerichteten Datenansichten neu zu

Durch die Kombination der Automatisierung (API), Zusammenarbeit (Excel) und Governance (freigegebene Komponenten) haben wir einen wiederholbaren und skalierbaren Prozess erstellt, der saubere, Self-Service-freundliche Datenansichten in CJA ermöglicht.

Abschließende Überlegungen

Die Migration zu CJA ist eine einmalige Gelegenheit, Ihren Analyse-Stack zu modernisieren. Die CJA-API bietet Ihnen (insbesondere in Kombination mit cjapy) die Tools zur Automatisierung, Überwachung und Skalierung Ihrer Arbeit auf eine Weise, die zuvor nicht einfach möglich war.

Die API ist ein strategisches Asset, unabhängig davon, ob Sie Ihre SDR neu erstellen, die Dashboard-Nutzung verfolgen oder freigegebene Komponenten einrichten. Uns hat ihre Kombination mit Databricks und Python großen Mehrwert bei der Erstellung flexibler, unseren Anforderungen entsprechenden Pipelines gebracht.