Spezialfolge 155 –

Data Engineering mit Wessel van de Goor

02.08.2024

// Podcast
// Spezialfolge 155

Shownotes

Herzlich willkommen zu unseren Spezialfolgen zum Thema Business Intelligence, kurz BI. In diesen drei Folgen erhältst du Grundlagen und erlangst essenzielle Kenntnisse zum Thema BI, unterstützt durch unser aktuell dreiköpfiges Team von Lotum.

Im ersten Teil der Serie sprechen wir mit Wessel van de Goor über das Thema Data Engineering. Im Gespräch mit Dennis erklärt Wessel, wie wir bei Lotum Analytics-Daten in unseren Mobile Games erheben, sammeln und aggregieren.

In dieser Podcastfolge geht es um die Grenzen von Google Analytics, unsere Nutzung von Google Firebase und wir klären, wann welches dieser beiden Tools das bessere Werkzeug ist. Außerdem diskutieren wir, ob und warum es sich lohnen könnte, eine komplett selbst gebaute Analytics-Toolchain zu verwenden und wann eher nicht.

Du bist neugierig auf mehr Insights zum Thema Business Intelligence? Unter https://programmier.bar erwarten dich weitere Episoden.

Gemeinsam mit Wessel, Tobias und Fabian die Datenmengen von Lotums Spielen auszuwerten, klingt für dich nach einer spannenden Mission? Dann hör dir auch die Spezialfolge zu Lotums Stellenausschreibung im Analytics Engineering an und erfahre mehr auf lotum.com/bi

Download

/transkript/programmierbar/spezialfolge-155-data-engineering-mit-wessel-van-de-goor

Dennis: Hallo und herzlich willkommen zu einem kleinen Programmierer Special. Und zwar reden wir über Business Intelligence. Wie kann man sagen, so die Business Intelligence Essentials, über die wir jetzt uns ein bisschen unterhalten werden und dafür habe ich gleich 3 Leute neben mir sitzen. Ich bin Dennis, mich kennt ihr, aus anderen programmier.bar Folgen. Heute habe ich aber 3 Kolleginnen aus der Lotum Welt dazu eingeladen, die unser Business Intelligence Team ausmachen. Und wir werden das Ganze son bisschen als Minifolge veröffentlichen, das heißt 3 unterschiedliche Folgen zu 3 unterschiedlichen Schwerpunkt Das heißt, 3 unterschiedliche Folgen zu 3 unterschiedlichen Schwerpunkten dieses Themas haben. Sitzen trotzdem jetzt hier alle in einem Raum zusammen, haben aber für jeden einmal ein bisschen ein Special. Trotzdem möchte ich euch allen einmal guten Morgen sagen. Fabian ist da. Guten Morgen Dennis. Wir haben den Wessel.
Wessel: Guten Morgen Dennis.
Dennis: Und Tobi ist am Start. Guten Morgen. So. Und ja, wir haben einfach intern son bisschen überlegt, dass das ist, dass wir das noch gar nicht so in unserem Podcast hatten. Wir hatten in der Frühjahr ganz viel, was wir so aus internem, ne, Wissen irgendwie geteilt haben und mittlerweile laden wir viele Gäste ein. Und Business Intelligence ist sicher ein Thema, was auch über die Jahre immer größer geworden ist in in in unserem Hintergrund, also bei Lotum. Und vielleicht da noch mal ganz kurz als Kontext, weil das ja sonst auch immer 'n bisschen außerhalb der programmier.bar steht. Lotum ist son bisschen das, was die programmier.bar vorantreibt. Das ist ein Spieleentwicklungsstudio im Norden von Frankfurt, Bad Nauheim. Wir entwickeln Mobile Games jetzt seit 2012, weltweit so für Sind wir jetzt bei 900000000 Downloads ungefähr, also durchaus eine Hausnummer mit einigen, ja, Millionen, die im Monat unsere Produkte nutzen. Von daher, da hört man schon eine gewisse Skalierung und mit Sicherheit auch 'n bisschen was, was mit Daten zu tun hat. Und ja, darum soll es auch in dieser Folge son bisschen oder in diesen 3 Folgen gehen. Was ist eigentlich mit diesen ganzen Daten? Und wozu brauchen wir die zum einen? Und wie machen wir das technisch, dass wir damit was anfangen können? Ich glaub, man kann grundsätzlich so sagen, ich glaub, das ist in ganz vielen Unternehmen heute, dass es sich das in die Richtung entwickelt, ne, dass man immer mehr Daten hat und aber irgendwie natürlich auch irgendwas mit diesen Daten machen muss, damit man dann 'n Mehrwert draus hat. Aber das heißt, in ganz, ganz vielen Unternehmen, das ist dann nicht nur auf die Gaming Branche, sondern in in ganz ja unterschiedlichsten Branchen braucht man dieses Wissen. Und von daher ist es immer noch 'n Bereich, der glaube ich auch noch deutlich größer wird und immer, genau, da ist. Wir natürlich als als Spieleunternehmen sind sehr interessiert daran so, was machen unsere User? Wie können wir unsere Spiele verbessern? Wie ja, können wir überhaupt sagen, ob ein Feature gut ist oder nicht gut ist? Was braucht man da irgendwie zur Einschätzung dessen? Weil das eine ist natürlich irgendwie, ja, am Ende hat man eine Downloadzahl, aber diese eine Downloadzahl ist halt doch noch sehr wenig an an Daten, wenn man sieht, was es sonst noch alles dort gibt. Die 3 Teile, die wir uns vorgestellt haben, so der erste Part soll ein bisschen darum gehen, wie kommen überhaupt, also wo kommen die Daten her? Wo speichern wir die Daten? Was was machen wir? Also wie behalten wir die? Glaubt so in in eurem Wording ist es Data Engineering vor allen Dingen, was dort viel, genutzt wird. Im zweiten Teil, den wir veröffentlichen, soll es Data Analytics gehen. Da finde ich, steckt es schon relativ schön im Namen so Analytics. Also es geht das Analysieren der Daten, wie kann man mit den ganzen Daten, die da rumliegen, irgendwie was machen? Und im im letzten Teil wollen wir dann nicht nur gucken, okay, was war irgendwie, also was was was können wir auswerten, sondern 'n bisschen uns vortasten auch in die Richtung, okay, was kann man denn auch für die Zukunft vielleicht vorhersagen mit Daten, die man schon hat? Also das alles, was unter Predictive Analytics zusammengefasst ist. Boah, das war aber ein langes Intro, das ich hier alleine machen musste. Von daher nehmen wir lieber schnell einen dazu, Wessel. Bevor wir direkt ins Thema einsteigen, magst Du ganz kurz, wie wie würdest Du deine Rolle erstens offiziell beschreiben von von es gibt ja, glaube ich, so ein bisschen unterschiedliche Bezeichnungen im Bereich Business Intelligence, das ist die erste Frage und wie
Wessel: Analytics Engineer. Ich sorge dafür, dass die Daten aus dem Spieler vorbereitet werden, damit man die analysieren kann, aber auch das Analysiere mache ich. Und wie bin ich eigentlich dazugekommen zu dieser, ja, Rolle? Ist eigentlich 'n bisschen längere Geschichte. Ich fass mal ganz kurz zusammen. Ich hab hier vorher als Werkstudent ja bei ein anderer Unternehmen gearbeitet, ging's über Marketingdaten, die ja, das wollte ich da Ich musste das immer mal mit Excel analysieren, hab das danach versucht, immer zu automatisieren, weil ich halt im Studium Computer Science, also Informatik studiert habe, das versucht zu automatisieren, damit man das einfach analysieren kann und ja genau dann danach, weil ich auch schon spielaffin bin, schon 'n bisschen die Richtung ein ein Job gesucht und dann komme ich bei Lotum. Und da bin ich auch seit 4 Jahre jetzt.
Dennis: Darf man deinen vorherigen Arbeitgeber nennen?
Wessel: Ja, dass sie Emma und Matratzen geben, ja, darf man.
Dennis: Darf man. Und da kann man nämlich auch direkt 'n Link noch machen, dass wir auch einen CDO Special hatten mit dem, ich denke, damaligen CDO oder ist er noch CTO? Weiß ich gar nicht, oder nee?
Wessel: Ich glaube, der ist immer noch CTO.
Dennis: Ja, schon. Müssen wir noch mal nachgucken. Ich hatte gerade irgendwie kurz im Kopf, was das, aber das stimmt nicht. Ja, dürfte noch so sein. Genau, ein CTO Special dort aufgenommen. Also in unserem Kontext, aber das ist ja wahrscheinlich irgendwie ähnlich, man hat irgendwie 'n Produkt da draußen und Nutzer*innen benutzen das, klicken darauf rum, tappen darauf rum und da entstehen Daten. So, in unseren Spielen, ja, kann man irgendwie sehen, okay, da wird eine eine Runde gespielt oder es wird ein Spiel gewonnen. Wie wie wie kommen diese Daten dann erst mal irgendwie generell zu uns? Was gibt's dafür?
Wessel: Also im Generellen gibt's immer sone SDK, was halt ein bisschen mehr Features bringt als nur das Tracking der Daten. Das heißt, wir haben bei uns in den Spielen Firebase integriert. Das ist ein SDK, woran man schicken kann von, hey, wir haben hier eine bestimmte Nutzer mit 'ner bestimmten ID und er hat hier diese bestimmte Interaktion ausgeführt. Und dann haben wir auch noch 'n paar so, das ist sind halt Daten auf ja Touchebene oder auf so Interaktionsebene. Son SDK sorgt auch dafür, dass wir sagen können, ah, das ist diese Nutzer und von ihm wissen wir, der hat zum Beispiel bei 1 von unsere Spiele, der hat so viele Münze oder der ist halt so lange dabei. Das managt das SDK auch, dass die Daten immer auch mit verschickt werden. Das ist dann das Firebase SDK, das ist eigentlich Google Analytics Und ja, Du verschickt das dann an diese Google Analytics Property, was dann wieder die Verbindung macht mit unserer Datenbank oder Data Warehouse Data Lake, wie man das nennen wir uns ist also am Anfang 'n Lake. Wir bekommen ja telemetrische Daten nennen nennt man das so, halt pro eine Zeile pro Interaktion, die ein Nutzer mit der App hat. Aber wie Du weißt, Dennis Du weißt auch Gamelead. Was willst Du eigentlich mit den Daten machen, ne? Und zum Beispiel man will nicht nur gucken, okay, ja, wie oft wird ein nur ein Button geklickt? Nein, man will 'n bisschen mehr Informationen da drüber wissen.
Dennis: Kannst Du ganz kurz noch mal, weil Du jetzt meintest, okay, wir haben Firebase und Google Analytics ist noch als Begriff gefallen so, Gäbe es auch ein Google Analytics SDK, was man alternativ anbieten kann oder ist das praktisch Googles Lösung, in Mobile Apps irgendwas zu tracken, dass man dann Firebase nimmt und es landet einfach nur in einem Tool, was sich Google Analytics nennt?
Wessel: Genau, Far Base Anal ist eigentlich Synonym für Google Analytics. Google Analytics, glaub ich, eher auch die bei Webtracking, dass man da dann Google Analytics einbindet, dann bildet man dann ein, braucht man auch kein SDK, sondern ein Pixel meistens oder halt Google Tag Manager, da verschiedene Events zu tracken. Eigentlich ist auch nur eine, also benutze das alles, wenn ich nicht ihre G Tag, was dann wieder ja das Google Tag ist und File Base Analytics dann oder dieses drum. Okay.
Dennis: Das heißt, egal ob jetzt Webseite oder App, die die Art von Daten, wie die wie die aussehen, ist immer ist relativ ähnlich.
Wessel: Das ist relativ ähnlich, aber bei die, also dann SDK bringt auch noch 'n bisschen mehr mit. Ich sag zum Beispiel bei bei bei Native, also bei uns bei mobile Apps, sagt ihr auch zum Beispiel, ah, das ist diese OS, also zum Beispiel iOS oder Android, das ist diese Version, das ist diese Mobil also Handytyp. Und die gibt da son bisschen mehr Metadaten über halt, was für Devices ist. Mhm. Und beim Web ist es eher 'n bisschen mehr gekapselt und ja, bekommen die die Daten, deswegen nicht. Okay.
Dennis: Und das ist standardmäßig, wenn man dann das das SDK nutzt, könnte man so was auch abschalten und da hätte man für irgend, also gibt's irgendwelche Fälle, wo man so sagt, das will man nicht haben oder ist das einfach, keine Ahnung, Betriebssystem und so was ist standardmäßig dabei?
Wessel: Ach, Du meinst, bestimmte so Informationen, die man nicht haben will? Eigentlich, was das SDK dann verschickt an Google Analytics, könnte man nicht einstellen, soweit ich weiß und sonst gibt es immer noch, wie ich vorher erwähnt hab, die Verbindung zwischen Google Analytics und unserem Big Query. Da können wir schon ein bisschen mehr limitieren. Man kann auch innerhalb Google Analytics in der Oberfläche limitieren, was man also Dimensionen. Ich weiß nicht direkt, ob man die Standarddimensionen deleten kann, aber da hat man so mehr Einfluss als in der Schritt von, hey, vom User Device geht es an Google Analytics über diese dieses SDK.
Dennis: Ja, und dann hast Du noch 'n Begriff genannt, Data Lake. Ja. Das ist sinnbildlich, also tatsächlich einfach so, wo erst mal die Daten ruhig liegen, also sehe, denk ich mal, das ist
Wessel: Nee, also das ist eher, dass es unstrukturiert da reingeschrieben wird. Mhm. Dass man das erst mal hat. Und ja, bei uns sind die auch nicht so unstrukturiert, würde ich sagen. Die sind schon in immer, also das wird geschrieben von Analytics in Bayquery, das hat schon eine bestimmte Struktur, aber die das die Daten, die sagen, die haben noch nicht viel Bezug zum Beispiel auf zum Beispiel die Nutzer, die wäre nicht richtig erkannt oder so. Wir müssen die noch quasi enricken. Also wir müssen da noch ein paar Daten, die wir dann haben, ja, darauf addieren oder damit kombinieren oder halt die Daten, die die uns liefern müssen wir aggregieren, damit wir oder 'n bisschen ja Transformer heißt das dann, damit wir da auch ja strukturierte, feste Werte daraus lesen können, wie zum Beispiel wie viele Nutzer wir haben, weil es gibt dann wieder bei Farbase Analytics gibt's mehrere Arten von Nutzer, Nutzer zu tracken, also. Oder vielleicht nicht Arten, aber mehrere Kennen Werte von, hey, das ist ein Nutzer.
Dennis: Mhm.
Wessel: Ja, weil da war auch, Du hast gemeint, hey, gibt's da 'n Unterschied zwischen ja, Fiebase Analytics Mobile Apps und Websites und da gibt's auch zum Beispiel, dass Fiebase Analytics immer versucht, hey, das ist die gleiche Nutzer, aber im Web machen wir das eher über eine Cookie. Mhm. Und wenn halt dein Fiebase App, also die Website halt in eine iframe oder so läuft und dann immer eine neue Cookie gesetzt wird, dann erkennt der halt nicht, hey, das ist der gleiche Nutzer.
Dennis: Okay.
Wessel: Und bei Mobile wär es dann eher Richtung der Deficer Identifiers.
Dennis: Okay. Und dann muss man noch mal kurz erklären, weil Du Big Query genannt hast, also wer Big Query nicht kennt, ist letztendlich einfach eine Art von Datenbank, wo man irgendwie Daten reinschreiben kann. Warum überhaupt der Schritt? Also ist nicht Google Analytics ein Tool, wo ich mir irgendwie Daten analysieren kann und angucken kann und da laufen die schon rein und dann dann hab ich schon was?
Wessel: Ja, das ist eine kätschüre Frage. Natürlich kann man da Sachen analysieren und natürlich kann man da schön so Ansagen Events zum Beispiel Ansagen drücke auf eine auf eine Knopf pro Land anzeigen lassen. Das Ding ist, wie ich vorher aber erwähnt hab, man muss manchmal die Daten noch 'n bisschen mehr transformieren, 'n bisschen Informationen hinzufügen. Und auch bei dieser Nutzererkennung, ich hab vorher erwähnt, okay, Farbase, die gibt halt eine Nutzer eine ID anhand von 'ner Cookie, aber wir als Spiel wissen auch, wenn der eingeloggt ist, hey, das ist der ID. Und wenn wir wissen, ah, der Nutzer, der Cookie a hatte, hatte ID 1 und den Nutzer mit Cookie b hatte auch ID 1, dann ist der gleiche Nutzer. Und das müssen wir dann auch bei uns irgendwie so ja aggregieren und sagen, das ist nur ein Nutzer. Wenn man das analysiert, aber in der Fibis ja Umgebung oder Google Analytics Umgebung würde das dann wieder als ja als 2 Nutzer angezeigt. Und wir wollen halt auch mehr auf Nutzerebene zum Beispiel sehen, also die Google Analytics Oberfläche, die bietet da eher sone grobe Status quo und hey, im Allgemeinen Anzahl an Events. Aber man kann da nicht so komplexere Verbindungen zwischen Daten zum Beispiel analysieren oder innerhalb 'ner Session oder ja, von einem Nutzer Session übergreifend.
Dennis: Hast Du eine Einschätzung, ab welchem, ist wahrscheinlich schwer zu definieren, aber so ab ab welchem Status man als, weiß nicht, als Unternehmen oder wenn Du irgendein neues Projekt baust oder so was, wo Du so sagst, so erst mal reicht vielleicht Google Analytics wahrscheinlich auch noch für irgendwie Use Cases und wo ist so der Knackpunkt, wo man dann sagt, da braucht man dann noch irgendwas Eigenes dahinter? Oder würdest Du sagen, wenn man's wenn man BI ernst nimmt, Ja, das muss man eigentlich direkt irgendwas anderes machen?
Wessel: Das ist halt das Ding. Wenn ich was starten würde, würde das für mich auch das Interessante sein. Also man hat keinen wirklichen Zugriff in Google Analytics auf die Rohdaten, also es gibt schon eine API, wenn kann die Daten ziehen und jetzt bei, also Google Analytics 4 gibt's jetzt, gibt's eine, ich glaub eben noch eine Beta API. Aber man will halt die Rohdaten halt haben, damit man da auch ja coolere oder halt einflussvollere Analyse machen kann. Mhm. Allerdings, wenn man nicht so ein Thema ist und wenn man einfach nur da eine Knopf grün oder blau machen will, also Standard Test, lass mal sagen oder Standardauswertung, dann reicht das komplett aus. Also es hängt ein bisschen von von deinen Skills oder Interesse überhaupt ab, Zeit, die Du reinsenken willst, weil Google Analytics ist ein mächtiges Tool, klar. Hat aber sein Leute, die ja, wie Du gemeint hast, BIANs nehmen, wollen dann schon gerne doch lieber auf den Rohdaten gehen.
Dennis: Okay. Und vor
Wessel: allem auch in Kombination, wenn Du halt andere, also Marketingcompinee, okay, Google Ads kann man verbinden, aber wenn man andere Companion, zum Beispiel E-Mail-Compania hat, dann will man trotzdem die Nutzer verbinden können von verschiedenen Datenquellen.
Dennis: Und dass wir jetzt Google Analytics beziehungsweise Firebase nutzen, ist das historisch, weil wir viel in Mobile Games Firebase genutzt haben und von daher irgendwann mal die Gameteams entschieden haben, das zu tun? Oder gibt's direkt Alternativen? Ist das der Platz Search? Echt, glaube ich,
Wessel: kann ich perfekt die Frage zurückstellen. Das war früher, als ich als ich bin seit 4 Jahren bei Load und wir hatten 'n Farebase Analytics bei Feel Bilder ein Wort und dann haben wir das ja letztendlich auch auf alle Spieler so mitgezogen, weil wir bemerkt haben, okay, das ist, wir hatten nicht immer die Rohdaten und jetzt haben wir so BI 'n bisschen mehr, ich war so quasi am Anfang vom BI Team, haben das mehr 1 genommen und jetzt wollten wir die Rohdaten und der damaliges Solution hat's halt nicht geboten. Haben wir dann also Firebase Analytics. Und warum Firebase statt ja eine andere Service? Das Gibt's irgendwelche, sagen
Dennis: wir mal, in eurem BI Space gibt es irgendwelche, also ich glaub, Google Analytics haben ganz viele mal gehört, ne, weil's auch aus dem Web kommt und man kann da irgendwie zu relaten. Gibt es andere große Player, wo man so sagt, die erst mal nur fürs Daten sammeln irgendwie SDKs haben und im Web und Mobile unterwegs sind?
Wessel: Ja, gibt's schon einige.
Dennis: Aber die willst Du nicht nennen?
Wessel: Ich bekomm hier keine Kommissionen oder so, deswegen nenne ich hier nix. Mir gerne eine E-Mail schicken. Nein, aber also im Allgemeinen, das Ding ist auch, es ist halt nicht Googles Hauptprodukt. Mhm. Merkt man, indem der Support nicht so cool ist, aber es ist umsonst. Und das ist auch eigentlich das große Ding von halt Google Analytics, es ist umsonst. Mhm. Meister andere, also nicht alle, aber Meister andere Track Insolations, die kommen halt mit 'nem ziemlich hohen Buy halt, dass man wirklich erst ab ja so viel Euro
Dennis: pro Monat da es benutzen kann, darf. Wieso ihr trotzdem schafft, hohe Rechnungen für den BI Bereich zu erzeugen, obwohl es kostenlos kommen wir wahrscheinlich gleich drauf.
Wessel: Da komme ich gleich drauf, ja. Warum wir dann doch noch Kosten haben, obwohl es umsonst ist. Ja.
Dennis: Okay. Und ganz kurz, weil ich es schon interessant finde, also gibt's ja auch bei uns durchaus die Überlegung, glaube ich, zu sagen so, lasst das wegschmeißen und wir machen das einfach komplett selbst, weil letztendlich ist ja einfach nur einfach nur in Anführungsstrichen ein Request, den man aus der App irgendwohin schickt. Aber ich glaub, wenn man so denkt, das ist 'n bisschen sehr vereinfache. Also es sind schon sehr viele Parameter, die irgendwie dahin kommen, so was zuverlässig zu machen. Aber ich glaube, das eine der der großen Kernsachen, so wenn man irgendwie Analytics machen will, dann muss man einigermaßen sicher sein, dass das, was da kommt, auch irgendwie eine Relevanz hat. Also das heißt, ich weiß nicht, eine 1 der großen, vielleicht hast Du noch bessere Beispiele oder 1 1 der großen Dinge, die ich immer so gehört hab, ne, wenn mal Leute offline sind beispielsweise. Also nicht eine dauerhafte Online Verbindung haben. So, dann können sie nicht die ganze Zeit ihre Events dahin senden, also brauchst Du schon sofort irgendwann eine Technik, das Lokal zu cachen und dann irgendwann später zu schicken und dann trotzdem richtig einzuordnen so. Aber wir hatten ja oder ich glaub, haben auch teilweise angefangen, unsere eigenen Tracking Solutions zu bauen so. Kannst Du da 'n kurzen Einblick geben, so warum noch nicht komplett da drauf und was sind die Herausforderungen und warum haben wir's überhaupt angefangen?
Wessel: Also erst mal auch die Frage, warum wir jetzt damit anfangen. Ist Google Analytics hat auch eigentlich, also es gibt immer eine Streamingkomponente von Google Analytics, die unsere Live Datum bringt. Aber wie Du erwähnt hast, gibt's auch Offline Spieler. Und dann die haben da eine Funktionalität, das heißt dann Badching, die man aber nur bis eine bestimmte so Anzahl von Events pro Tag schafft. Mhm. Jetzt haben wir neue Spiele und jetzt haben wir Google Analytics und die werden die neue Spiele wieder auch offline gespielt. Und jetzt kommen wir über diese Grenze und dann muss man bei Google schon ordentlich bezahlen. Und deswegen haben wir gesagt, okay, das ist ein Teil, warum wir ja unsere eigene Tracking solution haben wollen, weil die ja der Preis, also man muss dann GA3 60 holen und das ist eigentlich ein sehr mächtiges Tool und wir würden da so 5 bis 10 Prozent wirklich nutzen, deswegen lohnt es für uns ja, sich nicht so wirklich das zu nutzen. Genau, das ist ein Teil, warum wir ja gerne uns eigenen Tracking da bauen wollen würden. Du hast schon ein ein Einblick gegeben von, okay, was so zum Beispiel Offline Spieler, dann braucht man halt, ne, dieses eine oder was auch immer, was dann immer losgeschickt wird. Das ist ja schon ein Grund, warum wir das zu also, na ja, ist nicht 'n wirklich eine Grund, warum wir es noch nicht habe, aber das ist halt eine Herausforderung, ne. Es gibt aber noch viel mehr Herausforderungen, weil es ist halt eine Service. Das Wichtigste ist für uns erst mal, dass die Daten ankommen. Und wenn Du so einen Service hast und Du also hast all deine quasi in diesem, in diesem Tool, da musst Du auch sicher gehen, dass es immer live ist, dass es immer up to date ist, dass es immer am Laufen ist. Und dann braucht man auch eigentlich immer jemand, der Freitagabend 11 Uhr, wenn es da was schief geht, auch wirklich direkt da was ändern kann und ja, ein Fix deployen kann. Das ist ein ein großes Ding, so ein Live Service zu haben. Dazu natürlich gibt es auch Datenschutzthemen. Also man muss natürlich achten drauf, was darf man speichern, was kann man speichern, was darf man von einem Nutzer, von einem Device lesen? Mhm. Ich hab davor erwähnt, okay, Fiebase DEG schickt auch 'n paar andere Daten mit, soner Mobile Device name oder 'n iOS. Wie holen wir das raus? Wie holen wir überhaupt eine eine Country? Also welches Land, die die Nutzer spielen? Wir holen das raus und wir holen das auch zuverlässig raus und sonst auch die die Spracheinstellungen, das sind halt so, ist auch ein Teil, warum wir ein bisschen weggewonnen von Firbase Analytics sind halt so Themen, die sind schwierig, ist eine Blackbox, was Firbase oder Google Analytics da macht. Mhm. Aber deswegen ist auch wohl mehr weg, aber es ist auch dann wieder ein Problem, warum wir, wo es schwierig ist, wegzugehen. Ja. Weil man weiß nicht, was passiert und es gibt ja
Dennis: Okay. Ja, Thema Datenschutz könnte man wahrscheinlich eine eigene Folge oder eine ganze Miniserie zu machen. Aber ich mein, grundsätzlich ist ja so, keine Ahnung, GDPA und Digital Markets Act und was da alles so alles an Regelungen ist. Vielleicht trotzdem eine Hausnummer, also wir müssen ja alle User*innen fragen, so können wir irgendwie Sachen tracken. Ich glaub, wir bei Ich hab immer so das Gefühl, wie bei Lothar, ich ich mag grundsätzlich die ganzen Vorstöße, die da die da irgendwie existieren und ist wahrscheinlich aus gesellschaftlicher Sicht gut, dass wir das das machen und diese Regelung bekommen. Wir hatten ja noch nie das Ziel, mit Daten irgendwie, ne, also aus den Daten heraus Geld zu machen, also aus den reinen Daten. Ich mein, das war vielleicht auch vor 'n paar Jahren noch mehr, aber das ist natürlich auch irgendwie 'n Use Case von vielen Firmen gewesen, ne, Userdaten zu nutzen, diese daraus Geld zu machen so. Und bei uns ist ja wirklich es kommt uns ja nie es geht nie eine Person im Sinne von ne, irgendwie, was ist das für eine und was macht die, sondern es ist ja wirklich eher, wie ist das Spielverhalten 1 Person. So und gerne die über den die ganze User Journey tracken, aber wer das jetzt in Real Life ist, ist uns egal. Ne und von daher habe ich das Gefühl, wir sind immer sehr weit weg von irgendwie, ne, persönlich also Datenschutz und kann das irgendwie zurücktreten und so weiter. Und gleichzeitig, ja, ist natürlich okay und es ist gut, dass wir uns damit befassen und deswegen das auch hoffentlich korrekt alles abfragen. Was ist sone ganz große grobe Hausnummer? Wie viele Leute Also wie viel geht alleine verloren an Daten, weil die User sagen, sie wollen nicht gecheckt werden?
Wessel: Ich glaub, das war sone 10 Prozent, aber jetzt guck ich mal mich herum. Ich glaub, so 10 Prozent ist schon.
Dennis: 10 20 Prozent, ja.
Wessel: Ja. Danke. Also lass mal auch sagen, so 10 Prozent, weil nur Sachen wie Filebase Analytics überhaupt oder Google Ads überhaupt blockiert, ne und dann auch noch gibt's diese Content. Mhm. Da gehen schon auch einige an Daten verloren.
Dennis: Okay. Trotzdem kommen ja noch relativ viele Daten an. Dann lass uns mal versuchen, da weiterzumachen. Also Du hast gesagt, Google Analytics sammelt die erst mal über das SDK, dann schieben wir die im Big Query, Rohdaten zu haben.
Wessel: Genau, ins Warehouse und dann kommen die Rohdaten und ja, jetzt wollen wir wollen wir da Daten rauslesen, ne? Also wollen wir Informationen, die actionable sind Mhm. Halt gerne rauslesen. Und genau, hier ist auch die Frage von dir, woher kommen alle Kosten? Wir haben bei uns die Daten Command und wollen die weiterverwerten. Wir haben dann zum Beispiel eine, also man muss das sehen als Datenbank. Wir haben pro Interaktion eine Zeile. Wir wollen jetzt aber wissen, okay, zum Beispiel wie viele innerhalb 'ner Session, was macht ein Nutzer an bestimmten Nutzer in dem Session? Das heißt, wir müssen halt irgendwie ein Session identifizieren. Jetzt gibt es da verschiedene Möglichkeiten. Ich will da nicht so sehr ins Detail gehen, aber ein einfacher Schritt wäre, okay, wir gucken für einen Nutzer, das ist bei uns dann ja eine eine Spalte. Eigentlich kann man da auch noch drauf eingehen, weil wir haben, wie gesagt, diese Verknüpfung, ne. Wir haben eine Firebase, der gibt uns eine ID und wir haben eine ID.
Dennis: Mhm. Und
Wessel: wir matchen das zu einem ID, also zu unserer Spieler ID. Und wir versuchen, auf Basis von dieser Spieler ID zu googeln, hey, welche Events hast Du geschickt? Und zum Beispiel mehr als 30 Minuten zwischen ein Event geschickt, das ist dann dein Session. Deine Session hörte auf. Und dann muss man die Daten agieren. Dann sagt man, okay, innerhalb dieser Session, was ist der Zeitpunkt? Du wirst so Metadaten extrahieren von, hey, wir wissen wann dein erste Touch war, deine erste Interaktion, war mal deine letzte Interaktion. Na, die Sekunde dazwischen ist ein Session Time. Das will man daraus extrahieren. Wir können dann auch überhaupt aggregieren von, hey, Du hast innerhalb diese Session so auf diese Knopf gedrückt. Du hast so oft ein Spiel beendet. Und das aggregieren wir dann auch innerhalb bequery. Also ich weiß nicht, wie tief ich da ins Detail gehen soll, denn es kannst immer gerne Nachfragen stellen. Ja. Aber wir haben das halt quasi aus 'ner, innerhalb unserer, ja, Zeile. Also deswegen kommen innerhalb eine Zeile trotzdem sagen, oh, das Event würde so mal aus so oft ausgeführt, das andere Event so oft. Könnte man auch natürlich aus Spalten speichern von, hey, ich hab eine Spalte mit abgeschlossener Runde, eine Spalte mit Button Klicks. Wir möchten das aber für alle Events machen. Wir wollen das eher dynamisch, dass man nicht immer das Klima ändern muss. Das heißt, wir wollen nicht immer neue Spalte hinzufügen.
Dennis: Mhm.
Wessel: Deswegen haben wir eigentlich so eine Spalte, so dieses repeated field, wo wir sagen, hey, dieses Event oder sone, dieses Event ist wurde so oft ausgeführt.
Dennis: Okay. Und ist es dann so, dass wir, also wenn wir später, das ist wahrscheinlich dann in in der nächsten Folge, wenn wir uns die Daten angucken, aber speichern wir die in unterschiedlichen Aggregationen, die Daten oder versuchen wir schon ein Ding zu haben, aus dem wir dann alles rauslesen können?
Wessel: Also idealerweise sind meist, also jetzt hab ich einen Schritt erzählt, ne. Es gibt davor noch eigentlich dieses Mapping, dass wir von verschiedene, also von Firebase und Spieler ID zu einem ID kommen. Also es gibt auf China Aggregationsebene. Das ist ein Schritt. Jetzt hab ich erzählt, okay, danach sorgen wir, dass wir alles aggregiert auf eine Session Ebene. Idealerweise, wenn ein Gamedates sich anschauen will, okay, wie verhalten sich die Sessions? Würdet ihr das hier benutzen, diese Tabelle? Jetzt haben wir nur noch eine andere Aggregationsebene oder eine andere Stufe. Das wäre okay, was macht der Nutzer überhaupt am Tag? Ne? Wieder gleiche Geschichte, okay. Wir haben jetzt für einen Nutzer 3 Sessions. Mir könnt da alle Events, die er da ausgefüllt hat, addieren. Da haben wir, was der an einem Tag gemacht hat. Wir können die Session Times addieren, dann ist okay, so Langeweile am Tag im Spiel und dann, wenn die gerne analysieren wollen, hey, wie wie verläuft das Spiel? Was ist im Allgemeinen? Zum Beispiel wie wie viel Runde spielen die Nutzer am Tag? Wäre das sone perfekte Aggregationsebene? Vor allem auch, weil es auf Nutzerebene ist und man, das wird Tobi wahrscheinlich im nächste Folge erklären, dass man dann noch mehr Daten daran verknüpfen kann, dass man noch mehr daraus analysieren kann als nur, diese Nutzer hat das an dem Tag gemacht.
Dennis: Hast Du mal eine Hausnummer, wie viele Events es so geht? Also vielleicht einmal, wie also die Anzahl der unterschiedlichen Events, die so ein Spiel bei uns hat? Also sind das irgendwie, weiß ich nicht, 10 und das ist irgendwie ein Level up Event und ein Game Endet Event und dann ist fertig oder wie viele unterschiedliche Events trackt son Spiel bei uns?
Wessel: Vielleicht auch für die Hörer. Also es passiert auch oft, dass BI vorgeht, was getrackt wird. Ist bei uns nicht der Fall. Mhm. Und jetzt mach ich auch einfach mal live unser schlimmstes Spiel,
Dennis: würde ich machen Schlimmstes aus Beeisicht, ja?
Wessel: Schlimmste aus Beeisicht, also Meister an Events. Dennis vielleicht also die Hölle wissen. Hab ich
Dennis: nix mit zu tun.
Wessel: Ja, Du warst halt bei Viel Bilder ein Wort zuständig. Wir haben da 617 verschiedenen Events.
Dennis: Nö, ist doch knackig.
Wessel: Knackig, ja. Und wir gucken uns die natürlich auch alle an. Nee. Ja. Aber es gibt bei uns auch oft so zum Beispiel sagen, jeder geben, die sich anschauen will, ne, sone Anzeige später Runde oder für uns ist auch wichtig, dass Wir haben mehrere Spieler. Wir wollen halt diese Informationen, es sind halt diese Events, wir wollen dir halt so über alle Spiele auch die gleiche Art von so Aggregation, so was ist ein Spiel? Zum Beispiel haben wir irgendwo definiert von, hey, dieses Event in diesem Spiel, das ist bei uns ein abgeschlossener Runde. Mhm. Und so können wir auch dann über mehrere Spieler, weil das ist knackig hier, über mehrere Spieler zuverlässig sagen, okay, so viel Runde würde abgeschlossen oder ja. Das ist eigentlich das große Beispiel.
Dennis: Okay, also 600 und 17 unterschiedliche. Und dann Hausnummer, wie viel Daten wir so am Tag sammeln?
Wessel: Sammeln, das ist auch, kann ich dir auch Lifestyle oder ich gucke ja auch mal wegen NDA mäßig. Ich glaub, das passt alles. 205000000 Zeile am Tag für ein Spiel.
Dennis: 205000000 Zeilen am Tag für ein Spiel. Was ist das
Wessel: in Datenmengen? Gigabytes ist 255 Gigabyte.
Dennis: 255 Gigabyte für ein Spiel an einem Tag. Genau und ich
Wessel: sag dir natürlich nur das größte Spiel, weil dann Ja. Sieht es noch krasser aus, was wir machen. Ja. Also die anderen Spieler haben zum Beispiel eine 10 Daten, nein, das nicht.
Dennis: Ja, jetzt ist 'n kleiner, okay, aber was für Herausforderungen haben wir durch die Größe an der Stelle? Weil irgendwie, weißt Du, weißt Du, was jetzt Du jetzt erzählt hast, okay, wir kriegen Daten, wir formatieren die ein bisschen, aggregieren die ein bisschen, ne? Es geht ja auch darum, weiß auch nicht, ob das vielleicht an den zweiten Teil gehört, aber wie wir darauf ne zugreifen, aber ich glaube, es ist ja auch in der Vorbereitung irgendwie der Daten dann noch. Wenn wir 200 Gigabyte am Tag haben und wir wollen uns jetzt eine Woche angucken, was der User eine Woche ist wahrscheinlich relativ wenig, aber wir wollen uns mal angucken, was hat ein User die letzten 30 Tage gehabt und dann müssen wir Kopf rechnen. 30 mal 2 6
Wessel: Ah so viel. Ja.
Dennis: Terabyte. Einiges an Terabyte Daten durchgucken so. Hört sich jetzt als Query auch nicht so einfach an.
Wessel: Hört nicht sich nicht so einfach an. Dafür sind auch die Aggregationsstufen, weil wie erwähnt, wir können auch eigentlich auf diese telemetrische Daten eine Query schreiben, wenn ihr genau sagt, für diese Nutzer hat er diese Events ausgefüllt, Aber dafür sind die Aggregationsebene da. Wir vorberechnen das. Und wir vorberechnen das auf 'ner Session Ebene, auf 'ner Nutzerebene, auf 'ner so quasi Gesamtenbene pro Land zum Beispiel und und Spiel natürlich. Und dann am Ende, weil wir das vor AG haben und wir wollen halt sone mal anschauen, ah, ein Nutzer, wie viel Events hat er ausgefüllt in seinen, vielleicht auch seinen ganzen Liftern, was wir jetzt sagen.
Dennis: Mhm.
Wessel: Die Tabelle ist halt ein sehr kleine Fraktion am Ende. Also also kann man's ja auch sagen, am Ende zum Beispiel ist das nur 1.33 Terabyte.
Dennis: Mhm.
Wessel: Für unser Gesamtzeitraum von, was Okay.
Dennis: Und da vielleicht noch mal ganz kurz, technisch oder Tools oder so was. Also ich mein, das muss ja, gehe ich davon aus, ihr drückt jetzt nicht jeden Tag aufn Knopf, irgendwie die Daten neu zu bauen oder es passiert auch nicht live oder wie auch immer.
Wessel: Da ist schon noch eine lustige Geschichte dazu. Ich weiß nicht, ob ich Also bei uns nicht die ganze Zeit. Nee, es geht immer, letzter Arbeitgeberin gab's immer einen Typ, der hat dann jede 30 Minuten hat der halt son ganz langes SQL Statement auf seinen Rechner laufen lassen.
Dennis: Okay.
Wessel: So machen wir's nicht. Mhm. Nee, wir haben Airflow, also das von Apache Airflow, beziehungsweise wir benutzen da die Hostd Version von Google Cloud, damit man sich da nicht drum kümmern muss über Workerys und was auch immer. Das ist ein ja, Workflow lass man sagen. Da haben wir diese verschiedenen Schritte als SQL definiert. Das führt es ja im Nachhinein aus. Der guckt, hey, ich hab jetzt meine Nutzer gemappt so zum korrekten ID. Okay, jetzt kann ich weitermachen. Jetzt kann ich mir die Sessions aggregieren. Okay, jetzt kann ich wieder weitermachen. Und ja, das benutzt er dann dieses Cloud Composer dafür. Ja.
Dennis: Und der ist auch irgendwie so fail Safe. Das heißt, wenn ein Schritt kaputtgeht, dann hat er nicht alle Daten dazwischen zerschossen, sondern ist es irgendwo temporär und man kann dann einfach von vorne wieder anfangen, oder?
Wessel: Wir machen das alles auf Tagesebene. Mhm. Und die sind auch partitioniert nach Tage und der fasst immer nur eine Partition an. Wenn der in der Mitte abbricht, dann haben wir halt up to date Daten, ja bis zum der Schritt, lass mal sagen, der konnte nicht auf Tagsebene für die Nutzer das aggregieren, dann haben wir trotzdem das auf Sessions Ebene. Ist aber alles, was sehr wichtig ist bei der Engineering Engineering ist, dass es einem potend ist. Das heißt, wenn ich es zweimal ausführe, erwarte ich das gleiche Ergebnis. Das heißt, wir haben jetzt die Sessions aggregiert, aber ich könnte die ganze Pipeline nochmals anstoßen. Und ich würde dann wieder auch die die die Sessions aggregieren, aber da würde das gleiche Ergebnis, also das würde es nicht duplizieren oder was auch immer.
Dennis: Mhm. Das
Wessel: ist eigentlich sehr wichtig.
Dennis: Wie lange dauert das bei uns? Also diesen, wie nennt man den Prozess?
Wessel: Das ETA Prozess nennen wir das oder heißt es eigentlich. Das ja, dauert schon einiges. Jetzt kann ich mir das beste Beispiel nennen, glaub ich, wenn Du mir 'n bisschen Zeit gibt gibst. Natürlich.
Dennis: Ich überbrück es mit
Wessel: Du be
Dennis: Dings Musstest.
Wessel: Erzähl doch
Dennis: mal was. Erzähl erzähl doch mal 'n Witz.
Wessel: Ja, gibt gibt's
Dennis: 'n guten BI, gibt's 'n guten Data Engineering Witz, den ihr grade auf Lager habt.
Wessel: Oh, ich hatte aber gestern 'n gute gefunden oder 'n Real, son Meme.
Dennis: Die muss sich konzentrieren, Wessel.
Wessel: Nee, also ich hab es hier schon.
Dennis: Okay.
Wessel: Ist das nicht korrekt? Au, ja, okay. Eine Stunde für das Ganze, also nicht vor, was ich grade erzählt habe, weil das ist nur 'n kleiner Teil. Mhm. Für das ganze Prozess von Transformation und Es gehört quer ist eine Stunde. Okay.
Dennis: Und das machen wir einmal am Tag. Oder wahrscheinlich einmal in der Nacht irgendwann.
Wessel: Einmal in der Nacht und das ist jetzt auf ein Tag quasi, ja. Also das ist auch das gesamte Prozess von, das ist eine 'n bisschen längere Geschichte, aber ganz kurz gefasst, wir haben halt Offline Spieler, die Daten kommen später an. Die Daten, die kommen zum Beispiel heute an für vorgestern. Mhm. Und die Tage müssen wir auch noch mal laufen, aber das ist hier inkludiert in diese einen Stunde 8 Mhm. Minute.
Dennis: Und Wie weit zurück machen wir das?
Wessel: Wir machen immer nur 4 Tage, so gestern und dann noch 3 Tage extra. Machen wir zurück. Okay.
Dennis: Das heißt, wenn jemand 5 Tage offline war oder sagen wir mal 10 Tage offline war, dann kommen seine Daten nicht mehr in unsere Datenbanken. Genau. Und der ist dann einfach verloren.
Wessel: Ja. Leider ist sind das nicht die einige Daten, die verloren gehen, aber das ist eine andere Geschichte.
Dennis: Also was ganz kurz eingeschnitten? Also wo gehen Daten verloren? Überall.
Wessel: Ja, also das Ding ist, ne, wenn man in der Uni ist und man muss da son Analyse machen oder so Machine Learning, dann kommen immer son schönen Datensatz, keine kaputte Daten oder man kann das so fehlen, aber das ist in Wirklichkeit nie. Es gibt immer dann Daten innerhalb 'ner Session, Events, die wir merken, dass die fehlen. Wir haben zum Beispiel, dass die Spiele ein auch von vom Spiel selber eine ID mitschickt von, hey, das ist ein achter Event in dem Session.
Dennis: Mhm.
Wessel: Dass wir merken, okay, da fehlen halt so, weißt Du, Du hast 1, 2, 3 und 4 ist nicht da und 5 und dann so, okay. Da merkt man aber auch noch nicht, dass die dass sie überhaupt ganze Sessions vermissen, vor allem die erste Sessions. Wir wissen, wir tracken zum Beispiel, hey, Du hast Level 1 geschafft. Bei manchen Nutzer, die haben die fangen erst ab Level 10 an oder? Also die ersten neuen Levels zum Beispiel haben nicht getrackt, weil die erste Session wurde nicht getrackt. Und das sind schon so Challenges, womit wir immer zu tun haben. Also da könnte man noch einige Podcasts drüber füllen, aber Podcastfolgen, weil es gibt viele Challenges und deswegen sind wir auch 3 im Team und haben immer was zu tun. Und wenn die Challenges nicht gibt, dann bauen wir die irgendwo so Daten des Currencies ein.
Dennis: Sehr gut. Okay. Cool. Ja, also von meiner Seite, ich würde das denken, das ist ja jetzt schon einiges, was da irgendwie in diesem Bereich reinfällt. Aber da wir euch alle 3 im Raum direkt haben, Fabian, Tobi, habt ihr noch, Was, wo ihr sagt, so, das würdet ihr auf jeden Fall noch in dem Bereich sehen und sagt so, das ist eigentlich noch, das muss noch in diese Folge mit rein? Oder besser, lass Du noch was?
Wessel: Ja, es gibt noch mehrere Schichten, die wir halt von Aggregationsebenen, ne. Aber ich glaube, das ist eigentlich schon, was ich erzählt habe, halt nur eine neue Art von Aggregationen und sonst sonst glaub ich, dass es ziemlich so abgedeckt hat, was 'n bisschen das Engineering angeht. Wenn es noch Fragen gibt, background Loaten Punkt d, oh nee, ups. Ups. Ups. Background Programmier Punkt
Dennis: Komm, komm, bei bei der bei der Programmier sind wir immer, das ist Dennis dann, Dennis at Programmier Punkt Bar. Sorry. Da kann man mich direkt erreichen.
Wessel: Oder Wesso at Programmier Punkt Bar. Wink.
Dennis: Wink. Richten wir gleich noch ein.
Wessel: Okay, kann ich gerne auch noch Fragen schreiben.
Dennis: Sehr gut. Ja, absolut. Wie immer. Also wenn ihr Fragen habt oder Feedback, dann dann schreibt uns gerne entweder an Wesselad programmier bar, direkt zu ihm oder natürlich an Podcast at Programmier Punkt bar. Und würde ich sagen, haben wir den ersten Part hinter uns im nächsten. Werden wir uns son bisschen mehr angucken, okay, jetzt haben wir die ganzen Daten. Jetzt haben wir noch nicht so richtig was gewonnen bis an dieser Stelle, sondern wir haben ja erst mal nur Daten und die sind irgendwie schön strukturiert und so, dass man sie abfragen kann. Aber das Abfragen und tatsächlich irgendwelche Insights daraus ziehen, da kümmern wir uns in der nächsten Folge mit Tobi drum. Von daher freuen wir uns, wenn ihr da wieder einschaltet. Und ja, bis dahin Teil 2 von BI Essentials. Wie findet ihr den Namen? Ich fand ihn gar nicht so schlecht. Quatsch für Leben.
Wessel: Ah, ich fand's, ja. Kann man hier noch was einfallen lassen?
Dennis: Okay, machen wir. Bis dann.

Data Engineering mit Wessel van de Goor

Shownotes

Speaker Info

Wessel van de Goor

Verwandte Podcasts

Predictive Analytics mit Fabian Hadiji

Data Analytics mit Tobias Lampert

Analytics Engineer (w/m/d): Wir suchen Verstärkung!