# Trackdolphin > Serverseitiges Tracking für Onlineshops. Käufe kommen aus dem Shop-Backend statt aus dem Browser — kein Werbeblocker, kein Consent-Banner und keine fehlgeschlagene Rückleitung kann sie verhindern. Jede Fähigkeit ist über eine dokumentierte API erreichbar; MCP-Server und Kommandozeile leiten sich daraus ab. --- # Was Trackdolphin macht Trackdolphin misst Käufe **im Shop-Backend** und meldet sie an Google Ads, Meta, GA4 und LinkedIn. Nicht im Browser. Das klingt nach einem technischen Detail und ist der ganze Unterschied. ## Warum nicht im Browser Ein Kauf, den nur der Browser meldet, geht auf drei Wegen verloren: - **Der Werbeblocker** verhindert das Skript. Je nach Zielgruppe betrifft das 20 bis 40 Prozent der Besucher. - **Das Consent-Banner** blockiert es, bis jemand zustimmt — viele klicken erst nach dem Kauf oder nie. - **Die Rückleitung schlägt fehl.** Wer über PayPal oder Klarna bezahlt und die App schließt, sieht die Danke-Seite nie. Der Kauf ist im Shop, das Event nicht. Der dritte Fall ist der ärgerlichste, weil er ausgerechnet die Käufer trifft, die schon bezahlt haben. ## Was stattdessen passiert Der Shop meldet die Bestellung selbst — mit dem Betrag, den auch die Rechnung zeigt. Kein Werbeblocker steht dazwischen, kein Skript kann fehlschlagen. Der Browser meldet weiterhin, was nur er wissen kann: welche Produkte angesehen wurden, was in den Warenkorb ging, wo der Checkout abgebrochen wurde. Beide Wege tragen dieselbe `event_id`. Kommt ein Kauf über beide, erkennen die Plattformen die Dublette und zählen ihn einmal. ## Was das in Zahlen heißt Nach der Einrichtung importiert Trackdolphin die Bestellhistorie aus deinem Shop und vergleicht sie mit dem, was dein bisheriges Tracking gemeldet hat. Das Ergebnis ist eine Zahl, keine Behauptung: > 412 Bestellungen im Shop, 287 davon gemeldet — 125 fehlten, > 14.900 € Umsatz ohne Zuordnung. Siehe [Historie und Erkennungsquote](/docs/backfill.md). ## Wie es weitergeht - [Schnellstart WooCommerce](/docs/quickstart-woocommerce.md) - [Schnellstart Shopware](/docs/quickstart-shopware.md) - [Eigene Anbindung über das SDK](/docs/sdk.md) — für alles andere - [Die Anwendung im Überblick](/docs/app.md) — jede Seite mit Bildschirmfoto erklärt --- # Schnellstart WooCommerce > **Hinweis:** Voraussetzung ist WooCommerce 8.5 oder neuer. Ältere Versionen > funktionieren auch, liefern aber keine Order Attribution — siehe unten. ## 1. Plugin installieren Lade das Plugin im Dashboard unter **Einrichtung** herunter und installiere es in WordPress unter *Plugins → Installieren → Plugin hochladen*. Danach aktivieren. ## 2. Zwei Werte eintragen Unter *Einstellungen → Trackdolphin* trägst du ein, was im Dashboard steht: - **Collector-Endpoint** — wohin die Events gehen - **Shop-ID** — welcher Shop du bist Haken bei „aktiv“ setzen, speichern. Das war die Einrichtung. ## 3. Prüfen, ob etwas ankommt Ruf eine Produktseite in deinem Shop auf. Im Dashboard unter **Einrichtung** zählt der Eventzähler innerhalb weniger Sekunden hoch. Kommt nichts an, sind das die üblichen Ursachen: - Der Haken bei „aktiv“ fehlt. - Die Shop-ID hat einen Tippfehler — der Collector antwortet dann mit `unknown_shop` statt stillschweigend anzunehmen. - Ein Sicherheits-Plugin blockiert ausgehende Verbindungen von WordPress. ## Was das Plugin sendet Aus dem Browser: Seitenaufrufe, angesehene Produkte, Warenkorb-Bewegungen, Checkout-Schritte. Mit echten Produktdaten aus PHP, nicht aus dem HTML gelesen — ein aus dem Markup gelesener Preis bricht beim nächsten Theme-Update. Vom Server: den Kauf. Dreifach abgesichert über `woocommerce_thankyou`, `payment_complete` und den Statuswechsel. Wer die Danke-Seite nie erreicht, wird trotzdem gezählt. Dazu Stornos und Teilerstattungen — sonst bleibt eine erstattete Bestellung dauerhaft als Umsatz stehen und der ROAS sieht besser aus, als er ist. ## Order Attribution WooCommerce schreibt seit Version 8.5 zu jeder Bestellung mit, woher der Käufer kam: Quelle, alle UTM-Parameter, Referrer, Gerätetyp, wievielte Sitzung. Das ist der einzige Datensatz, der eine Bestellung ohne durchgehende Cookie-Kette einem Kanal zuordnet — bei gelöschten Cookies, gekürzter Speicherdauer oder einem Kauf auf dem Zweitgerät bleibt sonst nichts übrig. Trackdolphin liest ihn aus und schickt ihn mit. ## Danach [Historie importieren](/docs/backfill.md) — das zeigt dir in Zahlen, wie viel dein bisheriges Tracking übersehen hat. --- # Schnellstart Shopware > **Hinweis:** Voraussetzung ist Shopware 6.4 oder neuer. ## 1. Erweiterung installieren Lade das Plugin im Dashboard unter **Einrichtung** herunter. In der Shopware- Verwaltung: *Erweiterungen → Meine Erweiterungen → Erweiterung hochladen*. Danach installieren und aktivieren. ## 2. Zwei Werte eintragen Öffne die Konfiguration der Erweiterung und trage ein, was im Dashboard steht: - **Collector-Endpoint** - **Shop-ID** „Tracking aktiv“ einschalten, speichern. Betreibst du mehrere Verkaufskanäle, konfigurierst du sie einzeln — jeder Kanal sollte eine eigene Shop-ID bekommen, sonst laufen die Zahlen zusammen. ## 3. Prüfen Ruf eine Produktseite auf. Der Eventzähler im Dashboard reagiert innerhalb weniger Sekunden. ## Zugangsdaten für den Import Für den [Historienimport](/docs/backfill.md) braucht Trackdolphin lesenden Zugriff auf die Admin-API: *Einstellungen → System → Integrationen → Integration hinzufügen*. Eine Rolle mit **Leserechten auf Bestellungen** genügt — Trackdolphin schreibt nichts in deinen Shop. Access Key ID und Secret Access Key werden nur einmal angezeigt. --- # SDK für eigene Anbindungen Nicht jeder Kunde hat WooCommerce oder Shopware. Ein Fitnessstudio verkauft keine Artikel, es bucht Probetrainings; ein Buchungssystem hat gar keinen Warenkorb. Für alles außerhalb der Plugins gibt es das SDK. ## Im Browser ```js import { init, viewItem, purchase } from "@trackdolphin/sdk"; init({ shopId: "shop_meinshop_de_ab12cd", url: "https://td.meinshop.de/collect" }); viewItem([{ id: "SKU-1", name: "Laufschuh", price: 119.9 }], 119.9); ``` Das SDK übernimmt dabei still einiges, was sonst schiefgeht: - **First-Touch-Attribution** über 90 Tage, damit der Kanal auch beim zweiten Besuch noch bekannt ist - **Klick-IDs** aus der Adresszeile in Cookies sichern (`gclid`, `gbraid`, `wbraid`, `fbclid`) - **Besucherkennung** als First-Party-Cookie — sie verbindet die anonyme Reise, bis eine gehashte E-Mail bekannt wird - **Warteschlange**, solange keine Einwilligung vorliegt ## Auf dem Server Der Abschluss gehört auf den Server — dort kann ihn kein Werbeblocker verhindern und niemand fälschen. ```ts import { createClient } from "@trackdolphin/sdk/server"; const td = createClient({ shopId: "shop_meinshop_de_ab12cd", url: "https://td.meinshop.de/collect", }); await td.track({ type: "purchase", event_id: `order_${order.id}`, // aus der Bestellnummer, nicht zufällig value: order.total, currency: "EUR", email: order.email, // wird lokal gehasht, nie im Klartext gesendet phone: order.phone, }); ``` ## Reihenfolge: erst das Geschäft, dann die Messung ```ts const lead = await createLead(input); // zuerst try { await td.track({ type: "lead", event_id: `lead_${lead.id}`, email: input.email }); } catch (e) { logger.error("Tracking fehlgeschlagen — Lead ist gesichert", e); } ``` Fällt das Tracking aus, ist der Lead trotzdem da. Andersherum kostet ein Ausfall bei uns dich einen Kunden — das darf nie passieren. ## Die event_id leiten, nicht würfeln ```ts event_id: `order_${order.id}` ``` Eine abgeleitete Kennung macht jeden Versand wiederholbar: Zeitüberschreitung, Neustart, doppelter Webhook — die Plattform erkennt die Dublette und zählt einmal. Ein Zufallswert erzeugt bei jedem Versuch eine neue Conversion. ## Klartext bleibt bei dir E-Mail und Telefonnummer werden **lokal** gehasht, bevor irgendetwas das Gerät oder deinen Server verlässt. Telefonnummern nach E.164 ohne Plus — `0171…` wird zu `49171…`, sonst trifft der Hash bei Meta und Google nie. Siehe [Match-Qualität](/docs/matching.md). ## Historie einspielen Auch der Backfill läuft über das SDK — siehe [Historie und Erkennungsquote](/docs/backfill.md). --- # Historie und Erkennungsquote Wer heute anfängt zu messen, misst ab heute. Damit lässt sich weder sagen, ob die Werbung im letzten Quartal funktioniert hat, noch wie viel das bisherige Tracking überhaupt erfasst hat. Der Import holt beides nach. ## Was passiert Trackdolphin liest die Bestellungen aus deinem Shop-System, vergleicht sie mit dem, was das Tracking von sich aus gemeldet hat, und trägt die Lücken nach. Das Ergebnis ist eine Zahl: > 412 Bestellungen im Shop, 287 davon gemeldet — 125 fehlten, > 14.900 € Umsatz ohne Zuordnung. ## Einrichten 1. Im Dashboard unter **Historie** die Zugangsdaten deines Shop-Systems hinterlegen. **Leserechte genügen.** 2. Die Verbindung wird sofort geprüft — falsche Zugangsdaten fallen hier auf, nicht erst im nächtlichen Lauf. 3. Import starten. Je nach Größe dauert er Minuten; du bekommst eine E-Mail, wenn er fertig ist. ## Was gezählt wird und was nicht Stornierte Bestellungen fließen **nicht** in die Quote. Eine stornierte Bestellung nicht gemeldet zu haben ist kein Verlust — sie als entgangenen Umsatz auszuweisen wäre eine geschönte Zahl. Sie werden trotzdem importiert, als Korrektur. ## Zweimal importieren ist gefahrlos Die `event_id` ist aus Shop und Bestellnummer abgeleitet. Ein zweiter Lauf kostet Zeit, sonst nichts: Bereits erfasste Bestellungen fallen heraus, statt doppelt zu zählen. Nachgetragen werden nur die Lücken. Eine Bestellung, die das Tracking selbst gemeldet hat, bekommt kein zweites Event — sonst wäre der Umsatz im Dashboard doppelt so hoch wie in der Kasse. ## Ohne Plugin: über das SDK Für Systeme ohne fertige Anbindung: ```ts import { backfill } from "@trackdolphin/sdk"; const result = await backfill(orders, { shopId: "shop_meinshop_de_ab12cd", transport, // dein Versandweg batchSize: 200, onProgress: (p) => console.log(`${p.done}/${p.total}`), }); ``` E-Mail und Telefonnummer werden lokal gehasht. Mit `dryRun: true` rechnest du alles durch, ohne etwas zu senden — die vorbereiteten Events kommen zur Kontrolle zurück. Im Dashboard läuft derselbe Import geführt ab, siehe [Historie importieren](/docs/app-shop-historie.md). --- # HTTP-API Trackdolphin ist API-first, und zwar wörtlich: Das Dashboard ruft dieselben Endpunkte auf, die auch dir offenstehen. Es gibt keine Fähigkeit, die nur die Oberfläche kann. Daraus folgt der Rest: [MCP-Server](/docs/mcp.md) und [Kommandozeile](/docs/cli.md) leiten ihre Werkzeuge und Befehle aus der OpenAPI-Beschreibung ab. Was die API kann, können sie — ohne dass jemand eine zweite Liste pflegt. ## Beschreibung - **OpenAPI:** `https://api.trackdolphin.com/api/openapi.json` - **Zum Blättern:** `https://api.trackdolphin.com/api/docs` ## Anmeldung Ein API-Schlüssel aus dem Dashboard unter *Einstellungen → API & MCP*: ```bash curl https://api.trackdolphin.com/api/shops \ -H "Authorization: Bearer td_live_…" ``` Der Schlüssel gehört zur Organisation, nicht zu einer Person — ein Automatismus soll nicht stillstehen, weil jemand das Unternehmen verlässt. Gespeichert wird nur der Hash; der Klartext erscheint genau einmal. > **Wichtig:** Ein API-Schlüssel kann keine neuen Schlüssel ausstellen. Sonst > könnte ein Zugang, der nur lesen sollte, sich beliebig viele Nachfolger > anlegen — und ein Widerruf wäre wertlos. ## Die wichtigsten Endpunkte | Zweck | Aufruf | |---|---| | Shops auflisten | `GET /api/shops` | | Läuft das Tracking? | `GET /api/shops/{shopId}/health` | | Kennzahlen | `GET /api/shops/{shopId}/kpis` | | Kanäle | `GET /api/shops/{shopId}/channels?days=30` | | Beste Seiten | `GET /api/shops/{shopId}/pages` | | Kauftrichter | `GET /api/shops/{shopId}/funnel` | | Stand der Einrichtung | `GET /api/shops/{shopId}/onboarding` | | Historienimport starten | `POST /api/shops/{shopId}/import` | | Erkennungsquote | `GET /api/shops/{shopId}/import` | Jeder Shop gehört zu einer Organisation. Ein fremder Shop antwortet mit `403`, nicht mit Daten. ## Events senden Events gehen nicht an die API, sondern an den Collector — einen eigenen Dienst am Rand des Netzes, damit ein Ausfall der Verwaltung keine Events kostet: ```bash curl -X POST https://td.meinshop.de/collect \ -H "Content-Type: application/json" \ -d '{ "event_id": "order_1042", "shop_id": "shop_meinshop_de_ab12cd", "type": "purchase", "value": 119.90, "currency": "EUR", "em": "…sha256 der E-Mail…" }' ``` `em` und `ph` **müssen** bereits gehasht ankommen. Klartext wird mit `400` abgewiesen — siehe [Match-Qualität](/docs/matching.md). Schlüssel erstellst und widerrufst du im Dashboard, siehe [Einstellungen — API & MCP](/docs/app-einstellungen-api-mcp.md). --- # MCP-Server Der MCP-Server macht Trackdolphin für Sprachmodelle bedienbar. Statt ein Dashboard zu öffnen, fragst du: > Läuft das Tracking bei meinshop.de sauber? > Welche Kanäle haben letzten Monat am meisten Umsatz gebracht? > Starte den Historienimport für den neuen Shop. ## Einrichten Einen Schlüssel im Dashboard unter *Einstellungen → API & MCP* erzeugen, dann in die Konfiguration deines Clients eintragen. Für Claude Desktop (`claude_desktop_config.json`): ```json { "mcpServers": { "trackdolphin": { "command": "npx", "args": ["-y", "@trackdolphin/mcp"], "env": { "TRACKDOLPHIN_TOKEN": "td_live_…" } } } } ``` ## Was er kann Der Server pflegt **keine eigene Werkzeugliste**. Er lädt beim Start die [OpenAPI-Beschreibung](/docs/api.md) und macht daraus Werkzeuge. Ein neuer Endpunkt ist damit sofort ein neues Werkzeug — und es gibt keine zweite Liste, die veraltet. Heute sind das unter anderem: - `listShops` — welche Shops gibt es - `getShopTrackingHealth` — offene Störungen, letzter Prüflauf, letztes Event - `getShopKpis`, `getShopChannels`, `getShopTopPages`, `getShopFunnel` - `getShopImportStatus` — Erkennungsquote - `startShopImport` ## Was er nicht kann Die Schlüsselverwaltung. Ein Modell soll keine neuen Zugänge ausstellen können — sonst wäre ein Widerruf wertlos, weil der widerrufene Schlüssel sich längst einen Nachfolger angelegt hat. Schlüssel erstellst und widerrufst du im Dashboard, siehe [Einstellungen — API & MCP](/docs/app-einstellungen-api-mcp.md). --- # Kommandozeile ```bash export TRACKDOLPHIN_TOKEN=td_live_… npx @trackdolphin/cli shops ``` Wie der [MCP-Server](/docs/mcp.md) leitet die Kommandozeile ihre Befehle aus der [OpenAPI-Beschreibung](/docs/api.md) ab. Ein neuer Endpunkt ist sofort ein neuer Befehl. ## Beispiele ```bash trackdolphin shops trackdolphin tracking-health shop_meinshop_de_ab12cd trackdolphin kpis shop_meinshop_de_ab12cd trackdolphin channels shop_meinshop_de_ab12cd --days 30 trackdolphin start-import shop_meinshop_de_ab12cd --since 2026-01-01 ``` Die Shop-Kennung steht direkt hinter dem Befehl — man tippt sie ohnehin zuerst. Lesebefehle verlieren das Verb (`getShopKpis` → `kpis`), Schreibbefehle behalten es (`startShopImport` → `start-import`): Bei einem Schreibvorgang ist das Verb die Warnung. ## Alles anzeigen ```bash trackdolphin help ``` Bei einem Tippfehler schlägt sie das Naheliegende vor: ``` $ trackdolphin kpi shop_x Unbekannter Befehl: kpi Meintest du: kpis? ``` ## In Skripten Die Ausgabe ist JSON — mit `jq` weiterverarbeitbar: ```bash trackdolphin shops | jq -r '.shops[].id' | while read shop; do trackdolphin tracking-health "$shop" | jq -r '"\(.shop.name): \(.status)"' done ``` --- # Events und Routing ## Die Event-Typen **Abschlüsse** — darauf optimieren Kampagnen: `purchase`, `refund`, `lead`, `sign_up`, `schedule`, `contact`, `subscribe` **Kaufweg** — nützlich für Zielgruppen und Katalog-Retargeting: `view_item`, `view_item_list`, `add_to_cart`, `remove_from_cart`, `view_cart`, `begin_checkout`, `add_payment_info` **Allgemein:** `page_view`, `search` **Trichter** — interne Messung, verlässt Trackdolphin nie: `form_viewed`, `form_started`, `field_focused`, `form_validation_error`, `form_submitted`, `success_shown`, `confirmed_double_optin` Sie beantworten „wo brechen Leute ab?“ und hätten in einem Werbekonto nichts zu erklären — sie würden dort nur die Ereignisliste fluten. ## Routing Nicht jedes Event gehört zu jedem Ziel. Die Voreinstellungen sind zurückhaltend, weil die beiden Fehler ungleich schwer wiegen: Ein Event zu wenig sieht man in den Zahlen. Ein Event zu viel verzerrt die Optimierung, ohne sich zu zeigen. | | Google Ads, LinkedIn | Meta | GA4 | |---|---|---|---| | Abschlüsse | an | an | an | | Kaufweg | aus | an | an | | `page_view`, `search` | aus | aus | an | | Trichter | aus | aus | aus | Google Ads und LinkedIn kennen nur Conversion-Actions — ein Zwischenschritt dort erzeugt Conversions, auf die niemand bieten will. GA4 ist ein Analysewerkzeug, dort gehört alles hin. Änderbar im Dashboard unter *Einstellungen → Event-Routing*. Gespeichert werden nur Abweichungen. ## Eigene Events ```js lead("newsletter_bestaetigt", { value: 5 }); ``` Eigene Events gehen **ohne ausdrückliche Freigabe nicht** an Werbeplattformen. Der Name ist freier Text; ein Tippfehler würde sonst lautlos eine Conversion auslösen, auf die eine Kampagne dann optimiert. Im Routing kannst du je Ziel festlegen: freischalten, unter welchem Namen (`newsletter_bestaetigt` → `Lead`), und mit welchem festen Wert. Ein fester Wert greift nur, wenn das Event keinen mitbringt. Ein Lead hat keinen Warenkorbwert, aber du weißt, was dir einer wert ist — ein echter Kaufbetrag wird davon nie überschrieben. ## Umgebungen Teste dein Tracking auf Staging, ohne die Produktionszahlen zu verschmutzen: Gib Events deiner Testinstanz ein `environment` mit — `staging`, `development` oder ein eigener Name (Kleinbuchstaben, Ziffern, `-` und `_`). ```js init({ endpoint: "…", shopId: "…", environment: "staging" }); ``` Ohne Angabe gilt `production`. Staging-Events erscheinen in der Event-Liste (mit Etikett und eigenem Filter), werden aber **nie** an Werbeplattformen gemeldet und tauchen in **keiner** Kennzahl auf — eine Test-Conversion im echten Werbekonto würde die Optimierung verfälschen und wäre nicht rückholbar. Der Wächter und die Erkennungsquote rechnen ebenfalls nur mit production. Im Dashboard änderst du das Routing unter [Einstellungen — Event-Routing](/docs/app-einstellungen-event-routing.md); die empfangenen Events selbst siehst du unter [Events ansehen](/docs/app-shop-events.md). --- # Match-Qualität Eine Conversion nützt nur, wenn die Plattform sie einem Klick zuordnen kann. Dafür vergleicht sie gehashte Kundendaten mit ihren eigenen. Je mehr Merkmale übereinstimmen, desto mehr Conversions kommen im Werbekonto an — bei identischem Umsatz. ## Was mitgeschickt wird Alles als SHA-256, immer: | Feld | Inhalt | |---|---| | `em` | E-Mail | | `ph` | Telefon, E.164 ohne Plus — das Meta-Format | | `ph_e164` | Telefon, E.164 mit Plus — das Format von Google Ads und GA4 | | `fn`, `ln` | Vor- und Nachname | | `ct`, `st`, `zp` | Ort, Bundesland, Postleitzahl | | `country` | Land | | `external_id` | pseudonyme Kundennummer | Dazu die Klick-Kennungen `gclid`, `gbraid`, `wbraid`, `fbc`, `fbp`. ## Die Fallen **Telefonnummern.** Der häufigste stille Fehler — gleich doppelt. Erstens muss `0171 2345678` zu `491712345678` werden; Ziffern zu entfernen genügt nicht. Zweitens sind sich die Plattformen beim Pluszeichen uneinig: Meta verlangt die Nummer ohne, Google Ads und GA4 mit `+`. Zwei Eingaben, zwei Hashes — einer allein bedient nur eine Seite. Das SDK und die Plugins bilden deshalb beide. **Ort und Land.** Kleingeschrieben und ohne Leerzeichen: `Frankfurt am Main` wird zu `frankfurtammain`. **Leere Felder.** Meta wertet ein leeres Feld als Fehlversuch und meldet dafür eine schlechtere Qualität, als tatsächlich vorliegt. Weglassen ist besser als leer schicken — Trackdolphin macht das automatisch. **Server-IP.** Bei einem serverseitigen Event ist der Absender dein Shop-Server. Dessen IP als Nutzersignal weiterzugeben senkt die Qualität, statt sie zu heben. Trackdolphin schickt die IP des Käufers, die am Bestellobjekt steht. ## Ohne Werbe-Einwilligung Ohne Einwilligung gibt es kein `_fbp`-Cookie. Dann ist die First-Party- Besucherkennung von Trackdolphin das einzige stabile Merkmal über mehrere Besuche — sie wird als `external_id` mitgeschickt. Eine echte Kundennummer ist stabiler und geht vor. ## Klartext verlässt den Shop nie Gehasht wird **vor** dem Versand: im Plugin, im SDK, auf deinem Server. Der Collector weist Klartext in `em` oder `ph` mit `400` ab. Das ist keine Höflichkeit gegenüber der DSGVO, sondern die Bedingung dafür, dass in unserer Datenbank nichts steht, was dort nicht stehen darf. Enhanced Conversions je Plattform schaltest du im Dashboard zu, siehe [Einstellungen — Shop & Tracking](/docs/app-einstellungen-shop-tracking.md). --- # Der Wächter Ein Tracking-Ausfall meldet sich nicht. Die Seite lädt, der Shop verkauft, nur die Messung ist tot. Bei einem Kunden lief ein abgelaufener Meta-Zugang **sieben Tage** durch. 114 Abschlüsse fehlten im Werbekonto, während zwei auf Käufe optimierende Anzeigengruppen blind weiterliefen. Niemand merkte etwas — ein fehlendes Event löst nun einmal keinen Alarm aus. ## Was der Wächter prüft Alle sechs Stunden, und zwar das **Ergebnis**, nicht die Konfiguration: - Kommen noch Events an? - Kommen noch Käufe an — auch wenn der Traffic normal aussieht? - Geht bei jedem Ziel noch etwas raus? - Oder lehnt eines ab, weil ein Zugang abgelaufen ist? Eine Konfigurationsprüfung würde den Fall oben verfehlen: Prüf- und Sendeprozess laufen getrennt, ein Token-Check hätte eine Kopie geprüft. ## Warum er selten schreibt Verglichen wird gegen **denselben Wochentag** der Vorwochen, nicht gegen gestern — ein Shop verkauft sonntags anders als dienstags. Als Erwartung dient der Median, nicht der Mittelwert: Ein Black Friday würde den sonst so hochziehen, dass danach jeder normale Tag als Einbruch gilt. Dazu drei Bremsen: - **Anlaufschutz** — ohne genug Vergleichsdaten kein Urteil - **Mindestmenge** — bei fünf Events am Tag ist jede Abweichung Rauschen - **Entprellung** — einmal melden, bei Verschärfung erneut, einmal täglich erinnern, am Ende Entwarnung Das ist Absicht: Ein Wächter, der Fehlalarme schickt, wird nach der dritten Mail weggefiltert — und meldet den nächsten echten Ausfall an ein Postfach, das niemand mehr liest. ## Was in der Mail steht Was passiert ist, wie schlimm, was zu tun ist — mit den echten Zahlen: > An meta ging in den letzten 24 h nichts raus — üblich sind 40 Events. > Die Verbindung sendet still nicht mehr. > > → Öffne die Verbindung im Dashboard und verbinde sie neu — meist ist der > Zugang abgelaufen. ## Einstellen Pro Shop abschaltbar, Mindestmenge anpassbar. Empfänger sind alle Mitglieder der Organisation plus frei eingetragene Adressen — etwa die betreuende Agentur. Abrufbar ist derselbe Stand über `GET /api/shops/{shopId}/health`, im [MCP-Server](/docs/mcp.md) als `getShopTrackingHealth`. --- # Datenschutz > **Hinweis:** Dieser Text beschreibt, wie Trackdolphin technisch arbeitet. > Er ersetzt keine Rechtsberatung. ## Was nie gespeichert wird E-Mail-Adressen und Telefonnummern im Klartext. Gehasht wird vor dem Versand — im Plugin, im SDK, auf deinem Server. Der Collector weist Klartext in `em` oder `ph` mit `400` ab, statt ihn anzunehmen und „SHA-256“ darüberzuschreiben. Namen, Ort und Postleitzahl ebenfalls nur als Hash. Die Kundennummer aus deinem Shop wird pseudonymisiert, nie roh übernommen. ## Was gespeichert wird - Event-Art, Zeitpunkt, Wert, Währung, Positionen - Seiten-URL und Referrer - Klick-Kennungen der Werbeplattformen - IP und User-Agent des Besuchers - der mitgeschickte Einwilligungsstand - eine First-Party-Besucherkennung (Zufallswert, keine Person) ## Einwilligung Trackdolphin steuert dein Consent-Banner nicht und ersetzt es nicht. Das SDK hält Events zurück, bis eine Einwilligung vorliegt, und schickt den Einwilligungsstand bei jedem Event mit — damit später nachweisbar ist, unter welcher Bedingung ein Event entstand. Ob ein serverseitiges Event ohne Einwilligung ausgelöst werden darf, ist eine rechtliche Entscheidung, keine technische. Trackdolphin macht sie dir nicht ab. ## Wo die Daten liegen Verarbeitung und Speicherung in der Europäischen Union. Die Zustellung an Google, Meta und LinkedIn erfolgt an deren Schnittstellen — für diese Übermittlung bist du Verantwortlicher, wir Auftragsverarbeiter. ## Löschung Ein gelöschter Shop nimmt seine Events mit. Auf Anfrage löschen wir einzelne Personen anhand des E-Mail-Hashes — den Hash kannst du selbst bilden, ohne uns die Adresse zu nennen. --- # Die Anwendung im Überblick Dieser Abschnitt zeigt jede Seite der Anwendung mit echten Bildschirmfotos. Die Zahlen in den Bildern (①②③…) verweisen auf die nummerierte Liste direkt darunter — so lässt sich jedes Element eindeutig zuordnen. Die Anwendung gliedert sich in drei Bereiche: ## Dashboard Der Einstieg nach der Anmeldung — alle Shops einer Organisation auf einen Blick. Siehe [Dashboard](/docs/app-dashboard.md). ## Shops Alles, was zu einem einzelnen Shop gehört, in der Unternavigation unter seinem Namen: - [Übersicht](/docs/app-shop-uebersicht.md) — Verbindungen und Zustellstatus - [Einrichtung](/docs/app-shop-einrichtung.md) — der geführte Weg zum ersten Event - [Events](/docs/app-shop-events.md) — jedes empfangene Event einzeln - [Historie](/docs/app-shop-historie.md) — vergangene Bestellungen nachträglich einspielen - [Prüfung](/docs/app-shop-pruefung.md) — automatischer Check, ob das Tracking wirklich feuert - [Umstellung](/docs/app-shop-umstellung.md) — bei Google Ads sauber von alt auf neu wechseln ## Einstellungen Organisationsweite und shopbezogene Konfiguration, in sechs Unterseiten: - [Shop & Tracking](/docs/app-einstellungen-shop-tracking.md) — Domain, Consent, Enhanced Conversions - [Team](/docs/app-einstellungen-team.md) — wer Zugriff hat - [Event-Routing](/docs/app-einstellungen-event-routing.md) — welches Event an welches Ziel geht - [Tag-Manager-Umzug](/docs/app-einstellungen-tag-manager-umzug.md) — bestehenden GTM-Container auslesen - [API & MCP](/docs/app-einstellungen-api-mcp.md) — Schlüssel für Zugriffe ohne Browser - [Tarif & Nutzung](/docs/app-einstellungen-tarif-nutzung.md) — Kontingent und Tarife ## Gut zu wissen Diese Seiten zeigen die Oberfläche, nicht die dahinterliegenden Konzepte. Für „was ist ein Event", „wie funktioniert Match-Qualität" oder „was macht der Wächter" gilt weiterhin der Abschnitt Konzepte — etwa [Events und Routing](/docs/events.md) oder [Match-Qualität](/docs/matching.md). --- # Dashboard Die erste Seite nach der Anmeldung. Sie beantwortet drei Fragen auf einen Blick: Kommen Events an? Wie viele Käufe waren es zuletzt? Und welcher Shop braucht gerade Aufmerksamkeit? Bei einer Organisation mit nur einem Shop ist das Dashboard mit der Shop-Übersicht fast deckungsgleich — bei mehreren Shops ist es die einzige Seite, die alle zusammen zeigt. ![Dashboard mit Kennzahlen, Events-Diagramm und Shop-Tabelle](/docs/screens/dashboard.png) ① **Organisations-/Shop-Auswahl** — oben links. Wer mehreren Organisationen angehört (z. B. eine Agentur mit mehreren Kundenkonten), wechselt hier. Darunter die Liste der Shops dieser Organisation samt „Shop hinzufügen". ② **Shop-Unternavigation** — sobald ein Shop ausgewählt ist, erscheinen hier seine sieben Bereiche: Übersicht, Einrichtung, Events, Historie, Prüfung, Umstellung, Einstellungen. Diese Leiste begleitet dich durch den ganzen Shop-Bereich. ③ **Kennzahlen-Kacheln** — Events der letzten 24 Stunden, Käufe und Umsatz der letzten 7 Tage, Zustellquote der letzten 7 Tage. Die Zustellquote zeigt einen Strich, solange keine Events an Werbeplattformen gemeldet wurden — das ist der Fall, solange keine Plattform verbunden ist oder der Dispatcher noch nichts verarbeitet hat. ④ **Events-pro-Tag-Diagramm** — Balken je Tag, letzte 14 Tage, über alle Shops der Organisation summiert. Zeigt auf einen Blick, ob das Tracking gleichmäßig läuft oder an einem Tag ausgesetzt hat. ⑤ **Beste Seiten / Aktivste Kanäle** — die meistgesehenen Seiten (aus `page_view`- und `view_item`-Events) und die Kanäle, über die Besucher kommen, jeweils der letzten 7 Tage. „Direkt" heißt: keine erkennbare UTM-Herkunft oder Klick-ID. ⑥ **Shops-Tabelle** — bei mehreren Shops die Zeile pro Shop mit denselben Kennzahlen wie oben, plus dem Status der letzten [Prüfung](/docs/app-shop-pruefung.md). Ein Klick auf den Shopnamen springt in dessen Bereich. ## Typische Aufgaben 1. **Prüfen, ob überhaupt Events ankommen** — Kachel ③ „Events · 24 h". Steht dort 0, lohnt ein Blick in die [Einrichtung](/docs/app-shop-einrichtung.md). 2. **Einen bestimmten Shop öffnen** — Name in der Seitenleiste (①) oder in der Tabelle (⑥) anklicken. 3. **Einen weiteren Shop anlegen** — „+ Shop hinzufügen" unter der Shop-Liste in der Seitenleiste. ## Gut zu wissen Die Kennzahlen zählen nur Events mit `environment: production` — Events, die du bewusst als `staging` oder unter einem eigenen Namen sendest, tauchen hier nicht auf. Das ist Absicht: Ein Testlauf soll die echten Zahlen nie verfälschen. Details dazu unter [Events und Routing](/docs/events.md#umgebungen). --- # Shop-Übersicht Die Startseite eines einzelnen Shops (Sidebar: *Shops → Übersicht*). Sie zeigt, welche Werbeplattformen verbunden sind, wie viele Events pro Zustellziel zugestellt, fehlgeschlagen oder übersprungen wurden, sowie die gleichen Kennzahlen wie im [Dashboard](/docs/app-dashboard.md) — nur für diesen einen Shop. > **Hinweis:** Für diese Seite konnte kein Bildschirmfoto aufgenommen werden > — sie wirft in der aktuellen Version einen Serverfehler (500). Der Grund > ist bekannt und liegt im Frontend: Die Verbindungs-Kachel iteriert über > alle acht Verbindungstypen, die das Backend inzwischen kennt (`ga4`, > `google_ads`, `meta`, `linkedin`, `gtm`, `tiktok`, `pinterest`, > `microsoft_ads`), die Anzeige-Namen sind dort aber nur für die ersten vier > hinterlegt. Betrifft jeden Shop, nicht nur diesen. Diese Textbeschreibung > beruht auf dem Quellcode der Seite, nicht auf einem Livebild. Auf der Seite stehen normalerweise: - **Verbindungen** — eine Kachel je Werbeplattform (Google Ads, Meta, GA4, LinkedIn und, sobald das Frontend nachgezogen ist, auch TikTok, Pinterest, Microsoft Ads sowie der Google Tag Manager) mit Status „verbunden", „abgelaufen" oder „noch nicht verbunden" und einem Verbinden-Knopf. - **Zustellungen je Ziel** — Tabelle mit zugestellten, fehlgeschlagenen und übersprungenen Events je Plattform, verlinkt in die gefilterte [Event-Liste](/docs/app-shop-events.md). - **Beste Seiten / Aktivste Kanäle** — dieselbe Auswertung wie im Dashboard, hier auf diesen Shop beschränkt. ## Weiteren Shop anlegen Über „+ Shop hinzufügen" in der Seitenleiste (erreichbar von jeder Seite aus) legst du einen zusätzlichen Shop in derselben Organisation an — mit eigenen Verbindungen und eigenen Einstellungen. ![Formular „Shop hinzufügen“ mit Domain und Shopsystem](/docs/screens/shops-neu.png) ① **Formular** — Domain, auf der das Shop-Plugin läuft, und das Shopsystem (WooCommerce, Shopware, Shopify oder eigene Anbindung). Nach dem Anlegen landest du in der [Einrichtung](/docs/app-shop-einrichtung.md) des neuen Shops. ## Gut zu wissen Wie viele Shops eine Organisation anlegen darf, richtet sich nach dem Tarif — siehe [Tarif & Nutzung](/docs/app-einstellungen-tarif-nutzung.md). --- # Shop einrichten Diese Seite (Sidebar: *Shops → Einrichtung*) begleitet dich vom leeren Shop bis zum ersten empfangenen Event. Sie ist der Startpunkt für jeden neu angelegten Shop und bleibt danach als Referenz erreichbar — etwa um die Shop-ID oder den Collector-Endpoint erneut nachzuschlagen. ![Einrichtungsseite mit Fortschritts-Stepper, Werten fürs Plugin und Accounts verbinden](/docs/screens/shops-einrichtung.png) ① **Fortschritts-Stepper** — „Dein Weg zum vollständigen Tracking" in sechs Schritten: Plugin einrichten, Historie importieren (optional), Werbeplattformen verbinden, Tracking prüfen, eigene Tracking-Domain (optional), auf Trackdolphin umstellen (optional). Erledigte Schritte sind grün abgehakt, der aktuelle ist hervorgehoben. ② **Shop-System erkennen** — lässt Trackdolphin automatisch erraten, welches Shopsystem läuft (an der aufgerufenen Domain), um die passende Anleitung weiter unten einzublenden. Ohne Erkennung bleibt die generische HTTP-Anleitung sichtbar. ③ **Diese Werte braucht das Plugin** — Collector-Endpoint und Shop-ID, beide mit Kopieren-Knopf. Das sind die zwei Werte, die jedes Plugin oder jede eigene Anbindung braucht. ④ **Plugin einrichten** — Kurzanleitung fürs Versenden per HTTP-POST, dazu ein fertiger `curl`-Befehl für ein Test-Event. Der Link „Eigene Anbindung" führt zum [SDK](/docs/sdk.md) für alles, wofür es kein fertiges Plugin gibt. ⑤ **Erstes Event** — bestätigt in Echtzeit, sobald der Collector ein Event für diesen Shop empfangen hat, mit Zeitstempel und Typ des letzten Events. Vor dem ersten Event steht hier ein Warte-Hinweis statt der Bestätigung. ⑥ **Accounts verbinden** — Google Ads, Meta, Google Analytics 4 und LinkedIn per OAuth verbinden. Jede Verbindung lässt sich jederzeit wieder trennen; „Später verbinden" überspringt den Schritt — das Tracking läuft auch ohne, es meldet nur noch nichts an Werbeplattformen weiter. ## Typische Aufgaben 1. **Shop-ID oder Endpoint nachschlagen** — Block ③, jeweils mit Kopieren-Knopf. 2. **Prüfen, ob das Plugin sendet** — Block ⑤ neu laden oder die Seite aktualisieren; „Events kommen an!" erscheint automatisch. 3. **Eine Werbeplattform nachträglich verbinden** — Block ⑥, jederzeit wiederholbar. Dieselbe Liste findest du auch auf der [Shop-Übersicht](/docs/app-shop-uebersicht.md). ## Gut zu wissen Die Schritte „Historie importieren", „Eigene Tracking-Domain" und „Auf Trackdolphin umstellen" sind als optional markiert — sie verbessern Datenqualität beziehungsweise Signalqualität, sind aber für ein funktionierendes Tracking nicht zwingend. Siehe [Historie und Erkennungsquote](/docs/backfill.md) für den Import und [Umstellung](/docs/app-shop-umstellung.md) für den Wechsel bei Google Ads. --- # Events ansehen Die Event-Liste (Sidebar: *Shops → Events*) zeigt jedes einzelne Event, das für diesen Shop empfangen wurde — neueste zuerst, maximal 50 auf einmal. Sie ist die erste Anlaufstelle, wenn eine Zahl im Dashboard nicht plausibel wirkt: Hier lässt sich nachvollziehen, welches Event wann ankam und was danach mit ihm passiert ist. ![Event-Liste mit Filterleiste, Tabellenkopf und einer Beispielzeile](/docs/screens/shops-events.png) ① **Filterleiste** — Status (alle, zugestellt, fehlgeschlagen, übersprungen, noch offen), Typ (Kauf, Produkt gesehen, In den Warenkorb, …) und Plattform (GA4, Google Ads, Meta, LinkedIn). Die Filter lassen sich kombinieren. ② **Tabellenkopf** — Empfangen (Zeitstempel), Typ, Kanal, Wert, Zustellungen, Event-ID. ③ **Beispielzeile** — ein einzelnes Event in der Liste. Der Typ-Link (hier „Kauf") führt zur Detailseite dieses Events. ④ **Zustellstatus** — „— offen" heißt: Noch keine Zustellung an eine Plattform protokolliert. Nach einer Zustellung stehen hier grüne Häkchen je Ziel, bei einem Fehlschlag ein rotes Kreuz mit Fehlergrund. ⑤ **Event-ID** — die vom Shop oder SDK vergebene Kennung, meist aus der Bestellnummer abgeleitet (z. B. `order_1042`). Klick führt zur Detailseite. Das Kanal-Symbol unterscheidet „⚙ Server" (Plugin-Hook, z. B. eine Bestellung) von „◫ Browser" (Storefront-Snippet, z. B. ein Seitenaufruf). ## Event-Detailseite Ein Klick auf Typ oder Event-ID öffnet die Detailseite mit allem, was zu diesem einen Event gespeichert ist. ![Event-Detailseite mit Metadaten, Zustellungen, Positionen und Roh-Payload](/docs/screens/shops-events-detail.png) ① **Event** — Typ, Zeitpunkt des Auftretens (`occurred_at`, vom Shop gemeldet) und des Empfangs, Kanal, ob Standard- oder First-Party-Domain, Wert, sowie URL, Referrer, IP und User-Agent, sofern vom Ereignis mitgeliefert. ② **Zustellungen und Match-Signale** — je Zielplattform Status und Zeitpunkt der Zustellung, darunter die gehashten Signale (`em`, `ph`, …), die für den Abgleich mit Werbeplattformen genutzt wurden. Siehe [Match-Qualität](/docs/matching.md). ③ **Positionen** — die im Event enthaltenen Produkte (bei Kauf- und Warenkorb-Events), im Rohformat. ④ **Roh-Payload** — genau das JSON, das der Shop oder das SDK gesendet hat. Nützlich zum Debuggen einer eigenen Anbindung — siehe [SDK für eigene Anbindungen](/docs/sdk.md) und [HTTP-API](/docs/api.md). ## Typische Aufgaben 1. **Nachsehen, ob eine bestimmte Bestellung gemeldet wurde** — Typ „Kauf" filtern, in der Event-ID nach der Bestellnummer suchen (Browser-Suche reicht bei bis zu 50 Zeilen). 2. **Prüfen, warum eine Zustellung fehlschlug** — Status „fehlgeschlagen" filtern, Event öffnen, Zustellungen-Block ansehen. 3. **Ein Test-Event beim Debuggen wiederfinden** — nach Event-Typ oder Plattform filtern; Staging-Events tragen ein eigenes Etikett und laufen nie an Werbeplattformen weiter, siehe [Events und Routing](/docs/events.md#umgebungen). ## Gut zu wissen Die Liste zeigt maximal 50 Events und keine Paginierung darüber hinaus — für Auswertungen über größere Zeiträume oder viele Events ist die [HTTP-API](/docs/api.md) der bessere Weg. --- # Historie importieren Trackdolphin misst ab dem Tag der Einrichtung. Diese Seite (Sidebar: *Shops → Historie*) holt die Bestellungen der Vergangenheit nach — und zeigt dabei in Zahlen, wie viele Bestellungen das bisherige Tracking übersehen hat. Ausführlicher erklärt unter [Historie und Erkennungsquote](/docs/backfill.md). ![Historie-Seite mit Anleitung, Formular für Zugangsdaten und Schritt 2](/docs/screens/shops-historie.png) ① **Anleitung** — Schritt-für-Schritt-Beschreibung, wo sich Lese-Zugangsdaten im jeweiligen Shopsystem finden (hier WooCommerce → Einstellungen → Erweitert → REST-API), mit eingebettetem Beispielbild. ② **Formularfelder** — Shop-System (WooCommerce oder Shopware 6), Adresse des Shops, sowie Consumer Key und Consumer Secret. Der Button „Verbindung prüfen und speichern" testet die Zugangsdaten, bevor irgendetwas importiert wird. ③ **Schritt 2 — Bestellungen holen** — erst nach erfolgreicher Verbindung aktiv. Hier startest du den eigentlichen Import und siehst anschließend das Ergebnis: wie viele Bestellungen gefunden wurden und wie viele davon bereits im bisherigen Tracking ankamen. ## Typische Aufgaben 1. **Zugangsdaten anlegen** — im Shopsystem einen API-Schlüssel mit Leserechten erzeugen (Schreibrechte sind nie nötig) und hier eintragen. 2. **Import starten** — nach erfolgreicher Verbindung in Schritt 2. 3. **Erkennungsquote nachlesen** — nach dem Import, siehe [Historie und Erkennungsquote](/docs/backfill.md) für die Deutung der Zahlen. ## Gut zu wissen Trackdolphin verlangt für den Import ausdrücklich nur Leserechte — es schreibt nichts in den Shop zurück. Importierte Bestellungen zählen nie gegen das monatliche Event-Kontingent, siehe [Tarif & Nutzung](/docs/app-einstellungen-tarif-nutzung.md). --- # Tracking prüfen Diese Seite (Sidebar: *Shops → Prüfung*) ruft die eigenen Seiten auf und prüft, ob das Trackdolphin-Tracking tatsächlich feuert — und dokumentiert nebenbei, was sonst noch an Consent-Bannern und weiteren Trackern läuft. ![Prüfung-Seite im leeren Ausgangszustand vor dem ersten Lauf](/docs/screens/shops-pruefung.png) ① **Status** — „noch nicht geprüft", solange kein Lauf gestartet wurde. Nach einer Prüfung stehen hier Ergebnis und Zeitpunkt des letzten Laufs. ② **„Jetzt prüfen"** — startet den Check. Trackdolphin ruft die hinterlegte Shop-Domain aus der Ferne auf und wertet aus, ob und wie das eigene Tracking-Skript anspringt. > Für dieses Bildschirmfoto wurde bewusst kein Lauf gestartet: Der > Testshop trägt die Domain `test.de`, an die ich keine echte Anfrage > schicken wollte. Der leere Ausgangszustand ist der Zustand, den jeder neue > Shop zuerst sieht. ## Typische Aufgaben 1. **Erste Prüfung nach der Einrichtung** — Button „Jetzt prüfen", sobald das [Plugin eingerichtet](/docs/app-shop-einrichtung.md) ist. 2. **Erneut prüfen nach einer Änderung** — etwa nachdem ein Consent-Banner oder Tag-Manager-Container angepasst wurde. ## Gut zu wissen Die Prüfung ersetzt keine rechtliche Bewertung des eigenen Trackings — sie zeigt technisch, was auf der Seite ausgeführt wird. Die Umstellung bei Google Ads auf Grundlage einer sauberen Prüfung ist gesondert beschrieben unter [Umstellung](/docs/app-shop-umstellung.md). --- # Umstellung bei Google Ads Diese Seite (Sidebar: *Shops → Umstellung*) gibt es nur für Google Ads — laut Anwendung die einzige Plattform, bei der sich sauber in zwei Stufen umschalten lässt, statt das bisherige Tracking abrupt zu ersetzen. ![Umstellungsseite mit den zwei Stufen, automatischer Umstellung und Konto-Status](/docs/screens/shops-umstellung.png) ① **Mitlaufen → Umstellen** — die zwei Stufen im Überblick. In Stufe 1 läuft die serverseitige Conversion-Action von Trackdolphin sekundär mit: Sie zählt noch nicht und beeinflusst kein Bidding. Der Button „Conversion-Action anlegen" legt genau das an, ohne an den aktuellen Zahlen etwas zu ändern. In Stufe 2 wird sie primär, die bisherigen Actions rutschen im selben Schritt auf sekundär — kein Doppelzählen, keine Lücke. ② **Automatische Umstellung** — sobald die [Prüfung](/docs/app-shop-pruefung.md) saubere Zustellung meldet, stellt Trackdolphin selbst um. Wer den Zeitpunkt lieber selbst bestimmt, schaltet das hier aus. ③ **Conversion-Actions im Konto** — Liste der Conversion-Actions aus dem verbundenen Google-Ads-Konto mit ihrem jeweiligen Status (primär/sekundär). Ohne verbundenes Konto steht hier nur der Hinweis, dass Google Ads für diesen Shop nicht verbunden ist. ## Typische Aufgaben 1. **Google Ads verbinden** — falls noch nicht geschehen, über die [Einrichtung](/docs/app-shop-einrichtung.md) oder die [Shop-Übersicht](/docs/app-shop-uebersicht.md). 2. **Mitlaufen lassen** — „Conversion-Action anlegen" in Block ①. 3. **Zeitpunkt der Umstellung selbst bestimmen** — „Automatisch umstellen" in Block ② ausschalten und die Actions im Google-Ads-Konto manuell umschalten. ## Gut zu wissen Für andere Plattformen (Meta, GA4, LinkedIn) gibt es keine vergleichbare Umstellungsseite — sie kennen dieses Konzept einer primären/sekundären Conversion-Action nicht in derselben Form. --- # Einstellungen — Shop & Tracking Die Standardseite unter *Einstellungen* (Sidebar: *Einstellungen → Shop & Tracking*). Hier liegen die Stellschrauben, die Signalqualität und Datenschutz betreffen: wie Events technisch beim Empfänger ankommen, wie Einwilligungen behandelt werden, und mit welchen zusätzlichen Kundendaten Conversions angereichert werden. ![Einstellungen: Tracking-Qualität, Consent & Datenschutz, Enhanced Conversions, Gefahrenzone](/docs/screens/einstellungen-shop-tracking.png) ① **Einstellungen-Unternavigation** — die sechs Unterseiten dieses Bereichs: Shop & Tracking, Team, Event-Routing, Tag-Manager-Umzug, API & MCP, Tarif & Nutzung. ② **Tracking-Qualität** — Standard läuft über die neutrale Domain von Trackdolphin (funktioniert sofort). Optional lässt sich First-Party einrichten: eine Subdomain der eigenen Domain zeigt per CNAME auf Trackdolphin, was Browser und Werbeblocker wie einen Teil der eigenen Seite behandeln. Darunter die Shop-Domain, die für CNAME und Verifizierung verwendet wird. ③ **Consent & Datenschutz** — Consent Mode v2 ein-/ausschalten, die CMP-Integration wählen (liest die Consent-Signale eines Cookie-Banners aus — Borlabs Cookie, Cookiebot, Usercentrics, consentmanager), sowie die Option „Alle Nutzer tracken (Nicht-EU)" für Shops außerhalb der EU-Datenschutzregulierung. ④ **Enhanced Conversions** — je Zielplattform (GA4, Google Ads, Meta, LinkedIn) einzeln zuschaltbar. Erhöht die Genauigkeit der Conversion-Messung durch zusätzliche, lokal gehashte Kundendaten. Siehe [Match-Qualität](/docs/matching.md). ⑤ **Gefahrenzone** — löscht den Shop endgültig, inklusive aller Events, Verbindungen, Prüfungen und Einstellungen. Nur Inhaber der Organisation können das, und nur nach Eingabe des Shop-Namens zur Bestätigung. ## Typische Aufgaben 1. **First-Party-Tracking einrichten** — Block ②, „First-Party einrichten". Trackdolphin erkennt den DNS-Anbieter automatisch und führt durch die nötigen Schritte. 2. **Consent-Banner anbinden** — Block ③, passendes CMP in der Combobox wählen. 3. **Enhanced Conversions für eine Plattform aktivieren** — Block ④, den jeweiligen Schalter umlegen, dann „Einstellungen speichern". ## Gut zu wissen Die Verantwortung für „Alle Nutzer tracken (Nicht-EU)" liegt ausdrücklich beim Betreiber des Shops — die Anwendung trifft hier keine rechtliche Einschätzung, sie bietet nur den Schalter an. --- # Einstellungen — Team Sidebar: *Einstellungen → Team*. Verwaltet, wer Zugriff auf die gesamte Organisation hat — nicht nur auf einen einzelnen Shop. Einladen dürfen nur Inhaber. ![Team-Einstellungen mit Einladen-Formular, Mitgliederliste und offenen Einladungen](/docs/screens/einstellungen-team.png) ① **Einladen** — E-Mail-Adresse und Rolle (Mitglied oder Inhaber), dann „Einladung senden". Der Link in der Einladungsmail gilt sieben Tage und funktioniert einmal. ② **Mitglieder** — Tabelle mit Name, E-Mail, Rolle, Datum des Beitritts und letzter Anmeldung. ③ **Offene Einladungen** — Einladungen, die verschickt, aber noch nicht angenommen wurden. Ohne offene Einladungen steht hier ein entsprechender Hinweis. ## Typische Aufgaben 1. **Kollegin oder Kollegen einladen** — Block ①, E-Mail eintragen, Rolle wählen, senden. 2. **Rolle prüfen** — Block ②, Spalte „Rolle". Nur Inhaber sehen und nutzen diese Seite überhaupt vollständig. ## Gut zu wissen Die Rolle gilt für die ganze Organisation, nicht pro Shop — es gibt aktuell keine feingranulare Rechtevergabe je Shop. --- # Einstellungen — Event-Routing Sidebar: *Einstellungen → Event-Routing*. Legt fest, welche Event-Typen an welche verbundene Plattform gehen. Die Grundlagen dazu — welche Event-Typen es gibt, warum die Voreinstellungen zurückhaltend sind, und wie eigene Events funktionieren — stehen unter [Events und Routing](/docs/events.md). ![Hinweis: noch kein Ziel verbunden](/docs/screens/einstellungen-event-routing.png) ① **Hinweis „Noch kein Ziel verbunden"** — solange keine Werbeplattform (Meta, Google Ads, Google Analytics, LinkedIn) verbunden ist, zeigt diese Seite nur diesen Hinweis mit einem Link zu den Verbindungen. Erst nach mindestens einer Verbindung erscheint hier die eigentliche Routing-Matrix: je Zielplattform und Event-Typ ein Schalter, plus die Möglichkeit, eigene Event-Namen unter einem festen Namen und Wert freizuschalten. ## Typische Aufgaben 1. **Erst eine Plattform verbinden** — über die [Einrichtung](/docs/app-shop-einrichtung.md) oder die [Shop-Übersicht](/docs/app-shop-uebersicht.md), dann hierher zurückkehren. 2. **Ein eigenes Event freischalten** — nach dem Verbinden, siehe [Events und Routing → Eigene Events](/docs/events.md#eigene-events) für die Erklärung, warum das nicht automatisch geschieht. ## Gut zu wissen Die Voreinstellungen unterscheiden bewusst zwischen Abschlüssen, Kaufweg und allgemeinen Events — Details und die Tabelle der Voreinstellungen stehen in [Events und Routing](/docs/events.md#routing). --- # Einstellungen — Tag-Manager-Umzug Sidebar: *Einstellungen → Tag-Manager-Umzug*. Für Shops, die bereits über den Google Tag Manager tracken: Diese Seite liest den bestehenden Container und zeigt, was Trackdolphin davon serverseitig ersetzen kann — und was im Container stehen bleiben muss. ![Hinweis „Erst verbinden“ mit Erklärung und Verbinden-Button](/docs/screens/einstellungen-tag-manager-umzug.png) ① **Erklärung mit Verbinden-Button** — solange kein Container verbunden ist, steht hier: Trackdolphin liest nur, ändert am Container nichts; danach gibt es eine Liste aller Tags, gruppiert nach dem, was daraus wird; gefundene Kennungen (Measurement-ID, Conversion-Label, Pixel-ID) werden zum Übernehmen angezeigt — eingetragen werden sie nicht automatisch, das bleibt eine bewusste Entscheidung. „Google Tag Manager verbinden" startet die Leseverbindung; sie lässt sich jederzeit trennen. ## Typische Aufgaben 1. **Bestehenden Container prüfen, bevor man umstellt** — „Google Tag Manager verbinden" klicken und den Befund abwarten. 2. **Gefundene Kennungen übernehmen** — nach der Analyse manuell in die passenden Felder eintragen (z. B. unter [Shop & Tracking](/docs/app-einstellungen-shop-tracking.md) für Enhanced Conversions). ## Gut zu wissen Der Lesezugriff ändert nichts am bestehenden Container — bestehendes Tracking läuft unverändert weiter, bis der Container manuell angepasst wird. --- # Einstellungen — API & MCP Sidebar: *Einstellungen → API & MCP*. Erzeugt und verwaltet API-Schlüssel für Zugriffe ohne Browser: den [MCP-Server](/docs/mcp.md), die [Kommandozeile](/docs/cli.md) und eigene Skripte gegen die [HTTP-API](/docs/api.md). Ein Schlüssel gilt für die ganze Organisation und läuft nicht ab. ![API-Schlüssel-Seite: neu erstellter Schlüssel (unkenntlich gemacht), Formular, Tabelle](/docs/screens/einstellungen-api-mcp.png) ① **Neu erstellter Schlüssel** — direkt nach dem Erstellen wird der Klartext genau einmal angezeigt, mit dem Hinweis, ihn jetzt zu sichern — auch Trackdolphin selbst kann ihn danach nicht mehr anzeigen. Im Bildschirmfoto ist der Schlüssel aus Sicherheitsgründen unkenntlich gemacht. ② **Neuen Schlüssel erstellen** — ein Freitextfeld „Wofür?" (z. B. „MCP-Server"), die Umgebung (Produktiv oder Test), dann „Erstellen". ③ **Gültige Schlüssel** — Tabelle aller aktiven Schlüssel mit Name, den letzten sichtbaren Zeichen des Schlüssels, Umgebung, Erstellungsdatum, letzter Nutzung und einem „Widerrufen"-Knopf je Zeile. ## Typische Aufgaben 1. **Schlüssel für den MCP-Server erzeugen** — Block ②, Zweck eintragen, erstellen, Schlüssel sofort sichern (Block ①). 2. **Zugang entziehen** — Block ③, „Widerrufen" in der betreffenden Zeile. Sofort und endgültig. ## Gut zu wissen Ein API-Schlüssel kann keine neuen Schlüssel ausstellen — sonst könnte ein Zugang, der nur lesen sollte, sich beliebig viele Nachfolger anlegen, und ein Widerruf wäre wertlos. Details zur Anmeldung und den wichtigsten Endpunkten stehen unter [HTTP-API](/docs/api.md). --- # Einstellungen — Tarif & Nutzung Sidebar: *Einstellungen → Tarif & Nutzung*. Zeigt den aktuellen Tarif, die Nutzung im laufenden Monat und die verfügbaren Tarife zum Vergleich. Gezählt wird beim Empfang eines Events, nicht je Plattform, an die es anschließend geht. ![Tarif-Seite mit Kontingentanzeige und Tarifvergleich](/docs/screens/einstellungen-tarif-nutzung.png) ① **Aktueller Tarif und Kontingentnutzung** — Name des Tarifs mit Ampel-Status („im Rahmen" o. ä.), darunter zwei Balken: Events im laufenden Monat gegen das Monatslimit, und genutzte gegen erlaubte Shops. ② **Tarifübersicht** — die verfügbaren Tarife nebeneinander (im Bildschirmfoto: Kostenlos, Shop, Agentur) mit Preis, den wichtigsten Merkmalen und einem Upgrade-Knopf. Der eigene Tarif ist als solcher markiert statt eines Knopfs. ## Typische Aufgaben 1. **Nachsehen, wie viel Kontingent noch übrig ist** — Block ①. 2. **Tarif wechseln** — Block ②, „Upgrade auf …" beim gewünschten Tarif. ## Gut zu wissen Historienimport und Stornos zählen laut Anwendung nie gegen das Kontingent. Bei Überschreitung wird laut Anwendung nichts abgeschaltet — stattdessen meldet sich Trackdolphin.