Call Tracking für SEO: Anrufe korrekt zuordnen

Ein Anruf, der aus einer organischen Landingpage entsteht, hinterlässt in Google Analytics oft keine Spur. Der Besucher liest die Seite, tippt die angezeigte Telefonnummer ab oder tippt auf einen Anruf-Button auf dem Smartphone – und das Gespräch selbst findet außerhalb des Browsers statt. Für GA4 endet die Sitzung dort, wo der Klick aufhört zu existieren. Das Ergebnis: Ein Lead, der am Telefon zum zahlenden Kunden wird, taucht im Analytics-Bericht als gewöhnlicher, nicht konvertierter Seitenaufruf auf – oder verschwindet komplett aus der Statistik.

Dieser Artikel behandelt nicht, was Call Tracking grundsätzlich ist oder wie man ein Tool dafür auswählt – das wird an anderer Stelle im Blog bereits besprochen. Es geht um die eine Lücke, die dabei fast immer übersehen wird: Wie ein Anruf technisch der richtigen organischen Seite zugeordnet wird, warum ein erheblicher Teil der Anrufe die eigene Website nie berührt, wie geschlossene Abschlüsse aus dem CRM zurück in die SEO-Berichterstattung fließen – und warum die Zahlen am Ende trotzdem niemals exakt übereinstimmen werden. Wer bereits eine Formel für den ROI organischen Traffics im Kopf hat, findet hier den fehlenden Baustein für deren Ertragsseite.

Dynamic Number Insertion und die NAP-Falle

Dynamic Number Insertion, kurz DNI, tauscht die auf der Seite angezeigte Telefonnummer per JavaScript aus – abhängig davon, über welchen Kanal, welche Kampagne oder manchmal sogar welche einzelne Landingpage der Besucher gekommen ist. Technisch liegt dahinter ein Pool von Rufnummern, die ein Call-Tracking-Anbieter verwaltet. Wählt der Besucher die angezeigte Nummer, läuft der Anruf zunächst beim Anbieter auf, wird protokolliert – inklusive Quelle, Kampagne und oft Landingpage – und erst dann automatisch an die tatsächliche Geschäftsnummer weitergeleitet. Der Anrufer bemerkt davon nichts außer einer minimal längeren Verbindungszeit.

Genau hier entsteht ein Zielkonflikt mit lokalem SEO. Name, Adresse und Telefonnummer (NAP) müssen über Website, Google Unternehmensprofil und Branchenverzeichnisse hinweg konsistent sein, weil Suchmaschinen und Verzeichnis-Aggregatoren diese Konsistenz als Vertrauenssignal für ein reales, stabiles Unternehmen werten. Wird die angezeigte Nummer serverseitig für jeden Besucher unterschiedlich gerendert, sieht auch ein Crawler bei jedem Besuch eine andere Nummer im Quelltext – und diese kann sich von der Nummer im Google Unternehmensprofil und in Zitationen unterscheiden. Schlimmer wird es, wenn eine solche Tracking-Nummer aus dem HTML heraus indexiert oder von einem Verzeichnis übernommen wird: Dann existiert dauerhaft eine zweite, offiziell nirgends bestätigte Nummer im Umlauf.

Die praktikable Lösung trennt zwei Ebenen sauber voneinander: Die Nummer, die in strukturierten Daten (Schema.org LocalBusiness), im Footer, im Google Unternehmensprofil und in Zitationen steht, bleibt statisch und unangetastet. Der Tausch findet ausschließlich clientseitig statt, nachdem die Seite bereits mit der echten Nummer geladen wurde – ein Crawler, der kein JavaScript zur Nummernanzeige ausführt oder die strukturierten Daten separat ausliest, sieht dann immer die korrekte, zitierte Nummer.

Dasselbe Prinzip gilt für alles, was Nummern automatisiert aus dem Web übernimmt. Verzeichnis-Aggregatoren und manche Bewertungsportale gleichen Telefonnummern regelmäßig gegen das ab, was sie im Web finden, und aktualisieren ihre eigenen Einträge daran – landet eine Tracking-Nummer einmal in diesem Kreislauf, verbreitet sie sich von dort aus weiter, ohne dass DNI selbst noch beteiligt ist. Wo eine Anrufaufzeichnung oder eine Ansage vor der Weiterleitung eingesetzt wird, gehört auch das rechtlich sauber gelöst – in Deutschland braucht eine Aufzeichnung in der Regel die Einwilligung beider Seiten, weshalb ein kurzer Hinweis vor Gesprächsbeginn technisch meist ohnehin Teil der Weiterleitung ist.

• Die Nummer in Schema-Markup, Footer, Google Unternehmensprofil und Verzeichniseinträgen niemals durch DNI überschreiben lassen.
• Der Nummerntausch sollte rein clientseitig nach dem Laden erfolgen, nie serverseitig fest in den ausgelieferten Quelltext eingebacken werden.
• Rufnummern aus dem Tracking-Pool mit passender Ortsvorwahl wählen, damit eine versehentlich zitierte Nummer wenigstens plausibel lokal wirkt.
• Den Pool regelmäßig prüfen: Nummern, die durch alte Backlinks oder Screenshots im Netz zirkulieren, aus der Rotation nehmen.

Den Anruf der richtigen organischen Landingpage zuordnen

Damit ein Anruf nicht nur dem Kanal „Organisch", sondern einer konkreten Seite zugerechnet werden kann, braucht es sitzungsbasiertes statt nur poolbasiertes Tracking. Bei poolbasiertem DNI bekommt jeder Kanal eine feste, kleine Menge an Nummern – das reicht, um Organisch von Bezahlt zu unterscheiden, aber nicht, um eine einzelne Landingpage zu identifizieren. Sitzungsbasiertes DNI reserviert dagegen für die Dauer eines einzelnen Besuchs eine Nummer exklusiv für genau diesen Besucher. Beim ersten Seitenaufruf werden Referrer, Landingpage-URL und Quelle erfasst und mit der zugewiesenen Nummer verknüpft, bevor die Seite überhaupt vollständig geladen ist.

Damit diese Zuordnung auch dann noch stimmt, wenn der Besucher innerhalb der Sitzung zu einer zweiten oder dritten Seite weiterklickt, wird in der Regel ein First-Touch-Modell innerhalb der Sitzung verwendet: Die ursprüngliche Einstiegsseite bleibt für den gesamten Besuch die zugeordnete Landingpage, unabhängig davon, wo der Anruf-Button am Ende tatsächlich angeklickt wird. Verlässt der Besucher die Seite und kommt Tage später über eine gespeicherte Nummer im Adressbuch zurück, funktioniert diese Zuordnung nicht mehr – die Nummer war für die ursprüngliche Sitzung reserviert, nicht dauerhaft für die Person.

Viele Anbieter verlängern deshalb das Attributionsfenster über eine reine Browsersitzung hinaus, etwa über ein länger lebendes Cookie, das die Nummernzuordnung mehrere Wochen hält. Das erhöht die Trefferquote bei Käufen mit längerer Entscheidungsphase, kostet aber Genauigkeit: Ein Anruf drei Wochen nach dem letzten Besuch wird dann formal noch der damaligen Landingpage zugerechnet, obwohl in der Zwischenzeit möglicherweise weitere, nicht erfasste Recherche stattgefunden hat.

Eine Ebene tiefer als die Landingpage stößt die Zuordnung an eine harte Grenze: Der konkrete Suchbegriff, der zu diesem Besuch geführt hat, wird bei organischem Traffic aus Datenschutzgründen von Google nicht an Analytics-Tools weitergereicht. Ein Call-Tracking-Report kann deshalb zuverlässig sagen, welche Seite den Anruf ausgelöst hat, aber nicht, welche konkrete Suchanfrage davor stand – anders als bei bezahltem Traffic, wo dieser Wert über die Kampagnenstruktur oft noch verfügbar ist. Wer die Suchanfrage dennoch braucht, muss sie indirekt über die Search-Console-Daten der jeweiligen Landingpage annähern, nicht über das Call-Tracking selbst.

Der Anruf, der die Website nie erreicht

Ein beträchtlicher Teil lokaler Anrufe entsteht, ohne dass die Website überhaupt besucht wird: der Klick auf den Anruf-Button direkt im Suchergebnis-Snippet des Google Unternehmensprofils, im Knowledge Panel oder in Google Maps. Der Nutzer sieht Name, Bewertung und Nummer, tippt auf „Anrufen" – und war zu keinem Zeitpunkt auf der Domain. Es gibt schlicht keine Seite, auf der ein DNI-Skript die Nummer hätte austauschen können, und folglich auch kein GA4-Ereignis, das ausgelöst werden könnte.

Diese Anrufe verschwinden nicht spurlos, sie tauchen nur woanders auf: als aggregierte Kennzahl „Anrufe" in den Insights des Google Unternehmensprofils. Diese Kennzahl liefert eine Gesamtzahl pro Zeitraum, aber keine Anrufer-ID, keine Anrufdauer und keine Möglichkeit, einen einzelnen Anruf später mit einem CRM-Datensatz zu verknüpfen. Google bietet in manchen Konfigurationen selbst eine Weiterleitungsnummer für das Unternehmensprofil an – diese läuft dann über Googles eigene Infrastruktur und ist von den Nummern des eigenen DNI-Anbieters unabhängig, lässt sich also auch nicht ohne Weiteres in denselben Trichter einspeisen.

Daraus folgt ein struktureller, nicht durch bessere Konfiguration lösbarer Punkt: Alles, was innerhalb der Google-Oberflächen selbst passiert, bevor ein Nutzer die eigene Domain überhaupt lädt, bleibt für jedes JavaScript-basierte Tracking-Tool unsichtbar. Die einzig ehrliche Konsequenz ist, die Insights-Kennzahl aus dem Unternehmensprofil als eigenständige, parallele Größe zu führen – als Kontext neben der organischen Website-Performance, aber ohne Anspruch, sie zahlenmäßig mit den DNI-Anrufen der Website zu einer einzigen Summe zu verschmelzen. Wer versucht, beides zu addieren, zählt in Wahrheit zwei verschiedene, sich teilweise überschneidende Nutzerpfade als wären es getrennte Ereignisse.

Auf dem Smartphone kommt eine weitere Variante hinzu: Tippt jemand in der Maps-App auf „Anrufen", öffnet sich direkt die native Telefon-App des Geräts, ganz ohne Umweg über einen Browser oder eine Webseite. Auf dem Desktop zeigt Google in der Regel nur die Nummer zum Abtippen an – auch das ohne jeden Website-Besuch. Beide Varianten laufen technisch außerhalb dessen, was ein auf der eigenen Domain installiertes Skript jemals sehen kann, unabhängig davon, wie sorgfältig DNI dort eingerichtet ist.

Abgeschlossene Deals aus dem CRM zurück in die SEO-Zahlen holen

Ein Anruf ist im Moment der Verbindung nur ein Lead, kein Umsatz. Ob daraus ein zahlender Kunde wird, entscheidet sich oft erst Tage oder Wochen später – nach einem Angebot, einem Beratungsgespräch oder mehreren Rückrufen. Genau diese Verzögerung ist der Grund, warum die Ertragsseite einer ROI-Rechnung für organischen Traffic so häufig auf Schätzwerten statt auf beobachteten Zahlen beruht: Man kennt die Zahl der Anrufe, aber nicht deren tatsächlichen Wert.

Die Rückkopplung funktioniert über einen gemeinsamen Schlüssel. Jeder Anruf oder Lead wird bei seiner Entstehung mit einem Bezug zu seiner Quelle versehen – das kann die gewählte Tracking-Nummer selbst sein, eine Sitzungs- oder Anruf-ID, oder ein Referenzcode, der automatisch in das CRM übertragen wird. Der Vertrieb arbeitet den Lead wie gewohnt ab und trägt am Ende Ergebnis und Wert ein: gewonnen, verloren, Auftragswert in Euro. Für das Vertriebsteam ändert sich am eigentlichen Workflow nichts.

Regelmäßig – wöchentlich oder monatlich reicht in der Praxis meist aus, da Deals selten binnen Stunden abgeschlossen werden – wird dieser CRM-Export über den gemeinsamen Schlüssel mit den Anrufdaten der Website zusammengeführt. Das Ergebnis ist eine Tabelle der Art: Landingpage X erzeugte in einem Zeitraum N Anrufe, davon wurden M zu gewonnenen Deals im Wert von insgesamt Y Euro. Diese Zahl Y ist keine Annahme mehr, sondern eine beobachtete Größe – exakt die Ertragsseite, die eine ROI-Berechnung sonst nur über einen angenommenen durchschnittlichen Auftragswert schätzen müsste.

Am robustesten funktioniert diese Verknüpfung, wenn der Call-Tracking-Anbieter den Lead-Datensatz per Programmierschnittstelle automatisch im CRM anlegt und dabei die Marketingdaten direkt mitschickt. Die verlässlichste Verbindung bricht fast immer an derselben Stelle: bei einem Referenzfeld, das ein Vertriebsmitarbeiter manuell ausfüllen müsste. Bleibt dieses Feld leer, weil es optional ist oder im Tagesgeschäft schlicht vergessen wird, lässt sich der Anruf später nicht mehr zurückverfolgen – der Datensatz existiert im CRM, aber ohne jede Verbindung zu seiner Herkunft.

Warum GA4 und CRM sich niemals vollständig decken werden

Wer versucht, die Zahl der Schlüsselereignisse (früher Conversions) aus GA4 mit der Zahl gewonnener Deals im CRM auf die Stelle genau abzugleichen, vergleicht zwei Systeme, die grundsätzlich Verschiedenes messen. Das ist kein Zeichen einer fehlerhaften Einrichtung, sondern eine strukturelle Eigenschaft der beiden Datenquellen.

Ein vereinfachtes Beispiel macht das greifbar, ganz ohne echte Zahlen zu behaupten: Nehmen wir an, GA4 weist für einen Monat 40 Anruf-Schlüsselereignisse auf einer bestimmten Landingpage aus. Im CRM tauchen für denselben Zeitraum 33 tatsächlich geführte Gespräche auf, von denen 9 zu einem gewonnenen Deal wurden – die Differenz zwischen 40 und 33 erklärt sich allein durch Anrufe, die zwar die Mindestdauer erreichten, aber auf der Mailbox landeten oder falsch verbunden waren. Keine der beiden Zahlen ist „falsch"; sie beantworten schlicht unterschiedliche Fragen.

Die praktische Konsequenz daraus ist, jedes System für das zu nutzen, worin es zuverlässig ist: GA4 für das Signal, welche Seite überhaupt Anrufe auslöst, das CRM für das, was aus diesen Anrufen tatsächlich wird. Die im vorigen Abschnitt beschriebene, zusammengeführte Tabelle ist der Ort, an dem beide Sichtweisen zusammengeführt werden – nicht, um eine einzige, deckungsgleiche Zahl zu erzwingen, sondern um Trends und Größenordnungen über einen längeren Zeitraum verlässlich beurteilen zu können.

• GA4 zählt ein Schlüsselereignis oft schon, wenn ein Anruf eine hinterlegte Mindestdauer erreicht – das CRM zählt erst, wenn ein Vertriebsmitarbeiter den Deal als gewonnen markiert. Zwei unterschiedliche Ereignisse zu zwei unterschiedlichen Zeitpunkten.
• Ein Deal, der erst nach dem Attributionsfenster von GA4 abschließt, hat dort keinen Anknüpfungspunkt mehr – die Website-Sitzung ist längst aus dem Berichtszeitraum herausgefallen.
• Ein Anruf, der klingelt, aber nur auf der Mailbox landet, kann je nach Konfiguration die Mindestdauer erreichen und in GA4 als Schlüsselereignis zählen, ohne dass im CRM je ein Kontakt entstanden ist.
• Google wendet auf kleinere Datenausschnitte in GA4 Schwellenwerte und Modellierung an, die exakte Rohzahlen absichtlich glätten oder unterdrücken – ein CRM-Export kennt solche Schwellenwerte nicht.
• Reale Kaufreisen verlaufen über mehrere Sitzungen, teils über Wochen, mit einem Anruf irgendwo mittendrin – kein Attributionsmodell in GA4 bildet das vollständig ab, und das CRM kennt von dieser Reise ohnehin nur die Quelle „Telefon".
• Menschliche Fehler im CRM selbst – falsch zugeordnete Quelle, zusammengeführte Duplikate, vergessene Statusaktualisierung – verschieben Zahlen zusätzlich, unabhängig vom Tracking.

Die kleinstmögliche Einrichtung, die in der Praxis reicht

Nicht jede Website braucht sitzungsbasiertes Tracking auf jeder einzelnen Seite. Für die meisten Fälle genügt eine reduzierte Variante, die den Aufwand klein hält und trotzdem die wichtigsten Lücken aus diesem Artikel schließt.

• Sitzungsbasiertes DNI nur auf den Landingpages einsetzen, die tatsächlich nennenswerten organischen Traffic mit Kaufabsicht erhalten – auf schwach besuchten Unterseiten reicht poolbasiertes Tracking pro Kanal.
• Die im Google Unternehmensprofil hinterlegte Nummer unverändert lassen und die dort erfassten Anrufe bewusst als eigene, parallele Kennzahl führen statt sie den Website-Anrufen zuzurechnen.
• Das Referenzfeld, über das ein CRM-Datensatz mit seiner Marketingquelle verknüpft wird, technisch verpflichtend statt optional machen – oder besser noch automatisiert per Schnittstelle befüllen, statt es auf manuelle Eingabe zu verlassen.
• Die zusammengeführte Anruf-zu-Deal-Auswertung monatlich statt in Echtzeit betrachten, weil Deals Zeit zum Reifen brauchen und wöchentliche Blicke meist nur Rauschen zeigen.