Blog

WooCommerce: Bewertungen verschieben

michael · 15. März 2021 · Leave a Comment

Bewertungen sind ein wichtiger Vertrauensfaktor im E-Commerce. Sie sind häufig maßgeblich für eine Kaufentscheidung. Das gilt umso mehr, je unbekannter das verkaufte Produkt oder die jeweilige Marke ist. Nicht nur aus diesem Grund bietet es sich an, die Bewertungs-Funktion in WooCommerce zu nutzen.

Gleichzeitig lebt ein Online-Shop auch. Neue Produkte kommen hinzu, bestehende bearbeitet und alte gelöscht. Häufig wird auch der Aufbau des Shops verändert um beispielsweise die Kundenführung zu verbessern. Dann kann es vorkommen, dass etwa mehrere Einzelprodukte in ein variables Produkt zusammengefasst werden.

Hat das „alte“ Produkt dann eine Bewertung, möchte man diese natürlich in das neue Produkt mit übernehmen. Nur: Wie kann man eigentlich Bewertungen in WooCommerce-Produkten von einem Produkt in ein anderes übertragen?

Technischer Hintergrund: Bewertungen sind auch nur Kommentare

Aus technischer Perspektive sind WooCommerce-Bewertungen auch nur WordPress-Kommentare. Sie werden in der Datenbank genau wie Kommentare auf Blogbeiträgen oder Seiten abgespeichert. Sie landen in der Datenbank-Tabelle „wp_comments“. Zusätzlich werden noch sogenannte „Metainformationen“ für das Kommentar angelegt, um die Anzahl der Sterne abzuspeichern. Diese Informationen finden sich in der Tabelle „wp_commentmeta“.

Bewertungen mittels Plugin verschieben

Datenbank, Tabelle, Bahnhof? Klingt alles sehr technisch und kompliziert? Der große Vorteil: WooCommerce-Bewertungen lassen sich auch fast genau so wie Kommentare von Blogbeiträgen verschieben. Und dafür gibt es einige Plugins im WordPress-Repository. Ein wirklicher „Plugin-Sieger“ sticht nicht heraus, aber ein Beispiel ist „Copy or Move Comments“.

Spezifisch für WooCommerce-Bewertungen gibt es auch ein kostenpflichtiges Plugin. Das schlägt mit – zum Zeitpunkt der Entstehung dieses Blogs-Posts – rund 19 USD zu Buche. Weshalb sich dieses Plugin lohnen kann, wird spätestens im übernächsten Absatz klar. Denn leider ist der Job mit der einfachen „Verschiebung“ von Kommentaren nicht erledigt. Das Plugin selbst habe ich aber nicht ausprobiert, es ist aber vermutlich die einfachste Alternative für technisch wenig versierte Nutzer.

Bewertungen und Kommentare direkt in der Datenbank verschieben

Wer sich technisch etwas auskennt, kann die Bewertungen auch direkt in der Datenbank verschieben. Dazu benötigen wir die ID des entsprechenden Kommentars (der Bewertung) sowie die ID des zukünftigen Produkts.

Wichtig: Änderungen an der Datenbank sollten nur Personen mit mindestens einem Grundverständnis der Technik vornehmen. Falsche Änderungen in der Datenbank können massive Fehler – bis zum Ausfall der Webseite – hervorrufen.

Die ID des Kommentars bzw. der Bewertung finden wir am einfachsten im Backend unter „Kommentare“ heraus. Bearbeiten wir ein Kommentar, so wird die ID als GET-Parameter in der Browserzeile angezeigt. Oder natürlich direkt im Permalink 😉

Die ID des Kommentars wird in der Browserzeile angezeigt

Nach der ID suchen wir in der Tabelle „wp_comments“. In der Spalte „comment_post_ID“ wird die ID des neuen Produkts eingetragen. Wichtig: Gibt es auf eine Bewertung eine oder mehrere Antworten (also Kommentare als Antwort), so müssen auch in diesen Einträgen die Fremdschlüssel in der Spalte comment_post_ID aktualisiert werden.

Problem: Anzahl der Bewertungen, Bewertungsdurchschnitt, Bewertungsstruktur aktualisieren sich nicht

Leider war das nur die halbe Miete. Wer jetzt die Seite des neuen Produkts aktualisiert, wird feststellen, dass sich die Zahl der Bewertungen nicht verändert hat. Hat da etwas nicht geklappt? Vermutlich schon, denn die Bewertung wird tatsächlich im neuen Produkt angezeigt.

WooCommerce speichert aber die Anzahl der Bewertungen unabhängig von der Zahl der „tatsächlichen“ Bewertungen fest ab. Das hat mehrere Gründe: Zum einen wird die Webseite dadurch performanter (es muss nicht jedes Mal die Zahl der Bewertungen berechnet werden). Zum anderen gibt es auch noch weitere „Metriken“ wie die durchschnittliche Bewertung sowie die Verteilung der Bewertungen (10x 5 Sterne, 8x 4 Sterne, usw.). Müsste das System bei jedem Seitenaufruf all diese Berechnungen anstellen, so wäre es schlicht langsamer. Und schließlich mag niemand einen langsamen Online-Shop. Randbemerkung für alle technisch Versierten: Ja, mit Caching kann man dem Problem natürlich begegnen – und ja, ob ein Datenbank-Aufruf der Meta-Informationen effizienter ist als ein einmaliger Aufruf aller Bewertungen des Produkts und eine anschließende Berechnung in PHP sei dahin gestellt.

Wir müssen also die Zahl der Bewertungen, die durchschnittliche Bewertung sowie die Bewertungsstruktur noch aktualisieren. Diese Informationen werden als Meta-Informationen zum eigentlichen Produkt abgespeichert. Wir benötigen also wieder die ID des Produkts. Anschließend suchen wir in der Tabelle „wp_postmeta“ nach der entsprechenden „post_id“. Letztlich aktualisieren wir dann die „meta_key“-s mit den Schlüsseln „_wc_rating_count“, „_wc_review_count“ und „_wc_average_rating“. Die entsprechenden Neuberechnungen muss man leider von Hand anstellen – außer man schreibt sich ein passendes Skript.

Die Anzahl der Bewertungen, der Bewertungsdurchschnitt sowie die Bewertungsstruktur müssen von Hand angepasst werden – sie sind in den Produkt-Metadaten abgespeichert

Doch nicht so einfach: Anzahl der Bewertungen, Bewertungs-Durchschnitt und

Fazit: Alles doch nicht so einfach…

Wer technisch versiert ist, kann sich auch selbst an die entsprechenden Änderungen in der Datenbank machen. Normale „Endanwender“ tun sich vermutlich einen Gefallen, wenn sie entweder einen Experten beauftragen (Ich kann das für Sie erledigen) oder auf das (von mir nicht getestete) Plugin setzen. Mit einer einfachen Verschiebung von Kommentaren ist es leider nicht getan.

WooCommerce: „Telefonnummer“ als optional markieren

michael · 3. Februar 2021 · Leave a Comment

In manchen WooCommerce-Installationen wird das Feld „Telefonnummer“ als verpflichtend bzw. erforderlich markiert. Teilweise ist das auch für die Felder „Firmenname“ und „Adresszeile 2“ der Fall.

Sicherlich gibt es einige wenige Fälle, in denen die Angabe einer Telefonnummer dringend notwendig ist. Meistens sollte man diese Felder aber eher als optional markieren. Je mehr Felder der Kunde zwingend ausfüllen muss, desto länger dauert der Checkout. Das erhöht die Wahrscheinlichkeit, dass der Kunde auf den letzten Metern bis zum Umsatz doch noch abspringt.

Tatsächlich sind die Felder „Telefon“, „Firmenname“, „Adresszeile 2“ eigentlich auch standardmäßig optional. Was aber, wenn die Felder dennoch als „Pflichtfeld“ markiert sind?

Plugins als Ursache für Pflichtfelder

Häufig ist in solchen Fällen ein Plugin schuld. Ein problematischer Kandidat (der im Übrigen recht häufig Ärger bereitet…) ist das Plugin „WooCommerce PayPal Express Checkout Gateway“. Im konkreten Fall wurde bei der Kundin im Checkout plötzlich – ohne jegliches Zutun – das entsprechende Telefon-Feld als verpflichtend markiert.

Zum Glück ist das Problem einfach lösbar. Im Backend (also der Verwaltungsoberfläche von WordPress bzw. Deines Shops) gehst Du auf „Design“ > „Customizer“. Jetzt im Customer kannst Du „WooCommerce“ > „Kasse“ auswählen. Hier gibt es jetzt drei Felder, mit denen man die entsprechenden Felder auf optional setzen kann.

Auf diese Option bin ich dank des entsprechenden Github-Issues aufmerksam geworden. Immerhin bin ich nicht der einzige, der nicht unbedingt von „WooCommerce PayPal Express Checkout Gateway“ begeister ist.

Weitere Möglichkeiten

Dein Kasse-Feld ist trotzdem ein Pflichtfeld, aber Du hast das Plugin nicht installiert? Dann kann es möglicherweise auch an einem anderen Plugin liegen. Hast Du vielleicht ein Plugin installiert, dass den Checkout verändert? Kandidaten sind hier zum Beispiel „Checkout Manager for WooCommerce“ oder „Checkout Field Editor for WooCommerce“. Häufig kann man Probleme lösen, indem man Plugins Stück für Stück deaktiviert, um so den Übeltäter zu finden.

Code-Anpassung als letzter Ausweg

Es klappt immer noch nicht? Als letzten Ausweg kann auch etwas Code geschrieben werden, um das Feld ein für alle Mal als „optional“ zu markieren. Diesen Code musst Du dafür in einem eigenen (!) Plugin oder eigenem (!) Child-Theme hinzufügen. Es ist wichtig, ein eigenes Plugin oder Theme zu erstellen. Nutzt Du ein schon vorhandenes Plugin oder Theme, werden die Änderungen beim nächsten Update des Theme- oder Plugin-Autors einfach überschrieben – und das Problem ist wieder vorhanden.

<?php

function mn_remove_filter_phone ( $billing_fields ) {
  $billing_fields['billing_phone']['required'] = false;
  return $billing_fields;
}

add_filter( 'woocommerce_billing_fields', 'mn_remove_filter_phone', 10, 1 );

?>

Python pathlib: Forward-Slash statt Backward-Slash ausgeben

michael · 26. Januar 2021 · Leave a Comment

Die Verwendung von Python’s pathlib hat einige Vorteile gegenüber der „traditionellen“ Arbeit mit os.path. Dazu gehören unter anderem Interoperabilität zwischen Unix- und Windows-Systemen, aber auch viele hilfreiche Funktionen wie Path.is_dir(), Path.is_file() und so weiter. In meinen Augen hilft auch die „Slash“-Schreibweise bei Pfadangaben der Übersichtlichkeit. Eine gute Übersicht gibt es in den Artikeln von Trey Hunner (englisch).

Leider sind nicht alle Python-Bibliotheken mit Pathlib kompatibel – und erst recht nicht dann, wenn Pathlib unter Windows eingesetzt wird. In diesem Fall verwendet Pathlib (korrekterweise) automatisch einen Backslash („\“) als Trennzeichen. Das kann dann aber wieder zu Problemen führen – etwa mit der wfdb-Bibliothek, die zur Anzeige von Physionet-Daten verwendet werden kann.

Der folgende Code quittiert etwa unter Windows mit der Fehlermeldung „AttributeError: ‚WindowsPath‘ object has no attribute ‚endswith'“ seinen Dienst:

data_folder = Path("D:/Data").resolve()
path_pathlib = (data_folder / "mimic3wdb-matched-1.0.physionet.org" / "matched" / "matched" / "p00" / "p000020" / "p000020-2183-04-28-17-47n")
record = wfdb.rdrecord(path_pathlib)

Gibt man den Inhalt der Variable path_pathlib aus, stellt man fest, dass der Pfad mittels Backslashes getrennt wird. Damit kommt wfdb offensichtlich nicht zurecht.

D:\Data\mimic3wdb-matched-1.0.physionet.org\matched\matched\p00\p000020\p000020-2183-04-28-17-47n

Lösung: Etwas versteckt in der pathlib-Dokumentation (python.org, readthedocs.io) findet sich die Funktion „as_posix()“. Damit lässt sich der Pfad im Posix-Style mit „Forward-Slashes“ ausgeben und das Problem ist gelöst.

PurePath.as_posix()
Return a string representation of the path with forward slashes (/):

WooCommerce: Hausnummer im Kaufprozess abfragen

michael · 16. November 2020 · Leave a Comment

Das WordPress-Shop-Plugin WooCommerce kennt standardmäßig keine Hausnummern. Im Gegensatz zu vielen anderen Shopsystemen setzt es nur auf eine „Adresszeile 1“ und eine „Adresszeile 2“. Für viele Shops dürfte das letztlich keinen Unterschied machen – hier und da kann die fehlende Hausnummerabfrage aber zu Problemen führen. Das ist insbesondere der Fall, wenn:

Nachgeschaltete Dienstleister (und deren APIs) wie etwa DHL explizit nach einer Hausnummer fragen
Kunden vergessen, eine Hausnummer anzugeben (und dadurch häufige Nachfragen notwendig sind)

Hausnummer – ja oder nein?

Auf den ersten Blick scheint die Entscheidung gegen die explizite Verwendung eines Hausnummern-Felds überraschend und nicht nachvollziehbar. Es gibt aber auch gute Gründe für diese Entscheidung:

Conversion-Rate: Je mehr Felder ein Checkout hat, desto länger dauert der Kaufprozess und desto mehr Kunden können potenziell abspringen
Internationalisierung: Andere Länder, andere Sitten – in den USA z.B. sind Hausnummern häufig vorangestellt („123 Example St.“) – das müsste auch beim Layout berücksichtigt werden

Ansätze zur Problemlösung

Letztlich gibt es mehrere Ansätze, um das Problem zu beheben. Abhängig ist das vor allem vom Ursprungsproblem.

Im Fall von nachgeschalteten APIs lässt sich die Adresszeile 1 nachträglich z.B. durch Drittsoftware oder ein eigenes Plugin in eine Straße und eine Hausnummer „zerlegen“. Das kann man etwa mittels regulärer Ausdrücke (RegEx) umsetzen. Eine solche Lösung habe ich vor einigen Jahren für eine eigene Bestellverwaltungs-Plattform umgesetzt. Vorteil: Der schlanke Kaufprozess bleibt erhalten. Nachteil: Um wirklich alle Länder dieser Welt abzudecken, sind mehrere dutzend RegEx-Ausdrücke notwendig. Interessante Randfälle sind z.B. die „Straße des 17. Juni XYZ“ in Berlin, „N5 6+7“ in Mannheim, die „Herbortgasse 38/3/XYZ“ in Wien oder diverse (deutlich lebhafter umschriebene) Adressen in Spanien. Statt RegEx kann man natürlich auch auf Machine Learning setzen – aber wir wollen die Kirche ja im Dorf lassen ;-). Auch dafür gibt es mittlerweile Ansätze, z.B. AddressNet.

Kunden vergessen oder übersehen schlichtweg, dass in der Adresszeile 1 auch eine Hausnummer mit anzugeben ist? Dann ist es am einfachsten, das bestehende Feld deutlicher zu kommunizieren. Je nach verwendeter Shop-Konfiguration (Theme und Plugins) kann es vorkommen, dass zwar im Checkout-Feld selbst als „Placeholder“ von „Straße und Hausnummer“ die Rede ist, das eigentliche „Label“ aber nur von der Straße spricht. Dann kann man auch dem Kunden nicht wirklich einen Vorwurf machen.

Screenshot der Adresseingabe aus WooCommerce — Als Placeholder im HTML-Code ist zwar auch die Hausnummer verlangt – im entsprechenden Label taucht diese aber nicht auf. Das kann Kunden verwirren.

Hausnummerangabe verdeutlichen und klarer herausstellen

Wer einfach die Notwendigkeit der Hausnummer-Angabe verdeutlichen möchte, kann das mit wenigen Codeschnipseln erledigen. Der entsprechende Code wird etwa in ein eigenes Plugin kopiert. Bei Verwendung in der functions.php eines Themes muss man aufpassen, dass diese Datei unter Umständen bei Updates überschrieben wird.

<?php

add_filter( 'woocommerce_default_address_fields' , 'mn_override_street_field' );

// Our hooked in function - $address_fields is passed via the filter!
function mn_override_street_field( $fields ) {
     $fields['address_1']['label'] = "Straßenname und <b>Hausnummer</b>";
     return $fields;
}

?>

Im o. g. Beispiel wird noch der Zusatz „und Hausnummer“ an den Straßennamen gehängt. Achtung: Wer einen mehrsprachigen Shop betreibt (oder das ganze möglichst sauber umsetzen will), muss die WordPress bzw. i18n-Übersetzungs-Funktion nutzen und sich passende Sprachdateien erstellen.

Übrigens lassen sich so auch alle anderen Felder umbenennen. Es gibt mehrere Hooks, die in Frage kommen: woocommerce_default_address_fields (für alle Pflichtangaben) sowie woocommerce_billing_fields bzw. woocommerce_shipping_fields. Details dazu in der englischsprachigen WooCommerce-Referenz. Bei kundenspezifischen Implementierungen und Entwicklungsarbeiten unterstützte ich gerne.

Screenshot der Hausnummer-Abfrage in WooCommerce — Besser: Die Hausnummer ist deutlich hervorgehoben.

Hinzufügen der Hausnummer in WooCommerce

Natürlich gibt es Fälle, bei denen explizit eine eigene Hausnummerangabe notwendig wird. Dazu gibt es mehrere Möglichkeiten. Bei allen diesen Möglichkeiten muss man auf seine persönliche Shop-Konfiguration achten. Andere verwendete Plugins (z.B. Versand- oder Zahlungsdienstleister) verwenden unter Umständen weiterhin nur „Adresszeile 1“. Hier fehlt dann schlichtweg die Hausnummer, wenn diese in ein eigenes Feld eingegeben wird!

Hinzufügen der Hausnummer mittels Plugin

Am einfachsten geht es über das Plugin „Checkout Field Editor (Checkout Manager) for WooCommerce“. Hier lassen sich einfach und auch ohne Programmierkenntnisse entsprechende Felder hinterlegen. Das Plugin ist ziemlich selbsterklärend. Allerdings gibt es Nachteile: Jedes Plugin verlängert Ladezeilen, kann für Inkompatibilitäten sorgen und muss gewartet werden.

Hinzufügen der Hausnummer durch Code

Die Verwendung angepassten Codes setzt natürlich zumindest einfache Programmierkenntnisse voraus. Dafür lässt sich Ladezeit sparen. Natürlich muss aber auch dieser Code gewartet werden.

Auf der Seite businessbloomer.com finden sich mehrere Codeschnipsel, wie sich ein zusätzliches Hausnummern-Feld hinzufügen lässt. Nachteil: Das Layout des neuen Felds ist noch nicht optimal: Es wird in der „gesamten Breite“ angezeigt. Hier sind noch Feinarbeiten notwendig.

Cookie-Banner mit DSGVO-konformen Opt-In direkt in Google Tag Manager (GTM) erstellen

michael · 9. Oktober 2020 · Leave a Comment

Laut Datenschutz-Grundverordnung ist es notwendig, bei der Verwendung von Marketing- und Werbe-Cookies explizit ein Einverständnis des Nutzers einzuholen. Dafür gibt es unterschiedliche technische Lösungen – von CMS-Plugins bis hin zu kostenpflichtigen, professionellen JavaScript-basierten Lösungen.

Für die Einbindung von Marketing-Tags ist der Google Tag Manager eine häufig verwendete Lösung. Er vereinfacht die Verwaltung einer Vielzahl von Tags. Persönlich nutze ich ihn vor allem in Kombination mit Google Analytics und Google Optimize.

Ein einfaches Cookie-Banner in der Mobilansicht

Mit wenigen Codezeilen lässt sich auch ein einfacher Cookie-Banner in Google Tag Manager realisieren. Wichtig ist dabei, dass alle Marketing-Tags erst nach „Akzeptieren“ des Banners geladen werden (Optin). Möglich wird dies durch die Verwendung des DataLayer von Google Tag Manager. Vorteile sind eine geringe Codegröße, dadurch schnellere Ladezeiten und vor allem der Verzicht auf CMS-Plugins, die einen Einfluss auf Ladezeit haben und potenziell Sicherheitslücken hervorrufen können.

Im folgenden wird davon ausgegangen, dass bereits ein Google-Analytics-Tag in Google Tag Manager angelegt ist und mit dem Trigger „All Pages“ ausgelöst wird (d.h. nicht datenschutzkonform eingebaut ist).

Schritt 1: Cookiebanner-Tag anlegen

Zu Beginn wird in Google Tag Manager ein neues „Benutzerdefiniertes HTML-Tag“ angelegt. Benannt kann es etwa mit „Cookie-Banner-Tag“ werden, als Trigger wird der „All Pages“-Trigger verwendet. Dadurch wird das HTML-Tag bei jedem Seitenaufruf geladen.

Screenshot des "Neuer Tag"-Bildschirms — Das Cookiebanner-Tag enthält die eigentliche Cookiebanner-Funtionalität

Folgender Code wird unter „HTML“ eingefügt. Wichtig ist, in Zeile 44 und 59 die eigene Domain einzufügen. In Zeile 59 sollte der Punkt vor dem Domainnamen bestehen bleiben. Eine detaillierte Erklärung des Codes folgt im letzten Abschritt des Artikels. Anschießend kann das Tag gespeichert werden.

<style>
.cookie-banner {
  padding: 0.5em;
  position: fixed;
  z-index: 9999999;
  bottom: 0;
  background-color: #04378b;
  color: #fff;
  border-top: 1px solid #ccc;
  width: 100%;
  display: none;
  flex-direction: row;
  justify-content: space-between;
  flex-wrap: nowrap;
  align-items: center;
}
  
.cookie-banner a {
  color: #fff;
  text-decoration: underline;
}

.control {
  flex-shrink: 0;
}

.cookie-banner button {
  padding: 1em;
  background: #8C1257;
  color: white;
  border: none;
}

.small {
  font-size: 12px;
}

.small:hover, .cookie-banner button:hover {
  cursor: pointer;
}
</style>
<div class="cookie-banner" id="cookie-banner">
  <div class="text">
  Verwendung von Cookies: Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, nutzen wir Cookies. <a href="https://meine-domain.de/datenschutzerklaerung/">Mehr erfahren: Datenschutzerklärung</a>.
  </div>
  <div class="control">
    <button onclick="acceptCookies();">
      Cookies zulassen
    </button>
    <span class="small" onclick="denyCookies()">
      Ablehnen.
    </span>
  </div>
</div>

<script>
  function acceptCookies() {
    var x = document.getElementById("cookie-banner");
    document.cookie = "cookieconsent=True;max-age=31536000;domain=.DOMAIN-NAME-HIER-EINGEBEN-PUNKT-BESTEHEN-LASSEN.de;path=/";
    dataLayer.push({'event':'user_cookie_consent'});
    x.style.display = "none";
  }
  
  function denyCookies() {
    var x = document.getElementById("cookie-banner");
    x.style.display = "none";
  }
  
  function initializeBanner() {
    var cookieString = document.cookie;
    if(cookieString.includes("cookieconsent=True")){
      dataLayer.push({'event':'user_cookie_consent'});
    }
    else {
      var x = document.getElementById("cookie-banner");
      x.style.display = "flex";
    }
  }
    
  // In some cases, the GTM code is not ready yet when DOMContentLoaded is called - in this case, the code must be executed right away, as DOMContentLoaded won't fire again
  if(document.readyState === "complete" || document.readyState === "interactive") {
    initializeBanner();
  }
  else {
    document.addEventListener("DOMContentLoaded", function(event){
      initializeBanner();
    });  
  }
  
</script>

Schritt 2: Neuer Trigger: Cookies akzeptiert

Google Analytics (und alle anderen Marketing-Tags) sollen erst beim Feuern des Tag Manager-Events „user_cookie_consent“ geladen werden. Dieses wird in Zeile 72 des obigen Codes in den DataLayer injiziert. Um auch in Google Tag Manager auf das Feuern dieses Events zu warten, muss ein neuer Trigger angelegt werdne. Als Triggertyp wird „Benutzerdefiniertes Ereignis“ ausgewählt, der Name kann z.B. „Cookies akzeptiert“ lauten. Wichtig ist der „Ereignisname“ – dieser muss „user_cookie_consent“ lauten.

Screenshot des "Neuer Trigger"-Bildschirms — Ein neuer Trigger ist notwendig, damit Marketing-Tags erst dann geladen werden, wenn das „Cookies akzeptiert“-Event gefeuert wurde

Schritt 3: Auslösende Trigger der Marketing-Tags ändern

Anschließend müssen unter „Tags“ noch alle Marketing-Tags (z.B. Google Analytics) so eingestellt werden, dass als „Auslösender Trigger“ der gerade erstellte „Cookies akzeptiert“-Trigger zum Einsatz kommt. Das kann dann zum Beispiel so aussehen:

Screenshot einer Übersicht angelegter Tags — Als „auslösender Trigger“ für Marketing-Tags wird jetzt der „Cookies akzeptiert“-Trigger verwendet.

Jetzt müssen die Ergebnisse nur noch durch Klick auf „Senden“ veröffentlicht werden! Es bietet sich an, die Ergebnisse durch Verwendung des Chrome Tag Assistent zu überprüfen.

Was macht der neu eingefügte Code eigentlich?

Das HTML-Tag besteht zunächst einmal aus vielen Styling-Informationen für den Cookie-Banner selbst (Zeile 1-40) sowie den entsprechenden HTML-Code (Zeile 42-56). Dieser kann nach belieben angepasst werden – der obige Code bietet Mobil wie auf dem Desktop eine relativ gute Darstellung.

Die Funktion acceptCookies setzt selbst einen Cookie, der dafür sorgt, dass der Cookie-Banner nach Akzeptieren des Banners nicht erneut angezeigt wird. Darüber hinaus wird das entsprechende Event in den DataLayer injiziert (gepusht), auf welches GTM „hört“ und anschließend die entsprechenden Marketing-Cookies läd. Der Banner wird anschließend versteckt.

In denyCookies wird einfach nur der Banner versteckt. Wer auch dafür sorgen möchte, dass Nutzer nicht erneut um eine Einwilligung gebeten werden, sollte noch Zeile 59 kopieren und „cookieconsent=True“ durch „cookieconsent=False“ ersetzen.

InitializeBanner wird nach Laden der Seite aufgerufen. Hier wird zunächst überprüft, ob bereits eine Einwilligung gegeben wurde. In diesem Fall wird direkt das user_cookie_consent-Event gefeuert. Andernfalls wird der Banner dargestellt. Ggfs. wäre weitere Code erforderlich, um den Cookie-Banner nicht anzuzeigen, falls ein Nutzer eine Einwilligung explizit abgelehnt hat.

In den Zeilen 80 bis 88 wird in jedem Fall darauf gewartet, dass das DOM bereits geladen ist („DOMContentLoaded“). Es kann aber auch vorkommen, dass der GTM-Code erst geladen/initialisiert wird, wenn das DOM bereits fertig aufgebaut ist.