Hugo: Ben, willkommen bei DataFramed.
Ben: Danke, Hugo. Es ist großartig, hier zu sein, und ich freue mich darauf, heute mit dir über Convoy und Data Science zu sprechen.
Hugo: Ganz meinerseits. Es ist klasse, dass du da bist. In unserer laufenden DataFramed-Reihe darüber, was Data Science ist und sein kann, bin ich wirklich gespannt, heute mit dir über deine Arbeit bei Convoy zu sprechen und darüber, welche Rolle Data Science bei der Revolution der Lkw-Branche spielen kann – vermutlich eine der einflussreichsten Branchen in Nordamerika. Aber zuerst möchte ich über dich sprechen.
Ben: Gerne, danke.
Was macht ein Data Scientist?
Hugo: Ich werde oft gefragt: Was machen Data Scientists eigentlich? Ben, was denken deine Kolleginnen und Kollegen, was du tust?
Ben: Gute Frage. Der Begriff „Data Scientist" ist ziemlich unscharf. Er bedeutet für unterschiedliche Menschen Unterschiedliches. Ich komme zur Data Science mit einem natur- und sozialwissenschaftlichen Hintergrund. Außerdem habe ich einen Abstecher ins Silicon Valley gemacht, bevor ich meinen PhD in Volkswirtschaftslehre gemacht habe. Für mich sieht der Tag so aus: Etwa die Hälfte verbringe ich in Meetings über die Wissenschaft hinter unserer Plattform, darüber, wie wir Data Science hier weiterentwickeln, oder über konkrete Fragen wie Versuchsdesign. Etwa die Hälfte meiner Zeit mentore ich andere Data Scientists – ich helfe Junioren beim Versuchsdesign für eine Kampagne oder baue zum Beispiel ein Survival-Modell, um Kundenbindung zu verstehen.
Die andere Hälfte arbeite ich als Individual Contributor an den Hebeln unserer Plattform und versuche, Wirkung zu erzielen, indem ich das jeweils brennendste Problem löse. Da geht es um Themen wie Auktionen, Matching oder Pricing. Wer rechnen kann, merkt: Das sind drei Hälften. Aber ich arbeite in einem Startup – da addiert sich nicht immer alles zu eins.
Hugo: Absolut. Bei DataCamp habe ich manchmal das Gefühl, ich operiere als unendliche Summe. Und da dein Hintergrund in der Physik liegt: Du hast mir erzählt, für Physiker gibt es nur drei Zahlen, richtig?
Ben: Genau. Null, eins und unendlich – alles andere ist eine Frage der Skalierung. Das ist der alte Witz.
Bens Weg in die Data Science
Hugo: Eben. Wie bist du in die Data Science gekommen?
Ben: Gute Frage. Ich habe eigentlich immer mit Software, Daten, Mathematik, Statistik und Modellen gearbeitet. Nachdem DJ Patil den Begriff geprägt hat und der viral ging, hat mich irgendwann das Marketing als Data Scientist umbenannt. Schon im Studium habe ich Software geschrieben, um wissenschaftliche Fragen zu beantworten. Mein erstes datenwissenschaftliches Projekt war ein Programm zur Modellierung der Kraterrelaxation für McKinnon, einen großartigen Planetenforscher an der Washington University. Die Band Frankie war dort damals angesagt, und weil es um Kraterrelaxation ging, nannte ich mein Programm Frankie. Später, nach dem PhD, war ich an der University of Chicago und wurde zu Amazon rekrutiert. Das war so 2012. Ab da habe ich wirklich den Schritt gemacht, Dinge aus der Wissenschaft in die Industrie zu übertragen.
Hugo: Und jetzt arbeitest du als Data Scientist bei Convoy?
Ben: Genau.
Convoy
Hugo: Erzähl ein bisschen, was Convoy macht und welche Mission ihr habt.
Ben: Das ist ein gutes Beispiel dafür, dass es für Software oft leichter ist, in eine etablierte Branche hineinzukommen, als dass eine etablierte Branche selbst Software in die Tiefe integriert. Die Frachtbranche gibt es seit Ewigkeiten. In den USA ist das ein riesiger Markt – rund 800 Milliarden Dollar. Ein Kernproblem: Die Carrier, also die Speditionen bzw. Lkw-Unternehmen, sind extrem fragmentiert. Der Carrier im 95. Perzentil hat zwei bis drei Lkw. Shipper, also Verlader, verbinden sich mit ihnen meist über Broker, und die arbeiten gefühlt mit 80er-Jahre-Technologie: Telefon und Fax. Was wir bei Convoy tun: Wir treiben „Digital Freight" voran. Wir nutzen Technologie und insbesondere Data Science, um den gesamten Prozess für alle zu verbessern. Es ist extrem wichtig, den richtigen Carrier mit der richtigen Fracht zu matchen – dann läuft alles runder. Also müssen wir Preise bestimmen, matchen und den Prozess automatisieren. Das wird die Kostenstruktur der Branche nachhaltig verändern. Und ihr alle seid auch Konsumentinnen und Konsumenten: Die meisten Dinge, die du kaufst, legen acht bis zehn Lkw-Fahrten zurück, bis sie bei dir sind. Wenn wir also die Frachtkosten senken, sollten Preise am Ende wettbewerbsfähiger werden.
Hugo: Wie sieht das konkret vor Ort aus? Du hast gesagt, Carrier sind die Fahrer?
Ben: Carrier … die Definition ist etwas kompliziert, weil viele Owner-Operator sind – der amerikanische Traum sozusagen. Zum Beispiel hier im pazifischen Nordwesten: Ein russischer Immigrant kommt mit nichts, arbeitet sich hoch, wird Owner-Operator mit einem Lkw, und baut dann mit dem Erfolg seine Flotte aus. Das möchte Convoy unterstützen. Oder es sind mittelgroße, etablierte Speditionen. Typischerweise haben sie einen oder mehrere Lkw. Über etwa 20 Lkw hinaus wird der Betrieb für Einzelne schwer zu skalieren, weil Logistik, HR und vieles mehr komplex werden.
Hugo: Klar. Wie sieht Convoy für Carrier konkret aus? Nutzen sie Apps, oder …
Ben: Ja, genau. Der Hauptkontakt läuft über die Convoy App. Wir haben ein Onboarding, mit dem sie uns ihren Informationssatz einfach bereitstellen – Versicherungen, Lizenzen usw. Dann aktivieren wir ihren Account. Ab da sehen sie Angebote, die wir ihnen basierend auf ihren Präferenzen ausspielen. Sie sagen zum Beispiel: „Ich fahre gern am I-5-Korridor." Dann können sie diese Ladungen direkt in der App annehmen – ohne je mit einem Menschen sprechen zu müssen. Sehr effizient.
Sie können auch auf Ladungen bieten. Wenn ihnen unser Preis nicht gefällt oder sie mit anderen Carriern konkurrieren, geben sie Gebote ab. Der Preis kann je nach Marktlage steigen oder fallen. Außerdem: Fährt jemand von San Francisco nach Los Angeles, sehen wir das und sagen: „Hey, wir haben eine Rückladung von Los Angeles – zurück dorthin, wo du warst, oder an einen passenden anderen Ort." So halten wir sie in Bewegung und sorgen für Einkommen, sodass sie seltener leer fahren. Denn rund 40% der Lkw-Kilometer sind leer – schlecht für Umwelt und Fahrer.
Hugo: Da gibt es sicher Varianten des Handlungsreisenden-Problems. Du willst ja nicht, dass jemand mit einem leeren Lkw von Seattle in die Bay Area fährt, nur um dort wieder etwas aufzunehmen. Du willst die Tour so optimieren, dass die Auslastung stimmt, oder?
Ben: Exakt. Je mehr Liquidität wir auf der Plattform haben, desto einfacher lassen sich solche Probleme lösen und Carrier nahezu dauerhaft in Bewegung halten.
Hugo: Sehr cool. Spannend finde ich, dass wir bei Data Science im industriellen Kontext oft zuerst an Tech denken – eine Branche, die mit dem Aufstieg datengetriebener Infrastruktur groß wurde. Ihr revolutioniert dagegen eine Industrie, die lange vor all dem existierte.
Ben: Stimmt. Wenn wir erfolgreich sind, verändern wir die Kostenstruktur einer Schlüsselbranche, die sehr viele Amerikaner betrifft. Eine erstaunliche Zahl, die ich bei Convoy gelernt habe: In rund 45 Bundesstaaten ist Lkw-Fahrer der häufigste Beruf. Das betrifft viele Menschen in ihrer Beschäftigung – und es betrifft alle als Konsumenten. Das kann das Leben vieler positiv beeinflussen. Besonders für die Fahrer selbst: Wir machen es ihnen leichter, ihr eigenes Geschäft zu führen, zu wachsen und mit weit weniger Reibung zu arbeiten.
Data Science bei Convoy
Hugo: Wie spielt Data Science dann eine zentrale Rolle für Convoys Mission?
Ben: Data Science ist Kern unseres Geschäfts. Seit Tag eins arbeiten wir automatisiert. Wir lösen viele faszinierende Probleme mit starkem Wirtschaftsbezug. Preise korrekt vorherzusagen ist essenziell – gegenüber Shippern, oft in langfristigen Verträgen, und gegenüber Carriern. Dann müssen wir das Matching-Problem lösen: den richtigen Carrier mit der richtigen Fracht. Das führt zu besseren Outcomes für alle. „Richtig" kann zum Beispiel weniger Leerfahrt bedeuten – also die Strecke, die man leer bis zum Startpunkt fährt. Auch Zielorte spielen eine Rolle. Wir kümmern uns um Auktionen und Preisakzeptanzmechanismen für Carrier sowie viele weitere Aspekte im Carrier-Lebenszyklus und stellen sicher, dass nach Abholung alles glattläuft. Da gibt es eine Fülle solcher Probleme.
Hugo: Klingt, als würdet ihr dem klassischen Henne-Ei-Problem begegnen: Um Shipper zu überzeugen, braucht ihr Carrier – und um Carrier zu überzeugen, braucht ihr Shipper.
Ben: Das ist für jede Plattform schwer. Simon Rothman, einer unserer Series-A-Investoren, hat dazu einen großartigen Beitrag geschrieben: Du musst im Grunde zwei Unternehmen gleichzeitig starten – Angebot und Nachfrage –, und die Balance halten.
Zum Glück haben wir ein starkes Sales-Team, das qualitativ hochwertige Nachfrage generiert. Dann bauen wir schnell die Angebotsseite auf, um die Balance zu halten. Das tracken wir eng. Jede Plattform denkt über Liquidität und Balance nach. Wie bei einer Dating-Seite: Bist du hetero und es gibt keine Frauen dort, ist das Erlebnis schlecht. Es braucht eine ausgewogene Verteilung.
Hugo: Das kenne ich aus der Frühphase bei DataCamp: Lernende gewinnen und parallel Dozierende – Dozierende wollen Publikum, Lernende die besten Dozierenden.
Ben: Genau. Dazu kommen Netzwerkeffekte. Läuft es einmal, wachsen solche Plattformen exponentiell – sehr spannend. Wenn du es richtig machst, schläfst du irgendwann kaum noch.
Hugo: Du hast ein starkes Sales-Team erwähnt. Wie ist das Data-Science-Team bei euch integriert, etwa im Zusammenspiel mit Sales?
Ben: Wir helfen vor allem beim Thema Pricing – wie man auf Ladungen bietet, auf welche man bieten sollte, und so weiter. Pricing ist extrem komplex, mit vielen Anreizstrukturen. Das zu entwirren würde Stunden dauern.
Hugo: Wir kreisen um die Rolle von Data Science. Welche konkreten Fragestellungen musst du in deinem Job beantworten?
Ben: Unsere Kultur ist stark datengetrieben. Wir experimentieren sehr viel – wie alle Top-Player in der Industrie, würde ich annehmen. Antworten finden wir oft nur durch Experimente. Deshalb haben wir stark in ein gutes Experimentier-Framework investiert, das schnelle Iterationen erlaubt. Es gibt unterschiedliche Ansätze für A/B-Tests – Bayes’sch oder frequentistisch. Bayes’sche oder sequentielle Analysen liefern oft schneller Antworten und erleichtern die Kommunikation mit Product Managern.
A/B-Tests
Hugo: Gib uns mal ein Beispiel für einen A/B-Test bei euch.
Ben: Typisch testest du, ob ein neuer UX-Flow besser funktioniert. Wir legen Wert darauf, dass Fahrer nach einem Trip ihre Unterlagen automatisch hochladen – etwa den BOL, den Frachtbrief (bill of lading). Wenn wir einen neuen Prozess einführen, der das erleichtert, können wir ein Experiment aufsetzen: Die eine Hälfte der Carrier bleibt auf der alten Version, die andere bekommt die neue. Nach einer Weile sagen wir mit einer bestimmten Wahrscheinlichkeit, ob der neue Prozess besser ist.
Hugo: Großartiges Beispiel und gute Erklärung von A/B-Tests. Du meintest, Bayes-Methoden liefern schneller Ergebnisse als frequentistische. Magst du kurz für Laien den Unterschied skizzieren?
Ben: Gerne. Der erste echte Statistik-Ansatz war bayesisch – entwickelt von Thomas Bayes, einem Pfarrer. Die Idee funktioniert ähnlich wie Intuition: Du startest mit einer Prior, also einer Vorannahme – zum Beispiel, dass der neue Prozess 10% Hebel bringt. Mit einlaufenden Daten aktualisierst du diese Annahmen. Dieses Bayes’sche Updating konvergiert zur Posterior-Verteilung – der Verteilung, die wir für den Hebel erwarten.
Zum Frequentismus: Bayes-Methoden waren lange schwer zu berechnen, bis vor vielleicht zwei Jahrzehnten. Es fehlte die Rechenpower. Seither hat sich viel getan. Vorher konntest du nur Spezialfälle lösen. R. A. Fisher und andere waren sehr kritisch gegenüber Bayes und entwickelten im frühen 20. Jahrhundert den frequentistischen Ansatz. Hier gibt es einen „wahren" Parameterwert, und mit wachsender Stichprobe konvergiert der Schätzer gegen die Wahrheit.
Frequentisten sprechen über p-Werte und Konfidenzintervalle – die klassische Hypothesentestung. Im Frequentismus würdest du einer Marketing-Managerin sagen: „Unter der Annahme, dass die Nullhypothese wahr ist, beträgt die Wahrscheinlichkeit, einen so großen oder größeren Effekt zu beobachten, 5,7%." Dann diskutierst du über Signifikanzniveaus von 5%. In dem Fall dürftest du die Null nicht verwerfen – deine Managerin sagt aber vielleicht: „5,7% ist nah an 5%, lass uns 10% nehmen." Schon bist du im Argumentationsdschungel. Mit Bayes kannst du sagen: „Es gibt eine 94,3%- oder 98%-Wahrscheinlichkeit, dass Variante A besser ist als B." Das ist ein viel einfacheres Gespräch.
Hugo: In deinem Beispiel wären A und B die unterschiedlichen UX-Varianten und die Zielgröße der Anteil derer, die ihre Unterlagen vollständig hochladen?
Ben: Genau.
Hugo: Als Funktion dessen, wie die UX gestaltet ist.
Ben: Richtig. Egal, was du testest: Hat der neue Workflow höhere Klickrate oder Conversion? Senkt er Churn? Wir finden, Bayes erleichtert die Gespräche mit Product Managern, und in unseren Simulationen konvergiert er schneller – für unser Geschäft. Eure Kilometer können variieren.
Hugo: Ich meine, Dave Robinson hat auf Stack Overflow mehrere Beiträge zu Bayes-A/B-Tests geschrieben und gezeigt, dass es bei ihren Experimenten nicht unbedingt schneller konvergiert. Das verlinken wir in den Shownotes.
Ben: Ja. Es gibt dazu auch starke Blogposts von Evan Miller.
Weitere Methoden: Ökonometrie und Machine Learning
Hugo: Du hast Versuchsdesign erwähnt. Viele würden nicht erwarten, dass solche Methoden eine so große Rolle bei der Neuerfindung der Lkw-Branche mit Data Science spielen. Welche anderen Methoden nutzt ihr?
Ben: Noch kurz zum Abschluss bei A/B-Tests: Es gibt viel Branchenwissen im Trucking. Unser Unternehmen ist halb Tech-Startup, halb Branchenveteranen. Deren Wissen und Intuition sind wertvoll, aber nicht immer exakt. Durch Experimente machen wir Dinge greifbar.
Hugo: Hat das auch eine soziale Komponente? Veteranen haben viel Erfahrung und Einfluss, Startups „disrupten" gerne – braucht es da Fingerspitzengefühl?
Ben: Ich kann nur für Convoys Kultur sprechen: Wir sind sehr teamorientiert – wie in einem guten Eishockey-Team. Beide Seiten schätzen, was die andere einbringt. Auch unter Branchenveteranen gibt es unterschiedliche Meinungen. Bei Convoy versuchen wir, unlösbare Diskussionen zu vermeiden. Wenn sich ein Streit nicht mit Theorie oder Fakten klären lässt, machen wir ein Experiment – statt endlos zu debattieren.
Hugo: Welche weiteren Techniken setzt ihr ein?
Ben: Wir machen angewandte Data Science mit Fokus auf konkrete Businessprobleme in kurzer Zeit. Wir sind tool-agnostisch und nehmen, was passt – R oder Python, jeweils mit Stärken und Schwächen. Bei konkreten Ansätzen: Wenn wir etwas vorhersagen müssen – etwa ob jemand einen BOL hochlädt oder ein guter Carrier ist –, kommt Machine Learning zum Einsatz: logistische Regression oder ein geboosterter Klassifikator. Wenn wir verstehen müssen, ob A B verursacht hat und wir kein Experiment machen konnten, sind wir in der angewandten Statistik und machen Regressionsanalysen. Mein erster schneller Erfolg bei Convoy: Vor meinem Start wurde ein Feature ohne A/B-Test live genommen, und man wollte wissen, ob es hilft. Mit Googles Causal-Impact-Paket auf Basis Bayes’scher strukturierter Zeitreihen konnte ich zeigen, dass das neue Feature einen positiven Effekt hatte.
Hugo: Stark. Und das mit bereits erhobenen Daten?
Ben: Genau. Wir hatten bestehende Daten und mussten prüfen, ob die Zuteilung quasi zufällig war – die Grundvoraussetzung für Experimente: zufällige Zuweisung zur Behandlung, plus weitere Annahmen wie Individualität, Probabilität und Unverfälschtheit. Wenn das nicht gilt, bist du bei Beobachtungsdaten und nutzt angewandte Statistik oder Ökonometrie, um möglichst nahe an eine zufällige Zuweisung zu kommen – damit du kausal sagen kannst, ob A B verursacht hat.
Hugo: Erinnerst du kurz, was Ökonometrie ist?
Ben: Ökonometrie ist der Werkzeugkasten, den Ökonominnen und Ökonomen für wirtschaftliche Probleme entwickelt haben. Für die Wirtschaftspraxis ist er extrem nützlich, weil die meisten unserer Probleme ökonomischer Natur sind. Ein Klassiker ist der Umgang mit Stichprobenselektion und anderen Formen von Endogenität – also wenn Ergebnisse im Modell gemeinsam bestimmt werden. Beispiel: Führt mehr Polizei zu weniger Kriminalität? Kriminalität hängt von Polizeipräsenz ab – und umgekehrt bestimmt Kriminalität die Polizeistärke. Das ist Simultanität. Stichprobenselektion siehst du überall: Du willst testen, ob kleinere Klassen das Leseverständnis verbessern, aber wohlhabende Eltern setzen durch, dass ihre Kinder in kleinen Klassen sind. Schon sind die Kinder in kleinen Klassen tendenziell leistungsstärker – Selektionsbias.
Hugo: Ökonometrie hat also Tools für solche Herausforderungen?
Ben: Genau. Besonders wichtig, aber außerhalb der Ökonomie weniger bekannt, ist Paneldaten-Ökonometrie. Diese Methoden helfen gegen sogenannte individuelle Heterogenität. Beobachte ich Carrier oder Sendungen über die Zeit, kann ich mit Paneldatenmethoden unbeobachtete individuelle Effekte herausrechnen, die sonst Schätzungen verfälschen würden.
Hugo: Klingt so, als gäbe es viele starke ökonometrische Tools, die in der Data-Science-Welt noch zu wenig genutzt werden.
Ben: Richtig. Ich liebe Machine Learning, aber es gibt Probleme, die sich damit nicht lösen lassen. Da wird ML überfokussiert und ökonometrische Methoden übersehen, die extrem hilfreich sind. Bei Uber, bevor ich zu Convoy ging, erzählte mir jemand im Gespräch, dass sie Probleme hatten, die nur mit einem strukturellen ökonometrischen Modell lösbar waren – sehr aufwendig, dauert oft ein Jahr und mehr. Man modelliert den gesamten Entscheidungsprozess und die Nutzenfunktion. Ist es fertig, hat man ein mächtiges Modell mit starken Kontrafaktik-Prognosen.
Hugo: Cool. Das war bei Uber?
Ben: Ja, das kam während eines Interviews mit ihnen auf, bevor ich zu Convoy ging.
Geodaten, Qualität und autonome Lkw
Hugo: Ihr habt sicher viele Geodaten, auch Zeitreihen im Raum. Spielt das bei euch eine Rolle?
Ben: Auf jeden Fall. Wir fangen gerade erst an, das Potenzial auszuschöpfen. In der App nutzen wir Geodaten vielfach, um das Erlebnis für Carrier zu verbessern. Kommt ein Carrier zur Abholung, können wir ihn automatisch anhand der Geodaten einchecken. Manche Ladeorte sind schlecht organisiert; halten sie Lkw zu lange, müssen sie Detention zahlen. Wir können das automatisch auszahlen, sobald Carrier anspruchsberechtigt sind, statt sie durch einen papierlastigen Prozess zu schicken – ähnlich einer Versicherungsmeldung in den USA.
Hugo: Wenn ihr all diese Daten habt, ließe sich damit nicht auch viel sozialwissenschaftliche Forschung betreiben?
Ben: Sicher. Es gibt spannende Fragen zu Matching, Plattformen und Auktionen. Ich würde da gern tiefer einsteigen. Daraus ließen sich viele akademische Arbeiten entwickeln.
Hugo: Welche Data-Science-Projekte bei Convoy siehst du als besonders wirkungsvoll oder gesellschaftlich aufschlussreich?
Ben: Ich bin etwas über ein Jahr bei Convoy, wir sind etwas über zwei Jahre alt. Ich habe mich vor allem auf Pricing und Experimente fokussiert. Ein besonders interessantes Experiment kurz nach meinem Start: Wir gaben Carriern mit hoher Qualität bevorzugten Zugang zu Ladungen – und die Qualität sank. Alle waren überrascht: Wir geben den Besten früher Arbeit, und die Qualität sinkt? Das ergibt keinen Sinn. Ein schlechter Manager würde sagen: „Data Scientist, du liegst falsch." Unser Data-Science-Manager Ziad Ismail hat aber eine starke Datenkultur aufgebaut und uns graben lassen. Ich dachte an die Matching-Literatur in der Ökonomie. Meine Hypothese: Weil wir den Pool auf eine kleinere, wenn auch bessere Gruppe beschränkt hatten, sank die Match-Qualität. Das konnten wir verifizieren und mittels Regressionsanalyse zeigen, dass Match-Qualität kausal auf die Ergebnisqualität wirkt. Ein tolles Ergebnis – es zeigt, wie wichtig Matching für unsere Plattform ist.
Hugo: Um es für mich aufzudröseln: Früher Zugang für High-Quality-Carrier verschlechterte in gewisser Weise die Matching-Qualität mit Shippern und führte zu schlechteren Ergebnissen?
Ben: Ja. Weil der Pool kleiner war, überwog der negative Effekt trotz höherer Carrier-Qualität – die schlechteren Matches führten zu schlechteren Ausführungsqualitäten.
Hugo: Es gibt eine brasilianische Ameisenart, bei der angeblich 30% nichts tun. Entfernst du diese 30% und kommst einen Tag später zurück, ist wieder ein neues Drittel inaktiv. Nicht, dass es bei euch „Untätige" gäbe, aber vielleicht gibt es eine stabilisierende Dynamik. Spannend, dass es entgegen der Intuition schlechter wurde.
Ben: Genau deshalb sind Experimente so wichtig. Wir haben hier die Tradition, dass das ganze Unternehmen vorab abstimmt, welche Variante gewinnen wird. Die Sieger bekommen Donuts oder coole Sticker vom UX-Team. Oft passiert etwas Unerwartetes. Man verliebt sich leicht in ein Feature, das fantastisch wirkt – aber echte Hebel zu finden, wird immer schwerer.
Hugo: In gewisser Weise betreibt ihr also ein Labor.
Ben: Ja, fokussiert auf unsere Geschäftsfragen.
Hugo: Wenn das zu sehr in Strategie oder Interna geht, sag Bescheid. Wie messt ihr die Qualität von Carriern oder Lieferungen?
Ben: Es gibt ein branchenweites Problem: Rund 10% der zugesagten Fahrten werden kurzfristig abgesagt – der Klassiker: „Mein Lkw ist kaputt." Lkws gehen nicht in 10% der Fälle kaputt. Meist hat jemand eine besser bezahlte Ladung bekommen. Manche Carrier machen das ständig. Andere haben 100, 300 Touren gemacht und fallen praktisch nie aus. „Fall-off" ist ein zentrales Qualitätsmaß, weil es für uns sehr teuer ist. Wir versprechen Shippern hohe Servicequalität und müssen dann in letzter Minute Ersatz finden – teuer.
Hugo: Verstanden. Und autonome Lkw – denkt ihr darüber nach?
Ben: Vorher noch: Weitere Qualitätsmetriken sind zum Beispiel Pünktlichkeit. Wir versuchen, die Nutzung der App zu fördern – das senkt Kosten in Compliance und Sicherheit. In dem genannten Experiment war Fall-off die Hauptmetrik. Generell gilt: Wenn Carrier die App nutzen, passieren viele gute Dinge. Als Data Scientists denken wir auch sehr ökonomisch über Anreizstrukturen nach, um gewünschtes Verhalten zu fördern. Beispiel: Wer die App nutzt, bekommt Quick Pay – wir zahlen am selben Tag. In der Branche ist 30 Tage Standard, weshalb viele die Forderung an Factoring-Firmen verkaufen und 2–3% verlieren. Effektiv geben wir ihnen also eine Gehaltserhöhung um 2–3%, wenn sie die App nutzen.
Hugo: Das ist eine Erhöhung – und die Liquidität steigt auch.
Ben: Genau. Ich weiß nicht, wie es dir geht, aber ich werde gern zeitnah bezahlt. 30 Tage zu warten, ist unschön – man hat Ausgaben.
Hugo: Und zu autonomen Fahrzeugen – ein Thema bei euch?
Ben: Definitiv. Unsere Gründer sind da sehr gut vernetzt und nah dran. Wenn autonome Lkw kommen – wohl schrittweise mit verschiedenen Automationsstufen –, müssen sie trotzdem mit Fracht verbunden werden. Unsere Plattform macht genau das. Unser Ziel ist, sie einfach auf der Angebotsseite zu integrieren.
Die Vielseitigkeit in der Data Science
Hugo: Wir haben die Wirkung von Data Science im Trucking beleuchtet. Du bist Rechenökonom, Ex-Physiker und warst Research Scientist bei Amazon. Wie fließen diese Disziplinen in deine Rolle ein?
Ben: Man kann nie zu viele Werkzeuge haben. Als junger Physiker hatte ich das Glück, mit John Wheeler zu arbeiten. Er sagte – neben Niels Bohr zitieren – gern: „Zitiere nichts, bevor du die Antwort kennst." Du solltest ein Gefühl dafür haben, was in deinem Problem plausibel ist. Es gibt die berühmte Anekdote mit Feynman: Er kam mit einem „Beweis", Wheeler sagte, das sei falsch. Feynman war irritiert – doch es war ein Fehler in seiner Rechnung. Wheelers Physikwissen war so tief, dass er wusste, das Ergebnis konnte nicht stimmen. Übertragen: Wenn du in einem Experiment 10% Hebel durch Direktmailing misst – sehr wahrscheinlich falsch. Physik ist hier hilfreich: schlagkräftig sein, Mathe-Skills aufbauen, besonders Lineare Algebra. Die ist für Data Science wohl noch wichtiger als Analysis. Ökonomie gab mir Theorie für Business-Probleme und ökonometrische Tools, um Theorie mit Daten zu konfrontieren. Software Engineering gab mir die Skills, Statistik in Code zu gießen. Überall lernst du dazu. Amazon lehrt eine erwachsene Problemsicht: Dringlichkeit, Wirkung – wie im PhD-Programm: Frag dich ständig, ob das, woran du arbeitest, dich zum Abschluss bringt. Wenn nicht, arbeitest du am Falschen.
Hugo: Du hast einen tollen Vortrag bei der Data Science Pop-Up Seattle gehalten: „Correctness in Data Science". Du hast darin typische Fehler benannt und Wege zur Professionalisierung aufgezeigt. Welche Hauptfehler siehst du heute?
Ben: Freut mich, dass er dir gefiel.
Hugo: Ich loved ihn – wir packen ihn in die Shownotes.
Ben: Cool. Ich hoffe, die Zuschauerinnen und Zuschauer mögen ihn. Modellkorrektheit ist extrem wichtig. Viele denken anfangs: Mein Code lief, ich habe eine Zahl – also stimmt sie. Stopp. Ist es die richtige Zahl? Es gibt dazu einen erkenntnistheoretischen Rahmen aus der Nuklearindustrie: Verifikation, Validierung und Unsicherheitsquantifizierung (VV & UQ). Ich bin Robert Rosner dankbar, meinem Postdoc-Betreuer und früheren Direktor von Argonne, dass er mir VV & UQ nahegebracht hat. Es gibt drei Teile: Verifikation prüft, ob dein Code das Modell korrekt implementiert – unabhängig davon, ob das Modell korrekt ist. Also Unit-Tests, synthetische Daten via Monte Carlo mit bekannten Parametern erzeugen und prüfen, ob du die erwarteten Ergebnisse bekommst. Validierung prüft die Wirklichkeitsnähe des Modells – Experimente nachschalten, um zu sehen, ob das Modell die Realität gut abbildet. Unsicherheitsquantifizierung betrachtet die Grenzen deines Modells: Welche Annahmen hast du gemacht? Halten sie? Was ist mit Schwarzen Schwänen? Solltest du einen Tsunami einplanen, der dein Kernkraftwerk trifft? Das sind Basics. Ich frage BI-Engineers gern im Interview: Woran erkennst du, dass dein SQL korrekt ist? Das wirkt oft wie eine schräge Frage. Aber SQL – oder womit du die Daten ziehst – ist kritisch. Wenn dein Datensatz Murks ist, rettet dich keine Statistik. Sei systematisch und prüfe beim Zusammenstellen: Join-Pläne, Tests auf Teilmengen, ob Aggregatstatistiken und Verteilungen Sinn ergeben. Prüfe Plausibilität – zum Beispiel keine 10% Hebel beim Direct Mailing. Und Modelle gehen in Produktion: Du brauchst Integrationstests oder andere Checks, damit das in Production dem entspricht, was in Research entwickelt wurde.
Data Science in der Produktion
Hugo: Wo sind Data Scientists bei der Produktionsreife verortet – früher bei dir oder jetzt bei Convoy?
Ben: Das variiert. Mancherorts machen Data Scientists reine Forschung und „werfen es über die Mauer" – Engineering macht dann Magie. Das ist heikel, da viel verloren geht. Viele Engineers sind nicht glücklich, wenn du ihnen R-Code gibst. Mit Python eher. Bei Convoy wollen wir, dass Data Scientists ihre Modelle Ende-zu-Ende verantworten und wir eine ML-Plattform haben, um Modelle zu deployen. Da sind wir noch nicht ganz, aber es ist für alle besser: Engineers rufen einfach den Dataservice auf. Organisatorisch arbeiten wir in Produktgruppen: Product Manager, ein oder mehrere Data Scientists und mehrere Engineers arbeiten eng zusammen. Unsere PMs sind super technisch – viele mit Master in Informatik oder gutem MBA – und alle können SQL. Ein PM hat eine Left-Outer-Join-Frage im Interview in 60 Sekunden gelöst. Das ist das Niveau hier: technisch, datenorientiert, Stats auf Bachelor-Niveau. Das macht sie zu Fürsprechern für saubere Data Science. Zusätzlich sorgen wir für horizontalen Austausch: Data-Science-Brown-Bags, technische 1:1s, in denen ich helfe, Blockaden zu lösen.
Hugo: Technische PMs können das Gespräch mit dir auch wirklich führen, oder?
Ben: Genau. Sie sind investiert in Datenarbeit. Schreiben sie einen Plan für ein neues Feature, arbeiten sie mit Data Science an einem Auswertungsplan, um Ideen zu verifizieren und zu validieren. Unser Chief Product Officer, Ziad Ismail, schreibt selbst SQL – bis spät nachts –, um das Geschäft zu verstehen. Er kennt unser Data Warehouse so gut wie kaum jemand.
Hugo: Du hast einen beeindruckenden Methodenkoffer. Was ist deine Lieblingstechnik?
Ben: Schwer zu sagen – wie die Frage nach dem Lieblingsvogel. Die britische Redewendung wäre: „How long is a piece of string?"
Hugo: Darauf gibt es keine Antwort.
Ben: Eben. Ich nutze am liebsten das passende Werkzeug. Aus meinem PhD bringe ich starke Paneldaten-Methoden mit – an der UCL gab es Leute wie Richard Blundell, die das Feld geprägt haben. Aber ich mag auch viele Kern-ML-Tools. Es hängt vom Problem ab. Am glücklichsten bin ich, wenn ich interessante Probleme löse – nicht wenn ich ein Tool benutze. Ich bin angewandter Wissenschaftler. Ich habe an Themen von Quantenkosmologie über Bioinformatik bis Trucking gearbeitet. Spannende Probleme sind entscheidend – und das richtige Werkzeug zu finden, ebenso.
Zukunft der Data Science
Hugo: Wir haben viel über moderne Data Science gesprochen. Wie sieht die Zukunft aus?
Ben: Wir leben in einer großartigen Zeit. Wer Mathe und Statistik kann, findet überall Daten. Es wird spannend – bis Elon Musk herausfindet, wie er uns alle überflüssig macht.
Hugo: Und bis dahin?
Ben: Tools werden einfache Modelle automatisieren. Man sieht Firmen, die Commodity-Churn-Modelle verkaufen. Das ist problematisch, weil Daten jedes Unternehmens einzigartig sind – da baust du besser dein eigenes Churn-Modell. Aber es wird mehr Standardmodelle und Automatisierung für Low-Hanging-Fruit geben. Für eine erfolgreiche Karriere solltest du die Wertschöpfungskette hinaufgehen – dorthin, wo Automatisierung nicht so leicht greift, etwa bei automatisiertem Feature Engineering. Bei einem früheren Unternehmen, Context Relevant, wurde Feature Engineering für viele Problemklassen stark automatisiert.
Hugo: Welche Kompetenzen sollten angehende und erfahrene Data Scientists ausbauen, um nicht automatisiert zu werden?
Ben: Du kannst nie genug Mathe können. Das ist eine langfristige Investition – und beginnt früh. Als ich bei Galvanize unterrichtet habe, konnte ich fehlende Programmierpraxis in acht Wochen aufholen – fehlende Mathematik nicht. Das sind Jahre. Also kontinuierlich in Mathe investieren. Danach: Kernalgorithmen beherrschen und weiter lesen. Viele hören in der Industrie auf zu lesen. Für Fortgeschrittene: Such dir eine Spezialisierung, die dich interessiert. Ich habe mich in den letzten Jahren stark mit Experimenten und Bayes beschäftigt. Viele gehen in Deep Learning – ein kompetitives Feld. Es gibt viele andere spannende Bereiche. Wenn du in Deep Learning willst – tu es. Aber etwas konträr zu denken, zahlt sich oft aus.
Call-to-Action
Hugo: Sehe ich auch so. Hast du einen abschließenden Appell an aufstrebende und etablierte Data Scientists?
Ben: Versteh, dass du dich für ein Leben des Lernens entscheidest. Es ist ein Marathon, kein Sprint – wie ein PhD. Takte dich. Das kann Jahre dauern. Investiere weiter. Vielleicht abends weniger Netflix und mehr relevante Bücher, Papers, Code, Modelle. Wenn dich Daten nicht begeistern, gibt es vielleicht einen Ort, an dem du glücklicher bist.
Hugo: Also: weiterlernen, weiterlesen, weiter machen.
Ben: Ja. Für mich – und viele in unserem Feld – ist Datenanalyse wie ein Agatha-Christie-Roman. Da ist ein Rätsel, das ich lösen will: War es Colonel Mustard im Wohnzimmer mit dem Kerzenleuchter?
Hugo: Fantastisch, Ben. Du lebst dein Data-Science-Leben als Detektivgeschichte.
Ben: So in etwa.
Hugo: Das kann ich gut nachempfinden – Daten geben immer weiter. Ein Kollege sagt: Du musst deinen Daten zuhören. Sie sprechen, solange du zuhörst.
Ben: Stimmt. Und zu den häufigen Fehlern: Viele springen zu schnell ins Modellieren, ohne EDA zu machen – Explorative Datenanalyse nach Tukey. Es lohnt sich, Zeit in EDA zu stecken – du findest Überraschungen. Als ich bei Convoy anfing, habe ich EDA gemacht und Bereinigungs- und Ausreißerprobleme entdeckt. Wir haben sie behoben und die Pricing-Performance um rund 10% verbessert – geschenkter Hebel.
Hugo: Sehr aufschlussreich. Es ist verlockend, sofort Modelle zu bauen. Ich ermutige immer, Daten auf 100 Arten zu visualisieren und Kennzahlen anzuschauen, bevor man loslegt.
Ben: Genau. Ich versuche, Studierenden einen methodischen, standardisierten Ansatz beizubringen. CRISP-DM ist da großartig – der Cross-Industry Standard Process for Data Mining. Für Data-Science-Projekte ist das der beste Workflow, den ich kenne. Geh die Schritte durch, damit du nichts vergisst: Verstehe das Businessproblem, verstehe die Daten, bereite sie auf, modelliere, evaluiere, deploye. Und spring zurück, wenn du Fehler entdeckst. Beim Modellieren merkst du vielleicht, dass dein Feature Engineering nicht passt – dann geh zurück. Systematik verhindert Doppelarbeit und Lücken. In puncto Korrektheit würde ich gern CRISP-DM mit VV & UQ verheiraten – dann bist du professionell und reif aufgestellt.
Hugo: Großartig. Das skizziert eine systematische Struktur für die Zukunft der Data Science.
Ben: Ja. Modellieren macht Spaß und liefert die Antwort – aber 80% der Arbeit liegen davor: Daten säubern, vorbereiten. Das Modellieren selbst ist schnell – zack, vorbei – und du bist wieder im Alltag. Ich erwarte mehr Tools, die die Pre-Modellierungsphase beschleunigen – da liegen die großen Produktivitätsgewinne. Investiere dort. Lerne UNIX, werde stark auf der Kommandozeile und nutze Tools und Plattformen, die dich schneller modellbereit machen.
Hugo: Genau. Ben, es war ein Vergnügen, dich in der Sendung zu haben.
Ben: Danke, Hugo. Es war mir eine Freude und ich wünsche der Show viel Erfolg.
Hugo: Danke.