一款基于AI算法的调查问卷：从产品运营，到技术研发全过程深度剖析

我用最简单粗暴的形式，为大家讲解一个调查问卷项目横跨运营，产品，技术三个部门的背后，到底都经历了什么，从无从下手到顺水行舟，详细讲述一个用户调查问卷产品的生命周期，并且从代码层级展示一套初级的人工智能算法如何挖掘用户数据，那么这套算法对于商城类的线上产品有什么作用呢？简单来说就是，通过算法算出商品之间的关联性，下面我来带你们一步一步分别从运营，产品，技术三个维度去做这个项目。

项目整体步骤

项目背景

广电智能机顶盒覆盖率高达80%以上，覆盖用户千万级，我们的产品是基于广电内网的智能机顶盒的线上超市业务，以新零售作为出发点，用户在家用机顶盒下单，社区附近超市配送，双十二需要提前备货，所以库存货物品类是否精准，会直接影响到此次活动的成败，商家希望能预知某种商品的需求度，提前备货，运营部门需要线上线下配合做好这次活动，那么除了要预先知道不同产品客户的需求量以外，最重要的就是要做到精准推荐，让用户买他本来没想到要买，但是确实需要的东西。

第一步：运营部门任务

线下运营策划案：线下运营主要流程就是，先出线下地推方案，然后市场部门带着方案跟之前有过合作的超市去洽谈地推细节让他们提供场地支持和优惠券支持，敲定具体推广地点和时间，然后再进入社区找到社区物业或者居委会洽谈社区内的地推时间和地点，由于是政府项目，所以居委会积极响应，此次活动开展的还算比较顺利。后期我们就让地推团队带着易拉宝和DM单，同时进入社区和周边超市推广预热去了，由于本文章主要是要讲解线上运营，所以这里我就不对线下运营做详细的描述了，我会有后续文章发上来，一步步的带大家做地推。

线上新媒体运营策划案：至于线上新媒体运营部分在这里简单介绍一下，主要渠道就是当地各大垂直领域自媒体，报纸硬广，当地电视媒体报道等等。

线上产品运营策划案：我们这次主要来说一下线上产品运营，拿到这个项目的需求就只有老板的一句话，要做双12，销量要翻倍，自己去找资源，自己去协调，自己想方案，运营的工作就是这样，一开始都无从下手，不知道先干什么后干什么，那么就需要你自己目标感特别强，在迷茫的时候想一想源点，我到底是为什么要做这个活动，那么想做线上运营第一步就是基础数据分析，那么有人会说，如果是冷启动阶段，没有数据怎么办，当然也有其他渠道可以做数据分析我后面会说，先看下图，这是双十一期间的销售数据。

1、首先分析此次活动的目的

目的一：双12拉新，促活，消费转化。 目的二：商家想预知需要提高备货量的商品。 目的三：通过调查问卷做数据埋点，记录用户维度，建立用户画像，用关联算法挖掘用户数据，做精准推荐提高非预期消费比例。

基于这三个目的，所以不光要做同比环比数据对比，还着重看双11期间的数据，上图就是双11期间后台统计的数据，最后从数据中分析出几种购买频次比较高的商品，发现例如米面油这些刚需产品的购买频次最高，酒水饮料其次，所以这些产品就是这次调查问卷的主要涉及维度，基于这些维度在做深度数据挖掘。

2、要有稳定且执行力强的团队 ，团队协调也是运营

有了产品才能让新媒体和地推介入进来，否则你连调查问卷都没有，就去推广预热，你的投入就都白白浪费了。

其实，产品和运营两个部门的主要矛盾就是因为工作内容边界比较模糊，有些产品的工作其实离不开运营提出的建议，甚至一些运营人员都要替产品去写需求文档。所以后期就会出现一种现象，明明是运营人员输出的价值结果，产品经理拿去上老板那边邀功请赏，说这个产品的创意是他自己想出来的，这点就会让运营人员很不舒服，后期直接导致产品缺乏创意，怎么可能达到很好的运营效果？

所以比较靠谱的解决方式就是，统一的团队KPI，运营，产品，技术三个部门KPI相互关联，利益共同体，功过分明，功劳是谁的就是谁的，并且每个部门的主管是项目需求的唯一出入口，项目主管的核心作用就是降低团队内部和团队间的沟通成本，攻克项目中出现的难题。

我相信大家都遇见过那种你有事问他的时候，明明不懂还装出一副不屑于回答的样子，要不就是直接甩给你一个QQ号或者手机号让你自己去沟通的那种废柴领导，无形中给团队内部增加了大量的沟通成本造成项目成本过高，团队离职率上升。有了强力的团队，下面就是该设计产品了。

3、产品设计思路就是做一个H5做的调查问卷

H5做调查问卷最大的好处就是多平台适配，开发周期短，开发成本低，非常适合线上线下多渠道推广活动，有人会说这和一般的调查问卷没有什么区别啊，常见的调查问卷都是这种形式的，无非就是让用户做一些选择题，其实调查问卷的背后是用户画像，这是一个很大的课题，那些常见的调查问卷缺少用户参与感，很简单的一个例子，当你删除电脑软件的时候他都会问你为什么删除，有多少人会真正去按照自己的意愿去选择，都是直接点击右上角关闭按钮，归根结底就是这种调查问卷缺少参与感，运营的根源就是对人性的把控，那些运营l大咖都非常了解用户心理学，那么基于这种用户思维就产生了两个问题需要解决：

问题一：如何解决问卷调查参与感不强的问题

那么我是如何解决以往的调查问卷没有参与感这个问题呢，很简单，用十秒倒计时抢答的方式，让用户产生紧迫感，而且用户不知道后面还有几道题，永远都觉得下一次就是红包了，所以会一直做到结束，但是也不建议太多，大概10 – 15个选项就可以了，保证用户能在1分钟之内选择完就可以。

问题二：如何解决用户身份与奖品绑定步骤，层级过深的问题

所谓用户身份绑定步骤层级太深，就是指往常做问卷调查涉及到奖品的时候，需要把奖品和用户绑定，常用的做法就是在做问卷调查之前或者最后一步，让用户通过短信验证码绑定手机号登录，用户需要操作的流程是  输入手机号码点击发送验证码——>点击短信推送进入短信详情——>背下验证码——>返回问卷调查页面——>输入验证码点击确定，之前做过一次数据分析，每增加一个用户层级，用户流失率就会提高20%，也就是以往的问卷调查方式会流失80%以上的用户。

那我给你算一笔账：你花1W块钱做地推，比如获客成本是2块钱的话，也就能引流来5000个人参与问卷调查，经过上面四步每步流失20%用户，也就是最终要损失掉 5000 * 80% = 4000人 也就是说真实的获客成本从2块钱涨到了10块钱，如果你这次活动引流了1W人的话，你们老板要多花8W块钱，那么10W人呢，100W人呢，现在看出用户层级有多么重要了吧。

那么要解决这个问题，就尽量减少用户层级，能在首层解决的都在首层解决，所以我采用直接由服务器分配用户唯一优惠码并与奖品在后台绑定，用户只需要在最后页面点击保存优惠码图片，付款的时候直接使用就可以了。两个问题的解决方式见下图：

4、运营产品策划案交付审核，下发

至此线上运营产品策划案完毕，把UE和问卷调查需要采集的用户标签汇总，交付产品部门，其实大家可以看出来，运营部门其实已经帮助产品做了一部分的工作了，所以这就是我刚才说的运营和产品的工作内容边界比较模糊的原因。

第二步：产品部门任务

1、需求文档编写

需求文档的原则就是要把运营部门的用户需求，转变成技术能看的懂的功能需求，从控件大小，组件颜色的色号，到每一个功能的细节都要展示出来，甚至一些技术选型和数据交互策略都要体现出来，从而节省技术部沟通成本，由于本项目主要是配合运营时间节点，所以适用敏捷开发方式，我直接把需求文档和UE图整合，效果如下。

2、产品文档交付技术部门，开发说“无法实现”是真的吗？

拿着需求文档去跟技术部开产品会的时候，经常会遇到的问题就是，技术部会找各种借口说无法实现，最后为了保证基本功能，产品妥协，为了保证按时上线，运营妥协，后果就是对着悲惨的PVUV只能由大家一起买单，奖金就别想了。难道是真的无法实现吗？真的是技术部的人懒吗？真的是技术部的人多报工期吗？

技术部人员的性格跟产品运营部门最大的区别在于，一个想一劳永逸，一个不断要出新玩法，不断提升用户体验，对于技术部人员来说，他们觉得最理想的系统就是健壮的，后期产品运营部门提出任何需求，技术部都不需要改代码，直接告诉他们如何在后台配置一下就可以了，对于产品运营人员来说，每次活动都要标新立异，都要不一样，都要有新的数据埋点，所以就产生了以上的矛盾，那么如何解决呢？

1. 首先尽早提出需求，切记不要今天提出需求明天就要，这种行为会让技术部很反感。

2. 一切以运营部的标准为标准，因为运营部门是跟市场关系最紧密的部门，所以提出的建议和需求都是经过市场调查和数据分析的结果，保证运营部门的需求是大前提。

3. 如果现有需求跟原有技术选型和数据架构冲突太大，那就只能深入讨论，抽丝剥茧，在保证运营需求的前提下适当的做一些妥协，有些时候技术解决不了的问题，是可以用优化交互设计解决的，例如列表页的点赞功能，每次点赞都落盘的话服务器压力相当大，如果数据库也不是用redis的话很容易服务器宕机，更换数据库研发成本太高需要重构项目太不现实，所以通过优化交互设计把点赞功能放在更多里面把评论功能放在浅层级，这样平台既可以提升UGC(用户产生的内容)，服务器压力也减小了。

4. 产品运营人员多了解一些技术方面的知识是很有必要的，最起码跟技术部谈判的时候能知道他们是不是在夸大问题，如果真的是技术部人员消极怠工，故意不干活的话，那就只能直接把立项邮件带着需求文档设计稿@老板@各部门主管，自上而下的分配任务。

第三步：技术部门任务

1、拿到需求文档，分配任务

此次问卷调查项目，需要用到的技术岗位有，web前端，测试工程师，java后台工程师，项目经理。这四个岗位的任务，由项目经理按照需求下发到各岗位，按照时间进度排期进行就可以了，开发完毕测试通过上线，至此一次项目迭代完成。

项目经理任务：把控整体项目进度和成本，发现需求问题及时与其他部门沟通，编写接口文档，攻克技术难题。 java后台任务：完善接口文档，根据需求文档和接口文档做后台数据库搭建，接口功能实现，关联算法功能实现。 web前端任务：做调查问卷的页面效果实现与后台接口对接，不同分辨率设备适配。 测试任务：根据需求文档写测试用例，测试整体项目功能，做好适配测试和jmeter压力测试。

2、着重讲一下关联算法，最初级的人工智能，数据挖掘算法

本次线上运营的精髓之一就是利用关联算法增加用户非理性购买概率，达到提升消费转化的效果，那么什么是关联算法呢，举个最简单的例子就是，你去淘宝看了一款包包，然后页面拉到底部会有猜你喜欢，那里面的内容就是根据关联算法算出来然后精准推送给你的，那很多人说了，我知道这种就叫关联算法，但是作为一个运营人员怎么去使用关联算法，作为一个技术人员研发关联算法从哪里入手呢？下面拿出我用java实现的关联算法代码来给大家参考一下。

定义1： 支持度（support）

支持度s是事务数据库D中包含A U B的事务百分比，它是概率P（A U B），即support（A B）=P（A U B），它描述了A和B这两个物品集的并集在所有的事务中出现的概率。

定义2： 置信度（confidence）

可信度为事务数据库D中包含A的事务中同时也包含B的百分比，它是概率P（B|A），即confidence（A B）=P（B|A）。

定义3： 频繁项目集

支持度不小于用户给定的最小支持度阈值（minsup）的项集称为频繁项目集（简称频集），或者大项目集。所有的频繁1-项集记为L1。

定义看的一脸懵逼吧，我给翻译了一下：

支持度：同时买了衣服和裤子的订单数 ÷ 总订单数 （也就是看所有订单里面多少人同时买了衣服裤子，除一下的结果就是衣服和裤子的支持度） 置信度：购买了衣服和裤子的订单数 ÷ 购买了衣服的订单数（也就是所有买了衣服的订单里面，有多少人还买了裤子，除一下得到的结果就是衣服和裤子的置信度） 频繁集：就是事先设定一个最小支持度，比如0.2也就是20%，然后算法会把所有订单一起计算，不断的剪枝，凡是支持度不小于最小支持度的项集都是频繁集

目的就是从频繁集中选择支持度和置信度比较大的项集，去做关联推荐，比如我发现所有订单中买了衣服以后又买了裤子的人站有70%以上的比例，那我就给所有有意向买衣服的用户推送裤子，从而提高消费转化率，于是技术出身的我，用Java实现了这套算法，光说不直观，看代码运行效果吧。

这次活动一共获取到有效用户维度（数据库记录条数）23000组左右，通过算法深度挖掘用户维度，计算出来以下部分频繁集，可以看到最后三组，置信度都是80%以上，完全就可以用来关联推送了，这就是一个最初级的人工智能数据挖掘算法。

以上就是本次项目从运营，产品，技术三个维度的详细剖析，经验尚浅，大家且阅且指教。

 

作者：MT，一个为了做产品，卧薪尝胆，沉淀了8年技术的全栈工程师，兼职众创空间讲师。

本文由 @MT 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 unsplash，基于 CC0 协议