Byg en overvågning af indtjening og virksomhedsnyheder

En earnings-nyhedsmonitor er en watchlist-drevet tjeneste, der fusionerer to strømme over det samme sæt af tickers: den planlagte earnings-kalender (du ved hvornår en virksomhed rapporterer) og den uplanlagte virksomhedsnyhedsfeed (du ved ikke hvornår en historie bryder ud). Den fremhæver hver post vægtet efter, hvor tæt den falder på rapportdatoen. De fleste tutorials bygger kun halvdelen af det. De enten pollinger en nyhedsfeed API efter ticker, eller de trækker en earnings-kalender og stopper. Denne guide bygger hele tingene i Python: en watchlist, to lag, en earnings-window-relevansregel og en poll-løkke med persistens.

Denne vejledning er til FinTech-udviklere, der bygger en virksomhedsnyhedsovervågningsliste eller en aktienyheds-tracker, som skal kende forskel på en rutinemæssig tirsdags-overskrift og en historie, der lander dagen før en megacap rapporterer. Ved afslutningen vil du have en kørende monitor og et numerisk framework til at beslutte, hvad der skal vises.

Offentliggørelse: Denne vejledning er udgivet af APITube (apitube.io), en udbyder af nyheds-API, og live-kaldene bruger dens API til nyhedslaget. Metoden er leverandør-neutral: enhver realtids finansiel nyheds-API, der eksponerer enheds-tagging og et filter for udgivelsesdato, fungerer til nyhedssiden, og enhver kilde til indtjeningskalender (eller din egen database med rapportdatoer) fungerer til kalendersiden. APITube eksponerer ikke en indtjeningskalender-endpoint — så denne monitor parrer den bevidst med en ekstern kalender, og koden er eksplicit omkring denne samling. Dette er en teknisk vejledning, ikke investeringsrådgivning; relevans-scorer bestemmer, hvad der skal vises, ikke hvad der skal handles.

Vigtigste pointer:

• En monitor, der kun overvåger kalenderen eller kun nyhederne, er halvt blind – værdien ligger i at fusionere dem over én overvågningsliste.
• Indtjeningskalenderen er planlagte data; virksomhedsnyheder er uplanlagte data. De kræver forskellige afstemningsstrategier, men en delt relevansmodel.
• Indtjeningsvinduet – ca. T-5 til T+2 handelsdage omkring en rapporteringsdato – er, når virksomhedsnyheder betyder mest. Vægt efter nærhed, ikke kun tilstedeværelse.
• Hele monitoren er en overvågningsliste, to fetchers, en fusionsregel og en vedvarende afstemningsløkke — omkring 120 linjer af Python.

Indholdsfortegnelse

• Hvorfor kun kalender- eller kun nyhedsovervågning er halvt blind
• De to lag: planlagt vs. ikke-planlagt
• Rammeværket for indtjeningsvinduet
• Byg det: watchlist → kalender → nyheder → fuse → persist
• Gå til produktion
• FAQ

Hvorfor kalender-kun eller nyheder-kun overvågning er halvt blind

En kalender-kun-monitor og en nyhed-kun-monitor er hver blind for halvdelen af det, der bevæger en aktie omkring indtjening.

Et kalender-kun værktøj ved, at Nvidia rapporterer om juni 17 efter lukketid. Det ved ikke, at to dage tidligere en historie om forsyningskæden eller en lækket analytikerforudsigelse allerede bevæger navnet. Kalenderen fortæller dig, hvornår den planlagte begivenhed finder sted; den siger intet om de ikke-planlagte nyheder, der klynger sig omkring den.

Et værktøj kun til nyheder har den modsatte blindhed. Det indtager hver Nvidia-overskrift i realtid, men behandler dem alle ens. Det kan ikke se, at en triviel produktbeskrivelse i en stille uge og en overskrift med advarsel om marginen dagen før rapporten fortjener fuldstændig forskellig hastende. Uden kalenderen er enhver overskrift kontekstfri.

Markedet er opdelt præcis langs denne linje. Nyhedsfokuserede API'er som Finnhubs virksomhedsnyheds-endepunkt og Newsfilter.io – som annoncerer indeksering af artikler på under 500 millisekunder med NLP ticker-tagging – giver dig en hurtig strøm uden nogen idé om hvornår et firma rapporterer. Kalenderfokuserede API'er som Financial Modeling Preps indtjeningskalender giver dig rapporteringsdatoer og EPS-estimater uden nyheder tilknyttet. Næsten ingen fusionerer dem. Det hul er grunden til at bygge dette selv i stedet for at købe én boks.

Løsningen er ikke et smartere nyhedsfeed eller en rigere kalender. Det er et lille stykke lim: en monitor, der holder én overvågningsliste, spørger kalenderen "hvornår rapporterer dette ticker?" og nyheds-API "hvad sker der med dette ticker?", og kombinerer derefter de to til et enkelt relevansnummer.

De to lag: planlagt vs. ikke-planlagt

En virksomhedsnyheds-overvågningsliste skal håndtere to fundamentalt forskellige slags data. At behandle dem ens er fejlen. Her er den skelnen, der driver hele designet:

Det planlagte lag er billigt og langsomt bevægende: et tickers næste rapportdato ændres måske en gang om kvartalet, så du opdaterer det en gang om dagen og cacher det. Det ikke-planlagte lag er ildslangen: du afstemmer det kontinuerligt og holder tilstandsdata pr. ticker, så du aldrig genbehandler det samme vindue.

Monitorens opgave er at være stedet, hvor disse to møder hinanden. Den bruger det planlagte lag som kontekst og det ikke-planlagte lag som indhold. En overskrift er bare en overskrift, indtil kalenderen fortæller dig, at den landede inden for et indtjeningsvindue – så er det en advarsel om indtjeningschok. I modsætning til et feed, der kun indeholder nyheder, og som behandler hver overskrift ens, læser en fusioneret monitor hver overskrift gennem kalenderen. Den samme advarsel om margin scorer langt højere dagen før en rapport end tre uger ude.

Regnskabsvindues-frameworket

Dette er reglen, der fusionerer lagene. Indtjeningsvinduet er båndet af handelsdage omkring en rapportdato, hvor virksomhedsnyheder bærer mest signal. Definer det numerisk og vægt nyheder efter nærhed til rapporten.

Standardindstillingerne nedenfor er et udgangspunkt – finjuster dem mod dine egne data – men strukturen betyder mere end de nøjagtige tal:

To designvalg er bevidste. Først måles vinduet i handelsdage, ikke kalenderdage — en rapport om mandagen betyder, at forrige fredag er T-1, ikke tre kalenderdage tilbage. Tælling af hverdage holder vinduet synkroniseret med, hvornår markederne rent faktisk reagerer. For det andet er multiplikatoren asymmetrisk: vinduet åbner bredere før rapporten (T-5) end det lukker efter (T+2), fordi optakten er længere og mere støjende end den øjeblikkelige reaktion.

Multiplikatoren erstatter ikke en grundlæggende relevansscore – den skalerer den. En svag overskrift inden for spidsvinduet og en stærk overskrift langt udenfor kan lande på lignende slutscorer, hvilket er helt rigtigt: en ubetydelig notits bør ikke udløses bare fordi indtjeningen er i morgen, og en marginadvarsel bør ikke ignoreres bare fordi rapporten er tre uger ude. Hvis du ønsker en rigere grundscore – overraskelse, kilde troværdighed, dækningsspidser – udvikler vores ledsagende guide, Build Real-Time Market-Moving News Alerts, den scoringsmodel i dybden. Denne artikel holder grundlaget bevidst simpelt, så fusionslogikken forbliver i fokus.

Byg det: overvågningsliste → kalender → nyheder → fusioner → gem

Monitoren har fem dele: en overvågningsliste over tickers, en kalender over rapporteringsdatoer, en nyheds-fetcher, en fusionsregel (grundlæggende relevans × vinduesmultiplikator) og en vedvarende afstemningsløkke. Start med én rigtig nyhedsanmodning.

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"

Hver artikel indeholder de felter, fusionsreglen har brug for — enhedsmærkning, kategorier, kilderangering og en historie-ID til deduplikering:

{
  "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" }
      ]
    }
  ]
}

Watchlisten og kalenderen

Watchlisten mapper et ticker til firmanavnet, som nyheds-API tagger det. Kalenderen mapper et ticker til dets næste rapportdato – og dette er den ærlige søm: APITube har ingen indtjenings-endpoint, så disse datoer kommer fra en ekstern indtjeningskalender-kilde (FMP, din brokers data eller en manuelt vedligeholdt ordbog). Hold kalenderen som en almindelig ordbog, så fusionslogikken ikke er ligeglad med, hvor datoerne kom fra.

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),
}

Indtjeningsvinduesmultiplikator

Tæl hverdage mellem i dag og rapportdatoen, signeret (negativ = før rapporten), og kort derefter offsettet til en multiplikator. Dette er rammen fra det foregående afsnit, i kode:

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

Grundlæggende relevans og fusion

Basisscoren forbliver bevidst lille — fremtræden af enheder, et match i finans-kategorien og troværdighed af kilden. Vinduesmultiplikatoren udfører det indtjeningsbevidste arbejde:

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

Den vedvarende afstemningsløkke

Løkken henter nyheder pr. ticker siden sidste sete tidsstempel, beregner fusioneret relevans, deduplikerer efter story.id og viser alt over en tærskel. last_seen pr. ticker og et globalt seen_stories sæt er persistensen – i produktion lever disse i Redis, ikke hukommelsen.

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)

Det er hele monitoren. Overskriften Reuters-vejledning ovenfor — entitet Nvidia med frekvens 5 (20) + finans-kategori (10) + troværdig kilde OPR 8 (5) = 35 base — lander to hverdage før Nvidias juni 17 rapport, inden for peak-vinduet (×3), for en samlet score på 105. Den samme overskrift tre uger tidligere scorer 35. Samme historie, meget forskellig hast, og monitoren kender forskellen, fordi den fusionerede kalenderen med nyhederne.

Går i produktion

En demo-loop bliver en reel indtjeningsnyhedsovervågning med et par forstærkende trin:

1. Persister tilstand på tværs af genstarter. Flyt seen_stories og last_seen til Redis med en TTL, så en redeploy ikke genudløser gårsdagens alarmer eller springer et vindue over.
2. Opdater kalenderen med jævne mellemrum. Hent indtjeningskalenderen én gang om dagen (rapporteringsdatoer skifter, især bekræftelser), og cache den. Hent den ikke i den aktive loop.
3. Opløs entiteter, match ikke kun titler.title=Nvidia er et groft filter; foretræk entity.id, så "Apple" firmaet aldrig kolliderer med "apple" frugten. Entitetstype-tagging (type == "organization") er din disambiguator.
4. Stram afstemningen omkring vinduer. Udvid POLL_SECONDS for tickers langt fra indtjening; stram den for tickers i spidsvinduet. Brug din rate limit, hvor signalet er.
5. Overhold rate limits. Back off på HTTP 429. Nyhedsfilter-klasse latency (sub-500ms indeksering) hjælper kun, hvis du rent faktisk poller hurtigt nok til at se det i vinduet.
6. Log alle scorer, ikke kun dem, der vises. Du kan kun finjustere multiplikatorerne og tærsklen, hvis du senere kan sammenkøre scorer mod realiserede prisbevægelser.

Hvis du stadig vælger nyhedssiden, skal du evaluere feeds på kvaliteten af entitetstagging, kategoridybde (findes "indtjening" som en kategori?), kilde troværdighedssignaler og præcision af datofilter — de input, denne monitor afhænger af. Vores News API Buyer's Guide 2026 sammenligner udbydere på netop disse akser.

Ofte stillede spørgsmål

Hvordan får jeg realtidsvirksomhedsnyheder efter ticker?

Du får realtids firma-nyheder efter ticker ved at polle et nyheds-API's alt-i-én-endpoint filtreret til det firma, ved hjælp af en published_at.start cursor, så hvert kald kun returnerer nye artikler. Med APITube er det GET /v1/news/everything?title=Nvidia&category.id=business&published_at.start=<last_seen>; for tættere matching, brug entity.id-filteret i stedet for title. Map hver ticker til firmanavnet (eller entitets-id'et), som API bruger, og behold et per-ticker sidst-set tidsstempel, så du aldrig genbehandler det samme vindue.

Hvad er den bedste API til indtjeningsnyheder?

Der findes ingen enkelt bedste, fordi indtjeningsnyheder er to datatyper. Til nyheds-laget skal du bruge en finansiel nyheds-API i realtid med stærk entitetstagging og en finansiel kategori (APITube, Finnhub, Newsfilter.io). Til kalender-laget — rapportdatoer og EPS-estimater — skal du bruge en indtjeningskalender-API som Financial Modeling Prep. Den bedste "indtjeningsnyhedsovervågning" er den lim, du skriver for at fusionere de to, fordi ingen enkelt leverandør gør begge dele godt.

Hvordan bygger du en aktienyhedsovervågning?

Du bygger en aktienyhedsovervågning i fem dele: en watchlist, der mapper tickers til entiteter, en indtjeningskalender med rapporteringsdatoer, en nyhedshentning, der poller pr. ticker med en datocurser, en fusionsregel, der multiplicerer basisrelevans med en indtjeningsvinduesfaktor, og en persisteret poll-loop, der deduplikerer efter historie-id. Det hele er omkring 120 linjer af Python — arkitekturen i denne tutorial er et komplet, kørbar startpunkt.

Hvordan sporer du indtjeningsmeddelelser automatisk?

Du sporer automatisk indtjeningsmeddelelser ved at trække en indtjeningskalender API dagligt ind i et ticker -> report_date-kort og cache den. Derefter, i din nyhedsovervågning, beregner du forretningsdagsafstanden mellem i dag og hver tickers rapporteringsdato og bruger den til at vægte indkommende nyheder — tungere inden for -5 til +2-vinduet. Opdater kalenderen på en tidsplan (datoer bekræftes og flyttes lejlighedsvis) i stedet for at hente den i realtidsløkken.

Konklusion

En overvågningsservice for indtjeningsnyheder lever kun op til sit navn, når den kombinerer begge lag: den planlagte indtjeningskalender, der fortæller dig hvornår du skal være opmærksom, og den uplanlagte virksomhedsnyhedsstrøm, der fortæller dig hvad der rent faktisk sker. Byg kun den ene, og du har et halvt værktøj — en kalender, der er tavs op til begivenheden, eller en nyhedsstrøm, der ikke kan skelne en marginadvarsel fra en produktbeskrivelse.

Fusionen er lille: en delt overvågningsliste, en indtjeningsvinduesmultiplikator målt i handelsdage og en vedvarende afstemningsløkke. Start med koden ovenfor, log hver score mod realiserede bevægelser, og finjuster vinduet og tærsklen til din egen bog. Peg den derefter på din rigtige overvågningsliste og lad den fortælle dig, hvilke overskrifter der virkelig betyder noget i denne uge.

Prøv Apitube gratis → apitube.io

Ressourcer

• APITube Nyheder API Dokumentation
• Nyheder API Købsguide 2026: 6 Udbydere Scoret
• Finansiel modelleringsforberedelse — Indtjeningskalender API (en kalender-lagkilde)