TrackAny.Click — Dokumentation

Getting Started

1. Erstelle und bestätige genau einen Cloud-Account. 2. Wähle oder erstelle die Organisation, der die Integration gehört. 3. Lege ein Projekt für die Website, den Shop oder die Marke an, deren Daten zusammenbleiben sollen. 4. Öffne den Produkt-Workspace und prüfe die Freischaltung, bevor du Zugangsdaten kopierst oder Produktionsverkehr sendest.

Damit ist die Account-Einrichtung abgeschlossen. Alle folgenden Abschnitte sind Implementierungsanleitungen. Zugangsdaten sind immer projektgebunden; Server-Secrets gehören niemals in Browsercode, öffentliche Repositories oder clientseitige Umgebungsvariablen.

Vor der Integration

Die TrackAny.Click-Erfassung wird je Kundenprojekt aktiviert. Sende erst Produktivdaten, wenn der Projekt-Workspace einen öffentlichen Key, das Installationssnippet und eine aktive Collector-URL anzeigt. Vorbereitete URLs oder ein Script aus einem anderen Projekt aktivieren keine Erfassung.

Öffentlicher und geheimer Projektschlüssel

Der öffentliche pub_tac_-Key gehört in den Browser und ist auf die aktiven Domains des Projekts begrenzt. Der sec_tac_-Key wird bei der Projekterstellung einmal angezeigt, gehört ausschließlich in einen serverseitigen Secret Manager und authentifiziert Server-Events sowie Identify-Aufrufe.

Wurde der Secret-Key nicht gespeichert, darfst du weder den Public Key als Ersatz nutzen noch einen Server-Key im Browser veröffentlichen. Fordere vor der Serverintegration einen kontrollierten Ersatz an; eine Self-Service-Rotation des Secret-Keys ist derzeit nicht verfügbar.

Browser-Tracker installieren

Kopiere das projektspezifische Snippet unter TrackAny.Click → Installation. Es lädt https://trackany.click/v1/t.js, sendet an https://connect.trackany.click und startet mit verweigertem Consent. data-spa=true ergänzt initiale und History-API-Pageviews; bei klassischen Seitenaufrufen kannst du es weglassen oder pageview selbst senden.

<script>
  window.trackany = window.trackany || function () {
    (window.trackany.q = window.trackany.q || []).push(arguments);
  };
</script>
<script async
  src="https://trackany.click/v1/t.js"
  data-project="PUBLIC_PROJECT_KEY"
  data-consent="denied"
  data-spa="true">
</script>

Consent korrekt anbinden

Vor Consent erzeugt der Tracker keine Kennungen, greift nicht auf persistenten Speicher zu und sendet keine Events. Rufe consent=granted erst auf, nachdem der Consent Manager der Website Analytics freigegeben hat. Rufe bei Widerruf consent=denied auf; das löscht den lokalen TrackAny.Click-Zustand und stoppt neue Events, ist aber kein serverseitiger Löschantrag.

Vermeide personenbezogene Daten in URLs, UTM-Werten und eigenen Properties. Querystrings und Fragmente werden aus Seiten-URLs entfernt, Referrer reduziert und das SDK verwendet kein Fingerprinting.

Pageviews, Leads und Conversions erfassen

Nutze kleingeschriebene snake_case-Eventnamen. Markiere echte Ziele mit conversion=true und übergib Wert und dreistelligen Währungscode immer gemeinsam. Browser-Aufrufe tragen den consentgebundenen Besucher-, Session- und Attributionskontext automatisch.

Nutze ein Event für genau einen Geschäftsvorgang. Melde denselben Kauf nicht im Browser und erneut auf dem Server, wenn beide Events nicht bewusst unterschiedliche Fakten darstellen.

window.trackany("consent", "granted");
window.trackany("pageview");
window.trackany(
  "event",
  "qualified_lead",
  { form: "demo_request" },
  { conversion: true }
);

Vertrauenswürdiges Server-Event senden

Sende JSON per POST an /v1/events und nutze den Secret-Key als Bearer-Token. Server-Events können contactId oder externalId enthalten und werden getrennt von Browser-Events ausgewiesen. Halte eventId beim Retry stabil: identischer Inhalt wird dedupliziert, geänderter Inhalt unter derselben ID erzeugt HTTP 409 event_id_conflict.

curl --request POST "https://connect.trackany.click/v1/events" \
  --header "Authorization: Bearer $TRACKANY_SECRET_KEY" \
  --header "Content-Type: application/json" \
  --data '{
  "eventId": "evt_01JZ8J2K9M7P4Q6R8S1T3V5W7X",
  "event": "purchase",
  "timestamp": "2026-09-08T17:00:00Z",
  "contactId": "crm_123",
  "value": 49.9,
  "currency": "USD",
  "conversion": true,
  "properties": {
    "plan": "pro"
  }
}'

Besucher mit dem eigenen System verbinden

Lies nach Formularsendung oder Login die consentgebundene visitorId über window.trackany.getContext() und sende sie vom Backend an POST /v1/identify zusammen mit contactId, externalId oder beiden. Der Endpunkt verlangt den Secret-Key; öffentliche Browser-Keys werden abgewiesen.

curl --request POST "https://connect.trackany.click/v1/identify" \
  --header "Authorization: Bearer $TRACKANY_SECRET_KEY" \
  --header "Content-Type: application/json" \
  --data '{
  "visitorId": "vis_01JZ8J2K9M7P4Q6R8S1T3V5W7X",
  "contactId": "crm_123"
}'

Eventmodell festlegen

Definiere vor der Implementierung ein kleines Vokabular, etwa page_view → form_submitted → qualified_lead → purchase. Halte Akquisitionsaktivitäten und spätere Kundenergebnisse als getrennte Events, damit Berichte die beobachtete Reihenfolge und Vertrauensquelle zeigen.

Kampagnenattribution erhalten

Nutze konsistente utm_source, utm_medium und utm_campaign sowie stabile Provider-IDs wie utm_id, utm_adgroup_id und utm_ad_id. TrackAny.Click hält First Touch, aktuellen Session Touch und Last Non-Direct Touch getrennt; Kampagnennamen allein sind keine zuverlässigen Join-Schlüssel.

Batching und Ergebnisse

Sende 1–100 Events an /v1/events/batch, wenn ein Serverprozess mehrere unabhängige Fakten besitzt. Der Dienst validiert zunächst den vollständigen Batch und kann HTTP 207 mit Ergebnissen je Event liefern, wenn nur ein Teil geschrieben wurde. Bewahre Event-ID und Payload für sichere Retries auf.

Journeys lesen und Fehler behandeln

HTTP 202 bedeutet, dass das Event angenommen wurde. Behandle 400 als Vertrags- oder Zeitfehler, 401 als ungültigen Projektschlüssel, 402 als fehlendes Kontingent oder Guthaben, 403 als Origin-Sperre, 409 als geänderte Wiederverwendung einer Event-ID und 429 als Rate Limit. Wiederhole vorübergehende Fehler mit unveränderter Event-ID und Payload.

Journey- und Funnel-Berichte sind begrenzte Ansichten, kein Identity Graph. Sie zeigen Abdeckung und Kürzungen, halten Währungen und Vertrauensquellen getrennt und behaupten keine geräteübergreifende Gewissheit.