LLM-Traffic ist ein blinder Fleck in Ihrer Analytics. Hier erfahren Sie, warum.
Ihr KI-Kanal wächst. Ihre Analytics kommt nicht hinterher.
ChatGPT, Gemini, Claude, Perplexity und andere LLMs erzeugen mehr Traffic, als Sie denken. Das Volumen tröpfelt nicht herein, es beschleunigt sich in einem Tempo, das beginnt, etablierte Kanäle zu bedrängen. Manche Analysten schätzen, dass der KI-Referral-Traffic bis 2028 die klassischen Suchverweise übertreffen könnte. Wir sind der Ansicht, dass das auf einigen Websites bereits heute geschieht.
Dieser Artikel erklärt, warum, auf Basis praktischer Tests über mobile und Desktop-Geräte hinweg, mit Browser-Debug-Modi, serverseitigem Request-Logging und weiteren Techniken bei drei führenden LLM-Plattformen: ChatGPT, Gemini und Claude.
Zuerst: Verstehen Sie, wo sich Ihre Nutzer aufhalten
Bevor wir uns damit befassen, was wann bricht, hilft es, das Ausmaß des Problems nach Gerätetyp zu verstehen.
Mobile ist die dominierende Plattform für Webtraffic. Laut Cloudflare Radar, das HTTP-Anfragen über ein Netzwerk mit mehr als 20 % des gesamten globalen Webtraffics verfolgt, entfallen auf mobile Geräte rund 50 % aller Webanfragen. Diese Zahl sollte man am besten als Untergrenze betrachten: Das Cloudflare-Netzwerk führt ein beträchtliches Volumen an API-Traffic, B2B-Diensten und Entwickler-Tools, die allesamt stark Desktop-lastig sind. Verbraucherorientierter Webtraffic liegt auf mobilen Geräten deutlich höher. In den GA4-Konten, mit denen wir täglich arbeiten, machen mobile Geräte typischerweise zwischen 70 % und 90 % der Gesamtsitzungen aus. Desktop-Traffic ist real, aber zweitrangig.
Auf mobilen Geräten scheitert die LLM-Attribution am vollständigsten. Das Gerät, das der Großteil Ihrer Zielgruppe nutzt, ist das Gerät, auf dem die Messung am stärksten gestört ist.
Was wir getestet haben
Um genau zu verstehen, wo das Tracking bricht, haben wir praktische Tests auf mobilen und Desktop-Geräten mit den nativen Apps und Webbrowsern für ChatGPT, Gemini und Claude durchgeführt. Die Tests wurden auf einem iPhone mit der neuesten iOS-Version, einem Android-Gerät mit der neuesten Android-Version, einem Mac mit der neuesten macOS-Version und einem Windows-PC mit der neuesten Windows-Version durchgeführt.
Für jedes Szenario haben wir untersucht, ob UTM-Parameter vorhanden waren, ob ein Referrer an die Zielseite übergeben wurde und ob die Sitzungsidentität erhalten blieb, wenn ein Nutzer von der LLM-Oberfläche in einen Standardbrowser wechselte.
Hier ist, was wir gefunden haben.
Die Ergebnisse auf einen Blick
Die Zeile für die ChatGPT-Mobile-App ist als teilweise markiert, weil selbst bei vorhandenem UTM die realistische Nutzerreise, etwas in der App zu entdecken und später in einem Gerätebrowser zu konvertieren, dazu führt, dass UTMs nur selten die Conversion überleben. Unsere Schätzung liegt irgendwo zwischen 10 % und 20 % der Fälle.
Alle Browser-Zeilen erscheinen als trackbar, aber die mobile LLM-Nutzung erfolgt größtenteils über native Apps, nicht über den Browser. Die trackbaren Szenarien sind die Minderheit. Die App-Zeilen, in denen das Tracking weitgehend versagt, spiegeln das wider, was der Großteil Ihrer Zielgruppe tatsächlich erlebt.
Mobil: Wo der meiste Traffic ist, und wo das Tracking bricht
Die obige Tabelle erzählt die Geschichte ziemlich deutlich. Für mobile Apps gibt es ein geringes bis gar kein trackbares Signal. Aber warum?
Die Antwort lautet: Web-View. Es lohnt sich, zu verstehen, was das tatsächlich bedeutet, bevor wir auf die Plattform-Besonderheiten eingehen.
Wenn ein Nutzer in einer mobilen LLM-App auf einen Link tippt, ob in ChatGPT, Gemini oder Claude, öffnet sich der Link typischerweise in einem isolierten In-App-Browser, dem sogenannten Web-View. Dieser Web-View teilt weder Cookies, Sitzungsdaten noch die Identität mit dem nativen Browser des Geräts. Jeglicher Tracking-Zustand, der innerhalb dieses Web-Views aufgebaut wird, bleibt dort gefangen.
Die praktische Konsequenz: Wenn ein Nutzer das Browsen innerhalb der LLM-App beendet und später seinen regulären Gerätebrowser öffnet, um weiter zu recherchieren oder zu konvertieren, gibt es keine Kontinuität. Keine gemeinsame Identität. Keine Übergabe. Dieser Besuch wird zu unattribuiertem Direct-Traffic.
ChatGPT auf Mobilgeräten ist die am besten nachvollziehbare der getesteten Optionen. Die App übergibt utm_source=chatgpt.com bei ausgehenden Links, und technisch existiert ein Pfad zur Attribution, der jedoch von einer Abfolge von Ereignissen abhängt, die nicht sehr wahrscheinlich ist. Damit dieses UTM bis zu einer Conversion überlebt, müsste der Nutzer auf den Link innerhalb von ChatGPT tippen, in den In-App-Web-View geführt werden und dann explizit auf “Im Browser öffnen” tippen, um die Session an seinen nativen Browser zu übergeben, bevor er weiternavigiert. Beachten Sie, dass dieser Weg die Session nur auf Android-Geräten erhält. Unter iOS durchbricht selbst dieser Umweg die Sitzungskontinuität.
In der Praxis entdeckt jemand Sie innerhalb von ChatGPT. Die Person liest über Sie, klickt vielleicht kurz auf Ihre Website und geht dann weiter. Später, vielleicht eine Stunde später, vielleicht zwei Tage später, sucht sie auf Google nach Ihnen oder tippt einfach Ihre URL direkt ein, und dann beginnt möglicherweise der Conversion-Prozess. Diese Sitzung trägt keinerlei Spur der ChatGPT-Interaktion, die das Ganze angestoßen hat. Das UTM ist weg. Der Referrer ist weg. GA4 erfasst sie als “direct” oder “organic search”, und ChatGPT erhält keine Anerkennung. Und ja, das gilt selbst dann, wenn Sie Tracking-Funktionen wie Google Signals in Ihrer GA4-Property aktiviert haben.
Gemini und Claude auf Mobilgeräten übermitteln in keinem der getesteten Szenarien UTM-Parameter oder einen Referrer. Sitzungen von diesen Plattformen landen als reiner Direct-Traffic. Es gibt kein Signal, das sie mit dem LLM verbindet, das sie angetrieben hat.
Eine Nuance ist erwähnenswert: Wenn ein Nutzer eine Website entdeckt und innerhalb des Web-Views konvertiert, besteht in diesem isolierten Kontext eine interne Sitzungskontinuität. Der Web-View behält eigene Cookies über Sitzungen hinweg bei, sodass eine vollständig innerhalb der App abgeschlossene Reise theoretisch messbar ist. Standardbeschränkungen beim Cookie-Tracking gelten weiterhin, und wie oft Nutzer eine vollständige Conversion-Schleife innerhalb eines App-Web-Views abschließen, ist selbst eine offene Frage, die es zu erforschen lohnt.
Desktop: Besser, aber immer noch uneinheitlich
Der Desktop bietet günstigere Tracking-Bedingungen als mobile Geräte, doch das Bild bleibt fragmentiert, je nachdem, welche Plattform und Oberfläche verwendet wird.
Im Gegensatz zu mobilen Geräten sperren Desktop-LLM-Apps Links nicht in isolierte Web-Views ein. Sie übergeben ausgehende Links direkt an den Standardbrowser des Nutzers. Das Problem der Web-View-Isolation gilt auf dem Desktop also nicht. Was jedoch weiterhin gilt, ist, ob die Plattform überhaupt UTMs oder einen Referrer übergibt, und auf diesem Feld sind die Ergebnisse gemischt.
ChatGPT auf dem Desktop (native App) übergibt utm_source=chatgpt.com bei ausgehenden Links, das zuverlässigste Desktop-Szenario aller getesteten Plattformen. ChatGPT im Browser übermittelt einen Referrer, aber keine UTMs.
Gemini hat keine Desktop-App auf Mac oder Windows. Die gesamte Gemini-Desktop-Nutzung läuft über den Browser. Gemini im Browser übermittelt einen Referrer, aber keine UTMs, dieselbe Situation wie bei browserbasiertem ChatGPT.
Claude schneidet in allen Desktop-Szenarien am schlechtesten ab. Die native Desktop-App übermittelt weder UTMs noch einen Referrer. Auch Claude im Browser übermittelt keines von beidem. Jede Sitzung aus Claude auf dem Desktop landet als völlig unattribuierter Direct-Traffic, unabhängig davon, wie der Nutzer dorthin gelangt ist.
Das verschärfende Problem: Selbst gute Attribution schafft es nicht immer bis zur Conversion
Nehmen wir einmal an, das Tracking funktioniert. Das UTM ist gesetzt, der Referrer ist vorhanden, die Sitzung ist attribuierbar. Sie könnten meinen, Sie seien abgesichert.
Sind Sie nicht.
Der Weg von einer LLM-Interaktion zu einer abgeschlossenen Conversion ist selten eine einzige Sitzung. Ein Nutzer entdeckt tagsüber über ChatGPT auf seinem Smartphone etwas. Er klickt auf den Link, landet auf der Seite, stöbert einige Minuten. Er geht ohne Conversion. Zwei Tage später kommt er auf seinem Laptop zurück, um die Sache abzuschließen. An diesem Punkt ist das ursprüngliche UTM möglicherweise abgelaufen, das Gerät ist möglicherweise ein anderes, die Cookies sind möglicherweise weg.
Cookie-Ablauf, geräteübergreifende Reisen und Multi-Session-Pfade brechen jeweils unabhängig voneinander die Attribution. Zusammen sorgen sie dafür, dass selbst der Bruchteil der LLM-verwiesenen Sitzungen, die beim ersten Touchpoint korrekt getaggt werden, nur selten die Anerkennung für die eigentliche Conversion erhält.
Das ist kein Problem, das nur für LLM-Traffic gilt. Aber es trifft hier härter, weil LLM-assistierte Entdeckung tendenziell früher im Überlegungsprozess stattfindet, die Menschen recherchieren und erkunden, sie sind nicht kaufbereit. Der Abstand zwischen diesem ersten KI-beeinflussten Besuch und der späteren Conversion ist länger als ein typisches Click-to-Conversion-Fenster bei Paid-Traffic, was das Cross-Device-Problem verschärft.
Was das für Ihre Daten bedeutet
Versehen wir das Ganze mit groben Zahlen. Das Ziel ist keine falsche Präzision: Es geht um einen vernünftigen Bereich, der Ihnen hilft, das Ausmaß dessen zu verstehen, was Ihnen wahrscheinlich entgeht.
Beginnen Sie mit der Geräteaufteilung. Cloudflare Radar beziffert den globalen mobilen Webtraffic auf rund 50 % aller HTTP-Anfragen, und diese Zahl fällt für Verbraucher-Zielgruppen niedrig aus, weil das Cloudflare-Netzwerk einen hohen Anteil an API- und Entwickler-Traffic führt. In den GA4-Konten, mit denen wir arbeiten, liegt der Mobilanteil typischerweise zwischen 70 % und 90 % der Sitzungen. Wir verwenden hier 70 %, um konservativ zu bleiben.
Dann stellt sich die Frage, wie Menschen LLMs auf ihren Smartphones tatsächlich nutzen. Nicht alle nutzen die native App. Manche rufen ChatGPT, Gemini oder Claude über den mobilen Browser auf, und Browsernutzung ist deutlich besser trackbar. Zwei Annahmen umrahmen die Spanne.
Basisannahmen, die in beiden Fällen verwendet werden:
- Mobil/Desktop-Aufteilung: 70 % mobil, 30 % Desktop
- App-Signal-Überlebensrate: 20 % der Mobile-App-Klicks übermitteln erfolgreich ein brauchbares Signal (z. B. ein Android-Nutzer, der auf “Im Browser öffnen” tippt, oder eine Conversion innerhalb des Web-Views)
- Conversion-Pfad-Schwund: 25 % Abschlag für Signalverluste durch Gerätesprünge und abgelaufene Cookies
- Google-AIO-Faktor: Ein Teil der KI-beeinflussten Entdeckung geschieht inzwischen über Google AI Overviews und AI Mode, was GA4 als Standard-Organic-Search erfasst, ohne Möglichkeit zur Trennung
Die Spanne
Die obigen Annahmen sind Schätzungen, setzen Sie gern Zahlen ein, die Ihre eigene Zielgruppe oder Annahmen besser widerspiegeln. Verwenden Sie eine andere Mobil-Aufteilung, ein anderes App-zu-Browser-Verhältnis, eine andere Schwundrate. Das Modell ist nicht präzise gemeint. Es soll zeigen, dass unabhängig davon, welche vernünftigen Zahlen Sie wählen, die Schlussfolgerung dieselbe bleibt: Es findet eine erhebliche Untererfassung statt, und die Lücke ist groß genug, um relevant zu sein.
Mit unseren Annahmen reicht die Spanne von etwa 2,5x am optimistischen Ende bis zu 5x am pessimistischeren Ende, und möglicherweise höher, sobald Sie LLM-beeinflusste organische Google-Sitzungen einrechnen, die mit Standard-Analytics nicht zu trennen sind.
Wenn Ihr Dashboard 1,5 % Ihrer Sitzungen als von LLMs stammend ausweist, kommen wahrscheinlich irgendwo zwischen 4 % und 8 % dieser Sitzungen tatsächlich von LLMs, und diese Zahl wächst rasant. Das ist ein ganzer Kanal, der sich in Ihren Direct- und Organic-Berichten versteckt.
Lässt sich das beheben?
Teilweise. Eine vollständige Lösung gibt es nicht, aber es existieren sinnvolle Verbesserungen für Teams, die bereit sind, in anspruchsvollere Analytics und Tracking zu investieren.
Server-Side-Tracking und Request-Logging können Signale erfassen, die clientseitigem JavaScript vollständig entgehen. Device-Fingerprinting-Tools können probabilistische Identität über Web-View- und Browser-Kontexte auf demselben Gerät hinweg aufrechterhalten und schließen damit teilweise die Isolationslücke, die Standard-Cookie-Tracking nicht überbrücken kann. Keiner der Ansätze bringt Sie zu einer vollständigen Messung, und keiner löst das geräteübergreifende Problem ohne einen eingeloggten Nutzerstatus, der beide Sitzungen zusammenhält.
Die ehrliche Antwort: Eine vollständige Messung werden Sie nie erreichen. Die Architektur mobiler Betriebssysteme, die Referrer-Richtlinien der LLM-Plattformen und die Natur von Multi-Session-, geräteübergreifenden Reisen arbeiten allesamt dagegen. Aber das ist nicht das Wichtigste, was man über diesen Kanal verstehen muss.
Das Ziel der Messung ist keine perfekte Zählung jeder einzelnen Conversion: Es ist ein directionales Verständnis, das gut genug ist, um Entscheidungen zu treffen. Sie müssen nicht jede LLM-assistierte Conversion attribuieren, um zu wissen, dass dieser Kanal wächst, dass Ihr Anteil daran etwas ist, das Sie beeinflussen können, und dass sich die relativen Veränderungen, die Sie an Ihrer AI-Visibility-Strategie vornehmen, in Ihren Zahlen zeigen werden. Wenn sich Ihr LLM-verwiesener Traffic verdoppelt, nachdem Sie Ihre Inhalte für eine bessere KI-Zitation umstrukturiert haben, ist diese Bewegung aussagekräftig, egal ob Sie jeden einzelnen Verkauf auf eine bestimmte Chat-Sitzung zurückführen können oder nicht.
Dieser Artikel ist kein Argument dafür, die Messung aufzugeben. Er ist ein Argument dafür, unvollkommene Messung nicht zur Ausrede für Untätigkeit werden zu lassen. Die Teams, die AI Visibility jetzt als ernsthaften Wachstumskanal behandeln, nicht erst, wenn die Attribution sauberer ist, nicht erst, wenn GA4 aufgeholt hat, sondern jetzt, sind diejenigen, die einen Vorsprung aufbauen, den einzuholen schwer sein wird.
Methodik
Die Tests wurden auf einem iPhone mit der neuesten iOS-Version, einem Android-Gerät mit der neuesten Android-Version, einem Mac mit der neuesten macOS-Version und einem Windows-PC mit der neuesten Windows-Version durchgeführt. Linux wurde nicht direkt getestet, dürfte aber ähnlichen Mustern folgen. Jede LLM-Plattform, ChatGPT, Gemini und Claude, wurde über ihre native App (falls verfügbar) und über den Gerätebrowser getestet. Für jedes Szenario haben wir untersucht, ob UTM-Parameter gesetzt wurden, ob ein Referrer an die Zielseite übergeben wurde und ob die Sitzungsidentität erhalten blieb, wenn die Navigation von der LLM-Oberfläche zum Standardbrowser des Geräts wechselte. Server-Side-Logging wurde ergänzend zu den clientseitigen Beobachtungen eingesetzt.
Diese Recherche spiegelt das Plattformverhalten zum Zeitpunkt der Tests wider (12. April 2026). LLM-Plattformen aktualisieren ihre Apps und Weboberflächen häufig, und das Tracking-Verhalten kann sich ändern.
Das Fazit
KI-Kanäle sind keine Zukunftsfrage. Sie sind jetzt aktiv, wachsen und prägen Entscheidungen im großen Stil. Das Problem ist, dass die Infrastruktur, mit der die meisten Teams diese Kanäle messen, für eine Welt gebaut wurde, in der ein Klick einen verlässlichen Referrer und ein Cookie lieferte, das lange genug hielt, um eine Conversion zu sehen.
So funktioniert LLM-Traffic nicht.
Behandeln Sie die Zahlen Ihres KI-Kanals als erhebliche Untererfassung. Die sichtbaren Sitzungen sind die, die es zufällig durch jede Schicht des Tracking-Verlusts geschafft haben. Die anderen sind weit zahlreicher, und zu ihnen zählen Menschen, die Sie gefunden haben, die davon beeinflusst wurden, was eine KI über Sie gesagt hat, und die konvertiert haben, ohne eine Spur zu hinterlassen, der Sie folgen könnten.
Häufig gestellte Fragen
Warum zeigt mein GA4 fast keinen Traffic von Claude oder Gemini?
Weil beide Plattformen in der überwiegenden Mehrheit der von uns getesteten Szenarien keine UTM-Parameter und keinen Referrer übermitteln. Auf mobilen Geräten öffnen sich Links in isolierten In-App-Web-Views, die nie mit Ihrer Standard-Analytics-Umgebung verbunden sind. Auf dem Desktop übermittelt Claude weder in der App noch im Browser etwas. Gemini übermittelt im Browser einen Referrer, aber keine UTMs. Ohne das eine oder andere landet der Großteil dieses Traffics in GA4 als “direct” oder wird schlicht gar nicht erfasst.
ChatGPT zeigt etwas Traffic in meinen Berichten. Bedeutet das, dass er präzise getrackt wird?
Nicht ganz. ChatGPT ist die am besten nachvollziehbare der drei getesteten Plattformen. Sie hängt in mehreren Szenarien utm_source=chatgpt.com an, und die Desktop-App tut dies zuverlässig. Auf mobilen Geräten ist der Weg zur Attribution jedoch schmal und plattformabhängig. Das UTM kann überleben, wenn der Nutzer innerhalb des Web-Views auf “Im Browser öffnen” tippt, doch das funktioniert nur unter Android. Unter iOS bewahrt diese Übergabe die Session überhaupt nicht. Die Identität geht verloren, wenn der Nutzer den Web-View verlässt, unabhängig davon, wie er ihn verlässt. Selbst im besten Fall brauchen Sie also einen Nutzer unter Android, der die App verwendet und explizit auf “Im Browser öffnen” tippt, bevor er weiternavigiert. Das ist ein kleiner Ausschnitt Ihres tatsächlichen mobilen ChatGPT-Traffics. Die Zahlen, die Sie in GA4 sehen, sind real, aber sie repräsentieren nur einen Bruchteil dessen, was ChatGPT tatsächlich antreibt.
Betrifft dieses Problem nur mobile Nutzer?
Auf mobilen Geräten ist es am gravierendsten, aber auch auf dem Desktop ist es nicht sauber. Claude auf dem Desktop übermittelt in allen getesteten Szenarien nichts, weder in der App noch im Browser. Gemini auf dem Desktop übermittelt einen Referrer, aber keine UTMs, was je nach GA4-Setup korrekt klassifiziert werden kann oder auch nicht. Die Desktop-App von ChatGPT ist der einzige verlässliche Lichtblick. Selbst wenn Ihre Zielgruppe vollständig am Desktop wäre, würden Sie immer noch einen erheblichen Anteil an LLM-beeinflusstem Traffic verpassen.
Was ist ein Web-View und warum verursacht er Tracking-Probleme?
Ein Web-View ist ein In-App-Browser, der sich öffnet, wenn Sie in einer mobilen App auf einen Link tippen. Er sieht aus wie ein Browser, ist aber vom tatsächlichen Browser Ihres Geräts isoliert. Er teilt weder Cookies, Sitzungsdaten noch die Identität mit Safari oder Chrome. Jegliches Tracking, das in einem Web-View ausgelöst wird, bleibt also dort gefangen. Wenn der Nutzer später seinen echten Browser öffnet, um seine Reise fortzusetzen, wirkt er wie ein brandneuer Besucher ohne Vorgeschichte.
Wenn die endgültige Conversion im Web-View der App stattfindet, wird das getrackt?
Das kann sein, aber es ist nicht sauber. Die Conversion muss innerhalb des Web-Views stattfinden, damit die Attributionskette hält. Der Nutzer muss seine gesamte Reise nicht dort verbracht haben, aber dieser letzte Schritt schon. Der Haken ist, dass iOS bei den meisten Zielgruppen den Großteil des mobilen Traffics ausmacht, und unter iOS unterliegt der Web-View den Cookie-Beschränkungen von WebKit, einschließlich Intelligent Tracking Prevention. Diese Beschränkungen können die Kontinuität, auf die Sie sich verlassen, einschränken oder brechen. Auch wenn dieses Szenario theoretisch trackbar ist, ist es in der Praxis die am wenigsten kaputte verfügbare Option, kein verlässlicher Weg.
Kann ich das mit Server-Side-Tracking beheben?
Server-Side-Tracking hilft, löst aber nicht alles. Es kann Signale erfassen, die clientseitigem JavaScript entgehen, darunter Referrer-Daten, die GA4 nie erreichen. Device-Fingerprinting-Tools können zudem helfen, indem sie probabilistische Identität über Web-View- und Browser-Kontexte auf demselben Gerät hinweg aufrechterhalten. Doch keiner der Ansätze löst das geräteübergreifende Problem, und keiner liefert Ihnen eine vollständige Messung. Sie kommen der Wahrheit spürbar näher, aber Sie kommen nicht ganz hin.
Wie stark wird Traffic mit LLM-assistierter Conversion tatsächlich untererfasst?
Unserer Analyse zufolge irgendwo im Bereich des 2,5- bis 5-fachen, abhängig von Ihrer Zielgruppe und davon, wie sie LLM-Plattformen nutzt. Die konservative Schätzung (Fall A) geht davon aus, dass die Hälfte der mobilen Nutzer LLMs über den Browser aufruft, wo das Tracking weitgehend funktioniert, was nach Berücksichtigung der Verluste auf dem Conversion-Pfad zu einer etwa 2,5-fachen Untererfassung führt. Die realistischere Schätzung (Fall B) geht davon aus, dass 80 % der mobilen Nutzer die native App nutzen, wo das Tracking im Wesentlichen versagt, was eine 4- bis 5-fache Untererfassung ergibt. Beide Schätzungen dürften noch konservativ sein, denn ein wachsender Anteil dessen, was GA4 als organischen Google-Traffic einstuft, ist tatsächlich LLM-beeinflusster Traffic, der über AI Overviews und AI Mode eintrifft, Traffic, der sich mit Standard-Analytics nicht trennen lässt.
Sollte ich mehr in AI Visibility investieren, wenn ich die Ergebnisse nicht messen kann?
Ja, wohl sogar mehr, nicht weniger. Dass Sie die volle Wirkung dieses Kanals nicht messen können, bedeutet nicht, dass die Wirkung nicht vorhanden ist. Es bedeutet, dass Ihre aktuellen Tools nicht ausreichen, um sie zu erkennen. Die Sitzungen, die es bis in Ihre Berichte schaffen, zeigen bereits deutliches Engagement. Diejenigen, die es nicht schaffen, sind um Größenordnungen zahlreicher. Diesen Kanal als unwichtig zu behandeln, weil die Zahlen klein wirken, ist genau die falsche Schlussfolgerung.