SEM经验谈之数据呈现小技巧

标签: SEM经验分享 搜索引擎营销 | 发表时间:2015-03-22 16:23 | 作者:蓝鲸
出处:http://bluewhale.cc

本篇文章来自我的朋友王硕,他在SEM领域沉浸多年。他将通过一系列文章与大家分享自己在SEM工作中获得的经验。如果你对他的文章感兴趣,或希望了解更多SEM的知识,又或对文章内容有任何疑问,请在本篇文章后留言。

王硕 2009年入行,有5年以上SEM从业经验,第一批通过百度中级认证的从业者。曾在多家知名大型互联网公司任SEM负责人,包括链家地产,百合网,搜狐畅游等。目前在某互联网金融公司任线上广告投放总负责人。对各搜索引擎的关键字广告和网盟等展示类广告的投放和优化工作拥有丰富的经验。

关于SEM的文章,大都在讲,如何搭建账户,如何选择关键词,如何出价等等。但这些并不是SEM工作的全部。即使这些做的都没有问题,在日常SEM工作中,我们仍然会遇到各种各样让我们棘手的困难。根据我这些年的从业经验,恰恰是这些优化之外的问题,带给我们的压力更大。所以,我的SEM文章,会抓住一些能够解决某个日常工作的痛点来写,希望大家在工作中遇到类似问题时,能更加稳妥的进行处理。比如,今天我们就来谈谈,给客户(对于甲方同学来说,老板就是你的客户)呈现数据时的一个小技巧。

大部分SEM优化师,给客户呈现投放数据时,都是把SEM整个的投放数据直接拿出来,例如下面的样子:

SEM1客户看到后,一目了然,知道10月20日当天投放总体是一个什么情况。但这样的数据呈现方法,是有隐患的。

我们都知道,SEM的关键词,主要分为,品牌词,竞品词,通用词等。这些词类的划分,本质上是面对的人群不一样。例如品牌词,都是已经知道这个品牌的人,一般来说,品牌词的点击率转化率都会较高,成本较低。竞品词,则是已经知道竞争对手品牌的人,一般竞品词的点击率较差,CPC和成本较高。通用词,是对我们的产品有需求,但没有明确品牌导向的人群,通用词的投放效果,是最考验我们优化师水平的。

既然,SEM不同的关键词对应了不同的人群,那么在不同的人群受到市场消息的刺激后,就会做出不一样的反应。这些就会体现在SEM的数据变化上。最常见的就是,客户做了电视广告。

如果客户做了电视广告,之后看到数据是这样的:

电视广告投放前与投放中效果对比

SEM2这时,当然是皆大欢喜。但是,电视广告那么贵,客户可能做了几个星期之后,不做了。那么,之后客户见到的的数据,就会是这样的:

电视广告投放中与投放后效果对比

SEM3这个时候,优化师就比较被动了。我曾经尝试过多种办法向客户解释数据下降的原因,但大多会被客户反驳或质疑,不可避免的降低客户对我们的信任感。例如,我直说是广告投放对SEM的影响,客户会说“你们效果的提升要全指着我们的广告,那你们的价值如何体现 ? ”;如果我说“这是由于新上的一部分词效果不稳定造成的(或者任何一种同类解释)”,客户就会问“何时能恢复之前的效果?”实际上,我们都很清楚,只要客户不再投放广告,无论如何也无法恢复到之前的效果了。随着客户耐心的消失,换优化师是早晚会发生的结局。

那么,怎么避免出现这种情况呢?我的经验是,从初次给客户呈现数据时,就将数据按人群进行拆分,品牌人群,通用人群,竞品人群,潜在人群,等等。并且,给客户进行形象的描述。比如,品牌人群,可以说“这是对我们的品牌已经有所认知的人,点击我们广告,产生的后续行为数据,对于这些人群我们要极力维护我们品牌正面的形象,精彩的广告语,美观的广告图是我们的有力武器”;对于通用词,可以说“这是需要我们的产品,但还不知道选择什么品牌的客户,这些客户往往会对第一次选择的品牌建立极强的品牌忠诚度,是我们极力要争取的客户,同样,他们也是我们的竞争对手极力争取的,所以我们要和敌人进行正面的厮杀,CPC就是我们的武器”。当客户听到这样的数据解读时,往往会很有代入感,也觉得你好专业,对你的信任感爆棚,之后,对你的各种解释,也会做出更加正面的判断。

如果你一直如此给客户呈现数据,那么当遇到前面说的情况时,客户看到的是品牌人群数据先好后坏,通用人群的数据是基本稳定的,那么大可以这样解释“随着我们各渠道广告的停播,对我们品牌产生认知的人群数量出现下降,导致品牌类人群的推广效果出现了下降,这是正常情况,投放前后的数据也说明线下广告对我们的品牌认知起到了预期中的促进作用”。这时客户如果质疑你的说法,大可拿通用词的数据来进行说明:“虽然针对品牌人群的推广随着广告停播出现了效果下降,但在通用人群这个战场上,我们的战绩依然保持了稳定。”

当然,以上只是我个人这些年做SEM工作的经验总结,也许有同学有更好的方法,欢迎大家讨论。

相关 [sem 经验 数据] 推荐:

SEM经验谈之数据呈现小技巧

- - 蓝鲸的网站分析笔记
本篇文章来自我的朋友王硕,他在SEM领域沉浸多年. 他将通过一系列文章与大家分享自己在SEM工作中获得的经验. 如果你对他的文章感兴趣,或希望了解更多SEM的知识,又或对文章内容有任何疑问,请在本篇文章后留言. 王硕 2009年入行,有5年以上SEM从业经验,第一批通过百度中级认证的从业者. 曾在多家知名大型互联网公司任SEM负责人,包括链家地产,百合网,搜狐畅游等.

京东商城SEM——seo策略全面解析

- - 互联网的那点事
这家号称最大的3C消费类电子及家电的B2C企业的确给了我不少惊喜,尤其在其详细的产品型号的关键词方面. 品牌关键词,如:苹果、联想、九阳、志高、富士、多普达等. 这类关键词京东的总体情况是SEO排名在前三页居多,也不乏有表现非常良好的页面,比如:. GREE在百度的11、13、29位的自然排名位置;志高(CHIGO)在1、9位的自然排名位置;.

SEM五大要点以及分析体会

- - 傻子-王跸西的blog-WangBiXi.com
不管是电商还是SEO做CPS,网络营销 永远是我辈学习和努力的根本,今小舟 列举了当前网络营销的五大要点,以及分析和体会. 1, 目标客户和营销内容,永远比营销方式重要. 体会:可不是嘛,做生意的根本就在目标客户,客户感兴趣的营销内容就是我们的亮点. 用个比喻的话,目标客户和营销内容是我们的“道”,而营销方式最多只能算是“术”一个是根本核心,一个是武器策略.

福特首席数据科学家谈三点大数据经验

- - IT经理网
数据已经成了福特公司的“燃油”,从产品设计到商业智能,从汽车部件到社交网络上的用户,福特公司每天需要处理海量且快速增长的数据. 今日福特公司首席数据官Michael Cavaetta做客Structure Show, 介绍了福特公司的大数据处理经验,归结为三点:. 数周前福特公司在北美国际汽车展上亮相的F-150皮卡车型采用了轻型铝材取代钢材提高燃油经济性.

Craigslist迁移20亿数据到MongoDB的经验与教训

- gOODiDEA - NoSQLFan
MongoDB正热火朝天,应用案例层出不穷,可能你也正跃跃欲试. 好吧,既然要试,那我们最好搞清楚可能遇到哪些困难,下面PPT就是一个很好的经验总结,下面PPT是Craigslist网站(可能是全球最大的分类清单网站)将其20亿数据迁移到MongoDB过程中遇到的问题及其经验,相信对每一个使用MongoDB的同学都会有所帮助.

linkedin 数据科学实习的5个经验总结

- - 冰火岛
这些可以使接下来的工作更加简单,结果更加可信. As a data scientist at LinkedIn, you have access to Petabytes of data (1 Petabyte as much data as is transferred when viewing HDTV for about 13.5 years).

关于海量数据处理分析的经验总结

- - 互联网分析沙龙
笔者在实际工作中,有幸接触到海量的数据处理问题,对其进行处理是一项艰巨而复杂的任务. 一、数据量过大,数据中什么情况都可能存在. 如果说有10条数据,那么大不了每条去逐一检查,人为处理,如果有上百条数据,也可以考虑,如果数据上到千万级别,甚至过亿,那不是手工能解决的了,必须通过工具或者程序进行处理,尤其海量的数据中,什么情况都可能存在,例如,数据中某处格式出了问题,尤其在程序处理时,前面还能正常处理,突然到了某个地方问题出现了,程序终止了.

学习笔记:Twitter核心数据类库团队的Hadoop优化经验

- - 博客 - 伯乐在线
此稿介绍了Twitter的核心数据类库团队,在使用Hadoop处理离线任务时,使用的性能分析方法,及由此发现的问题和优化手段,对如何使用JVM/HotSpot profile(-Xprof)分析Hadoop Job的方法调用开销、Hadoop配置对象的高开销、MapReduce阶段的排序中对象序列化/反序列的高开销问题及优化等给出了实际可操作的方案.

达观数据推荐系统和搜索引擎的经验技巧

- - 互联网 - ITeye博客
推荐系统和搜索引擎的关系达观陈运文. 从信息获取的角度来看,搜索和推荐是用户获取信息的两种主要手段. 无论在互联网上,还是在线下的场景里,搜索和推荐这两种方式都大量并存,那么推荐系统和搜索引擎这两个系统到底有什么关系. 本文作者有幸同时具有搜索引擎和推荐系统一线的技术产品开发经验,结合自己的实践经验来为大家阐述两者之间的关系、分享自己的体会(达观数据陈运文博士).

百万级运维经验一:Mongodb和Redis数据不能放在同一个服务器

- - CSDN博客系统运维推荐文章
一开始时,为了省服务器,把Mongodb和Redis放在一个服务器上. 网站每到高峰期都特别卡,还经常出现502. 找了很久的原因,发现硬盘的写数据很大,IOPS也很高,排查了很多原因都没找到. 然后再仔细研究监控,发现写硬盘的操作很有规律,每隔几分钟就有一次频繁的写硬盘,联想到Redis同步数据到硬盘的间隔就是几分钟,所以开始怀疑是Redis引起的.