去年年末，我为当时负责的一款产品规划建立了一套埋点方案。这是一款主打海外市场的内容资讯类产品，上架到GooglePlay。 鉴于这是我第一次、从0到1、独立完成一套结构化的埋点方案，并能够通过这套埋点方案完成对整个应用的数据收集与分析，因此写下这篇文章记录当时的搭建思考和实践过程。 按照官方的说法，Firebase是Google的移动工具平台，适用于移动APP和Web程序。 从我个人的角度来讲，Firebase是GoogleAnalytics（GA）的增强升级版。过去几年我经常使用的数据分析工具是GA，后来Google停止维护GA的SDK，要求开发者全部改为使用Firebase的SDK。 因为GA有着多年的数据分析产品经验，完全免费，并可以与GoogleAds结合等，再加上Google在全球范围内庞大的用户基础，GA可以说是海外产品必备的工具。 但由于网络限制，主打国内用户的产品不适合使用GoogleFirebase，因为会有很多数据收集不到。 现在的Firebase中包含的产品总共分为以下三大类： DevelopProducts开发类 QualityProducts质量保证类 GrowProducts运营增长类 这三大类下面总共细分了18个产品模块，开发者可以通过这些产品模块实现构建应用，提高应用质量，拓展业务等目的。 Firebase提供的产品模块如此众多，要实现数据收集与分析系统该选择哪些呢？ GoogleAnalytics（分析）是Firebase的核心，你可以通过它收集用户事件、行为等，并生成分析报告。搭建基本的数据分析系统，只需（也是必需）集成GoogleAnalytics。 你可以集成Prediction（预测）、A/BTesting（A/B测试）实现一些精细化的、偏运营侧的需求。 如果集成了Prediction（预测），Firebase会利用自己的机器学习技术帮助你细分用户群体、预测用户行为，你可以为不用的用户群体配置不同的产品和运营策略。 举例：你可以利用Prediction分析用户对于应用内购买的接受程度以及可能性，从而精细化分营销推广策略：为付费接受程度高的用户推荐高级套餐，为接受程度低的用户推荐初级套餐。再结合A/BTesting进行对比测试，即可知道这种运营方式是否奏效。 3.Crashlytics+PerformanceMonitoring 集成Crashlytics（崩溃分析）、PerformanceMonitoring（性能监控）可以帮助开发人员收集并分析程序的崩溃记录，实时监控应用的性能表现。 GA完全免费，但Firebase不是完全免费的，它的价格方案分为Spark（免费方案）和Blaze（即用即付，按使用量付费）两种，详细收费方案可在官网中的查看。 上面提到的5个产品均可在Spark方案中免费使用。 使用FirebaseAnalytics时的四个要素分别是Event事件、Conversion转化、UserProperty用户属性、Audience受众群体。 理解这四个要素后，我们便知道了在产出埋点方案时，应该从哪几个角度出发。 如果某个事件对你的业务来说十分重要，例如用户注册、付费等关键业绩指标（KPI），你可以将这个事件标记为「转化」。当事件被标记为转化后，系统即开始收集与该事件相关的用户行为及相关数据。 即用户的身份特征或所使用设备的特征，如年龄、兴趣爱好、所在地区、语言、操作系统版本等。 用户属性也是比较基础的数据，在后期进行数据分析或者查找问题的过程中，用户属性可以作为筛选条件帮助你分析用户。 此要素无需单独添加代码获取，而是在控制台中通过「Event事件」与「UserProperty用户属性」组合后筛选出的细分用户群体。 在上述的四要素中，Firebase会根据应用类型自动捕获或预设一部分事件、转化、用户属性，但更多的、更详细的则需要开发者自行添加代码配置。 与Event事件息息相关的一个重要概念是Parameter参数，你可以为一个事件关联多个参数，从而更细致地分析某个事件。 举例：用户分享了应用中的内容到社交平台，此时触发的是「share」事件，那么这个事件可以关联收集「content_type」（内容类型）参数、「share_channel」（分享渠道）参数，由此可以知道用户对于社交网络的使用偏好等。 参数需要开发人员在程序中添加代码配置，生效后即可在控制台中为事件关联参数。在Console控制台关联参数时，可以选择要统计该参数的Text文本还是Number数量。 参数并不附属于某个事件，两者是关联的关系，你可以在控制台中为某个事件关联参数，这不会影响这个参数继续被其他事件关联。 但是Firebase对一个项目中使用的参数总数量有限制（「应用+网站」类型项目最多支持100个参数），并且同一个参数如果被多个事件关联，那么关联的次数都会算进参数的总限制数量中。 举例：你的项目支持100个参数，如果你在10个事件中关联了同一个参数，则可使用的参数数量还剩100-10个。 所以你需要在埋点前尽量全面地梳理自己项目所需的参数，避免出现参数用尽的情况。 当应用转到后台运行后，Firebase会开始计算会话超时时长。 默认的会话超时时长是30分钟，这意味着如果应用在前台运行了5分钟后又在后台运行了30分钟（应用没被系统杀掉的话），则这个用户本次会话的时长就是35分钟。 这对某些后台运行需求不强烈的应用来说，可能会干扰他们判断真正的用户会话时长。因此，你可以根据自己的应用特性，设定自己应用的会话超时时长。 Session对话时长不是必须自定义修改的，可以看产品类型和需求来决定。 如果你需要追踪用户在应用内的行为流、用户在不同界面的停留时长、事件数量等等，你可以根据需求对screen_class重新命名，然后在控制台中按照screen_name方式查看即可。 或者你也可以自定义进入屏幕、退出屏幕的触发规则，然后开发人员按照规则统计屏幕浏览数据。 在界面内左右划动屏幕切换 切记屏幕跟踪方案要与开发人员协商制定，因为不同应用、不同开发人员有不同的代码架构方式，这决定了他们使用哪种方案性价比最高。 关于如何产出埋点的方案文章和方法论有很多，近期读到的比较好的一篇是友盟+团队的文章。 简单来说，你需要根据自己的身份（产品经理、运营、数据分析师、开发），结合应用类型（电商、内容、旅行等）确定自己的数据需求，然后将需求转化成核心数据。 以我负责的资讯产品为例，我会有以下数据需求： 衡量用户对于内容品牌的偏好； 衡量用户对某功能的使用程度； 评估用户的登录意愿，以及对登录方式的偏好； 评估用户的订阅通常发生在哪些关键节点之后； 有了数据需求后，开始着手将需求转化为所需的核心数据。比如：我需要知道各个内容品牌的阅读量、停留时长、各分享渠道等等。这个过程十分重要，但本文不再赘述。 埋点方案最终交到开发人员手上是采用Excel表格的形式，我的方案包含4个部分，分成4页Sheets呈现。 1）第一页：Session定义 在这里定义： Session会话开始的标志 Session会话的标志 会话的超时时长 2）第二页：Events 在这里列出你需要收集的所有Event事件，你需要告诉开发人员这些事件的名称、事件是如何触发的、事件包含了哪些参数、参数该如何取值。 EventName——事件名称 Trigger——触发时机 ParametersName——参数名称 ParameterValue——参数取值 ParameterType——参数值类型 为了是开发人员更加清晰、快速理解这些Event事件，你还要告诉开发人员这个事件要满足满足哪些数据需求，以及其他一些辅助性的描述，例如： 3）第三页：Screen 上面已经讲过，在收集Screen_view屏幕浏览数据时，我们需要与开发人员沟通后确定方案。如果沟通后你们需要自定义屏幕跟踪方案，则可以使用以下方式呈现： screen_view——触发时机 模块/场景 Screen_Name——屏幕名称 屏幕描述 名称示例 同样需要写明一些辅助性的描述： 4）第四页：User_Property 这里需要定义清楚产品中会出现的几类用户群体： UserPropertyName——属性名称 Description——属性描述 举例：根据用户的Level将用户划分为不同类型，则属性名称可以叫做「user_level」，不同的Level分别使用数字标记，0是一般用户，1是付费用户等等。 快速验证埋点结果——DebugView，由于Firebase采用的是定期轮询数据的方式，通常1小时一次，所以在开发集成的过程中，我们如果等轮巡后将数据展示到控制台中，然后再检查埋点是否成功、是否准确，这个过程会非常漫长。 因此Firebase在控制台中提供了「DebugView」功能，通过DebugView，我们可以在设备上操作应用，相关事件会以Timeline的形式实时展示在DebugView报告中。 本文由@Jalyn原创发布于人人都是产品经理，未经允许，禁止转载 题图来自Pexels，基于CC0协议
上一篇
下一篇