企业官网建设流程全解析

信息流投放做久了，最怕的就是预算花出去之后，要等四十五天才突然发现某个渠道的整体ROI是亏的。我前两年就陷在这种被动里：投放计划开了几百条，数据散落在好几个广告后台，每天靠人工导出Excel再合并，等报表整理完，趋势已经走到第三天了。后来实在顶不住，我做了这么一套东西：信息流广告ROI线性预测看板，加上投放分析监控看板和完整的数据处理入库链路，把取数、清洗、入库、特征计算、模型训练、可视化展示全部打通。这篇就把整个项目的架构设计、数据入库流程、线性预测模型的落地方法，以及监控看板的展示逻辑一次讲清楚。如果你也是做投放优化、数据分析，或者正打算从零给团队搭一套广告数据监控体系，这篇文章可以作为一份完整参考。

1. 项目背景与整体架构设计

1.1 为什么做这件事：投放决策滞后的痛

其实一开始我也没想搞这么复杂。最开始的问题很简单：每天打开五六个广告后台，把消耗、点击、转化数据复制到Excel里，手动算ROI、CTR、CVR，然后做一张日报表发给老板。听起来不难，做起来全是坑。首先是平台和平台的口径不一样：同一个广告计划，在巨量引擎后台上看到的消耗数字，从API拉出来可能差两到三个小时；腾讯广告的转化回传又有延迟，今天看到的CVR过两天又会变。这就导致每天日报的数字，第二天自己都能推翻自己。

更要命的是ROI的反馈周期。信息流广告从用户点击到最终成单，中间往往隔着好几天。今天花出去的钱，可能要到第七天甚至第十四天才能确认带来多少GMV。等你把所有回传数据收齐，确定这个计划的真实ROI，钱早就已经按这个节奏花了一个多星期了。投放团队当时给我的反馈就是：能不能提前两三天告诉我这个计划大概会跑成什么样，不行就及时关掉。

所以项目刚开始的需求非常明确，就三个方面：第一，把每天从各平台拉回来的数据自动处理好，不要再用人工Excel合并；第二，在数据还没完全回传的时候，用已有的信息提前预测ROI大概会落在哪里；第三，做一个所有人都能直接打开看的监控看板，不用再等日报。需求听起来简单，但真落地的时候牵扯到的细节非常多，下面逐个展开。

1.2 技术选型：轻量优先，够用就好

先说技术栈。我这边是小团队，没有专门的大数据平台，所以一切以轻量、够用、好维护为原则。

• 语言：Python 3.10，处理数据、调接口、跑模型都靠它
• 存储：MySQL 8.0，放了所有明细数据、汇总数据和特征数据
• 调度：Airflow 2.x，用来编排每天的数据任务，一开始用的crontab，任务多了之后切到Airflow
• 缓存：Redis，主要用来做实时看板接口的缓存，减轻数据库压力
• 可视化：前端用ECharts加自研管理后台页面；如果不想开发前端，直接用Metabase或者Superset也能实现大部分看板效果
• 模型：scikit-learn的Ridge回归作为主力模型

为什么选这么一套组合，而不是上Flink、ClickHouse、Hive那一套？原因很简单：项目初期每天处理的数据量就是百万级左右，MySQL完全扛得住；团队里也没有专门的大数据运维人员，引入太多组件反而成了负担。先把链路跑通、把业务问题解决，比技术栈炫酷重要得多。这不算什么高深的架构，但胜在每一层都是团队里有人能维护的。

整体数据流向是这样的：每天早上由调度任务触发，先从各个广告平台API拉取昨天的消耗数据和转化数据，写入原始数据表；接着跑清洗任务，做去重、时区统一、ID映射之类的处理，生成标准的事实明细表；然后根据明细表做按天、按渠道、按计划的汇总，生成指标宽表；再基于宽表训练ROI线性预测模型，并把当天预测结果写回预测表；最后看板后端从这些表里取数，通过接口把数据给到前端展示。整个链路串起来之后，每天上午十点前，当天所有报表、预测和看板就自动更新完毕，不需要任何人手工参与。

2. 数据处理入库全流程

2.1 数据源梳理与采集策略

做任何数据处理项目，第一步都不是写代码，而是先把数据源理清楚。我当时花了一天时间，把所有要接的源理成了一张表：源名称、接口文档、拉取权限、字段说明、更新频率、延迟时长、对账口径。这个动作看起来简单，但后面所有清洗逻辑都建立在这张清单上，如果一开始不把这个盘明白，后面的清洗和入库一定会反复返工。

信息流广告这边的数据源大致分三类。第一类是广告平台侧，包括巨量引擎、腾讯广告、磁力引擎等平台的消耗、展示、点击、CPM、CPC、CTR、CPL之类的数据，主要通过平台开放平台的API拉取，按广告主ID加时间范围查询。第二类是业务侧转化数据，包括订单量、GMV、激活量、付费用户数，这部分数据从自己的业务库或者数据上报服务取，通过click_id和广告平台的点击关联起来。第三类是物料信息，包括计划名、素材方向、落地页URL、投放时段、出价策略，这些字段多数在平台的计划管理接口里能拿到，也有少量需要内部维护。

采集策略上要注意一个核心问题：不同平台数据的时间口径不一样。大多数平台支持按天拉取，但当天数据会持续变化。所以我当时的策略是：每天凌晨2点拉取"昨日全量"数据入库，然后到第二天上午10点再做一次修正拉取，把平台延迟回传的部分补上。换句话说，报表上的"昨日数据"，严格意义上要等第二个跑批之后才算准。这个修正机制非常重要，否则你看到的ROI永远是偏低的，因为转化数据还没有完全回传。

2.2 清洗、标准化与归因匹配

数据从API拉回来之后，直接入库是不行的，必须经过清洗和标准化。这一步踩过的坑最多，我列几个重点。

第一个是去重。平台接口偶尔会返回重复记录，尤其是网络超时重试的时候。所以每一张原始表我都设计了唯一键，比如ad_id加stat_date加data_source的组合，入库时用INSERT ... ON DUPLICATE KEY UPDATE，保证同一条数据重复拉也不会产生脏数据。

第二个是时区统一。有的平台按北京时间给数据，有的按UTC给，如果直接混用，日汇总就会对不上。我的做法是：拉取时把接口参数统一转成UTC+8，入库前再把日期字段全部转成北京时间，最后在统一的时区里做汇总。这个听起来很基础，但一旦渠道多起来，总有一两个平台会漏掉时区转换，最后对账的时候数据就差了好几个小时。

第三个是ID映射。同一个计划在巨量引擎叫"23456789"，在腾讯广告叫"plan_987654321"，在内部业务库可能又有一个自增id。所以我在库里建了一张mapping表，把各平台计划ID统一映射到内部计划编号，后面所有表都挂在内部编号上，这样跨平台对比才有意义。

第四个是归因匹配。这块比较绕，简单解释一下：广告平台告诉你"这一天这个计划产生了1000次点击"，但业务侧不可能立刻知道这1000次点击里有多少人最终完成了购买，因为用户可能在点击后第二天才下单。所以业务侧在生成点击时，会给每次点击分配一个click_id，并通过前端SDK在用户下单时把这个click_id带回服务端；服务端再按归因窗口（我这边配置的是点击后7天内）把订单归到对应的点击和计划上。这套逻辑直接决定ROI算得准不准，是整个数据链路里最重要的一环。

清洗逻辑跑完之后，数据就进入标准的事实明细表，后面所有汇总和预测都基于这份相对干净的数据展开。

2.3 库表设计与存储方案

库表设计我遵循"明细表、汇总表、特征表三层分离"的思路，不搞一张大宽表硬扛所有查询。

明细表只存原子数据。比如广告消耗明细表，粒度是"日期加广告账户加计划加素材"，每个字段尽量保持原始语义，不做聚合。

CREATE TABLE fact_ad_spend_daily ( id BIGINT AUTO_INCREMENT PRIMARY KEY, stat_date DATE NOT NULL COMMENT '统计日期（北京时间）', channel VARCHAR(32) NOT NULL COMMENT '渠道', account_id VARCHAR(64) NOT NULL COMMENT '广告账户ID', plan_id VARCHAR(64) NOT NULL COMMENT '平台侧计划ID', inner_plan_id BIGINT NOT NULL COMMENT '内部计划ID', creative_id VARCHAR(64) COMMENT '素材/创意ID', spend DECIMAL(12,4) NOT NULL DEFAULT 0 COMMENT '消耗', impression INT NOT NULL DEFAULT 0 COMMENT '展示', click INT NOT NULL DEFAULT 0 COMMENT '点击', cpm DECIMAL(12,4) DEFAULT 0, ctr DECIMAL(8,6) DEFAULT 0 COMMENT '点击率', cpc DECIMAL(12,4) DEFAULT 0 COMMENT '点击均价', update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_plan_date (stat_date, channel, plan_id, creative_id), KEY idx_plan (inner_plan_id), KEY idx_date (stat_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='广告消耗日明细表';

汇总表是关键。因为看板90%的查询都不需要下钻到明细，只要查"某天某渠道汇总"或"某天某计划汇总"，所以我把常用的维度提前聚合好，查询快很多。比如渠道日汇总表，按"日期加渠道"粒度存储消耗、点击、转化、GMV、ROI等核心指标。细节上要注意，汇总表里最好加一个数据状态字段，标记当前是预估数据还是修正后数据，避免后续对账混乱。

特征表是给模型用的宽表，把模型需要的特征从明细和汇总里整理出来，按"日期加渠道加计划"一行一行地放好。这样训练模型时不用每次都做复杂的关联查询，直接读这张表即可。正因为有了这张宽表，后来迭代模型特征的时候方便很多，不用改底层明细表结构。

存储策略上，明细表按月份做RANGE分区，一个月一个分区，查询和清理都方便。超过6个月的历史明细数据，我会定期导出归档到一个备份库里，线上只保留最近6个月，控制表体量。这样做的好处是，既保留了历史数据的可追溯性，又不会让主库查询越来越慢。

2.4 调度、幂等与数据校验

调度这一块，我一开始用的是crontab加shell脚本，任务少的时候够用。但后来任务增加，依赖关系复杂起来，比如"汇总任务必须等所有渠道拉数任务成功后才能跑""特征任务必须等汇总完成后才能跑"，用crontab硬编太痛苦，就切到了Airflow。

整个DAG的执行顺序大概是这样的：

1. 拉数任务（并行）：巨量引擎拉取、腾讯广告拉取、磁力引擎拉取、业务转化数据同步
2. 清洗入库任务：等所有拉数任务成功后，对原始数据做清洗，写入事实明细表
3. 汇总任务：基于明细表生成渠道日汇总、计划日汇总
4. 特征任务：基于汇总和数据修正逻辑生成特征宽表
5. 模型任务：训练模型并输出预测结果
6. 看板刷新任务：预热看板接口缓存

每一步都是可重跑的。所谓可重跑，就是每次执行同一个任务前，先删除当天相关的数据，再重新写入，保证任务重复执行多次也不会产生重复数据。这个"先删后写"的幂等机制是批处理项目里的基本功，一定不能省。否则某天调度失败后手动补跑一次，报表上就可能出现翻倍的数据。

数据校验我也单独加了一层。每次跑批结束后，我会对关键数字做自动检查，比如"今天各渠道消耗合计与昨天相比不能低于20%或高于200%""某计划昨日的点击为0但消耗大于0，就需要告警"。这些规则不用很复杂，但能第一时间发现源接口异常或清洗逻辑出了问题，避免错误数据一路污染到看板。印象里有一次平台接口字段突然改动，导致消耗字段解析成了0，就是靠这个校验规则发现得早，没造成太严重的后果。

3. ROI线性预测模型：从无到有

3.1 为什么没有一上来就用深度学习

当时有不少人问我，ROI预测为什么不直接上LSTM或者XGBoost？我的回答是：先想清楚你拿预测结果来干什么。投放团队要的是可解释、可干预的参考数字，他们要能看明白"为什么预测这个计划ROI会跌"，而不是一个黑盒给个彩票号码。线性模型的好处就在于，每个特征对应一个系数，你可以直接解释：CTR最近掉了，所以预测ROI往下走，这个逻辑对投放同学来说非常友好。

另外，样本量也不支持。一个计划从上线到衰退，生命周期可能就两到三周，能拿到的有效历史样本就是十几二十天，这样的量级去训一个复杂模型，过拟合的风险远大于收益。Ridge回归加几组构造特征，反而能在这种小样本场景下稳定输出。所以我当时的策略是，先用线性模型把整套流程跑通，保证预测结果稳定、可解释，如果后续某个渠道的数据量积累上来了，再针对这个渠道尝试更复杂的模型。

这里的"线性"不是简单的一条直线，而是多元线性回归，ROI被建模为多个特征的加权和。公式长这样：

ROI_next_7d = w0 + w1 * spend_7d + w2 * ctr_7d + w3 * cvr_7d + w4 * cpa_7d + w5 * channel_a + w6 * channel_b + ...

其中spend_7d是近7天消耗，ctr_7d和cvr_7d是近7天平均点击率和转化率，channel_a、channel_b是渠道的虚拟变量。通过最小二乘法拟合出w0到w6这组权重，就能用当天已知的信息去预测未来7天的ROI。这套思路虽然简单，但在投放预算分配和计划去留判断上，已经比拍脑袋强太多了。

3.2 特征工程与样本构建

特征工程是这一步的重头戏。我最终使用的特征组合大致包括几组：消耗类（近1天、近3天、近7天的消耗及对数变换）、效率类（近7天平均CTR、CVR、CPC、CPA）、计划属性类（渠道虚拟变量、广告位类型、出价方式）、新鲜度类（计划已上线天数、素材上新距今天数）、环境类（星期几虚拟变量、是否活动期）。这些特征不是一次就想全的，而是结合投放同学的经验一点点补进去的，每补一个特征，模型在验证集上的效果都会有些变化。

这里有个很容易犯的错：不小心把未来信息混进特征里。比如你想预测未来7天ROI，训练时用的特征只能包含"预测时点已知"的信息，如果拿当周完整的转化数据去训练，看起来效果很好，上线就崩。这种"数据泄漏"问题在时间序列预测里特别隐蔽，我一开始也踩过，后来把所有特征按数据可用时间打上标签，才彻底解决。

样本构建我按"时间切片"来做：每行样本对应的预测目标，是"从T日开始未来7天的ROI"。特征则全部使用T日及之前的信息。训练集和测试集按时间顺序切割，比如用过去180天数据训练，最近30天数据做验证，绝对不能随机抽样，否则模型学到的是"记住了答案"而不是"学会了推断"。这一点对做这类预测项目的朋友来说，是必须刻在脑子里的。

3.3 建模与评估

建模代码本身不复杂，我用的是scikit-learn的Ridge回归，加了一个StandardScaler做特征标准化。Ridge的好处是有L2正则项，在特征之间存在多重共线性时比我直接裸用LinearRegression稳定很多。

import pandas as pd from sklearn.model_selection import TimeSeriesSplit from sklearn.linear_model import Ridge from sklearn.preprocessing import StandardScaler df = pd.read_sql(""" SELECT dt, channel, plan_id, spend_1d, spend_7d_log, ctr_7d, cvr_7d, cpc_7d, cpa_7d, plan_age, creative_age, is_weekend, is_activity, roi_next_7d FROM ad_roi_feature WHERE dt >= DATE_SUB(CURDATE(), INTERVAL 180 DAY) """, engine) df = df.dropna(subset=["roi_next_7d"]) features = ["spend_1d", "spend_7d_log", "ctr_7d", "cvr_7d", "cpc_7d", "cpa_7d", "plan_age", "creative_age", "is_weekend", "is_activity"] X, y = df[features], df["roi_next_7d"] tscv = TimeSeriesSplit(n_splits=5) for fold, (tr_idx, va_idx) in enumerate(tscv.split(X)): X_tr, X_va = X.iloc[tr_idx], X.iloc[va_idx] y_tr, y_va = y.iloc[tr_idx], y.iloc[va_idx] scaler = StandardScaler() X_tr_s = scaler.fit_transform(X_tr) X_va_s = scaler.transform(X_va) model = Ridge(alpha=1.0) model.fit(X_tr_s, y_tr) print(f"fold {fold} r2:", model.score(X_va_s, y_va))

评估指标我重点看两个：一个是R²，衡量模型对历史波动能解释多少；另一个是MAPE（平均绝对百分比误差），衡量预测值和真实值平均差几个百分点。对我这个场景来说，MAPE在15%以内就基本够用，因为投放决策本身也不需要精确到小数点后两位。还有一个经验：不要把R²作为唯一追求，有时候R²很高但预测误差很大，说明模型过拟合了历史波动，这类模型看板用起来反而不踏实。

3.4 预测上线与看板联动

模型训练好之后，预测结果没有直接算完就完事。我把预测结果按"内部计划ID加预测日期"写入一张预测结果表，同时记录下模型版本号、特征版本号和训练数据截止日期。这样哪一天预测出现了问题，可以很快定位是模型版本不对，还是特征数据出了问题。这个版本记录的习惯救了我好几次，因为模型迭代频繁，如果没有版本回溯，线上预测错了根本查不出原因。

看板联动这一块，我在总览页的ROI趋势图上同时画了两条线：一条是实际ROI曲线，一条是预测ROI曲线。两线之间的距离越近，说明模型越靠谱；一旦出现大偏差，立刻复查。投放团队的习惯是每天上午先看一眼预测值，如果某个计划预测未来7天ROI低于阈值，就提前下调出价或关停，不用等真实数据反馈。这里要注意，预测值只是参考，最终决策还是要结合投放同学的判断，不能完全依赖模型。

这里有一个非常重要的细节：预测结果的刷新频率。刚开始我做成每天凌晨跑一次，后来发现当天的实时消耗数据每两个小时就变化很大，预测结果一天更新一次根本不够。所以我改成了"凌晨跑修正版预测加每两小时跑一次实时预测"，实时预测的数据来自当天增量汇总，这样看板上的预测数字会随着当天投放进度滚动更新，和投放后台的实时变化保持同步。

4. 投放分析监控看板展示

4.1 指标体系设计：不要只堆数字

做看板最忌讳的就是把一堆指标平铺上去，看上去信息量很大，实际上没人看得懂。我做这个看板时先定了一个原则：把指标分成三个层级，让看的人第一眼就知道"今天整体到底行不行"，然后才看"哪个环节出了问题"。

核心指标放在最顶层，包括ROI、总消耗、GMV、付费用户数。这四项直接回答老板最关心的问题：今天花了多少钱，赚了多少回来，赚得比昨天好不好。过程指标放在第二层，包括CTR、CVR、CPC、CPM、CPA。这五项回答投放执行层的问题：如果ROI不行，到底是曝光太贵、点击太低还是转化太差。辅助指标放在第三层，包括素材上新数、计划存活率、计划衰退速度，这些是优化师做下一步决策要看的。

这个层级关系在页面布局上也要体现出来。我见过很多看板把核心指标和辅助指标混在一起，排成一行十来个卡片，看的人反而抓不住重点。正确的做法是，核心指标一定要在页面最显眼的位置，字号和颜色都要突出，过程指标和辅助指标放在下面或侧边，需要的时候再看。

4.2 看板分层：总览、渠道、计划、素材

看板页面本身我分成了四层，每一层解决一类问题。

总览层是所有人每天打开的第一个页面。顶部一排核心指标卡片，每个卡片显示今日值、昨日值和7日均值，值的变化超过阈值就用颜色标出来。下方是一张最近90天的ROI趋势图，同时画上预测线，让老板一眼看出趋势和预测是否吻合。再往下是各渠道今日核心指标对比表，按ROI降序排列，表现差的渠道自动标红。这一层的设计目标是"十秒内判断今天整体是好是坏"。

渠道层进入单个渠道的详情。比如你点进巨量引擎，能看到这个渠道的消耗和ROI双轴图、分计划的表现排行、近7天的CTR/CVR漏斗。这一层最大的用途就是定位问题出在哪个渠道的哪个计划上。实际使用中，投放负责人的第一反应通常是：总览里ROI跌了，然后立刻进渠道层看是哪个渠道拖了后腿。

计划层和素材层是投放优化师最常用的。计划层有每个计划的生命周期曲线，能清楚看到计划什么时候起量、什么时候衰退。素材层会展示每套素材的CTR、CVR趋势，用来判断素材跑量的持续性。因为素材是有生命周期的，一般上新后三天内表现最好，之后会逐渐衰减。我在这层放了一张"素材新鲜度 vs ROI"的散点图，能直观看到素材越新ROI整体越好的规律，提醒团队持续上新素材。这个规律其实很多投放同学都知道，但用一个图可视化呈现出来后，对排期和内容规划的指导意义更大。

4.3 图表选型与视觉呈现细节

图表选型遵循"一个图回答一个问题"的原则。趋势数据一定用折线图，占比数据用堆叠条形图，排名对比用横向条形图，分布关系用散点图。不要在一个图里塞三种颜色以上的信息，也不要为了酷炫做一堆没有业务含义的3D和动画。你可能会觉得这些都是基本功，但实际看板项目里，图表选错导致的误读非常常见。

双轴图这里提个醒：左侧放消耗、右侧放ROI的时候，上下限的设定要小心。如果左侧消耗最大到100万，右侧ROI最大到2，轴的刻度差距太大会导致ROI的波动看起来非常平缓，掩盖问题。我当时的处理是，在右侧ROI基线1.0的位置画一条虚线，低于虚线就说明在亏钱，这样视觉上更直观。还有一点，轴刻度上限不要固定得太死，要让数据自己在图表中充分展开，否则不同天之间的对比也不明显。

颜色上统一用红绿来表达好坏：绿色代表达标，红色代表预警。但不要只用颜色来区分，因为有色弱用户，需要同时配合数值和箭头。这个细节我是在内部测试时被同事提醒的，当时才意识到不是所有人都能靠颜色快速判断。后来所有关键状态都同时加了文字标签，比如"达标""预警"，比单靠颜色可靠得多。

4.4 告警与自动通知

看板解决的是"主动去看"的问题，但很多紧急情况需要"被动通知"。我做了一个告警服务，挂在汇总任务之后，每天跑完数据就检查一遍所有指标是否越界。

告警规则分三类：绝对值阈值告警，比如单渠道ROI低于0.8；波动率告警，比如某计划消耗环比昨天同一时段上涨超过100%；持续性告警，比如某个渠道ROI已经连续3天下降。不同类型的告警推送到不同的群，避免把所有人都打扰一遍。比如消耗波动告警推给投放负责人，核心指标异常推给数据组和管理层，这样信息传递更精准。

推送渠道我用的是企业微信群机器人，通过Webhook发markdown格式的消息，实时性很好。下面是当时写的推送脚本片段：

import requests def send_roi_alert(channel, roi, yesterday_roi, plan_list): webhook_url = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx" drop_ratio = (yesterday_roi - roi) / yesterday_roi * 100 content = ( "**【ROI预警】**\n" f"> 渠道：{channel}\n" f"> 今日实时ROI：{roi:.2f}\n" f"> 较昨日同期下降：{drop_ratio:.1f}%\n" f"> 涉及计划：{', '.join(plan_list[:5])}" ) payload = {"msgtype": "markdown", "markdown": {"content": content}} requests.post(webhook_url, json=payload)

告警频率要控制好。同一个渠道、同一个规则，半天之内不要重复推送超过两次，否则群里天天刷屏，大家就麻木了。我用Redis对告警规则做了去重，比如同一个计划ID在6小时内不重复触发同一条规则。这个去重逻辑很关键，因为告警服务本身也会被调度触发，如果源头数据连续几天异常，不控制频率的话，一个消息能刷几十条。

5. 数据处理与模型落地中的坑

5.1 数据不一致的三大元凶

这个项目跑起来之后，最常被挑战的就是"数字为什么对不上"。我复盘了一下，主要矛盾集中在三个地方。

第一个是平台回传延迟。同一个计划，在平台后台看到的消耗和转化，跟通过API拉出来的数据往往不一致。尤其是转化数据，平台有反作弊过滤，也有回传延迟，今天看是100个转化，明天可能变95个，后天又变102个。我的解决方案是：不要用当天数据做最终决策，日常监控用"预估数据"，每周一对账一次用"修正后数据"。看板上标明了数据状态，预估和修正分开展示。这个"数据状态"字段帮了大忙，让团队明白当前看到的数字是暂时的，不是最终结论。

第二个是时区差异。接入海外渠道之后问题更明显，有的平台按UTC统计，有的按东京时间，业务库又统一用北京时间，稍不注意日期汇总就对不上。清洗层统一转北京时间之后，我把每一张表的时区说明都写进了数据字典，后来对账省了很多事。数据字典这个习惯，一开始觉得麻烦，后来发现这是多人协作时最值钱的东西。

第三个是归因窗口不一致。有的平台默认点击后1天归因，有的是7天归因。同一个订单，在A平台算A计划的，在B平台算B计划的，两边ROI加起来甚至可能超过100%。这个没法完全消除，只能统一口径，在内部把归因窗口固定下来。内部归因用点击后7天，对外报表也统一用这个口径，至少保证自己内部是自洽的。对账的时候，对外解释的时候口径不一致很容易引起信任危机，所以统一归因窗口是底线。

5.2 MySQL慢查询与存储性能优化

数据量上来之后，MySQL的慢查询问题也随之而来。我印象很深的一个案例是，有一张明细表到了几千万行之后，跑计划级汇总任务的SQL从原来的20秒直接涨到3分钟，整个调度链路都被拖住了。

排查的时候我先打开了MySQL慢查询日志，把执行时间超过1秒的SQL都捞出来分析。当时发现最严重的是一条按日期范围加渠道分组统计的查询，虽然已经建了索引，但索引只建在stat_date上，加上channel和plan_id之后就无法命中联合索引，导致每次都要扫全分区。这个案例很典型：不是没建索引，而是索引建得不满足查询模式。

优化方案做了三件事。第一，把最重要的查询改成联合索引：KEY idx_date_channel (stat_date, channel, inner_plan_id)，让查询能走索引下推。第二，给明细表做按月RANGE分区，查询直接落在对应分区，减少扫描量。第三，把常用的汇总查询改成"先刷汇总表、再看板查汇总表"的模式，而不是让看板SQL直接扫明细表。优化之后，原来3分钟的查询降到了5秒以内，整个调度链跑完的时间提前了将近40分钟。这个收益是实打实的，每天早上能看到报表的时间从十点半提到了九点半。

这里还要说一句，慢查询日志不是打开就不管了，我设置了一个定时任务，每周把慢查询日志里的高频SQL抓出来，人工看一遍，判断有没有新的优化空间。这是一项常规但很有效的数据库运维习惯，尤其对于广告数据这类写多读多的场景，索引策略需要随着数据量和查询模式的变化持续调整。

5.3 线性模型失效的典型场景

线性模型不是万能的，我在使用过程中遇到过几个让它"翻车"的场景。

第一个是节假日和大促。双11前后投放数据完全偏离正常规律，线性模型基于历史均值学习出来的权重，会严重低估大促期间的ROI拉升。我当时的处理方式是：在特征里加入"距大促天数"的变量，同时在大促前一周直接把每日预测结果替换成人工预估，等大促结束后再切回模型预测。这里的核心思路是：模型处理不了小样本的突变场景，人工介入是必要的，不要迷信模型在所有情况下都优于人。

第二个是素材衰退导致的预测滞后。一个新素材上线前两天ROI很高，模型基于这个前景预测未来7天都会很好，但第三天素材开始衰退，实际ROI直线下降。这个问题的本质是模型没有区分素材新鲜度。我在特征里加了creative_age之后，预测的效果有明显改善，但仍然无法完全捕捉素材突然衰退的信号。所以看板上做了一个提醒：任何预测都仅供参考，素材类计划必须人工复核。

第三个是"填0"的问题。有些小计划当天没有消耗，ROI字段被填成了0，模型会把这些0当成真实标签去学习，导致整体预测被拉低。解决办法很简单，统计和建模时都要过滤掉"消耗为0或转化缺失"的样本，不要让空值变成有效数字。这个坑特别隐蔽，因为从表结构上看不出那条记录是"真实没有转化"还是"数据还没回传"，需要在特征任务里单独处理。

第四个是渠道算法的大幅调整。某个渠道忽然改版了流量分配规则，历史数据瞬间失去参考价值，这时候模型预测的偏差会明显上升。这类情况只能靠人工标记，在特征里添加一个"算法变更后"的哑变量，同时将该渠道的预测权重调低，尽量用最近3天的新数据重新校准参数。这种人工标记的方式虽然简单，但在渠道迭代频繁的行业里非常管用。

5.4 让看板真正被用起来

最后说一个可能很多人没注意的问题：看板做好了，团队不用，等于白做。我刚上线看板的前两周，日访问量寥寥无几。后来复盘发现，原因是看板堆了太多指标，大家不知道从哪看起，也不知道看完了该做什么动作。

改造的办法是"每个页面只回答一个问题"：总览页回答"今天整体好不好"，渠道页回答"问题在哪个渠道"，计划页回答"要关停或加量哪个计划"，素材页回答"该不该上新素材"。每个页面下面加了一行"建议动作"，比如某个计划ROI低于阈值，页面直接显示"建议暂停"，而不是只给个数字让优化师自己猜。这个改动其实很小，但带来的变化非常明显，大家不再需要自己解读一堆指标了，看板成了真正的决策辅助工具。

改完之后，看板使用率明显上来了，大家每天上午打开的第一件事变成了先看预测值和告警，再决定今天怎么安排。到这一步，这个项目才算真正闭环。我个人做下来最大的体会是，这类项目最难的不是模型或者看板本身，而是把数据口径和链路稳定下来。模型再准、看板再炫，前面任何一环的数据不对，后面全是白费。先把数据链路打通、把口径统一好，再谈预测和可视化，这个顺序千万别搞反。