数据分析在运营的工作中可以起到很大的作用,运营对于平台的数据波动比较关注,特别是如今是精细化运营时代,运营在工作中对于数据的分析就更加重视。 运营是一个理性和感性相结合的岗位。感性的人可以做好活动运营,可以做好用户运营,反而容易失去大局观;理性的人可以做好流程规划,可以做好数据运营,反而很难做成超出用户预期的活动和文案。很多时候,我们需要在理性和感性之间进行权衡。 运营工作离不开数据的指导,特别是目前进入精细化运营时代,运营人员离开了数据分析做运营上的决定,与赌场中的赌徒并没有太大的差别;运营人员更不能为不符合预期的结果找借口,而是要基于数据统计分析实事求是地撰写运营计划复盘;所以,运营人员不能把运营方案寄托在感觉之上,而应该建立在理性的数据分析之上。 产品运营需要通过数据找出波动背后的原因,在产品的不同阶段,关注不同的指标。渠道运营人员需要通过数据衡量渠道的价值,互联网的渠道有很多,到底哪个渠道对于产品的价值最高?现在各个平台的规则不断完善,免费流量的获取难度逐渐增大。 无论选择哪个渠道,最终目的都是为了转化用户,完成企业的业务目标。其中,能够获得用户并直接形成转化的渠道是最优选择渠道。如果你的目标是为了增加产品使用人数,那么围绕拉新工作设置运营流程的转化节点需要重点考虑。如果你的目标是完成产品的销售额,那么扩大投放用户群体并优化购买流程需要重点考虑。 通过渠道拉新或利用运营技能转化用户的过程,每个节点都会影响最终的结果。所以,从渠道到转化的每个节点都应该做好数据统计工作,支撑后续的数据分析并优化节点的转化率。 用户运营人员需要通过数据建立用户分层分析用户的关键性行为,运营人员要做到比用户更懂用户。用户数量和用户价值是产品的核心指标,只有庞大的用户数量和高用户价值才能支撑起商业模式,所以用户运营是企业中比较核心的工作;运营人员需要对用户做深度分析后,才能决定采用何种运营技能。
给你我的爱 发布的最新帖子
-
数据分析如何驱动运营
-
交互设计的更深层—交互成本
每位产品设计师都必须掌握三项核心技能:产品思维、视觉设计和交互设计。
交互设计背后的理念基础是“交互成本”,这经常用来衡量一个产品的可用性。尼尔森·诺曼(Nielsen Norman)将“交互成本”定义为用户为实现其目标而必须付出的身心努力的总和。 通常,我们希望将交互成本保持在尽可能低的水平。但是这很困难,因为产品涉及的用户场景越多,难度就越大。支持更多用户场景和功能会增加产品信息架构(IA)和导航的复杂性。用户场景是一系列步骤,是从用户的目标开始到该目标完成的整个流程。 交互成本可以分为物理交互成本(PIC)和心理交互成本(MIC)。
根据Tesler的“复杂性守恒定律”,所有系统都具有无法删除或隐藏的固有复杂性。良好的设计可确保由系统而不是用户承担尽可能多的复杂性。注意,不要将界面简化到过于抽象。一个常见的陷阱是降低物理交互成本(PIC),却以心理交互成本(MIC)为代价
心理交互成本(MIC)的两个最重要的组成部分是注意力和记忆力。如果要评估界面对心理交互成本(MIC)的关注程度,可考虑进行眼动追踪研究(ETS)。
使用ETS不仅推断用户的位置,还可以推断他们的想法。 工作记忆(短期记忆的一部分)是最相关的。最短的记忆类型称为工作记忆,通常在任务过程中仅持续几秒钟。换句话说,当我们参与其他认知过程时,我们的工作记忆负责我们可以掌握的信息。
我们应尽可能减少交互成本,但是,当必须做出权衡时,要保证首要基础用户使用场景的交互成本足够低。
-
供应链金融业务模式
供应链融资这块,但不知道怎么入手,在现有的业务平台基础上,怎么切入,才能把供应链做好,所以开始就从供应链这块来分析,后续我会定期与大家分享互联网电商和互联网金融相关的经验。
供应链金融淡化了银行看中的企业规模、财务报表,这恰恰是中小微企业的弱项,而更看中企业的交易历史记录、合同执行能力和贸易的连续性,使银行跳出单个企业的局限,凭借核心企业的信用增信,对核心企业与上下游企业真实的交易进行资信捆绑,通过资金的封闭运作,降低了相对弱势的小企业准入门槛。因此核心企业的资信情况和交易关系稳定性以及核心企业的配合程度是否愿意与提供融资的银行进行书面协议或锁定付款路径就显得尤其重要。 对于企业或银行来说,做供应链其实就是考核对产业链的整合能力。无论是从B2B转做供应链金融还是搭建供应链金融平台,都需要银行、上下游企业、物流企业、小贷公司或担保公司多方参与,需要与多方的业务系统进行对接。梳理总结目前国内做供应链金融模式,共有三种:以产业链核心企业为中心的“1+N”模式。强调上下游交易关系稳定且连续的“N+N”模式。以第三方物流商、交易市场为核心的仓单质押、货权质押模式。
从目前供应链金融业务发展的趋势来分析,未来3年谁对产业链各方资源的整合能力强,谁就会成为这个领域的老大,现在已经可以看到供应链金融生态圈的雏形,包含银行、上下游企业、第三方金融机构、担保公司、第三方物流商、第三方交易市场、小贷公司、货权变现公司等。
-
整合营销如何兼得
企业在做品牌营销的时候,想要做到品效合一是很难的。大多数广告的结果都是品牌热度在此期间达到了一个升值,或者说在此期间达成一定的产品交易效果。鱼和熊掌真的不能兼得吗?成年人不能两者都要吗?当然可以。 品效合一就是企业在做营销的时候,既要看到品牌的声量,又要看到效果的销量。产品要带动品牌声量的提升,同时品牌推广本身也要有销量的增长。因此,企业营销不仅要品牌,更需要效果,在移动互联网上做营销必须要追求品效合一。 换而言之,企业在做品牌营销的时候,品牌在整个营销活动中的热度与产品的销量是一个相辅相成的存在,品牌的热度可以效率提高更好的辅助,而好的销量可以为品牌达成更加广泛的传播。
随着互联网的进步发展,现在任何一个品牌只有有足够的“资源”都可以在央视投放广告,而在二十年前一个品牌在央视播放一个几秒钟的广告都是一件了不得的事情。人们的认知以及网络环境的变化造就了品牌营销的内卷,如何尽可能的做好品牌的“品效合一”可从以下几个方面思考
了解用户痛点:结合“品效合一”来看,一个广告营销的最终目的有两个。一是扩大品牌在用户中的知名度,让用户知道这个产品,从而影响用户后续所有的购买行为中增加成功购买率。二是让用户用最短时间完成产品购买,将产品转化为产品销量。但需要做成这两件事的前提就是营销广告在主题传达路径之时,就要针对用户的痛点进行系列的营销手段。 占领用户的心智的广告很多,譬如脑白金洗脑广告““今年过年不收礼,收礼只收脑白金”,王老吉广告;“怕上火,就喝王老吉”。在我看来,品牌广告想要占领用户心智,并在后续用户有所需求的时候想到依然是它。在广告语方面除了朗朗上口容易好记之外,必须是帮用户解决问题的。 加速用户购买 当用户看到你的广告并且在购买的时候优先选择你的产品时,你的广告已经帮助用户加速完成购买的过程了,简单举例下;你去一个便利店购买一个矿泉水,农夫山泉的广告语是“我们不生产水,我们只是大自然的搬运工。”加速用户购买其中最重要的用户所在的渠道,一个用户决定购买某个产品是从多方面考虑的。
-
WhatsApp可用性测试
WhatsApp是一款面向移动手机和网络的信息服务,你可以通过网络发送短信、图片、音频和视频。WhatsApp 在全球范围内被广泛使用,是最受欢迎的在线消息应用程序(之一)。 痛点1:寻找联系人;有两种方式可以找到一个人和他聊天:在聊天列表中搜索;点击顶部的聊天图标并搜索联系人。不过,用户并不清楚如何区分使用这两种方式。在聊天列表中搜索的话,是假设搜索的范围仅在聊天列表中,实际上它适用于聊天列表和联系人列表;另一方面,顶部的聊天图标还提供聊天和联系人列表。这就增加了用户的理解难度,他们需要做一些什么才能了解这些功能。 建议:需要明确区分聊天列表和联系人列表。可以通过在联系人列表中提供过滤器选项来完成,也可以根据最近的聊天或联系人名称对单个列表进行排序。 痛点2:查看消息;在“消息信息区域”中,显示消息状态的区域与“消息信息区域”合并了。另外,用户并不能很清楚地了解当前正在查看消息的状态。此外,用户需要花费时间在“消息信息区域”的顶部找到“关闭”图标。 建议:需要明确区分消息信息区域和消息的区域。由于这是桌面版本,并且在消息打开时消息信息区域仍然是可见的,所以消息及其信息之间的链接关系可以更加突出。当前所选的消息可突出显示。
-
暗藏玄机的MySQL查询超时问题
线上有个定时任务,这个任务需要查询一个表几天范围内的一些数据做一些处理,每隔十分钟执行一次,直至成功。通过日志发现,从凌晨5:26分开始到5:56任务执行了三次,三次都因为SQL查询超时而执行失败,而诡异的是,任务到凌晨6:00多就执行成功了。每天都是凌晨五点多失败,凌晨六点执行成功。总结来说就是MySQL查询超时问题。我以为三分钟可以解决完成,但事实上并且如此。 看到超时SQL,大多数人第一反应就是这个SQL没有走索引,我也不例外,我当时的第一反应就是这条SQL没有走索引。SQL里面有两个日期参数,这两个起始日期是某种商品的可交易时间区间,相隔三到五天,我取了17天的时间间隔的保守值,Explain了一下这条SQL。 根据Explain结果,我当时的推断是:这条SQL肯定走了索引,如果没有走索引,那六点多钟的查询肯定也会超时,因为这个表的数据是千万级别的。为了验证这一推断,我找DBA帮我导出了一下凌晨5点到早上7点关于这个表的慢SQL,DBA告诉我那个时间段没有关于这个表的慢SQL。 这也进一步验证了我说推断:这条SQL走了索引,只是在五点多的时候因为一些神秘原因导致了超时。接下来,需要做的就是找出这个神秘的原因。 按照以往的经验,我认为有这几点因素会导致查询超时MySQL资源竞争、数据库备份、网络。 MySQL资源竞争:首先,我通过监控系统查看了那段时间MySQL的运行情况,连接数和CPU负载等指标都非常正常。所以,因为MySQL负载导致超时首先就可以被排除。 数据库备份:首先备份锁表不会锁这么久,这个任务是前前后后半个小时都执行失败了;其次我们是备份的从库,并不是备份的主库;最后,我们的备份任务都不是凌晨五点执行的。所以,因为备份导致超时可以排除了。 网络:是不是网络波动的原因呢?我找运维同学帮忙看了一下执行任务的那台机器那段时间的网络情况,非常平缓没有丝毫问题,机房也没有出现什么网络抖动的情况。再者,如果是网络问题,肯定会影响其他任务和业务的,事实上,从监控系统中查看其他业务并没有什么异常。所以,因为网络波动导致超时也可以排除了。 当自己的设想被一个个推翻,在我突然要放弃的时候,我突然发现SQL日志记录里面的时区都是标准时区的,而我那个任务执行的时候是北京时间,要知道标准时区和北京时区是差了8个小时的! 从日志上面可以看到,查询的日期区间从2020年9月到2021年4月,时间跨度7个月。MySQL成本计算的时候认为区间太大,走索引还不如直接扫描全表,最终没有走索引扫描了1800W条数据。 说好的时间区间最多七天呢?怎么变成了七个月?赶紧定位代码,定位发现底层在取时间区间时,调了一个RPC接口,这个接口预期返回的时间区间只有几天,结果返回了七个月的时间区间。这段逻辑是18年上线的。 于是联系提供这个RPC接口的相关人员,通过查找验证确定这是底层数据的问题,应该返回几天结果返回了几个月。最后修复了相关数据,增加了相应的校验和监控,重新发布系统,这个存在了两年的BUG也就得以解决了。
-
浅谈GooglePlayASO优化
ASO是为了提高该产品的搜索结果成绩,提升APP的下载量,针对Google Play来说,ASO就是优化APP页面。 什么是ASO?ASO即APP Store Optimization,是用于提高APP在应用市场排名的工具,其实也就是移动产品的SEO工作。ASO是为了提高该产品的搜索结果成绩,提升APP的下载量,针对Google Play来说,ASO就是优化APP页面。 为什么要做ASO?根据Forrester调研,有63%的用户寻找APP的时候是通过在应用市场搜索,另外,Google Play也有报道称80%的自然流量来自于Google Play的搜索。
-
自动内存泄漏检测工具MLeaksFinder
MLeaksFinder 是腾讯开源的 iOS 平台的自动内存泄漏检测工具,引进 MLeaksFinder 后,就可以在日常的开发,调试业务逻辑的过程中自动地发现并警告内存泄漏。开发者无需打开 instrument 等工具,也无需为了找内存泄漏而去跑额外的流程。并且,由于开发者是在修改代码之后一跑业务逻辑就能发现内存泄漏的,这使得开发者能很快地意识到是哪里的代码写得问题。这种及时的内存泄漏的发现在很大的程度上降低了修复内存泄漏的成本。
特性:自动检测内存泄漏和释放不及时的场景;构建泄漏对象相对于 ViewContrller 的引用链以帮助开发者定位问题;不侵入业务逻辑,引入即生效,无需修改任何代码或引入头文件。
用法:MLeaksFinder 可自动查找 UIView 和 UIViewController 对象中的泄漏。当发生泄漏时,它会在 View-ViewController 堆栈中显示泄漏对象预警。
-
跨集群的网络连接Submariner
Submariner 为部署在需要相互通信的多个 Kubernetes 集群中的微服务提供网络连接,由容器管理软件提供商 Rancher Labs 推出。这一全新的解决方案解决了 Kubernetes 集群之间的连接障碍,为多集群部署提供了更多实现方式,例如在跨地区的 Kubernetes 内复制数据库,以及跨集群部署服务网格。
越来越多的企业将 Kubernetes 用作为跨所有公有云和私有云基础设施的基础计算平台,而 Submariner 让这些企业得以无缝连接、扩展和迁移部署在 Kubernetes 集群上的工作负载,无论这些 Kubernetes 集群是部署在何种云上。
主要功能:与现有集群的兼容性和连接性:用户可以将Submariner部署到已有的Kubernetes集群中,并在位于不同集群的节点之间添加三层网络连接。安全路径:使用IPSec隧道实现加密的网络连接。
各种连接机制:虽然IPSec是开箱即用的默认连接机制,但Rancher将在不久的将来启用不同的连接插件。集中式代理:用户可以注册和维护一组健康的网关节点。灵活的服务发现:Submariner提供跨多个Kubernetes集群的服务发现。CNI兼容性:适用于流行的CNI驱动程序,如Flannel和Calico。
项目地址: https://submariner.io/#
-
基于AndroidAppBundle的动态化框架Qigsaw
Qigsaw 是爱奇艺自主研发的动态化框架,其核心优势如下:利用 Android App Bundle 开发套件,极速开发体验。支持 Android App Bundle 所有功能特性,“山寨”Play Core Library 公开接口实现,开发者阅读官方文档即可愉快开发。任何进程均可动态加载插件,支持 Android 四大组件动态加载。如果应用有出海需求,可无缝切换至 Android App Bundle 方案。仅一处 Hook,少量私有 API 访问,保证框架稳定性。
Qigsaw 提供了两个插件,分别作用于 App 和 Dynamic feature, 先来看看 Dynamic feature 部分。gsaw 是基于对于 com.google.android.play.core 对外暴露的接口,进行了自定义实现。因为 AAB 目前只能对 Google play 上发布应用起作用,所以开发者重新实现了一套 com.google.android.play.core 包名的第三方库,这样就可以做到在国内市场,与国外应用市场无缝迁移。
Qigsaw 提供两种加载方式加载插件 apk,单 classloader 和多 calssloader 模式,单 classloader 涉及私有 api 访问,而多classloader 不涉及私有 api 访问。
简而言之,Qigsaw 可以让我们在国内使用 Android App Bundle,并且可以无缝切换到 Google Play.