I-validate ang ads.txt mo, linya kada linya.
I-paste ang iyong Authorized Digital Sellers file at suriin ito laban sa IAB Tech Lab spec. Bawat error, babala, at paalala, kasama ang eksaktong linya at kung paano ito ayusin. Walang lumalabas sa browser mo.
Buong-buong pina-parse sa browser mo — hindi kailanman ina-upload ang file mo.
Dito lilitaw ang iyong mga resulta
Mag-paste ng file o mag-load ng halimbawa, tapos patakbuhin ang validator. Sinusuri nito ang bawat linya nang lokal — walang upload, walang network.
Isang pampublikong listahan ng puwedeng magbenta ng inventory mo.
Ang Authorized Digital Sellers — ads.txt — ay isang pamantayan ng IAB Tech Lab. Naglalathala ka ng plain-text file sa yourdomain.com/ads.txt na nagpapangalan sa bawat advertising system na awtorisadong magbenta ng inventory mo at sa mga account ID na ginagamit nila.
Kina-crawl ng mga buyer ang file na iyon para kumpirmahing lehitimo ang isang bid request, at doon nagsasara ang pinto sa domain spoofing at hindi awtorisadong reselling. Kung wala sa ads.txt mo ang isang seller, hindi na basta magtitiwala ang maingat na buyer sa impression — kaya ang tumpak na file ang pagkakaiba ng isang bid at isang laktaw.
Pare-pareho ang apat na field ng bawat data record.
Ang isang record ay iisang linya ng mga value na pinaghihiwalay ng kuwit. Kailangan ang unang tatlong field; opsyonal ang pang-apat. Binabalewala bilang komento ang mga blangkong linya at ang kahit anong nasa likod ng #.
- 1 Kailangan
google.comDomain ng advertising system
Ang canonical na domain ng SSP o exchange — isang bare host gaya ng google.com, walang https:// o path.
- 2 Kailangan
pub-0000000000000000Account ID ng publisher
Ang iyong seller o account ID sa loob ng advertising system na iyon, eksakto sa paraang ibinigay nila ito.
- 3 Kailangan
DIRECTRelationship
DIRECT kung direkta kang may kontrata sa system, RESELLER kung awtorisado silang magbenta sa ngalan mo.
- 4 Opsyonal
f08c47fec0942fa0ID ng certification authority
Ang TAG-ID ng system — karaniwang 16 na hexadecimal na character. Opsyonal, pero pinapatibay nito ang authorization chain.
Higit sa record: ang mga deklarasyong binabasa rin ng buyer.
Ang mga variable ay mga linyang KEY=value na naglalarawan sa file mismo sa halip na sa iisang seller. Kinikilala ng validator ang lahat ng lima mula sa spec — ang dalawang orihinal na variable ng v1.0 at ang tatlong idinagdag sa v1.1 para sa transparency ng ownership at management.
CONTACT v1.0 Isang contact para sa mga tanong tungkol sa file — isang email address o URL. Opsyonal pero magandang gawi.
SUBDOMAIN v1.0 Itinuturo ang isang subdomain na may sariling ads.txt, para alam ng mga buyer na dapat din itong i-crawl.
OWNERDOMAIN v1.1 Ang root domain ng may-ari ng inventory. Isa lang kada file — ginagamit ito ng mga buyer para kumpirmahin kung sino ang kumikita.
MANAGERDOMAIN v1.1 Ang domain ng eksklusibong monetization partner, puwedeng i-scope sa isang country code.
INVENTORYPARTNERDOMAIN v1.1 Nagpapangalan sa isang partner na dapat ding konsultahin ang sellers.json nito para sa indirect na inventory.
Ang pinakamadalas naming makitang error — at ang solusyon.
Kailangan ng bawat data record ng relationship bilang pangatlong field nito. Magdagdag ng DIRECT o RESELLER pagkatapos ng account ID.
Bare host ang unang field. Isulat ang google.com, hindi https://google.com/ads o www.google.com.
Case-insensitive itong binabasa ng mga consumer ng file, pero upper-case ang canonical na anyo sa spec. Isulat ang DIRECT at RESELLER.
Ang parehong domain, account ID, at relationship na nakalista nang dalawang beses ay nagdaragdag ng ingay at puwedeng magtago ng copy-paste na pagkakamali. Alisin ang sobrang linya.
CONTACT, SUBDOMAIN, OWNERDOMAIN, MANAGERDOMAIN, at INVENTORYPARTNERDOMAIN lang ang kinikilala, at kailangan ng bawat isa ng value pagkatapos ng =.
Hindi ito error, pero idagdag ang TAG-ID saanman may inilalathala ang advertising system — mas mahirap pekein ang authorization dahil dito.
Pinapanatili naming malinis ang authorization chain mo, para mabili ang bawat impression.
Pinapamahalaan ng RevIQ ang iyong mga entry sa ads.txt at sellers.json bilang bahagi ng onboarding, kinukumpirma ang mga seller relationship sa likod ng bawat dolyar, at ipinapakita kung aling demand path talaga ang nagbabayad. Transparent na fees, natu-track na spend, totoong inventory.
- Pinamamahalaang ads.txt at sellers.json, laging naka-sync habang nagbabago ang mga partner mo
- Verified na DIRECT at RESELLER relationships, mula simula hanggang dulo
- Natu-track na payouts — tingnan ang fee na kinuha sa bawat impression
ads.txt, sinagot
Ang pinakamadalas itanong ng mga publisher tungkol sa Authorized Digital Sellers.
Humiling ng accessLibre ba ang ads.txt validator na ito?
Oo. I-paste ang file mo at i-validate nang kasindalas ng gusto mo. Buong-buo itong tumatakbo sa browser mo, kaya hindi kailanman ina-upload sa server ang file mo.
Saan dapat ilagay ang ads.txt file ko?
Sa root ng domain mo — https://yourdomain.com/ads.txt — na sine-serve bilang text/plain. Doon lang tumitingin ang mga buyer, kaya hindi ito puwedeng nasa subfolder.
Ano ang pagkakaiba ng DIRECT at RESELLER?
Ang DIRECT ay nangangahulugang may direkta kang kontrata sa advertising system na iyon para sa inventory mo. Ang RESELLER naman ay nangangahulugang inawtorisahan mo silang ibenta ito sa ngalan mo sa pamamagitan ng ibang partido.
Sinusuri ba nito ang ads.txt v1.0 at v1.1?
Oo. Nauunawaan nito ang mga record ng v1.0 at ang CONTACT at SUBDOMAIN na variable, pati na ang mga idinagdag sa v1.1: OWNERDOMAIN, MANAGERDOMAIN, at INVENTORYPARTNERDOMAIN.
Puwede ba akong mag-validate ng live na domain gamit ang URL?
Bina-block ng mga browser ang cross-origin requests sa karamihan ng ads.txt file, kaya hindi maaasahan dito ang pagkuha gamit ang URL. Buksan ang yourdomain.com/ads.txt, kopyahin ang nilalaman, at i-paste sa itaas — eksaktong pareho ang pagsusuri.
