簡(jiǎn)介OpenRTB 2.5 中文翻譯文檔是一份計(jì)算廣告領(lǐng)域的協(xié)議學(xué)習(xí)資料面向 DSP、SSP、Ad Exchange 開發(fā)者和程序化廣告從業(yè)人員幫助讀者突破英文文檔障礙系統(tǒng)掌握實(shí)時(shí)競(jìng)價(jià)中請(qǐng)求、響應(yīng)、競(jìng)價(jià)、定向與定價(jià)等核心環(huán)節(jié)。文檔對(duì) Bid Request、Bid Response、Impression、User、Device、Site/App、Ext、Bidder Seat、Price Floors 等對(duì)象逐一說(shuō)明并結(jié)合 Bid Request 中如何攜帶用戶、設(shè)備與廣告位信息DSP 如何組織 Bid Response 返回出價(jià)和創(chuàng)意以及 Price Floors 對(duì)庫(kù)存價(jià)值的保護(hù)作用展開梳理同時(shí)介紹了 GDPR 隱私處理、視頻/音頻/富媒體廣告支持、地理位置精確定位以及基于 JSON 的數(shù)據(jù)交換方式便于對(duì)照實(shí)際業(yè)務(wù)快速定位字段含義。資源共 1 個(gè) PDF 文件壓縮包僅 1.36MB適合在電腦或移動(dòng)設(shè)備上隨時(shí)查閱。目前已有 709 人學(xué)習(xí)尤其適合正在搭建競(jìng)價(jià)流程知識(shí)體系的技術(shù)人員也可作為團(tuán)隊(duì)內(nèi)部協(xié)議培訓(xùn)的補(bǔ)充材料。1. 為什么 OpenRTB 2.5 中文翻譯文檔值得你放在手邊做程序化廣告對(duì)接最磨人的往往不是寫代碼而是查字段。競(jìng)價(jià)請(qǐng)求里幾十個(gè)對(duì)象、上百個(gè)字段英文原版規(guī)范每個(gè)詞都認(rèn)識(shí)連起來(lái)卻拿不準(zhǔn)這個(gè)字段到底要不要上送、填錯(cuò)了會(huì)怎樣。我第一次對(duì)接某交易平臺(tái)時(shí)因?yàn)闆](méi)有吃透imp下的geo和user下的geo到底誰(shuí)優(yōu)先線上流量有一半被判成地址不匹配預(yù)算花了大半才發(fā)現(xiàn)問(wèn)題。OpenRTB 2.5 的中文翻譯文檔本質(zhì)上不是一份翻譯件而是一份能讓中文團(tuán)隊(duì)一起評(píng)審、一起排錯(cuò)的工作底稿。它不解決算法問(wèn)題但能解決字段理解偏差和跨角色溝通成本。適合三類人DSP/SSP 的后端開發(fā)廣告交易平臺(tái)的協(xié)議維護(hù)者還有做流量質(zhì)量與反作弊的數(shù)據(jù)工程師。接下來(lái)我把翻譯文檔的邊界、查詢方法、代碼對(duì)照和實(shí)務(wù)陷阱一次講清楚。2. OpenRTB 2.5 在翻譯什么對(duì)象模型、版本差異與文檔邊界OpenRTB 2.5 規(guī)范的核心是一張“請(qǐng)求—響應(yīng)”的數(shù)據(jù)契約。翻譯文檔的價(jià)值不在逐字翻譯而在于把這條契約里的對(duì)象、字段、枚舉和示例理順讓團(tuán)隊(duì)在聯(lián)調(diào)時(shí)說(shuō)的不是“那個(gè)字段”而是imp.bidfloor。2.1 從 2.3 / 2.4 到 2.5中文翻譯文檔里最容易被帶偏的三個(gè)變化如果團(tuán)隊(duì)之前用的是 2.3 或 2.4 的中文資料直接切到 2.5 時(shí)最容易在同名不同義的地方翻車。第一個(gè)變化是“廣告位多格式”的正式化。2.5 里同一個(gè)imp可以同時(shí)攜帶banner、video甚至native子對(duì)象。老版本里一個(gè)imp往往只放一種展示類型翻譯文檔如果還按老思路解釋新手會(huì)把多格式請(qǐng)求拆成多個(gè)imp分別上送結(jié)果競(jìng)價(jià)率明顯下降。我一般會(huì)在文檔里專門加一句注釋同一個(gè) impression 下多個(gè)展示類型對(duì)象可以并存交易平臺(tái)會(huì)依據(jù)點(diǎn)位與設(shè)備能力做篩選。第二個(gè)變化是source對(duì)象。2.5 把請(qǐng)求鏈路上的供應(yīng)方信息例如fd、ext正式納入對(duì)象模型。很多早期中文資料只講site/app對(duì)source一筆帶過(guò)。實(shí)際排查拿不到完整鏈路時(shí)缺的恰恰是它。比如流量經(jīng)過(guò)多級(jí)中間層source.ext里可能帶有每一級(jí)來(lái)源標(biāo)識(shí)翻譯文檔若沒(méi)有解釋反作弊同學(xué)很容易把它當(dāng)成噪音字段丟掉。第三個(gè)變化是枚舉值與協(xié)議細(xì)節(jié)調(diào)整。api、protocol、creative_attribute、devicetype這些字段的取值范圍在 2.5 里有新增和廢棄。直接沿用舊版中文文檔里的枚舉表格會(huì)很危險(xiǎn)因?yàn)槁?lián)調(diào)時(shí)傳輸?shù)氖菙?shù)字枚舉丟了數(shù)字等于沒(méi)有翻譯。判斷一份中文翻譯文檔是否值得采用先看它有沒(méi)有標(biāo)注“對(duì)應(yīng) 2.5 版本”和“枚舉值變更說(shuō)明”而不是看它翻譯得是否通順。2.2 BidRequest / BidResponse 的層級(jí)結(jié)構(gòu)先建坐標(biāo)再讀字段協(xié)議對(duì)象看起來(lái)扁平實(shí)際是嵌套結(jié)構(gòu)。BidRequest 最上層是id、imp數(shù)組、site/app、device、user、at、tmax。imp下面掛banner/video/native、pmp、bidfloor。device下面掛geo、ext。user下面掛geo、data、ext。如果不把層級(jí)畫出來(lái)查geo就會(huì)出現(xiàn)兩條路徑device.geo是設(shè)備所在地user.geo是用戶注冊(cè)地或常駐地的近似位置。先畫一張對(duì)象層級(jí)縮略圖后面讀什么字段都不會(huì)迷路BidRequest ├─ id ├─ imp[] │ ├─ id │ ├─ banner{} │ ├─ video{} │ ├─ native{} │ ├─ pmp{ deals[] } │ ├─ bidfloor │ └─ bidfloorcur ├─ site{} / app{} ├─ device{ geo{}, ext{} } ├─ user{ geo{}, data{} } └─ regs{ coppa, ext }這個(gè)縮略圖不是標(biāo)準(zhǔn)圖但它非常管用。中文翻譯文檔如果能帶一張類似的層級(jí)圖字段歸屬就不會(huì)混。BidResponse 結(jié)構(gòu)相對(duì)簡(jiǎn)單id、seatbid[]、bidid、cur。seatbid里是seat和bid[]bid里最常引起爭(zhēng)議的是nurl與adm。adm是直接返回的創(chuàng)意代碼或物料地址nurl是通知地址要求買家在此地址發(fā)起創(chuàng)意請(qǐng)求。中文文檔里如果不區(qū)分就會(huì)有人把nurl當(dāng)物料地址直接拉取結(jié)果創(chuàng)意一直出不來(lái)。注意geo類字段都包含lat/lon和type。type不同經(jīng)緯度的來(lái)源與精度也不同翻譯注釋里必須寫明否則數(shù)據(jù)校驗(yàn)會(huì)按錯(cuò)誤標(biāo)準(zhǔn)攔截。2.3 翻譯文檔與英文規(guī)范的關(guān)系版本、勘誤和擴(kuò)展字段的邊界翻譯文檔永遠(yuǎn)以英文規(guī)范為母本但它不是英文規(guī)范的中文鏡像。規(guī)范是靜態(tài)的翻譯文檔是動(dòng)態(tài)的要記錄團(tuán)隊(duì)踩坑后的結(jié)論。第一記錄版本號(hào)和日期。規(guī)范組織會(huì)發(fā)修訂版翻譯文檔若不標(biāo)版本三個(gè)月后沒(méi)人知道它對(duì)應(yīng)哪個(gè)版本。第二記錄術(shù)語(yǔ)表的來(lái)源。規(guī)定哪些詞保留英文原詞哪些詞在項(xiàng)目里有約定俗成的譯法。第三對(duì)未翻譯或難以翻譯的字段保留英文原詞。我接手過(guò)一個(gè)項(xiàng)目有人把intevention這類字段硬譯成“介入”結(jié)果評(píng)審時(shí)沒(méi)人明白改回英文反而一目了然。另一個(gè)邊界是ext字段。2.5 規(guī)范里大量ext是開放的規(guī)范只給示例不給完整約束。如果中文翻譯文檔沒(méi)有明確標(biāo)注“這是交易平臺(tái)自定義字段不是標(biāo)準(zhǔn)字段”聯(lián)調(diào)就會(huì)變成黑匣子對(duì)方說(shuō)參考 OpenRTB 2.5實(shí)際上走的是imp.ext私有對(duì)象。我習(xí)慣把ext單獨(dú)列一節(jié)并區(qū)分“規(guī)范示例”與“需向交易平臺(tái)確認(rèn)”兩類。翻譯文檔的作用不是替代英文規(guī)范而是給英文規(guī)范做批注。批注里記錄的是團(tuán)隊(duì)翻車后的結(jié)論例如“這個(gè)字段在視頻場(chǎng)景不填會(huì)直接返回 4 開頭錯(cuò)誤碼”。這樣的文檔才真正值得信任。3. 按對(duì)象查還是按場(chǎng)景查把翻譯文檔變成排查工具拿到一份翻譯文檔不要從頭讀到尾。正確用法是把它當(dāng)排查工具像用字典一樣去查。3.1 兩種閱讀順序按對(duì)象逐字段讀還是按問(wèn)題反查新人容易從頭讀到尾但工程場(chǎng)景永遠(yuǎn)是“有一個(gè)現(xiàn)象要定位到字段”。所以我建議二八開兩成時(shí)間按對(duì)象通讀八成時(shí)間按問(wèn)題反查。按對(duì)象通讀是從object到字段建立全局觀。按問(wèn)題反查是從現(xiàn)象出發(fā)。舉個(gè)例子iOS 設(shè)備上視頻廣告一直沒(méi)有填充。按問(wèn)題反查的順序是先看請(qǐng)求里device.os是否等于 iOS再看video.protocols是否被對(duì)方支持繼續(xù)看imp.bidfloor是否高于平臺(tái)心理價(jià)最后看bcat是否誤把自己創(chuàng)意分類過(guò)濾掉。這個(gè)路徑在翻譯文檔里應(yīng)該能一步到位。真正好用的翻譯文檔不是把所有字段整齊排列而是給高頻字段加“常見(jiàn)問(wèn)題”備注。我見(jiàn)過(guò)一份團(tuán)隊(duì)自建文檔在regs.coppa字段后面寫“coppa1 表示兒童流量非兒童應(yīng)用千萬(wàn)不要填否則流量會(huì)被直接過(guò)濾?！边@個(gè)備注比翻譯本身值錢得多。3.2 自建“字段索引表”一份可檢索的 Excel 或 Markdown把文檔里的字段抽成索引表是投入最少、收益最高的事。結(jié)構(gòu)可以直接照下面的表頭做字段路徑對(duì)象類型必須性取值范圍/枚舉中文說(shuō)明關(guān)聯(lián)場(chǎng)景字段路徑寫完整路徑例如device.geo.country、imp.bidfloorcur。必須性用 R/R/O 標(biāo)注Required / Recommended / Optional。取值范圍寫枚舉數(shù)字和對(duì)應(yīng)的英文、中文。關(guān)聯(lián)場(chǎng)景寫“PMP 私有交易”“視頻請(qǐng)求”“兒童流量”。這份索引表放在 Excel 或 Markdown 都行關(guān)鍵是能全文檢索。我一般會(huì)把它拆成兩個(gè)工作表請(qǐng)求字段表和響應(yīng)字段表。因?yàn)轫憫?yīng)字段的排查頻率極高尤其是nurl、adm、price。字段多的時(shí)候不要按字母排序要按對(duì)象分組排序。這樣從問(wèn)題反查字段時(shí)可以順著對(duì)象一路找下去。提示字段索引表不要只抄規(guī)范要抄項(xiàng)目里實(shí)際用過(guò)的值。比如badv和bcat規(guī)范只給語(yǔ)義項(xiàng)目里要記錄廣告分類代碼在哪里查、誰(shuí)維護(hù)。3.3 字段四步走中文名、定義、取值、示例被問(wèn)到任何一個(gè)字段時(shí)用四步走回答第一步中文名。第二步定義。第三步取值類型與單位。第四步一段最小 JSON 示例。這個(gè)習(xí)慣能避免“字面翻譯陷阱”。舉個(gè)例子banner.wmax字面是“最大寬度”。但實(shí)際語(yǔ)義是“橫幅廣告允許的最大寬度”且當(dāng)w/h與wmax/hmax同時(shí)存在時(shí)平臺(tái)有優(yōu)先級(jí)差異。再比如topframe有人直接翻譯成“頂部框架”真實(shí)含義是“廣告是否在頂層窗口展示”。按字面理解前端參數(shù)就會(huì)傳錯(cuò)。遇到翻譯確實(shí)拗口的地方保留英文再補(bǔ)充注釋。中文文檔不需要把每個(gè)英文詞都翻譯真正重要的是團(tuán)隊(duì)建立共識(shí)。硬譯只會(huì)制造新的黑話反而不如直接用nurl、adm這樣的原詞。4. 用中文翻譯文檔反推代碼JSON 的逐行注解與字段校驗(yàn)翻譯文檔最終要落到代碼里才能兌現(xiàn)價(jià)值。我習(xí)慣的做法是先看中文翻譯搞懂字段語(yǔ)義再動(dòng)手寫 JSON 或 Schema 校驗(yàn)。4.1 一個(gè)最小 BidRequest 示例逐行注解以下是最小可用的 BidRequest 示例只保留核心字段{ id: 0a1b2c3d, imp: [ { id: 1, banner: { w: 320, h: 50 }, bidfloor: 0.5, bidfloorcur: CNY, pmp: { private_auction: 1, deals: [ { id: deal-001, bidfloor: 1.2, bidfloorcur: CNY, at: 2 } ] } } ], device: { ua: Mozilla/5.0 (Linux; Android 12; Pixel 6), ip: 203.0.113.42, os: Android, osv: 12, devicetype: 4 }, user: { id: u-abc-123 }, at: 2, tmax: 120, bcat: [IAB-25], badv: [example.com] }邏輯說(shuō)明id是請(qǐng)求唯一標(biāo)識(shí)交易平臺(tái)會(huì)拿它和響應(yīng)id對(duì)應(yīng)。imp是廣告位數(shù)組這里只請(qǐng)求一個(gè) 320x50 的橫幅。bidfloor是底價(jià)bidfloorcur是底價(jià)貨幣必須成對(duì)出現(xiàn)否則某些平臺(tái)按默認(rèn)美元處理。pmp表示私有交易deals數(shù)組里放的是與指定買家約定的交易 IDprivate_auction1表示只有列表內(nèi)的買家可以參與。參數(shù)說(shuō)明at是競(jìng)價(jià)方式2 表示密封競(jìng)價(jià)1 表示價(jià)格無(wú)下限。tmax是最大處理時(shí)間單位毫秒。bcat是廣告主類別黑名單IAB-25是某內(nèi)容分類。badv是廣告主域名黑名單這里阻塞了 example.com。devicetype4對(duì)應(yīng)手機(jī)設(shè)備查翻譯文檔枚舉表會(huì)發(fā)現(xiàn) 4 是 Phone不要和 1移動(dòng)/平板混淆。4.2 BidResponse 解析must-have 字段與空值處理對(duì)應(yīng)上述請(qǐng)求的響應(yīng)如下{ id: 0a1b2c3d, seatbid: [ { seat: dsp-001, bid: [ { id: a1, impid: 1, price: 1.8, adid: ad-10086, adomain: [advertiser.example.com], crid: creative-001, w: 320, h: 50, adm: html.../html } ] } ], cur: CNY }邏輯說(shuō)明響應(yīng)頂層id必須與請(qǐng)求id一致否則交易平臺(tái)無(wú)法關(guān)聯(lián)。seatbid里每個(gè)bid的impid必須對(duì)應(yīng)請(qǐng)求里的imp.id。price是競(jìng)價(jià)價(jià)格單位是cur這里為 CNY。adm是創(chuàng)意代碼直接返回物料 HTML。nurl如果存在則是通知地址交易平臺(tái)會(huì)在競(jìng)價(jià)成功通知后請(qǐng)求該地址。參數(shù)說(shuō)明adomain用于廣告主域名白名單校驗(yàn)若請(qǐng)求里有badv交易平臺(tái)會(huì)把這里的內(nèi)容做比對(duì)。crid是創(chuàng)意 ID一般與adid配合做頻控與反作弊。w/h必須與請(qǐng)求的 banner 尺寸一致如果不一致交易平臺(tái)可能直接丟棄這條出價(jià)。注意響應(yīng)里seatbid[].bid[]可以為空數(shù)組表示不競(jìng)價(jià)但頂層id不能為空。解析器要把“空競(jìng)價(jià)”和“協(xié)議錯(cuò)誤”區(qū)分開否則監(jiān)控會(huì)誤報(bào)。4.3 常見(jiàn)做法把 JSON Schema 和 protobuf 定義掛在翻譯文檔旁邊如果只是人工看 JSON翻譯文檔已經(jīng)夠用。但工程上要減少遺漏最好把機(jī)器校驗(yàn)規(guī)則也放到翻譯文檔旁邊。我一般會(huì)為字段索引表里的 Required 字段生成一份簡(jiǎn)化 JSON Schema用工具做上線前校驗(yàn)。常見(jiàn)做法是寫一個(gè)最小腳本讀取請(qǐng)求樣本逐字段對(duì)拍翻譯文檔里的必填項(xiàng)jq .imp[] | .id as $imp_id | .banner, .video, .native | select(has(id)|not) bid_request_sample.json這條命令會(huì)檢查每個(gè)imp對(duì)象下是否缺少必填 ID。jq的過(guò)濾邏輯并不復(fù)雜關(guān)鍵在于把翻譯文檔里的字段必須性持續(xù)固化成這種機(jī)器檢查規(guī)則而不是依賴人工 review。邏輯說(shuō)明select(has(id)|not)會(huì)輸出所有沒(méi)有id的展示對(duì)象。字段索引表里一旦有imp.id為 Required就應(yīng)該在 CI 里跑類似規(guī)則。這樣翻譯文檔就不只是給人看的也成了機(jī)器契約的一部分。5. 翻譯文檔使用避坑5 個(gè)實(shí)務(wù)陷阱與排查記錄再好的翻譯文檔用錯(cuò)了地方也會(huì)翻車。以下 5 條都是實(shí)際發(fā)生過(guò)的問(wèn)題按“現(xiàn)象 → 原因 → 解決”的方式記錄可以直接對(duì)照自查。5.1 “Recommended”當(dāng)“Required”用上線后收到一大片超時(shí)現(xiàn)象某廣告位接入新流量源后競(jìng)價(jià)請(qǐng)求大量超時(shí)交易平臺(tái)返回 5 開頭錯(cuò)誤碼。原因團(tuán)隊(duì)按中文翻譯文檔把所有 Recommended 字段都加上必填校驗(yàn)導(dǎo)致部分字段缺失就拒絕發(fā)請(qǐng)求。但規(guī)范里 Recommended 只是“推薦”不是“必須”。比如imp.banner.h在部分視頻插屏場(chǎng)景可以不填由平臺(tái)端自適應(yīng)。過(guò)嚴(yán)的校驗(yàn)把本應(yīng)發(fā)出去的流量拒之門外。解決把字段索引表統(tǒng)一改成三檔Required / Recommended / Optional并讓平臺(tái)側(cè)接口配置與翻譯文檔保持一致。Recommended 字段做警告不做硬校驗(yàn)。5.2 枚舉值漏翻設(shè)備類型表譯錯(cuò)一位數(shù)據(jù)直接進(jìn)錯(cuò)模型現(xiàn)象某模型按設(shè)備類型切分效果上線后發(fā)現(xiàn) Android 流量占比異常低。原因翻譯文檔里的devicetype枚舉只翻譯了名稱沒(méi)保留數(shù)字編號(hào)。實(shí)現(xiàn)時(shí)按字母順序重新映射把 Phone 和 Tablet 的編號(hào)寫反數(shù)據(jù)全部分錯(cuò)。解決在字段索引表里強(qiáng)制保留“數(shù)字編號(hào) 英文名稱 中文翻譯”三列。任何枚舉字段都不允許只寫中文杜絕二次理解。5.3 設(shè)備標(biāo)識(shí)相關(guān)字段語(yǔ)義不明GAID/OAID 映射寫反現(xiàn)象歸因數(shù)據(jù)對(duì)不上激活和點(diǎn)擊不是同一條設(shè)備記錄。原因在 OpenRTB 2.5 里設(shè)備標(biāo)識(shí)一般出現(xiàn)在device.ext或user.ext各家交易平臺(tái)字段名不一致。翻譯文檔把它統(tǒng)一成“設(shè)備 ID”沒(méi)說(shuō)明誰(shuí)是 Android 的 GAID、誰(shuí)是國(guó)產(chǎn)安卓的 OAID、誰(shuí)是 iOS 的 IDFA。后端點(diǎn)位配置時(shí)映射錯(cuò)位數(shù)據(jù)自然對(duì)不上。解決翻譯文檔單獨(dú)出一張“設(shè)備標(biāo)識(shí)映射表”列出常見(jiàn)交易平臺(tái)字段名與對(duì)應(yīng)系統(tǒng)。做不到統(tǒng)一時(shí)寧可保留原字段英文名也不要含糊翻譯成“設(shè)備 ID”。5.4 拿舊版中文文檔對(duì)接新版流量multiformat 支持缺失現(xiàn)象安卓端部分開屏流量無(wú)法競(jìng)價(jià)日志顯示請(qǐng)求被對(duì)方解析失敗。原因流量方升級(jí)到了 2.5 風(fēng)格的多格式請(qǐng)求一個(gè)imp同時(shí)放了banner和video。但對(duì)接方看的是基于 2.3 的中文譯稿解析邏輯只讀取banner遇到多格式請(qǐng)求直接丟出異常。解決升級(jí)翻譯文檔到 2.5并在代碼里兼容imp下多個(gè)展示對(duì)象并存。解析時(shí)不要用else if要用多個(gè)獨(dú)立判斷。5.5 把示例 JSON 當(dāng)完整協(xié)議漏掉必填的 bidfloor 與擴(kuò)展字段現(xiàn)象測(cè)試環(huán)境一切正常線上填充率驟降。原因測(cè)試請(qǐng)求復(fù)制自文檔示例示例里沒(méi)有bidfloor。翻譯文檔沒(méi)解釋這是示例最小值實(shí)現(xiàn)時(shí)完全照搬流量變成了無(wú)底價(jià)競(jìng)價(jià)而部分平臺(tái)對(duì)無(wú)底價(jià)請(qǐng)求不響應(yīng)。解決在翻譯文檔每個(gè)示例旁邊標(biāo)注“最小示例實(shí)際請(qǐng)求需要按業(yè)務(wù)補(bǔ)全字段”。同時(shí)把bidfloor、badv、bcat等項(xiàng)目級(jí)字段做成初始化模板不允許從零手寫。6. 讓翻譯文檔真正生效三欄術(shù)語(yǔ)表與每周對(duì)照評(píng)審一份翻譯文檔如果只停留在“有人翻譯過(guò)”的狀態(tài)很快就會(huì)失效。要讓它在團(tuán)隊(duì)里持續(xù)生效以下三個(gè)動(dòng)作最有效。6.1 三欄術(shù)語(yǔ)表英文原文、中文譯文、備注不要只做“英文-中文”兩欄。加一欄備注專門記錄邊界條件和項(xiàng)目習(xí)慣。例如英文原文中文譯文備注bidfloor出價(jià)底價(jià)單位跟隨 bidfloorcur不填可能被部分平臺(tái)按 0 處理nurl通知地址競(jìng)勝后由交易平臺(tái)請(qǐng)求不是創(chuàng)意物料地址imp廣告位請(qǐng)求可同時(shí)包含 banner/video/native不要拆成多個(gè) imppmp私有交易private_auction1 時(shí)僅 deal 列表內(nèi)買家可參與這個(gè)表是團(tuán)隊(duì)的共同語(yǔ)言新同學(xué)接入時(shí)先讀它能少踩一半坑。6.2 每周 Code Review 時(shí)對(duì)照規(guī)范原文過(guò)一遍變更協(xié)議不是天天變但業(yè)務(wù)代碼天天改。我習(xí)慣每周找個(gè)半小時(shí)把最近改過(guò)的請(qǐng)求構(gòu)造代碼和翻譯文檔對(duì)一遍。重點(diǎn)看字段必須性、貨幣單位、設(shè)備類型枚舉。這樣做不是走形式是防止某個(gè)同學(xué)按自己的理解新造了一個(gè)字段。6.3 一個(gè)具體技巧用“上線前驗(yàn)收清單”驗(yàn)證翻譯文檔可用性把翻譯文檔的要點(diǎn)固化成一張清單每次接新交易平臺(tái)前逐項(xiàng)打勾。包含請(qǐng)求 ID 是否在日志中可追蹤、廣告位 ID 是否映射一致、底價(jià)字段是否有單位、響應(yīng)解析是否處理空競(jìng)價(jià)、設(shè)備標(biāo)識(shí)是否區(qū)分系統(tǒng)、枚舉值是否有數(shù)字編號(hào)、擴(kuò)展字段是否單獨(dú)評(píng)審。我現(xiàn)在接任何新流量源第一件事不是看代碼而是先找對(duì)方要協(xié)議版本號(hào)再打開翻譯文檔對(duì)一遍枚舉和必須性。這個(gè)習(xí)慣幫我少發(fā)了無(wú)數(shù)次“為什么填充率是 0”的排查消息。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取