Der CFO einer 8-Standort-Gruppe kann Ihnen genau sagen, was der Werbeetat des letzten Monats gekostet hat. Fragen Sie ihn, welcher Euro davon den Verkauf erzeugt hat, der tatsächlich Geld eingebracht hat — nicht einfach irgendein Verkauf, sondern der mit dem unterbewerteten Inzahlungnahme-Fahrzeug, dem genutzten F&I-Menü, dem Fahrzeug, das zum Listenpreis wegging, statt 90 Tage zu stehen und mit einem Preisnachlass von 2.000 € das Haus zu verlassen — und die Antwort existiert nicht. Nicht weil niemand hinschaut. Sondern weil die zwei Systeme, die sich darüber einigen müssten, nie dafür gebaut wurden, über dasselbe Fahrzeug zu sprechen.
Warum beantwortet „Welcher Kanal hat den Klick bekommen" die CFO-Frage nicht?
GA4 erfasst eine Conversion als eine Sitzung, die ein Ziel erreicht hat — ein ausgefülltes Formular, ein Klick-zum-Anruf, ein VDP-Engagement, das als Lead-Event markiert wurde. Das ist eine echte Zahl. Sie ist aber auch eine andere Zahl als die, die ein CFO tatsächlich braucht: Hat dieses spezifische Fahrzeug verkauft, zu welchem Preis im Verhältnis zu seinem tatsächlichen Wert, und welche Werbe-Euro haben es auf dem Weg zur Unterschrift berührt.
Das sind nicht dieselben Fragen in unterschiedlicher Formulierung. Ein Kanal kann zwanzig Conversions pro Monat zu einem hervorragenden CPL liefern und dennoch der Kanal sein, der am meisten dazu beigetragen hat, alte, überteuerte Fahrzeuge mit einem Rabatt zu bewegen, den niemand schlucken wollte. Ein anderer Kanal kann zwölf Conversions zu einem schlechteren CPL liefern und dabei still und leise die Fahrzeuge verkaufen, die null Preisnachlass brauchten. Das Dashboard von GA4 rankt den ersten Kanal jedes Mal höher, weil Volumen und Cost-per-Lead die einzigen Eingaben sind, die es hat. Marge ist nicht im Schema.
Das ist dasselbe blinde Fleck, der in GA4s Unfähigkeit, die Expositionshistorie eines spezifischen VINs nachzuverfolgen, behandelt wird — nur dass die Margen-Version des Problems schlimmer ist, weil selbst ein Händler, der VIN-genaues Expositions-Tracking löst, das meist für Lead-Attribution löst, nicht für das Preis-Ergebnis. Zu wissen, dass ein Tundra auf Meta gesehen und auf Microsoft gesucht wurde, sagt nichts darüber aus, ob er für seinen tatsächlichen Wert verkauft wurde.
Welcher Werbe-Euro hat den margenpositiven Verkauf erzeugt?
Stellt man die exakte CFO-Frage neben das, was der typische Reporting-Stack einer 8-Standort-Gruppe tatsächlich liefern kann, ist die Lücke strukturell — kein Konfigurationsproblem. Die Werbeplattformen melden Kosten und Conversions pro Kampagne. Die eigene Website des Händlers zeigt, zu welchem Preis ein Fahrzeug an einem bestimmten Tag angeboten wurde. Kein System kennt für sich allein den endgültigen Verkaufspreis eines Fahrzeugs im Verhältnis zu seiner Preishistorie — und keines weiß, welche spezifischen Werbeexpositionen stattgefunden haben, bevor das Fahrzeug den Besitzer wechselte.

Das Ergebnis: Budgets werden durch Cost-per-Lead auf Kanalebene verteidigt — das ist die falsche Einheit für ein Geschäft, bei dem ein Marketingposten von 700 € und einer von 4.000 € beide „ein Lead" sein können, obwohl sie wildly unterschiedliche Ergebnisse darstellen, sobald der Kaufvertrag steht. Ein CFO, der den Channel-Mix auf Basis von CPL verteidigt, verteidigt die falsche Zahl mit echter Überzeugung — das ist schlimmer als gar nicht messen, weil es rigoros aussieht.
Das ist dieselbe Falle, die in der CFO-Frage nach den Kosten pro verkauftem Fahrzeug in einer Multi-Standort-Gruppe beschrieben wird: Cost-per-Lead überlebt als Reporting-Standard genau deshalb, weil er leicht zu produzieren ist — nicht weil er beantwortet, was der CFO tatsächlich wissen will. Marge pro Kanal ist aus einem strukturellen Grund schwerer zu produzieren: Es erfordert die Verknüpfung von Werbeplattform-Daten mit der tatsächlichen Preishistorie eines Fahrzeugs — und fast nichts in einem typischen Stack leistet diese Verknüpfung.
Warum suchen Händler ständig nach „Dealership CRM" und „Digital Sales vs. Digital Marketing"?
Das Autocomplete-Volumen beider Phrasen hält sich seit Monaten konstant — und keine davon ist wirklich eine Kaufanfrage. Ein GM, der „Dealership CRM" bei Google eingibt, sucht nicht nach einem neuen CRM-Anbieter — das CRM weiß bereits, wer gekauft hat. Ein GM, der „Digital Sales vs. Digital Marketing" eintippt, zieht eine Grenze, die auf keiner Rechnung, die er je erhalten hat, als Posten auftaucht: Der Marketing-Bericht endet bei einem Lead oder einem Klick, und das Verkaufsergebnis — was das Auto tatsächlich eingebracht hat — liegt in einem völlig separaten Datensatz, den niemand mit dem Werbeetat abgeglichen hat.
Dieses Suchmuster ist ein Symptom derselben Lücke, mit der dieser Artikel begonnen hat. Händler tasten sich an eine Frage heran, die ihre aktuellen Anbieter nicht beantworten — ohne dass sie schon einen Namen für die fehlende Ebene hätten. Wenn genug GMs und CFOs Varianten derselben unbeantworteten Frage in eine Suchzeile eingeben, ist das ein Marktsignal: Das bestehende Toolset schweigt zu dem, was tatsächlich zählt — unabhängig davon, was das Dashboard jeder einzelnen Plattform zu zeigen behauptet.
Warum kann weder das CRM noch die Werbeplattform diese Frage allein beantworten?
Teilt man das Problem in seine zwei Hälften auf, scheint jede für sich lösbar — genau das ist der Grund, warum niemand die kombinierte Version behoben hat.

Die Werbeplattform-Seite: Das Produkt-Level-Reporting von Google Shopping und Performance Max kann Conversion-Daten nach product_item_id aufschlüsseln — das ist für den Fahrzeug-Feed eines Händlers der VIN, und Meta-Catalog-Ad-Insights unterstützen eine product_id-Aufschlüsselung, die auf denselben VIN abbildet, wenn die Anzeige aus einem Fahrzeugkatalog ausgeliefert wurde. Die Werbeplattform-Seite einer fahrzeuggenauen Ansicht ist also technisch verfügbar — sofern jemand die Pipeline aufbaut, die Daten auf VIN-Ebene statt auf Kampagnen-Ebene zu ziehen, was fast niemand tut.
Die Preis-Seite ist ein separates Problem: Zu wissen, zu welchem Preis ein spezifischer VIN im Verhältnis zu seinem ursprünglichen Angebotspreis verkauft wurde, erfordert eine Aufzeichnung der Preisentwicklung dieses Fahrzeugs über die Zeit — nicht nur den aktuellen Listenpreis. Die Website eines Händlers zeigt den heutigen Preis. Sie zeigt nicht, dass derselbe VIN vor drei Wochen 2.000 € teurer war, oder dass er zweimal gesunken ist, bevor er den Besitzer wechselte. Ohne diese Historie sehen „das Auto hat verkauft" und „das Auto hat mit einem Rabatt verkauft, der die Rentabilität des Deals vernichtet hat" aus der Sicht der Werbeplattform identisch aus — beides ist einfach ein Conversion-Event.
Weder das CRM noch die Werbeplattform wird diese Lücke allein schließen, weil das CRM nie dafür gebaut wurde, VIN-spezifische Werbeexposition aufzunehmen, und die Werbeplattform nie dafür gebaut wurde, die Preishistorie eines Fahrzeugs zu verfolgen. Die Verknüpfung muss an einem dritten Ort stattfinden, der gezielt dafür gebaut wurde, beide Hälften zu halten.
Warum behebt ein besseres Attributionsmodell das Problem nicht?
Wenn ein CFO die Lücke bemerkt, ist der Instinkt, ein ausgefeilteres Attributionsmodell zu fordern — datengetrieben statt last-click, Inkrementalitätstests, die aus dem CPG-Bereich entlehnt sind. Das berührt das eigentliche Problem nicht. Ein besseres Modell, angewendet auf Conversion-Zahlen, die nie mit der Preishistorie verknüpft wurden, produziert nur eine selbstsichere Version derselben unvollständigen Antwort. Man kann eine elegante Multi-Touch-Gewichtung über fünf Kanäle aufbauen und immer noch keine Ahnung haben, ob das Fahrzeug, um das es bei diesen fünf Berührungspunkten ging, mit gesunder Marge verkauft wurde oder mit Verlust abgestoßen wurde, um die Standtage zu reduzieren.
Attributionsmodellierung beantwortet: „Welcher Touchpoint bekommt die Gutschrift für die Conversion." Sie beantwortet nicht: „War die Conversion es wert, gutgeschrieben zu werden." Das sind unterschiedliche Fragen — und eine Händlergruppe, die einen Budgetzyklus damit verbringt, die erste zu verfeinern, während die zweite unbeantwortet bleibt, hat die falsche Ebene des Stacks optimiert.
Was wäre nötig, um die Werbeexposition eines Fahrzeugs neben seinem Preis-Ergebnis zu sehen?
Drei Dinge müssen am selben Ort vorhanden sein, bevor diese Frage für einen einzigen VIN beantwortet werden kann — geschweige denn für ein Portfolio: Engagement-Daten, die zeigen, dass ein Interessent die Seite dieses Fahrzeugs tatsächlich aufgerufen hat; Werbeplattform-Daten, die zeigen, in welchen Kampagnen dasselbe Fahrzeug erschienen ist; und eine Preishistorie, die zeigt, zu welchem Preis das Fahrzeug während der gesamten Werbezeit angeboten wurde — nicht nur am Tag des Verkaufs.
GA4 kann Seitenaufrufe und engagierte Sitzungen auf Ebene der einzelnen Fahrzeug-Detailseite melden, wenn die Website eines Händlers so instrumentiert ist, dass die Identität dieser Seite als Event-Parameter übergeben wird. Das löst den ersten Teil. Das oben beschriebene VIN-genaue Werbeplattform-Reporting löst den zweiten. Der dritte Teil — Preishistorie über die Zeit, nicht nur ein aktueller Preisschnappschuss — ist derjenige, den fast kein Händler-Stack überhaupt vorhält, weil die meisten Inventory-Feeds den bisherigen Preis überschreiben, sobald ein neuer gesetzt wird.
Wie löst AUTONOMi das
AEGIS führt als feste nächtliche Funktion eine fahrzeuggenaue Funnel-Intelligence durch — sie vereint GA4-Engagement auf Fahrzeug-Detailseitenebene mit VIN-spezifischer Werbeleistung aus Googles Produkt-Level-Shopping/PMax-Reporting und Metas Catalog-Ad-product_id-Aufschlüsselung, verknüpft mit der VIN-spezifischen Preishistorie, die aus den eigenen Inventory-Scrapes des Händlers erfasst wird. Das ist die Verknüpfung, die dieser Artikel die ganze Zeit beschrieben hat — keine CRM-Integration, kein DMS-Feed, sondern die drei Teile (Engagement, Werbeexposition, Preishistorie) an einem Ort, weil AEGIS das System ist, das alle drei bereits generiert und hält.
AEGIS nimmt das Inventory eines Händlers auf, indem es die öffentliche Website des Händlers in einem wiederkehrenden Zyklus scrapt — das bedeutet, jede Preisänderung, die ein VIN durchläuft, wird als datierter Datensatz erfasst statt überschrieben — der Preishistorien-Teil, den die meisten Stacks by Design verwerfen, ist ein Nebenprodukt davon, wie AEGIS das Inventory ohnehin bereits verfolgt. Diese Historie macht einen Preisnachlass als Preisnachlass sichtbar, anstatt ihn in dem Moment unsichtbar zu machen, in dem der neue Preis den alten auf der Seite ersetzt.
Was dabei entsteht, ist eine fahrzeuggenaue Diagnose, kein Dashboard auf Kanalebene: Für einen gegebenen VIN, ob die Werbeexposition ausreichend war und der Preis der Einwand war, oder ob die Werbeexposition dünn war und die Sichtbarkeit die eigentliche Lücke, oder ob das Fahrzeug mit einem Preisnachlass verkauft wurde, der den dagegen eingesetzten Werbeetat von Anfang an einpreisen hätte müssen. Das ist eine grundlegend andere Lesart als „Kanal X hat diesen Monat N Conversions produziert" — es ist eine Lesart, die zurückverweist auf die Frage, ob der resultierende Verkauf ein lohnenswerter war. Diese VIN-genaue Werbeleistungsansicht deckt derzeit Google und Meta ab — die zwei Plattformen mit Produkt- oder Catalog-Level-Reporting, das AEGIS bis auf VIN-Ebene ausliest — und erstreckt sich noch nicht auf TikTok oder Microsoft Ads in derselben Granularität.
Nichts davon ist eine DMS- oder CRM-Integration, und es wird auch nicht als solche dargestellt. Es ist das, was AEGIS sehen kann, weil es bereits die Kampagnen betreibt, bereits die GA4-Property ausliest und bereits das Inventory scrapt — drei Datenquellen, die ein System bereits berührte, verknüpft auf Fahrzeugebene statt als drei separate Berichte, die niemand abgleicht.
Was sollte ein CFO mit 8 Standorten vor dem nächsten Budgetmeeting damit anfangen?
Die ehrliche Version der These dieses Artikels ist enger gefasst als „AUTONOMi löst Attribution." Sie lautet: Die Frage, die ein CFO tatsächlich beantwortet haben will — welcher Euro hat den margenpositiven Verkauf erzeugt — kann von einem System, das nur Klicks sieht, nicht beantwortet werden. Und sie kann auch von einem System nicht beantwortet werden, das nur den heutigen Preis sieht. Es braucht ein System, das Engagement, Werbeexposition und Preishistorie kontinuierlich gegen dasselbe Fahrzeug hält — nicht einmal im Quartal aus drei Exporten rekonstruiert, die keinen gemeinsamen Schlüssel teilen.
Ein CFO, der sehen möchte, wie diese Verknüpfung gegen die eigene Standortzahl und den eigenen Channel-Mix aussieht, bevor er Budget in einen Umbau steckt, kann den Gesamtetat und die Kanal-Allokation der Gruppe gegen eine fahrzeuggenaue Ansicht der Zahlen modellieren — statt eine weitere Runde CPL-Verteidigung auf Kanalebene durchzuführen, die eine Frage beantwortet, die auf Finanzebene niemand gestellt hat.
