Ein Tag im Leben eines Data Analysts

Die Stellenbeschreibung lautete „Insights entwickeln, die Geschäftsentscheidungen informieren." Dann kommt der erste Slack-Ping um 8:47 Uhr: „Hey, kurze Frage: Warum weicht der MRR um 3.000 Dollar vom letzten Board-Deck ab?" Und Sie verbringen die nächsten neunzig Minuten damit, zu beweisen, dass das Deck korrekt war.

Diese Lücke zwischen Stellenanzeige und Arbeitsalltag erklärt, warum die Mitarbeiterfluktuation bei Data Analysts in SaaS-Unternehmen bei etwa 22 bis 28 Prozent pro Jahr liegt. Niemand hat Sie darauf vorbereitet, dass die Rolle zur Hälfte aus SQL, zur Hälfte aus Übersetzungsarbeit und zu einem Viertel aus dem Verteidigen von Zahlen besteht, die Sie vor drei Monaten geschrieben haben. (Ja, das ergibt 125 Prozent. Das Rechnen ist Teil des Problems.)

Das hier ist, wie ein echter Dienstag für einen Data Analyst IC bei einem B2B SaaS- oder Mid-Market-Unternehmen mit ein bis vier Jahren Berufserfahrung aussieht. Nicht die LinkedIn-Version. Die echte.

Warum das jetzt wichtig ist

Das Volumen an Ad-hoc-Anfragen hat sich seit der Verbreitung von Self-Service-BI-Tools ungefähr verdoppelt. Jede Produktmanagerin möchte bis Dienstag einen individuellen Kohortenschnitt. Jeder VP hat eine Hypothese, die bis Freitag validiert sein soll. Die Werkzeuge versprachen demokratisierte Daten und lieferten stattdessen eine Anfragenlawine.

Kandidatinnen und Kandidaten, die sich in diesen Job hineindenken als ruhigen Schreibtischtag voller Modellarbeit, kündigen innerhalb von achtzehn Monaten. Wer bleibt, lernt etwas, das die Stellenanzeige nie erwähnt: die eigene Denkzeit zu schützen und gleichzeitig erreichbar zu wirken. Das ist die eigentliche Senior-Kompetenz.

Wer einstellt, sollte das wissen, um die richtigen Fragen im Screening zu stellen. Wer als Analyst arbeitet, kann durch das Benennen dieser Muster besser damit umgehen. Gehen wir den Tag durch.

8:00 Uhr: Dashboard-Gesundheitscheck

Bevor Slack geöffnet wird, bevor die ersten Stakeholder aufgewacht sind, werden die sechs bis acht Dashboards überprüft, die die Führungskräfte tatsächlich öffnen. Nicht alle zwanzig, die Sie gebaut haben. Die, auf die geklickt wird.

Dabei suchen Sie nach drei Dingen:

• NULL-Werte, wo keine sein sollten. Eine Umsatzzahl, die für gestern leer angezeigt wird. Eine Anmeldeanzahl, die an einem Mittwoch null zeigt.
• Defekte Verknüpfungen nach dem gestrigen dbt-Lauf. Ein Modell ist stillschweigend fehlgeschlagen, und das Dashboard zeigt veraltete Daten mit einem aktuellen Zeitstempel. Das ist die schlimmste Art von Fehler, weil ihn niemand bemerkt, bis jemand eine Entscheidung darauf basiert.
• Ungewöhnliche Ausreißer. Der Traffic ist viermal so hoch wie üblich? Entweder hat das Marketing etwas gestartet, von dem Sie nichts wussten, oder ein Tracking-Event feuert doppelt. Beides rechtfertigt eine Slack-Nachricht, bevor jemand anderes fragt.

Die gesamte Überprüfung dauert fünfzehn Minuten, wenn alles in Ordnung ist. Fünfundvierzig, wenn nicht. Ziel ist es, den Fehler zu finden, bevor der CFO das Dashboard um 9:15 Uhr öffnet und fragt: „Stimmt das so?"

Ein sauberer Morgencheck ist unsichtbare Arbeit. Sie werden dafür keine Anerkennung erhalten. Aber an dem Tag, an dem Sie ihn überspringen, sieht ein Vorstandsmitglied fehlerhafte Zahlen. Und dieser Tag ist deutlich lauter als die hundert ruhigen Morgen davor.

9:30 Uhr: Ad-hoc-Anfragen-Triage

Die Jira-Warteschlange hat elf neue Tickets. Slack zeigt sechs direkte Nachrichten. Ein VP hat Ihr privates Telefon angeschrieben, was Sie bereuen, ihm auf der Weihnachtsfeier gegeben zu haben.

Triage bedeutet Sortieren, nicht Lösen. Jede Anfrage kommt in einen von vier Bereichen:

• 10-Minuten-Abruf. Jemand möchte eine Anzahl, eine Liste, einen schnellen Filter. Diese werden sofort erledigt, die Antwort im Thread gepostet, dann weiter.
• 2-Tage-Analyse. Echte Fragen, die ein Modell, eine Kohorte oder ein schriftliches Ergebnis erfordern. Diese werden eingeplant.
• Duplikat. Jemand fragt, was jemand anderes letzten Monat gefragt hat. Die alte Antwort wird gesucht, verlinkt, das Ticket wird geschlossen. Höflich.
• Unklar. Die Anfrage nennt keine Entscheidung, die sie unterstützen soll. Diese brauchen eine kurze Rückfrage, die vier Stunden Arbeit spart.

Diese Frage lautet: „Welche Entscheidung wird das beeinflussen?"

Freundlich formuliert: „Ich kümmere mich gern darum. Kurze Vorabfrage: Was werden Sie je nach Datenergebnis anders machen?" Lautet die Antwort „nichts, ich bin nur neugierig", kann ehrlich deprioritisiert werden. Lautet sie „Wir entscheiden am Freitag, ob wir den Trial-Flow abschalten", wird die Anfrage eskaliert. So oder so haben Sie Ihren Job erledigt, bevor eine Zeile SQL geschrieben wurde.

Eine praktische Aufnahme-Vorlage, die Sie in Jira, Linear oder was auch immer Sie nutzen einfügen können:

**Entscheidung, die diese Analyse informieren soll:**
**Datum, bis wann Sie sie benötigen:**
**Wer das Ergebnis noch prüft:**
**Was Sie bereits geprüft haben:**
**Erforderliche Präzision (grobe Schätzung oder auditgerechte Genauigkeit):**

Die Hälfte der Anfragen scheitert bereits am ersten Feld, weil die anfragende Person erkennt, dass sie noch keine Entscheidung getroffen hat. Das ist beabsichtigt.

11:00 Uhr: Anforderungsinterview am Vormittag

Dreißig Minuten Zoom mit einer Produktmanagerin, die sagte: „Ich brauche Churn-Daten."

Die eigentliche Anfrage liegt immer drei Ebenen tiefer. Ihre Aufgabe ist es, von vage zu konkret zu gelangen, ohne sie das Gefühl zu geben, eine dumme Frage gestellt zu haben. Der Trick liegt in diagnostischen Fragen, nicht in Verhörfragen.

Ein funktionierender Ablauf:

1. Wiederholen, dann präzisieren. „Sie möchten also Abwanderung verstehen. Damit ich das richtig aufbereite: Meinen Sie Kunden-Abwanderung, Umsatz-Abwanderung oder Logo-Abwanderung? Die Kennzahlen entwickeln sich unterschiedlich."
2. Nach der Entscheidung fragen. „Was werden Sie mit dem Ergebnis tun? Planen Sie Headcount für ein Retention-Team oder suchen Sie das Segment, das zuerst optimiert werden soll?"
3. Die Kohorte definieren. „Wenn Sie von ‚abgewanderten Kunden' sprechen: Meinen Sie Kündigungen in den letzten 30 Tagen oder Kündigungen ohne Reaktivierung? Und zählt ein Downgrade dazu?"
4. Ein Präzisionsziel festlegen. „Brauchen Sie das richtungsweisend bis EOD, oder auditgerecht für das QBR? Die Antwort ändert meinen Aufwand um etwa einen Tag."

Die meisten Produktmanagerinnen möchten vor der Führungsebene keine Unsicherheit zeigen, also formulieren sie Anfragen in der Sprache des Decks, das sie präsentieren müssen. Ihre Aufgabe ist es, das in eine Frage zurückzuübersetzen, die SQL beantworten kann. Sie untergraben die Person nicht, indem Sie fragen. Sie schützen sie davor, ein Diagramm zu präsentieren, das nicht das aussagt, was sie glaubt.

Camellias Regel: Lassen Sie keine Stakeholder ein Anforderungsgespräch verlassen, ohne dass beide laut gesagt haben, was das Ergebnis ist, was die Kohorte ist und welche Entscheidung es unterstützt. Wenn Sie das nicht in eine einzige Slack-Nachricht nach dem Meeting fassen können, haben Sie noch keine Spezifikation.

13:30 Uhr: Asynchrone Arbeit mit Engineering und Product

Das Zeitfenster zwischen Mittag und 16 Uhr ist für die Arbeit reserviert, um die niemand bittet, die aber darüber entscheidet, ob das nächste Quartal handhabbar sein wird.

Das ist der Async-Block. Drei Arten von Eingaben:

dbt-PR-Reviews. Ein Data Engineer hat geändert, wie das fct_subscriptions-Modell Trial-Conversions behandelt. Sie lesen den Diff. Ein Kommentar, der tatsächlich nützlich ist:

Diese Änderung sieht für neue Trials richtig aus, aber ich denke,
sie wird jeden Account doppelt zählen, der im selben Quartal
konvertiert, downgradet und dann wieder konvertiert. Wir haben
davon etwa 40 pro Quartal (geprüft in #data-quality letzten Monat).
Können wir einen Test zur Eindeutigkeit von `subscription_id` im
Staging-Modell hinzufügen, bevor das gemergt wird? Ich schreibe ihn
gern.

Konkret. Verweist auf echte Daten. Bietet Hilfe an. Blockiert den PR nicht aus vagen Gründen.

Product-Spec-Kommentare. Eine Produktmanagerin hat eine Spezifikation für einen neuen Onboarding-Flow eingereicht. Im Abschnitt zur Event-Verfolgung steht „onboarding_completed feuern, wenn der Nutzer fertig ist." Sie hinterlassen einen Kommentar: Welcher Schritt gilt als „fertig"? Was passiert, wenn Schritt drei übersprungen wird? Soll onboarding_completed für jede Flow-Variante gefeuert werden oder gibt es separate Events? Besser jetzt fragen als in sechs Wochen durch fehlerhafte Daten graben.

Hinweise auf Schema-Änderungen. Engineering benennt am Freitag eine Spalte in der Produktion um. Sie suchen in jedem Looker Explore, jedem Hex Notebook und jedem dbt-Modell nach diesem Spaltennamen. Vier Dashboards werden kaputt gehen. Sie schreiben dem Engineering-Lead mit der Liste und verzögern entweder die Umbenennung oder koordinieren die Umstellung. Diese zwanzig Minuten entscheiden zwischen einem ruhigen Samstag und einem Samstag, an dem Sie Executive-Dashboards neu aufbauen, während Ihr Kind fernsieht.

Hier verdienen Senior Analysts ihren Titel. Der IC schreibt das SQL. Der Senior erkennt den Schaden drei Wochen bevor er eintritt.

16:00 Uhr: End-of-Day-Datenabruf für Führungskräfte

Der CFO braucht drei Zahlen für die morgige Board-Vorbereitung. Die Nachricht kam um 15:47 Uhr. Das Board-Meeting ist um 8 Uhr morgens.

Das ist der Moment, in dem SQL auf Einsatz trifft. Sie Abfragen Snowflake (oder BigQuery oder Postgres, je nach Ihrer Unternehmensinfrastruktur) und prüfen jede Zahl gegen die gemeldeten Zahlen des letzten Quartals. Wenn der neue Abruf nicht mit den alten Zahlen übereinstimmt, senden Sie nichts, bis Sie verstehen, warum.

Das Ergebnis sind nicht drei Zahlen. Es sind drei Zahlen plus Kontext. Ein praktisches Format für die Notion- oder Confluence-Notiz:

**Q1 2026 Schnellabruf für Board-Vorbereitung**

1. Netto-Neuabschlüsse ARR: 1,42 Mio. Dollar
   (vs. 1,38 Mio. Dollar im Q4-Deck: +3%, im erwarteten Bereich)
   Hinweis: Enthält 2 Deals mit Close-Datum 31.3., die erst am 2.4.
   gebucht wurden; im strengen Q1-View unten ausgeschlossen.

2. Logo-Abwanderungsrate: 4,1% (annualisiert)
   Strikter Q1-View: 1,40 Mio. Dollar, 4,4%
   Abgerufen um 16:35 Uhr am 28.4.; Aktualisierung möglich vor 8 Uhr.

3. Trial-to-Paid: 18,7%
   (vs. 17,2% in Q4: getrieben durch die Preistest-Kohorte vom Feb.,
   was ein temporärer Anstieg ist, kein struktureller Sprung.
   Bitte nicht linear fortschreiben.)

Quellmodelle: fct_subscriptions, fct_trials, dim_accounts.
Bei Abweichungen zu Ihren Werten bitte melden.

Vier Punkte, vier Zeilen Kontext. Der CFO kann das präsentieren, ohne nochmals nachfragen zu müssen. Und wenn im Board-Meeting jemand sagt „warte, das stimmt nicht mit dem überein, was Sie im Februar sagten", hat der CFO die Antwort bereits parat.

Das ist die Arbeit, die zu Beförderungen führt. Nicht das SQL. Die vier Kontextzeilen darunter.

Die zwei wiederkehrenden Krisen

Zwei Muster werden Ihre Woche verschlingen, wenn Sie sie zulassen. Ihnen einen Namen zu geben hilft.

Krise eins: Die Ad-hoc-Explosion

Sie haben am Montag einer schnellen Anfrage zugestimmt. Die anfragende Person hat einer Kollegin erzählt, wie hilfsbereit Sie waren. Bis Mittwoch haben sich vier Personen in Ihrem direkten Nachrichtenbereich gemeldet. Bis Freitag haben Sie achtzehn Tickets und keine Zeit mehr für das strategische Projekt, nach dem Ihre Führungskraft Sie tatsächlich bewertet.

Das ist die Duplikat-Anfragen-Schleife. Sie verstärkt sich, weil Ja-Sagen im Moment schneller ist als einen Prozess einzurichten, und weil sich jede „kurze Frage" nicht wie eine Anfrage anfühlt. Es fühlt sich einfach wie ein Gespräch an.

Das Muster, das wirklich funktioniert:

• Sprechstunden, zweimal pro Woche. Ein 60-minütiger Block, in dem jede Person mit einer Frage auftauchen kann. Die meisten „Ich brauche eine schnelle Zahl"-Anfragen passen in dieses Format und brauchen gar kein Jira-Ticket.
• Aufnahmeformular für alles andere. Verlinkt in Ihrem Slack-Profil und im Channel-Topic. Enthält die Vier-Felder-Vorlage oben. Wenn jemand Ihnen direkt schreibt, lautet Ihre Antwort: „Gute Frage, tragen Sie es bitte ins Formular ein, damit ich es gegen die anderen zwölf priorisieren kann. Hier ist der Link."
• Eine wöchentliche Zusammenfassung abgeschlossener Tickets. Jeden Freitag in #data gepostet. Drei Zeilen pro abgeschlossenem Ticket: wer gefragt hat, was sie wollten, was die Antwort war. Baut eine durchsuchbare Historie auf, reduziert Duplikate und zeigt dem Team, was Sie tatsächlich geliefert haben.

Das ist keine Behinderung. Es schützt die zehn Stunden konzentrierter Arbeit pro Woche, in denen Sie die Dinge bauen, die wirklich zählen.

Krise zwei: Die Definition-Mismatch-Panik

Slack-Nachricht einer Direktorin, Donnerstag 17:55 Uhr: „Dieser Bericht ist falsch. Aktive Nutzer sind um 30 Prozent gegenüber der Vorwoche gesunken, und das stimmt nicht mit dem überein, was Marketing sieht."

In neunzig Prozent der Fälle ist der Bericht korrekt, und die Direktorin vergleicht zwei verschiedene Definitionen. Marketing zählt als „aktiv" jede Person, die die Website besucht hat. Das Produkt-Dashboard zählt als „aktiv" jede Person, die eine bedeutungsvolle Aktion abgeschlossen hat. Beide sind korrekt. Sie werden nie übereinstimmen.

Das Triage-Skript:

1. Dringlichkeit anerkennen, ohne selbst in Panik zu geraten. „Ich schaue jetzt nach und melde mich in zehn Minuten mit dem Befund."
2. Zuerst die Definition prüfen, dann die Zahl. Welches Feld nutzt die Quelle der Direktorin? Welches Feld nutzt das Dashboard? Sind sie verschieden, ist das Problem bereits gelöst.
3. Eine Gegenüberstellung anbieten. Nicht nur sagen „sie nutzen unterschiedliche Kennzahlen." Die zwei Zahlen nebeneinander zeigen, mit den Definitionen darunter. „Marketings Quelle: Seitenaufruf-aktiv, 142.000. Dashboard: Aktion-aktiv, 98.000. Der Rückgang von 30 Prozent ist real, wenn man Aktion-aktiv meint; es ist ein Rückgang von 4 Prozent, wenn man Seitenaufruf-aktiv meint."
4. Den Mismatch dokumentieren. Eine Notiz im Datenkatalog oder Definitionsdokument hinzufügen. In der Antwort verlinken. Beim nächsten Mal nur den Link schicken.

Die Direktorin hat nicht Unrecht. Sie arbeitet mit einer anderen Definition. Ihre Aufgabe ist es, die Definitionslücke schnell genug aufzudecken, damit niemand ein Deck neu erstellen muss.

Stack-Realitätscheck

Die Werkzeuge, die Sie tatsächlich anfassen werden:

• SQL. Snowflake, BigQuery oder Postgres. Lernen Sie das, was Ihr Unternehmen nutzt. Fensterfunktionen, CTEs und QUALIFY (Snowflake/BQ) decken 90 Prozent der Arbeit ab.
• Ein BI-Tool. Looker, Tableau, Hex oder Mode. Jedes hat eine andere Philosophie: Looker setzt auf eine semantische Schicht, Tableau ist visuell per Drag-and-drop, Hex und Mode setzen auf Notebook-Stil mit SQL und Python. Sie werden sich auf das spezialisieren, das Ihr Unternehmen gewählt hat. Versuchen Sie nicht, gleichzeitig Looker-Experte und Tableau-Experte zu sein; LookML und Tableau-Berechnungssyntax übertragen sich nicht gut.
• dbt für die Datenmodellierung. Liest YAML und schreibt SQL. Wenn Ihr Unternehmen ein Data-Engineering-Team hat, werden Sie deren PRs häufiger reviewen als eigene Modelle schreiben, aber Sie müssen dbt fließend lesen können, um zu verstehen, was hinter jedem Dashboard steht.
• Notion oder Confluence. Für Dokumentation, Entscheidungsaufzeichnungen und die vierzeiligen Kontextnotizen. Das Werkzeug ist egal; die Disziplin, Dinge aufzuschreiben, ist es nicht.
• Jira (oder Linear oder Shortcut). Für die Anfragewarteschlange. Welches System Ihr Unternehmen auch für Engineering-Tickets nutzt, leiten Sie Datenarbeit ebenfalls darüber. Wenn Daten in einem separaten System leben, werden sie ignoriert.

Wenn eine Stellenbeschreibung alle fünf als Anforderung aufführt und gleichzeitig Expertenwissen in jedem erwartet, ist das ein Warnsignal. Niemand ist in allen fünf Experte. Die ehrliche Version: tiefes Wissen in einem BI-Tool, fließendes SQL, komfortables Lesen von dbt, Ordnung in Notion, Reaktionsfähigkeit in Jira. Das war es.

Was die Stellenanzeige Ihnen nicht sagt

Ungefähr fünfzig Prozent Ihrer Woche sind Kommunikation und Übersetzung, keine Analyse. Anforderungsgespräche, Slack-Threads, Definitionsdebatten, asynchrone PR-Reviews, End-of-Day-Kontextnotizen. SQL ist die Spitze des Eisbergs.

Ihre am häufigsten genutzte Fähigkeit ist: „Welche Entscheidung versuchen Sie zu treffen?" Die zweithäufigste ist: Nein zu sagen, ohne behindernd zu wirken. Die dritthäufigste ist: Entscheidungen zu dokumentieren, damit der nächste Analyst sie nicht neu aushandeln muss.

Die IC-Analysten, die ausbrennen, sind diejenigen, die glauben, dass SQL der Job ist. Wer befördert wird, hat erkannt, dass SQL zwanzig Prozent des Wertes ausmacht, und die anderen achtzig Prozent sind alles drum herum: die Triage, die Übersetzung, die Kontextzeilen, die Definitionsdokumentation, der Freitagsdigest.

Wenn das nach dem Job klingt, den Sie wollen, werden Sie gut abschneiden. Wenn es wie ein Bait-and-Switch klingt, ist das eine faire Einschätzung. Besser jetzt wissen als nach drei Jahren.

Mehr erfahren

• Data Analyst Stellenbeschreibung
• Ad-hoc-Datenanfragen triage
• Ein Stakeholder-Anforderungsinterview durchführen
• Zahlen verteidigen, wenn ein Director sagt „Das ist falsch"