App+Web Ecommerce Daten mit Enhanced E-Commerce (EEC) Implementierung

App+Web Properties sind immer noch im beta Status, aber deren Funktionsumfang wächst kontinuierlich. Ein Ersatz für Universal Analytics sind sie noch (lange) nicht. Aber der Rollout der eCommerce Funktionalität macht natürlich neugierig. Für App+Web wird ein anderes (neues) Schema als das EEC Schema benötigt, jedoch können App+Web auch mit EEC Implementierungen umgehen, auch wenn dabei etwas Hilfe des Tag Managers benötigt wird.

Das neue App+Web eCommerce Schema

Das neue App+Web eCommerce Schema stellt im Wesentlichen eine Vereinheitlichung dar. So werden eCommerce Events (Poduktklick, Add-To-Cart, Kauf) durch vordefinierte Events abgebildet. Das kennen wir so bereits aus Firebase (heißt ja auch App+Web 😉 ). Die folgenden eCommerce Events gibt es vordefiniert:

Eventname	Beschreibung
view_item_list	Ansicht eines Produktes in der Produktliste
select_item	Klick eines Produktes in einer Liste
view_promotion	Interne Promotion gesehen
select_promotion	Interne Promotion geklickt
view_item	Aufruf der Produktdetailseite
add_to_cart	Hinzufügen eines Produktes zum Warenkorb
add_to_wishlist	Hinzufügen eines Produktes zur Wunschliste (kein Bestandteil von EEC)
remove_from_cart	Entfernen eines Produktes aus dem Warenkorb
view_cart	Ansicht des Warenkorbs (kein Bestandteil von EEC)
begin_checkout	Beginn des Checkouts (Entspricht EEC checkout step 1)
add_shipping_info	Hinzufügen der Versandoption (konnte bisher in EEC chcekout über option abgebildet werden)
add_payment_info	Hinzufügen der Zahlungsmethode (konnte bisher in EEC checkout über option abgebildet werden)
purchase	Bestellung
refund	Erstattung

Da eine bestehende EEC Implementierung genutzt werden soll, nutzen wir die bereits vorhanden Events. (Jede Implementierung ist allerdings unterschiedlich, so dass ggf. bei einigen die Events bereits abgebildet sind oder auch fehlen. Refunds lasse ich auch unberücksichtigt, da diese meist nicht implementiert sind.)

Die Produktdaten werden pro Event einfach als Event-Parameter items mitgegeben. Das Format von items entspricht zwar nicht dem Format von EEC, aber App+Web ist diesbzgl. abwärtskompatibel.


'event', 'add_to_cart', {
  'items': [
    {
      'item_id": "12345",
      'item_name": "Produktname",
      'item_brand": "Produktmarke",
      'item_category": "Kategorie",
      'item_variant": "Variante",
      'quantity": 1,
      'price": '20.00'
    }
  ]
}

Gegenüber dem EEC Schema gab es einige Umbennungen, aber auch einige neuen Optionen im Schema der Produktdaten (siehe hier). Aber App+Web kann auch mit den bestehenden EEC-Produktdaten umgehen.

Nur bei drei Events reicht die Kombination von Eventname und dem Event-Parameter “items” nicht aus: “add_payment_info”, “purchase” und “refunds”.

“add_payment_info” erwartet “payment_type” als Event Parameter und ggf. “value” (entspricht revenue im EEC Schema) und “currency”.

“purchase” erwartet wie im EEC Schema weitere Event-Parameter und enthält auch optionale Parameter. “Refunds” kann entweder die Transaktions-Id enthalten (vollständige Erstattung) oder zusätzlich die Produktinformationen in “items” über erstattete Produkte.

Gegenüber dem EEC Schema gab es einige Umbenennungen, aber ebenso einige neuen Optionen im Schema der Produktdaten (siehe hie r). Aber App+Web kann auch mit den bestehenden EEC-Produktdaten umgehen.

EEC Schema nach App+Web senden

Sollen nun EEC Implementierungen für App+Web genutzt werden, ist das recht einfach umzusetzen. Damit nicht für jedes Event ein separates Tag erstellt werden muss, werden die Tags, die keine gesonderten Parameter benötigen, gesamt in ein Tag implementiert.

Für den Fall das noch kein Configuration-Tag vorhanden ist, wird dies zuerst konfiguriert, so dass es beim Seitenaufruf (und natürlich nach Consent 😉 ) ausgelöst wird und einen Pageview auslöst. Die Measurement ID ist bei App+Web nicht die Property ID, sondern die ID des Streams.

Um IP-Anonymisierung muss sich ebenfalls nicht gekümmert werden. App+Web Properties anonymisieren die IP standardmäßig.

Zuerst werden einige DataLayer Variablen benötigt, die den Pfad der Produktdaten im EEC Schema wiedergeben. Dieser variiert leicht je nach EEC-Event, daher werden mehrere benötigt. (Es gibt auch Möglichkeiten dies in einer Variable zu vereinen, Um das Case einfach zu halten, gehe ich hier so vor):

ecommerce.add.products

ecommerce.checkout.products

ecommerce.click.products

ecommerce.detail.products

ecommerce.impressions

ecommerce.promoClick.promotions

ecommerce.promoView.promotions

ecommerce.purchase.products

ecommerce.remove.products

Nun werden folgende zwei Lookup Tables angelegt. Der erste gibt die Bezeichnung des vordefinierten Events für App+Web wieder. Dadurch können diese Events in einem Tag verarbeitet werden. Der linke Bereich des Lookup-Tables muss durch die Benennung des jeweiligen Events in der EEC Implementierung ersetzt werden.

Der zweite Lookup Table liest basierend auf dem Event die Daten für “items” zurück. Dafür wird die passende dataLayer Variable zum Event zugeordnet.

Im Lookup Table ist bei dem jeweiligen Event die Produktinformation vorhanden.

Für das Event “begin_checkout” ist eine weitere Besonderheit zu beachten. Das EEC Checkout Event ist in der Standard Implementierung auf jeder Checkout Seite vorgesehen. Checkout-Seiten werden anhand des “step”-Eintrages unterschieden. Da nun nur der Einstieg in den Checkout mit “begin_checkout” gemessen wird, benötigen wir eine dataLayer-Variable, die den Step in der EEC Checkout Implementierung zurückliefert.

ecommerce.checkout.actionField.step

Nun wird der Trigger für EEC Checkout kopiert und mit Bedingung versehen, das dieser nur im ersten Schritt auslöst. Das Custom Event muss ggf. an die EEC Implementierung angepasst werden.

Das Tag kann nun mit erstellt werden.

Alle Trigger außer dem Trigger für Käufe und “add_payment-info” können nun an das Tag angebunden werden.

Für den Kauftrigger benötigen wir noch weitere Informationen, wie oben aufgeführt. Wieder werden die Informationen aus dem EEC Objekt für purchase ausgelesen, diesmal hauptsächlich aus dem Feld actionField. Dafür werden die folgenden dataLayer Variablen angelegt:

ecommerce.purchase.actionField.affiliation

ecommerce.purchase.actionField.coupon

ecommerce.currencyCode

ecommerce.purchase.actionField.id

ecommerce.purchase.actionField.revenue

ecommerce.purchase.actionField.shipping

ecommerce.purchase.actionField.tax

Dann kann das Tag mit dem entsprechenden Trigger und den Event-Parametern angelegt werden:

In der EEC Implementierung wird häufig im Checkout im Feld “option” die Zahlungsmethode hinterlegt. Um diese auszulesen, wird die folgende dataLayer Variable verwendet:

ecommerce.checkout.actionField.option

Nun kann der Trigger angelegt werden, der das Tag auslöst, wenn option gesetzt wird. Das Tag sieht dann entsprechend so aus (bei Bedarf können noch weitere Informationen wie coupon, value oder currency übergeben werden):

Und wir sind soweit fertig.

Testen der Implementierung

Nachdem die Vorarbeit getan ist, ist es sinnvoll, die Implementierung zu testen. Hierfür kann der debug_mode genutzt werden. Hierfür wird debug_mode=true in das Configuration Tag geschrieben.

Im Preview Modus des Google Tag Managers kommen die Daten in der App+Web Property im Debug View an. Die Verzögerung ist etwas größer als im Universal Analytics Realitme View.

Leider werden (derzeit?) die Daten des Event-Parameters “items” dort nicht angezeigt.

Allerdings können die Hits inkl. der Produktdaten in der Browserconsole geprüft werden. Entgegen dem Tracker von Universal Analytics sind die Hits für App+Web nur noch auf Produktebene in Key-Value Pairs getrennt, nicht mehr auf Eigenschaftenebene.