智能采集组合文章( 如何采集数据，形成服务再到供给运营，看效果)

　　智能采集组合文章(

如何采集数据，形成服务再到供给运营，看效果)

　　

　　“用户画像”、“用户标签”、“大数据”这些词是我们这几年经常听到的词，但这些词很难直接产生价值。我们都知道大数据有用，人像也有用，但到底怎么用？怎么可能体现为产品，却很少有人能解释清楚。

　　如何采集数据，形成服务，然后提供操作，这也是本文章想要分享的核心。

　　在市场上，申策和易观将其称为智能用户运营平台。本期文章将和朋友一起讲解用户运营平台的产品设计，帮助大家了解其底层支持和产品性能。

　　产品设计讲解将分为3个部分，分别是：选择用户、做操作、看效果。

　　一、产品搭建背景

　　

　　产品建设背景如下：

　　1. 数据不可用

　　数据不可用的原因有很多，更容易理解是数据库没有埋点。

　　其次，数据分散，分散在不同业务中的用户数据没有关联，会导致用户三维画像不足，甚至无法识别是否是同一用户。

　　假设我们无法在关闭前识别出用户的关键路径，将很难分析他们的决策偏好和流失过程，操作的深度也会受到限制。

　　然而，许多数据使用方法只停留在浅层的报表应用中。数据分析很重要，但分析后也应该应用到操作中。

　　2. 操作无法管理

　　这是指大多数企业运营管理严重依赖人力，缺乏平台沉淀的运营逻辑。人事变动时，依赖人力和代码维护的旧逻辑很容易被忽视，运营策略的跟踪和改进可能会丢失。

　　如何让不同的角色快速了解自己业务的运营策略和对用户的影响，也是建设的目标之一。

　　3. 运营成本高

　　运营成本高，因为对交付和干预的需求很高，但每一个需求都需要经过产品、研发、测试和发布的过程。即使上线效率高，上线周期也会滞后。

　　低重用率是由于难以扩大依赖研发的运营策略。

　　4. 效果跟踪很困难

　　结果难以追踪的主要原因是难以形成统一的业务标准，不同的评价标准无法进行比较。我们之前听说过一个故事，每个部门都有正的投资回报率，但公司却在亏损。这是一个笑话，但这是真的。

　　有不同的标准，只看正面指标不看负面指标，那当然大家都是好消息。每个业务的形式都不一样，很难制定标准。你能尝试找到类似的项目进行操作吗？

　　这四点是用户运营平台想要解决的问题。接下来，我们将解读产品的核心结构。

　　二、产品架构解读

　　用户运营平台的产品分解为：选择用户、做操作、看效果。

　　分解为产品术语是：圈定目标用户并设置操作规则，根据操作渠道发送指定操作内容，跟踪效果后进行自助优化调整。

　　

　　上图解释如下：

　　用户圈选：在访问产品页面时选择一个没有交易且有工作的人。操作规则：今晚8点对用户进行风控评判。例如，通过A/B实验，一组由推荐算法确定推荐产品，另一组由操作设置，设置渠道和产品。操作频道：选择弹出的资源频道。操作内容：设置弹窗登陆页面跳转到商家详情页面。效果评估：跟踪上线后的漏斗数据和交易数据。

　　

　　选择用户对应的用户数据平台，操作对应的规则引擎和用户交互平台，看效果就是分析中心。

　　在对所提供的运营服务有一个大致的了解后，我们会逐渐了解这个核心服务所对应的底层支持和产品性能。

　　三、用户操作平台：选择用户

　　上一篇对应的选择用户的痛点是数据不可用。我们必须使数据可用，解决数据分散的问题。我们会将分散在不同业务中的用户数据关联起来，以识别是否是同一用户。

　　最后实现了目标用户的可视化选择。

　　1. 底层支持：用户数据平台

　　

　　要让数据可用，需要建设的是用户数据平台，这是一切的开始。即便不用于实际干预用户的操作，也离不开画像分析和个性化推荐。

　　从用户运营平台的角度来看，我们需要采集整个站点的数据，使数据多样化和客观，然后过滤掉无效和异常值，关联起来成为同一个用户以确保更立体的肖像。

　　最后，将详细数据处理成可用的圆选择条件并提供给操作。

　　在了解表现层之前，首先要了解它的底层支持，并知道为什么会这样。

　　1）数据采集

　　使用数据的前提是要有数据，而采集数据是第一环节。手动采集是上传数据并导入数据库，而自动采集是埋点上报和第三方数据传输相关的工作。

　　2）数据处理

　　第二个环节是数据处理，主要包括数据入库后的清洗、合并、去重、处理四个步骤。

　　

　　清洗是指发现和纠正数据中可识别的错误，包括检查数据一致性、处理无效和缺失值等。

　　

　　关于合并和去重的概念，对数据的理解可以参考这篇文章：《Tableau Basics How to Merge Your Data？理解与逻辑（上篇）》，Tableau已经描述的很全面了。

　　合并有两个目标。一方面是关联不同业务的核心数据，让用户画像更加立体。另一方面，离线查询大批量时，查询速度可以更快。

　　不同的数据存储在不同的表中。我们希望在查询订单的同时查询到用户的关注数据。常用的方法是查询表。

　　但是，这种方法只适用于少量数据。当数据量达到百万时，开始连接表和查询会很慢。这时候会用到宽表，可以理解为一个收录大量数据字段的表。. 例如，在订单表中增加用户的公众号关注数据。

　　处理逻辑涉及条件的组合。

　　我们的原子数据，比如年龄、性别，是可以直接使用的查询条件，但是如果我们想要“中年男性”这个条件，就涉及到处理，这让我们在查询数据的时候更加敏捷。

　　3）数据管理

　　数据采集，处理后的下一步就是数据管理，这是数据服务的基础，负责定义数据标准，管理数据权限，保证数据质量。

　　

　　标准是指我们如何定义一个完整的数据，它需要名称、取值类型、取值范围、处理逻辑等。权限决定了谁控制数据，安全级别决定了不同角色的操作，包括读、写和采用。

　　最后的质量部分是通过相应的监控措施来保证数据质量，数据是否及时更新，更新进度和速度是否符合预期，生成的数据是否符合规范，幅度波动是否达到警戒线。

　　假设一切正常，下游是否正常消费，消费过程是否阻塞。

　　4）数据服务

　　数据服务，这个词泛指数据采集、处理、管理都是服务。这里特指提供实际运营的服务，如众包服务、风控服务、运营服务等。

　　

　　①风控服务

　　借助数据，可以针对不同场景制定不同的风控评分规则，用于黑品识别、金融产品预售评估、金融产品定价等。异常监控是指当号码或账户被冻结时，可能导致用户违约，并在金融产品层面进行预警。

　　② 运营服务

　　智能推荐的本质也依赖于数据平台，通过用户特征输出推荐结果。RTA用于广告，根据特征决定是否参与定价。

　　③ 人群服务

　　用户运营平台的“用户选择”环节将使用众包服务，数据管理可以为前端渲染提供可选择的用户条件。

　　选择好条件后，涉及到数据的去重、不同组间的计算，以及最终应用环节的加解密。这部分将在下面详细描述。

　　说完底层支持，接下来就是用户运营平台表现层的“用户圈选”。数据平台如何提供“用户圈选”能力？

　　2. 产品表现：用户圈子

　　选择用户时必须考虑的产品功能有：圈选方式、圈选频次、圈选条件和人群服务。本质上，这四个功能的底层支持来自于用户数据平台，用户运营平台负责服务的应用和性能。

　　

　　1）圈选方法

　　

　　① 条件选择

　　

　　这是一种在可视化、自助选择用户情况后，通过比较其取值范围，计算生*敏*感*词*群数据包的一种形式。

　　一般来说，可视化抽象条件下的数据使用频率更高，数据准确性更高。其底层原理是将条件和计算标准化，然后拼接出类似SQL的数据查询语句。

　　② 智能选择&独立上传&SQL提取

　　

　　智能选择、独立上传、SQL选择是对“条件选择”的补充。

　　智能选型的主流分为两类。第一类是在用户规模不能满足要求时计算用户的相似度，从而扩大用户规模。

　　另一个应用场景是利用算法模型选择用户，根据运营效果数据优化模型，不断寻找最优的高响应人群。

　　SQL 选择的原理与条件选择类似。主要用于数据不规范，无法直观选择的场景。

　　另一种场景是追求更快的查询速度，因为标准化的查询语句追求通用性，查询速度大多比自写语句慢。

　　2）圈选频率

　　

　　① 单次提取

　　单次抽取是指一次性抽取数据，当前时间抽取后数据不会发生变化。

　　使用的场景多为操作实验，操作实验效果不够好，暂时没有标准操作方案；另一种场景是用户操作规模大，数据量过大。long，提前提取数据。

　　② 动态提取

　　动态抽取是指在不同时间抽取相同条件。在这种情况下，基于数据的及时性，其数据可能会发生变化。在常规和固定的运营计划中很常见，例如：用户将在交易后​​ 10 天获得积分。

　　自上传没有动态提取，是一次性操作。

　　3）圈选标准

　　下面的交互只是条件选择，而SQL、上传、智能交互都是不同的表达方式。

　　

　　条件的来源主要有四种，除了界面上报，应该都是来自用户数据平台管理的数据，然后根据其数据标准渲染到前端页面。

　　这里补充说明一下“用户特征”和“宽表字段”的区别，如下图：=

　　

　　非实时查询条件主要分为宽表字段和用户特征。

　　为了快速查询更多的用户数据，会根据userId将用户数据整合到一张数据表中。因为存储了大量不同的业务字段，所以也称为宽表，比如添加用户年龄、性别等字段。

　　宽表字段是详细数据，数据量大意味着查询速度会受到限制，但也可以快速提取其相关数据；当您需要快速执行点查询并且不需要用户相关数据时，将使用用户特征。.

　　例如，如果您需要向前一天关注公众号的用户发送短信，则会使用具有详细数据属性的宽表字段来获取他们的手机号码。但是，如果是在活动页面上，则需要实时判断用户是否在关注，引导用户的注意力，才会用到用户特征。

　　既然了解了条件的来源，下一节将介绍如何比较条件，这与数据的值类型有关。前端页面还应该根据值类型呈现比较条件。

　　

　　时间条件一般不列举，因为随着时间的流逝很难统计。

　　对应的条件选择交互式日历选择器或者日历范围选择器，而动态时间一般采用T+N的形式，其中T指的是时间（通常是天），N也可以是负数。

　　例如：关注时间=T-1，表示1天前关注的用户。

　　数字和字符串的比较方法比较接近，只是数字和时间可以有“大于”和“小于”等比较方法，而字符串没有。

　　4）人群服务

　　上一部分描述了如何选择用户，这部分是选择后要做什么。其执行过程如下：

　　

　　通过条件查询得到人群包，然后对不同的人群包进行互相关的数学计算。计算后对数据进行去重，最后查询这些用户的数据，供内容语言和界面使用。

　　这些服务详细描述如下：

　　① 交叉交叉

　　

　　② 去重

　　

　　重复数据删除很容易理解。核心原因是防止数据重复，避免在查询数据时因数据重复而浪费资源。

　　③ 关联数据查询

　　在此，分别在内容语言和界面使用方面提供两个示例。

　　内容讲，我们推送了一批等待续保的客户，指导售后部门续费。但是，如果他们需要能够指导他们的策略，他们还需要在售后提供有关保险单的详细信息，例如：保险金额、保费和被*敏*感*词*。关系等

　　接口的使用与调用接口所需的输入参数有关。比如风控界面一般需要用户的*敏*感*词*和手机号。

　　四、用户操作平台：做操作

　　产品和运营的工作主要是计划和执行，痛点由此产生。

　　规划的痛点是过去的逻辑难以追溯，难以系统地理解过去的运营思路，过去谁做了什么效果如何，目前是否在运行？我们新的解决方案总是从零开始，我们需要重新踩过过去的坑。

　　实施的痛点是运营方案链太多无法上线。不同的任务以不同的方式完成，有些需要配置，有些需要开发。不仅界面人不同，而且上线周期慢且分散，非常依赖。项目管理能力。

　　有没有办法尽可能配置多变的操作规则，让操作可以在线管理？

　　这里的解决方案是规则引擎负责操作规则的组合，交互平台提供组合的内容，然后提供不同操作角度的管理视图和自助配置工具。如果这两个能做到极致，那就是*敏*感*词*了。

　　1. 底层支持：规则引擎和用户交互

　　1）规则引擎

　　规则引擎行业也被称为自动化营销平台。术语规则引擎有点抽象。它可以理解为操作一件事的规则或逻辑。

　　

　　这是 5W2H 法则中熟悉的部分，规则引擎在什么时间对谁、在哪里以及以何种方式（5 个赌注）进行操作。

　　什么时候做，给谁做是触发条件，由谁做是由实时事件触发的，比如用户签到立马开奖。在这种情况下，事件既是触发条件，也是判断条件的一部分。

　　判断条件的本质是过滤。比如过滤昨天登录的用户中的黑产用户，除了用户自身的特点外，我们还会接入风控、推荐等接口。

　　从计算机操作的角度来看，流程控制是改变流程执行顺序的指令，浅层理解是判断条件和执行条件之间的连接器。

　　实际操作中，不一定每次判断生效都立即执行，会等待时间或分组执行。例如：当用户访问页面并等待15分钟触发操作逻辑时，等待指令为流程控制。

　　执行条件比较简单，但不要拘泥于思维。

　　用户的一切操作干预手段都可以被我们覆盖，无论是触摸还是弹窗，无论是非人工、人工还是智能，B端最重要的是连接和共赢。

　　

　　了解了规则引擎的四个核心要素之后，接下来的问题就是如何让研发、产品、运营的不同角色被使用成为可能。适用角色的每一步，易用性都会变得更高。

　　如果连研发的敏捷度都提高不了，那么这个引擎就没有存在的意义。

　　关于敏捷，我理解的是操作需求的低代码或无代码实现，以及无需发布即可独立测试的能力，所以对应的解决方案是可视化拖拽。很棒的案例。

　　但相比*敏*感*词*，我个人更喜欢低码。无代码基本上是通用模型和标准化模板。无需研发和人工投入即可快速应用。

　　它可以指标准化服务的提供者，例如网页和活动。这种方法的缺点是它强烈依赖模板。如果没有合适的模板，它的实用性就会大打折扣，很难兼容复杂的逻辑，最简单最不灵活。

　　低代码，通过一些基础设施的搭建，实现一些逻辑配置和一些编码，实现一些逻辑配置，测试可以自助。适合对产品、运营等有一定R&D理解能力的同学。

　　2）用户交互

　　交互，顾名思义，就是沟通和互动。规则引擎负责规则组合，交互内容负责规则的最后一个节点：执行。

　　如果我们要做用户操作，就需要和用户进行连接，这取决于能接触到用户的渠道，不同的渠道有自己的互动内容。

　　本章没有太多复杂的底层支持逻辑。基本上就是渠道能力的建设，渠道内容的维护和管理，更要注重的是愿景。

　　

　　这张图列举了可能与用户交互的渠道以及渠道支持的内容方式。渠道不仅是推送，还有Qiwei等私域的聊天消息，其次是对应电话和网站资源的人工服务。.

　　发送的内容不仅是文字和图片，还有任务或奖品。任务可以理解为你希望用户完成的事情，奖品是你完成某事后提供的激励。

　　这里大家可能会有的疑问是，着陆页通常带有任务和奖品，这是真的。但是，在某些场景下，不会有落地页，比如智能外呼、短信等。此时，将应用广义的用户任务系统和奖品。

　　至于内容的产品支持工具，还包括二维码、海报、短链接、落地页生成等，这些产品如何实现不是本篇文章的重点，这里不再赘述.

　　2. 产品性能：方案管理和方案配置

　　运营痛点是：管理难、成本高、上线周期长。

　　在线列表视图只是最表面的管理。我们还应该提供不同类型的视图，帮助运维同学了解运维计划的运行状态和业务逻辑。

　　成本和周期问题要通过自助、一站式、可视化配置来解决，这部分依赖于4-1的底层支持。

　　1）项目管理

　　方案管理，首先要明确什么是运营方案，它由目标用户、运营策略、效果评价三部分组成。

　　对于节目管理，最常见的是列表视图，包括基本列表和列表过滤。这一点就不赘述了，但是当我们想了解业务的运行状态时会用到：执行视图、逻辑视图等。

　　① 执行视图

　　

　　从运营的角度来看，任何交付类的运营基本上都涉及到KPI。不论效果如何，首先要按时按量执行每项运营策略。这是运营有效性的基础。

　　时间部分主要分为开始时间和时长，部分业务对任务完成的时效性要求较高。

　　量级部分的第一个也是最重要的部分是任务的成功率。在产品设计上更进一步，也可以根据相应计划的总水平和成功水平做出同比或趋势，方便我们定位问题。

　　② 逻辑视图

　　逻辑视图承载操作计划的逻辑。其次，我要帮助运筹学同学树立全球运营的视野。

　　这部分对于不同的产品形式和业务目标是非常不同的。下图是基于商品的逻辑视图。

　　

　　商品视图是单个商品在不同的运营场景下，在什么时间节点，通过什么渠道进行运营。

　　每个频道可能有自己的细分目标。点击“目标：引导加购”进入详细运营计划，查看运营逻辑。第二张图是从类别的角度来检查场景操作是否缺失。此视图不关注频道和时间等具体细节。

　　这只是两个例子。您可以根据自己的业务形态设计自己的管理视图。

　　2）方案配置

　　上面的产品视图只承载了部分逻辑，更详细的逻辑会进入运营计划页面。它包括以用户为导向的运营策略和运营计划的评估指标。

　　下一部分我将向您解释方案配置的表示层是什么样的。业界主要有两种配置方式，一种是流程视图，另一种是表单视图。

　　流程视图可以参考钉钉易达和易观数学。这里我们只展示简单的图片。

　　应该使用指甲：

　　

　　易观数学：

　　

　　表单视图也是一种比较主流的方式。个人设计将运营计划分为4个部分：运营频率、用户导向、运营策略、效果评估。在本节中，首先解释前三点。

　　① 运行频率

　　

　　对于一个操作计划，首先要处理的是在什么时间范围内操作，其次是操作的频率和时间。

　　事件触发不依赖于时间，根据事件的发生实时触发。这种类型没有运行时间的概念。循环触发和单次触发都会有时间的概念。

　　循环触发是指多次触发任务。触发事件仅适用于每日定时任务和间隔每日定时任务。举一个间隔日定时任务的例子来帮助理解：你必须每周一去上班。

　　单个触发器是一次性任务，可以在计划建立后立即发送，也可以在计划创建后一次发送。交互如下图所示：

　　

　　② 对于用户

　　这部分在讲解用户数据平台的表现层时会详细介绍，这里只展示交互。

　　

　　③ 经营策略

　　

　　上图是一个简单的模式，可以服务于大多数场景。但在实际过程中，还是会涉及到判断和执行条件的结合。

　　对于复杂模式，会在上图中添加额外的操作规则字段。通过研发可视化拖拽配置规则，然后通过相关渠道和内容渲染和执行规则，提供操作和填写。

　　但是随着规则的增多，很难维护和理解。除了流程视图，如何让它更容易使用和理解，我目前还没有很好的答案。

　　灵活多变，要做出取舍真的没那么容易。

　　五、用户操作平台：看效果

　　终于到了主流程的最后一部分：看效果。

　　回顾看到结果的痛点：评价标准不同、无法比较、缺乏负面评价。

　　个人观点，这部分主要是需求端，不是执行者，所以没有太多底层实现可以分享，而表现层则是根据运营计划的执行结果，进行漏斗统计和ROI成功干预的用户的计算。并深入分析肖像。

　　以下是关于漏斗统计和投资回报率计算的一些想法：

　　1. 漏斗统计

　　

　　漏斗的统计主要看端到端的转化。指标定义如下：

　　转化的概念非常广泛，取决于您希望该用户完成的行为指标。该指标可能因每个运营计划而异，包括交易、续订、访问、关注等。

　　如果你不关心数据产品，关注的核心应该是梳理不同业务的转化指标，将统计数据传递给数据部门，整合到你的平台中。

　　2. 投资回报率统计

　　ROI 统计 这是一个比较难设计的模块，这里可能只是一个指导。

　　之所以难，是因为不同的业务指标不一样，统计的方法也不一样。如果强制输出，可能不是所有人都认可。

　　这里的个人想法是分业务算盘，把握小局，放弃大局。了解并梳理不同业务的计算方式，为其提供通用的配置计算能力。帮助不同部门能够在内部进行比较和衡量。

　　

　　与传统的计算方式相比，ROI的计算公式多了一个参数：“负指标经济价值”。

　　原因也很简单，每发一个公众号文章，就会有人关注，就会有人下架。但这并不是说不需要继续操作，而是让分子大于0，并尽可能接近和超越分母。

　　

　　对于上图第二个例子的解释，假设是某张Dong Plus会员年卡，快到期时用户还没有续费。这时平台运营会将这些用户推送到出站座位，出站同学会引导用户进行续费。

　　过程指标反映了完成结果指标的方式。为提高成果指标的经济价值，要么减少完成过程的损失，要么提高完成成果的单价。

　　而负面指标，也就是这种操作行为可能造成的损失，就是这种操作动作的负面影响，比如第一个例子中的unfollow。

　　负指标也需要换算成经济价值，比如一个公众号粉丝的成本，一个小程序UV的成本。正负方向的结合可以使计算更加客观。

　　六、写在最后

　　这个 文章 写起来非常困难和有趣。难度是我最熟悉的我从未想过的B端产品。如果你沉下心来写，会有这么多的产品方向。有趣的是，我终于不用在意那些该死的界限、价值观和实现的难度，可以设计出理想中应该收录的东西，以及应该呈现的交互风格。

　　一个完整的用户操作平台是非常复杂和昂贵的。它要求您的业务强烈依赖召回，并具有足够大的业务规模和收益。否则，我仍然建议从这里获取灵感并制作自己的 MVP。

　　思想可以更开放。借助用户数据平台，还可以实现基于特征的拖放BI报表，也可以进行画像分析。有一个规则引擎来解决审批流程配置和调查问卷的问题也很好。通过构建渠道能力，为外呼团队和客服团队提供支持也是一个很好的途径。

　　其实能设计出这样一款产品，真的是很幸运，这和我过去的产品体验有联系。在我的第二份工作中，我做了很多B端产品，包括：页面配置、任务、奖品、用户功能等，但都非常脱节。

　　这一次，是一点点所谓的生态情怀，而不是假名。

　　最后，我也想建议B端产品在设计时尽量屏蔽底层逻辑，减少配置项。这么多的可视化和自助化配置，确实降低了研发成本，但只是转化为正在向前发展的产品和运营。

　　回到C端已经快3个月了。我写了一篇关于B端产品的毕业论文，2个月还清了债务。

　　非常感谢您来到这里，谢谢宁。

　　#专栏作家#