> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dreizack-medien.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Tracking

> Test-Modi, Artikelnummer im Tracking, interne Shop-Statistik und die Übersicht aller Käufe, die der Shop zusätzlich vom Server meldet.

## Übersicht

In der Ansicht **Tracking** von DZM Resources steuerst du die Tracking-Grundlage deines Shops. DZM Resources erzeugt die E-Commerce-Ereignisse (Artikelansicht, Warenkorb, Checkout, Kauf) einmal zentral nach dem Standard von Google Analytics 4. Die Tracking-Dienste selbst – Google Tag Manager, Meta Pixel, TikTok Pixel und weitere – richtest du in NIU Plus ein, siehe [Consent & Tracking einrichten](/NIU-Plus/consent).

Hier findest du:

<CardGroup cols={2}>
  <Card title="Artikel-IDs" icon="barcode" href="#artikel-ids">
    Welche Artikelnummer an GA4, Meta und Co. geht.
  </Card>

  <Card title="Test-Modi" icon="flask" href="#test-modi">
    Tracking prüfen, ohne eine Einwilligung zu umgehen.
  </Card>

  <Card title="Interne Statistik" icon="chart-line" href="#interne-statistik">
    Eigene Kennzahlen des Shops, ohne Besucher-Kennung.
  </Card>

  <Card title="Server-Side-Tracking" icon="server" href="#server-side-tracking">
    Alle Käufe und Stornos, die der Shop zusätzlich vom Server meldet.
  </Card>
</CardGroup>

Die Einstellungen speicherst du gemeinsam über den Speichern-Button der Ansicht.

***

## Artikel-IDs

Legt fest, welche Artikelnummer als `item_id` an GA4, Meta und Co. übergeben wird. Sie sollte zu deinen Produkt-Feeds passen, z. B. Google Shopping oder dem Meta-Katalog.

<ParamField path="Varianten-ID" type="select">
  * **Kind-Artikelnummer (Standard):** Bei Varianten wird die Artikelnummer der gewählten Variante übergeben.
  * **Vater-Artikelnummer:** Es wird immer die Artikelnummer des Vaterartikels übergeben.

  Bei Varianten wird zusätzlich immer die Vater-Artikelnummer als `item_group_id` übergeben.
</ParamField>

***

## Test-Modi

Zum Prüfen deines Tracking-Setups musst du keine Einwilligung im Banner umgehen. Es gibt drei Test-Modi:

| Modus | Für wen | Wirkt auf Server-Side-Tracking |
| - | - | - |
| Admin-Debug | nur den eingeloggten Backend-Admin | – |
| Test-Link | nur den Browser, der den Link geöffnet hat | ja |
| Globaler Testmodus | alle Besucher, höchstens 7 Tage | nein |

<Note>
  **Für das Server-Side-Tracking zählt nur der Test-Link.** Der globale Testmodus wirkt nur im Browser – sonst gingen Bestellungen echter Kunden ohne Einwilligung vom Server an die Dienste. Mehr dazu unter [Server-Side und Einwilligung](/NIU-Plus/consent#server-side-und-einwilligung).
</Note>

### Admin-Debug

Bist du im Backend eingeloggt, siehst du im Shop alle Tracking-Events in der Browser-Konsole und in einem kleinen Overlay.

<ParamField path="Admin-Debug aktivieren" type="boolean">
  Schaltet die Anzeige der Events für den eingeloggten Admin ein.
</ParamField>

<ParamField path="Trocken (nichts senden)" type="boolean">
  Die Tools bekommen die Events, senden sie aber nicht ab. Gilt nur für den eingeloggten Admin.
</ParamField>

### Test-Link

Wer den Link öffnet, wird per Cookie als Tester markiert. Nur in diesem Browser wird die Einwilligung übergangen – zum Beispiel für die Prüfung in GA4 DebugView durch eine Agentur. Bestellungen aus diesem Browser gehen auch an das Server-Side-Tracking.

<Steps>
  <Step title="Gültigkeit festlegen">
    Lege unter „Gültigkeit neuer Links“ fest, wie viele Tage ein neuer Link gilt (1 bis 90, Standard 7).
  </Step>

  <Step title="Link erzeugen">
    Gib unter „Neuen Test-Link erzeugen“ eine Bezeichnung ein, z. B. „Agentur“, und klicke auf **Erzeugen**.
  </Step>

  <Step title="Speichern">
    Speichere die Ansicht. Neue oder widerrufene Links gelten erst nach dem Speichern.
  </Step>

  <Step title="Link weitergeben">
    Kopiere den Link über **Link kopieren** und öffne ihn im Browser, in dem getestet werden soll. Mit **Widerrufen** und anschließendem Speichern machst du einen Link vorzeitig ungültig.
  </Step>
</Steps>

<Tip>
  Für einen Test des Server-Side-Trackings nimmst du am besten eine Zahlart, bei der die Bestellung vor der Zahlung angelegt wird, z. B. Vorkasse oder Rechnung. Wird die Bestellung erst nach der Zahlung beim Zahlungsanbieter angelegt, fehlt dem Shop in diesem Moment das Test-Link-Cookie.
</Tip>

### Globaler Testmodus

Übergeht die Einwilligung für **alle** Besucher des Shops. Nur für Testshops gedacht.

<ParamField path="Globalen Testmodus aktivieren" type="boolean">
  Schaltet den Modus ein. Wirksam wird er erst, wenn du zusätzlich „Ich habe den Hinweis gelesen und übernehme die Verantwortung“ bestätigst und speicherst.
</ParamField>

<ParamField path="Läuft ab am" type="datetime">
  Zeitpunkt, zu dem sich der Modus automatisch abschaltet – höchstens 7 Tage in der Zukunft. Liegt das Datum weiter in der Zukunft, bleibt der Modus wirkungslos.
</ParamField>

<Warning>
  **Nur zu Testzwecken und auf eigene Verantwortung.** Solange dieser Modus aktiv ist, laden alle Tracking-Tools bei allen Besuchern ohne Einwilligung und senden Daten. Das ist eine Datenschutzverletzung, wenn der rechtliche Rahmen des Shops das nicht abdeckt. Solange der Modus läuft, zeigt das Backend einen Hinweis.
</Warning>

***

## Interne Statistik

Der Shop zählt eigene Kennzahlen – Seitenaufrufe, Einstiege, Warenkorb, Checkout, Käufe – unabhängig von GA4 & Co. und ohne Besucher-Kennung. Die Auswertung findest du unter [Analysen → Shop-Statistik](/Resources-and-Health/analyse#shop-statistik).

<ParamField path="Interne Statistik" type="boolean">
  Tageswerte ohne Kennung des Besuchers: keine IP, kein eigenes Cookie, keine Kunden- oder Bestellnummer. Den laufenden Besuch kennt nur die Shop-Session. Standard: an.
</ParamField>

<ParamField path="Besuche auswerten" type="boolean">
  Zusätzlich eine anonyme Zeile je Besuch (Einstieg, Quelle, Gerät, erreichte Checkout-Schritte, Dauer – Uhrzeit nur auf die Stunde). Damit bekommst du einen genaueren Checkout-Trichter mit Anteilen und Abbrüchen je Besuch sowie die Consent-Quote. Standard: aus.

  Beim Einschalten zeigt das Backend diesen Hinweis:

  <Warning>
    **Bitte vor dem Einschalten rechtlich prüfen.** Mit der Besuchsauswertung speichert der Shop zu jedem Besuch eine anonyme Zeile (Verlauf aus der Sitzung), und der Browser meldet den Stand der Einwilligungen an den Shop. Gespeichert wird keine Kennung des Besuchers. Ob das ohne Einwilligung zulässig ist, hängt vom Einzelfall ab – das ist keine Rechtsberatung. Gegebenenfalls in der Datenschutzerklärung ergänzen.
  </Warning>
</ParamField>

<ParamField path="Tageswerte aufbewahren" type="number">
  In Monaten, Standard 25. Ältere Daten löscht eine tägliche Aufgabe.
</ParamField>

<ParamField path="Besuche aufbewahren" type="number">
  In Monaten, Standard 13. So weit reicht auch der Checkout-Trichter je Besuch zurück.
</ParamField>

Das Aufräumen übernimmt die Aufgabe „DZM Resources: Shop-Statistik aufräumen“, die täglich läuft – auch bei ausgeschalteter Statistik.

***

## Server-Side-Tracking

Die Box **Server-Side-Tracking: Versände** zeigt alle Käufe und Stornos, die der Shop zusätzlich vom Server an GA4, Meta und TikTok meldet. Gesendet wird stündlich per Cron und nur mit Einwilligung des Käufers. Die Ziele schaltest du im NIU-Plus-Companion ein:

* [GA4 vom Server (Measurement Protocol)](/NIU-Plus/gtm#ga4-vom-server-measurement-protocol)
* [Meta Conversions API](/NIU-Plus/tracking#meta-conversions-api)
* [TikTok Events API](/NIU-Plus/tracking#tiktok-events-api)

### Aufbau der Übersicht

Oben siehst du je Ziel (GA4, Meta, TikTok), wie viele Versände in welchem Status sind. Ist noch kein Ziel eingerichtet, zeigt die Box „Kein Server-Side-Ziel aktiv.“ Darunter filterst du die Tabelle nach Ziel und Status und lädst sie mit **Aktualisieren** neu.

| Spalte | Inhalt |
| - | - |
| Angelegt | Zeitpunkt der Bestellung bzw. des Stornos |
| Ziel | GA4, Meta oder TikTok |
| Ereignis | `purchase` (Kauf) oder `refund` (Storno) |
| Bestellung | Bestellnummer |
| Status | siehe unten. Zeigst du mit der Maus auf den Status, siehst du den Stand der Einwilligung bei der Bestellabgabe bzw. „Test-Link“. |
| Versuche | Anzahl der Sendeversuche |
| Zuletzt / gesendet | letzter Versuch bzw. Zeitpunkt des Versands, bei offenen Zeilen zusätzlich der nächste Versuch |
| Meldung | Antwort des Dienstes oder Grund, warum nicht gesendet wurde |

### Status

<AccordionGroup>
  <Accordion title="offen">
    Der Versand steht an und geht mit dem nächsten Lauf des Cronjobs raus. Schlägt ein Versuch vorübergehend fehl, bleibt die Zeile offen und wird mit wachsendem Abstand erneut versucht, insgesamt bis zu fünfmal.
  </Accordion>

  <Accordion title="wird gesendet">
    Der Cronjob verarbeitet die Zeile gerade.
  </Accordion>

  <Accordion title="gesendet">
    Der Dienst hat das Ereignis angenommen. Die Meldung enthält seine Antwort, z. B. „TikTok: angenommen“ oder bei GA4 im Debug-Modus „GA4 Debug: keine Validierungsfehler (nicht aufgezeichnet)“.
  </Accordion>

  <Accordion title="fehlgeschlagen">
    Der Versand ist endgültig nicht möglich. Typische Meldungen:

    * „GA4: Mess-ID oder API-Secret fehlt“, „Meta: Pixel-ID oder Zugangstoken fehlt“, „TikTok: Pixel-ID oder Zugangstoken fehlt“ – Zugangsdaten im Companion prüfen.
    * „Kein \_ga-Cookie bei Bestellabgabe – GA4 kann den Kauf keiner Sitzung zuordnen“
    * „Ereignis älter als 72 Stunden – GA4 nimmt es nicht mehr an“ – GA4 nimmt Käufe nur bis 72 Stunden danach an, z. B. wenn der Cronjob länger nicht lief.
    * „Kauf wurde im Debug-Modus gemeldet und von GA4 nicht gezählt – kein refund“
    * Eine Fehlermeldung des Dienstes, z. B. bei einem ungültigen Token.
  </Accordion>

  <Accordion title="übersprungen">
    Der Shop hat bewusst nicht gesendet. Typische Meldungen:

    * „Keine Einwilligung: …“ – der Käufer hatte dem Dienst bei der Bestellung nicht zugestimmt, z. B. „Keine Einwilligung: niu\_ga4 denied“.
    * „refund ausgeschaltet“ – eine Bestellung mit gemeldetem Kauf wurde storniert, „Stornos als refund senden“ ist aber aus.
    * „kein gemeldeter Kauf zu dieser Bestellung“ – der Storno betrifft eine Bestellung, deren Kauf nicht vom Server gemeldet wurde.
    * „Kauf nicht gesendet (Status …)“ bzw. „Kauf wurde nicht gemeldet“ – der zugehörige Kauf ging nicht raus, deshalb auch kein Storno.
  </Accordion>
</AccordionGroup>

<Info>
  Meta und TikTok bekommen nur Käufe. Stornos (`refund`) gehen ausschließlich an GA4 und nur, wenn eine Bestellung in der JTL-Wawi vollständig storniert wird.
</Info>

### Cronjobs

Zwei Aufgaben von DZM Resources gehören zum Tracking. Beide werden bei der Installation bzw. beim Update automatisch angelegt und sind unter [Cronjobs](/Resources-and-Health/cronjobs) sichtbar.

| Aufgabe | Takt | Zweck |
| - | - | - |
| DZM Resources: Server-Side-Tracking senden | stündlich | verschickt offene Käufe und Stornos |
| DZM Resources: Shop-Statistik aufräumen | täglich | löscht Daten der Shop-Statistik nach Ablauf der Aufbewahrung |

<Warning>
  **Cron fehlt:** Fehlt die Aufgabe „DZM Resources: Server-Side-Tracking senden“, zeigt die Übersicht den Hinweis „Die Aufgabe „DZM Resources: Server-Side-Tracking senden“ fehlt – es wird nichts gesendet.“ Lege sie dann unter **Administration → System → Cron** neu an (stündlich). Fehlt die Aufräum-Aufgabe, weist die Shop-Statistik darauf hin; lege sie ebenso neu an (täglich).
</Warning>

### Aufbewahrung

Die Daten für den Versand – Bestelldaten und Kennungen wie IP-Adresse, Browserkennung und Cookie-Kennungen – bewahrt der Shop höchstens 90 Tage auf, danach werden sie geleert. Was bis dahin nicht gesendet wurde, gilt als fehlgeschlagen. Die Zeilen der Übersicht selbst werden nach 13 Monaten gelöscht.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.