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

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

前言 我花了几天时间逐页核对 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) 广告素材或链接被更改导致归因失败

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

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

1. 先收集三类数据源：平台对账单（含原始明细）、你方服务器/SDK 日志、第三方监测数据（如有）。
2. 统一时间口径和字段命名（建议统一为 UTC，事件名统一为 impression/click/conversion）。
3. 用 impressionid / clickid / request_id 做主键逐条比对，找出缺失或重复的事件。
4. 按国家/媒体来源/广告位/SDK 版本分层统计差异，往往能快速定位问题范围。
5. 分析异常时间段（小时级）——若差异集中在某时段，可能是 SDK 崩溃、回源失败或平台系统升级导致。
6. 要求平台给出扣量/风控规则与具体扣减明细（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 天为准。教训：合同中列明窗口并保存归因链路证据（点击→重定向→转化时间）。

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

• eCPM = (总收入 / 总展示次数) * 1000
• Fill rate = 填充展示数 / 请求数
• RPM（页面收益）= 总收入 / 页面浏览量 这些公式用来快速识别是否存在极端异常（比如 eCPM 突然下降但请求量不变）。

给你的快速对账清单（上线前/结算时）

• 上线前：确认事件定义、归因窗口、请求/展示/点击/转化字段与 sample 数据。
• 每日校验：对比请求数与展示数（按小时）、检查 fill rate 和 eCPM 波动。
• 每次结算前：索要明细结算单、索要扣减明细、统一时间口径然后做小时级别抽样比对。
• 发现争议：保存原始日志、截图、时间戳和所有后台导出数据，必要时请求第三方仲裁或审计。

结语 广告结算看起来是“数学题”，但更多时候是“流程与证据”的比拼。掌握好数据口径、保留关键 ID、明确合同条款，并把对账流程制度化，就能把被动挨扣的概率降到最低。遇到不透明的平台，先走小额试水并要求细化条款；对长期合作方，争取在合同中写明透明度和对账机制，这样双方都更安心。

如果你需要，我可以把上述对账流程做成一页可直接套用的对账模板（字段、示例 CSV、对账步骤），或者帮你用你现有的结算单做一次差异分析。想要哪个就说。

• 喜欢（11）
• 不喜欢（2）