Server Side Tracking mit Stape und Borlabs Cookie: Vollständige Implementierungsanleitung

Inhaltsverzeichnis

Archiv

tl;dr: Diese Anleitung zeigt dir Schritt für Schritt, wie du serverseitiges Tracking über Stape zusammen mit Borlabs in einem WooCommerce-Shop einbinden kannst.

Lesezeit: ca. 20 Minuten
Letztes Update: 6. Februar 2026

Die nachfolgende Anleitung basiert auf einer realen, funktionierenden Implementierung für ein österreichisches Unternehmen. Bei Fragen oder für individuelles Setup-Consulting, kontaktiere uns gerne!

Was du mit dem nachfolgenden Setup erreichen kannst:

  • Zuverlässiges Conversion Tracking (unabhängig von Ad-Blockern und ITP)
  • Enhanced Conversions mit vollständigen Kundendaten
  • Automatische Deduplizierung zwischen Browser- und Server-Events
  • Server-Side Tracking für alle wichtigen Werbeplattformen

 

Was sind die Grundbedingungen?

Einleitung und Problemstellung

Server-Side Tracking über Google Tag Manager (GTM) bietet entscheidende Vorteile für Onlineshops, wie etwa WooCommerce-Webshops. Beispielsweise bessere Performance, höhere Datensicherheit und Compliance mit DSGVO-Anforderungen. Doch Tracking erfordert auch Consent. Viele Tools wie Cookiebot, Usercentrics oder ONE Trust können schnell teuer werden, vor allem wenn man viele Seiten oder Zugriffe hat.

Eines der beliebtesten WordPress-Plugins für Consent im deutschsprachigen Raum ist das Borlabs Cookie Consent Management Plugin. Dies lässt sich relativ einfach umsetzen, wenn es sich um klassisches Webtracking handelt. Die Integration von serverseitigem Tracking erfordert jedoch eine strukturierte Vorgehensweise, um die Tags und Consent-Signale korrekt an den Server-Container weiterzuleiten und gleichzeitig auf die anderen Vorteile nicht verzichten zu müssen.

Stape Assistant

Im ersten Schritt kümmern wir uns um die Konfiguration unserer GTM-Container. Seit einigen Wochen stellt Stape ein Tool names „Setup Assistant“ zur Verfügung. Dieses Tool findet man im Stape-Account unter „sGTM“. Dort kann man in nur wenigen Schritten die Konfigurationen für Web-GTM (webGTM) und Server-GTM (sGTM) konfiguieren. In diesem Fall handelt es sich um einen WooCommerce-Webshop, daher wählen wir Type = E-commerce und Platform = WooCommerce. Bei Consent settings needed? bleiben wir auf „No“, weil die Borlabs-Integration manuell konfiguriert werden muss und nicht über die vorgefertigten CMP-Templates des Assistenten erfolgt.

Stape Assistant

Im zweiten Schritt kann man alle Destinationen auswählen, an die man Daten senden will, wie beispielsweise GA4, Meta oder Google Ads. Im dritten Schritt muss man alle Basisdaten wie Server Container URL, GA4 Measurement ID, Meta Pixel ID usw. hinterlegen – ich gehe davon aus, dass du weißt, woher du diese Daten bekommst. Im letzten Schritt kann man sich entweder JSON-Dateien für webGTM und sGTM herunterladen oder die Containerfiles direkt importieren. Wenn du diesen Schritt abgeschlossen hast, hast du alle Tags, Trigger und Variablen in deinen GTM-Containern.

Stape Plugin konfigurieren

Damit das Setup der Container nun auch funktionell ist, installieren wir im zweiten Schritt das Conversion Tracking Plugin von Stape. Wir verwenden es jedoch nicht, um den GTM-Container an sich in die Seite einzubinden, sondern nur um den E-Commerce dataLayer einzubinden. Dieser ist essenziell für E-Commerce- und Conversion-Tracking, weil nur damit Umsätze, Daten aus Enhanced Conversions etc. an externe Tools wie GA4, Google Ads oder Meta Ads übergeben werden können.

Stape Conversion Tracking Plugin

Diese Einstellungen finden wir im zweiten Tab unter „Data Layer“.

Stape Plugin Data Layer Optionen

Hier aktivieren wir die ersten beiden Menüpunkte. Die user data benötigen wir u.a. für Enhanced Conversions bei Google. Ob du das dataLayer-Event dekorieren willst (es heißt dann z.B. view_item_stape und nicht mehr view_item), ist dir überlassen. Ich verzichte im Normalfall darauf, da ich bei unseren Tracking-Setups auf keine anderen ECOM-Events zurückgreife und daher weiß, dass alle Standardevents über Stape kommen.

Stape Custom Code generieren

Weil wir den GTM-Code, der von Stape bereit gestellt wird, weder über das Stape-Plugin (wie gerade beschrieben) noch über das Borlabs-Plugin (mehr dazu später) geladen wird, binden wir diesen im <head> unseres Themes ein. Dazu benötigen wir den Custom Code. Diesen finden wir in unserem Stape-Account unter „Power-Ups“ beim Custom Loader“.

Zunächst Domain und ID des Web-Containers hinterlegen (nicht des Server-Containers!), „GA4 ad block bypass“ aktivieren. Anschließend bei der Platform nicht „WooCommerce“ wählen (dies ist etwas kontraintuitiv), sondern „Other“. Beim „User identifier type“ am besten die Stape User ID wählen (die gesondert aktiviert werden muss). Anschließend auf „Generate“ klicken und du bekommst deinen sGTM-Container-Code.

Stape Custom Code

Die Stape User ID ist ein persistenter First-Party Cookie, der besseres Cross-Domain und Session-Tracking ermöglicht und als Alternative zur Google Client ID dient.

Stape Code via Hook in einbinden

Nun musst du den Code in deine Website einbinden. Wir verwenden in unserem Beispiel eine WP-Seite mit dem Theme von Astra. Dort hat man im Bereich „Site Builder“ die Möglichkeit, Snippets in verschiedene Bereiche einer Website einzubinden. Wir erstellen dabei ein neues Code-Snippet vom Typ „Hook“. Dieses platzieren wir unter „Action“ im Bereich „Head Top“, da der GTM-Container so schnell wie möglich geladen werden sollte, wenn man eine Seite öffnet. Wichtig ist auch die Einstellung „Display On“ mit „Entire Website“.

WP Head Hook Stape Code

Borlabs Plugin konfigurieren

Nun haben wir den Code von Stape direkt im <head> der Seite eingebunden, den dataLayer laden wir über das Stape-Plugin. Nun müssen wir uns um die Konfiguration des Borlabs-Plugins kümmern. In der Borlabs Cookie Library (Hauptmenü > Bibliothek) gibt es einen Service vom Typen Google Tag Manager (inkl. Consent Mode v2). Dort kann man die eigene GTM-ID hinterlegen, den Consent Mode konfigurieren und die Service-Gruppen anpassen.

Borlabs Bibliothek - Google Tag Manager Template

Standardmäßig wird ein GTM-Container bei der Verwendung dieses Templates über den nachfolgenden Code geladen:

<script data-no-optimize="1" data-no-minify="1" data-cfasync="false">
    if('{{ google-tag-manager-cache-locally }}' === '0' && ('{{ google-tag-manager-use-own-integration }}' === '1' || '{{ google-tag-manager-use-own-integration }}' === '0')) {
        if ('{{ google-tag-manager-use-own-integration }}' === '1') {
            window.BorlabsCookie.Unblock.unblockScriptBlockerId('google-tag-manager');
        } else if ('{{ google-tag-manager-use-own-integration }}' === '0') {
            /* GTM block start */
            (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
                    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
                j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
                'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
            })(window,document,'script','dataLayer','{{ google-tag-manager-id }}');
            /* GTM block end */
        }
    }
</script>

Und ist sehen wir schon das Hauptproblem. Du siehst im Code, dass der GTM hier über https://www.googletagmanager.com/gtm.js?id= geladen wird. Einer der Hauptvorteile von SST über Stape ist jedoch, dass der Server-Container von der eigenen Tagging Server URL geladen wird, die man im Stape-Account definiert hat.

Es gibt auch nicht die Möglichkeit, dass du den Code hier einfach durch deinen Custom Code von Stape ersetzt, erstens weil dieser bei jedem Update zurückgesetzt wird, zweitens weil der Code von Stape und jener von Borlabs auch technisch gesehen nicht kompatibel sind.

Daher muss man in Borlabs unter Services die Code-Ausführung deaktivieren. Wenn diese Option aktiviert ist, wird der JS-Code von Borlabs nicht mehr ausgeführt und der GTM-Container nicht mehr durch Borlabs geladen.

Weil wir den GTM über den Hook in unserem Astra-Theme laden, müssen wir ebenfalls die Option Eigene Integration verwenden aktivieren. Weil der Consent Mode direkt im GTM konfiguriert wird, muss die Aktivierung des Einwilligungsmodus ebenfalls deaktiviert sein.

Borlabs GTM Einstellungen

Letztendlich bedeutet dies, wir verwenden den Borlabs-Service für den GTM nur, um den Dienst im Consentbanner anzuzeigen. Ich gehe an dieser Stelle bewusst nicht auf das sogenannte Hannover-Urteil (Urt. v. 19.03.2025, Az.: 10 A 5385/22) ein (das besagt, dass theoretisch auch ein leerer GTM-Container erst dann geladen werden darf, wenn man seine Einwilligung gibt), weil dies den Rahmen sprengen würde. Es handelt sich daher hier um eine rechtliche Grauzone und wenn du dir unsicher bist, solltest du juristische Beratung einholen.

Einstellungen der Service-Tags in Borlabs

Für andere Services wie Google Analytics 4, Google Ads oder Meta Ads kann man wie gewohnt das jeweilige Template aus der Bibliothek laden, installieren und dann die Einstellungen vom nachfolgenden Screenshot tätigen. Zum einen die Code-Ausführung deaktivieren (der Code wird via GTM geladen) und zum anderen den Consent Mode deaktivieren – denn dieser wird wir zuvor beschrieben ebenfalls via GTM gesteuert.

Borlabs - Einstellungen GA4

Consent über GTM steuern

Da wir den Consent Mode wie zuvor beschrieben nicht über das Borlabs Plugin, sondern über GTM direkt aussteuern, benötigen wir dort ein Tag-Template dazu. Das beliebte Consent Mode Template von Simo Ahava bietet die aus meiner Sicht beste Integration. Dazu musst du das Template aus der Gallery hinzufügen.

Schritte:

  1. GTM → Templates → Tag Templates
  2. „Search Gallery“ klicken
  3. Suchen: „Consent Mode (Google & Microsoft tags)“
  4. Template hinzufügen

Anschließend kannst du das Template folgendermaßen konfigurieren:

Tag Name: [Consent] Default
Tag Type: Consent Mode (Google + Microsoft tags)
Consent Command:
Default

Consent Settings:
ad_storage: denied
analytics_storage: denied
ad_user_data: denied
ad_personalization: denied
personalization_storage: granted (oder eigene Variable)
functionality_storage: granted
security_storage: granted

Trigger: Consent Initialization – All Pages

Consent Default Template GTM

Die nicht-werbebezogenen Storage Types werden typischerweise standardmäßig auf „granted“ gesetzt, da sie für grundlegende Website-Funktionalität benötigt werden und nicht unter dieselben DSGVO-Restriktionen fallen wie ad_storage und analytics_storage.

Der Trigger „Consent Initialization“ bedeutet, dass dieses Tag ganz am Anfang, sobald der GTM geladen ist, lädt und den Zustimmungsmodus für alle Analytics- und Ads-Tags auf nicht erlaubt setzt. Denn solche Tags dürfen erst dann gefeuert werden, wenn ein User seine Zustimmung gibt.

Borlabs Consent Listener erstellen

Der Consent Listener ist die Brücke zwischen Borlabs Cookie und GTM. Er hat zwei Aufgaben:

  1. Bei neuen Besuchern: Übersetzt das Borlabs-Event ‚borlabs-cookie-consent-saved‘ in ein GTM-kompatibles dataLayer Event ‚borlabs-consent-update‘.
  2. Bei wiederkehrenden Besuchern: Prüft aktiv, ob bereits ein Consent Cookie existiert und triggert den Update-Prozess, da in diesem Fall kein User-Klick erfolgt.

 

Tag Name: [cHTML] Borlabs Consent Listener
Type: Custom HTML
HTML Code: [nachfolgendes Script]
Triggering: Initialization – All Pages Wichtig:

Der Trigger „Initialization“ stellt sicher, dass der Listener bereit ist, BEVOR der User mit dem Banner interagiert oder andere Tags evaluiert werden.

<script>
(function() {
  // Verhindere doppelte Ausführung
  if (window._borlabsListenerInit) return;
  window._borlabsListenerInit = true;
  
  function handleConsentUpdate() {
    console.log('[Borlabs] Consent update triggered');
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({'event': 'borlabs-consent-update'});
  }
  
  // Event Listener für Consent-Änderungen
  window.addEventListener('borlabs-cookie-consent-saved', function() {
    console.log('[Borlabs] Cookie consent saved event');
    handleConsentUpdate();
  });

  // Sofort prüfen für wiederkehrende Besucher - mehrere Versuche
  function checkExistingConsent() {
    if (typeof window.BorlabsCookie !== 'undefined') {
      console.log('[Borlabs] Existing consent detected');
      handleConsentUpdate();
      return true;
    }
    return false;
  }
  
  // Mehrfache Prüfung mit verschiedenen Timings
  if (!checkExistingConsent()) {
    setTimeout(checkExistingConsent, 100);
    setTimeout(checkExistingConsent, 300);
    setTimeout(checkExistingConsent, 500);
  }
})();
</script>

Die gestaffelten setTimeout-Checks (100ms, 300ms, 500ms) sind essentiell:

// Mehrfache Prüfung mit verschiedenen Timings
if (!checkExistingConsent()) {
  setTimeout(checkExistingConsent, 100);
  setTimeout(checkExistingConsent, 300);
  setTimeout(checkExistingConsent, 500);
}

Bei wiederkehrenden Besuchern gibt es kein borlabs-cookie-consent-saved Event (der User klickt ja nicht erneut auf den Banner). Das Borlabs-Objekt wird asynchron geladen. Die Timeouts stellen sicher, dass der Consent Status auch dann in GTM landet, wenn Borlabs Cookie verzögert initialisiert wird. Die gestaffelten Timeouts fangen Edge Cases ab, wenn Borlabs Cookie verzögert initialisiert wird (z.B. bei langsamen Verbindungen oder vielen Plugins). Google Consent Mode gibt CMPs standardmäßig 500ms Zeit für Consent Updates via wait_for_update. Unsere gestaffelten Timeouts (100ms, 300ms, 500ms) nutzen dieses Zeitfenster optimal aus.

Borlabs Cookie Variables erstellen

Um solche Tags nun bei einem Klick auf „Cookies akzeptieren“ im Consentbanner richtig auszusteuern zu können, benötigen wir zwei Custom Javascript Variablen, die den Consent Status aus dem Tool an GTM übermitteln. Borlabs Cookie stellt in der offiziellen Knowledge Base diverse JavaScript-API-Methoden zur Verfügung, die wir in GTM-Variablen übersetzen.

Variable 1: Marketing Consent
Variable Name: CJS – Borlabs – Marketing Consent
Variable Type: Custom JavaScript

function() {
  if (typeof window.BorlabsCookie !== 'undefined' && 
      typeof window.BorlabsCookie.Consents !== 'undefined') {
    // Prüfe Marketing Service Group
    var hasMarketingConsent = window.BorlabsCookie.Consents.hasConsentForServiceGroup('marketing');
    return hasMarketingConsent ? 'granted' : 'denied';
  }
  return 'denied';
}

Variable 2: Analytics Consent
Variable Name: CJS – Borlabs – Analytics Consent
Variable Type: Custom JavaScript

function() {
  if (typeof window.BorlabsCookie !== 'undefined' && 
      typeof window.BorlabsCookie.Consents !== 'undefined') {
    // Prüfe Statistics Service Group
    var hasAnalyticsConsent = window.BorlabsCookie.Consents.hasConsentForServiceGroup('statistics');
    return hasAnalyticsConsent ? 'granted' : 'denied';
  }
  return 'denied';
}

Wichtig: Die Namen marketing und statistics müssen exakt (case-sensitive: „marketing“ und nicht „Marketing“) mit den Borlabs Cookie-Gruppennamen im Bereich der Services übereinstimmen.

Consent Update Tag

Neben dem Consent Default Tag und den beiden CJS Variablen müssen wir jetzt noch ein zweites Consent Mode (Google + Microsoft tags) Tag vom Typ Consent Update konfigurieren:

Tag Name: [Consent] Update
Tag Type: Consent Mode (Google + Microsoft tags)
Consent Command:
Update

Consent Settings:
ad_storage: {{CJS – Borlabs – Marketing Consent}}
analytics_storage: {{CJS – Borlabs – Analytics Consent}}
ad_user_data: {{CJS – Borlabs – Marketing Consent}}
ad_personalization: {{CJS – Borlabs – Marketing Consent}}
personalization_storage: granted (oder eigene Variable)
functionality_storage: granted
security_storage: granted

Other Settings: ☑ Pass Ad Click Information Through URLs

Advanced Settings: Tag Firing Priority: 100 (höchste Priorität)

Triggering: Custom Event: borlabs-consent-update

Custom Event Trigger für Borlabs erstellen

Das Custom Event borlabs-consent-updatewird jedes Mal gefeuert, wenn der User seine Zustimmung ändert. So erstellst du diesen Trigger:

Trigger Name: ce - borlabs-consent-update
Trigger Type: Custom Event
Event Name: borlabs-consent-update
This trigger fires on: All Custom Events

Custom Event borlabs-consent-update

GA4 Configuration Tag einrichten

Nun haben wir alles rund um den Consent konfiguriert und können uns um die Einrichtung von Google Analytics 4 kümmern. Basis dafür bildet der GA4 Config Tag. Dieser GA4 Config Tag wird jedoch nicht bei borlabs-consent-update gefeuert, sondern bei DOM Ready. Dazu erstellen wir folgenden Trigger:

Trigger Name: DOM Ready - All Pages
Trigger Type: DOM Ready
This trigger fires on: All DOM Ready Events

DOM Ready feuert, wenn die HTML-Struktur vollständig geladen ist, aber bevor alle Assets (Bilder, CSS) geladen sind. Das ist der ideale Zeitpunkt für GA4 Config, da zu diesem Zeitpunkt der Consent Status garantiert bekannt ist.

Warum ist dies der Fall? Schauen wir uns die Event-Reihenfolge beim ersten Besuch eines Nutzers an:

1. Consent Initialization → Default DENIED
2. Initialization → Tags würden blockiert
3. User sieht Borlabs Banner
4. User stimmt zu → borlabs-consent-update Event
5. [Consent] Update Tag feuert → gtag('consent', 'update')
6. Consent Update → Consent = GRANTED
7. DOM Ready → JETZT ist Consent garantiert gesetzt
8. GA4 Config Tag feuert → Mit Consent GRANTED ✅

Auf dieser Basis können wir den GA4-Tag folgendermaßen konfigurieren:

Tag Name: [GA4] Config
Tag Type: Google Tag (GA4 Configuration)

Configuration Settings:
Measurement ID: G-XXXXXXXXXX
Server Container URL: https://deine-sgtm-domain.com

Triggering:
Trigger 1: DOM Ready – All Pages
Trigger 2: Initialization – All Pages (für wiederkehrende User)

Advanced Settings → Consent Settings:
Additional Consent Required: analytics_storage

Advanced Settings → Tag Firing Options:
☑ Once per page (wichtig!)

Warum zwei Trigger für GA4 Config?

Szenario 1: Neuer Besucher (kein Consent gewählt bzw. kein Cookie gesetzt):

Event-Flow:
1. Initialization → GA4 Config evaluiert, Consent = DENIED → Blockiert
2. borlabs-consent-update → Consent Update auf GRANTED
3. DOM Ready → GA4 Config feuert mit Consent ✅

Szenario 2: Wiederkehrender Besucher (Cookie vorhanden):

„Once per page“ verhindert, dass der Tag in Szenario 2 zweimal feuert.

Trigger für Tags erstellen

E-Commerce Events (view_item, add_to_cart, etc.) werden vom Stape Plugin synchron beim Seitenaufbau gefeuert, während das borlabs-consent-update Event asynchron bei User-Interaktion ausgelöst wird. Die sogenannte Trigger Group löst dieses Timing-Problem. Bei einer Trigger Group feuert ein Tag erst dann, wenn zwei oder mehrere Bedingungen erfüllt sind.

Im Beispiel am Screenshot unten haben wir eine TG für das view_item erstellt. Dieses Tag feuert erst dann, wenn das view_item Event gefeuert wurde UND borlabs-consent-update Event gefeuert wurde (und der Consent den passenden Status hat). Im GTM-Preview ist eine Trigger Group meistens das letzte Event, das in der Übersicht am linken Bildschirmrand angezeigt wird.

Trigger Group Borlabs

Testing & Debugging

So überprüfst du, ob deine Implementierung funktioniert:

GTM Preview Mode:

  • Öffne GTM Preview und navigiere durch deinen Shop
  • Prüfe in der Timeline, ob „borlabs-consent-update“ Event feuert
  • Kontrolliere bei „[Consent] Update“, ob die CJS-Variablen korrekte Werte zurückgeben („granted“ oder „denied“)

 

Browser Console:

  • Öffne Developer Tools (F12) → Console
  • Such nach „[Borlabs] Consent update triggered“ und
  • [Borlabs] Existing consent detected“
  • Diese console.log-Ausgaben bestätigen, dass der Listener arbeitet

 

GA4 DebugView:

  • Aktiviere Debug Mode (GA4 Config Tag → Fields to Set → „debug_mode“ = „true“)
  • Öffne GA4 → Configure → DebugView
  • Prüfe, ob Events mit korrektem Consent-Status ankommen

Häufige Fehlerquellen

Problem: GA4 Events feuern nicht

  • Service Group Namen in Borlabs exakt prüfen (Case-sensitive!)
  • Once per page“ beim GA4 Config aktiviert?
  • Server Container URL endet ohne trailing slash (/)

 

Problem: Consent Update kommt nicht an

  • Consent Listener auf „Initialization“ Trigger prüfen
  • In Browser Console nach Borlabs-Logs suchen
  • window.BorlabsCookie im Console testen

 

Problem: Doppelte Pageviews in GA4

  • „Once per page“ fehlt beim GA4 Config Tag
  • Prüfe, ob GA4 nicht zusätzlich über Stape Plugin geladen wird

Zusammenfassung: Server-Side Tracking mit Borlabs Cookie erfolgreich implementieren

Die Integration von Borlabs Cookie mit serverseitigem Google Tag Manager stellt eine Herausforderung dar. In diesem Artikel haben wir eine bewährte Lösung implementiert. Das Fundament bildet ein vollständiges Consent Mode Setup mit Consent Initialization Tag (Default State „denied“), Custom JavaScript Variablen zum Auslesen der Borlabs-Zustände und einem Consent Update Tag mit dem Simo Ahava Template.

Der entscheidende Durchbruch liegt in der Zwei-Trigger-Strategie für den GA4 Configuration Tag: Trigger 1 (DOM Ready) greift bei neuen Usern, die erstmals zustimmen – zu diesem Zeitpunkt ist der Consent garantiert gesetzt. Trigger 2 (Initialization) aktiviert das Tracking bei wiederkehrenden Usern mit bestehendem Cookie. Kombiniert mit der Option „Once per page“ stellen wir sicher, dass der Tag in beiden Szenarien genau einmal feuert – immer mit gültigem Consent. Zusätzliche Consent Settings (analytics_storage required) fungieren als zweite Schutzschicht. Das Ergebnis ist eine DSGVO-optimierte Lösung ohne verlorene Conversions, die optimal performt und eine wartbare Architektur bietet.

Mit über 100 erfolgreich umgesetzten Websites mit Borlabs Cookie und als offizieller Stape.io Partner verfügt MONOBUNT über umfassende Expertise in Server-Side Tracking-Implementierungen. Wir kennen jede Fallstricke und Best Practice aus realen Projekten. Du möchtest Server-Side Tracking mit Borlabs Cookie umsetzen oder dein bestehendes Setup optimieren? Kontaktiere MONOBUNT – wir bringen dein Tracking auf das nächste Level.

Weiterführende Links:

Server-Side Tracking anfragen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Das könnte dich auch interessieren: