看到这个题目也许你会吓一跳，但这个数据可并不夸张。下面是我们的一个案例，从中你会体会到建模的复杂性和不确定性，从而知道为什么我要否决大多数的建模需求。
一、需求是什么
以下是市场部门的一个营销目标用户的建模需求，具体情况如下：
（1）营销活动：针对Y权益套餐（主流APP的会员及流量优惠）的用户进行营销，迅速占领市场
（2）需求描述：找到订购Y权益套餐的意向用户
（3）用户限制：当前尚未享受它套餐优惠的用户
（4）当前营销情况：已办理用户20w，外呼成功率10%
（5）当前定向规则：基于用户APP使用情况标签（月使用流量、月使用天数）筛选目标客户
二、建模师A的需求理解
大家好，我是建模师A，拿到这个需求后，我跟业务人员做了进一步沟通，了解了Y权益套餐的具体内容，并与其就模型目标达成一致：计划输出目标用户400万，外呼成功率能达到20%。
基于对业务的理解，我开始设计用户的特征变量，具体如下：

我在做了初步设计后，就来找领导B汇报思路，因为团队制定了数据挖掘军规，要求需求和设计必须评审，因此我得按照规矩办事，虽然以前是没有这个习惯的。
三、领导B的需求理解
我是A的直属领导B，一方面希望团队能用建模的方式去为业务创造价值，另一方面则对于建模的成功率不太有信心，自己从业这么多年，手上经过的建模成百上千，但真正经得起市场和时间检验的模型屈指可数。
因此，每当团队要用建模的手段去支撑市场营销的时候，我总是想跟大家做深层次的交流和探讨，论证这个事情做成的可能性。
我很希望建模师能从全流程、端到端的角度去看建模这个事情，比如在做之前要考虑清楚各个环节是否具备条件。
我的经验是，建模做到最后，其实就是在做一个产品，产品经理一般还有点风险意识，但很多建模师没有，拉起来就想做模型训练。
回到这个建模课题，我提出了以下的四大疑问，这些问题不澄清，做这个模型的风险就很高，你能get到吗？
1、业务分析不透彻
在市场部门给的需求中，其实已经包括了相当多的信息，但所谓的业务理解不是简单的理解表面意思，而是要善于做定量分析。
既然已经营销了20万用户，就意味着不是冷启动，可以拿到正样本，做这批用户的基本面分析是必须的，包括用户年龄、性别、流量等等，如果通过分析发现业务规则就可以达到精准定向的目的，其实就不需要专门建模了。
事实上业务人员已经有了“基于用户APP使用情况标签（月使用流量、月使用天数）筛选目标客户”这个业务规则，就需要针对性的去分析还有哪些不满足条件的用户也受理了该权益套餐。
只有这么层层深入，才能看到目标用户群的全貌，给出性价比最高的方案，而不是拿着锤头看啥都是钉子。
有时候我们一通建模还顶不过人家业务人员的几个取数规则好用，就在于你对于用户是不了解的，想着用技术暴力来解决问题，这样往往事倍功半。
建模师不应只会算法，更要有基本的业务分析能力，不要用战术上的勤奋掩盖战略上的懒惰。
2、目标制定不合理
建模师跟业务人员能明确目标是好事，但在制定目标前要有一定的依据，“计划输出目标用户400万，外呼成功率20%” 这种目标也许能符合业务人员的期望，但建模师不要乱拍胸脯。
建模师至少需要明确当前的成功率是多少，如果真的如业务人员所说的是10%，就要去核实外呼清单的数据和效果，如果真属实，你说达到20%才有点依据。
业务人员有时会觉得建模师做出来的模型效果很差，其实他没有参照物，信口开河，或者有些根本不是靠建模能达到的，有时候大数据被吹的神乎其神，但建模师要善于澄清问题。
从规模的角度讲，建模师要对能营销触达的用户量多少有个基本判断，大多数情况下实际能营销触达的用户是有限的，比如“当前尚未享受它套餐优惠的用户”这个限制条件就可能剔除了很多用户，这些数据的测算可能业务人员自己都没做过，建模师不明就里的许下承诺，就注定了失败的结局。
3、资源配备未到位
即使我们定制的目标在数据上显得合理，也并不意味着具备可行性，因为营销是需要政策和渠道资源的，也许跟你提需求的业务人员根本没做好这准备，他跟你提了建模需求，等到你真的做出了模型需要验证和生产的时候，他也许会跟你讲等着排期，这种事情太多了。
要知道营销不是一个人的事情，建模也不是一个人的事情，涉及到周边一系列人员和资源的配合。
因此建模师要敢于向业务人员提出要求，比如在什么时间点给多少政策和流量，如果对方不置可否，要么搁置，要么升级，如果对方长时间没响应，只能说这种模型需求不值得做。
很多时候双方开始的时候是你好我好大家好，但最终由于营销资源问题不了了之，业务人员可以拍拍屁股走人，因为自己没花成本，但建模人员投下去的时间和精力怎么算？
企业内不是市场经济，只能靠加强管理来提升做事的效率，既然建模的机会成本这么高，就不能随意浪费资源。
4、变量准备太低效
在讨论的时候，我发现B准备变量耗用了很多的时间，其实完全没有必要，比如前面的特征变量中，除了上网行为和交往圈中一些视频变量过于特殊外，其他的都可以复用已有的，因为团队已经建设了统一的数据挖掘宽表。
建模师真正要做的，是在这个基础上，结合具体场景开发一些特殊的变量，要尽量把变量准备的时间压缩到最少，传统的70-80%的变量准备时间还是太奢侈了。
我有时反对合作伙伴来从事建模工作，其中的一个原因就是他们重复造轮子的现象更为严重，反正都是干活。
完成这个可行性需求分析后，建模师A倍感压力，因为发现需求分析阶段要做的事情很多，超出了自己的想象，难度也很大。
但如果领导B不去这么死抠，你觉得这个模型会有多大的成功机会？做大数据当然要去干一些冒险的事情，前提是是否做了必要的风险判断。
希望我的分享于你有帮助。