企业在做品牌营销的时候,想要做到品效合一是很难的。大多数广告的结果都是品牌热度在此期间达到了一个升值,或者说在此期间达成一定的产品交易效果。鱼和熊掌真的不能兼得吗?成年人不能两者都要吗?当然可以。 品效合一就是企业在做营销的时候,既要看到品牌的声量,又要看到效果的销量。产品要带动品牌声量的提升,同时品牌推广本身也要有销量的增长。因此,企业营销不仅要品牌,更需要效果,在移动互联网上做营销必须要追求品效合一。 换而言之,企业在做品牌营销的时候,品牌在整个营销活动中的热度与产品的销量是一个相辅相成的存在,品牌的热度可以效率提高更好的辅助,而好的销量可以为品牌达成更加广泛的传播。 随着互联网的进步发展,现在任何一个品牌只有有足够的“资源”都可以在央视投放广告,而在二十年前一个品牌在央视播放一个几秒钟的广告都是一件了不得的事情。人们的认知以及网络环境的变化造就了品牌营销的内卷,如何尽可能的做好品牌的“品效合一”可从以下几个方面思考 了解用户痛点:结合“品效合一”来看,一个广告营销的最终目的有两个。一是扩大品牌在用户中的知名度,让用户知道这个产品,从而影响用户后续所有的购买行为中增加成功购买率。二是让用户用最短时间完成产品购买,将产品转化为产品销量。但需要做成这两件事的前提就是营销广告在主题传达路径之时,就要针对用户的痛点进行系列的营销手段。 占领用户的心智的广告很多,譬如脑白金洗脑广告““今年过年不收礼,收礼只收脑白金”,王老吉广告;“怕上火,就喝王老吉”。在我看来,品牌广告想要占领用户心智,并在后续用户有所需求的时候想到依然是它。在广告语方面除了朗朗上口容易好记之外,必须是帮用户解决问题的。 加速用户购买 当用户看到你的广告并且在购买的时候优先选择你的产品时,你的广告已经帮助用户加速完成购买的过程了,简单举例下;你去一个便利店购买一个矿泉水,农夫山泉的广告语是“我们不生产水,我们只是大自然的搬运工。”加速用户购买其中最重要的用户所在的渠道,一个用户决定购买某个产品是从多方面考虑的。
玻璃 发布的最新帖子
-
整合营销如何兼得
-
运营人的难题
运营人的两大难:新用户拉新,老用户留存。而拉新的成本远高于留存的成本,且老用户的消费能力远高于新用户。那么,如何做好用户留存呢?
提供一如既往的高品质产品,无论你是写文章还是做服务,亦或是卖货,从用户的角度来说,这都是一个商品。 关注用户的售后服务体验,只管卖,不管售后,这是很多平台都容易犯的错,往往服务跟不上销售。一种是在业务高速发展中忽视这样的问题,一种是业务进入平稳期轻视了这样的问题。而对于用户来说,如果自己花钱得不到良好的售后保障,自然是会对平台失望的。 千万不要让用户找不到你,每次把货卖出去以后,商家都挺怕用户找来的,甚至主动拒绝与用户联系。大家有没有遇到过,打一些机构的电话,永远都是打不通的?但凡那写怕用户找的,或者用户找来服务不好的,都是对自己的产品、服务不自信,怕麻烦、怕吃亏,把用户假设成了坏人。 做一个有温度的人,平常这些app给我推送的大部分消息我都会忽略,但每年唯独这条我会打开看一眼,这是一种很微妙的关系。虽然我们和客户之前本质上就只有一种消费关系,但消费关系如何巩固,就和我们做了什么息息相关。 让用户对你充满期待,为什么苹果手机的发布会,每一年用户都会充满期待。因为大家认为它就是行业的方向标,从它的外观设计到产品功能再到周边产品,的确会有一些惊艳的地方。所以,创新是任何一个个人和品牌保持竞争力的核心。
-
通过改变思维方式替代同理心
产品经理要有同理心,站在用户的角度思考问题,和用户共情,这已经成为了很多产品经理的共识。 同理心(Empathy),亦译为“设身处地理解”、“感情移入”、“神入”、“共感”、“共情”。泛指心理换位、将心比心。亦即设身处地地对他人的情绪和情感的认知性的觉知、把握与理解。主要体现在情绪自控、换位思考、倾听能力以及表达尊重等与情商相关的方面。 同理心的核心作用在于理解,而产品经理与需要的是什么?是了解用户。一字之差,天差地别,“我理解你”和“我了解你”这俩句话的差异有多大?简单来说,产品经理需要了解用户情感的动机来源,而不需要理解用户有多痛苦,多快乐,多悲伤,多愤怒。 用户的情绪就是对于马匹速度的不满,产品经理需要做的不是理解用户有多不满,而是了解用户为什么不满,这需要的是透过现象看本质的能力,而不是同理心。想要了解用户为什么不满,可以通过直接询问,问卷调查或是数据分析,都可以达到了解用户需求的目的,而不是通过同理心去感受用户的情感,代入过多的情感只会增加判断出错的,而判断力就是产品经理的生产力! 在基本了解了同理心作用和基本概念后,接下来从“经历”对于同理心的影响来说明为什么“产品经理需要同理心”是个伪命题,或者说“产品经理会和用户产生共情是个伪命题”。 产品经理现在对于用户的判断并不是出于同理心,而是通过对规律的判断,再结合自己的感受,形成对用户的理解。说直白点,现有产品经理大部分都是通过用户信息判断用户类型,然后根据用户类型推测用户行为与思考方式,这个过程需要严谨的逻辑思考能力与丰富的知识,同理心能起作用只是推测时产生的幻觉。
-
一份漂亮的表单设计
表单在我们的日常工作中经常会用到,一个优质的表单可以提高我们的工作效率,完成一些更多的业务,提高产品体验。 产品角度 – 收集产品现存的问题:运用“交互行为五要素”将一整套业务拆分成一个个小的业务场景,通过产品体验剧本进行交付沙盘模拟分析各个核心业务场景下的产品现状。 客户角度 – 获取客户的诉求:一线交付人员对客户做了调研访谈,深入的挖掘他们对当前的产品使用问题;客户成功团队收集用户的心声,将不同岗位和职级对于租赁系统的问题真实反馈收集汇总。 将每个场景下的客户诉求,与产品现状进行对比,那么在产品现状中没能满足客户诉求的地方,便是产品需要改进提升的问题。由于得到的问题其实还是较为零散,最后我们利用“双钻模型”对待改进的问题进行聚焦,也就是对同类问题进行归类、发现零散问题背后的本质问题,得到目前新签合同的核心问题:缺乏业务场景化设计,签订效率低。 针对之前所提出的问题,本次新签合同流程的设计目标“有场景、更高效、更易懂”大致体现在如下几个方面:功能整合,架构升级。在旧版的框架体系中,所有任务信息直接平铺展示在页面中,导致功能信息杂乱分散,重点信息难以查找,信息关联性弱等问题,严重影响了客户的签订效率。 聚焦业务,重组结构;在页面结构上,通过捕捉用户习惯与认知,借鉴了用户最熟悉的线下纸质合同样式,消除机器语言的陌生感,强化业务感知,降低用户认知负担。 化繁为简,内容为王:在表单填写中,过多的信息透传会让用户在使用时产生“冗余感”,影响填写效率。而清晰明了的信息展示,则可以减少用户对选定内容的反复查对,降低焦虑感。 精益求精,更有温度;复杂业务表单由于充斥着各种条理和逻辑性,给表单本身带来了额外的使用负担。通过心理学的思考、UI 上的感情化设计、目标人群的特性、使用场景的氛围结合等手段进行等手段进行表单设计,能让用户在填写中更轻松、更顺畅。
-
iOS平台设计规范
iOS是运行于iPhone、iPad和iPod touch设备上、最常用的移动操作系统之一。作为互联网应用的开发者、产品经理、体验设计师,都应当理解并熟悉平台的设计规范。这有利于提高我们的工作效率,保证用户良好的体验。 三大界面要素Interface Essentials:大多数iOS应用都是由UI Kit中的组件构建的。UI Kit是一种定义通用界面元素的编程框架,这个框架不仅让APP在视觉外观上保持一致,同时也为个性化设计留有很大空间。UI Kit提供的界面组件有三类:栏(Bars),视图(Views),控件(Controls)。
栏(Bars):栏,可以告诉用户在APP中当前在所在的位置、能提供导航,还可能包含用于触发操作和传递信息的按钮或其他元素。包括6种:导航栏、搜索栏、侧边栏、状态栏、标签栏、工具栏。 视图(Views):包含用户在APP中看到的基本内容,例如:文本、图片、动画以及交互元素。视图可以具有滚动、插入、删除和排列等交互行为。
控件(Controls):控件,是用于触发操作并传达信息的。例如:按钮、开关、文本框和进度条,都属于典型的控件。! -
基于Paxos协议的分布式队列PhxQueue
PhxQueue 目前在微信内部广泛支持微信支付、公众平台等多个重要业务,日均入队达千亿,分钟入队峰值达一亿。其设计出发点是高数据可靠性,且不失高可用和高吞吐,同时支持多种常见队列特性。
PhxQueue支持的特性如下:同步刷盘,入队数据绝对不丢,自带内部实时对账出入队严格有序,多订阅,出队限速,出队重放,所有模块均可平行扩展;存储层批量刷盘、同步,保证高吞吐;存储层支持同城多中心部署;存储层自动容灾/接入均衡,消费者自动容灾/负载均衡。
Store 作为队列存储,引入了 PhxPaxos 库,以 Paxos 协议作副本同步。只要多数派节点正常工作及互联,即可提供线性一致性读写服务。为了提高数据可靠性,同步刷盘作为默认开启特性,且性能不亚于异步刷盘。在可用性方面,Store 内有多个独立的 paxos group,每个 paxos group 仅 master 提供读写服务,平时 master 动态均匀分布在 Store 内各节点,均衡接入压力,节点出灾时自动切换 master 到其它可用节点。
Producer 作为消息生产者,根据 key 决定消息存储路由。相同 key 的消息默认路由到同一个队列中,保证出队顺序与入队顺序一致。
Consumer 作为消费者,以批量拉取的方式从 Store 拉消息,支持多协程方式批量处理消息。Consumer 以服务框架的形式提供服务,使用者以实现回调的方式,根据不同主题(Topic),不同处理类型(Handler)定义具体的消息处理逻辑。
Scheduler - 消费者管理器(可选择部署):Scheduler 的作用是,收集 Consumer 全局负载信息, 对 Consumer 做容灾和负载均衡。当使用者没有这方面的需求时,可以省略部署 Scheduler,此时各 Consumer 根据配置权重决定与队列的处理关系。
部署 Scheduler 后,Scheduler leader 与所有 Conusmer 维持心跳,在收集 Consumer 的负载信息的同时,反向调整 Consumer 与队列的处理关系。当 Scheduler leader 宕机了后,Scheduler 依赖下述分布式锁服务选举出新 leader,不可用期间仅影响 Consumer 的容灾和负载均衡,不影响 Consumer 的正常消费。
Lock - 分布式锁(可选择部署):Lock 是一个分布式锁,其接口设计非常通用化,使用者可以选择将 Lock 独立部署,提供通用分布式锁服务。
项目地址: https://github.com/Tencent/phxqueue -
全局捕获Crash的库NeverCrash
NeverCrash for Android 一个全局捕获Crash的库。信NeverCrash,永不Crash。
全局捕获: 全局(包含浏览器外)出现一个鼠标事件,会被设置全局捕获的对象捕获,如果此对象正好有对应的事件函数,那么会被触发,而最初的发起事件的元素就不会执行它的事件函数了,通俗点说就是事件被掠走了。
全局捕获只能执行一次捕获的事件,如果持续捕获可能会出现问题,可以想象下:如果全局捕获点击事件,鼠标无论点击哪里都会执行那段代码,那么连最基本的关闭浏览器窗口都不行了。如果持续捕获,必须有取消全局捕获。
-
Arkcontrol数据库云管平台
Arkcontrol是极数云舟独立自研的一套全面解决MySQL日常运维和集群管理的自动化平台,平台提供MySQL的集群管理、实例管理、监控备份、日常巡检、参数建议等等多种功能,同时提供对公有云数据库API的调用管理,帮助使用MySQL的企业或者用户提升工作效率,降低故障时间,提升数据安全性。
多样化产品支持:Arkcontrol支持官方版MySQL以及MySQL的各种分支版本,也支持MySQL的常见架构,例如传统的Master-Slave、Galera Cluster、Group Replication等等。同时Arkcontrol也支持Redis的运维,并计划逐步支持Oracle、SQL Server、HBase、MongoDB等数据库。
系统化资源管理:Arkcontrol统一管理主机和数据库资源,通过资源录入功能,实现自动侦测发现已有数据库集群及其拓扑结构,并对数据库实例和数据库集群统一管理。
平台化安装部署:Arkcontrol实现多种数据库和集群架构的一键式自动化部署,避免重复性操作和人工误操作,提升工作效率,保证部署的规范化和正确性。
定制化监控告警:Arkcontrol内置数据库日常巡检、以及定制化监控告警功能,实现各种告警阈值和告警通道的动态设置及巡检报告的格式化输出。  自动化备份恢复:Arkcontrol可平台化定制数据库备份策略,自动化完成备份任务;同时根据实际恢复需求,实现自动化数据恢复,保证数据安全。智能化查询分析:Arkcontrol提供自动化慢查询采集、统计和图表展示,并对查询语句给出智能化优化建议。
-
TMS运输管理系统
TMS(运输管理系统)是一个物流运输平台,它是供应链管理系统(SCM)的一部分。广义的TMS平台涉及面较广,不同企业的业务模式不一样。 运营方按照一定的运输规则处理,做这个规则处理的过程,一般称之为计划,计划的形式有多种,主要有拼单、拆单、规划线路图、地图合单等,然后再将计划好的这个订单分派给合适的承运方。 最常见的手段是拼单,又称零担运输。将多个货主订单合并拼成一个派车订单,一般规则的处理条件有:订单量、装载能力、价格、路线、发货时间、收货时间等。 计划的手段除零担集货外,还有大单拆分、长单分段等,主要目的来达到成本分摊的作用。计划的手段有智能计算,和人工处理+半自动计算。 承运方接受订单,并将订单分配给司机,由司机执行完成运输任务,这个阶段又称之为调度。运营方将计划的订单分配给承运方,生成最终的运输订单,它是运营方同下游承运方的唯一标识,这个凭证会关联到订单的跟踪监控和应付结算等功能。 基础资料的建立,对TMS的需求任务单和调度非常重要,只有建立了合作关系,才能在客户需求订单上选择到正确(有合作关系)的客户,在计划调度的时候才能匹配到正确(有合作关系)的承运方。 录入货主、承运方的信息,以便于后期订单的生成, 这些信息的维护可以保证每个订单都有归属客户,方便订单的管理。
-
SaaS系统
SaaS是一种通过Internet提供软件的模式,软件的开发、管理、部署都交给第三方,不需要关心技术问题,可以拿来就用,如今很多企业也都在开发SaaS系统。 从全球范围看,软件业的SaaS化已是大势所趋。传统软件厂商大多在推进云化、平台化,典型如Adobe、WPS、万兴;新兴厂商如Figma、墨刀、石墨文档等,则从创业之初就坚定走在云端。 可有意思的是,大家在内部会上听的是连连点头,但私下交流时却很难对SaaS说出个所以然;有人认为它等于ToB,有人认为它就是公有云,也有人认为它是通过浏览器访问使用、无需下载的应用。 起初我以为这只是个别的理解偏差。后来看了市面上的相关资讯和资料,并且与部分业内人士交流后,我发现原来不少人,包括部分科普者,对于SaaS的理解也存在相当的局限性;于是决定写篇文章,整理下目前大家在SaaS理解上的几个争议,以及自己对SaaS的一些观察和思考。 SaaS平台供应商将应用软件统一部署在自己的服务器上,客户可以根据工作实际需求,通过互联网向厂商定购所需的应用软件服务,按定购的服务多少和时间长短向厂商支付费用,并通过互联网获得SaaS平台供应商提供的服务。 简单翻译过来就是,服务器在云端,按照客户定购需求,通过网络提供应用软件服务的,都算是SaaS;比如大家看视频常用的优爱腾,存资源用的百度网盘、阿里云盘,办公必备的Office 365、Adobe CC,等等。 与SaaS软件相对的,是需要下载到本地运行的传统软件,典型如未转型前的Office和Abode;后者需要按版本购买,获取license(软件序列号)激活。 软件license在市场上进行买卖,本质是一种单纯的售卖关系,用户通过一次买断的方式获得传统软件的永久使用权;它区别于SaaS模式(普遍采取订阅付费),后者售卖的内容从软件license转变为服务,软件成为服务的载体。软件提供商与用户的关系,从一锤子买卖转变为长期服务关系。![0a8d89f9-a878-4a40-9a27-9575c9a5aa2a-image.png](https://upyfuntask.suwis.com/xnit.funtask.club/f73cce0c-fb3a-4450-ae81-f3e523f5cc54.png)