产品经理的埋点选择
产品经理会借助用户行为分析平台来监控用户行为表现，探索新的产品机会，分析导致用户留存或转化的原因。而正确的数据采集是实现上述场景的必要条件。 在多年的实践中，我们陆续发现，只用一种数据采集方式无法解决日益复杂的数据分析需求，无法适应高速迭代的产品开发节奏。越来越多的公司（如网易，美团，有赞等）开始采用多种采集方式协同使用的方法进行数据分析。 产品经理需要了解什么场景下使用无埋点事件，什么场景下使用埋点事件，以便于满足他的数据诉求。 在了解场景之前，产品经理须知道上述数据采集能力的特性和边界，才能能扬长避短，充分发挥两种采集能力的优势。 埋点事件， 顾名思义就是借助埋点（写代码）来采集数据，在需要监测用户行为数据的地方加上一段代码。经过数据校验后的埋点数据是准确的，稳定性高，适合监控和分析。埋点往往可以添加较多的业务属性，方便产品经理对事件进行业务属性拆解和下钻分析，能很好地从业务逻辑切入行为分析，理解行为后的业务思路。 当然，实现上述目标，付出的代价相对比较高。 首先，埋点这件事，往往不是一个人或者一个团队内完成的事情，它是一个跨团队协作问题，需要业务人员，分析师，打点工程师，数据校验工程师的通力合作。而真实的场景是，跨团队协作长会遇到部门墙问题，沟通问题，资源优先级问题等等。同时，产品经理很难从一开始就掌握所有用户路径，必然会存在漏埋、错埋的现象，又要重新协调排期和资源，费时费力。 其次，埋点不能回溯历史数据。 最后，往往由于埋点数量有限，许多用户行为数据缺失，分析过程中数据缺失比较严重。 最终导致诸如：没有埋上点，埋点数据异常，埋点上线业务已经下线，想分析的维度忘了「埋」上去等等。另一面讲，如果产品经理等业务人员总是能用上准确的，及时的数据，并能深度分析，那么这家公司的组织能力，数据治理的能力，数据驱动的文化往往都很优秀（当然这种公司的业务表现也很好）。 无埋点事件，当然它并不是真正的不需要写代码，而是前端自动采集全部事件并上报所有的数据，并通过「圈选」来获取需要使用的事件。圈选数据不需要组织协作，产品经理不依赖任何人就能采集到数据，并马上在分析工具中使用，所见即所得。 以往花费几天的工作，借助无埋点秒级完成。而且圈选可以回溯过去7天数据，较好的解决了忘了「埋点」这个痛点。 然而，没有一种数据采集方式可以解决一切问题，这种方式依然有其弊端，产品经理在使用时要了解这些弊端，并判断这种采集方式是否可以支持你的业务需求。 常见的弊端：
数据采集方式的选择是基于业务场景的，不同的业务场景下应该选取什么样的数据采集方式？ 你是否遇到过如下场景？
你是否也遇到过如下场景？
你是否还遇到过如下场景？
第一类场景更适合使用无埋点事件，基本上也只能使用无埋点事件。 这类场景，我们称之为探索式数据场景，它们具有如下属性：
第二、三类场景核心KPI监控，建议使用埋点事件，深度业务分析也只能使用埋点事件。 这两类场景，我们称之为数据监控与分析式数据场景，它们具有如下属性：
两类场景不是互斥的，作为产品经理，我们近乎同时遇到这两种场景。 一个用无埋点采集方式就能解决的问题，若使用埋点，既不会立刻看到数据，也会浪费公司工程资源；一个埋点采集才能解决的问题，用了无埋点可能会导致数据不稳定，业务维度少等问题。 面对不同的场景我们需要明确目标是什么，是探索，监控还是深度业务分析？ 我们需要采集的事件多吗？我们为了实现这个目标拥有的资源是什么？我们的 Deadline 是什么？ 结合各种情况综合判断，采用合适何种埋点方式。
本文素材来自互联网 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
