Li Tan · 文章

Default to AI 之后

li.tan83033@gmail.com (Li Tan) — Wed, 06 May 2026 00:00:00 GMT

我现在的团队是 default to AI。多数 ticket 一开始就有模型在 loop 里，而不是一个空白光标。启动一项工作的速度比以往任何时候都快。AI 做了很多 heavy lifting，我每天花在 review 和打磨上的时间比敲键盘的时间还多。

这是大家挂在嘴上的部分。被低估的是后半截：工作的形态变了。敲键盘的时间下降，review 的负担上升，整个工作从「做」转向「查」。如果你没准备好接这个迁移，AI 并不会真的帮你省时间，它只是把时间从一个地方挪到另一个地方。

我看到很多人会陷进两个误区。

误区一：「AI 做 90%，你只要检查结果」

听起来很美：把 context 全部喂给模型，让它端到端把分析做完，扫一眼结果就 ship。

直到有人提问。

你没写过的步骤，你不拥有它的细节。你可以读懂结果，但你 defend 不了它。当 stakeholder 第一次反问 为什么这个 filter、为什么这样定义 cohort、pre-launch 用户怎么办，你站在那里解释一份你根本没做过的工作。如果你想先验证结果对不对，你得自己重做一遍，重做到一定程度，等于你一开始就该自己写。「省下的时间」在 review 阶段蒸发一次，在 readout 上当着大家的面再蒸发一次。

还有更深一层的坑。大部分公司的内部文档本身就一般，湾区科技行业固有的 high turnover 把这个问题放大：当年知道一张表究竟意思的那批人早走了，wiki 里留下的东西半数过时、半数错误。如果你把 AI 怼到这堆资料上，依赖它的总结，得到的不是干净的概要，而是被自信地复述一遍的错误信息。如果你对 business 的理解还不到能识别错误的程度，AI 只是帮你在错误的方向上走得更快、更远。

解法不性感：在 reasoning 这一层留在 loop 里。你不需要敲每一行，但你必须知道每一行为什么在那。

误区二：「AI 全权处理 ETL」

我以前的一天里有大量 SQL：拉数据、validate、整理好、交给下游。这些活儿现在大部分由 AI 起稿，简单数据源上效果很好。

数据 model 一复杂就开始翻车。

当你面对几十张表、重叠的 key、半重复的数据、十种「active user」的合理定义，模型会从这些表里挑某一条路径走。这条路是不是对的，没有任何保证。看起来合理的 join 经常是从错的表上 join 出来的，数字回来一切正常，但其实是错的。

修这个问题不靠更好的 prompt，而要往上游修。你必须先给 AI 一份 join map：哪些 fact 表是某个粒度下的 canonical 选择，哪些 dim 表已经废弃，哪些列看起来像但其实不是默认安全选项。我个人摸索出来最干净的做法是：和 data engineer 一起花一小时，把常用表和它们的典型 use case 写下来，再 pin 几条已经 validate 过的 query 给模型做 pattern-match。做完这一步之后，AI 出的 SQL 质量直接上一个台阶，因为它不再是在猜结构。

订单粒度的 join map 示意左侧两张 fact 表连向右侧的 dim 表。canonical 的 join 用实线表示，已废弃的 dim 表带删除线和虚线，并标注 AI 容易选错的路径。其中一条 canonical join 上有"已验证"的徽标，代表可以喂给模型作为模式参考的 query。JOIN MAP · 订单粒度FACT × DIMFACT 表DIM 表fct_orderscanonicalfct_paymentscanonicaldim_userscanonicaldim_users_v1已废弃dim_listingscanonicalJOIN ON user_idAI 容易选这条已验证把仓库变成一份有立场的地图，而不是一道搜索题。

一小块切片。这张图把仓库的"对的路径"喂给模型，而不是让它自己摸。

这一步没有捷径。在你把 ETL 委派给 AI 之前，你得先了解仓库本身。AI 不会取代你对 warehouse 的理解，反而让这种理解更有杠杆。

一个让我省下不少时间的小习惯

当 AI 给我的回答密度太大的时候，比如一篇 paper、一段推导、或者一坨纠缠在一起的统计推理，我会让它再用 simple and plain 的语言重写一遍解释。

不是降智，只是把学术腔扒掉。

我们这行一半的认知负担来自解码语言，不是想清楚思想。语言一旦平实，思路通常就显形了，你几秒钟就能判断这是不是你要的东西。pain point 或 key insight 浮出来更快，学一个新方法的曲线明显变缓。

听起来很简单，但确实管用。

一年下来，工作的形态

AI 没把活从我盘子里拿走，它只是把活重新分配了。我写得更少，review 更多，debug 更小心，更多时间花在搭脚手架（join map、prompt、validated example）上，让 AI 能去做有用的事，而不是自信地犯错。

从 default to AI 里收益最多的，不是把活外包得最干净的人，而是那些虽然把活交出去、但仍然清楚自己交了什么出去的人。

我 pipeline 里藏着的幻觉

li.tan83033@gmail.com (Li Tan) — Fri, 10 Apr 2026 00:00:00 GMT

上个月我让 Claude 给我写一个 dbt model。SQL 看着干净，join 也合理。我直接上线了。

三周后才发现，它悄悄丢了 8% 的行。该用 LEFT JOIN 的地方用了 INNER JOIN。没人抓到。仪表盘看着没事，因为丢掉的那 8% 恰好没怎么影响头部指标。

这就是 AI 在数据工作里的问题。它不知道它不知道什么。而且无论对错，它都说得很有把握。

我每周都会中招的两个地方

ETL。 join 用错 key。过滤看着对，但默默丢掉了边缘 case。type conversion 把时间戳转成日期，时区丢了。window function 的 ORDER BY 写法"对"，但不是你想要的那个意思。代码跑得通，数字出得来，看着没问题。但就是不对。

建模。 特征工程里有 leakage。"交叉验证"写成了偷看未来的版本。回归把带空值的行默默扔掉也不告诉你。指标算在和标签不一样的粒度上。模型训好了，AUC 看着很漂亮，一上线就翻车，等你在生产里发现。

共同点：看着对不等于对。AI 把"看着对"练得非常强。一个写得很顺的错误答案，比一个写得别扭的错误答案更危险，因为你会跳过 review。

review 现在就是你整个工作

我跟团队里年轻的同事反复说同一句话：

AI 的上限取决于你 review 它的能力。

一个资深的人用 AI，产出快 10 倍。一个新人用 AI，bug 也多 10 倍。工具是一样的，结果是反的。差别不在 prompt，在眼力。

我 review AI 输出的时候，做的跟 review 一个没信用的实习生一样：

每一行都读，不是扫。用自己的话讲一遍它干了什么。
拿一个已知答案的 case 跑一遍，对得上吗？
join 前后数一下 row count。bug 经常就藏在这儿。
找静默失败。 丢 key、丢 null、隐式转换。这些从来不报错，只吃你的数据。
问一句"它假设了什么"。AI 会做假设，但不会告诉你，你得挖出来。

这很费时间。这就是这份工作。

新的技能

大家在讲 prompt engineering 是要学的新技能。不是。要学的是更快地识别错误。一页生成的代码，你多快能看出里面的谎言？一个看着合理的数字，你多快能感觉到它不对劲？

这个技能其实不新。就是老技能：会读代码、懂自己的数据、有品味。AI 只是把筹码变大了。你现在一天产出更多代码，意味着一天错的机会也更多。

我每天还在用 AI，回不去了。但我不再把它的输出当作"答案"。我把它当作一个很快、很会讲、有时候完全不对的实习生的初稿。我的工作是那支红笔。

如果你没有在用这支红笔，AI 不是在帮你，它只是在帮你更快、更自信地犯错。

A/B 之外：没法做实验，如何衡量真实的产品影响

li.tan83033@gmail.com (Li Tan) — Sat, 26 Jul 2025 00:00:00 GMT

理想世界里，每次产品变更都该跑一次随机对照实验。现实更乱。有时候你不能随机：功能已经全量上线，法律约束不让留 holdout，或者样本太小没有统计功效。

碰到这些场景，我用准实验方法。下面是我的 playbook。

观测数据的问题

根本难题是混杂（confounding）。采用新功能的用户和不采用的本就不同。可能更活跃、更懂技术、或者是在某次营销活动里涌入的。简单对比"用 vs. 不用"，对于功能真实影响而言什么都说明不了。

我见过团队反复犯这个错：欢呼一个"功能成功"，其实只是选择偏差。

方法一：双重差分（DiD）

当一个功能在不同时间铺到不同群体（比如按地区或平台），DiD 能很好用。关键假设是平行趋势：处理组和对照组在无干预的情况下会一起动。

永远去画那些 pre-trend。如果不平行，DiD 会给你误导性结论。正如上面的滑块所示，即使小幅违反也会让朴素对比产生有意义的偏差。

# 简化的 DiD 估计
import statsmodels.formula.api as smf

model = smf.ols("outcome ~ treated * post + C(group) + C(time)", data=df)
results = model.fit()
# treated:post 的系数即为处理效应

方法二：合成控制

当你只有一个处理单位，但有很多潜在的对照，合成控制用对照的加权组合造一个"合成"的处理对象。我在地理实验里大量用这个，它比简单对比更能处理真实市场的脏乱。

方法三：断点回归（RD）

如果处理是按某个阈值分配的（例如 engagement score 高于 X 的用户才拿到功能），RD 利用阈值处的不连续。阈值上下的用户几乎相同，形成局部随机化。

这个方法我觉得被低估了。很多产品功能都有天然的阈值，却没人想到去挖。

什么时候用哪个

方法	最适合	关键假设
DiD	分时段上线	平行趋势
合成控制	单一处理单位	干预前拟合
RD	阈值分配	阈值处连续性

你的场景适合哪个？

回答下面几个问题，我给你指一个方向。

结语

没有哪个方法完美。最好的做法是组合多种方法，看它们是否讲出一致的故事。当它们背离，往往就是最有意思的学习点。通常说明你对底层动态的理解缺了一块。

关于 DMA 测试的一些想法

li.tan83033@gmail.com (Li Tan) — Wed, 21 May 2025 00:00:00 GMT

DMA（Designated Market Area，指定市场区域）测试是衡量营销增量最有力的工具之一。但也特别容易做错。这里是我自己一路踩坑换来的几点。

为什么 DMA 测试重要

不像用户级归因，DMA 测试可以捕捉到：

需要几周才显现的品牌效应
跨设备转化
口碑与社交溢出
从认知到购买的完整漏斗

正因如此，我反复回到这个工具，尽管它复杂。

常见陷阱

1. DMA 数量不够

地理实验的统计功效来自地理单元数，不是总用户数。只有 20 个 DMA，你需要极大的效应才能显著。

经验法则：至少 50 个，理想 100+。这会限制你能测的渠道，但弱功效实验比不做还糟。

2. 市场间的溢出

消费者会出差旅行，数字广告跨边界。如果你的"对照"市场被处理组污染，估计就会偏向零。

缓解：设缓冲带、排除边境区域、或显式建模溢出。这件事我已经学会偏执。

3. 忽视季节性

营销效应随季节变化。11 月跑的测试几乎告诉不了你 2 月会怎样。

最佳实践：跑足够长以覆盖至少一个完整周期，或用能容纳季节性的时间序列方法。

更好的打法：合成控制

相比简单的处理 vs. 对照比较，合成控制法用加权组合来构造一个"合成"的控制市场，使其在干预前最贴合处理市场。

它能处理：

市场间异质性
地区各异的趋势
噪声大的结果数据

我在地理测试里用合成控制的效果比朴素 DiD 好得多。

关键收获

市场数 > 每市场的用户数
从一开始就为溢出做设计
预注册能防止 p-hacking
合成控制常常胜过简单 DiD
上线前务必做功效分析

跳过功效分析，等于提前预定一个"不显著"的结论。

从 Insight 到行动

li.tan83033@gmail.com (Li Tan) — Wed, 21 May 2025 00:00:00 GMT

分析最难的部分从来不是找到 insight，而是让人基于它行动。

Insight-Action Gap

每个分析师都经历过：你花了几周做一个严谨的分析，呈现出令人信服的发现，得到一圈点头……然后什么都没变。Insight 死在了 PPT 里。

这种事我见得比我愿意承认的多，包括我自己的工作。为什么会这样？

1. 没有 context 的 insight

数据不会自己说话。"留存下降 5%" 没有 context 毫无意义：

这是正常的季节性波动吗？
相比竞对如何？
折算成美元业务影响多少？

修：始终用利益相关方在意的口径来 frame，通常是收入、成本、或战略目标。

2. 没有明确的 owner

"有人该研究一下这个问题" 是 insight 的坟墓。没有特定人为某个发现负责，这件事就不会发生。

修：每份分析结尾都给明确的建议和指派人。就算尴尬也要这么做，我已经在硬着头皮做了。

3. Insight 太多

一次呈现 20 条发现会稀释注意力。高管带宽有限，他们没法对每件事都采取行动。

修：狠心排序。开篇只放最重要的 1–3 条，其余塞 appendix。

ARIA 框架

我用一个简单框架判断 insight 是否能驱动行动：

Actionable：真的有人能对它做点什么吗？
Relevant：与当前业务重点有关吗？
Impactful：潜在价值够大吗？
Assigned：有明确的 owner 和时间线吗？

任何一项不过关，就还不到呈现的时机。

用时间建立影响力

推动行动不是单次分析的事，而是积累信用：

从小处开始：在啃大问题前，用快赢证明价值
回访：跟踪建议是否被采纳、结果如何
诚实对待不确定性：承认边界反而换来信任
懂业务：最好的分析师理解的不只是数据，还有运营

目标不是"做对"，而是让业务变得更好。有时候这意味着接受：一份被真正使用的"够好"的分析，比一份完美但吃灰的分析更有价值。

AI 准备好取代营销数据分析师了吗？

li.tan83033@gmail.com (Li Tan) — Tue, 20 May 2025 00:00:00 GMT

每周都有新的标题在讲 AI 即将取代分析师。作为一个天天用 AI 工具、并亲眼看着自己产出翻倍的人，我给一个更诚实的判断。

AI 今天真正擅长的

1. 数据总结

AI 非常擅长把大数据变成一段可读的概要。丢一份导出的数据给它，它能比人工翻看更快识别趋势、异常和模式。这在初步探索阶段尤其好用。

2. 写代码

SQL 查询、Python 脚本、可视化代码，有 AI 协助速度会大幅提升。我自己的常规编码任务生产率提升约 30–40%，有时候更多。

3. 文档工作

解释方法、写报告、做 PPT，只要 prompt 给到位，AI 处理这些相当不错。

AI 仍然吃力的地方

1. 因果推断

找相关性？AI 可以一天到晚找。但搞清楚指标为什么动了、不同情景下会怎样？这仍然需要人类的判断。我见过 AI 自信地给出完全误判原因的解释。

2. 业务 context

AI 不知道你们 CEO 上周刚宣布了战略转向，也不知道 marketing 和 sales 现在关系紧张。context 重要到离谱，而这是没法靠 prompt 绕过的。

3. 新颖问题

碰到真正新颖、训练数据里没充分覆盖的分析问题，AI 的建议就开始不可靠。这时候经验就是经验。

4. 利益相关方管理

说服一个半信半疑的 VP 基于数据改变策略？这是人的活儿，大概率一直会是。

真正的未来

AI 不会取代分析师。但用 AI 的分析师会取代不用的。

最佳组合：

AI 负责：速度、规模、常规任务、第一稿
人负责：判断、战略、关系、新颖问题

职称可能不变，但实际工作在往更高杠杆的方向迁移：问更好的问题、设计更好的分析、推动组织变化。

我的建议

深度学 AI 工具：不只是 prompt，而是理解能力边界
在判断力上加倍下注：那些靠经验和直觉的部分
经营关系：你的价值会越来越多来自影响力，而非单纯的分析
保持好奇：生态在快速演化

真正活得好的分析师，会把 AI 视作强有力的协作者，而非威胁。我把自己的职业赌在了这个判断上。

异常检测：一个实用速览

li.tan83033@gmail.com (Li Tan) — Mon, 19 May 2025 00:00:00 GMT

异常检测听起来很高大上，但我的经验是：现实里 80% 的场景用异常简单的方法就能解决。

问题定义

你有一个指标（收入、注册、报错数，随便哪种），想知道什么时候出了异常。不是"数字涨了"，而是"数字比预期涨得多"。

方法一：简单 Z-score

把今天的值与历史均值、标准差对比：

z_score = (current_value - historical_mean) / historical_std
is_anomaly = abs(z_score) > 3

适用：稳定、没有强季节性的指标。

局限：处理不了趋势和周内模式。

方法二：滚动统计

用滚动窗口让基线自适应：

rolling_mean = df["metric"].rolling(window=28).mean()
rolling_std = df["metric"].rolling(window=28).std()
z_score = (df["metric"] - rolling_mean) / rolling_std

适用：有缓慢趋势的指标。

局限：仍处理不好季节性。

方法三：季节性分解

把时间序列拆成趋势、季节、残差，对残差做检测：

from statsmodels.tsa.seasonal import seasonal_decompose

result = seasonal_decompose(df["metric"], period=7)
residuals = result.resid
# 对残差做 z-score

适用：周/月级别有明显周期的指标。

方法四：Prophet

Facebook Prophet 自带不确定区间：

from prophet import Prophet

model = Prophet(interval_width=0.99)
model.fit(df)
forecast = model.predict(df)
# 落在 yhat_upper/yhat_lower 之外的点视为异常

适用：复杂季节性、节假日效应。

实用建议

从简单开始：Z-score 能解决的问题比你想的多。我通常就从这里起步。
调阈值：3σ 是起点不是铁律。根据你能容忍的误报率调整。
处理缺失值：检测器最烦数据有洞，填补要讲究。
警报疲劳是真的：宁可漏报一些，也别天天喊狼来了。这是血泪经验。
先调查再报警：很多"异常"其实有平平无奇的原因。

元问题

异常检测最难的从来不是算法，而是定义什么样的异常值得采取行动。从"看到这条告警我们会做什么？"倒推阈值。如果答案是"什么也不做"，那也许这条告警根本不必存在。

MTA 与 LTA 之间

li.tan83033@gmail.com (Li Tan) — Mon, 19 May 2025 00:00:00 GMT

归因之争永不停歇。我分享一下自己的思路。

核心问题

一个用户看到 Facebook 广告、点了 Google 广告、读了一篇博客，然后下单。功劳归谁？

末次触达（LTA）：Google 拿 100%
首次触达（FTA）：Facebook 拿 100%
多触点归因（MTA）：按某种权重分配

没有一个答案是"正确"的，它们都是不同假设下的模型。

LTA 为什么活到现在

LTA 常被批评太简单，但它有真实优势：

简单：好解释、好实现
可执行：给出明确的优化信号
保守：倾向于偏底部漏斗、高意向的渠道

对很多业务，尤其是考虑周期短的业务，LTA 就够用了。我见过不少团队把事情复杂化，本来 LTA 完全够。

什么时候 MTA 有用

MTA 在这些场景发光：

考虑周期长：B2B、大件消费
上漏斗投入重：品牌 campaign、内容营销
复杂的用户旅程：多设备、多渠道、多触点

MTA 试图按每个触点对转化的"贡献"分配信用。

MTA 的根本问题

说个脏话：MTA 不测增量。

MTA 回答的是："哪些触点出现在已转化用户的旅程里？"

MTA 不回答："如果没有这些触点，会发生什么？"

本来就会转化的用户仍然会有触点出现，MTA 照样给它们记功。这就是为什么我始终要用真实实验来校准 MTA。

更好的框架

与其争论归因模型，不如先问：

你想做什么决策？
- 跨渠道重分配预算？你需要增量性测试
- 单渠道内部优化？平台归因可能就够
- 理解用户旅程？做 user path analysis
你需要多准？
- 方向对就行？LTA 通常足够
- 精确校准？需要实验
你能真正测什么？
- 可行时设计 holdout 实验
- 对不能单独随机化的渠道，用地理测试

我的现状观点

归因模型适合日常监控和方向性优化；做预算分配决策时，必须用实验证据来校准。

最好的测量体系是组合：

归因用于日常监控
增量性测试用于校准
MMM 用于整体预算分配

没有哪个单一方法给你真相。但多方法三角化会更靠近。

自己试一下

在下面拼一条用户旅程，看五个归因模型对同一笔转化给出的截然不同的分账。同一份数据、完全不同的故事。这恰恰是为什么不先定义决策、光争模型是浪费时间。

与代理商共建 MMM：入门提示

li.tan83033@gmail.com (Li Tan) — Sun, 18 May 2025 00:00:00 GMT

和外部代理商合作做营销组合模型（MMM）是常见路径。但这段关系需要小心经营，才能让模型真正为你所用。这件事我在甲乙双方都站过，下面是我学到的。

为什么和代理商合作

代理商能带来：

专业能力和工具
跨客户的外部基准
当你自己团队吃紧时的带宽
对争议性结论的"政治缓冲"

需要警惕的信号

1. 黑盒方法

如果代理商说不清他们的模型设定、系数估计、验证方式，转身离开。你必须理解是什么驱动了结果。

我曾接手过一个内部没人懂的代理商模型。当结果和现实脱钩时，我们连诊断的切入点都找不到。

2. 不真实的精度

MMM 估计本就带有较宽的置信区间。任何代理商告诉你"电视广告带来了精确的 4.2M 美元增量收入"却不给不确定区间的，都是在过度销售。保持怀疑。

3. 为"让客户开心"优化

有些代理商会调模型直到结果符合 CMO 的期待。要求预注册模型设定。他们如果抗拒，这本身就是信号。

要向代理商要求的东西

完整的模型文档：函数形式、先验、变量变换
留出集验证：样本外预测准确度
敏感性分析：在合理参数范围内扫描
原始输出文件，不止于精修过的 PPT
代码审阅权限（如可能）

打造高产的合作关系

最好的代理商合作像伙伴。分享业务 context，解释为什么某些结果会让你意外，当事情不合理时就直接 pushback。

你的工作不是"接收交付物"。你的工作是把模型理解得足够深，能为它的含义辩护或反驳。

我合作过的最好的代理商，恰恰是那些欢迎我质疑、而不是抱团自卫的那些。

给 VP 及以上汇报的经验谈

li.tan83033@gmail.com (Li Tan) — Sun, 18 May 2025 00:00:00 GMT

职业早期，我在向高管汇报时几乎把能踩的坑都踩了一遍。硬着头皮换来的几件事：

错 1：从方法论开始

我早期的 PPT 上来就是"数据源 / 模型设定 / 验证方式"的长篇。

高管（至少一开始）不关心这些。他们想知道：我们该做什么，为什么？

修：以建议开场，方法论放 appendix 或答疑。

错 2：精度过剩

"收入预计上升 3.7%，95% 置信区间 [2.1%, 5.3%]。"

高管听到的是："大概 2% 到 5% 之间吧。"

修：大胆四舍五入。不确定时用区间。聚焦决策，而非小数点。

错 3：回答问题过于字面

VP: "Q3 下降是什么原因？"

我（以前）：花 20 分钟逐一展开每个贡献因素

我（现在）："主要三个：季节性、10 月修掉的一个产品问题、竞争加剧。产品问题占影响的 60%。"

修：先给头条。他们想深入再深入。

错 4：不懂业务 context

我曾经呈现过一个"技术上完美"的分析，结论推荐的恰恰是 CEO 两个月前在公开场合否决过的方向。那场会议很尴尬。

修：任何高管汇报前，先跟他们团队聊一聊。了解他们在关注什么、担心什么、已经决定过什么。

真正有效的做法

金字塔原则

把你的信息结构化为：

情境（Situation）：一句话交代 context
矛盾（Complication）：问题或诉求
结论（Resolution）：你的建议
支持（Support）：2–3 个关键支撑点

其他都是后援素材。

预判问题

高管一定会问：

"业务影响多大？"
"你有多确定？"
"最坏情况是什么？"
"下一步做什么？"

把这些的利落答案准备好。如果答不上来，你还没准备好。

让决策变简单

别给五个选项让他们挑。给一个带清晰理由的建议。他们不同意会自己 push back。

尊重时间

给你 30 分钟，就准备 15 分钟呈现 + 15 分钟讨论。高管往往想参与，不只是听。

元教训

技术能力只是准入门槛。越到高层，你的价值越来自：

问对问题
清晰表达
用时间积累信任

我认识的最好的分析师，花在沟通上的时间和花在分析上一样多。早点有人告诉我就好了。

营销是艺术还是科学？

li.tan83033@gmail.com (Li Tan) — Thu, 15 May 2025 00:00:00 GMT

"营销是艺术还是科学？" 这是我在会议上被问得最多的问题之一。

我的答案：两者都是，比例取决于你在衡量什么。

艺术的一面

营销里确实有一些地方是真正创造性的：

品牌搭建：情感共鸣 A/B 测试不出来
讲故事：好叙事源自人的洞察，不是算法
文化时刻：时机与品味需要直觉
创意执行：决定一个作品是"够用"还是"传世"

我共事过的最好的营销人都有无法被数据复制的创作直觉。

科学的一面

另一些东西高度可测：

媒介采购：出价优化、定向、频次控制
转化率优化：测、量、迭代
渠道分配：跨触点 ROI 对比
定价：弹性可以实验测量

在这些地方，严谨胜过直觉，数据说话，有纪律的测试胜出。

难就难在中间

大部分营销工作都在这个混沌地带：

一个绝妙的创意 + 聪明的媒介投放
情感化的品牌信息 + 为转化优化的落地页
凭直觉选的 campaign 时机 + 严谨的事后分析

最好的营销组织不在艺术与科学之间二选一，而是把两者整合。

对测量的启示

这一点很重要：你不能用测量科学的方式测量艺术。

如果你硬要用跟效果营销一样的严谨去证明品牌建设的 ROI，会得到：

品牌投入不足（因为"不好测"）
过度优化短期指标
创意商品化（因为"数据驱动"压过了"灵感"）

正确做法：

能严谨测的，就严谨测
不能严谨测的，用代理指标和判断
别让"可测性"主导战略。我觉得这是很多数据团队翻车的地方

我的工作框架

营销活动	艺术/科学比例	测量方法
品牌 campaign	70/30 艺术	品牌追踪、长期 lift
内容营销	60/40 艺术	互动、辅助转化
效果营销	30/70 科学	直接归因、ROAS
定价 / 优惠	20/80 科学	A/B 实验、弹性

结语

艺术 vs. 科学是伪二分。好营销两个都要。

分析师的工作不是用数据消灭艺术，而是帮组织做更好的决策：把"我们知道什么、不知道什么、在赌什么"讲清楚。

有时候这意味着跑严谨的实验，有时候意味着信任有才华的营销人的创作直觉。

智慧在于知道何时用哪个。