手机号归属地查询速查
- 作者: 小策
- 来源: 神策网
- 2022-06-24 22:54
在营销推广工作中,电话是非常重要的一种沟通方式。并且,跟踪电话来源,可以完善广告优化闭环,提升电话的推广的效果,从而提升业绩。
对于营销推广来说,电话是很重要的沟通方式,特别是有些企业,在总业绩中,电话咨询占有不小的比例。
但电话来源的跟踪一直是个头疼的问题。
无法跟踪电话来源,广告的转化数据就存在缺失,优化闭环不完整,优化调整就不全面。
如果能够跟踪电话来源,就可以完善广告优化闭环,提升电话的推广的效果,从而提升业绩。
如何跟踪电源的来源渠道、计划、关键词、广告呢?有这么几个方法。
事件跟踪方式不同分析工具跟踪用户事件的原理大同小异,都是通过特定的JS命令,将指定的行为事件发送回分析工具,进行统计分析。
针对需要跟踪的行为,比如拨打电话、点击注册、提交表单等,在网页相应位置添加事件跟踪代码,当上述行为发生时,分析工具就可以记录下来,然后比对URL跟踪标记,从而知道是哪些渠道的流量产生的行为。
比如,某个项目希望访客添加微信,我们可以把复制微信号的行为作为转化目标。
因为基本上只做百度,所以选择百度统计作为分析工具,设置了复制行为的事件转化,并在网页添加事件跟踪代码代码:
结合百度搜索推广的展现、点击、消费数据,就可以分析不同计划、单元、关键词的转化效果:
如果是百度之外的渠道,百度统计中可以通过“指定广告跟踪”查看,但因为数据不互通,所以展现、点击、消费等数据还需要另外统计分析:
上图中左侧红框显示是“推广单元”,其实是推广计划,可能百度统计对UTM的兼容不是很好。
事件跟踪的优势是方便部署,给电话拨打按钮加段代码就可以跟踪到。
但是缺陷也很明显,无法判断访客是否真正呼出了电话。
所以这种方式统计到的电话拨打次数,会超过实际的电话接通数量,只能作为参考。
多个号码方式这种方式简单粗暴,就是办理很多电话号码,用于不同渠道的投放。
比如,电视、报纸、墙体、email……不同的渠道投放不同的号码,哪个号码有咨询,就是绑定的渠道带来的。
但这种方式对于网络营销就不是很适用。
发新闻稿、做外推,用这个方式还能勉强凑合,做竞价、信息流,就有些吃力了。
因为一家公司可能投放很多付费广告渠道,不同的渠道又有不同的计划、单元,需要大量的电话号码。
如果是搜索竞价,这种方式也很难追踪到具体的关键词。
而且,目前来看,国内申请大量电话号码也不现实。
所以这种方式只适用于渠道数量较少的公司。
网页回呼方式网页回呼有两种方式,一种是类似百度离线宝的“真·回呼”,一种是类似商务通的“假·回呼”。
百度离线宝回呼这种真·回呼的原理是,访客在网页输入自己的电话号码,回呼系统同时拨打访客和公司的电话,双方都接通后就可进行通话。
由于这种方式需要在网页添加一段代码,这段代码可以读取到用户的cookie文件,从而获取到访客的来源信息,将来源信息与电话对应,就确定了电话的来源渠道。
不过百度离线宝需要开通媒体追踪功能才能确定电话来源。另外访客不接听的话,也无法建立通话。
商务通的网页回呼这种网页回呼,其实是一个留言系统。用户在电话输入框填写电话、请求回呼后,生成一条留言信息。在线的客服看到留言中的电话后,进行回拨。
因为商务通能够记录对话、留言的来源网址,如果推广的URL添加了跟踪标记,就可以将电话和推广渠道进行对应。
两种方式各有利弊:离线宝、媒体追踪要花钱,但能实时回呼;商务通可能便宜点,但必须客服在线才能回呼。
但两种回呼方式都有同样的困境:访客对回呼功能的认识不足。
比如,经常遇到访客输入网页上的400电话,或者错误的号码,就是不了解这个功能,或者出于防备的心理故意输错。
两种方式在使用上也额外增加环节:填写电话。
直接拨打电话是最方便的,但是网页回呼却要让访客自己输入电话号码,增加了转化流程。
如果网页有电话拨打按钮,或者400电话,访客有很大的概率直接拨打电话,而不使用回呼功能。
所以这种方式只能是目前勉强能用的选择。
动态电话方式这种方式在国外十分流行,原理也十分简单。
在网页添加一段代码,页面就会显示一个动态的电话号码。当访客拨打电话,系统将电话号码和访客来源匹配,从而获取电话的来源数据。
为了保证访客能正常拨打电话,电话号码库中要保证一定数量的号码。
比如网站访问高峰时,同时在线的访客有100人,最多可能要准备100个不同的号码,防止这100个访客同时拨打电话。
当然也可以按渠道来分配电话号码。
上图是国外某网站的对动态电话跟踪的介绍图片,帮助大家理解。
当访客拨打被分配的号码时,电话追踪系统能够记录到电话的拨打时间、地理位置、产生拨打的页面,以及来源渠道、搜索词等信息。
如果推广的URL添加了跟踪标记,还能将电话来源精确到投放的关键词。
如果利用Google Analytics的虚拟页面来记录电话拨打行为,就可以直接使用Google Analytics来分析Adwords或者其他广告渠道的电话拨打效果。
除了在自己公司的网站使用动态电话,在其他网站、email、甚至线下媒体也可以使用动态电话确定来源。
比如,在新浪、网易、搜狐等网站投放不同的包含动态电话的广告,就可以区分不同的网站效果。
比如,在报纸上投放动态电话和一个包含跟踪标记的短连接/二维码,访客可能直接拨打电话,也可能扫码浏览网页后拨打网页上的电话,我们都可以追踪到电话来源。
可以说,动态电话就是将前面多个电话的方式给系统化、数字化了,而且大幅降低了电话号码申请、维护的费用、工作量,提升了电话追踪的精确度。
只可惜,国内目前好像还无法使用这样的业务。
动态ID的方式传统的确定电话来源的方式,就是询问。比如询问客户是搜索什么词进到的网站、从哪看到的电话等等。
但询问的方式不太友好,特别是如果问的问题很多,又和客户想要了解的业务无关,客户可能一生气就挂电话了。
所以想要通过询问的方式确定来源,问题数量越少越好,问题越简单越好。
动态ID就是一个解决方案。原理如下:
给每个访客生成一个独立的ID,并显示在网页上。当接到电话时,客服询问访客的ID,根据ID就可确定来源渠道。
当然,网站上的电话最好和其他渠道区分开,这样就不用问访客是不是从网站上看到的电话。
别看一个ID很简单,却能有效确定电话的来源,而且几乎不影响客户的体验。
那么,怎么实现这个功能呢?
很多网站程序后台都有一个在线访客的页面,没有的话,可以找技术开发一个,比如下面这样的:
或者在服务器安装一些开源的、能够显示实时访客的网站分析工具,进行二次开发。
然后对在线访客页面进行修改,能够显示访客的来源网址、初始访问网址、动态ID就可以了。
动态ID可以存到cookie里,也可以存到一个临时的数据表中,只要能读取到即可。
客服上班后打开在线访客页面,就可以看到在线访客的来源渠道和动态ID。有电话进来时,询问ID,就确定了电话的来源。
如果嫌自己开发的太简陋,可以使用现成的,目前国内有公司提供这个功能,比如Udesk。
Udesk是给访客生成一个4位数的ID,他们叫做访客ID。
上图是Udesk官网的截图,这次分给我的访客ID是“5343”,这个ID也保存在cookies中。
无论我如何刷新,这个ID都不会变,直到系统判断此次访问结束。
因为Udesk本身就是客服系统,通过cookies能够获取到访客来源、访问信息。所以如果我拨打了Udesk的客服电话,并告知这个ID,Udesk客服在系统中输入这个ID,就可以将我的电话关联到来源渠道。
除了上述5种方式,还有一种苦力的方式:
如果每天接听的电话数量比较少,而且推广的流量也很少,竞价人员再愿意出点力辛苦下的话,每当接到电话,就通过查询访问时间、访客地域、电话拨打时间、主叫号码归属地等,将电话和推广的关键词对应起来。
但流量稍微大一点,就会耗费大量时间,也未必准确,特别是访客搜索进到A页面,浏览多个产品后,对B页面的内容产生兴趣,拨打电话。
所以现在应该没有人用这种方式了吧?
无法获取电话来源数据怎么办因为种种原因,无法获取到电话来源数据怎么办?
可以根据以往的数据,计算出电话线索比例,反推各渠道、计划的电话数量。
能这么做的原因,是因为人群趋同。
400电话看人群行为趋同有段时间400电话数量特别少,根本不是正常的比例。账户检查了、页面检查了、客服检查了,都没有问题。查下400后台,才发现有近百个电话的状态是未接听。
于是进行测试,拨打400电话,听筒里能听到振铃,但是座机、手机都跟死机一样,不动、不响。
直接拨打座机号、手机号,座机、手机就立马撒欢的动起来、叫起来。
系统出问题,竞价很无奈啊。
对了,我们把没接通400电话的主叫号码都下载下来后,打算分给销售联系。为了防止号码重复,和那段时间的咨询线索、留言线索进行了对比,结果,只有4个客户,在电话打不通之后,通过在线咨询、留言的方式留了电话。
这种行为趋同,导致某个细分行业的客户,各种沟通方式的比例是稳定的。因为一个人群内,有固定比例的人喜欢拨打电话,其他的人喜欢在线咨询、留言。
所以电话在所有线索中的比例,在大的时间周期内,应该是稳定在一个区间。
比如,根据统计,过去电话的比例在30~40%之间,在不变更创意、页面、客服话术等等前提下,这个比例会是稳定的。
那么每当渠道咨询、留言产生70个线索,并且有30个以上的电话找不到来源时,我们可以把30个电话当做是渠道推广产生的。
但是,如果电话的比例很大,对话咨询的比例很小,就不能采用这种方式。
这种方式,是实在无法确定来源时的折中方法。
不过,即使再困难,也应该至少使用上述5种方式中的一种来跟踪电话转化。
即使没钱、没人,网站总是做好的,百度统计、谷歌分析也是免费的,通过事件跟踪记录电话事件又不花钱,拿来作参考,也比瞎猜强。
本文由 @小曹同学 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议