我查了91在线相关页面：背后的广告结算机制 · 我把坑点列出来了

V5IfhMOK8g2752026-01-19 12:04:02

前言我花了几天时间逐页核对 91 在线（以及其相关流量来源和平台）公开的广告位、SDK 接入说明、结算规则与开发者社区讨论，把常见的结算逻辑、数据差异来源和常见“坑”梳理成一份可直接用的清单。目标很简单：让流量主、投放方或内容负责人在谈合作、对账和结款时不再被模糊条款牵着走，能更快发现问题并保住应得收益。

我怎么做的

对比了公开页面、开发者文档、SDK 接入说明以及若干第三方监测（例如广告平台后台导出的 CSV、服务器日志）；
汇总社区和论坛中关于结算争议的典型案例；
把常见的计费/结算模型拆解成可核对的数据点，配合具体的对账动作。

先把结算模型说清楚（概念扫盲）

CPM（千次展示付费）：按展示计费，通常以“可竞价展示或可视展示”为准。展示定义不一致会直接影响收入。
CPC（点击付费）：按点击计费，点击判定和防作弊策略差异会导致计费差异。
CPA/CPL（行为或线索付费）：按注册、下载、激活或留资计费，需有明确事件定义和归因窗口。
CPS（按成交付费）：对比 CPA 复杂，常牵涉到二次结算、退款扣除和归属规则。
Rev-Share（分成）：平台按分成比例结算，通常有保底、最低分成门槛和不同结算周期。

常见坑点（按问题强度排序） 1) 数据口径不一致——最常见也最致命

平台统计的是“填充成功的展示”或“展示请求”，你看的是页面或客户端的展示日志，两个口径差几十个百分点并不罕见。
建议核对字段：请求ID / impressionid / timestamp / eventtype（request, bid, impression, click, conversion）。

2) 归因窗口与归属规则模糊

CPA/CPL 常见归因窗口不同（1天/7天/30天），有些平台还用最后点击/首次点击或加权模型。结算时先问清楚默认归因策略并写进合同。

3) 无效流量与风控扣量

平台会在结算前做流量清洗，常见扣量有：机器人流量、重复点击、异常行为等。很多平台只给模糊说明，不给扣减明细。
最好争取“扣量明细”或可审核的流量报告（按小时、按国家、按 IP 段/UA 汇总）。

4) 延迟结算与保留期

部分平台有 30/45/60 天保留期用于反作弊或退款核查，真实到账被延后或出现回拨。合同里没有明确保留期就容易被动。
建议约定最长保留期和清算触发条件。

5) 隐性费用与平台抽佣

有的平台会收服务费、技术费或“媒介费”，结算单里只给净额。别只看毛收入，要求列出扣项。
汇率、跨境手续费、税务代扣也会影响到手金额。

6) 计费与结算时区不一致

不同平台使用不同时区（UTC / 本地时间），导致日结/周结数据对不齐，尤其在跨日高峰时差异明显。
对账时统一时区和时间戳解析规则非常必要。

7) 事件定义不明确导致的争议

比如“激活”到底是安装成功、首次打开，还是满足一定留存？没有明确定义，平台会按最有利于自己的口径处理。

8) 第三方监测和平台数据不一致

多头打点时，第三方监测（如 AppsFlyer、Adjust 或 server-side logs）与平台数据会有差异。常见原因包括网络抖动、SDK 丢事件、事件过滤策略不同。
推荐使用 server-to-server 回传以减少 SDK 丢包问题，并保存原始请求日志作证据。

9) 退款/退量策略不透明

某些结算会在下周期回扣之前发生退款或退量，平台往往只在对账单里体现，不提前通知。

10) 广告素材或链接被更改导致归因失败

修改投放链接或加参数出错会让转化无法归因到媒体，造成无辜扣量。

如何一步步查清对账差异（实操流程）

先收集三类数据源：平台对账单（含原始明细）、你方服务器/SDK 日志、第三方监测数据（如有）。
统一时间口径和字段命名（建议统一为 UTC，事件名统一为 impression/click/conversion）。
用 impressionid / clickid / request_id 做主键逐条比对，找出缺失或重复的事件。
按国家/媒体来源/广告位/SDK 版本分层统计差异，往往能快速定位问题范围。
分析异常时间段（小时级）——若差异集中在某时段，可能是 SDK 崩溃、回源失败或平台系统升级导致。
要求平台给出扣量/风控规则与具体扣减明细（IP 段、UID 列表或错误码），便于复盘。

可写进合同或谈判时硬要的条款（样例思路）

明确计费口径与归因窗口（例：CPM 以可视展示为准；CPA 以 7 天最后点击为准）。
结算周期与保留期（例：Net30，最多 45 天保留，保留期结束无争议后 7 日内支付）。
扣量/回拨须提供明细（包含事件 ID、时间戳、扣减原因）。
支付货币、结算费率、税务代扣说明和手续费分担。
双方数据对账流程与周期、仲裁机制和访问对方日志的权限范围（必要时可加第三方审计）。
对 SDK/代码变更的通知义务与回滚责任。

技术层面的防护和优化建议（便于减少纠纷）

尽量使用 server-to-server（S2S）回传关键转化，降低 mobile SDK 丢包风险。
在请求中保留完整的 requestid/impressionid，并在所有环节传递并存档。
在关键流量上部署第三方监测（可视化检测、流量质量检测服务）作为仲裁证据。
对 SDK 版本和投放参数做严格变更管理，任何改动都做 A/B 并记录。
设置默认 floor（底价）和黑名单/白名单机制，防止低质流量被误算为收益。

对投放方的建议（如何避免被“忽悠”）

要求平台给出样例结算单，先做小额测试跑量，观察对账差异再放大。
关注 eCPM 与 fill rate 的同时段波动，异常波动多数是质量或竞价问题而非随机波动。
谈判时要求明确退量/扣量的最大比例和理由列表，不接受“平台风控认为”这种模糊原因。

常见争议案例（简短示例）

案例 A：一个 SDK 在高峰期丢失 20% impression，平台以“展示失败”理由扣款，但未提供原始 request_id 列表，导致对账难以胜诉。教训：保留请求日志，并要求对方提供扣减 ID。
案例 B：CPA 活动对归因窗口认定不同，投放方以 7 天为准、平台以 1 天为准。教训：合同中列明窗口并保存归因链路证据（点击→重定向→转化时间）。

简单结算核算公式（便于检查）