CommunityRecherche & Datenanalysegithub.com

Analytics-Tracking-Automation (DE)

KI-gestützte GA4 + GTM Event-Tracking-Automation – automatisiert Site-Analyse, Event-Schema, GTM-Sync, Vorschau-Verifikation und Veröffentlichung. Funktioniert mit Cursor, Codex und jedem KI-Agenten.

Was ist Analytics-Tracking-Automation (DE)?

Dieses Skill-Paket bietet eine durchgängige, automatisierte Lösung für die Implementierung von GA4- und GTM-Event-Tracking. Es deckt den gesamten Workflow von der initialen Site-Analyse und Erkennung über die Schema-Erstellung, die Synchronisation mit dem Google Tag Manager (GTM) bis hin zur Vorschau-Prüfung und Veröffentlichung ab. Der Skill ist speziell für den Einsatz mit KI-Agenten wie Claude Code, Cursor oder Codex konzipiert und nutzt ein modulares System aus einem Haupt-Skill und sieben Phasen-Skills. Durch die integrierte Logik zur Intent-Erkennung und Fortsetzung bestehender Läufe wird sichergestellt, dass immer die richtige Phase gestartet oder nahtlos fortgesetzt wird. Wichtig ist, dass der Skill an entscheidenden Checkpoints (z.B. Schema-Bestätigung, GTM-Zielauswahl) immer die explizite Zustimmung des Benutzers einholt, bevor er fortfährt. Der Skill unterstützt auch plattformspezifische Workflows, wie z.B. für Shopify, und verfügt über ein automatisches Update-System, das stets die neueste Version aus GitHub lädt.

Funktioniert mit✓Claude Code✓Codex CLI✓Cursor
npx skills add jtrackingai/analytics-tracking-automation

Installed? Explore more Recherche & Datenanalyse skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Analytics-Tracking-Automation

Nutze diesen Skill als End-to-End-Koordinator für die GA4- und GTM-Tracking-Bereitstellung.

Verwende ihn, wenn:

  • der Benutzer einen vollständigen GA4- + GTM-Implementierungsablauf von der Analyse bis zur Go-Live-Bereitschaft benötigt
  • die Anfrage mehrere Workflow-Phasen umfasst (Discovery, Schema, Sync, Verifikation, Publish)
  • der richtige Einstiegspunkt noch unklar ist und du diesen Skill benötigst, um zur richtigen Phase zu leiten

Nimm nicht an, dass der Benutzer den vollständigen Workflow wünscht.

Auto-Update

Dieser installierte Root-Skill kann vor dem Fortfahren nach neueren GitHub-Versionen suchen.

Bevor du eine Aufgabe in diesem Paket erledigst:

  1. Ermittle das Verzeichnis, das diese installierte SKILL.md enthält. Von Installern verwaltete Kopien befinden sich normalerweise im Skills-Verzeichnis, das von deiner Agentenumgebung konfiguriert wird, z. B. $CODEX_HOME/skills/analytics-tracking-automation oder ein äquivalenter, von der Runtime verwalteter Pfad.
  2. Führe aus: node "<bundle-dir>/runtime/skill-runtime/update-check.mjs" --json.
  3. Wenn der Status des Ergebnisses update_available ist, führe sofort aus: node "<bundle-dir>/runtime/skill-runtime/self-update.mjs" --apply.
  4. Wenn das Update erfolgreich ist, lies die <bundle-dir>/SKILL.md erneut, bevor du fortfährst, damit du die aktualisierten Anweisungen verwendest.
  5. Wenn der Status des Ergebnisses disabled ist, behandle dieses Paket als lokalen Entwicklungs-Link oder Repo-Checkout und fahre ohne Update fort.

Skill-Familie

Die Skill-Familie ist aufgeteilt in einen übergeordneten Skill plus sieben Phasen-Skills:

  • tracking-discover für Crawl-Abdeckung, Plattformerkennung und Bootstrap neuer Artefakte
  • tracking-group für die Erstellung und Freigabe von Seitengruppen
  • tracking-live-gtm für die Prüfung der tatsächlichen Live-GTM-Runtime vor der Schema-Generierung
  • tracking-schema für Schema-Vorbereitung, Review, Validierung und Freigabe
  • tracking-sync für GTM-Konfigurationsgenerierung und Sync
  • tracking-verify für Preview-QA und optionale Publish-Übergabe
  • tracking-shopify für Shopify-spezifische Schema-, Sync-, Installations- und Verifikationsregeln

Wenn die Anfrage bereits auf eine Phase beschränkt ist und dieser Phasen-Skill verfügbar ist, leite dorthin weiter, anstatt das vollständige Runbook hier einzubetten.

Sobald site-analysis.json Shopify anzeigt, behalte die gemeinsame Discovery und Gruppierung bei und überlasse dann tracking-shopify den Shopify-spezifischen Zweig.

Gemeinsamer Vertrag

  • Verwende den Repo-lokalen Wrapper ./event-tracking in diesem Repository. Wenn dist/cli.js fehlt, führe zuerst npm run build aus.
  • Für öffentliche/ClawHub-Installationen musst du zuerst dies ausführen, bevor du einen event-tracking-Befehl verwendest: npx skills add jtrackingai/analytics-tracking-automation.
  • Halte ein Artefaktverzeichnis pro Site unter <output-root>/<url-slug> vor.
  • Wenn der Benutzer bereits ein Artefaktverzeichnis oder eine seiner Dateien bereitstellt, setze ab der frühesten nicht erfüllten Voraussetzung fort, anstatt von analyze neu zu starten.
  • Verwende ./event-tracking status <artifact-dir-or-file>, wenn der aktuelle Checkpoint oder der nächste Schritt unklar ist.
  • Verwende ./event-tracking runs <output-root>, wenn das Artefaktverzeichnis unbekannt ist, das Ausgabeverzeichnis jedoch bekannt ist.
  • Bevorzuge High-Level-Einstiegsbefehle für benutzerseitige Abläufe: run-new-setup, run-tracking-update, run-upkeep, run-health-audit.
  • Behandle Workflow-Mode-Metadaten als interne Workflow-State-Schicht, nicht als benutzerseitige Befehlsfläche.
  • Behandle Playwright-gestützte und OAuth-einladende Schritte standardmäßig als Nicht-Sandbox-Befehle. In der Praxis: analyze, validate-schema --check-selectors, preview und sync.
  • Führe promptgesteuerten GTM-Sync von Anfang an mit einem interaktiven TTY durch, es sei denn, die genauen Werte für --account-id, --container-id und --workspace-id sind bereits bestätigt.
  • Wähle niemals automatisch ein GTM-Konto, einen Container oder einen Workspace im Namen des Benutzers aus.
  • Gehe nicht über die Phasengrenze hinaus, nach der der Benutzer gefragt hat.

Gesprächsaufnahme

Wenn der Benutzer über den Chat hereinkommt und noch keine begrenzte Phase, kein Artefaktverzeichnis und keinen genauen Befehl angegeben hat, beginne mit einer absichtsorientierten Aufnahme.

Klassifiziere die Anfrage in einen dieser Einstiegs-Intents:

  • resume_existing_run: Der Benutzer hat bereits ein Artefaktverzeichnis oder eine seiner Dateien; inspiziere die Artefakte und verwende status.
  • new_setup: Net-neue Tracking-Implementierung von Grund auf; bevorzuge run-new-setup, folge dann dessen empfohlenem nächsten Schritt.
  • tracking_update: Überarbeite oder erweitere eine bestehende Implementierung; bevorzuge run-tracking-update.
  • upkeep: Routine-Wartung, Review oder inkrementelle QA einer bestehenden Einrichtung; bevorzuge run-upkeep.
  • tracking_health_audit: Nur-Audit-Bewertung des aktuellen Live-Trackings; bevorzuge run-health-audit.
  • analysis_only: Nur Crawl/Bootstrap/Discovery ohne sich bereits auf den vollständigen Workflow festzulegen; leite zu tracking-discover weiter und stoppe nach analyze.

Regeln:

  • Bitte den Benutzer nicht, zwischen internen Workflow-Metadaten-Flags und analyze zu wählen.
  • Wenn die Absicht mehrdeutig ist, stelle eine kurze, verständliche Intake-Frage mit benutzerseitigen Begriffen wie "neues Setup", "bestehendes Tracking aktualisieren", "Wartung", "Health-Audit", "nur analysieren" oder "bestehenden Lauf fortsetzen".
  • Wenn der Benutzer eine neue URL angibt und fragt, ob er Tracking einrichten soll, verwende standardmäßig new_setup.
  • Wenn der Benutzer eine neue URL angibt und nur darum bittet, die Site zu inspizieren, die Struktur zu analysieren oder die aktuellen Tracking-Signale zu überprüfen, verwende standardmäßig analysis_only.
  • Wenn der Benutzer ein Artefaktverzeichnis oder eine Workflow-Datei angibt, verwende standardmäßig resume_existing_run, anstatt von analyze neu zu starten.

Routing-Regeln

Leite nach Benutzerabsicht und aktuellen Artefakten:

  • neue URL, Crawl-Anfrage oder noch keine Artefakte: Beginne mit tracking-discover.
  • site-analysis.json mit fehlenden oder nicht bestätigten pageGroups: Leite zu tracking-group.
  • Bestätigte site-analysis.json mit erkannten Live-GTM-Container-IDs, aber noch keinem Live-Baseline-Review: Leite zu tracking-live-gtm.
  • Bestätigte site-analysis.json oder ein laufendes event-schema.json: Leite zu tracking-schema.
  • gtm-config.json: Leite zu tracking-sync.
  • gtm-context.json: Leite zu tracking-verify, wobei Publish als separate explizite Aktion behandelt wird.
  • Shopify-Plattformbestätigung: Behalte die gemeinsamen frühen Phasen bei, übergib dann an tracking-shopify.

Wenn nur der Root-Skill verfügbar ist, folge derselben Routing-Logik direkt und stoppe an der passenden Phasengrenze.

Stopp-Regeln

  • Überspringe nicht die Freigabe von Seitengruppen vor prepare-schema.
  • Fordere bei wichtigen Entscheidungs-Checkpoints immer explizite Benutzerbestätigung an, bevor du fortfährst:
    • pageGroups (vor confirm-page-groups und vor prepare-schema)
    • event-schema.json (vor confirm-schema und vor generate-gtm)
    • GTM-Zielauswahl (Konto/Container/Workspace während sync)
    • Publish-Entscheidung (vor publish)
  • Wenn die Bestätigung fehlt oder mehrdeutig ist, stoppe und frage nach; fahre nicht automatisch fort.
  • Eine breite Anfrage wie "vollständiger Workflow", "全流程", "end-to-end" oder "mach alles weiter" ist nur eine Bereichsautorisierung. Sie gilt nicht als Checkpoint-Genehmigung.
  • Zeichne niemals eine Checkpoint-Genehmigung im Namen des Benutzers mit confirm-page-groups --yes oder confirm-schema --yes auf, es sei denn, der Benutzer bestätigt diesen Checkpoint explizit in der aktuellen Runde.
  • Wenn Live-GTM-Container auf der Site erkannt werden, überspringe nicht das Live-Baseline-Review vor der Schema-Generierung.
  • Überspringe nicht die Schema-Freigabe vor generate-gtm, es sei denn, der Benutzer möchte explizit --force.
  • Behandle Preview-QA und Publish als separate Entscheidungen.
  • Behandle tracking-health.json als Publish-Gate; springe nicht zu Publish, wenn Health fehlt, manuell oder blockiert ist, es sei denn, der Benutzer möchte explizit --force.
  • Behandle die manuelle Shopify-Verifikation als den erwarteten Pfad für Shopify-Läufe, nicht als Fallback-Fehlerfall.
  • Behandle tracking_health_audit als Nur-Audit-Workflow-Modus. Führe keine GTM-Bereitstellungsaktionen (generate-gtm, sync, publish) aus, es sei denn, der Benutzer bittet explizit um Überschreibung.

Fortsetzen und Abschluss

Beim Fortsetzen:

  • Bevorzuge workflow-state.json, wenn vorhanden.
  • Überprüfe dennoch den tatsächlichen Artefaktsatz, wenn Warnungen auf veraltete Gates hinweisen.
  • Verwende status, wenn der nächste Schritt unklar ist.

Wenn eine Phase oder der vollständige Workflow endet, halte die Abschlussantwort an erster Stelle:

  • Beginne mit einer kompakten, entscheidungsbereiten Zusammenfassung in verständlicher Sprache.
  • Gib keine rohen JSON-Daten, rohen URL-Listen oder Artefaktbestände vor der Zusammenfassung aus.
  • Liste Dateien, Checkpoints und den nächsten Befehl erst nach der menschenlesbaren Zusammenfassung auf.

Referenzen

Verwandte Skills

affaan-m/uspto-database

USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs.

community

affaan-m/scholar-evaluation

Structured scholarly-work evaluation for papers, proposals, literature reviews, methods sections, evidence quality, citation support, and research-writing feedback.

community

affaan-m/literature-review

Systematic literature-review workflow for academic, biomedical, technical, and scientific topics, including search planning, source screening, synthesis, citation checks, and evidence logging.

community

affaan-m/everything-claude-code

The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.

community

forrestchang/andrej-karpathy-skills

Agent skill repository discovered by 10x-chat research.

community

langgenius/backend-code-review

Review backend code for quality, security, maintainability, and best practices based on established checklist rules. Use when the user requests a review, analysis, or improvement of backend files (e.g., `.py`) under the `api/` directory. Do NOT use for frontend files (e.g., `.tsx`, `.ts`, `.js`). Supports pending-change review, code snippets review, and file-focused review.

community
← More Recherche & Datenanalyse skills