Next Level SEA Audiences: Segmentierung für Google Ads mit BigQuery in der Google Cloud automatisieren
44:19
Data Analytics 0 Views

Next Level SEA Audiences: Segmentierung für Google Ads mit BigQuery in der Google Cloud automatisieren

Zusammenfassung

mohrstade zeigt, wie du mit BigQuery in der Google Cloud automatisiert Nutzer-Segmente für Google Ads erstellst – eine kostengünstige und flexible Alternative zu teuren Customer Data Platforms. Mit einem RFM-Modell (Recency, Frequency, Monetary) und Machine-Learning-Algorithmen lassen sich First-Party-Daten analysieren und Audiences für SEA optimieren.

Next Level SEA Audiences: Segmentierung für Google Ads mit BigQuery automatisieren

Die Ära der Third-Party-Cookies geht zu Ende – und mit ihr auch die einfachen Wege, Nutzer im Google-Ökosystem wiederzuerkennen und gezielt anzusprechen. Marketing Analytics wird daher immer wichtiger. Statt auf teure Customer Data Platforms oder ungewisse Lösungen wie die Google Privacy Sandbox zu setzen, zeigt mohrstade eine smarte Alternative: Segmentierung mit BigQuery in der Google Cloud. Der Vortrag erklärt, wie du deine Google-Analytics- und Google-Ads-Daten nutzt, um Nutzer automatisiert in sinnvolle Zielgruppen einzuteilen – schneller, kostengünstiger und flexibler.

Die alte Welt: Third-Party-Cookies und Remarketing

Lange Zeit war es einfach: Google und andere Ad-Plattformen setzten Third-Party-Cookies (sogenannte «Served-Party-Cookies»), um Nutzer über ihre Domain hinweg zu erkennen. Das Cookie enthielt einen eindeutigen Identifier – wenn ein Nutzer dann bei Google suchte, konnte das System diesen Cookie auslesen und entsprechend reagieren.

Das ermöglichte klassisches Retargeting, Gebotsanpassungen und präzises Targeting nach Nutzerverhalten (»Welches Produkt hat er sich angesehen?«). Allerdings war diese Methode nicht transparent, datenschutzrechtlich fragwürdig – und sie funktioniert heute in den meisten Browsern einfach nicht mehr.

Customer Data Platforms vs. Google Privacy Sandbox: Die bisherigen Lösungen

Der Markt hat auf den Cookie-Niedergang reagiert. Zwei Ansätze dominieren derzeit:

  • Customer Data Platforms (CDPs): Tools wie Tealium oder die Adobe Experience Platform versprechen umfangreiche Datenintegration, Segmentierung und Analyse – aber zu hohen Kosten (oft 6-stellige Lizenzgebühren) und langer Implementierungsdauer (6-12 Monate). Außerdem: Die Data-Science-Funktionalität ist begrenzt, echte Custom Analytics für dein Team sind kaum möglich.
  • Google Privacy Sandbox: Googles Alternative hat keine Lizenzkosten, aber auch kaum Analyse- oder Segmentierungsfunktionen. Der Status bleibt unklar, wann es aus der Beta kommt – und ob es sich überhaupt durchsetzt.

Beide Wege haben Nachteile. CDPs sind teuer und langsam, die Privacy Sandbox ist ungewiss.

Die intelligente Alternative: Cloud-basierte Segmentierung mit BigQuery

Hier kommt die Google Cloud Platform (oder AWS, Azure) ins Spiel. Der Vorteil: Du baust eine maßgeschneiderte Lösung, ohne teure Softwarelizenzen zu bezahlen.

  • Kosten: Pay-per-use-Modell statt sechs- oder siebenstellige Lizenzen. Du kannst klein starten und schrittweise wachsen.
  • Time-to-Market: Schneller zu ersten Ergebnissen. Du brauchst nicht sofort die «Mega-Lösung» zu implementieren, sondern kannst iterativ vorgehen.
  • Data Science: Deine Data Scientists arbeiten in einer ihnen bekannten Umgebung (Python Notebooks, SQL) und haben Zugriff auf skalierbare Rechenpower.
  • Datenintegration: Du verbindest nicht nur Web-Analytics und Google-Ads-Daten, sondern auch CRM, Transaktionssysteme und alles, was du hast.
  • Flexibilität: Das Setup passt sich deinem Business-Modell an – egal ob E-Commerce, Subscription oder B2B.

RFM-Modell: Der praktische Einstieg

Um konkret zu werden: mohrstade empfiehlt, mit einem klassischen RFM-Modell zu starten. RFM steht für:

  • Recency: Wie lange ist der letzte Kauf/die letzte Aktion her?
  • Frequency: Wie oft hat der Nutzer gekauft/interagiert?
  • Monetary: Wie viel Geld hat er ausgegeben?

Diese drei Dimensionen sind einfach zu erfassen und in BigQuery zu berechnen – jede E-Commerce-Plattform hat diese Daten. Danach kannst du schrittweise erweitern um Device-Type, Region, Engagement-Metriken oder alles andere, das für dein Geschäftsmodell relevant ist.

Cluster-Analyse: Nutzer intelligent gruppieren

Um Nutzer in Segmente zu packen, nutzt man Machine Learning-Algorithmen wie den K-Means-Algorithmus. Dieser findet ähnliche Nutzer und gruppiert sie automatisch – ohne dass du manuell Regeln schreiben musst.

Das Ergebnis: Automatisierte, datengetriebene Audiences, die sich in Google Ads importieren lassen und für Conversions und Retargeting nutzbar sind.

Vom Standard-Case zur Maßlösung

Der RFM-Start ist einfach und funktioniert schnell. Die eigentliche Wertschöpfung entsteht aber durch Anpassung an dein Geschäftsmodell:

  • Subscription-Services brauchen andere Segmentierungslogiken als klassischer E-Commerce.
  • B2B-Unternehmen fokussieren auf andere KPIs als D2C.
  • Du integrierst Daten aus CRM, Logistik, Support – alles, was dein Unternehmen weiß.

Das ist der Unterschied: Mit einer Cloud-Lösung kannst du klein starten, schnell lernen und dann iterativ verfeinern. Mit einer teuren CDP musst du die Mega-Lösung gleich von Anfang an durchdenken – das macht Innovation schwer und teuer.

Takeaways: Warum BigQuery statt CDP?

  • Kostengünstiger: Pay-per-use statt sechs- oder siebenstellige Lizenzen.
  • Schneller: Proof of Concept in Wochen, nicht Monaten.
  • Flexibler: Passt sich deinem Business an, nicht umgekehrt.
  • Control: Deine Data Scientists haben volle Kontrolle über Logik und Algorithmen.
  • Skalierbar: Du fängst klein an und wächst mit deinen Anforderungen.
  • Google Analytics-Daten sind bereits in BigQuery – lass sie arbeiten.

Die Botschaft: Du brauchst keine teure Customer Data Platform, um datengetriebenes Marketing zu machen. Die Google Cloud + BigQuery ist eine schlanke, intelligente Alternative, die dir mehr Kontrolle, schnellere Ergebnisse und niedrigere Kosten bringt. Besonders jetzt, wo Third-Party-Cookies weg sind und du auf First-Party-Data setzen musst, ist das der richtige Weg.

Häufige Fragen

Warum sollte ich BigQuery statt eine Customer Data Platform nutzen?

CDPs kosten oft 6-stellig und dauern 6-12 Monate zu implementieren. BigQuery kostet nur für das, was du nutzt (Pay-per-use), und du kannst in Wochen starten. Außerdem haben deine Data Scientists volle Kontrolle über die Logik und können mit bekannten Tools (Python, SQL) arbeiten.

Kann ich mit BigQuery auch Google-Ads-Audiences automatisch erstellen?

Ja. Du segmentierst deine Nutzer mit RFM oder anderen Kriterien in BigQuery, exportierst die Daten und importierst die Audiences in Google Ads – alles lässt sich automatisieren.

Was ist das RFM-Modell und warum ist es ein guter Start?

RFM = Recency (wie lange ist der letzte Kauf her), Frequency (wie oft kauft der Nutzer), Monetary (wie viel gibt er aus). Es ist einfach, jedes Unternehmen hat diese Daten, und es funktioniert sofort in BigQuery. Du kannst später weitere Dimensionen hinzufügen.

Funktioniert das auch ohne eigene Data Scientists?

Mit etwas SQL-Wissen und Standard-Algorithmen (K-Means) ja. Es gibt vorgefertigte BigQuery-Templates und Dokumentation. Aber um wirklich maßgeschneidert zu werden, helfen erfahrene Data Scientists oder Analytics-Teams, die SQL können.

Ist BigQuery eine Lösung für Third-Party-Cookie-Verlust?

Bedingt ja. BigQuery hilft dir, First-Party-Daten (Daten über deine eigenen Nutzer) zu nutzen und in sinnvolle Segmente zu packen – so kannst du weiterhin gezielt advertisen. Es ersetzt Cookies nicht, nutzt aber die Daten, die du hast.

Transkript Komplettes Gespräch zum Mitlesen & Durchsuchen

Hallo zusammen. Guten Morgen und viele Grüße nach München, ihr beiden. Wie geht es euch denn heute an diesem, ich hoffe, bei euch auch sonnigen Dienstagmorgen? Ich bin froh, dass es nicht so sonnig ist, weil er war so warm letztes Mal. Aber jetzt, heute ist es ein bisschen bewölkt da, deswegen ist es perfekt, dass wir nicht so während der Dreiviertelstunde hier ins Schwitzen kommen. Genau. Traumhaft. Bei uns war es gestern bewölkt. Heute ist es in Berlin wieder sehr sonnig. Ich glaube, irgendwie 29 Grad erreichen wir heute und wir schauen mal, wie warm es im Studio noch wird. Ihr beide, ich habe eine schöne Anekdote von der OMKB aus April aus Berlin. Das war ganz interessant. Ihr wisst ja, dass ich vornehmlich oben an der Main Stage war, weil ich da technisch eingebunden war. Und wir hatten morgens die zweite Session, wo auch die Parallel Stages gestartet sind und ich wunderte mich: „Mensch, auf der Mainstage ist gar nichts los oder verhältnismäßig wenig los. Und ich nahm mein Handy, telefonierte runter und fragte: „Hey, wo sind die ganzen Leute? Sind die irgendwie alle am Buffet oder laufen auf der Expo rum? Und dann wurde mir gesagt: „Nein, die Jungs vom Morschade hier auf der Second Stage, die machen hier die Hütte gerade voll. Da ist richtig, richtig Alarm. Das fand ich ziemlich beeindruckend und cool, weil das zeigt ja auch, wie wichtig, also A, war es schon immer wichtig, aber wie die Wahrnehmung von Data-Analytics-Themen oder Data-Thema allgemein noch stärker zugenommen hat. Könnt ihr das auch so bestätigen? Macht ihr immer die Hütte so voll? Ich hoffe, ich kann das bestätigen, weil das ist natürlich unser Geschäft. Grundsätzlich, der Bedarf steigt enorm. Es ist nie ein Problem von der Auftragsseite her und dem Interesse her, sondern es ist eher ein Problem, gute Leute zu finden, die das auch entsprechend umsetzen können. Ja, das umtreibt euch, glaube ich, auch. Ihr habt jetzt ja auch gerade bei uns über unseren Newsletter noch auf der Plattform gerade noch mal aufgerufen dazu, sich bei euch zu bewerben. An welchen Standorten kann ich denn bei euch arbeiten, wenn ich mich bewerbe? In München, in Hamburg oder in Wien. Ja, da ist doch für jeden etwas dabei, oder? Ansonsten, wenn er schon sehr seniorig ist und viel kann, dann ist es auch kein Problem, von überall zu arbeiten. Ja, sehr cool. Also alle Data Cruncher oder mit der Liebe für Daten jetzt bei euch bewerben. Sehr cool. Schön. Ihr habt einen richtig guten, coolen Vortrag mitgebracht. Ich habe das gelesen und ich kann das gar nicht so wiedergeben. Deswegen muss ich das mal vorlesen. Next Level SEA Audiences: Segmentierung für Google Ads mit Big Query in der Google Cloud automatisieren. Mensch, wie seid ihr denn auf den Titel gekommen? Das ist ja Gigalarm hoch hundert, oder? Ja, wir haben überlegt: Was kannst du denn mit SEA, Google Ads hauptsächlich, so Gutes machen? Und es gibt ja ganz viele neue Ideen im Markt: Customer Data Plattform sind da stark im Kommen und so weiter. Und dann haben wir überlegt: Was kann ich denn da eigentlich in der Cloud machen, mit den Google Ads Daten oder mit Google Analytics Daten, für Segmentierung? Und wie kann ich Nutzer vielleicht dann doch auch nach dieser Third-Party-Cookie-Era ein bisschen besser ansprechen? Und da gibt es coole Möglichkeiten in der Cloud und das wollten wir mal zusammen machen. Wir haben auch, glaube ich, nur fünf oder zehn Slides. Ja. Und darum gehen wir auch direkt mal ins Tool und schauen uns das an, wie man das zusammen machen kann. Also sehr hands-on, das Ganze. Also ich werde auf jeden Fall die ganze Zeit dabei bleiben. Ich bin mit einer eigenen Historie viele Jahre ... Also ich bin ab und zu auch immer noch in Google Ads Konten unterwegs, aber früher sehr viel stärker und deswegen freue ich mich ganz besonders auf eure Insights und gerade den Einblick ins Operative. Ihr sagt gerade wenig Slides, sondern richtig Power. Sehr, sehr cool. Dann würde ich sagen, übergebe ich das Zepter an euch und ihr übernehmt und wir sehen uns dann. Wie lange braucht ihr etwa? Eine halbe Stunde roundabout? Ungefähr, ja. Je nachdem. Ansonsten, ich weiß nicht, Fragen machen wir danach oder du kannst es auch gerne währenddessen unterbrechen. Das wäre auch kein Thema. Ja, ich manage das. Genau, ich kuratiere das und dann würde ich sagen, sehen wir uns im Anschluss wieder und gehen mal durch. So machen wir das. Perfekt. Sehr gut. Dann teile ich mal meine wenigen Slides, die wir haben. Gehen wir doch mal direkt rein. Das sollte jetzt auch jeder sehen, glaube ich. Perfekt. Genau, du hast es ja vorgestellt: Next Level SEA Audience. Segmentierung für Google Ads mit Google Big Query, also innerhalb der Google Cloud automatisieren. Was wir darunter verstehen, wird hoffentlich jetzt dann auf den nächsten paar Slides klar. Das ist so die gute alte Welt, die wir alle kennen und eigentlich auch immer super fanden, der alte wilde Westen. Wir hatten unsere Surparty Cookies, da hatten wir unsere Nutzeridentifikation und wir konnten eigentlich sehr schön Remarketing machen auf Basis von Informationen, ob ein Nutzer schon auf der Webseite war, welches Produkt er sich angesehen hat et cetera. Wie das Ganze funktioniert? Hier ein kurzes Beispiel: Da kommt auch meine Webseite, dann speichere ich einen „Served Party Cookie. „served Party Cookie heißt, dass er eben nicht von meiner eigenen Domain gesetzt wird, sondern von einer Dritten Dritten Domain. Und in dem Fall ist es zum Beispiel bei Google Ads natürlich google. De. Da unten sieht man auch so ein kleines Beispiel: Die Domain google. De setzt da eben einen Cookie mit einem entsprechenden Value und dieser Value ist der Identifier, anhand dessen Google den Nutzer wiedererkennen kann. Das heißt, wenn der Nutzer jetzt auf Google geht und irgendwas sucht, kann er diesen Cookie auslesen im Browser und-Dann geht die Information natürlich zum Google Server und dann kann Google Ads entsprechend reagieren. Dann kann ich Gebotsanpassungen machen. Dann kann ich vielleicht irgendwie sagen, der Nutzer war bei mir schon mal auf der Seite und deswegen biete ich für ihn mehr, weil er mir mehr wert ist. Darüber läuft dann aber auch Remarketing im Google-Universum etc. Und das hat natürlich super funktioniert, ist aber aktuell leider nicht mehr genauso umsetzbar, weil wir wissen alle, Third-Party-Cookies gibt es in den meisten Browsern einfach nicht mehr. Und jetzt ist natürlich am Markt richtig viel Aufruhr und natürlich auch einige Tools haben den Trend erkannt und gesagt, wir müssen darauf reagieren. Und jetzt habe ich hier mal zwei Alternativen, die eigentlich unfair sind, miteinander zu vergleichen, aber ich stelle sie trotzdem mal gegenüber, weil sie den gleichen Zweck verfolgen. Nämlich auf meine Habe ich eine Custom-Data-Plattform und die Google Privacy Sandbox. Und wenn ich die jetzt mal versuche, unfairerweise, zu vergleichen, dann sehe ich, ja, okay, eine Custom-Data-Plattform, da kann ich natürlich richtig viel analysieren und segmentieren. Bedeutet, ich analysiere meine Nutzer und stecke die in entsprechende Audiences, in Zielgruppen, die ich dann wieder zum Beispiel retargeten möchte oder irgendwie anders mit Marketing bespielen möchte. Das ist eine coole Sache. Warum ist der Daumen nicht ganz oben? Weil Data Science ist da immer noch so eine Blackbox. Es gibt da so ein paar Knöpfe, die man drücken kann in so Custom Data Plattformen, Kaufwascheinlichkeiten und so weiter. Aber ein großes Unternehmen möchte ja eigentlich schon auch mit seinen eigenen Data Scientists dort arbeiten in einer Umgebung, die sie kennen und das ist da leider noch nicht so möglich. Also wirklich auch in keiner. Sei es jetzt eine Adobe Experience Platform, sei es jetzt Tealium. Diese Funktion in dem Umfang gibt es noch nicht. Kann aber natürlich noch kommen. Trotzdem kann ich da viel machen. Was ich dafür machen kann, ist das Ding aber auch relativ teuer. Das heißt, die Kosten sind wirklich ziemlich hoch. Liegt auch daran, dass es ziemlich lange dauert, die einzuführen. Meine letzte Customer Data Platform, eigentlich führe ich sie immer noch ein. Das Projekt zieht sich jetzt auch schon wieder sieben Monate. Das heißt, das dauert sehr lange, weil es natürlich auch einen riesen Impact hat ins Unternehmen, sehr viel organisatorische Anforderungen, aber auch technisch gar nicht so trivial ist, weil ich sehr viele Datenquellen miteinander verbinden möchte. Das heißt, Time-to-Market ist relativ hoch und man lizensiert ja eben so ein Tool auch für viel Geld und möchte natürlich das dann auch relativ umfangreich von Anfang an implementieren, da ein Proof of Concept zu schaffen. Deswegen dauert das lange, aber ich kann natürlich sehr viele weitere Daten integrieren und spreche jetzt dann nicht nur von Webanalyse-Daten und nicht nur meinen Google-Ads-Daten, sondern ich kann meine CRM-Daten integrieren et cetera. Da sind super spannende Use Cases möglich, vielleicht auch mehr als in der Vergangenheit nur mit Solparty Cookies. Warum habe ich die Google Privacy Sandbox mit aufgenommen? Weil die genau ein ähnliches Ziel verfolgt, nämlich dass ich einfach meine Nutzer wieder in irgendeiner Art und Weise erkennen kann und auch bespielen kann. Aber ich habe natürlich keine Analyse-und Segmentierungsfunktion. Es gibt da jetzt auch keine Kosten. Time to Market kommt immer drauf an, wann Google denn mal das aus der Beta bringt. Ob es denn sich auch wirklich durchsetzt, weiß man auch noch nicht. Und natürlich kann ich da jetzt keine weiteren Daten integrieren. So, was habe ich denn also für Alternativen, wenn ich jetzt sage, ich habe die teure Customer Data Platform, die ziemlich lang dauert zu integrieren oder ich habe die Google Privacy Sandbox, auf die ich hoffentlich mal irgendwann setzen kann, wenn ich da mein Retargeting und Co. Entsprechend nutzen möchte in Zukunft. Ich habe natürlich immer die Möglichkeit, in einer performanten Cloud-Umgebung, sei es die Google Cloud Platform, sei es AWS, sei es Microsoft Azure et cetera. Ja, das tut mir leid, ich nenne da irgendwie immer nur amerikanische Firmen, aber so ist das leider. Da kann ich natürlich sehr viel machen und vor allem Analyse und Segmentierung, das, was ich bei der Custom Data Plattform bemängelt habe, dass ich da Data Science nicht so machen kann, da bin ich in der gewohnten Umgebung, da habe ich Price Notebooks, da können meine Data Scientists sich allem bedienen. Ich habe extrem starke, skalierbare Rechenpower und die Kosten können relativ gering sein, weil es ist natürlich Pay-per-use. Und das schreckt sich auch auf den Time-to-Market natürlich wieder, weil wenn ich erst mal klein starten kann, dann komme ich da viel schneller zu einem Ergebnis. Also ich muss nicht die gesamte Lösung über einer Custom Data Platform, wenn ich da, keine Ahnung, 300.000 Euro Lizenzkosten bezahle, dann möchte ich natürlich auch das Beste aus diesen 300.000 Euro rausholen. Bei einem individuellen Cloud-Setup, da kann ich auch erst mal klein starten und das ist auch ein schöner Vorteil, wenn man im Team, vielleicht im Analyse-oder im Online-Marketing-Team erst mal startet und dann weitere Daten integriert von anderen Abteilungen, vielleicht dann auch intern erst mal überzeugt, ob das Ganze funktioniert, da auch einen Proof of Concept schafft, da kann ich wirklich viel kosteneffizienter sein. Und ich kann natürlich, ich habe es schon gesagt, weitere Daten integrieren. Das ist die Cloud. Ich habe da Datenbanken Möglichkeiten ohne Ende. Natürlich kann ich dort alle meine Daten entsprechend integrieren, wenn sie nicht eh schon irgendwo in der Cloud sind und ich sie nur noch zusammenstecken muss. Jetzt habe ich lange darüber geredet, aber was wollen wir denn eigentlich machen mit dem individuellen Cloud-Setup? Wir wollen nämlich eine Cluster-Analyse machen, Nutzer zu segmentieren. Das heißt letztendlich einfach nur, wir wollen ähnliche Nutzer anhand ihrer Eigenschaften in Segmente packen. Dafür nutzen wir einen Algorithmus, der heißt K-means-Algorithmus. Den kennt vielleicht der eine oder andere noch aus dem Studium. Es gibt auch noch ein paar andere Single Linkage, wurde mir gesagt, wird auch gerne oft in der Praxis verwendet. Aber grundsätzlich versuchen wir.Lutz Nutzer anhand ihrer Eigenschaften ahm zu gruppieren. Das heißt, entweder geht es darum, ob ich sehr viele Ähnlichkeiten der Nutzer zusammenfinde, also diese Objekte oder große Unterschiede. Und da gibt es unterschiedliche Algorithmen, die das eben rausfinden können. Und beim K-Mins Algorithmus geht es über Ähnlichkeiten. Ahhhm Ich würde sagen, das skippen wir mal. Ich lasse es aber gerne in den Slides mit dabei, weil wir teilen die natürlich auch im Nachgang. Wir wollen jetzt erst mal einen ganz einfachen Einstieg, den vielleicht jeder, der Marketing Background hat, auch kennt. Wir brauchen ja erst mal irgendwelche Eigenschaften über unsere Nutzer und da haben wir uns gedacht, na schauen wir uns einfach mal aufs Geld. Ahhhm Wir bewerten mal unsere Website Online Shop Käufer hinsichtlich der Eigenschaften Monetary, Recency und Frequency. Das ist ein klassisches RFM Modell. In der Praxis sollte man das natürlich noch erweitern um ja, welches Device nutzt der? Aus welcher Region kommt der? Alle möglichen Daten, die ich habe, können da super wertvoll sein, aber die Daten hat wirklich jeder. Es sind relativ leicht zu erfassen und auch in BigQuery, wie wir es machen wollen, in der Google Cloud ahhhm zusammenzubauen. Genau, was wir hier machen, ist ja, wir starten mit einem Standard Case, aber das die große Wertschöpfung kommt ja dadurch, dass ich es meinem Geschäftsmodell anpassen kann, den Daten, die ich habe, ein Subscription Modell funktioniert anders als ein klassisches E Commerce Modell. Deswegen einfach starten und dann optimieren. Genau. Aber das einfache Modell ist nicht das, was wir empfehlen, sondern wir empfehlen natürlich, das dann irgendwann zu erweitern und größer zu denken. Aber wir zeigen hier einfach mal diesen technischen Workflow mhm innerhalb der Google Cloud, wie ich sowas aufbauen kann. Und das ist nämlich schönerweise gar nicht mehr so kompliziert wie vor noch ein paar Jahren. Aber was ist eigentlich RFM? Also Monetary, wie viel hat er bei mir ausgegeben in einem bestimmten Zeitraum, den ich betrachte? Recency, wann war der letzte Kauf und Frequency, wie häufig hat er gekauft? Das sind die ahhhm Eigenschaften, nach denen ich meine Nutzer jetzt ahhhm bewerten möchte und dann in unterschiedliche Segmente packen möchte. Das heißt, ich möchte ähnliche Nutzer in einem Segment haben, die einen ähnlichen monetary, frequency und recency Wert haben. Ganz genau. So, wenn wir das gemacht haben, das heißt, ich habe meine Daten, wir holen die aus Google Analytics vier in BigQuery und dann baue ich dann mit dem KMeans Algorithmus auf Basis der AFM Daten, auf Basis der Eigenschaften Recency, Frequency und Monetary User Segmente auf. So, keine Angst, wir machen das dann auch live. Ich wollte nur den Workflow zeigen. Dann haben wir irgendwie so ein Table im Big Query und da stehen meine gesamten Nutzer IDs drin und die entsprechenden Cluster. Jetzt ist die Frage natürlich, ahhhm wie bringe ich das denn an Google Ads? Das ist ja auch, was Customer Data Plattform so erfolgreich macht, dass sie da ganz viele Schnittstellen haben. Und da gibt es unterschiedliche Möglichkeiten. Wir gehen mal drei Beispiele durch. Eine einfache Möglichkeit wäre natürlich einfach, dass ich im Google Tag Manager oder in irgendeinem anderen Tag Management System im Tracking Code, also im Remarketing Tracking Code, das Cluster mit übergebe. Da ist nur die Frage, wie bringe ich das jetzt aus BigQuery quasi in den Tag Manager? Das ist relativ einfach. Ich kann ja im Tag Manager JavaScript nutzen und hole mir einfach meine User Pseudo ID bzw. meine Client ID und die sende ich dann einfach über eine Cloud Funktion an BigQuery, suche die raus und dann hole ich mir das entsprechende Cluster und feuer das gesamte Tag und sende die Information an Google Ads. Einfaches Beispiel, großer Nachteil, ich bin immer noch völlig abhängig von Third Party Cookies, also eigentlich hilft mir das nicht so richtig viel. Gibt aber tatsächlich, und da immer Vorsicht, es gibt Customer Data Plattformen, die genau das tun, was einem gar nicht so helfen könnte. Immer ein bisschen drauf achten. Beispiel zwei ist schon viel eleganter. Ich könnte einfach die entsprechenden Daten acht Google Ads hochladen. Wie ich das mache? Ich mache da, ich erstelle entsprechende Conversions innerhalb von Google Ads und ordne die dann entsprechend zu. Das werden wir auch einmal live zusammen testen. Und der dritte Weg ist natürlich, ja, ich kann auch die Daten an Google Analytics übermitteln, entweder per Measurement Protokoll oder per Upload und innerhalb von Google Analytics dann Segmente bilden und die in Google Ads nutzen. Das funktioniert auch wunderbar. Und dann last but not least, das geht immer, ich kann natürlich auch eine API direkt ansprechen, kann ich in der Cloud Funktion schreiben, schicke die Daten darüber und dann per API habe ich die Daten in Google Ads. So Markus, das war jetzt meine kurze Einführung. Ich hoffe es war ganz so kurz war es nicht, aber ich hoffe es geht. Das ist quasi die Theorie und wir schauen jetzt mal, wie wir das erstellen können. RFM machen wir zuerst, dann ahhhm kommen wir unsere, also kMeans, dann haben wir unsere Segmente und dann versuchen wir sie an Google ads zusammenzurücken. Genau, perfekt. Ansonsten, wer das mal probieren möchte und einfach im Start such, es gibt auch, ich hoffe du hast es in den Slides drin, wenn nicht, ergänzen wir das noch, einen Link zu einem GitLab, wo man sich das alles runterladen kann. Genau. So, jetzt share ich mal hier wieder. Jetzt sharest du mal das Video. Jetzt share ich mal meine. Wunderbar. Was haben wir gemacht? Wir haben hier so einen kleinen Demoshop uns mal aufgesetzt und haben da einfach Testprüfe durchgeführt. Machen wir schon ein bisschen länger. Und RFM, Recency, Frequency, Monetary. Also ich möchte wissen. Du hast es zum ersten Mal richtig ausgesprochen. Danke schön. Danke schön. Ja, ich war auch sehr stolz auf mich. (kichern) Also, da haben wir Google Analytics viel drauf und dann kann man Big Query Export. Wir können das natürlich auch mit allen anderen Tools machen, das heißt Adobe Analytics, Piano, was auch immer. Solange ich da irgendwie an die Rohdaten ein bisschen rankomme, kann ich genau dieses Prinzip ahhhm ja umsetzen. Und was machen wir? Wir haben jetzt hier wie gesagt Google Analytics implementiert, einfache Geschichte, ahhh und wir kriegen einen Export. Und jetzt wollen wir auf RFM zugreifen und dafür brauchen wir ein bisschen SQL. Wir machen das alles mit SQL, so dass das eigentlich innerhalb von drei, vier, fünf Zeilen Code mhm on demand laufen kann. Auch wenn jetzt jemand keinen SQL kann, ahhhm es gibt genügend Leute, die können das und die kann man engagieren dafür, dass sie.zwanzig Zeilen Code schreiben und dann hat man das schon. Also es ist nicht so kompliziert. Ansonsten, ihr könnt auch gerne Copy Paste machen, wir sharen, wie gesagt alle Codes. Genau, aber gehen wir einmal kurz durch. Wie holen wir das raus? Ähm, im Endeffekt, SQL ist jetzt nicht so kompliziert. Man schreibt da: „Was will ich haben?" Ne, Select. Ich nehme jetzt mal mein Event Timestamp, um R. R steht in dem Fall für Recency, also wann hat er dieses letzte Mal gekauft. Ich nehme mein Timestamp und meine User Pseudo ID. Meine User Pseudo ID ist in dem Fall der Identifier für den User. Jetzt habe ich vielleicht keine User ID wie eine E-Mail-Adresse da drin, weil Google namentlich vier E-Mail-Adressen und so geht ja nicht, aber ich habe einen Cookie-Wert. Das heißt, ich habe einen eindeutigen Wert. Wenn der User auf die Seite kommt, wird ein Cookie gesetzt und anhand diesem Wert, ähm, schaue ich mir das Ganze an und ich hole mir hier noch den Revenue raus, den ich an der Stelle noch gar nicht brauche, aber ist egal. Magst du mir nur ein Gefallen? Könntest du zeigen, was der User Pseudo ID eigentlich ist? Klar, kann ich gerne machen. Wenn Sie Google Analytics einsetzen, dann haben Sie das letztendlich beim GA-Cookie gespeichert. Genau. First-Party-Cookie wird nämlich von meiner eigenen Domain gesetzt und das ist der eindeutige Identifier, anhand dessen Google Analytics den Nutzer wiedererkennt. Und das ist im Big Ferry einfach nur die User-Pseudo-ID. Genau. Das heißt, wenn ich auf die Seite gehe und hoffentlich Content gegeben habe, dann wird der Cookie gesetzt und alle Informationen, die, äh, die mit diesem Wert gesendet werden, werden zu einem User zugeordnet und wenn sie innerhalb eines bestimmten Zeitfensters sind, dann natürlich auch einer Sitzung. Genau. Entschuldigung, ich wollte dich nicht unterbrechen. Nein, nein, wichtig, wichtige Info. Danke dir. Genau. Also, das heißt, ich hole mir erstmal alle Käufer raus und sage hier unten nur, wo mein Event Name Purchase ist. Ich führe das mal einfach so aus. Gehe mal hier auf Run und dann bekomme ich hier IDs, hoffentlich, das dauert. So, bekomme ich jetzt hier IDs. Das ist meine User Pseudo ID, die aus dem Cookie. Ich bekomme den Revenue, den der User mit bei diesem Kauf hatte und ich bekomme einen Event Timestamp hier, also ein eindeutiges, ja, ein Time Stamp, ne, eindeutige Zeiteingabe. So, wenn ich jetzt r haben möchte, brauche ich ja nur sagen: „Okay, gib mir mal meine User Pseudo ID, das ist das hier oben, und gib mir mal das Maximum von dem Time Stamp für diesen User. Damit habe ich den letzten Kauf. Der letzte Zeitpunkt des Purchases und dann möchte ich die User Pseudo ID haben und dann habe ich schon Recency. Genau. So einfach kann das mit SQL sein. Ähm, ich führe das hier noch mal kurz auf, um das zu zeigen. Ähm, aber im Endeffekt genau das muss ich machen. Was will ich haben? Unter welchen Bedingungen? Und möchte ich das vielleicht mit einem Minimum oder Maximum haben? Und damit habe ich jetzt für jede User Pseudo ID den Time Stamp meines letzten Kaufs. Genau. Also habe ich r. So, passt. Ähm, gehen wir noch mal ein Stückchen weiter runter. Ich habe hier noch mal f und m. Das mache ich mit einem Mal. Frequency Monetary. Wir wollen wissen, wie viel hat er insgesamt ausgegeben im Zeitraum und wie häufig hat er was gekauft? Genau. Und was muss ich dafür machen? Ich gehe natürlich hier auch-- Ich hole mir einfach den Revenue. Ich hole mir genau dasselbe wieder raus und sage, wo der Event name Purchase ist. Ich nehme genau wieder dieselbe Tabelle. Was brauche ich für Frequenzien? Ich zähle einfach die Anzahl der Käufe, die der User hatte. Ne, das machen wir hier unten. Ne, ich kaufe das-- Sag mir mal die Zeilen hier für Total Events und ich nehme hier einfach die Summe, monetary rauszubekommen. Einfach gesagt, Anzahl der Käufe, ich zähle monetary, ich nehme die Summe. Ja, also das sollte jeder können. Es ist nicht komplizierter als eine Excel-Formel, ne? Genau. Ja, also eigentlich nicht. Es ist auch, wie gesagt, man sieht das ja hier, sieht am Anfang ein bisschen komplexer aus, als es dann zum Schluss ist, aber mehr ist es ja dann auch nicht. Ah, was will ich haben? Minimum, Maximum. Und dann bin ich da eigentlich auch schon sehr weit. Und dann sind wir bei r, f und m. Das heißt, wir haben ein Table, sehen wir jetzt hier, r, also clv, ne, monetary, total events, eins, frequency. Jetzt muss ich die ganzen nur noch zusammenpacken. Ne, das heißt, wie gesagt, hier packen wir mal meine Table zusammen auf Basis meiner User Pseudo ID, weil das ist der Identifier für den User. Damit habe ich r, f und m zusammen. Und wenn ich das habe, dann mache ich hier mal so, bekomme ich einfach eine Tabelle- Die mir jetzt r, f und m. Die mir einfach erst mal als Eingabeformat liegt. R, F und M für jede User-Pseudo-ID, für jede kleinen id gibt. Genau. Nicht wundern, hier die Nummer, Entschuldigung, das ist falsch. Hier oben, die ein bisschen merkwürdig aussieht, das sind App-IDs. Nicht wundern. Ah, die sind dann noch mal ein bisschen anders aufgebaut. Ähm, App funktioniert nicht auf Basis von Cookies, sondern auf Basis der App-Instance-ID, ähm, die dann so aussieht. So, jetzt sollte ich r, f und m haben und meine User-Pseudo-ID. So, Recency, Frequency und meine kleinen IDs. Genau. Wenn ich jetzt nicht Google Analytics 4 einsetze, sondern ich setze was anderes ein, Adobe Analytics, äh, Matomo, whatever, dann ist der Weg zu dem Ding ein bisschen anders, aber die Logik ist gleich. Ne, das Datenformat unterscheidet sich nicht. Aber ab hier ist dann der Weg eigentlich relativ gleich. Weil was habe ich jetzt? Ähm, ich habe jetzt r, f und m und ich habe meine User-Pseudo-ID. Und jetzt, und dann kommt immer Big Query Machine Learning. Das gibt es natürlich auch in AWS und Azure und mit was man da immer arbeitet, aber Machine Learning ist es eigentlich nicht, weil es ist ein bisschen erweiterte Mathematik, ja, statistische Verfahren im Endeffekt, aber man haut halt immer so den Stempel Machine Learning drauf. Die werden es bestimmt auch bald AI nennen. Ja, ganz sicher, ganz sicher. (lacht) Aber jetzt passiert genau das. Jetzt baue ich ein Modell und sage: „Bitte kopier mir meine User anhand dieser Eigenschaften, und das geht relativ einfach. Ich habe das hier schon mal vorbereitet. So, jetzt machen wir das mit drei Zeilen Code. Wir sagen: „Kreiere mir bitte ein Modell." Ich mache Create oder Replace, damit ich nicht so viele Delle habe, und benenne das hier. Das ist einfach nur der Namen. Und jetzt gebe ich Optionen mit und sage: „Was ist meine Option?" Und Option, wir halten das mal einfach. Man kann das natürlich noch mit verschiedenen Parametern optimieren, aber was wir machen, ist, wir sagen K-means. K-means partitionieren das Verfahren. Also ich teile meine User in einzelne Cluster auf und K-means hat eine, ähm, eine-- Nachteil? Nein, eigentlich nicht ein Nachteil, sondern eine Eigenheit, sage ich jetzt mal. Ich muss am Anfang sagen, wie viele Cluster will ich denn bilden? Mhm.Ja, also man kann jetzt sagen, ich brauche fünf am Ende oder ich brauche drei am Ende. Und hier kommt dann wieder so ein bisschen das, was ich dann ein bisschen bemenge, wo ich sage: „Ja, ist schön, dass wir das alles in der Cloud haben, aber dann diese Zusatzfunktionen, die gibt es dann wieder nicht, nämlich die sogenannte Elbow Function, mit der ich die Anzahl der optimalen Cluster bestimmen kann. Das heißt, es gibt ein mathematisches Verfahren, mit dem ich sagen kann, ja, jeder Cluster mehr bringt einen Mehrwert oder nicht und irgendwann knickt das dann so ab und dann sage ich: „Okay, jetzt brauche ich keinen neuen mehr. Deswegen Elbow. Genau, Elbow. Hervorragend. Hervorragend, Patrick. Wunderbar, danke. Genau. Also ich muss vorher sagen, wie viele Cluster wir benutzen. In dem Fall nehme ich jetzt mal drei Cluster. Ich kann natürlich auch mal fünf Clustern. Wenn jetzt mathematisch rauskommt, dass ich mit 100 Clustern arbeiten sollte, macht das vielleicht auch nicht unbedingt businessmäßig Sinn, weil wer kann schon 100 Seher Audiences dann wieder so genau steuern? Das muss man natürlich wissen. Wenn ich jetzt sage, ich kann operativ fünf SEO-Audiences steuern, dann kann ich es ja mal probieren und einfach fünf Cluster erstellen mit kBs. Wir haben jetzt hier mal ein Beispiel mit drei. Genau. Und wir versuchen jetzt, unsere Nutzer anhand Frequency, Recency und Monetary in drei Buckets zu stecken, wo die innerhalb der Buckets sehr ähnlich zueinander sind, hinsichtlich der Eigenschaften. Genau. Und da muss ich natürlich jetzt sagen, wer sind die Daten, die ich da reinwerfe? Das sind die Daten, die wir gerade eben kreiert haben, nämlich R, F und M, wo wir sagen: „Werfe alles rein, außer unsere User-Pseudo-ID, weil die User-Pseudo-ID ist zwar ein Merkmal, aber das ist keines, was ich kopieren will, weil das ist ja einfach nur eine zufällig generierte Zahl, die in dem Cookie drin steht, sondern das ist ja jetzt erst mal ein Ding, das will ich raus haben. Ich will nicht, dass die User-Zorder in irgendeiner Art und Weise mit in meine Bewertung einfließt. Weil sie ist eh unique, anhand der möchte ich natürlich nicht clustern. Wir bauen jetzt quasi eine Funktion auf, auf Basis der Daten, die wir da haben. Genau. Und mit der können wir dann vorhersagen. So, jetzt machen wir das mal. So, das wird jetzt ungefähr eine Minute dauern. Was passiert jetzt? Wir bezahlen relativ viel Geld an Google. Das ist wahr. Also pro Terabyte kostet das 200 $, 250 $ Terabyte. Also wenn man einfach startet mit ein paar Gigabyte, kostet das nicht die Welt. Man sollte sich aber aware sein über das Preis vom Big Curve-Mäßigen. Aber was passiert jetzt? Im Prinzip werden jetzt diese Eigenschaften einfach nur an Skalen abgetragen und dann werden einfach – wir haben jetzt gesagt, drei Cluster – drei Zentren gesetzt und die werden so lange hin und her geschoben ... Es gab so eine Punktwolke, drei Zentren und dann waren die so lange hin und her geschoben, bis diese Zentren möglichst nah an diesen eigenen Punkten hinsichtlich der Eigenschaften, die sie in den Multifunktionalitäten liegen. So kann man sich das vorstellen. Und damit habe ich jedem Wert einem Zentrum zugeordnet und dieses Zentrum Zentren sollten sich schon unterscheiden. Und wenn das jetzt hier durch ist, jetzt sind wir hier bei einer Minute knapp, jetzt soll das vielleicht noch fünf Sekunden dauern oder zehn, aber dann können wir ja mal schauen, was für Zentren haben wir denn gefunden? There we go. So, there we go. Wir gehen mal hier zum Model und jetzt habe ich hier natürlich die Möglichkeit, ich kann hier natürlich in die Details rangehen und ich kann es optimieren, aber das, was wir eigentlich machen wollen, ist unter Evaluierung, weil hier sehe ich jetzt, was wurde welchem Zentrum zugeworden. Wir haben gesagt, drei Zentren. Die haben wir hier unten nämlich auch, unsere Zentrums-ID, die ist einfach eins, zwei, drei benannt. Aber Patrick, was sehen wir denn jetzt? Jetzt ist die Frage ... Also ich sehe jetzt natürlich erst mal drei Segmente und da wurden entsprechend viele Nutzer zugeordnet, hinsichtlich der Eigenschaften Frequency, Monetary und Recency. Und jetzt muss ich es natürlich mit einer Marketing-Sachlogik betrachten oder mit einer Business-Brille, weil da hilft mir der Algorithmus erst mal nichts. Also ich muss mir das jetzt anschauen und sage: „Okay, es ist eine gewisse Anzahl an Nutzern im Segment eins. Was beschreibt denn dieses Segment? Und dann sehe ich, die kaufen relativ selten. Frequency ist ziemlich gering, Monetary ist auch relativ gering, bedingt sich natürlich auch ein bisschen, aber es ist gar nicht so lange her, dass sie das letzte Mal gekauft haben. Sind vielleicht so ein bisschen Neukunden. Was haben wir denn da noch? Neukunden würde ich jetzt nicht sagen, weil 217 Tage. Ja. Aber Leute, die wenigstens im letzten Jahr gekauft haben. Bei unserem, bei unserem Produkt an, bei unseren Demodaten natürlich. Da habe ich jetzt irgendwie Cluster drei. Was haben wir denn hier? Die kaufen relativ häufig, geben natürlich super viel Geld aus, in der Zeit auch am meisten. Und es ist leider aber doch auch 404 Tage her, dass sie es jetzt mal gekauft haben. Genau. So, das hilft mir jetzt an sich erst mal noch nicht. Das heißt, ich muss natürlich mit einer Business-Logik draufschauen und mir dann überlegen: „Okay, wie will ich denn jetzt Cluster 1 und Cluster 2 und 3 unterschiedlich in meinem Marketing behandeln? Weil nur dann bringt mir das was, wenn ich die Segmente an Google Ads übermittel. Ich muss ja irgendwie darauf auf der Basis Anpassungen machen. Ich kann CPC-Adjustments machen, ich kann denen andere Textanzeigen ausspielen, ich kann andere Google-Shopping-Anzeigen schalten et cetera. Das kann ich natürlich alles tun, aber die Sachlogik muss trotzdem immer noch von mir als Marketer kommen. Da hilft mir der Algorithmus und Machine Learning, AI, bla bla bla, alles nichts. Ich muss das interpretieren und das ist eine Herausforderung und die ist natürlich vom Geschäftsmodell, vom Datensatz zu Datensatz immer unterschiedlich. Exakt. Genau. Wähle ich die an, mache ich eine Wirkgewinnung, schließe ich sie aus. Das sind dann einfach dann Sachen, die man über das Businessmodell adaptieren muss. Aber noch mal: Das heißt, nicht jeder User, den wir jetzt diesem Cluster zugeordnet haben, hat genau diese Eigenschaft, sondern das ist jetzt die Eigenschaft des Zentrums. Das bringt uns jetzt natürlich in dem Sinne erst mal noch nichts, weil jetzt müssen wir ja wissen, welcher User ist in welchem Zentrum. Also nutzen wir das Modell, um Vorhersagen zu treffen. Das können wir auch direkt im BigKermi machen. Wir nehmen jetzt einfach unsere Tabelle, die wir hier vorne hatten, also die hier, auf der wir auch das Modell aufgebaut haben und sagen ...Ja, machen wir jetzt doch fünf Zeilen Code. Dann gib mir bitte unsere Zentroid ID, also das, was wir gerade gesehen haben, ist ja Klasse eins, zwei oder drei, und unsere User Pseudo ID raus, mit, und dann nehmen wir hier die Funktion „predict. Das heißt, nimm das Modell und mach eine Vorhersage auf der Basis der Informationen, die wir gerade generiert haben, also auf Basis des RFM-Modells. Diesmal lassen wir die User-Pseudo-ID drin. Das Modell weiß, dass das nicht generiert werden muss, dass das nicht betrachtet werden muss, weil wir machen jetzt ein Prediction. Das Modell ist trainiert mit RF und M. Alles, was ich weiter noch rein schiebe, wird ignoriert ist dann aber als Output verfügbar. Das heißt, wenn ich das jetzt hier mache, läuft das Modell durch, nimmt die meine RFM-Daten und sagt mir, welche User ist mit welcher User-Pseudo-ID in welchem Cluster drin und ist damit eigentlich schon segmentiert. Das heißt, Sie haben jetzt den ersten Teil hier: User eins, zwei, drei, die sind jetzt irgendwo da drin. Jetzt weiß ich, der User hat ewig nicht gekauft, der User hat das nicht gemacht. Jetzt muss ich das Ding ja irgendwie zurückbringen. Und dann gibt es ja zwei Möglichkeiten. Erste Möglichkeit: Real-time-case. Also es gibt mehrere Möglichkeiten, wir zeigen zwei. Sorry, so wollte ich es formulieren. Real-time-case. Ich brauche die Information aus irgendeinem Grund direkt auf der Webseite in dem Moment, in dem der User draufkommt. Dann mache ich folgendes: Ich baue diese Tabelle, die ich jetzt habe, Cluster 1, User-Zorder, die generiere ich natürlich vor. Die mache ich jetzt nicht bei jeder Abfrage, aber ich stecke im Prinzip eine Information an BigQuery und sage: „Bitte gib mir für die User-Zorder, die in diesem Cookie drin ist, mal die Information, welcher Cluster ist das? Jetzt kann ich natürlich nicht von außen direkt auf BigQuery zugreifen. Deswegen nimmt man für sowas Cloud Functions. Ich gehe mal rein. Ich habe das hier mal ausprobiert. Das ist jetzt hier die, die im Prinzip folgendes macht. Die sagt: „Ich erwarte eine User-Pseudo-ID und ich gucke hier einfach mal in Big Query nach, was die User-Pseudo-ID für einen Cluster hat und werft das auf die Webseite zurück. Genau. Also User ist auf der Webseite. Ich schnappe mir die Client-ID, die User-Pseudo-ID aus dem Cookie, sende die an Big Query, suche die raus, er bringt mir das Cluster zurück und dann habe ich die Information in meinem Tag Manager. Genau. Und so eine Cloud Function hat natürlich auch einen Endpunkt, der öffentlich sein kann. Das heißt, ich kann da sagen: „Ja gut, ich authentifiziere mich und bitte liefer mir das zurück. Also brauche ich jetzt nur irgendeinen Tool, der sagt: „Wenn der User drauf kommt, lies mir mal die Cookie-ID aus, schick die mal dahin und liefer mir das zurück. Dafür nehmen wir mal ein Tech Management System, in unserem Fall Google Tech Manager. Und ich habe das hier mal implementiert. Im Tech, wie gesagt, das Ganze ist auch in dem GitLab verfügbar, aber im Endeffekt passiert nichts mehr, als dass diese Funktion hier angefragt wird mit dem Parameter CID. Ich habe das hier mal hart gecodet, dass wir der Teil der dynamisch sein muss. Das heißt, dieses JavaScript ruft letztendlich eigentlich nur eine URL auf, nämlich die des Endpoints von der Cloud Function und gibt als Get-Parameter – das hat der Markus jetzt markiert – diese CID einfach mit. Genau. Und jederman kann dann was in der Datenbank. Jeder, der den Google Tag Manager kennt, weiß, okay, das kann ich natürlich auch dynamisch machen. Das heißt, ich kann auch die CID entsprechend anpassen auf Basis des Cookie Identifiers und dann läuft das schon. Genau. Dann schicke ich es rüber. Genau. Dann schicke ich es rüber und wenn ich das Ergebnis habe, das funktioniert alles asynchron, dann muss ich jetzt die Seite nicht anhalten mit dem Laden und so. Wenn du das hast, schick es mir doch bitte zurück und schick es mir hier in den Data Layer, dataLayer. Push, sag hier, ich hätte gerne ein Event, das heißt Cluster. Oder als Cluster, gib mir einfach mal mein Feedback von der Datenbank zurück. So, und gucken wir uns das einmal an. Ich lade hier mal die Seite ... Ich mache das mal hier weg. Gut, ich lade mal die Seite neu und gucke mal, ob es denn noch connected ist. Super. Here we go. Und hier sehen wir jetzt, hier kam jetzt die Information Cluster. Das heißt, hier wurde jetzt Cluster ausgelöst. Das ist die Funktion, die wir gerade haben. Und wenn ich in die Data Layer reinschaue und ich schaue mal hier bei Cluster, dann sehen wir, dieser User ist in Cluster zwei. Offensichtlich in Cluster zwei. Und da kann ich jetzt sagen: „Oh, dieser Cluster zwei. Ich kann ihn natürlich auch noch nicht benennen. Das habe ich jetzt gespart. Aber was ich jetzt natürlich sagen kann, ist auch für Cluster zwei, da hätte ich jetzt gerne folgendes Pixel, Google Ads, Facebook, was auch immer, mit folgenden Werten, das dann im Interface zu segmentieren. Genau. Und ich schicke es auch. Die Information, dass der Nutzer mit der User-Pseudo-ID Cluster 2 ist und das gebe ich einfach an Google Ads mit und kann ihn dann irgendwie anders behandeln. Exakt. Oder ich meine, das ist natürlich ein Problem, oder nicht ein Problem, aber das ist natürlich ein Case, der ist real time. Das heißt, ich muss immer anfragen, ich muss immer das Ganze durchlaufen lassen. Das lohnt sich natürlich wirklich nur, wenn ich einen Real-Time-Use-Case auf der Seite habe, zum Beispiel Onsite-Optimierung. Wenn ich jetzt nur wissen will, boah, ich möchte jetzt-. Ob er ein Abo kündigt, zum Beispiel. Genau. Der ist in einem Segment, die kündigen wahrscheinlich in den nächsten zehn Tagen ihr Abo, dann will ich schnell reagieren, dann kann ich noch was machen. Exakt. Aber für die meisten Cases, zum Beispiel Wiederansprache von Usern über Google Ads oder auch über Facebook, brauche ich das ja fast gar nicht, weil da kann ich ja auch regelmäßig einfach meine Segmente updaten. Und was brauche ich dafür? Du hast ja vorhin schon gesagt, wir erstellen meine Conversion. Ich habe hier eine Conversion erstellt. Ich gehe hier mal rein. Conversions. Boah, das ist deutsch. Das ist alle nicht gekommen. Wir sind jetzt beim ... Das war der erste Weg, wo wir gesagt haben, der ist natürlich cool, aber hat auch seine Nachteile. Und jetzt machen wir den zweiten Weg. Wir laden es direkt nach Google Ads hoch, genau über den Umweg, dass wir Conversions pro Cluster erstellen und dann entsprechend die Daten hochladen. Genau. Und jetzt ist natürlich das Thema User-Pseudo-ID, Google-Klient-ID, die kann ich nicht nach Google Ads hochladen. Genau. Ich brauch die Google Click-ID. Das ist die ID, die quasi erstellt wird, sobald ein Nutzer bei mir auf meine Werbeanzeige klickt. Und die, ist das Tolles, habe ich natürlich auch im Big World. Exakt. Das heißt, ich brauche als erstes eine Conversion.Wo ich sage, da lade ich das hoch. Die will ich natürlich nicht mit anderen Conversions irgendwie vermixt haben. Da nehme ich halt eine, die bei Upload Conversion heißt. Die nenne ich dann halt Cluster eins, Cluster zwei, Cluster drei. Und dann kann ich natürlich hier meine Zielgruppenverwaltung geben, kann sagen: „Ich hätte gerne hier eine Zielgruppe basierend auf Webseitenbesucher zum Beispiel, basierend auf einem bestimmten Tag. Und da kann ich dann sagen: „Ja, ich Ich hätte gern das hier oder meinen Test-Tag. Solange das Google Reel-Marketing-Pixel drauf ist, connecten die. Aber wie kann ich es denn hochladen? Genau. Das heißt, ich kann hier natürlich hingehen. Brauche ich jetzt hier nicht. Ich gehe hier mal einmal zurück in meine Zielgruppenverwaltung. Und jetzt kann ich hier natürlich hingehen und kann sagen ... Nein, Zielgruppen. Entschuldigung, ich will ja nicht mein Zielgruppen. Ich will ja einen Conversion uploaden. Ich muss hier bei meinen Conversions rein Kann hier sagen, ich hätte gerne meine Conversions ab scribe. Und hier kann ich jetzt natürlich sagen, ich möchte die hochladen. Na komm. Was hat er denn heute wieder? Das Interface ist manchmal echt ein Traum. Aber hier kann ich Uploads machen. Was brauche ich für Uploads? Ich brauche eine Google Click ID. Ich muss wissen, welche Conversion das ist. Und ich brauche was wie Werte, dass das ein Euro war oder so. Was mir fehlt, ist jetzt mein Google Click ID. Die habe ich ja in meinem Analysesystem drin und die kann mich relativ einfach connecten, indem ich sage: „Ja, okay, gib mir bitte aus. Das ist das, was wir jetzt gerade eben hatten, ne? Cluster eins, zwei, drei. Bitte gib mir zurück. Was war denn der letzte? Was war denn die Google-Klick-ID vom letzten Besuch des Users? Ich will natürlich auch nur die letzte Google-Klick-ID, weil das ist natürlich die, die auch für den Google-Ads-Server relevant ist. Genau, hole mir die letzte Google-Klick-ID raus und connecte die mit dem Cluster, das hochgeladen wird. Genau. Dann habe ich eine Datenbasis, die ich dann nur noch hochladen muss, wo wir kleiden die Informationen. Jetzt sehen wir, ich habe ein bisschen getestet. Das sieht aber nach einer richtigen Google-Klick-ID aus. Ich habe hier einen Timestamp und ich habe hier den Cluster. So habe ich jetzt zusammen. Wichtig ist, ich kann die Uploads nur 90 Tage nach dem Klick durchführen. Danach ist die Client-ID nicht mehr bekannt. So, und mehr brauche ich jetzt eigentlich gar nicht. Jetzt kann ich das Ganze, ich kann das per HGP-API hochladen oder auch per Google Sheets. Und ich habe vorbereitet ... Wichtiger Punkt. Du kannst es nämlich natürlich automatisieren. Ich kann das irgendwie auf den FTP-Server legen et cetera und dann darauf zugreifen. Genau. Alles andere, ich will es ja nicht händisch hochladen, das würde mir ja irgendwie nichts bringen. Das kann ich natürlich automatisch machen, wenn ich einmal meine Marketingstrategie festgelegt habe für die unterschiedlichen Segmente, updatet sich das. Es geht sogar so einfach, dass man mit der Google-Tabelle arbeiten kann. Das wollte ich gerade zeigen. Würde ich halt sagen, ja. Ist für den Test okay, aber das ist automatisiert. Google Tablett ist auch noch was besser bei Excel. Google Tablett ist auch noch was besser bei Excel. Es ist natürlich- Ich finde es besser, aber es ist natürlich limitiert anhand der Daten, die ich da reinbringen kann. Aber Markus, ich glaube, wir müssten auch langsam ... Ja, ich bin fertig. Magst du noch den einen Case zeigen? Nein, ich bin mit dem Case fast durch und dann ist fein. Perfekt. Ich wollte nur kurz sagen ... Genau, also API geht natürlich, aber Google Ads, wie sieht das Ganze aus? Kann ihr natürlich Tabellen nutzen? Und ich habe mal hier das einfach vorbereitet, aus der Out of the Day Table einfach exportiert. Ich habe hier meine Google Click ID, ich habe meinen Conversion Name, den ich in Google Ads habe, den muss ich mit angeben. Meinen Timestamp, wann ich ihn haben will und dann mein Conversion Value, Conversion Curve, ist für uns relativ wurscht. Wichtig ist Timestamp, wichtig ist Conversion Name, wichtig ist die Google Click ID. Und wenn ich das habe, kann ich das hier direkt hochladen. Ich mache hier mal Google Tabelle verknüpfen und habe hier ... Wo habe ich das? Hier Google Ads Upload. Das war die Tabelle, die ich gerade gezeigt habe. Ich sage hier: Übernehmen. So, und jetzt werden die Daten hochgeladen. Ja, da funktioniert es. Wenn das verarbeitet ist, dann sagt er mir, wie viele Klick-IDs konnte ich nicht matchen? Wie viele sind jetzt ... Meine sind jetzt älter, deswegen würde er die nicht matchen können. Aber genau, und damit hätte ich dann meine Ziele Gruppe. Alright. Einfacher Start. Relativ simpel. Und damit wäre ich dann auch schon fertig, Patrick. Dann würde ich sagen, mach mal einfach deinen Bildschirm weg und wir hätten noch ein bisschen Zeit für Fragen. Genau. So, hier bin ich wieder. Ihr werdet bemerken, dass ihr mich wahrscheinlich nicht seht. Ist das korrekt? Genau. Ja, die Kamera. Wir haben heute einen interessanten Vormittag. Vielleicht für euch zur Info: Wir hatten heute Morgen schon eine DDoS-Attacke auf unseren Server, aus München identifiziert übrigens. Ich hoffe, ihr habt nicht zwischendurch noch andere Hobbys. Und jetzt gerade haben wir ein kleines Ein technisches Problem an der Kamera, da sind wir aber dran. Aber ihr hört mich ja sehr gut und ja, was soll ich sagen? Ihr habt nicht zu viel versprochen. Die Session war sehr nerdig, sehr deep, sehr hands-on. Also hat mir sehr, sehr viel Spaß gebracht, euch durch die Tools zu folgen und man merkt, dass ihr da auf jeden Fall eine große Passion für habt. Sehr, sehr cool. Ich habe die eine oder andere Frage gar nicht so tief hands-on rein. Ich glaube, da habt ihr die Leute echt ordentlich erschlagen. Allerdings kam die Frage: Ihr hattet gesagt, ihr stellt Codes zur Verfügung. Wie erhalten wir die am besten? Das machen wir über uns, die Session-Teilnehmer.Machen. Wir über UKW, genau. Genau. Traumhaft. Und vielleicht so ein bisschen anknüpfend. Also der eine oder andere scheint auch entdeckt zu haben, dass er da auch gerne tiefer abtauchen möchte. Könnt ihr Weiterbildungsangebote empfehlen, wie man sich selber im E-Learning-Segment vielleicht selber ein bisschen frisch machen kann in der ganzen Thematik? Ja, also auf YouTube gibt es natürlich einiges. Es gibt auch so Sachen wie Datacamp, wo man Python sehr spielerisch lernen kann und so weiter. Dann kann man auch gerne ... Markus hat noch so ein Nebenhobby, die Analytics Pioneers, wenn man das einmal zeigen kann. Die machen jeden Freitag so einen Online-Training, da kann man teilnehmen. Geht gerne auf analyticspioneers. De. Da kann man sich anmelden. Die sind natürlich auch kostenfrei, die sind sehr hands-on und da geht man auch durch die Tools durch. Also da gibt es viele Möglichkeiten, sich das selber beizubringen. Absolut. Okay, cool. Und ab welcher Größenordnung konsultiere ich euch? Gibt es da so eine Faustformel? Was sagt ihr, welche Kundenklientel habt ihr aktuell in eurem Portfolio? Also welchen Onlineshop beispielsweise? Sagt ihr da, ab einem gewissen Zeitpunkt macht es für mich Sinn, mit euch Vollprofis zu arbeiten?Es kommt immer drauf an, wie viel Expertise ich natürlich intern habe. Wir machen ja nicht nur diese advanceden Sachen, sondern es gibt natürlich auch mal Themen, einfach nur Tracking-Fehler zu beheben. Und sowas können wir natürlich auch unterstützen. Grundsätzlich, für alle Unternehmen, die digitale Plattformen haben, die wichtig sind für ihre Kunden und für ihr Geschäftsmodell, bedarf es ja irgendwie Daten. Und wenn da jemand Unterstützung braucht, sind wir, egal ob es die Fahrschule nebenan ist. Bis jetzt hat noch keiner angefragt, aber da wären wir relativ flexibel. Okay, also einfach bei euch melden auf den gängigen Kanälen über eure Website oder mal bei LinkedIn einfach anschreiben wahrscheinlich. Einfach mal melden. Cool. Eine Frage noch, eine organisatorische: Wird es die Session on demand geben? Die beantworte ich einfach mal stellvertretend für euch. Sowohl die Session jetzt von der virtuellen Summer Edition als auch die letzte Session aus April stellen wir oder haben schon on demand zur Verfügung gestellt. Ihr erhaltet dazu eine E-Mail von uns, auch sobald wir den Upload vollzogen haben. Das wird wahrscheinlich Ende der Woche sein und ihr könnt euch die Session in der vollen vierzig-minütigen Länge noch einmal bei uns gönnen. So, und das wäre es dann schon. Ich glaube, wir sind auch sehr gut in der Zeit, Dreiviertelstunde. Jungs, ich bedanke mich bei euch. Es hat große Freude bereitet und ich hoffe, es war nicht das letzte Mal und ihr werdet demnächst wieder einen schönen Nerd Talk bei uns halten. Alles klar. Sehr gerne. Dann vielleicht nächstes Mal auf der Mainstage. Ja, wer weiß. Im November ist es wieder soweit. Wir sprechen die Tage. Überleg es dir noch mal. Alles klar, vielen Dank. Schöne Grüße nach München. Ciao, ciao. Tschüss. Tschau.

Automatisch erstellt & redaktionell aufbereitet — kann vereinzelt Fehler enthalten.

<c
<a class="wpil_keyword_link" href="https://omkb.de/mohrstade-realtime-marketing-attribution/" title="mohrstade" data-wpil-keyword-link="linked">mohrstade</a>

<a class="wpil_keyword_link" href="https://omkb.de/mohrstade-realtime-marketing-attribution/" title="mohrstade" data-wpil-keyword-link="linked">mohrstade</a>

Im Video erwähnt

Tools & Agenturen aus diesem Talk — direkt im OMKI-Verzeichnis ansehen.

Beschreibung

Ihr möchtet eure Google-Ads-Zielgruppen-Segmentierung auf ein völlig neues Level bringen? Dann solltet ihr diese Session auf keinen Fall verpassen! Patrick und Marcus zeigen euch, welche Potenziale in der Rohdaten Analyse mit BigQuery stecken. Sie starten mit einem Überblick zu den wichtigsten statistischen Methoden zur Zielgruppen-Segmentierung (explorativ). Danach geht es ans Eingemachte: Die Zielgruppen werden direkt in Google BigQuery segmentiert und im Anschluss an GA und Google Ads übermittelt. Achtung: Geek Level - aber großes Uplift-Potenzial.

Themen in diesem Video

  • <a class="wpil_keyword_link" href="https://omkb.de/mohrstade-realtime-marketing-attribution/" title="mohrstade" data-wpil-keyword-link="linked"
  • mohrstade</a