Natív hirdetési adat API: Programozott hozzáférés rögzített natív kreatívokhoz
A legtöbb natív hirdetési intelligencia egy irányítópult mögött rejtőzik. Így szereznek elemzők és adatcsapatok rögzített kreatívokat, feloldott hirdetőket, ellátási lánc lépéseket és céloldalakat strukturált rekordokként API-n keresztül.

Ha valaha is megpróbáltál igazi elemzést végezni natív hirdetéseken, ismered a falat. Az intelligencia létezik, de egy irányítópult mögött rekedt. Böngészhetsz egy kreatívet egyszerre, szemmel látható néhány hirdetőt, talán exportálhatsz egy CSV-t, amely már elavult, mire letöltődik. Amit nem tehetsz meg, az az, hogy a natív hirdetési adatokat úgy kezeld, mint a verem minden más adatkészletét: lekérdezd, összekapcsolod, ütemezed, egy modellbe pumpálod.
Ez a útmutató azoknak szól, akik az adatokat akarják, nem az irányítópultot. Versenyképességi nyomkövetőket építő elemzőknek. CRM-t gazdagító adatcsapatoknak. Kreatív szögeket visszatesztelő kvantoknak. És egyre inkább azoknak az MI-ügynököknek, akik ezt a munkát ember nélkül végzik. A kérdés egyszerű. Hogyan kaphatsz rögzített natív kreatívokat, azok mögötti ellátási láncot és a céloldalakat, amelyekre mutatnak, tiszta, strukturált rekordokként API-n keresztül?
Kontextusként: az OpenAdLibrary gyűjteményének 2026 júniusi pillanatképe 589 036 kreatívot, 5,4 millió hirdetési megfigyelést, 25 933 különálló hirdetőt és 926 259 rögzített céloldalt tartalmazott 42 hálózaton keresztül. Ez történelmi mérőszám arra nézve, amit összegyűjtöttünk, nem a natív piac mérete, és nem aktuális darabszám. Egy API feladata az, hogy pontosan odaadja a kért rekordokat.
Mit ad vissza valójában egy natív hirdetési adat API#
Egy natív hirdetési adat API egy végpont, amely a natív hirdetési intelligenciát gépi olvasható rekordokként adja vissza egy weboldal helyett. Egy rekord tartalmazhatja a kreatívet (képet és címsort), a szolgáltató kiadót és hálózatot, az elhelyezés mögötti ellátási lánc lépéseket, a kattintás által feloldott céloldalt, és időzítési jeleket, mint az első látás és utolsó látás dátumát. Szűrheted, összekapcsolhatod és összesítheted, mint bármely adatbázis táblát.
Ez a rendszeres definíció sok mérnöki munkát rejt. Egy keresési vagy Meta hirdetéssel ellentétben, amely egy hivatalos könyvtárban ül, egy natív elhelyezést egy natív hirdetési widget renderel, a "Ajánlott neked" vagy "A weben" sáv a cikkek alján. Ezek a widgetek dinamikusak, földrajzilag célzottak és személyre szabottak. Ezért egyetlen statikus kaparás kihagyhat olyan hirdetéseket, amelyeket más látogatók látnak. Egy valódi adatkészletnek földrajzok és idő szerint kell rögzítenie, majd deduplikálnia kell egy stabil kreatívvá.

A fenti hirdetés a műfaj tipikus példája a rögzítéseinkben: egy határidő, egy homályos hatóság és egy dollárösszeg. 13 napon át figyeltük meg, amikor utoljára láttuk. Ez azt mondja meg, mennyi ideig láttuk, nem azt, hogy nyereséges volt-e, vagy hogy az állítása pontos-e.
Egy natív hirdetési adatkészlet négy adatrétege#
Gondolj a natív hirdetési adatokra négy egymásra rakott rétegként. Egyes eszközök csak a felső réteget mutatják meg. Az érték halmozódik, ahogy lefelé haladsz.
| Réteg | Mit rögzít | Miért számít |
|---|---|---|
| Kreatív | Teljes felbontású kép, címsor, felhívás a cselekvésre | A tényleges hirdetés, nem egy miniatűr. Táplálja a Copy DNA-t és a vizuális klaszterezést. |
| Hálózat és kiadó | Melyik natív hálózat szolgáltatta, melyik oldalon | Lehetővé teszi a "ki hirdet ezen az oldalon?" kérdés megválaszolását és a forrás szerinti szegmentálást |
| Ellátási lánc | A hirdetéstechnológiai lépések a kiadó és a hirdető között | Felfedi az újraértékesített állományt, közvetítőket és útválasztást |
| Céloldal | A kattintás elő-landingje és végső célhelye | Felszínre hozza a valódi hirdetőt és az értékesített ajánlatot |
Az ugrás a második rétegről a negyedikre az egész játék. Egy elhelyezést egy hálózat szolgáltat (Taboola, Outbrain, MGID, Revcontent, Teads, Yahoo, MSN), de a hálózat nem a hirdető. A hirdető az, aki a kattintás végén ül. A kreatívok hálózat szerinti számolása nem mondja meg, ki vásárol valójában. Az átirányítási lánc követése, kiszolgáló oldalon és anélkül, hogy valódi kattintást indítana egy élő kampányon, változtatja át egy névtelen widget kreatívok halmazát olyan versenyképességi intelligenciává, amivel cselekedhetsz.
A közbeni útválasztás mechanikájáért lásd a natív hirdetési ellátási láncot. A szolgáltató hálózat mögötti valószínű vevő kiderítéséhez olvasd el, hogyan azonosítható egy natív hirdetés mögötti valószínű hálózat.
Az időtartam hasznos oszlop, és könnyű túlértelmezni#
Egy időbélyeg egy natív hirdetési adatkészlet egyik leghasznosabb mezője, mert lehetővé teszi annak mérését, hogy egy hirdetést mennyi ideig figyeltek meg.
Nem láthatod senki költségvetését natívban, és az időtartam nem helyettesíti azt. Egy kreatív, amely hetekig fent marad számos oldalon, lehet nyereséges, de lehet márkakampány, maradék költségvetésű teszt, vagy olyan hirdetés, amelyet senki nem vizsgált felül. Az itt idézett 2026 júniusi rögzítésekben a leghosszabb folyamatosan megfigyelt kreatívok körülbelül 28 napig futottak, ami akkor a megfigyelési ablakunk határa volt, így hosszabb futásokat nem lehetett látni. Azok a címsorok, amelyek elérték ezt a határt, érdemesek egy pillantásra, mint példák.

A SmartAsset "Hogyan Kerülhetem El az IRA Kivonások Adójának Fizetését?" címsora rajta volt a 28 napos listán. Ugyanígy több "Mi az IQ Szinted?" kvízhirdetés a My IQ-tól a Microsoft Audience Network-en, és egy hallókészülék-hirdetés a Hidden Hearing-től, két különböző kreatívval ugyanazon a határon. Egy hirdető, amelynek több változatát a teljes ablakban figyeltük meg, még mindig futtatta őket. Nem tudjuk megmondani, hogy az ajánlat nyereséges volt-e, hogy nagy volt-e a költségvetés, vagy hogy a hirdetésekben szereplő állítások pontosak voltak-e.
Egy óvatosságot érdemes világosan kijelenteni. A médiavásárlási körökben idézett "90 napos győztes" iparági legenda, nem a mi mérésünk. Amit ezekben a 2026 júniusi rögzítésekben igazolni tudtunk, az a kreatívenkénti körülbelül 28 napig tartó folyamatos futás volt. Kezeld a 90 napos számot folklórként, amíg saját adatkészleted nem időbélyegzi.
API vs irányítópult: illessd az eszközt a feladathoz#
Nincs semmi baj egy irányítópulttal alkalmi kutatáshoz. A két felület különböző feladatokra készült, és az összekeverésük oda vezethet, hogy a csapatok olyan eszközökért fizetnek, amelyeket alig használnak.
- Használj irányítópultot, amikor egy ember végez feltáró munkát: szemmel követi egy versenytárs szögét, kihúz néhány kreatívet egy prezentációhoz, átfutja, mi forró ezen a héten. Ez a klasszikus ad spy tool munkafolyamat.
- Használj API-t, amikor a fogyasztó egy rendszer: egy ütemezett feladat, egy dbt modell, egy funkciótár, egy Slack riasztás vagy egy MI-ügynök. Rekordokat akarsz, nem pixeleket, és cron szerint akarod őket.
A gyakorlati jel az ismétlés. Ha úgy találod, hogy minden hétfőn kézzel exportálod ugyanazt a nézetet, nincs kutatási problémád. Integrációs problémád van, és egy API megoldja. Ez az a pont is, amerre a szélesebb hirdetési intelligencia fegyelem halad: kevesebb kézi böngészés, több programozott csatorna, amelyeket egyenesen a versenyképességi és kreatív munkafolyamatokba kötnek.
Egy konkrét folyamat#
Így köti be egy adatcsapat valójában a natív hirdetési adatokat valami hasznosba. A minta érvényes, függetlenül attól, hogy egy teljes vertikálist vagy egy versenytársat követ.
- Határozd meg a figyelőlistát. Egy olyan hirdetők, céloldal domainek vagy kiadói oldalak halmaza, amelyek érdekelnek. A keresési végpont dokumentálja az olyan szűrőket, mint az advertiserDomain, landingDomain és publisher, így csak azt húzod le, amit követsz.
- Húzz ütemezés szerint. Egy éjszakai feladat azokat a hirdetéseket kéri le, amelyeket tegnap óta láttak utoljára (a keresési végpont dokumentál egy lastSeenFrom szűrőt, és egy külön changes végpont egy since vízjelet fogad), majd id szerint upserteli őket, így ugyanaz a kreatív nem tárolódik kétszer.
- Kapcsold össze saját adataiddal. Illeszd a céloldal domaineket a CRM-edhez vagy egy versenytárs táblához. Azok a kreatívok, amelyeknek a céloldal domainje illeszkedik, egy már követett céghez rendelődnek.
- Számítsd ki a megfigyelt időtartamot és terjedést. Csoportosíts kreatív ID szerint. Mérd meg a megfigyelt napokat (utolsó látás mínusz első látás) és a különálló kiadók számát. A hosszan megfigyelt, széles körben elterjedt kreatívok közelebbi vizsgálatra érdemes jelöltek, nem megerősített győztesek.
- Cselekedj. Tolj egy napi összefoglalót az új, hosszan megfigyelt kreatívokról Slackbe, tápláld a kreatívokat egy klaszterező modellbe, vagy add át a strukturált tervet egy ügynöknek.

A negyedik lépés az, ahol egy időbélyeggel ellátott adatkészlet hasznos. Egy olyan kreatív, mint a fenti Nebroo hallóeszköz-hirdetés, 26 napon át megfigyelve, az a fajta rekord, amelyet a folyamatod felülvizsgálatra jelölhet meg. Az időtartam csak akkor olvasható, ha adatkészleted időbélyegez minden megfigyelést, ezért ült a 2026 júniusi pillanatképben 5,4 millió megfigyelés azok mögött a 589 036 kreatív mögött. A megfigyelések az idősor. A kreatív csak a kulcs. A megjelölés arra késztet egy embert vagy egy modellt, hogy közelebbről megnézze, nem pedig ítélet arról, hogy a hirdetés működik.
Mi választja el egy használható adatkészletet egy zajostól#
A mennyiség a rossz főcím metrika. Tíz millió elavult, rosszul deduplikált, csak hálózati rekord rosszabb, mint egy kisebb halmaz, amely friss, attributált és tiszta. Amikor kiértékeled egy natív hirdetési adatkészletet vagy annak API-ját, próbáld ki öt dologgal:
- Frisesség. Élő elhelyezéseket rögzítenek, első látás és utolsó látás dátumokkal? Vagy egy időszakos adatcsomag, amely már hetek óta elavult?
- Kreatív hűség. A tényleges kép teljes minőségben van tárolva, vagy egy lefelé skálázott miniatűr, amely használhatatlan vizuális elemzéshez?
- Attribúciós mélység. Megáll a hálózatnál, vagy követi a kattintást a végső céloldalig és a valódi hirdetőig?
- Rögzítési módszer. Nyilvános hirdetéseket olvas anélkül, hogy valódi kattintásokat indítana élő kampányokon? Szintetikus kattintások más hirdetők pénzét költik el és rombolják az ő adataikat, és a tiédet is.
- Lefedettség szélessége. Átfedi a fő natív hálózatokat és földrajzok szerint rögzít, vagy egy kiadó egy országban?

Figyeld meg a részletet abban a napelemes akkumulátor hirdetésben. Teljes felbontásban elolvashatod az ajánlatot, a keretet és a vizuális kezelést, ami táplálja a vizuális klaszterezést és a szövegelemzést. Egy miniatűr mindezt eldobja. Ez az öt teszt az is, ami megkülönbözteti az igazi hirdetési átláthatóságot egy képernyőképes könyvtártól, amelyre keresődoboz van ráerősítve. A natívnak nincs a Meta-éhoz vagy a Google-éhez hasonlítható hivatalos könyvtára, és útmutatónk, mi a natív hirdetési könyvtár és miben különbözik a Meta-étól és a Google-étól, elmeséli ezt a történetet.
Miért nehezebb, és miért jutalmazóbb a natív, mint amilyennek látszik#
A Meta, a Google, a Microsoft (az EU-ban és az EGT-ben futó Bing hirdetésekhez) és a TikTok hivatalos hirdetési könyvtárakat tesz közzé, és ezek egy része azért létezik, mert az EU Digital Services Act rendelete nyilvános hirdetési tárhelyet ír elő a kijelölt nagyon nagy online platformok és keresőmotorok számára. Az Európai Bizottság e szolgáltatásokat felsoroló listája (2026. augusztus 31-i frissítés) nem tartalmazza a Taboola-t, az Outbrain/Teads-t, az MGID-t vagy a Revcontent-et, és nem tudunk nyilvános hirdetési könyvtárról tőlük, ezért a programmatic natív hirdetésnek nincs a Meta-éhoz hasonlítható hivatalos könyvtára. Ez a rés az, amiért független adatkészletek léteznek. A hirdetések nyilvánosan jelennek meg; megszervezésük külön feladat.
A rögzítési probléma megoldásának jutalma egy rekord arról, amit a hirdetők nyilvánosan megmutatnak. Párosítsd ezt programozott hozzáféréssel, és olyan natív hirdetési adatokat kapsz, amelyeket infrastruktúraként használhatsz, nem csak egy webhelyként, amelybe bejelentkezel. A szélesebb kontextushoz, hogyan illeszkednek össze a hirdetési könyvtárak, törvények és eszközök, kezdd a pillérrel mi az a hirdetési átláthatóság és hogyan használd, és nyílt hirdetési könyvtárak magyarázata lefedi az eszközök terepét.
Hogyan illeszkedik az OpenAdLibrary#
Az OpenAdLibrary adja ki ezt a blogot, és értékesíti az itt leírt terméket. Nyilvános natív hirdetéseket rögzít a Taboola, Outbrain, MGID, Revcontent, Teads, Yahoo és MSN hálózatokról, API-first módon, böngészős crawlerrel kiegészítve, és 2026 októbere óta könyvtára Meta és TikTok hirdetéseket is tartalmaz. Tárolja a kreatívet, osztályozza az ellátási láncot, és élő hirdetések kattintása nélkül követi az átirányításokat a céloldalig. Egy REST API és egy hosztolt MCP szerver ugyanazon könyvtár nyilvános adatait teszi elérhetővé egy elemző, egy folyamat vagy egy MI-ügynök számára. A hirdetési adatok és a kutatás mindkettőn keresztül a Founders csomag része: egy ingyenes fiók kulcsa csak annak a fióknak a saját végpontjait éri el, minden más végpont fizetést igénylő választ ad. Az API dokumentáció szerint nyilvános kreatív tartalmat, miniatűr URL-eket, összesített darabszámokat és a hirdetés mögötti átirányítási láncot adja vissza, beleértve a hirdető URL-jét, ahol a kattintás végződik. Nem adja vissza a webes alkalmazásban látható, kizárólag Meta- és TikTok-adatokat, például a Meta költésbecslését és EU-s elérését, szabad szöveges keresése pedig a 3 000 legutóbb látott illeszkedő hirdetésből ad választ, nem a teljes korpuszból. Minden kulcsnak napi kérési kvótája van (az API referenciában alapértelmezés szerint napi 5 000 kérés szerepel). A keresési eredmények tartalmazhatnak Meta és TikTok hirdetéseket, amelyeknek az id-je meta- vagy tiktok- előtaggal kezdődik, és az egyetlen hirdetést lekérdező végpont ezekhez nem tartalmaz rekordot.
A Founders csomag $29.99 havonta, és tartalmazza a REST API-t és a hosztolt MCP szervert. Egy ingyenes fiókhoz nem kell kártya, és az alkalmazásban a 20 legújabb Meta, TikTok és natív hirdetést mutatja, így fizetés előtt ellenőrizheted, hogy az adatkészlet relevánsnak tűnik-e a figyelőlistádhoz; egy alapos ellenőrzéshez és bármilyen API-használathoz a Founders csomag szükséges.
Kezdd ingyen, és nézd meg az adatokat az alkalmazásban; az API-hozzáféréshez a Founders csomag szükséges.







