{"id":81804,"date":"2026-09-18T09:37:00","date_gmt":"2026-09-18T09:37:00","guid":{"rendered":"https:\/\/taggrs.io\/?p=81804"},"modified":"2026-09-24T08:58:35","modified_gmt":"2026-09-24T08:58:35","slug":"woocommerce-server-side-tracking","status":"publish","type":"post","link":"https:\/\/taggrs.io\/de\/woocommerce-server-side-tracking\/","title":{"rendered":"WooCommerce Server-side Tracking: Eine vollst\u00e4ndige Einrichtungsanleitung"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Die \u00fcbliche WooCommerce-Tracking-Einrichtung besteht aus einem Pixel auf der Website und einem Kauf-Tag auf der Dankeseite. Die Installation geht schnell und es funktioniert auch bei einer Testbestellung \u2013 deshalb nutzen es so viele Shops. <\/p>\n\n<p class=\"wp-block-paragraph\">Das Problem ist, wie eine Testbestellung aussieht. Du w\u00e4hlst ein Produkt aus, bezahlst mit Karte und landest auf der Best\u00e4tigungsseite, auf der der Kauf angezeigt wird. Das Problem ist, dass nur sehr wenige Leute so einkaufen. Ein echter Kunde legt einen Artikel von einer Kategorieseite aus in den Warenkorb, die nicht neu geladen wird \u2013 daher gibt es keine Seitenaufruf-Metrik, an die das Ereignis angeh\u00e4ngt werden kann. Bei Zahlungen \u00fcber iDEAL oder Klarna werden sie von deiner Seite weitergeleitet, und wenn sie den Tab schlie\u00dfen, bevor die Weiterleitung sie zur\u00fcckbringt, zeichnet WooCommerce eine Bestellung auf, die dein Tracking nicht erfasst hat. Dazu kommen zwischengespeicherte Checkout-Seiten mit veralteten Werten, Banner zur Einwilligung, die abgelehnt wurden, und Werbeblocker, die die Anfrage stoppen, bevor sie den Browser verl\u00e4sst.     <\/p>\n\n<p class=\"wp-block-paragraph\">Das wird nicht als Fehler angezeigt. Dein Shop nimmt weiterhin Bestellungen entgegen und die Berichte f\u00fcllen sich immer weiter, sodass alles ganz normal aussieht \u2013 bis jemand versucht, die Zahlen abzugleichen. <\/p>\n\n<p class=\"wp-block-paragraph\">Das server-side Tracking ersetzt diese verstreute Konfiguration durch einen einzigen Pfad, den du selbst kontrollierst. Im n\u00e4chsten Abschnitt wird erkl\u00e4rt, was das bedeutet, und im weiteren Verlauf des Leitfadens geht es um die Einrichtung, die spezifischen Probleme bei WooCommerce und darum, wie du feststellen kannst, ob es bei dir funktioniert. <\/p>\n\n<h2 id=\"what-server-side-tracking-actually-does\" class=\"wp-block-heading\">Was server-side Tracking eigentlich bewirkt<\/h2>\n\n<p class=\"wp-block-paragraph\">Normalerweise l\u00e4dt dein Shop ein Skript von Google, ein weiteres von Meta und vielleicht noch ein drittes von TikTok. Jedes davon sendet Daten direkt vom Browser des Besuchers an das jeweilige Unternehmen. Du hast keine Kontrolle dar\u00fcber, was gesendet wird, und es gibt keinen zentralen Ort, an dem du das \u00fcberpr\u00fcfen kannst.  <\/p>\n\n<p class=\"wp-block-paragraph\">Beim server-side Tracking kommt ein Zwischenschritt hinzu. Der Browser sendet Daten an einen Server, den du kontrollierst und der unter deiner eigenen Webadresse l\u00e4uft. Dieser Server entscheidet dann, was an GA4, was an Google Ads, was an Meta geht und was zuerst entfernt wird.  <\/p>\n\n<p class=\"wp-block-paragraph\">Dadurch \u00e4ndern sich drei Dinge. Du beh\u00e4ltst die Kontrolle, weil du Werte korrigieren oder personenbezogene Daten entfernen kannst, bevor \u00fcberhaupt etwas das System verl\u00e4sst. Du profitierst von einer zuverl\u00e4ssigeren Auslieferung, da die Werbeanfrage nicht mehr vom Browser stammt. Und du erh\u00e4ltst eine bessere Attribution, da dein Server Besucherinformationen l\u00e4nger speichern kann, als es der Browser zul\u00e4sst.   <\/p>\n\n<h3 id=\"what-you-gain-and-what-you-do-not\" class=\"wp-block-heading\">Was du gewinnst und was nicht<\/h3>\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Was die Leute erwarten<\/strong><\/td><td><strong>Was wirklich passiert<\/strong><\/td><\/tr><tr><td>Das behebt mein Tracking-Problem<\/td><td>Das behebt das Problem bei der Ausgabe. Wenn dein Setup einen falschen Wert meldet, wird nun zuverl\u00e4ssig der falsche Wert ausgegeben. <\/td><\/tr><tr><td>Ich kann mein Meta-Pixel ausschalten<\/td><td>Meta funktioniert besser, wenn Browser- und Serverdaten miteinander abgeglichen werden. Nur Serverdaten sind die Ausnahme. <\/td><\/tr><tr><td>Es umgeht die Einwilligungsvorschriften<\/td><td>Das ist nicht der Fall. Die Einwilligungsvorschriften gelten weiterhin. <\/td><\/tr><tr><td>Das ist eine einmalige Einrichtung<\/td><td>Die Route ist stabil, dein Shop aber nicht. F\u00fchre nach dem Bezahlen sowie nach \u00c4nderungen an Plugins und Themes einen erneuten Test durch. <\/td><\/tr><\/tbody><\/table><\/figure>\n\n<h2 id=\"why-woocommerce-tracking-breaks\" class=\"wp-block-heading\">Warum das WooCommerce-Tracking nicht funktioniert<\/h2>\n\n<p class=\"wp-block-paragraph\">WooCommerce l\u00e4sst sich zu fast jeder Art von Online-Shop gestalten. Diese Flexibilit\u00e4t ist f\u00fcr das Gesch\u00e4ft von Vorteil, erschwert aber die Nachverfolgung. <\/p>\n\n<h3 id=\"block-checkout-and-classic-checkout-behave-differently\" class=\"wp-block-heading\">\u201eBlock Checkout\u201c und \u201eClassic Checkout\u201c funktionieren unterschiedlich<\/h3>\n\n<p class=\"wp-block-paragraph\">Der klassische Checkout nutzt Shortcodes und seit langem etablierte WooCommerce-Hooks. Warenkorb- und Checkout-Bl\u00f6cke verwenden die Store-API und ihr eigenes Ereignissystem. Einige \u00e4ltere jQuery-Warenkorb-Events werden in native Browser-Events mit dem Pr\u00e4fix \u201ewc-blocks_\u201c umgewandelt.  <\/p>\n\n<p class=\"wp-block-paragraph\">Ein Trigger, der auf einem klassischen jQuery-Event basiert, erh\u00e4lt m\u00f6glicherweise nicht die erwarteten Daten von einer blockbasierten Seite. WooCommerce dokumentiert die aktuellen <a href=\"https:\/\/developer.woocommerce.com\/docs\/block-development\/extensible-blocks\/cart-and-checkout-blocks\/dom-events\/\" target=\"_blank\" rel=\"noopener\">DOM-Events der Warenkorb- und Checkout-Bl\u00f6cke<\/a>, aber die Datenschicht muss diese noch in ein stabiles Analyseformat umwandeln. <\/p>\n\n<h3 id=\"your-cart-updates-without-reloading-the-page\" class=\"wp-block-heading\">Dein Warenkorb wird aktualisiert, ohne dass die Seite neu geladen wird<\/h3>\n\n<p class=\"wp-block-paragraph\">Viele Themes und Produkt\u00fcbersichten nutzen AJAX, um einen Artikel hinzuzuf\u00fcgen, ohne dass eine neue Seite geladen wird.<\/p>\n\n<p class=\"wp-block-paragraph\">Ein Trigger f\u00fcr Seitenaufrufe kann diese \u00c4nderung nicht erkennen. F\u00fcr eine zuverl\u00e4ssige Messung ist ein \u201eadd_to_cart\u201c-Event erforderlich, das das richtige Produkt, den richtigen Preis und die richtige Menge enth\u00e4lt \u2013 und zwar genau in dem Moment, in dem WooCommerce die Aktion best\u00e4tigt. <\/p>\n\n<h3 id=\"payment-flows-leave-the-store\" class=\"wp-block-heading\">Zahlungsstr\u00f6me verlassen das Gesch\u00e4ft<\/h3>\n\n<p class=\"wp-block-paragraph\">Bei manchen Zahlungsmethoden wird der K\u00e4ufer auf eine andere Seite weitergeleitet, bevor WooCommerce den Kaufvorgang als abgeschlossen markiert. Ein Kauf-Tag, das nur an das Aufrufen der Dankeseite gebunden ist, \u00fcbernimmt diese Ungewissheit. Das Neuladen der Seite kann das Tag ebenfalls erneut ausl\u00f6sen, sofern die Transaktions-ID nicht korrekt verwendet wird.  <\/p>\n\n<p class=\"wp-block-paragraph\">Der konkrete Fehler sieht folgenderma\u00dfen aus: Jemand schlie\u00dft die Zahlung ab und schlie\u00dft dann das Fenster, anstatt abzuwarten, bis er zu deinem Shop zur\u00fcckgeleitet wird. WooCommerce erfasst die Bestellung, aber dein Tracking wird nicht ausgel\u00f6st, da niemand die Best\u00e4tigungsseite geladen hat. Das macht sich als Differenz zwischen den WooCommerce-Ums\u00e4tzen und den Plattformums\u00e4tzen bemerkbar, die auf Mobilger\u00e4ten noch gr\u00f6\u00dfer ausf\u00e4llt und bei lokalen Zahlungsmethoden noch weiter zunimmt.   <\/p>\n\n<p class=\"wp-block-paragraph\">Es gibt zwei M\u00f6glichkeiten. Du kannst den Verkauf direkt aus WooCommerce heraus \u00fcbermitteln, sobald die Bestellung erstellt wird \u2013 so ist das Ganze \u00fcberhaupt nicht vom Browser abh\u00e4ngig. TAGGRS unterst\u00fctzt das \u00fcber Webhooks. Oder du nimmst die L\u00fccke in Kauf und \u00fcberpr\u00fcfst sie monatlich. Der Webhook-Weg ist umfassender, da nur eine einzige Einstellung erforderlich ist. Google Ads ben\u00f6tigt die Klick-ID, um einen Verkauf zuzuordnen, und WooCommerce speichert diese standardm\u00e4\u00dfig nicht. Wenn du sie fr\u00fcher im Customer Journey erfasst und der Bestellung hinzuf\u00fcgst, kann ein TAGGRS-Webhook sie weiterleiten. Ohne diesen Schritt haben Verk\u00e4ufe, die ausschlie\u00dflich \u00fcber den Webhook eingehen, keine Klick-ID, der sie zugeordnet werden k\u00f6nnen. Ein g\u00e4ngiger Ansatz ist es, das Browser-Event zu nutzen, sofern es vorhanden ist, und den Webhook als Ausweichl\u00f6sung f\u00fcr Bestellungen zu verwenden, bei denen kein solches Event erzeugt wurde.        <\/p>\n\n<h3 id=\"wordpress-plugins-overlap\" class=\"wp-block-heading\">WordPress-Plugins \u00fcberschneiden sich<\/h3>\n\n<p class=\"wp-block-paragraph\">Ein Data-Layer-Plugin, ein Meta-Plugin, die Google-Integration, eine Consent-Management-Plattform (CMP) und der Theme-Code k\u00f6nnen sich alle \u00fcberschneiden. Keines davon wird dich warnen, denn aus Sicht der einzelnen Plugins funktioniert alles einwandfrei. Du merkst es erst, wenn Meta doppelt so viel Umsatz meldet wie tats\u00e4chlich erzielt wurde oder wenn du ein scheinbar \u00fcberfl\u00fcssiges Plugin deaktivierst und die Ums\u00e4tze deutlich einbrechen.  <\/p>\n\n<h3 id=\"safari-is-stricter-than-most-setups-expect\" class=\"wp-block-heading\">Safari ist strenger, als die meisten Konfigurationen erwarten<\/h3>\n\n<p class=\"wp-block-paragraph\">Safari begrenzt die G\u00fcltigkeitsdauer von Cookies auf 7 Tage. Wenn ein Safari-Besucher nicht innerhalb einer Woche zur\u00fcckkommt, wird er als v\u00f6llig neuer Nutzer behandelt, ohne dass Informationen dar\u00fcber vorliegen, woher er gekommen ist. Das gilt f\u00fcr jeden Browser auf dem iPhone, einschlie\u00dflich Chrome und Firefox, da Apple vorschreibt, dass diese die Safari-Engine nutzen m\u00fcssen.  <\/p>\n\n<p class=\"wp-block-paragraph\">Normalerweise hei\u00dft es, dass server-side Tracking dieses Problem l\u00f6st, da Daten, die von deinem eigenen Server gesetzt werden, l\u00e4nger bestehen bleiben als solche, die im Browser gesetzt werden. Das war fr\u00fcher die ganze Geschichte. <\/p>\n\n<p class=\"wp-block-paragraph\">Seit 2023 f\u00fchrt Safari eine weitere \u00dcberpr\u00fcfung durch. Wenn dein Tracking-Server auf einem anderen Hosting-Anbieter l\u00e4uft als dein Shop, behandelt Safari ihn als extern und wendet trotzdem die gleiche Sieben-Tage-Frist an. Das ist ein h\u00e4ufiges Problem bei Online-Shops. Wenn dein Shop zum Beispiel auf einem WordPress-Host l\u00e4uft und dein Tracking-Server auf Google Cloud, sehen die beiden nicht so aus, als geh\u00f6rten sie zusammen.   <\/p>\n\n<p class=\"wp-block-paragraph\"><strong>So \u00fcberpr\u00fcfst du das:<\/strong> Gib in Safari eine Testbestellung auf und schau dir dann das Tracking-Cookie an, das dein Server setzt. Wenn es nach sieben Tagen abl\u00e4uft statt nach dem von dir konfigurierten Zeitraum, bist du betroffen. <\/p>\n\n<p class=\"wp-block-paragraph\"><strong>Was du tun kannst:<\/strong> Entweder hostest du deinen Tracking-Server zusammen mit deinem Shop, damit beide aufeinander abgestimmt sind, oder du nutzt eine speziell daf\u00fcr entwickelte Wiederherstellungsfunktion. TAGGRS <a href=\"https:\/\/taggrs.io\/de\/cookie-recovery-ios\/\">Cookie Recovery<\/a> stellt Daten wieder her, die von Safari und iOS gel\u00f6scht werden. Dazu muss das \u201eEnhanced Tracking Script\u201c aktiviert sein.  <\/p>\n\n<p class=\"wp-block-paragraph\">Werbeblocker sind die andere H\u00e4lfte des Problems. Selbst wenn Daten an deine eigene Webadresse gesendet werden, kann die Adresse selbst immer noch offensichtliche Tracking-Begriffe enthalten, die von den Blockern erkannt werden. Server-side Tracking kann nichts verarbeiten, was bereits gestoppt wurde, bevor es den Browser verlassen hat.  <\/p>\n\n<h2 id=\"woocommerce-server-side-gtm-architecture\" class=\"wp-block-heading\">Server-Side GTM-Architektur f\u00fcr WooCommerce<\/h2>\n\n<p class=\"wp-block-paragraph\">Die Strecke der Veranstaltung sieht so aus:<\/p>\n\n<p class=\"wp-block-paragraph\"><strong>WooCommerce-Shop \u2192 Data Layer \u2192 Web-GTM \u2192 Server-GTM \u2192 Analyse- und Werbeplattformen<\/strong><\/p>\n\n<p class=\"wp-block-paragraph\">Jedes Teil hat eine Aufgabe:<\/p>\n\n<ol class=\"wp-block-list\">\n<li><strong>Der Shop protokolliert den gesamten Vorgang<\/strong> \u2013 von der Produktansicht bis zur abgeschlossenen Bestellung.<\/li>\n\n\n\n<li><strong>Die Datenschicht erfasst dies<\/strong> anhand eines GA4-Events und der entsprechenden Produkt- oder Bestelldetails.<\/li>\n\n\n\n<li><strong>Web GTM erfasst die Daten<\/strong>, wendet die Einwilligung an und sendet sie an die URL des Server-Containers.<\/li>\n\n\n\n<li><strong>Server GTM verarbeitet die Daten<\/strong>, bevor <strong>sie<\/strong> an GA4, Google Ads, Meta oder einen anderen Empf\u00e4nger gesendet werden.<\/li>\n<\/ol>\n\n<p class=\"wp-block-paragraph\">Die Datenschicht ist die \u00dcbersetzungsschicht zwischen WooCommerce und GTM. Ohne sie kann jede \u00c4nderung am Theme oder Plugin zu einem eigenen JavaScript-Projekt werden. Ein Plugin, das dem <a href=\"https:\/\/developers.google.com\/analytics\/devguides\/collection\/ga4\/ecommerce\" target=\"_blank\" rel=\"noopener\">GA4-E-Commerce-Event-Modell<\/a> folgt, bietet eine stabilere Grundlage.  <\/p>\n\n<h2 id=\"before-you-start\" class=\"wp-block-heading\">Bevor du loslegst<\/h2>\n\n<p class=\"wp-block-paragraph\">Bevor du das server-side Tracking in WordPress einrichtest, solltest du folgende Dinge bereithalten:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Administratorzugriff auf WordPress und WooCommerce<\/li>\n\n\n\n<li>Ein Google Tag Manager-Webcontainer<\/li>\n\n\n\n<li>Ein Google Tag Manager-Servercontainer und Hosting<\/li>\n\n\n\n<li>Eine First-Party-Tagging-URL, wie zum Beispiel https:\/\/sending.example.com<\/li>\n\n\n\n<li>Eine GA4-Property und ein Web-Datenstrom<\/li>\n\n\n\n<li>Zugriff auf die entsprechenden Google Ads- und Meta-Konten<\/li>\n\n\n\n<li>Ein CMP, das Einwilligungsentscheidungen an GTM weiterleiten kann<\/li>\n\n\n\n<li>Ein Testshop oder eine andere sichere M\u00f6glichkeit, Testbestellungen aufzugeben<\/li>\n\n\n\n<li>Eine Liste von Plugins, die bereits Pixel, GTM oder E-Commerce-Events hinzuf\u00fcgen<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Eine Datenebene sollte f\u00fcr das E-Commerce-Event zust\u00e4ndig sein, und f\u00fcr jedes Plattformziel sollte ein Tag zust\u00e4ndig sein. Notier dir diese Zust\u00e4ndigkeiten, bevor du irgendetwas \u00e4nderst. Diese kurze Bestandsaufnahme deckt jede Menge Probleme auf.  <\/p>\n\n<h2 id=\"how-to-set-up-woocommerce-server-side-tracking\" class=\"wp-block-heading\">So richtest du das server-side Tracking in WooCommerce ein<\/h2>\n\n<p class=\"wp-block-paragraph\">Da sich Hosting-Seiten und Plugin-Einstellungen \u00e4ndern k\u00f6nnen, konzentrieren sich diese Schritte auf den Pfad der Ereignisse und die wichtigen \u00dcberpr\u00fcfungen.<\/p>\n\n<h3 id=\"1-host-the-server-gtm-container\" class=\"wp-block-heading\">1. Den GTM-Container auf dem Server einrichten<\/h3>\n\n<p class=\"wp-block-paragraph\">Stelle den Server-Container bereit und verbinde ihn mit einer First-Party-Tagging-URL, zum Beispiel sending.example.com. Vermeide offensichtliche Tracking-Begriffe wie \u201emetrics\u201c, \u201eanalytics\u201c oder \u201edata\u201c in der Subdomain. Filterlisten von Werbeblockern k\u00f6nnen sowohl erkennbare Domainnamen als auch Anfragepfade ins Visier nehmen.  <\/p>\n\n<p class=\"wp-block-paragraph\">Nutze die <a href=\"https:\/\/taggrs.io\/docs\/server-side-tracking\/setup\/subdomain\">Anleitung zur Einrichtung benutzerdefinierter Subdomains<\/a>, um die Domain zu konfigurieren und zu \u00fcberpr\u00fcfen. F\u00fcge die Produktions-URL in den Einstellungen des Server-Containers hinzu und \u00fcberpr\u00fcfe deren Status, bevor du den Shop-Traffic weiterleitest. Der Server-Container sollte au\u00dferdem in der GTM-Vorschau korrekt ge\u00f6ffnet werden.  <\/p>\n\n<h3 id=\"2-add-a-woocommerce-data-layer-for-ga4\" class=\"wp-block-heading\">2. F\u00fcge eine WooCommerce-Datenebene f\u00fcr GA4 hinzu<\/h3>\n\n<p class=\"wp-block-paragraph\">Installiere eine Datenebenen-Integration, die die verwendeten Storefront- und Checkout-Typen unterst\u00fctzt. Sie sollte Standard-E-Commerce-Events mit einem Artikel-Array und einheitlichen Produktkennungen \u00fcbermitteln. <\/p>\n\n<p class=\"wp-block-paragraph\">Teste zumindest Folgendes:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>view_item_list und view_item<\/li>\n\n\n\n<li>add_to_cart und remove_from_cart<\/li>\n\n\n\n<li>view_cart und begin_checkout<\/li>\n\n\n\n<li>purchase<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">\u00dcberpr\u00fcfe beim Kauf die Daten zu \u201etransaction_id\u201c, \u201evalue\u201c, \u201ecurrency\u201c und \u201eitem\u201c. Google verlangt f\u00fcr jede Bestellung eine eindeutige ID. Verwende die WooCommerce-Bestellnummer \u2013 GA4 nutzt sie, um doppelte Bestellungen zu erkennen und sp\u00e4tere R\u00fcckerstattungen abzuwickeln.  <\/p>\n\n<p class=\"wp-block-paragraph\">Drei Grenzen solltest du kennen:  <\/p>\n\n<ul class=\"wp-block-list\">\n<li>Das funktioniert nur bei Website-Daten \u2013 bei App-Daten klappt es nicht.<\/li>\n\n\n\n<li>Es werden nur Duplikate desselben Besuchers erfasst, daher wird dieselbe Bestellnummer, die von zwei verschiedenen Personen eingeht, zweimal gez\u00e4hlt.<\/li>\n\n\n\n<li>Wenn das Feld leer bleibt, behandelt GA4 jede dieser Bestellungen als identisch und fasst sie zu einer zusammen, was deinen Tagesumsatz zunichte machen kann, ohne dass irgendwo ein Fehler angezeigt wird.<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Betrachte das als Sicherheitsnetz. Wenn das Aktualisieren deiner Best\u00e4tigungsseite einen zweiten Kauf ausl\u00f6sen kann, behebe das Problem lieber, anstatt dich darauf zu verlassen, dass GA4 das in Ordnung bringt. <\/p>\n\n<h3 id=\"3-route-ga4-through-server-side-gtm\" class=\"wp-block-heading\">3. GA4 \u00fcber server-side GTM weiterleiten<\/h3>\n\n<p class=\"wp-block-paragraph\">Konfiguriere im Web-Container das Google-Tag mit dem Parameter \u201eserver_container_url\u201c. Sein Wert ist die First-Party-URL, die mit dem Server-Container verkn\u00fcpft ist. <\/p>\n\n<p class=\"wp-block-paragraph\">Event-Tags sollten denselben Route nutzen. Stell im Server-Container sicher, dass der GA4-Client die Anfrage annimmt, und leite sie dann an die richtige Property weiter. <\/p>\n\n<h3 id=\"4-configure-google-ads-and-meta\" class=\"wp-block-heading\">4. Google Ads und Meta konfigurieren<\/h3>\n\n<p class=\"wp-block-paragraph\">Erstelle f\u00fcr Google Ads das erforderliche server-side Conversion-Tag und ordne den Kaufwert, die W\u00e4hrung und die Transaktions-ID zu. Entferne oder deaktiviere eine \u00e4ltere Browser-Conversion f\u00fcr dieselbe Aktion, es sei denn, die Konfiguration sieht eine gezielte Ma\u00dfnahme vor, um doppelte Meldungen zu verhindern. <\/p>\n\n<p class=\"wp-block-paragraph\">Meta nutzt in der Regel ein Dual-Signal-Setup: das Meta-Pixel im Browser und die Conversions API (CAPI) auf dem Server. Beide Aufzeichnungen derselben Aktion m\u00fcssen denselben Ereignisnamen und dieselbe Ereignis-ID haben. Im Browser-Pixel wird der Parameter als \u201eeventID\u201c geschrieben; beim Server-Ereignis lautet er \u201eevent_id\u201c. Meta nutzt dieses Paar, um Duplikate zu erkennen.   <\/p>\n\n<p class=\"wp-block-paragraph\">Dahinter stecken zwei zeitliche Regeln. Meta gleicht die beiden Kopien nur ab, wenn sie innerhalb von 48 Stunden nacheinander eintreffen. Jede Konfiguration, bei der Serverdaten in zeitversetzten Stapeln gesendet werden, f\u00fchrt also zu einer Doppelz\u00e4hlung. Wenn beide Kopien ungef\u00e4hr zur gleichen Zeit eintreffen \u2013 was normal ist \u2013, beh\u00e4lt Meta die Browserversion bei.  <\/p>\n\n<p class=\"wp-block-paragraph\">Das kannst du \u00fcberpr\u00fcfen, ohne raten zu m\u00fcssen. Im Meta Events Manager wird eine korrekt zugeordnete Bestellung als ein Event aus zwei Quellen angezeigt. Wenn dort ein Event aus einer Quelle angezeigt wird oder sich deine Verkaufszahlen in etwa verdoppelt haben, stimmen der Ereignisname oder die ID nicht \u00fcberein.  <\/p>\n\n<p class=\"wp-block-paragraph\">Erzeuge die ID einmal und \u00fcbertrage sie dann in die Datenschicht und in beide Tags. Ein neuer Zufallswert, der separat in jedem Tag generiert wird, sorgt nicht f\u00fcr eine Duplikatsbereinigung. <\/p>\n\n<p class=\"wp-block-paragraph\">E-Mail oder Telefon k\u00f6nnen die Zuordnung verbessern, wenn das Gesch\u00e4ft die Daten erfasst hat und die Einwilligung deren Nutzung erlaubt. Befolge die Normalisierungs- und Hash-Anforderungen der jeweiligen Plattform. Lass Kundendaten nicht l\u00e4nger als n\u00f6tig in einer \u00f6ffentlichen Datenebene liegen.  <\/p>\n\n<h3 id=\"5-pass-consent-into-the-full-route\" class=\"wp-block-heading\">5. Die Einwilligung an die gesamte Route weiterleiten<\/h3>\n\n<p class=\"wp-block-paragraph\">Server-side Tracking ersetzt die Einwilligung nicht. Das CMP sollte die entsprechenden GTM-Einwilligungsstatus festlegen, bevor Tags Werbe- oder Analysedaten verarbeiten. <\/p>\n\n<p class=\"wp-block-paragraph\">Bei Google k\u00f6nnen zu diesen Zust\u00e4nden \u201eanalytics_storage\u201c, \u201ead_storage\u201c, \u201ead_user_data\u201c und \u201ead_personalization\u201c geh\u00f6ren. Andere Plattformen ben\u00f6tigen Steuerungsm\u00f6glichkeiten auf Tag-Ebene, die auf derselben Entscheidung des Besuchers basieren. \u00dcberpr\u00fcfe beide Container, anstatt davon auszugehen, dass das Server-Tag das richtige Verhalten \u00fcbernommen hat.  <\/p>\n\n<h3 id=\"6-test-the-complete-purchase-flow\" class=\"wp-block-heading\">6. Testet den gesamten Kaufprozess<\/h3>\n\n<p class=\"wp-block-paragraph\">F\u00fchre die GTM-Vorschau f\u00fcr beide Container durch. Teste das Hinzuf\u00fcgen zum Warenkorb per AJAX, den Gast-Checkout, die wichtigsten Zahlungsmethoden sowie die Layouts f\u00fcr Mobilger\u00e4te und Desktop-PCs. <\/p>\n\n<p class=\"wp-block-paragraph\">\u00dcberpr\u00fcfe bei einem Kauf Folgendes:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Die Datenschicht enth\u00e4lt ein Kaufereignis mit den korrekten Bestelldetails<\/li>\n\n\n\n<li>Web GTM sendet die Anfrage an die First-Party-Server-URL<\/li>\n\n\n\n<li>The server client receives and parses the event<\/li>\n\n\n\n<li>GA4- und Google Ads-Tags werden mit \u00fcbereinstimmendem Wert und derselben W\u00e4hrung ausgel\u00f6st<\/li>\n\n\n\n<li>Meta empf\u00e4ngt Browser- und Server-Events mit demselben Namen und derselben Ereignis-ID<\/li>\n\n\n\n<li>Der Befehl erscheint jeweils einmal in der Test- oder Debug-Ansicht der jeweiligen Plattform<\/li>\n<\/ul>\n\n<p class=\"wp-block-paragraph\">Die Vorschau zeigt, dass eine Anfrage gesendet wurde, nicht aber, dass die Bestellungen der letzten Woche korrekt sind. Vergleiche nach dem Start die WooCommerce-Bestellungen anhand der Transaktions-IDs mit den K\u00e4ufen auf der Plattform. <\/p>\n\n<h2 id=\"woocommerce-pitfalls-to-check-before-launch\" class=\"wp-block-heading\">WooCommerce-Fallstricke, die du vor dem Start \u00fcberpr\u00fcfen solltest<\/h2>\n\n<h3 id=\"block-checkout-updates\" class=\"wp-block-heading\">Aktualisierungen bei der Block-Kasse<\/h3>\n\n<p class=\"wp-block-paragraph\">Teste den Trichter erneut, nachdem du zwischen dem klassischen Checkout und den Checkout-Bl\u00f6cken gewechselt hast. Mach dasselbe, nachdem du ein Checkout-Plugin oder eine Zahlungsintegration ausgetauscht hast. Die sichtbare Seite kann fast identisch aussehen, w\u00e4hrend sich die darunter liegenden events ge\u00e4ndert haben.  <\/p>\n\n<h3 id=\"cache-on-cart-checkout-and-account-pages\" class=\"wp-block-heading\">Cache auf den Seiten \u201eWarenkorb\u201c, \u201eKasse\u201c und \u201eKonto\u201c<\/h3>\n\n<p class=\"wp-block-paragraph\">WooCommerce empfiehlt, die Seiten \u201eWarenkorb\u201c, \u201eKasse\u201c und \u201eKonto\u201c vom Vollseiten-Caching auszuschlie\u00dfen, da sie f\u00fcr jeden Besucher spezifische Inhalte enthalten. F\u00fcge dieser Liste zu Tracking-Zwecken auch die Bestellbest\u00e4tigungsseite hinzu. Eine zwischengespeicherte Seite kann veraltete Werte anzeigen oder das Laden der Bestelldetails g\u00e4nzlich verhindern, was dazu f\u00fchrt, dass das Kaufereignis mit fehlenden oder falschen Daten ausgel\u00f6st wird.  <\/p>\n\n<h3 id=\"duplicate-native-pixels\" class=\"wp-block-heading\">Native Pixel duplizieren<\/h3>\n\n<p class=\"wp-block-paragraph\">WooCommerce-Erweiterungen laden m\u00f6glicherweise Google-, Meta- oder TikTok-Tags ohne GTM. Behalte sie nur, wenn sie Teil des gew\u00e4hlten Designs sind. Andernfalls deaktiviere sie vor\u00fcbergehend und \u00fcberpr\u00fcfe anhand des Netzwerkprotokolls des Browsers, ob nur noch die beabsichtigten Anfragen \u00fcbrig bleiben.  <\/p>\n\n<h3 id=\"guest-email-timing\" class=\"wp-block-heading\">Zeitpunkt f\u00fcr die E-Mail an G\u00e4ste<\/h3>\n\n<p class=\"wp-block-paragraph\">Beim Bezahlvorgang als Gast kann die E-Mail-Adresse sp\u00e4ter erscheinen als die Warenkorbdaten. Ordne sie den Events zu, bei denen das Feld tats\u00e4chlich vorhanden ist \u2013 in der Regel beim Bezahlvorgang oder beim Kauf. \u00dcbertrage niemals einen Wert, der m\u00f6glicherweise zu einem anderen K\u00e4ufer geh\u00f6rt.  <\/p>\n\n<h3 id=\"tax-shipping-and-currency\" class=\"wp-block-heading\">Steuern, Versand und W\u00e4hrung<\/h3>\n\n<p class=\"wp-block-paragraph\">Lege fest, was ein Wert bedeutet, und verwende diese Definition \u00fcberall. Wenn ein Tag einen Gesamtbetrag inklusive Mehrwertsteuer \u00fcbermittelt, w\u00e4hrend ein anderer die Mehrwertsteuer ausklammert, entsteht eine L\u00fccke in der Berichterstattung \u2013 selbst wenn beide dieselbe Bestellung erfassen. <\/p>\n\n<p class=\"wp-block-paragraph\">Shops mit mehreren W\u00e4hrungen erfordern eine zus\u00e4tzliche \u00dcberpr\u00fcfung. Der W\u00e4hrungscode, die Artikelpreise und der Bestellwert m\u00fcssen sich auf dieselbe Transaktionsw\u00e4hrung beziehen und d\u00fcrfen keine Mischung aus der Basisw\u00e4hrung des Shops und der dem Kunden angezeigten W\u00e4hrung sein. <\/p>\n\n<h3 id=\"redirects-reloads-and-failed-payments\" class=\"wp-block-heading\">Weiterleitungen, Neuladungen und fehlgeschlagene Zahlungen<\/h3>\n\n<p class=\"wp-block-paragraph\">Teste alle wichtigen Zahlungsgateways, nicht nur die Standard-Kartenoption. Das Kaufevent sollte eine abgeschlossene Bestellung darstellen. Aufladungen d\u00fcrfen keine zweite Konversion ausl\u00f6sen, und eine fehlgeschlagene Zahlung sollte nicht wie ein Verkauf aussehen.  <\/p>\n\n<h3 id=\"refunds-and-cancellations\" class=\"wp-block-heading\">R\u00fcckerstattungen und Stornierungen<\/h3>\n\n<p class=\"wp-block-paragraph\">Dein Kaufereignis meldet die Bestellung so, wie sie aufgegeben wurde. Es wird nicht aktualisiert, wenn der Kunde die H\u00e4lfte davon zur\u00fcckschickt, sodass Google und Meta weiterhin auf der Grundlage des urspr\u00fcnglichen Betrags optimieren. In einem Shop mit hohen R\u00fccklaufquoten ist diese Diskrepanz gro\u00df genug, um zu beeinflussen, welche Kampagnen als profitabel erscheinen.  <\/p>\n\n<p class=\"wp-block-paragraph\">Jede Plattform handhabt das anders. GA4 nutzt daf\u00fcr ein R\u00fcckerstattungs-Event. Du \u00fcbermittelst die Bestellnummer, und GA4 sucht den passenden Kauf, von dem der Wert abgezogen werden soll. Wenn die Bestellnummern nicht \u00fcbereinstimmen, wird die R\u00fcckerstattung ignoriert und der Verkauf bleibt in deinen Berichten mit dem vollen Wert stehen. Google Ads nutzt Conversion-Anpassungen, die den Verkauf entweder entfernen oder seinen Wert \u00e4ndern. Meta korrigiert dies \u00fcber die Conversions-API anhand der Bestellnummer.     <\/p>\n\n<p class=\"wp-block-paragraph\">Lege vor dem Start fest, was als Verkauf gilt. Schreib es auf und sorge daf\u00fcr, dass auf jeder Plattform dieselbe Regel gilt. <\/p>\n\n<h3 id=\"common-problems-and-where-to-look\" class=\"wp-block-heading\"><strong>H\u00e4ufige Probleme und wo man nachsehen sollte<\/strong><\/h3>\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><tbody><tr><td><strong>Was du gerade siehst<\/strong><\/td><td><strong>Die wahrscheinlichste Ursache<\/strong><\/td><td><strong>Wo du nachsehen kannst<\/strong><\/td><\/tr><tr><td>Die Einnahmen bei GA4 sind ungef\u00e4hr doppelt so hoch wie bei WooCommerce<\/td><td>Zwei Dinge, die den Verkauf ausl\u00f6sen: meist ein Plugin und deine Tag-Einstellungen<\/td><td>Gib eine Testbestellung auf und z\u00e4hle, wie viele Kauf-Events angezeigt werden<\/td><\/tr><tr><td>Meta meldet etwa doppelt so hohe Ums\u00e4tze<\/td><td>The two instances of the event are not being matched<\/td><td>Der \u201eEvents Manager\u201c sollte ein Ereignis aus zwei Quellen anzeigen<\/td><\/tr><tr><td>Die GA4-Ums\u00e4tze liegen durchweg etwa 10 % unter denen von WooCommerce<\/td><td>Steuern oder Versandkosten sind an der einen Stelle enthalten, an der anderen aber nicht<\/td><td>Den Wert einer Bestellung mit dem Gesamtbetrag in WooCommerce vergleichen<\/td><\/tr><tr><td>\u201eIn den Warenkorb\u201c zeigt immer dasselbe Produkt an<\/td><td>Das Tag liest die Seite statt das Ereignis aus<\/td><td>\u00dcberpr\u00fcfe die Datenebene auf einer Kategorieseite<\/td><\/tr><tr><td>Umsatz, der nur bei einer Zahlungsmethode fehlt<\/td><td>Der Kunde ist vom Zahlungsanbieter nie zur\u00fcckgekommen<\/td><td>WooCommerce-Bestellungen nach Zahlungsart filtern und vergleichen<\/td><\/tr><tr><td>Safari-Besucher werden immer als neu angezeigt<\/td><td>Die Sieben-Tage-Frist von Safari wird angewendet<\/td><td>\u00dcberpr\u00fcfe die G\u00fcltigkeitsdauer des Cookies nach einer Testbestellung in Safari<\/td><\/tr><tr><td>Beim Aktualisieren wird der Kaufvorgang erneut ausgel\u00f6st<\/td><td>Das Tag ist an die Seite gebunden und nicht an die Bestellung<\/td><td>Lade die Best\u00e4tigungsseite neu und schau zu<\/td><\/tr><tr><td>Der Server empf\u00e4ngt \u00fcberhaupt nichts<\/td><td>Die Serveradresse fehlt oder die Domain ist noch nicht online<\/td><td>Rege im Browser auf der Registerkarte \u201eNetzwerk\u201c nach Anfragen an deine Tracking-Domain<\/td><\/tr><tr><td>Nach einem Update der Website sind die Verkaufszahlen pl\u00f6tzlich eingebrochen<\/td><td>Der Typ des Checkouts wurde ge\u00e4ndert oder ein Theme-Update hat die Seite ver\u00e4ndert<\/td><td>Teste den gesamten Ablauf noch einmal<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<h2 id=\"dual-signal-or-server-only\" class=\"wp-block-heading\">Dual-Signal oder nur Server?<\/h2>\n\n<p class=\"wp-block-paragraph\">\u201eserver-side\u201c hei\u00dft nicht automatisch \u201eohne Browser\u201c. Das richtige Modell h\u00e4ngt vom Ziel ab. <\/p>\n\n<p class=\"wp-block-paragraph\">Meta und TikTok empfehlen, Browser- und Serversignale gemeinsam zu nutzen, wobei \u00fcbereinstimmende IDs zur Duplikatsbereinigung verwendet werden. Google Ads bietet zwei Optionen, die unterschiedlich funktionieren. Du kannst eine Conversion aus GA4 importieren, wobei GA4 die Messung durchf\u00fchrt und Google Ads das Ergebnis \u00fcbernimmt. Du kannst die Conversion aber auch direkt aus deinem Server-Container senden.   <\/p>\n\n<p class=\"wp-block-paragraph\">Die zweite Option h\u00e4ngt davon ab, dass die Google Ads-Klick-ID \u00fcber den gesamten Weg erhalten bleibt. Wenn ein Zahlungsanbieter sie auf dem R\u00fcckweg aus der Webadresse entfernt, hat Google Ads keine Grundlage mehr, um den Verkauf zuzuordnen. W\u00e4hle pro Conversion eine Option aus und deaktiviere die andere, denn wenn du beide Optionen ohne einen Plan zum Abgleich laufen l\u00e4sst, werden deine gemeldeten Ums\u00e4tze aufgebl\u00e4ht und das automatische Bidding verwirrt.  <\/p>\n\n<p class=\"wp-block-paragraph\">  Tools zur Kundenbindung, die keine geeignete Dublettenbereinigung bieten, erfordern m\u00f6glicherweise eine reine Server-L\u00f6sung.<\/p>\n\n<p class=\"wp-block-paragraph\">Nutze den <a href=\"https:\/\/taggrs.io\/de\/which-platforms-support-server-side-gtm\/\">server-side GTM-Plattform-Checker<\/a>, um die aktuelle Platzierung f\u00fcr jedes Ziel zu \u00fcberpr\u00fcfen. Kopiere das Muster einer Plattform nicht einfach auf eine andere. Die APIs und die Regeln zur Duplikatsbereinigung unterscheiden sich.  <\/p>\n\n<h2 id=\"where-taggrs-fits\" class=\"wp-block-heading\">Wo TAGGRS passt<\/h2>\n\n<p class=\"wp-block-paragraph\">F\u00fcr die Einrichtung werden zwei Komponenten ben\u00f6tigt, die in einer Standard-WooCommerce-Installation nicht enthalten sind: ein zuverl\u00e4ssiger GA4-Datenlayer und ein Ort, an dem der GTM-Container auf dem Server ausgef\u00fchrt werden kann.<\/p>\n\n<p class=\"wp-block-paragraph\">TAGGRS bietet verwaltetes server-side GTM-Hosting und eine First-Party-Tagging-URL. <a href=\"https:\/\/taggrs.io\/docs\/server-side-tracking\/woocommerce-data-layer\/\">Die Dokumentation zum WooCommerce-Data-Layer-Plugin<\/a> behandelt die Installation, die Web-GTM-Container-ID, unterst\u00fctzte GA4-E-Commerce-Events und den Debug-Modus. <\/p>\n\n<p class=\"wp-block-paragraph\">Das Plugin unterst\u00fctzt au\u00dferdem das optionale <a href=\"https:\/\/taggrs.io\/de\/enhanced-tracking-script-against-ad-blockers\/\">TAGGRS Enhanced Tracking Script (ETS) v3<\/a>, das die gesamte Anfrage vom Browser zum Server verschl\u00fcsselt, sodass Filterlisten keine \u00dcbereinstimmungen mit g\u00e4ngigen Tracking-Markern finden k\u00f6nnen. Die Einwilligungsregeln gelten weiterhin, und kein Skript kann eine Interaktion weiterleiten, die der Shop nie erfasst hat. <\/p>\n\n<p class=\"wp-block-paragraph\">F\u00fcr Shops, die von einer anderen Plattform umsteigen, folgt <a href=\"https:\/\/taggrs.io\/de\/?p=73343\">der Leitfaden zum server-side Tracking bei Shopify<\/a> dem gleichen Prinzip, nur mit einem anderen CMS. Shopify hat sein eigenes Pixel und sein eigenes Checkout-Modell. Bei WooCommerce muss man sich mehr mit Bl\u00f6cken, WordPress-Plugins, Caching und Zahlungsgateways besch\u00e4ftigen.  <\/p>\n\n<h2 id=\"conclusion\" class=\"wp-block-heading\">Fazit<\/h2>\n\n<p class=\"wp-block-paragraph\">Ein Tag auf der Dankesseite ist eine unsichere Grundlage f\u00fcr die Umsatzauswertung. Es passiert einfach zu viel, bevor der K\u00e4ufer dort ankommt, und WordPress gibt jedem Plugin die M\u00f6glichkeit, sich einzumischen. <\/p>\n\n<p class=\"wp-block-paragraph\">Ein WooCommerce-Datenlayer und server-side GTM sorgen f\u00fcr eine klarere Abgrenzung. WooCommerce beschreibt das Ereignis einmal, Web-GTM leitet es mit dem richtigen Einwilligungsstatus weiter, und der Server-Container \u00fcbernimmt die Bereitstellung auf der Plattform. Die Einrichtung muss noch sorgf\u00e4ltig getestet werden. Zumindest werden die Fehler nun in einer einzigen Pipeline sichtbar, anstatt sich in einem Haufen von Pixeln zu verstecken.   <\/p>\n\n<p class=\"wp-block-paragraph\"><strong><em>M\u00f6chtest du das server-side Tracking in deiner WooCommerce-Installation ausprobieren?<\/em><\/strong><a href=\"https:\/\/dashboard.taggrs.io\/de\/register\"><em> <\/em><em>Erstelle ein kostenloses TAGGRS-Konto<\/em><\/a><em> oder<\/em><a href=\"https:\/\/taggrs.io\/de\/demo-anfordern\/\"><em> <\/em><em>buche eine Demo<\/em><\/a><em> , um deine konkreten Tracking-Anforderungen zu besprechen.<\/em><\/p>\n\n<h2 id=\"faq\" class=\"wp-block-heading\">FAQ<\/h2>\n\n<h3 id=\"do-i-still-need-web-gtm\" class=\"wp-block-heading\">Brauche ich Web-GTM noch?<\/h3>\n\n<p class=\"wp-block-paragraph\">Ja. Interaktionen im Shop beginnen im Browser. Web GTM erfasst sie und leitet sie an den Server weiter. Um Backend-Bestellevents direkt zu senden, ist eine separate individuelle L\u00f6sung erforderlich.   <\/p>\n\n<h3 id=\"can-server-side-tracking-bypass-every-ad-blocker\" class=\"wp-block-heading\">Kann server-side Tracking jeden Werbeblocker umgehen?<\/h3>\n\n<p class=\"wp-block-paragraph\">Nein, es umgeht vielleicht nicht jeden Werbeblocker. Die Filterlisten der Werbeblocker werden st\u00e4ndig aktualisiert, daher kann alles, was heute noch funktioniert, n\u00e4chsten Monat schon nicht mehr funktionieren. <\/p>\n\n<p class=\"wp-block-paragraph\">Was du tun kannst, ist, dein Tracking schwerer erkennbar zu machen. Bei einer Standardkonfiguration werden Daten an Webadressen gesendet, die offensichtliche Tracking-Begriffe enthalten, nach denen Blocker suchen. Das \u201eTAGGRS Enhanced Tracking Script v3\u201c entfernt diese Muster, sodass es nichts Offensichtliches gibt, das abgeglichen werden k\u00f6nnte. Bei TAGGRS liegt unsere typische Wiedergewinnungsrate zwischen 9,1 % und ca. 30 %.   <\/p>\n\n<p class=\"wp-block-paragraph\">Zwei Einschr\u00e4nkungen bleiben bestehen. Die Einwilligungsregeln gelten weiterhin; wenn ein Besucher also das Tracking ablehnt, sollte das Event gar nicht erst gesendet werden. Zweitens sch\u00fctzt das Skript Daten nur auf ihrem Weg vom Browser zu deinem Server. Wenn dein Setup den Verkauf von vornherein gar nicht erfasst hat, k\u00f6nnen die Daten auch nicht erfasst werden. Deshalb ist die Datenebene wichtiger als jedes Skript, das du dar\u00fcber legst.    <\/p>\n\n<h3 id=\"should-meta-pixel-stay-enabled-with-meta-capi\" class=\"wp-block-heading\">Sollte Meta Pixel bei Meta CAPI aktiviert bleiben?<\/h3>\n\n<p class=\"wp-block-paragraph\">Meta empfiehlt, Browser- und Server-Signale gemeinsam zu nutzen, sofern beide korrekt implementiert werden k\u00f6nnen. Die Namen der Events und IDs m\u00fcssen \u00fcbereinstimmen, damit Meta die Aktion nur einmal z\u00e4hlen kann. <\/p>\n\n<h3 id=\"is-woocommerce-server-side-tracking-the-same-as-shopify-server-side-tracking\" class=\"wp-block-heading\">Ist das server-side Tracking bei WooCommerce dasselbe wie das server-side Tracking bei Shopify?<\/h3>\n\n<p class=\"wp-block-paragraph\">Der Aufbau ist derselbe: Commerce-Event, Datenschicht, Web-GTM, Server-GTM, Ziel. WooCommerce bietet mehr Varianten bei den Checkout-Typen, beim Caching und bei den Plugins, daher ist das Testen in der Regel aufwendiger. <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Die \u00fcbliche WooCommerce-Tracking-Einrichtung besteht aus einem Pixel auf der Website und einem Kauf-Tag auf der ...<\/p>\n","protected":false},"author":15,"featured_media":81798,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[348],"tags":[],"class_list":["post-81804","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-side-tracking-de-2"],"acf":[],"_links":{"self":[{"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/posts\/81804","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/users\/15"}],"replies":[{"embeddable":true,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/comments?post=81804"}],"version-history":[{"count":3,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/posts\/81804\/revisions"}],"predecessor-version":[{"id":81836,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/posts\/81804\/revisions\/81836"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/media\/81798"}],"wp:attachment":[{"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/media?parent=81804"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/categories?post=81804"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/taggrs.io\/de\/wp-json\/wp\/v2\/tags?post=81804"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}