Erstellen Sie einen Monitor für Gewinn- und Unternehmensnachrichten

Ein Earnings-Nachrichtenmonitor ist ein Watchlist-gestützter Dienst, der zwei Datenströme über denselben Satz von Tickers zusammenführt: den geplanten Earnings-Kalender (Sie wissen wann ein Unternehmen berichtet) und den ungeplanten Unternehmensnachrichtenfeed (Sie wissen nicht wann eine Geschichte bricht). Er gewichtet jedes Element danach, wie nah es zum Berichtsdatum liegt. Die meisten Tutorials bauen nur die Hälfte davon. Sie fragen entweder einen Nachrichts-API nach Ticker ab, oder sie ziehen einen Earnings-Kalender und stoppen. Diese Anleitung baut das Ganze in Python: eine Watchlist, zwei Ebenen, eine Earnings-Window-Relevanzregel und eine Poll-Schleife mit Persistenz.

Dieses Tutorial richtet sich an FinTech-Entwickler, die eine Unternehmensnachrichten-Watchlist oder einen Aktiennachrichten-Tracker erstellen, der den Unterschied zwischen einer routinemäßigen Schlagzeile vom Dienstag und einer Geschichte, die am Tag vor der Berichterstattung eines Megacaps veröffentlicht wird, erkennen muss. Am Ende verfügen Sie über einen lauffähigen Monitor und ein numerisches Framework zur Entscheidung, was angezeigt werden soll.

Offenlegung: Dieses Tutorial wird von APITube (apitube.io), einem Anbieter von Nachrichten-API, veröffentlicht, und die Live-Aufrufe nutzen dessen API für die Nachrichtenebene. Die Methode ist anbieterneutral: Jede Echtzeit-Finanznachrichten-API, die Entity-Tagging und einen Filter für das Veröffentlichungsdatum bietet, funktioniert für die Nachrichtenseite, und jede Quelle für einen Gewinnkalender (oder Ihre eigene Datenbank mit Berichtsdaten) funktioniert für die Kalenderseite. APITube bietet keinen Endpunkt für Gewinnkalender – daher kombiniert dieser Monitor ihn bewusst mit einem externen Kalender, und der Code macht diese Nahtstelle explizit. Dies ist ein technisches Tutorial, keine Anlageberatung; die Relevanzbewertungen entscheiden, was angezeigt wird, nicht was gehandelt wird.

Wichtige Erkenntnisse:

• Ein Monitor, der nur den Kalender oder nur die Nachrichten beobachtet, ist halb blind – der Wert liegt in der Verschmelzung beider über eine Watchlist.
• Der Ergebnis-Kalender sind geplante Daten; Unternehmensnachrichten sind ungeplante Daten. Sie erfordern unterschiedliche Abrufstrategien, aber ein gemeinsames Relevanzmodell.
• Das Ergebnis-Fenster – ungefähr T-5 bis T+2 Handelstage um ein Berichtsdatum herum – ist die Zeit, in der Unternehmensnachrichten am wichtigsten sind. Gewichtung nach Nähe, nicht nur nach Anwesenheit.
• Der gesamte Monitor ist eine Watchlist, zwei Fetcher, eine Fusionsregel und eine persistente Abrufe-Schleife – etwa 120 Zeilen Python.

Inhaltsverzeichnis

• Warum die reine Kalender- oder Nachrichtenüberwachung eine halbe Blindheit ist
• Die beiden Ebenen: geplant vs. ungeplant
• Der Earnings-Window-Rahmen
• Erstellen Sie es: Watchlist → Kalender → Nachrichten → Fuse → Persist
• Produktionsstart
• FAQ

Warum nur Kalender- oder nur Nachrichtenüberwachung blind ist

Ein Kalender-only-Monitor und ein News-only-Monitor sind jeweils blind für die Hälfte dessen, was eine Aktie um Gewinne herum bewegt.

Ein reines Kalender-Tool weiß, dass Nvidia nach Börsenschluss am Juni 17 berichtet. Es weiß nicht, dass zwei Tage zuvor eine Meldung über die Lieferkette oder ein Analysten-Leak den Namen bereits bewegt. Der Kalender sagt Ihnen, wann das geplante Ereignis stattfindet; er sagt nichts über die ungeplanten Nachrichten aus, die sich darum ballen.

Ein Tool, das sich nur auf Nachrichten konzentriert, hat die gegenteilige Blindheit. Es erfasst jede Nvidia-Schlagzeile in Echtzeit, behandelt sie aber alle gleich. Es kann nicht erkennen, dass eine alltägliche Produktankündigung in einer ruhigen Woche und eine Schlagzeile mit Gewinnwarnung am Tag vor dem Bericht völlig unterschiedliche Dringlichkeit verdienen. Ohne den Kalender ist jede Schlagzeile kontextfrei.

Der Markt ist genau entlang dieser Linie aufgeteilt. Nachrichten-zentrierte APIs wie Finnhubs Unternehmensnachrichten-Endpunkt und Newsfilter.io – die das Indizieren von Artikeln in unter 500 Millisekunden mit NLP Ticker-Tagging bewerben – bieten Ihnen einen schnellen Stream ohne die Vorstellung, wann ein Unternehmen berichtet. Kalender-zentrierte APIs wie Financial Modeling Preps Ergebnis-Kalender liefern Ihnen Berichtstermine und EPS-Schätzungen ohne Nachrichten. Fast niemand fusioniert sie. Diese Lücke ist der Grund, dies selbst zu bauen, anstatt eine fertige Lösung zu kaufen.

Die Lösung ist kein intelligenterer Nachrichtenfeed oder ein umfangreicherer Kalender. Es ist ein kleines Stück Klebstoff: ein Monitor, der eine Watchlist führt, den Kalender fragt „Wann berichtet dieser Ticker?“ und die Nachrichten-API „Was gibt es Neues bei diesem Ticker?“, und kombiniert dann beides zu einer einzigen Relevanzzahl.

Die zwei Ebenen: geplant vs. ungeplant

Eine Nachrichten-Watchlist eines Unternehmens muss zwei grundlegend unterschiedliche Datenarten verarbeiten. Sie gleich zu behandeln, ist der Fehler. Hier ist die Unterscheidung, die das gesamte Design bestimmt:

Die geplante Ebene ist billig und bewegt sich langsam: Das nächste Berichtsdatum eines Tickers ändert sich vielleicht einmal pro Quartal, also aktualisieren Sie es einmal täglich und cachen Sie es. Die ungeplante Ebene ist der Feuerlöscher: Sie fragen ihn kontinuierlich ab und behalten den Status pro Ticker, damit Sie dasselbe Fenster nie erneut verarbeiten.

Die Aufgabe des Monitors ist es, der Ort zu sein, an dem diese beiden aufeinandertreffen. Er verwendet die geplante Ebene als Kontext und die ungeplante Ebene als Inhalt. Eine Schlagzeile ist nur eine Schlagzeile, bis der Kalender Ihnen mitteilt, dass sie in ein Gewinnfenster gefallen ist – dann ist es eine Gewinnüberraschungswarnung. Im Gegensatz zu einem reinen Nachrichten-Feed, der jede Schlagzeile gleich behandelt, liest ein fusionierter Monitor jede Schlagzeile durch den Kalender. Dieselbe Meldung über Margenwarnungen erzielt am Tag vor einem Bericht weit höhere Werte als drei Wochen zuvor.

Das Ertragsfenster-Framework

Dies ist die Regel, die die Ebenen verschmilzt. Das Gewinnfenster ist der Zeitraum von Handelstagen um das Berichtsdatum, in dem Unternehmensnachrichten das meiste Signal tragen. Definieren Sie es numerisch und gewichten Sie Nachrichten nach Nähe zum Bericht.

Die folgenden Standardwerte sind ein Ausgangspunkt – passen Sie sie an Ihre eigenen Daten an –, aber die Struktur ist wichtiger als die genauen Zahlen:

Zwei Designentscheidungen sind bewusst getroffen worden. Erstens wird das Fenster in Handelstagen, nicht Kalendertagen gemessen – ein Bericht am Montag bedeutet, dass der vorherige Freitag T-1 ist, nicht drei Kalendertage zurück. Das Zählen von Wochentagen hält das Fenster mit den Marktphasen, auf die tatsächlich reagiert wird, synchron. Zweitens ist der Multiplikator asymmetrisch: Das Fenster öffnet sich weiter vor dem Bericht (T-5) als es sich danach schließt (T+2), da der Anstieg länger und unruhiger ist als die unmittelbare Reaktion.

Der Multiplikator ersetzt keinen Basis-Relevanzwert – er skaliert ihn. Eine schwache Schlagzeile im Spitzenfenster und eine starke Schlagzeile weit außerhalb können zu ähnlichen Endwerten führen, was genau richtig ist: Ein wegwerfbarer kurzer Beitrag sollte nicht nur feuern, weil die Gewinne morgen sind, und eine Margenwarnung sollte nicht ignoriert werden, nur weil der Bericht drei Wochen entfernt ist. Wenn Sie einen reichhaltigeren Basiswert wünschen – Überraschung, Glaubwürdigkeit der Quelle, Berichterstattungshöhepunkte –, entwickelt unser Begleitleitfaden „Build Real-Time Market-Moving News Alerts“ dieses Bewertungsmodell im Detail. Dieser Artikel hält die Basis bewusst einfach, damit die Fusionslogik im Fokus bleibt.

Erstellen Sie es: Watchlist → Kalender → Nachrichten → Fuse → Persist

Der Monitor hat fünf Teile: eine Watchlist von Tickersymbolen, einen Kalender von Berichtsterminen, einen Nachrichten-Fetcher, eine Fusionsregel (Basisrelevanz × Fenster-Multiplikator) und eine persistente Poll-Schleife. Beginnen Sie mit einer echten Nachrichtenanfrage.

curl -s "https://api.apitube.io/v1/news/everything?api_key=YOUR_KEY&title=Nvidia&category.id=business&language.code=en&published_at.start=2026-06-15T00:00:00Z&per_page=50"

Jeder Artikel enthält die Felder, die die Fusionsregel benötigt – Entitäts-Tagging, Kategorien, Quell-Ranking und eine Story-ID zur Deduplizierung:

{
  "results": [
    {
      "id": 3211554477,
      "href": "https://www.reuters.com/technology/nvidia-...",
      "published_at": "2026-06-15T13:42:00.000Z",
      "title": "Nvidia guides Q3 revenue above Wall Street estimates",
      "language": { "code": "en" },
      "story": { "id": 3211554477 },
      "is_duplicate": false,
      "source": { "domain": "reuters.com", "rankings": { "opr": 8 } },
      "sentiment": { "overall": { "score": 0.42, "polarity": "positive" } },
      "entities": [
        { "id": "nvidia-corp", "name": "Nvidia", "type": "organization", "frequency": 5 }
      ],
      "categories": [
        { "id": "business", "name": "business" },
        { "id": "earnings", "name": "earnings" }
      ]
    }
  ]
}

Die Watchlist und der Kalender

Die Watchlist ordnet ein Tickersymbol dem Firmennamen zu, wie die Nachrichten-API es kennzeichnet. Der Kalender ordnet ein Tickersymbol seinem nächsten Berichtsdatum zu – und das ist die ehrliche Nahtstelle: APITube hat keinen Gewinnendpunkt, daher stammen diese Daten aus einer externen Gewinnkalenderquelle (FMP, die Daten Ihres Brokers oder ein manuell gepflegtes Wörterbuch). Behalten Sie den Kalender als einfaches Wörterbuch bei, damit die Fusionslogik nicht darauf angewiesen ist, woher die Daten stammen.

from datetime import date

# ticker -> company name as the news API tags it
WATCHLIST = {
    "NVDA": "Nvidia",
    "AAPL": "Apple",
    "TSLA": "Tesla",
}

# ticker -> next earnings report date.
# APITube has NO earnings-calendar endpoint — these come from an external
# source (e.g. FMP /earnings-calendar) or your own database. Refresh daily.
EARNINGS_CALENDAR = {
    "NVDA": date(2026, 6, 17),   # reports after market close
    "AAPL": date(2026, 7, 30),
    "TSLA": date(2026, 7, 22),
}

Der Multiplikator für das Ergebnis-Fenster

Zähle Geschäftstage zwischen heute und dem Berichtsdatum, vorzeichenbehaftet (negativ = vor dem Bericht), und ordne den Offset einem Multiplikator zu. Dies ist das Framework aus dem vorherigen Abschnitt, im Code:

from datetime import date, timedelta

def business_days_between(start: date, end: date) -> int:
    """Signed count of weekdays from start to end (negative if end is earlier)."""
    if start == end:
        return 0
    step = 1 if end > start else -1
    days, cur = 0, start
    while cur != end:
        cur += timedelta(days=step)
        if cur.weekday() < 5:          # Mon–Fri only
            days += step
    return days

def window_multiplier(today: date, report_date: date | None) -> float:
    if report_date is None:
        return 1.0
    offset = business_days_between(today, report_date)
    if offset in (-1, 0, 1):
        return 3.0                     # peak: T-1, report day, T+1
    if -5 <= offset <= 2:
        return 2.0                     # hot window: T-5..T-2 and T+2
    return 1.0                         # outside the window

Basis-Relevanz und Fusion

Der Basis-Score bleibt bewusst klein – Entitäts-Prominenz, eine Übereinstimmung mit der Finanzkategorie und Glaubwürdigkeit der Quelle. Der Fenster-Multiplikator erledigt die umsatzabhängige Arbeit:

FINANCE_CATS = {"business", "earnings", "stock market",
                "mergers and acquisitions", "economy"}

def base_relevance(article: dict, company: str) -> float:
    score = 0.0
    for e in article.get("entities", []):
        if e.get("name") == company and e.get("type") == "organization":
            score += min(e.get("frequency", 1), 5) * 4   # up to 20
            break
    cats = {c.get("name") for c in article.get("categories", [])}
    if cats & FINANCE_CATS:
        score += 10
    if (article.get("source", {}).get("rankings", {}) or {}).get("opr", 0) >= 6:
        score += 5                                       # credible source
    return score

def relevance(article: dict, company: str, today: date,
              report_date: date | None) -> tuple[float, float]:
    mult = window_multiplier(today, report_date)
    return base_relevance(article, company) * mult, mult

Die persistente Abrufe-Schleife

Die Schleife ruft Nachrichten pro Ticker seit dem letzten gesehenen Zeitstempel ab, berechnet die fusionierte Relevanz, dedupliziert nach story.id und zeigt alles über einem Schwellenwert an. Pro-Ticker-last_seen und ein globaler seen_stories-Satz sind die Persistenz – in der Produktion leben diese in Redis, nicht im Speicher.

import time, requests
from datetime import datetime, timezone

BASE = "https://api.apitube.io/v1/news/everything"
API_KEY = "YOUR_KEY"
SURFACE_THRESHOLD = 30.0
POLL_SECONDS = 30

def fetch_news(company: str, since_iso: str) -> list[dict]:
    r = requests.get(BASE, params={
        "api_key": API_KEY,
        "title": company,                 # or entity.id for tighter matching
        "category.id": "business",
        "language.code": "en",
        "published_at.start": since_iso,
        "per_page": 50,
    }, timeout=10)
    r.raise_for_status()
    return r.json().get("results", [])

def surface(ticker: str, a: dict, score: float, mult: float):
    flag = "🔥 earnings window" if mult > 1 else ""
    print(f"[{score:5.0f}] {ticker} {flag} — {a['title']}")
    print(f"        {a['source']['domain']} · {a['published_at']}")

def run_monitor():
    seen_stories: set = set()
    last_seen = {t: datetime.now(timezone.utc).isoformat() for t in WATCHLIST}
    while True:
        today = datetime.now(timezone.utc).date()
        for ticker, company in WATCHLIST.items():
            try:
                articles = fetch_news(company, last_seen[ticker])
            except Exception as e:
                print(f"{ticker} fetch error:", e)
                continue
            report_date = EARNINGS_CALENDAR.get(ticker)
            for a in sorted(articles, key=lambda x: x["published_at"]):
                sid = (a.get("story") or {}).get("id") or a["id"]
                if sid in seen_stories or a.get("is_duplicate"):
                    continue
                score, mult = relevance(a, company, today, report_date)
                if score >= SURFACE_THRESHOLD:
                    surface(ticker, a, score, mult)
                    seen_stories.add(sid)
                last_seen[ticker] = max(last_seen[ticker], a["published_at"])
        time.sleep(POLL_SECONDS)

Das ist der gesamte Monitor. Die obige Reuters-Leit-Schlagzeile — Entität Nvidia mit Frequenz 5 (20) + Finanzkategorie (10) + glaubwürdige Quelle OPR 8 (5) = 35 Basis — landet zwei Geschäftstage vor Nvidia's Juni 17 Bericht, innerhalb des Spitzenfensters (×3), für einen fusionierten Score von 105. Dieselbe Schlagzeile drei Wochen früher erzielt 35. Gleiche Geschichte, sehr unterschiedliche Dringlichkeit, und der Monitor kennt den Unterschied, weil er den Kalender mit den Nachrichten fusioniert hat.

Produktionseinführung

Eine Demo-Schleife wird mit einigen Härtungsschritten zu einem echten Nachrichten-Monitor für Quartalsergebnisse:

1. Zustand über Neustarts hinweg beibehalten. Verschieben Sie seen_stories und last_seen nach Redis mit einem TTL, damit ein Redeploy nicht die gestrigen Benachrichtigungen erneut auslöst oder ein Fenster überspringt.
2. Aktualisieren Sie den Kalender nach einem Zeitplan. Rufen Sie den Ergebnis-Kalender einmal täglich ab (Berichtsdaten verschieben sich, insbesondere Bestätigungen) und cachen Sie ihn. Rufen Sie ihn nicht in der Hot Loop ab.
3. Entitäten auflösen, nicht nur Titel abgleichen.title=Nvidia ist ein stumpfer Filter; bevorzugen Sie entity.id, damit „Apple“ das Unternehmen niemals mit „Apfel“ der Frucht kollidiert. Entity-Type-Tagging (type == "organization") ist Ihr Disambiguator.
4. Engen Sie den Zeitrahmen für Fenster ein. Erweitern Sie POLL_SECONDS für Ticker, die weit von den Quartalszahlen entfernt sind; verengen Sie ihn für Ticker im Spitzenzeitraum. Setzen Sie Ihr Ratenlimit dort ein, wo das Signal am stärksten ist.
5. Rate Limits respektieren. Backoff bei HTTP 429. Latenz im Newsfilter-Klasse (sub-500ms Indizierung) hilft nur, wenn Sie tatsächlich schnell genug abfragen, um sie während des Fensters zu sehen.
6. Protokollieren Sie jede Punktzahl, nicht nur die angezeigten. Sie können die Multiplikatoren und Schwellenwerte nur abstimmen, wenn Sie die Punktzahlen später mit realisierten Preisbewegungen verknüpfen können.

Wenn Sie noch die Nachrichtenseite auswählen, bewerten Sie Feeds nach der Qualität der Entitätstaggung, der Tiefe der Kategorien (gibt es „Gewinne“ als Kategorie?), Signalen zur Glaubwürdigkeit der Quelle und der Präzision des Datumsfilters – den Eingaben, von denen dieser Monitor abhängt. Unser News API Buyer's Guide 2026 vergleicht Anbieter anhand genau dieser Achsen.

Häufig gestellte Fragen

Wie erhalte ich Echtzeit-Unternehmensnachrichten nach Ticker?

Sie erhalten Echtzeit-Unternehmensnachrichten nach Ticker, indem Sie den Everything-Style-Endpunkt einer Nachrichten-API abfragen, der auf dieses Unternehmen gefiltert ist, und einen published_at.start-Cursor verwenden, sodass jeder Aufruf nur neue Artikel zurückgibt. Bei APITube sind das GET /v1/news/everything?title=Nvidia&category.id=business&published_at.start=<last_seen>; für engere Übereinstimmungen verwenden Sie den entity.id-Filter anstelle von title. Ordnen Sie jeden Ticker dem Firmennamen (oder der Entitäts-ID) zu, den die API verwendet, und behalten Sie einen Zeitstempel pro Ticker für das letzte Gesehene bei, damit Sie nie dasselbe Fenster erneut verarbeiten.

Was ist die beste API für Gewinnnachrichten?

Es gibt keine einzelne beste Option, da die Gewinnnachrichten zwei Datentypen umfassen. Für die Nachrichten-Ebene verwenden Sie eine Echtzeit-Finanznachrichten-API mit starker Entitätsetikettierung und einer Finanzkategorie (APITube, Finnhub, Newsfilter.io). Für die Kalender-Ebene – Berichtstermine und EPS-Schätzungen – verwenden Sie eine Gewinnkalender-API wie Financial Modeling Prep. Der beste „Gewinnnachrichten-Monitor“ ist die Verbindung, die Sie schreiben, um die beiden zu verschmelzen, da kein einzelner Anbieter beides gut beherrscht.

Wie baut man einen Aktiennachrichten-Monitor?

Sie erstellen einen Aktiennachrichtenmonitor in fünf Teilen: eine Watchlist, die Ticker mit Entitäten abgleicht, einen Gewinnkalender mit Berichtsdaten, einen Nachrichtenabrufer, der nach Ticker mit einem Datums-Cursor abfragt, eine Fusionsregel, die die Basisrelevanz mit einem Gewinnfensterfaktor multipliziert, und eine persistente Abrufe-Schleife, die nach Story-ID dedupliziert. Das Ganze besteht aus etwa 120 Zeilen Python – die Architektur in diesem Tutorial ist ein vollständiger, ausführbarer Ausgangspunkt.

Wie verfolgen Sie automatisch Gewinnankündigungen?

Sie verfolgen Gewinnankündigungen automatisch, indem Sie täglich einen Earnings-Kalender API in eine ticker -> report_date-Map ziehen und zwischenspeichern. Berechnen Sie dann in Ihrem News-Monitor die Distanz zwischen Geschäftstagen zwischen heute und dem Berichtsdatum jedes Tickers und verwenden Sie sie, um eingehende Nachrichten zu gewichten – stärker im T-5 bis T+2-Fenster. Aktualisieren Sie den Kalender nach einem Zeitplan (Daten werden bestätigt und gelegentlich verschoben), anstatt ihn in der Echtzeit-Schleife abzurufen.

Schlussfolgerung

Ein End-to-End-Monitor für Gewinnnachrichten verdient seinen Namen nur, wenn er beide Ebenen vereint: den geplanten Gewinnkalender, der Ihnen sagt, wann Sie aufpassen müssen, und den ungeplanten Unternehmensnachrichten-Feed, der Ihnen sagt, was tatsächlich passiert. Wenn Sie nur einen bauen, haben Sie ein halbes Werkzeug – einen Kalender, der während des Laufs still ist, oder einen Nachrichten-Feed, der einen Margenwarnung von einer Produktnotiz unterscheiden kann.

Die Fusion ist klein: eine gemeinsame Watchlist, ein Multiplikator für das Ergebnis-Fenster, gemessen in Handelstagen, und eine persistente Poll-Schleife. Beginnen Sie mit dem obigen Code, protokollieren Sie jeden Score gegen realisierte Bewegungen und stimmen Sie das Fenster und den Schwellenwert auf Ihr eigenes Buch ab. Richten Sie es dann auf Ihre echte Watchlist und lassen Sie es Ihnen sagen, welche Schlagzeilen diese Woche wirklich wichtig sind.

Testen Sie Apitube kostenlos → apitube.io

Ressourcen

• APITube News API Dokumentation
• Nachrichten API Käuferleitfaden 2026: 6 Anbieter bewertet
• Vorbereitung auf Finanzmodellierung — Earnings Calendar API (eine Kalender-Layer-Quelle)