Spezialfolge 157 –

Data Analytics mit Tobias Lampert

16.08.2024

// Podcast
// Spezialfolge 157

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 zweiten Teil unserer Business-Intelligence-Serie sprechen wir mit Tobias Lampert über seine Reise vom Backend Developer zum Analytics Engineer. Wir diskutieren die Nutzung grafischer Tools im Vergleich zum Schreiben von Code und lernen, was statistische Signifikanz bedeutet.

Außerdem erfahren wir, wie das Team Self-Service-Lösungen baut, um den Game Leads bei Lotum eigenständiges Arbeiten mit aggregierten Daten zu ermöglichen. Und wir hören, welche Stolperfallen es auf dem Weg dahin geben kann und warum eine klare Definition von Metriken und KPIs essenziell ist, um schwerwiegende Fehler zu vermeiden.

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-157-data-analytics-mit-tobias-lampert

Dennis: Hallo und herzlich willkommen zur zweiten Folge unserer BI Mini Serie, die ich einfach eigenmächtig Business Intelligence Essentials genannt hab in der ersten Folge. Ich bin Dennis. Ich sitze hier zusammen mit den 3 BIlern von Lotum. Wir haben zum einen Wessel. Hallo. Wir haben Tobi. Hallihallo. Und wir haben Fabian.
Tobias: Hallo.
Dennis: Genau und wie in der ersten Folge angekündigt, deswegen werden wir das nicht alles wiederholen, wenn ihr nur zufällig auf diese Folge trefft und die erste nicht gehört habt. Also in dieser Miniserie geht's 'n bisschen darum, was sind so die Bestandteile unseres unter unseren Arbeiten, die unter Business Intelligence fallen? Und in der ersten haben wir uns mit Vestal darüber unterhalten, wie wir überhaupt in unseren Spielen an Daten kommen, wie wir die irgendwo ablegen. Und jetzt kommen wir das zu dem spannenden Teil, uns darüber zu unterhalten. Was machen wir denn dann überhaupt mit den Daten und wie kommt ein Nutzen Nutzen aus den Daten raus? Der ja hoffentlich da ist, sonst würden wir den ganzen Aufwand nicht betreiben. Und der Part wird heute ein bisschen stärker von Tobi unterstützt. Tobi, magst Du ein bisschen was über dich erzählen sein? Wann hast Du mit Daten zu tun? Warum macht dir das Spaß? Was was was sollten die Leute über dich wissen?
???: Ja, hallo, ich bin der Tobi. Ich hab ja schon sehr, sehr lange mit Daten zu tun. Ich hab viele Jahre, fast 10 Jahre als Backend Entwickler gearbeitet und eher Applikationen gebaut, die große Datenmengen ja verwalten. Und hab dann so vor ungefähr 7, 8 Jahren gemerkt, mir macht eigentlich das Analysieren oder das Erzeugen von Mehrwert aus den Daten viel mehr Spaß und hab mich dann von der Backend Entwicklung in Richtung Data Science, Data Engineering entwickelt und hab dann bei verschiedenen Firmen als Data Scientist gearbeitet. Und ja, immer, sag ich mal, so die gesamte Kette von Datenerfassung, Datentransformation, Datenspeicherung, Datenanalyse und die Plattform, die man dazu braucht, das alles zu machen, mitbetreut. Und das ist auch genau das, was ich bei Lotum als Analytics Engineer mache. Das umspannt im Prinzip genau diese Tätigkeiten, die ich jetzt grade geschrieben hab, die gesamte Kette von da, wo die Daten entstehen bis zu dem Punkt, wo man aus Daten einen Wert schöpft, ja, und das Tooling, was man dafür braucht, das zu tun, zu betreuen.
Dennis: Bevor wir in den Bereich einsteigen, den wir gleich haben, ich mein, wir haben das jetzt einfach unter euch 3 son bisschen aufgeteilt, die 3 Themen, die wir haben. Wie würdet ihnen beschreiben, wie sehr eure Jobs sich unterscheiden im im Alltag? Also seid ihr einfach alle 3 für den ganzen BI Bereich zuständig oder gibt es schon so, dass ihr sagt, ihr habt Präferenzen? Also der eine kümmert sich lieber das State Awarehouse oder ist das schon sehr ausgeglichen jetzt in eurem speziellen Fall bei euch rein?
???: Ich würde es schon irgendwo als BI Generalisten beschreiben irgendwo, weil wir alle Themen, die sowohl mit Data Engineering als auch mit Datenanalyse und Datenplattformen und Infrastruktur zu tun haben, uns schon damit auskennen. Es gibt natürlich bei dem ein oder anderen gewisse Schwerpunkte. Es gibt dann halt jemanden wie Wessel, die sich mit luca, unserem Dashboarding Tool zum Beispiel sehr gut auskennt. Ich komm vielleicht dadurch, dass ich halt sehr lange in der Softwareentwicklung gearbeitet habe, halt mehr so aus dem vielleicht Software Engineering Bereich und alles, was irgendwie mit mit Codschreiben zu tun hat. Fabian, vielleicht ist jemand, der sich mit so Monetarisierungsthemen dann sehr gut auskennt. Es gibt natürlich son bisschen 'n kleines Fokusthema, aber im Großen und Ganzen denk ich mal, können wir ja alles sehr gut abdecken, die gesamte Bandbreite.
Dennis: Mir fällt grade auf, können wir ja vielleicht einfach noch nachreichen, so was wir im ersten Teil vielleicht gar nicht so sehr gemacht haben, als es mit Wessel das Data Engineering Thema ging. Eigentlich so dein, ich schalte noch mal Wessel einfach dazu, wir sitzen auch hier, Wessel dein dein Skill Set oder so. Also was ne, wir haben gesagt, okay, wir haben irgendwie Google Analytics, das bauen wir ein, das bauen ja irgendwie die Game Teams ein und dann haben wir dieses Warehouse und wir haben irgendwie Air Flowers Technologie. Was sind denn die tatsächlichen, weiß ich nicht, wie nennt man's denn dann? Nicht, man hat ja keine Programmiersprachen, aber also SQL ist vermutlich eine Sache, wo man schon relativ advanced drin sein muss, irgendwie coole Querys zu schreiben. Und es ist sonst ein Ja, was sind noch sonst so Gibt es noch Sprachen oder gibt es dann Also hast Ist da viel auf Programmieren in den In den Engineeringbereich oder?
???: Ach so Airflow, ja, haben wir nicht drüber geredet, ja, aber das ist alles in Python. Also das ist alles, die ganze Workflow ist da in Python. Gibt es eigentlich nur Python? Wir haben dann vielleicht 'n paar JSons, son paar so strukturelle Sachen da zu definieren, wo wir dann mit Python drüber lupen oder drüber also die Daten, die die Informationen heraus extrahieren. Ist eher auch so, weil wir die Files dann in mehrere Service quasi benutzen und dann son JSON ist halt, es wird überall akzeptiert, ist da sehr angenehm. Genau, das ist ein ein Skill, den man braucht, SQUAL, wichtig. Auch vor allem da auch die Inseln von von BQUERY zu kennen, ne. Das ist ein spaltenbasierte Datenbank. Deswegen ist auch immer wichtig, da auch 'n bisschen mehr Skills mitzubringen von okay, Datenbank, Datenbank Architektur. Mhm. Weil unsere Aggregation jetzt ebenen, die wir vorher besprochen haben, muss auch auf bestimmte Art gespeichert werden. Ja, das sind schon die so die Skills of Analytics engineer oder so. Ihr Data engineering last dich. Okay.
Dennis: Und über euch hinweg, was würdet ihr sagen, wenn wir jetzt SQL auch als Code beschreiben, wie viel Prozent eures Arbeitsalltags habt ihr Code vor euch? Sei es SQL Python oder sonstiges? Also wie viel ist eher in die Nutzung von Tools, ne und irgendwie Auswertung und LookKA und keine Ahnung was und wie viel ist tatsächlich Code, Query schreiben, sowas? Irgendeine Hausnummer?
???: 80 oder?
Tobias: Glaub, das ist für jeden von uns 3 'n bisschen unterschiedlich. Also ich bei mir in der Rolle schreib eigentlich kaum mehr Code, aber arbeite schon auch einiges mit SQL. Weil ich mein, was man vielleicht auch dazu sagen sollte, wir beleuchten ja jetzt grad so die BI Essentials und was aber so in den Rollen auch noch wichtig ist, dass wir ja auch in den Spieleteams arbeiten und dort meinetwegen unterstützen. Ich mein, da wird Tobi gleichzeitig noch drauf zurückkommen und da ist das dann natürlich auch noch mal son Teil Skill, dass man halt auch Geschichten aus Daten erzählt. Und da braucht man natürlich dann in jedem Fall eine Menge SQL. Wenn SQL nicht mehr ausreicht, geht's dann auch mehr Python. Und ich würd sagen, bei mir ist es dann doch ja in der Woche dann eher 10, 20 Prozent, aber bei euch vermutlich deutlich mehr, ne.
???: Das ist so phasenweise. Also es ist natürlich, wenn ich mal jetzt eine Initiative hab, die eher so infrastrukturlastig ist, dann ist es weniger, aber wenn ich an was arbeite, wo es Datenanalyse geht, dann kann das auch mal 80 Prozent sein. Also im Schnitt würde ich sagen, vielleicht 50 Prozent der Zeit hab ich Code vor mir. Mhm. Ja. Wobei man dazu sagen muss, das ist vielleicht für die Hörer auch ganz interessant. Also die Codemenge, die wir produzieren, ist im Vergleich zum traditionellen Softwareengineering vielleicht sehr viel geringer, ja. Es ist das ist wenige Zeilen Code, die aber sehr, sehr gut überlegt sein müssen, ne. Das ist vielleicht das, was uns von 'nem normalen Softwareentwickler unterscheidet.
Dennis: Wie ist denn AI in dem Feld eigentlich? Also wir haben ja viel, keine Ahnung, in anderen Folgen reden wir viel über, ne, Copilot und ist das, was die reine Entwicklung angeht? Ich mein, wir reden gleich, ne, oder im dritten Teil ja auch noch über Predictive, da hatten wir mit Sicherheit 'n bisschen was mit AI zu tun. Aber so in eurem Alltag, wenn ihr curry schreibt, nutzt ihr sowas wie Co Pilot oder ChatGPT oder Gemini oder wie immer?
???: Also ich verwend es selten. Meine Erfahrung, sag ich mal, mit AI Tools sind, sie können relativ gut einfache Use Cases abdecken. Also das, was man, sag ich mal, ja, wenn man eine für einen sehr einfachen Anwendungsfall hat, den das kann man in 'ner plane English, sag ich mal, mittlerweile sehr gut formulieren und da kriegt man auch wahrscheinlich korrekten Code raus. Die das Risiko ist halt immer wahrscheinlich. Also der Code, den son AI Tool generiert, ist immer mit 'n bisschen Vorsicht zu genießen. Und das ist grade im Bereich sehr riskant, sag ich mal, dass da sich halt kleine Fehler einschleichen, die man, wenn man wenig Erfahrung hat, ganz einfach auch übersieht, ja. Also deshalb halt ich das grade bei komplexeren Use Cases noch für einen ja, mit sehr Vorsicht zu genießendes Tool aktuell. Okay.
Dennis: Gut. Versuchen mal bisschen einzusteigen in den Bereich Data Analytics. Das heißt, wir haben jetzt gehen davon aus, wir haben die Daten, die liegen da rum und jetzt wollen wir Fragen beantworten beispielsweise. Also kann ich mir vorstellen, wir haben jetzt in unserem Kontext haben wir Spiele und wir haben natürlich viele, also große KPIs, so was wie, wie viele Spieler sind da täglich in unseren Spielen unterwegs? Das ist so eine sehr große Kennzahl, würde ich sagen, ist relativ relativ einfach wahrscheinlich noch zu beantworten mit den Sternchen, die wir in der ersten Folge hatten. Vorne es fehlen irgendwelche Daten und man muss 'n bisschen gucken, dass man die gleichen User nicht doppelt zählt und solche Dinge, aber sonst ist es einfach nur ein er muss einmal da gewesen sein am Tag, vielleicht noch ein bisschen einfacher. Dann glaube ich, gibt's so ein paar Sachen, die die in vielen Produkten und natürlich in Spielen ganz wichtige Metriken sind, sowas wie eine Retention. Das heißt, wenn ein User einmal da war, wie häufig oder wie viel Prozent der Nutzer kommen dann irgendwie wieder. Und ich glaube, was wir auch noch, also andere Use Case, den wir sehr sehr regelmäßig sehr viel haben, sind ja irgendwie AB-Tests, also wir wollen ne, wir rollen ein neues Feature aus und wollen wissen, ist das Feature besser als das, was wir vorher hatten? So. Wie unterstützt BI an der Stelle die die Gameteams?
???: Jetzt muss man natürlich an der Stelle erst mal sagen, BI ist ja jetzt nicht direkt an den Daten interessiert. Also wir sind nicht, die die Fragen stellen, sondern der Gamelead ist der, der die Fragen stellt, der will halt wissen, ja? Sind meine Nutzer in dem in dem Spiel, steigen die an oder verlieren wir Nutzer jeden Tag? Oder ist da 'n neues Feature, was wir entwickelt haben? Wird das überhaupt angenommen oder ist aus irgendeinem anderen Grund plötzlich die Aktivität in dem Spiel? Verschied sie sich? Wir als BI Team müssen das Tooling und die Daten in 1 Form zur Verfügung stellen, die es dem Gamelead erlauben, auf diese Fragen relativ schnell Antworten zu generieren. Und wir wollen natürlich auch, da wir jetzt 'n kleines Team von 3 Leuten sind, möglichst viel von dieser Analysearbeit dem Gameteam ja zum Game Team rüberschieben, ne. Dass die mit wenig Aufwand sagen, ihr ihre eigenen Fragen beantworten können. Also das nennt man Self Service Data Analytics, ne. Wir wollen, dass der Gamelead, der eine eine Businessfrage hat, die auch selbst beantworten kann, Und das sehen wir als unsere Aufgabe, Daten so vorzubereiten, dass sie verlässlich sind, dass sie einfach abzufragen sind und dass wir das Tooling dem Gamelead geben, mit dem man das auch sehr schnell und einfach machen kann und dann halt auch den Ergebnissen vertrauen kann. Ja. Und dafür verwenden wir luca als Dashboarding Tool. Das hat für uns den Vorteil, dass es relativ flexibel ist. Das heißt, wir haben jetzt nichts, was wir relativ starr vorgeben müssten. Es ist bei Gameleads immer 'n bisschen schwierig zu antizipieren, was die eigentlich genau wissen wollen, ja. Also wenn wir jetzt genau heute schon sagen könnten, welche Fragen son Game Lead in 3, 6, 12 Monaten stellen wird, könnten wir natürlich Tooling bauen, was genau diese Fragen auch ganz starr beantwortet, feste Dashboards, die man einfach nur aufrufen muss. So einfach ist die Welt leider nicht, ja? Es ist die Spiele verändern sich, die Fragen verändern sich. Wir bauen Features ein. Und das ist immer son bisschen sone sehr ja, spontane Ad hoc Geschichte, was son Gameboat eigentlich genau wissen will. Das heißt, wir müssen ihm 'n bisschen 'n modulares Tooling geben, wo er sich seine eigenen Dashboards und seine eigenen Analysen mit vergleichbarem, ja kleinem Aufwand zusammenklicken kann. Und das ist das, was wir in luca machen, wo das ist 'n Dashboardingtool, was ja im Prinzip son son Baukasten unter der Haube hat, mit dem man bestimmte Sachen schon vorbereiten kann, aber im Prinzip nicht die komplette Businessfrage beantwortet, sodass der Gamlead im Prinzip im letzten Schritt sich ein Dashboard zusammenbauen kann und genau definieren kann, das ist jetzt die Metrik, die ich mir anschauen will. Die möcht ich mit dem und dem vergleichen. Ich möchte diese und diesen Daten wie folgt filtern. Ich möchte vielleicht nur die User aus einem bestimmten Land sehen für einen bestimmten Zeitraum. Und genau das kann sich der Gameleit dann ganz spontan zusammenbauen.
Dennis: Und das, was rauskommt, ist 'n Graph
???: In der Regel, oder?
???: Ja, also irgendwo sind es immer Charts und man kann auch einfach einzelne Werte anschauen, aber in der Regel ist es halt schöner visualisiert als als ja, Linienchart über die Zeit oder einen. Das das kann der Gamlead dann für sich, so wie er das für richtig halt genau einstellen, damit er halt genau das sieht, was ihm die Beantwortengefahr ermöglicht.
Dennis: Mhm. Vielleicht auch da an der Stelle jetzt, weil das ist einfach ein Tool, was wir jetzt nutzen, wo wir uns mal durch irgendeine Recherche für entschieden haben. Gibt es da irgendwie andere große Alternativen, wo man so sagt, ja, was gibt's oder irgendwas noch?
???: Ja, da gibt's natürlich 'n Zoo an Tools, dann ist 'n riesengroßer Markt an Dashboarding Tools. Das geht los bei bei ganz, ganz einfach simplen Dingen bis zu extrem großen Enterprislösungen, die sich in der Komplexität und natürlich auch in den Kosten riesenmäßig unterscheiden. Da gibt's jetzt auch nicht, sag ich mal, so den Königsweg, wo man sagt, das ist genau richtige Tool, sondern da muss jeder halt für sich entscheiden, was ist denn mein Anwendungsfall? Wie viel Geld möcht ich ausgeben und wie viel Wartungsaufwand möcht ich in so was reinstecken? Ja, da gibt's mit Sicherheit Tools, die sind eher SQL lastig, wo man, son Dashboard zu bauen, unheimlich viel SQL Code jedes Mal schreiben muss. Das ist genau das, was wir nicht wollen. Wir wollen nicht einen Gamelead jetzt auch noch mit Coding Aufgaben belasten. Mhm. Und schon gar nicht für jede Frage von 'nem Gamelead selbst was coden müssen, ne. Und dann gibt's mit Sicherheit auch Enterprise Tools, die wir nicht nutzen, die halt schon sehr, sag ich mal, drauf ausgelegt sind, dass man sich wirklich nur noch Sachen zusammenklicken kann. Die sind aber auch dann halt relativ starr in ihrer in den Vorgaben, was man was man so tun kann. Und da haben wir halt mit luca son son Baukastensystem gefunden, dass wir uns selbst zusammenbauen und anpassen können, mit dem wir eigentlich ganz zufrieden sind.
Dennis: Liegt luca einfach nur oberhalb von unseren Daten oder haben die oder sind sind da unsere Daten drin? Also kriegen die irgendwie hier, haben die eine eigene Datenbank, wir füttern die mit Informationen oder wo woher kommen die Daten, die dann angezeigt werden?
???: Wir haben ja in der letzten Folge, hat Wessel es ja schon erklärt, wo unsere Rohdaten herkommen und wie sie in Big Query, unserem Data Warehouse landen. Mhm. Wir haben diverse Transformationsschritte dann in Big Query noch mal. Das sind diese Aggregationen, von denen Wessel geredet hat, wo wir Daten zum Beispiel nach einzelnen Sessions oder nach Tagen aggregieren oder Daten auf User Basis aggregieren. Das landet dann in einzelnen Tabellen in Big Query. Und luca ist die Visualisierungsschicht im Prinzip da drauf. Luca greift auf diese vorbereiteten Daten in Big Query zu und macht vielleicht noch mal kleine Aggregationen da oben drauf, kleine Berechnungen oben drauf, aber im Grunde genommen mit sehr einfachen weiteren kleinen Querys, die wir in in kleine Teile verpackt haben, macht es die Visualisierung auf den bereits vorbereiteten Daten.
Dennis: Okay, das heißt, was im Hintergrund irgendwie passiert, wenn ich jetzt was abfragen will und klicke mir praktisch 'n Dashboard zusammen oder einen Graphen zusammen, ist, dass dadurch eine Query entsteht und die ist teils definiert von euch in dem Loca Tool und wird dann irgendwie kombiniert mit, weiß ich nicht, Filtern oder irgendwelchen anderen Sachen, die man dort hat. Und das ist dann eine Abfrage, die aber auf wiederum unseren eigenen, in Anführungsstrichen, Datenbanken läuft, die im Hintergrund liegen.
???: Genauso funktioniert's. Also wir bereiten im Prinzip in den Transformationsschritten die Daten so weit vor, wie's halt möglich ist, noch eine gewisse Flexibilität zu erlauben. In luca, wenn man das Dashboard zusammenbaut, wird unter der Haube noch mal eine kleine zusammengebaut, die auf diesen transformierten Daten dann das Endergebnis erzeugt.
Dennis: Und hab ich als Gamelead, wie ist 'n mein Einstieg? Also hab ich hab ich praktisch irgendwie eine Art, weiß ich nicht, Dashboard oder so was für die unterschiedlichen Aggregationstabellen oder kann ich jetzt wirklich auf 'nem weißen Blatt Papier anfangen und sagen, ich will die und die Metrik haben? Also wie ist praktisch in der Nutzung Hat der Game Deal irgendwas mit diesen mit diesen Aggregationsschichten zu tun? Muss er sich darüber Gedanken machen oder ist das soweit auch weg abstrahiert, dass er einfach nur sagen kann, ich, ist mir egal, ich will einfach nur wissen, wie viele Events, weiß ich nicht, wie viele wie viele Keule muss man Beispiel machen, wie viele Dollar an In App Käufen haben wir gestern umgesetzt?
???: Da muss sich der Gamlead schon 'n bisschen Gedanken machen, weil da gibt's jetzt auch nicht den den einen vorgegebenen Weg, weil wir diese Daten, die Du jetzt grad genannt hast, die In App Käufe aus verschiedenen Quellen, die wir in unseren Transformationsstufen haben, aus im Prinzip auf verschiedene Art und Weise wieder extrahieren könnten, ne. Und das steht und fällt einfach son bisschen mit, es gibt mit Sicherheit einen besten Weg, aber es gibt nicht nur den einen Weg. Und der Gamelead kann natürlich es sich das Leben selbst schwer machen, indem er halt einfach eine eine ungünstige Methode jetzt den Lucke nimmt. Wir sagen normalerweise, okay, wenn Du folgende Frage beantworten willst, dann greif bitte auf folgende Tabelle zu, weil da haben wir die Daten schon optimal in dem Zustand vorbereitet, wie sie für dich halt bestens nutzbar sind. Aber das ist halt son bisschen, sag ich mal, die den ja den Gripps, den der den der Gamleader am Ende noch mal reinstecken muss, wie er für seinen Use Case sich im Prinzip die beste Vorgehensweise in Luca wählt. Mhm. 'N
Dennis: bisschen die Komplexität einzuschätzen, wie viele Schichten oder wie viele Aggregationstabellen haben wir ganz grob so?
???: Über 'n Daumengehalt so 10. Also es ist relativ überschaubar.
Dennis: Okay. Ja.
???: Das kenn ich jetzt aus anderen Firmen zum Beispiel, die es deutlich fragmentierter haben. Die Notwendigkeit, das weiterzufragmentieren, sehen wir noch nicht. Bei uns ist halt immer so, wir müssen die Balance halten zwischen, ist dieses Datenmodell mit seinen ganzen Transformationen für uns noch wartbar und handelbar?
Dennis: Mhm.
???: Und ziehen wir halt schon den maximalen Benefit da draus?
Dennis: Okay. Das heißt jetzt für den konkrete Fragestellung wieder, wie viel wurde gestern an In App Käufen umgesetzt? Weil ich jetzt gestern sage, wüsste ich dann, okay, wahrscheinlich ist irgendwas aggregiert auf Tagen.
???: Ja, wir haben zum Beispiel eine Tabelle, die nennt sich Purchces, wo einfach einfach nur alle In App Käufe drinstehen. Okay. Ja, und da kann man halt direkt dann abfragen, zack für Tag x, was wurde denn da umgesetzt?
Dennis: Weil die dann nicht so groß ist und dann letztendlich, also
???: Genau, die
Dennis: machen jetzt nicht die so die Anzahl der Events sind und von daher, also nicht nicht so groß Wie schon von Ja, ja.
???: Ja, ganz vereinfacht, vor allem könnte natürlich, der Wessel hat's jetzt erwähnt, 205000000 Zeilen pro Tag Ja. Und könnte natürlich auch hergehen und diese 205000000 Zeilen einfach durchscannen Ja. Und die Innerkäufe sich dann halt aufsummieren. Aber das ist halt total ineffizient und langsam und genau das wollen wir ja nicht. Deshalb Ja. Bereiten wir halt genau diese Teilinformation vor, sodass sie, wenn jemand die Frage hat, genau nach diesen In App Käufen genau in der Form vorlegt, wo er einfach nur noch diese diese Daten abfragen muss.
Dennis: Okay, hab ich glaube ich so weit habe ich so weit verstanden. Und das heißt, die Aggregation machen wir ja auch aus Performance Gründen, ne, dass man nicht auf allen Daten dann rumeterieren muss und so was. Ist die Nutzung dann noch irgendwie ein ein oder das, was an Querys rauskommt, irgendwie ein Problem bei Loca oder kann man einfach, also dauert das, wie lange dauert so eine Query, wenn ich dann auf aggregierten Daten arbeite?
???: Also wenn man's richtig macht, dann reden wir ja wirklich in wenigen Sekunden. Das ist wirklich ein ein fließender, also wirklich sehr schnelles Arbeiten. Wenn man's falsch macht, kann sone Query locker mal 'n paar Minuten oder noch viel länger laufen, ne? Und die ist natürlich, wir haben, na ja, nicht nur eine Effizienzfrage, ist halt auch nur son bisschen sone eine Kostenfrage natürlich auch, ne. Langlaufende Querys, die viel Daten durchs Scannen kosten uns halt auch mehr. Und am Ende wollen wir natürlich auch son zuverlässige Daten liefern, ja. Also die die Rohdaten, die bei uns reinkommen, Wessel hat's ja schon beschrieben, die sind nicht die allerbeste Qualität immer. Da muss man auch immer noch mal 'n bisschen gegensteuern, eventuell 'n bisschen Sachen bereinigen, Sachen zusammenfassen, Sachen ausfiltern, Sachen ja, kombinieren und halt bestimmte Fälle unterscheiden. Genau das wollen wir so weit wie möglich in diesen Transformationsstufen vorbereitet haben, damit der Gamlead sich halt mit solchen Sonderfällen nicht mehr rumschlagen muss, muss, ne, dass wir wirklich sagen, der Gamlead kann sehr einfach die Daten abfragen und kriegt genau die Antwort raus, die er haben will, egal in welcher Qualität am Anfang die Daten reingekommen sind.
???: Mhm.
Dennis: Ich stell mir also Ich glaub, eine oder stell mich zumindest vor, dass so die Herausforderung ja auch ist, wenn man's auf unterschiedlichen Ebenen aggregiert, dass man teilweise auch zu anderen, na das heißt nicht anderen Ergebnissen, aber dass dass die Sichtweise ja schon unterschiedlich ist auf so unterschiedliche, also auf auf irgendwie gleiche Daten, aber aus 'ner anderen Durch 'n anderen Schnitt führen vielleicht dann doch wieder zu zu anderen zu dem anderen Auswertungen. So wie wie wie wie stellt ihr sicher oder könnt ihr sicherstellen überhaupt, erst mal die Frage so, dass das, was ich angucke mir, dass es dann auch tatsächlich die Daten sind oder dieses dieses Sicherstellen davon. Also sagen wir mal ne, ich mache irgendwie eine Auswertung und hab jetzt In App Käufe oder sowas und das ist ja durch 'n Riesenprozess gelaufen. Wir haben diese, ne, Aggregierung und es kamen Daten daher und daher. Wie kann man überhaupt sicherstellen, dass das dass das jetzt richtig ist am Ende?
???: Ab 1 gewissen Komplexitätsebene kommt das Problem wirklich zum Tragen, ne. Also wir haben jetzt bei so einfachen Metriken vielleicht wie die die DOS, also die die Anzahl Nutzer in unserem Spiel, da ist es wahrscheinlich noch nicht so problematisch, egal in welche aus welcher Seite man das abfragt, da wird man weitestgehend dieselbe dasselbe Ergebnis rausbekommen. Aber wenn wir jetzt zu so etwas komplizierteren Metriken gehen wie zum Beispiel Retention, also sprich die der Prozentsatz von Nutzern, die nach 1 bestimmten Zeit immer noch im Spiel aktiv sind, Da kommen halt sehr viele Sachen zum Tragen. Und da kann es sehr leicht passieren, dass, wenn man das auf 2 unterschiedliche Weisen abfragt, selbst in luca und selbst mal auf unseren vorbereiteten Daten, dass man leicht unterschiedliche Ergebnisse rausbekommt. Und das ist etwas, wo wir eigentlich permanent damit kämpfen. Und das ist auch son ganz gängiges Problem im Data Bereich, die Definition von Metriken. Damit fängt's halt erst mal an, ne. Was versteht man denn eigentlich unter soner Metrik? Wie ist die definiert? Was sind denn so die Variablen, von denen die abhängt? Und wie erklären wir, sag ich mal, das Ergebnis dann auch, ja? Und da ist es halt 'n gängiges Problem durchaus, ne, dass jemand sagt, ja, ich hab hier Metrik x gemessen und dann jemand anders sagt, ich hab aber auch Metrik x gemessen. Sie glauben, sie haben das Gleiche sich angesehen, haben's aber auch völlig unterschiedliche Art und Weise abgefragt und die Ergebnisse unterscheiden sich ganz leicht. Und da müssen wir als BI Team auch sehr viel Aufklärungsarbeit Wir müssen halt sagen, ja, wie ist denn das genau definiert? Wie fragt ihr das optimalerweise ab und wie sorgt ihr dafür, dass eine Abfrage, die ihr hier baut, mit den Freiheitsgraden, die wir euch gegeben haben, auch das korrekte Ergebnis liefert. Mhm.
Dennis: Okay. Das ist ja wahrscheinlich dann nochmal, also ich meine, man hat ja einmal das irgendwie, jetzt sind die Daten da und man will sie analysieren. Ein ganz großer Teil aus Folge 1, den wir vielleicht müssen wir dann auch noch übersprungen haben, ist ja wie sammel ich sie oder an welchen Stellen? Also auch die Definition von, was wird überhaupt getrackt, ist ja wahrscheinlich auch mal ein guter, ein wichtiger Part, überhaupt hinten raus verstehen zu können, ne? Was das bedeutet. Also auch die Definition, was bedeutet das, wenn ich jetzt sage, haben wir was Komplizierteres als Level-up? Das ist irgendwie eindeutig.
Tobias: Ja, ich meine, alleine auch der Fakt ist, passieren ja auch Sachen im Backend zum Beispiel, ne? Also Du kommst in eine neue Stufe in 'nem bestimmten Spiel oder so was und das passiert ja durch bestimmte Bedingungen. Sowas muss ja auch erfasst werden und das ist dann meinetwegen überhaupt keine aktive Aktion
???: Ja.
Tobias: Der Spieler in in dem Moment zum Beispiel und
Dennis: Ja. Dass das auch schon schwierig, es zu definieren, ne, an an an der Stelle, das gemeinschaftliche Bild zu haben.
???: Ja. Und jetzt kommt halt noch dazu, wir haben ja nicht nur ein Spiel. Wir haben ja 4 oder sogar noch mehr, wenn man wirklich mal alle Spiele, die wir so aktiv betreiben, mit reinrechnet. Spiele, die technologisch sogar leicht unterschiedlich sind und wo das Tracking prinzipiell über dieselbe Methodik, also Firebase funktioniert, aber die einzelnen Events, die geschickt werden, die Wessel hat die 600 irgendwas erwähnt von von vor Pix, sich dann doch wieder unterscheiden. Am Ende möchte man aber vielleicht auch mal die Spiele in ihrer Performance vergleichen. Und das ist halt noch mal die nächste Schwierigkeit, die wir haben, das so weit zu vereinheitlichen über eine einheitliche Datenplattform zu betreiben, dass am Ende wieder vergleichbare Zahlen dabei rauskommen.
Dennis: Und was ist so die, also an an welcher Stelle kann man das am meisten sicherstellen oder wo sind die größten, also geht's denn darum, mein Firebase hast Du gesagt, ja klar, technologisch ist trotzdem unten drunter noch mal was anderes. Wir haben manchmal irgendwelche Web Views, die die irgendwelche Sachen tracken. Manchmal haben wir eine Flatter App, die irgendwie dahintersteckt. Das sind wahrscheinlich auch schon 'n bisschen Unterschiede. Wie viel musstet ihr vorgeben, weil besser hat er eben gesagt, ne, vieles glaube ich in in den Gameteams entsteht das erst mal, also sie haben eine Idee oder sie sagen, okay, das müssen wir tracken, das ist das, was wir machen wollen. Wie viel an gibt es son Set an standardisierten Events, wo wir so sagen, das ist auf jeden Fall das, was in allen Spielen gleich ist und was uns dann hilft, das zu vereinheitlichen?
???: Ja, aber ich glaub, das ist relativ klein, ja. Und vor allen Dingen die die Events selbst unterscheiden sich von der Benahmung her. Also die Spiele sind natürlich von ihrer Mechanik her unterschiedlich, von ihren von der technologischen Umsetzung, die sind teilweise in unterschiedlichen Sprachen programmiert. Also da haben wir natürlich versucht, Sachen zusammenzufassen. Was verstehen wir denn quasi unter den? Und dann eine Runde ist beendet. Mhm. In Spiel x und in Spiel y versuchen das so früh wie möglich in unserem Datenmodell zu vereinheitlichen, damit wir eben genau diese Vergleichbarkeit haben.
Dennis: Okay. Machen wir nur Analysen mit den Daten oder gucken wir auch irgendwie, ob Dinge schiefgehen? Also ist das eher so, weil gucken wir auch irgendwie, ob Dinge schief gehen? Also ist das eher so, weiß ich nicht, jetzt auf technischer Seite gibt's auch noch so Alerding Tools und wir haben irgendwie 'n Backend, was kaputt gehen kann und so weiter, aber ist es in Erfahrung, also nutzen wir in den Gameteams unsere Analytics auch, die Stabilität und Performance der Games anzugucken oder ist es eher proaktive Analysen, dass ich sage, hey, ich hab das und das Feature oder ich will mir noch mal angucken, wie denn die User aus Frankreich auf das und das reagiert haben? Was ist der Haupt Use Case für die Energy Analytics Daten?
???: Also grundsätzlich würde ich da jetzt mal so 3 Haupt Use Cases skizzieren oder je nachdem, vielleicht sogar einen vierten. Also der Haupt Use Case ist mit Sicherheit Datenanalyse, die Performance in den Games zu messen, und zwar einerseits durch so Ad hoc Analysen, wo halt einfach ein Gameteam eine Frage hat, die man beantworten muss. Zum anderen fahren wir natürlich auch sehr viel Experimente und AB-Tests, wo wir neue Features ausprobieren und wissen müssen, ob das jetzt von den Spielern angenommen wird oder nicht. Wir überwachen die Trackingdaten dahingehend, dass wir versuchen herauszufinden, ob sich irgendetwas unnormal verhält, also sprich, ob wir zum Beispiel in irgendeinem Land plötzlich eine ganze Menge zusätzlicher User haben oder uns User wegbrechen oder ob eine bestimmte Plattform, sei es durch technische Gründe oder sei es durch organischen Traffic, den wir reinbekommen, plötzlich anders performt als als vorher. Das ist natürlich etwas, was manuell kaum zu machen ist. Also da sind wir grade dabei, sehr stark unser Tooling auch auszubauen, dass wir relativ frühzeitig benachrichtigt werden, wenn irgendetwas in einem Spiel ja, sich ungewöhnlich verhält. Und das kann man natürlich mit dieser Datenmengen, die wir haben, sehr gut machen. Das ist aber keine einfache Aufgabe, weil es reicht natürlich jetzt nicht einfach zu sagen, na ja, von den zig Millionen Spielern, die wir haben, haben wir plötzlich von einem Tag auf den anderen 10 Prozent mehr oder 10 Prozent weniger. Das beantwortet nämlich die Frage nicht, sondern die Frage ist eigentlich ja, wo kommen denn diese 10 Prozent mehr oder 10 Prozent weniger eigentlich genau her?
Dennis: Mhm. Okay. Ich glaub, also haben wir anfangs schon mal gesagt, aber vielleicht können wir da auf son paar Use Cases Use Cases noch mal 'n bisschen genauer eingehen. Also zum einen, ne, ich hab irgendwie eine grundsätzliche Frage als Gamieat, das ist das andere und ich glaub, das, was aber ein ein sehr regelmäßiger Use Case ist in unseren Spielen ist, dass wir möglichst versuchen, alles, was wir verändern, irgendwie ja durch Daten zu bestätigen oder zu validieren. Sprich in der Regel, wenn es möglich ist, mit dem AB-Test, also gibt 'n paar Use Cases, wo man's nicht parallel testen kann, aber das das meiste ist so, dass wir ja, wenn wenn wenn wir ein AB oder ABCD oder wie auch immer Test machen können für neue Features, für Änderungen, die dann die dann auszuwerten. Was, glaube ich, per se als Thema, wahrscheinlich auch eine, könnte eine ganze Podcastfolge füllen, aber vielleicht kannst Du da mal 'n Einblick hinter die Herausforderung so bringen, die die mit einem da mit einhergehen. Also was was braucht man alles, aus Datensicht zu sagen, so ein ein Experiment, ein Feature in einem Game war erfolgreich oder nicht?
???: Na ja, wenn man sich das mal ganz abstrakt vorstellt, wir haben ein Spiel, wo wir eine bestimmte Mechanik verändern und wollen messen, ob diese Mechanik jetzt zu einem besseren oder schlechteren Ergebnis, also im Sinne von Engagement machen die Spieler mehr in dem Spiel, bleiben sie länger drin, führt, ne. Also wenn wir jetzt einfach mal son simples Beispiel nehmen, wir würden einfach, was weiß ich, den den die Farbe von 'nem Button von blau auf rot ändern und wollen wissen, ist das jetzt gut gut fürs Spiel oder schlecht fürs Spiel? Das geht erst mal damit los, dass wir natürlich rein technologisch die User, die das Spiel in 2 Teile teilen müssen. Es gibt User, die halt nur diese eine Variante sehen und es gibt Nutzer, die nur die andere Variante sehen. Wir müssen technologisch erst mal sicherstellen, dass sich das auf keinen Fall vermischt, ne. Es gibt, der Nutzer kommt in die in eine Testgruppe und eine Treatment Gruppe und die während das Experiment läuft, sehen die genau diese Variante vom Spiel und keine andere. Und dann müssen wir natürlich dafür Sorge tragen, dass die Trackingdaten, die wir erheben, genau dem entsprechen, was die Nutzer auch gesehen haben, ne. Ansonsten würden wir nämlich es überhaupt nicht auswerten können, wie sich ein Nutzer verhält, der eine bestimmte Spielvariante gesehen hat. Dann müssen wir entscheiden, wie lange lassen wir denn son Experiment überhaupt laufen,
Dennis: ne?
???: Also man kann jetzt nicht einfach sagen, na ja, wir machen jetzt mal einen grünen und 'n roten Button und eine Stunde später haben wir genug Daten, sagen zu können, welcher ist denn jetzt erfolgreich? Da wird es dann relativ statistischlastig. Also wir müssen genau abschätzen können, wie viele Nutzer brauchen wir denn? Wie viel mal muss son Button geklickt sein, damit wir überhaupt mit 1 gewissen Sicherheit sagen können, ja, das hat jetzt 'n positiven oder einen negativen Effekt gehabt. Und da geht halt 'n bisschen Arbeit auch rein in die Vorbereitung von sonem Experiment. Da muss man sich halt einfach anschauen, na ja, was ist denn was ist denn der Uplift, den wir erwarten? Also sprich, wir haben wir definieren eine Metrik. Wir sagen zum Beispiel, na, wir wollen messen, jetzt mal ganz simpel, die Anzahl Runden, die gespielt werden, sollte sich erhöhen 10 Prozent in der Gruppe, weil der rote Button einfach sehr viel attraktiver ist. Mhm. Und auf auf Basis von dieser Annahme können wir dann sagen, na ja, okay, wir müssen das Experiment, was weiß ich, 'n Tag, eine Woche, 'n Monat laufen lassen. Und dann schaut man idealerweise erst am Ende. In der Praxis schauen wir aber dann irgendwie dann doch regelmäßig in das Experiment rein und schauen mal, wie sich die beiden Testgruppen gegeneinander verhalten. Und genau das ist im Prinzip die Aufgabe von diesen ganzen Datentransformationen, die wir beschrieben haben, genau diese Auswertung, ne. Wie verhält sich Testgruppe a gegen Testgruppe b? Relativ simpel und vor allen Dingen halt auch verlässlich. Gruppe a gegen Test Gruppe b, relativ simpel und vor allen Dingen halt auch verlässlich durchzuführen.
Dennis: Wie kann man vorher festlegen oder berechnen, wenn Du jetzt sagst, okay, wir wollen 10 Prozent Steigerung in den in den gespielten Runden 1 Spiels, Wie kann man vorher festlegen, wie wie lange man dafür braucht?
???: Die ja, das Stichwort hier ist statistische Signifikanz. Wir wollen im Prinzip jetzt mal allgemein gesprochen sagen, wir wollen ein Ergebnis haben, das mit fünfundneunzigprozentiger Wahrscheinlichkeit korrekt ist. Also dass wir sagen können, wir sehen hier eine Verbesserung von 10 Prozent. Und wir sind uns auch sehr sicher, dass diese Verbesserung von 10 Prozent nicht einfach blanker Zufall ist, weil wir einfach nur zufällig eine ganz kleine Anzahl User in dieser Testgruppe hatten, die sich halt blöderweise anders verhalten haben, sondern wir wollen sicherstellen, dass diese 10 Prozent Verbesserung, die wir gesehen haben, wirklich an der geänderten User Experience hängt.
Dennis: Mhm.
???: Ja. Und da schließen halt so, das kann man natürlich ausrechnen im Vorfeld, da fließen halt so Faktoren rein, wie viel Nutzer haben wir überhaupt in dem Experiment? Wie groß ist denn der Uplift, also sprich der die die Veränderung zwischen der User Experience Original und der veränderten User Experience und noch 'n paar andere statistische Variablen. Und dann kann man halt ausrechnen, na ja, der Effekt, den wir beobachten, ist eher von einem zufälligen, ja, basiert eher auf Zufall. Oder der Effekt, den wir beobachten, hängt mit sehr hoher Wahrscheinlichkeit an dieser geänderten User Experience, ne. Da gibt's so den Metrik, den p value nimmt man in dem Fall, kommt ausm statistischen Bereich. Und an dem kann man sehr genau ablesen, wenn der unter einen bestimmten Schwellenwert sinkt. Ab dem Zeitpunkt kann man sagen, ja, der Effekt, den wir beobachten, ist definitiv kein zufälliger, sondern wir sind uns sicher, dass der durch die durch die geänderte User Experience kommt.
Dennis: Mit meinem Halbwissen rund AB-Test ist ja irgendwie Also wo ist der Unterschied oder das, was ich oft gehört hab, so ist es wichtig, vorher sich Gedanken darum zu machen, dass man weiß, ab welchem wo das dann ist, also dass man's praktisch vorher berechnet und sagt, ne, wenn das so lange läuft oder wenn wir so viele Ergebnisse haben, dann ist das Was was spricht dagegen, wenn man einfach dauerhaft reinguckt und es ist es nicht trotzdem so, dass man dann diesen sich irgendwie 'nem dieser Sicherheit nähert? Also dass man irgendwie am Anfang sagt, ja okay, im Moment sind wir uns 8 Prozent sicher, dann
???: sind wir uns irgendwie 85 Prozent sicher? Das die Schwierigkeit dabei ist natürlich, das ist jetzt kein, sag ich mal, gut vorhersehbarer Prozess. Es kommen halt viele Faktoren zusammen. Also wir haben natürlich mehrere ABAB Tests, die wir auch parallel laufen lassen. Dann hast Du saisonale Effekte. Du willst den Test halt auch nicht zu lang laufen lassen, weil sich eventuell kommt die Userbasis dann halt wieder verschiebt und es kommen andere Effekte rein, die Du gar nicht kontrollieren kannst. Sondern Du möchtest eigentlich einen Test vergleichsweise kurz laufen lassen, bis zu einem Punkt kommen, wo Du sagst, ja, jetzt treff ich eine Entscheidung. Also entweder kann les ich ab, keine Ahnung, ja. Ich weiß nicht, was ich machen soll oder Du liest ab, na ja, das hat jetzt doch nichts gebracht oder Du liest am Ende von dem Test ab, ja, ich bin mir sicher, das hat was gebracht und dann können wir dieses Feature auch ausrollen. Grundsätzlich bei The Book würde man sagen, na ja, wir rechnen vorher aus sozusagen, wie lang wir in den Test laufen lassen müssen und dann genau an dem Tag, den wir uns vor berechnet haben, schauen wir in das Experiment rein und treffen eine Entscheidung. Das ist halt, wie's in der Praxis nicht immer läuft. Hab ich, glaub ich, noch nie bei 'ner Firma erlebt, dass man das genau so macht. In der Praxis schaut man halt doch hin und wieder rein und entscheidet dann, na ja, lassen wir den Test noch mal eine Woche länger laufen. Eventuell tut sich ja noch was. Mhm. In vielen Fällen hat man aber nach relativ kurzer Zeit, teilweise überraschend kurzer Zeit, ein relativ klares Bild davon, ob diese veränderte User Experience was gebracht hat oder nicht. Mhm.
Dennis: Und die Funktionalität, das zu machen, ist das auch was, was dann, was wir auch in luca auswerten können? Also ist das auch innerhalb dieses dieses luca Umfelds und dann kann Game Lead einfach reingehen und sagen, hey, hier ist irgendwie einen Dashboard für meinen AB-Test? Mhm.
???: Wir haben in luca für die die Game Leads Tooling gebaut, mit denen Sie Ihre Experimente auswerten können, wo Sie sagen können, ja, ich hab hier 'n Experiment, das läuft unter folgender ID oder unter folgendem Handel. Ich möchte zum Beispiel auswerten, ja, was war denn jetzt die Retention im Vergleich der beiden Experimentiergruppen und sich dann relativ einfachen Dashboard zusammenbauen, was für dieses Experiment alle Metriken anzeigt im Vergleich und an auch statistisch Kennzahlen dazu aus wirft und zum Beispiel auch sagt, ist dieses Ergebnis jetzt statistisch signifikant? Sprich, können wir davon ausgehen, dass das kein zufälliger Prozess ist, der dazu geführt hat. Mhm. Wir sind dabei, aktuell unser Tooling im Bereich AB-Tests auch zu erweitern, ja, mit 'ner ganzen Menge an Zusatzfunktionalität, weil wir gemerkt haben, da ist luca vielleicht nicht so das allerbeste Tool. Es stößt relativ schnell dann doch an seine Grenzen. Und wenn wir dieses Thema AB-Testing noch besser, noch ernsthafter betreiben wollen, mehr Experimente, schnellere Experimente, teilweise Experimente auch parallel, dann brauchen wir halt 'n besseres Tooling auf unseren Use Case zugeschnitten. Und da bauen wir grade eine Menge rechts und links noch in luca dran. Und und schau mal, wie die wie die Gameleads damit arbeiten und wie sie wie sie damit zurechtkommen. Das ist für uns auch 'n Learningprozess, ne, dass wir dass wir immer mal 'n bisschen was verbessern, ja, was Neues den Gameleads zur Verfügung stellen, dann mal schauen, wie sie damit zurechtkommen und eventuell ja kommt's an, vielleicht auch nicht. Mhm. Und wenn
Dennis: Du sagst, Du baust dann was luca rum, also ist es dann irgendwas, was dort als, weiß ich nicht, Plug in oder Extension oder ist es 'n komplett separates?
???: Wir haben das Tooling, was wir in luca haben, kontinuierlich erweitert. Zusätzlich haben wir jetzt aber auch 'n paar Webtools gebaut, da verwenden wir dafür. Das ist im Prinzip so im Data Bereich ein, ja, son Framework, was es relativ einfach erlaubt, so Daten Datentools, die halt so kleine ja Datenanalysen erlauben, mit relativ wenig Code in einen in eine Web GUI zu gießen. Mhm. Und damit haben wir eigentlich sehr gute Erfahrungen gemacht.
Dennis: Okay, cool. Tja, jetzt haben wir schon einiges analysiert. Ich überlege grad, ob's noch Ich gucke mal wieder in die Runde. Entweder Tobi, Du hast noch was und sagst, hey, das haben wir jetzt noch komplett ausgelassen oder die anderen beiden sagen noch, da fehlt noch was?
Tobias: Nicht unbedingt, dass da da was fehlt, aber ich glaub, was noch mal 'n ganz interessanter Punkt ist, wir hatten ja in der Folge mit WeChat schon mal drüber gesprochen, warum sammeln wir überhaupt diese ganzen Rohdaten und nehmen nicht einfach Google Analytics?
???: Mhm. Und ich
Tobias: glaube, das kann man jetzt so im Data Analytics Bereich wieder son bisschen sich anschauen, warum nutzen wir nicht für alles luca? Und da hat Tobi ja grad auch schon gesagt, irgendwann stößt luca an seine Grenzen. Ich glaub, ein interessanter Teil unserer Arbeit so im Bereich Data Analytics ist halt auch noch, dass wir durchaus häufiger mal so ad hoc oder so One Time Analysen machen, weil halt Looker einfach nicht alle Möglichkeiten gibt, wenn's mal wirklich tiefergehender Analysen bedarf. Und das, denk ich, ist halt auch noch 'n spannender Teil der Data Analytics Arbeit, wo wir dann wirklich den Wert der Rohdaten nutzen können und da dann stärker ins Detail gehen.
Dennis: Hört ihr zufällig 'n einigermaßen greifbares Beispiel ein
Tobias: Also ich meine Sachen, wo ich glaube, wo wir in letzter Zeit wirklich einiges noch mal gemacht haben, sind zum Beispiel 4 Bilder ein Wort, wo wir die ganze Coin Economy detaillierter durchsucht haben und Verteilungen uns dann angeschaut haben. Und ja, meinetwegen halt auch so uns angeschaut haben, bei welchen Kontoständen der virtuellen Währung Spieler*innen bestimmte Sachen machen und so was lässt sich halt den Lookal nicht mehr mit 'nem ganz einfachen Look abbilden. Und ich glaub auch, dass wir noch durchaus einiges gemacht haben für 1 unserer neueren Spiele, The Test, wo's dann halt auch noch mal son bisschen mehr darum ging, zum Beispiel wirklich so den den Content zu analysieren. Also das The Test ist halt 'n Spiel, wo's darum geht, wo man mit Freunden Fragen beantwortet und da natürlich dann auch eine interessante Frage ist, wie zum Beispiel der Inhalt von Fragen mit dem Engagement zu tun hat. Und das sind so Sachen, da würd ich sagen, stößt Luca und seine Grenzen. Fallen euch sonst noch gute Beispiele an? Ich mein, bei euch in den Teams, in denen ihr
???: Meistens schon bei Segmentierungen, dass es dann trotzdem einfachere ist. Mal, wenn Du von 'ner Subgruppe von Nutzer was analysieren willst, brauchst Du eigentlich immer, dass Du diese Subgruppe aussondest. Also sone, das baust und dann son Squara mit soner City heißt das dann. Das ist ja das kurz mal so, hey, das sind die Nutzer, die ich anseheme und dann Mhm. Ansehe ich da die die Events oder die Und das ist dann in Dubai möglich, aber ja, ist dann schwieriger umsetzbar. Und für uns ist auch immer da son bisschen das Ding, habt ihr auch hier jetzt herausgehört. Wir wollen Freiheit geben, aber Freiheit kommt auch mit so Marke, ne. Wenn man mehrere Wegen nach Rom hat, mal zum Beispiel die Purches, gibt's Gefahr, Furish Analyse und so. Und deswegen auch bei so was Segmentierungen ist es immer schon mal gut, da auch ja, Ergebnisse zu unterstützen und dann trotzdem das 'n bisschen aus Looker zu halten.
???: Ja, es gibt immer so Use Cases. Das ist ja das, was ich beschrieben habe. Lucke ist son Baukastensystem und der Baukasten, ja, man kann den erweitern. Und man muss ja irgendwann die Frage stellen, lohnt es sich, den Baukasten zu erweitern oder machen wir halt außerhalb von Lucke eine eine Analyse für einen etwas komplizierteren Use Case? Also das geht dann halt häufig los mit zu sagen, ja, ich möchte, was Wessel grade gesagt hat, eine Analyse machen für Nutzer, die aber nur ein bestimmtes Event, ne, die irgendwo draufgeklickt haben und dann irgendwas anderes gemacht haben. Und dann wird's natürlich in luca sehr schwierig. Und das muss man halt wirklich von Fall zu Fall sehr individuell machen. Und das ist halt auch so Ad hoc Analysen, die wir sehr viel machen. Dann nutzen wir SQL, Python, Jupiter Notebooks, 'n bisschen was halt für den Use Case, wo wir glauben, das ist genau der das richtige Tooling dafür. Und da lohnt es sich dann teilweise nicht, Sachen halt groß vorzubereiten, weil wir sind relativ sicher, na ja, das wird wahrscheinlich je nur einmal gebraucht. Da ist diese die Nachhaltigkeit, dass so was halt wiederverwendbar sein muss, dann einfach auch nicht gegeben.
Dennis: Cool. Dann würde ich sagen, kommen wir zum Ende unserer zweiten Folge.
Tobias: Wer steht die Hand?
Dennis: Sehr gut.
???: Ich hab noch eine gute Idee aus
Dennis: dem Name.
???: Weißt Du so, programmier.bar, weil es eine Bar ist, Programmier Bebar, hört man so, eine Bebar.
Dennis: Für die ganze Folge meinst Du die Programmier Beaper. Ja. Weil ihr seid die 3, ihr seid dann die 3 Programmier Beaper.
???: Ja, genau.
Dennis: Das ist schön.
???: Ich glaub, okay, die würd sich freuen, da so Bilder davon zu machen. Das
Dennis: ist ja. Ist auch ist auch sehr, also kommt auch direkt allen dann direkt, glaube ich.
???: Aber wenn wir's
Dennis: auch als Cover machen oder so. Und gleich Merch. Bisschen Jingle Ei euch als Ja. Biegemutation. Schön.
???: Wir können's aber auch umdrehen und nicht bibör, sondern Barbie.
???: Rausmachen. Ja. Tobi ist die Barbe, oder wie ist nicht? Biber. Beides nicht schlecht. Oder 'n Zara.
Dennis: Ja, kann man viel mit dem b machen. Schön. Wir gucken mal, wenn wir bei der dritten Folge ankommen, ob wir dann schon noch noch bessere Namen und Ideen gefunden haben, wie wir diese Minireihe nennen können. Bis dahin schon mal vielen Dank fürs Zuhören, wie immer Feedback gerne an den Wesselprogrammierpunkt war.
???: Der der Vielleicht muss man das auch buchstabieren oder?
Dennis: Wessel, das ist richtig. WESSEL Genau. At Programmier Punkt bar. Er freut sich über persönliche Post von euch. Wenn ihr allgemeineres Feedback habt, schreibt gerne einen Podcast Ad programmier.bar und ja, seid gespannt. In der dritten Folge wird's Predictive Analytics gehen. Ein bisschen in die Zukunft gucken und bis bald. Macht's gut.
???: Vielen Dank.

Data Analytics mit Tobias Lampert

Shownotes

Speaker Info

Tobias Lampert

Verwandte Podcasts

Predictive Analytics mit Fabian Hadiji

Data Engineering mit Wessel van de Goor

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