Es kommt immer wieder vor, dass besonders wichtige Trackingdaten (z.B. die Bestellstrecke eines Onlineshops) aufgrund von technischen Änderungen der Website oder der App nicht mehr erfasst werden. Oft fällt der Fehler dann sehr spät auf und auch das anschließende Debugging erfolgt dann manuell. Ich beschreibe hier deshalb eine Lösung die es ermöglicht die wichtigsten Daten automatisiert und kontinuierlich zu testen und zu monitoren. Damit fallen Trackingfehler sofort auf und können schnell behoben werden.
Dafür nutze ich den BigQuery Streaming Export in Google Analytics 4. Vom Auslösen eines Events bis zur Verfügbarkeit in BigQuery vergehen nur wenige Sekunden. Werden die GA4 Daten aus dem Universal Analytics EEC Object geholt, ist auch das Testen dieser Daten damit möglich. Schauen wir uns im Folgenden den Aufbau eines Tests für vier eCommerce Events an: view_item, select_item, add_to_cart, purchase.
Der Workflow
Um die Events zu testen, wird folgender Workflow genutzt:
Um das eCommerce Setup zu testen, wird ein Plugin genutzt, das den Browser steuert und die Tags im Google Tag Manager auslöst. Über den Big Query Streaming Export sind die Daten dann in Big Query verfügbar und werden anschließend in DataStudio visualisiert.
Browser-Steuerung mit Selenium IDE
Das Auslösen der Events soll automatisiert erfolgen. Hierfür verwende ich Selenium IDE für Chrome oder Firefox. Mit dem Plugin ist es einfach möglich, Abläufe im Browser aufzuzeichnen und regelmäßig ausführen zu lassen. In diesem Fall möchten wir die eCommerce Events view_item, select_item, add_to_cart, purchase regelmäßig prüfen. Nach dem Öffnen des Selenium Plugins, kann ein Test aufgezeichnet werden:
Um zu kennzeichnen, dass es sich um den Test für die EEC-Events handelt, wird die Startseite mit dem Query Parameter „?test“ ergänzt. Danach werden die Aktionen definiert und der Workflow gespeichert. Dabei sollte so vorgegangen werden, als würde das Setup manuell getestet werden.
Mit dem Klick auf Run kann der Test jederzeit gestartet werden:
Selenium orientiert sich bei den Aktionen an Attributen der HTML-Tags. Wenn sich diese ändern, kann der Test ggf. Nicht mehr korrekt ausgeführt werden. Dieser Test kann natürlich auch automatisiert in der GCP z.B mit Python und Selenium regelmäßig durchgeführt werden.
Die Daten des Tests erscheinen nun im BigQuery Intraday Table des Google Analytics 4 Projektes:
Daten in BigQuery finden
Um nun die Daten des letzten Tests zu extrahieren, wird der folgende Query verwendet:
SELECT event_name as eventname, items, TIMESTAMP_MICROS(event_timestamp) as time
FROM `<Project>.analytics_<id>.events_intraday_*` where user_pseudo_id=
(
SELECT user_pseudo_id FROM `<Project>.analytics_<id>.events_intraday_*`, unnest(event_params) as e where e.key="page_location" and e.value.string_value="https://demo.gmp-masterclass.de/?test" order by event_timestamp desc LIMIT 1
)
and
event_timestamp>=
(
SELECT event_timestamp FROM `<Project>.analytics_<id>.events_intraday_*`, unnest(event_params) as e where e.key="page_location" and e.value.string_value="https://demo.gmp-masterclass.de/?test" order by event_timestamp desc LIMIT 1
)
order by event_timestamp desc
Der Query gibt die Events und die passenden item Daten, also Produktdaten zurück, für die letzte user_pseudo_id (User Identifier) von der eine URL mit „?test“ aufgerufen wurde. Um das Vermischen von verschiedenen Tests zu verhindern, werden nur Events berücksichtigt, deren Timestamp größer ist als der des letzten Pageviews mit „?test“. Das Ergebnis des Queries sieht dann wie folgt aus:
Wir sehen als Ergebnis alle Events mit item-Parametern des letzten Tests.
DataStudio Datenvisualisierung
Nun möchten wir nicht nach jedem Test die Daten in BigQuery suchen. Datastudio bietet uns hier das passende Mittel zur Visualisierung. Wir bauen ein Dashboard, das auf den Workflow angepasst ist und den Test abbildet. Hierfür wird eine DataStudio Community Visualization eingesetzt und später direkt mit BigQuery verbunden:
Das Dashboard kann natürlich auch anders und mit mehr Design-Elementen gestaltet werden. Ich habe hier eine sehr rudimentäre Version gebaut. Es empfiehlt sich, den Code der Visualisierung an den Test anzupassen, also die Prüfung der Parameter direkt in DataStudio vorzunehmen. Dadurch ist das Dashboard flexibler. DataStudio Community Visualization bestehen im Wesentlichen aus folgenden Dateien:
- manifest.json die die Meta-Daten und Ressourcen URLs enthält
- Ein JSON-file für die Konfiguration der Einstellungen in DataStudio (Anzahl Dimensionen, Metriken, Styles, etc.), für dieses Projet viz.json genannt
- Einer CSS Datei für die Styling, hier viz.css
- einer Datei, die die Logik der Visualisierung enthält (Code in Javascript), sowie den Code der Data Studio Community Component Library dscc.js. Die dscc.js stellt die passenden Methoden zur Verfügung, eine DataStudio Community Visualization zu erstellen.
Kompletter Code dieser Visualisierung im Gitlab. Codelab zu DataStudio Community Visualizations
Für die DataStudio Community Visualization verwende ich folgenden Code (vereinfacht). DataStudio stellt für die Ausführung die passenden Daten in dem Array row[„Dimensionen“] (= Dimensionswerte), und data.fields[„Dimension“] (= Dimensionsnamen), vorgefiltert, segmentiert, etc. bereit:
var select_item=false;
var eec_viewitem=false;
var eec_addtocart = false;
var eec_purchase = false;
var select_item_array=['Select Item : false'];
var eec_viewitem_array=['Item View : false'];
var eec_addtocart_array=['Add to Cart : false'];
var eec_purchase_array=['Purchase : false'];
rowData.forEach(function (row, i) {
if (row["Dimension"][0]=="select_item")
{
select_item=true;
x=1;
while(x<row["Dimension"].length)
{
select_item_array.push(data.fields["Dimension"][x].name+" : "+row["Dimension"][x]);
x++;
}
}
if (row["Dimension"][0]=="view_item")
{
eec_viewitem=true;
x=1;
while(x<row["Dimension"].length)
{
eec_viewitem_array.push(data.fields["Dimension"][x].name+" : "+row["Dimension"][x])
x++;
}
}
if (row["Dimension"][0]=="add_to_cart")
{
eec_addtocart=true;
x=1;
while(x<row["Dimension"].length)
{
eec_addtocart_array.push(data.fields["Dimension"][x].name+" : "+row["Dimension"][x])
x++;
}
}
if (row["Dimension"][0]=="purchase")
{
eec_purchase=true;
x=1;
while(x<row["Dimension"].length)
{
eec_purchase_array.push(data.fields["Dimension"][x].name+" : "+row["Dimension"][x])
x++;
}
}
});
select_item_array[0]='Select Item : '+select_item;
eec_viewitem_array[0]='Item View : '+eec_viewitem;
eec_addtocart_array[0]='Add to Cart : '+eec_addtocart;
eec_purchase_array[0]='Purchase : '+eec_purchase;
Zuerst wird für jedes Element ein Boolean (false) und ein Array angelegt. Nun wird geprüft, ob ein Event vorhanden ist und falls ja, wird der Boolean auf true gesetzt und die Key-Value Pairs zu diesem Event in das passende Array geschrieben. (Der Code ist einfach gehalten, nicht optimiert und kann für den Produktiveinsatz deutlich verbessert werden, beispielsweise indem auch item Werte auf Vorhandensein geprüft werden).
Nun wird jedes Array Key-Value Pair in ein HTML-Element umgewandelt und an ein übergeordnetes HTML-Element, mit der ID des Boolean, gebunden. In der CSS-Datei ist für #true und #false ein entsprechendes Stylesheet hinterlegt, das entweder die Hintergrundfarbe Grün oder Rot erscheinen lässt. Zum Schluss wird dieses dann an das BODY-Element angehängt und es scheint in DataStudio.
var si = document.createElement('div');
si.id=select_item;
select_item_array.forEach(function(e)
{
var param = document.createElement('div');
param.innerHTML=e;
param.id="param"
si.appendChild(param)
});
var vi = document.createElement('div');
vi.id=eec_viewitem;
eec_viewitem_array.forEach(function(e)
{
var param = document.createElement('div');
param.innerHTML=e;
param.id="param"
vi.appendChild(param)
});
var atc = document.createElement('div');
atc.id=eec_addtocart;
eec_addtocart_array.forEach(function(e)
{
var param = document.createElement('div');
param.innerHTML=e;
param.id="param"
atc.appendChild(param)
});
var pp = document.createElement('div');
pp.id=eec_purchase;
eec_purchase_array.forEach(function(e)
{
var param = document.createElement('div');
param.innerHTML=e;
param.class="param"
pp.appendChild(param)
});
var eecobj=document.createElement('div');
eecobj.id="eec";
eecobj.appendChild(si);
eecobj.appendChild(vi);
eecobj.appendChild(atc);
eecobj.appendChild(pp);
document.body.appendChild(eecobj);Nun müssen die Files der DataStudio Community Visualization zur Verwendung in DataStudio in einen Google Cloud Bucket hochgeladen werden. In diesen Google Cloud Bucket wird nun dem User AllUsers Zugriff gewährt mit den Rechten Cloud Storage Viewer. Damit ist der Bucket öffentlich über seine URL erreichbar. In der manifest.json muss für unter „resource“ der Pfad für die einzelnen Dateien (js, config, css) im Bucket hinterlegt werden, beginnend mit gs:// .
Sind die Dateien im Google Cloud Storage Bucket verfügbar, kann nun in die DataStudio Community Visualization hinzugefügt werden.
- DataStudio Community Visualization auswählen
2. Build your own community visualisation auswählen
3. Pfad zur Visualisation hinzufügen, auswählen und Consent gewähren
4. Die DataStudio Community Visualization wird nun angezeigt, allerdings noch nicht konfiguriert:
Nun wird die Datenquelle BigQuery hinzugefügt:
und als Custom Query in unserem Projekt den bereits oben generierten Query:
DataStudio nutzt damit das Resultat des Queries als Datenquelle. Nach dem Klick auf Add, werden die vorhanden Felder angezeigt. Obwohl im Query nur item abgefragtg wird, sind alle Felder in diesem Aobjekt einzeln vorhanden:
Bei jedem Anfragen der Daten durch DataStudio wird damit der Query ausgeführt. Hinweis: Die Ausführung des Queries durch DataStudio wird zu Kosten im Rahmen des BigQuery Projektes führen.
Nun müssen nur noch die Dimensionen im DataStudio Panel ergänzt werden. Gemäß dem Quellcode oben, wird auf Position 1 der Eventname erwartet, danach die item Paramter:
Damit ist unser Dashboard fertig. Führen wir nun den Test aufgezeichneten Test aus:
Das Ergebnis in DataStudio:
Nun wird das Add to Cart Tag im Tag Manager pausiert und der Test neu gestartet:
Für wiederkehrende Tests, beispielsweise vor dem Launch einer Website, in der Entwicklung oder beim Auto-Event-Tagging bietet sich ein automatisiertes Vorgehen an, auch wenn der initiale Aufwand zur Anpassung des Codes recht hoch ist.
1 thought on “GA4 Recipes: Automatisiertes Testen der Google Analytics Implementierung”