产品专栏 | 灵动分析2.0开创埋点新时代

2018年8月TalkingData正式发布了移动运营平台5.0私有化部署版本,同时也发布了其中的一款无代码埋点利器——灵动分析2.0。

从连接系统到看数据全流程迅速响应——

5 秒  内连接系统

10秒 内完成一个埋点事件

30秒 拉取配置单上报数据

实时  查看报表数据

在灵动分析2.0时代,TalkingData最大程度的简化操作,降低业务与研发的沟通成本、学习成本,提高运营效率,让业务人员能够聚焦于数据。运营人员既不用读懂复杂的SDK集成文档,也不需要向研发解释埋点的业务逻辑,系统能够自动识别可埋点的元素,且支持事件参数埋点,全流程可视化,开创了国内可视化事件参数埋点的先河。

灵动分析本次迭代带来了7大亮点:

1、扫码进入5秒内连接系统

从扫码到连接系统只需5秒钟快速响应,取代旧版摇一摇,解决多人同时摇动抢占连接系统资源的尴尬,解决摇动多次连接不上或响应慢的烦恼。

2、支持多种模式的移动应用一站式埋点  

无论是混合模式app、原生app还是H5,都支持在PC端完成一站式埋点。

3、3种埋点方式 满足业务小姐姐的分析灵感

支持当前元素、当前位置、同类元素3种埋点方式,业务小姐姐可以根据分析需求选择适合的埋点方式,且从埋点到看数据全流程快速响应:

※ 10秒 内完成一个埋点事件

※ 30秒 拉取配置单上报数据

※ 实时 查看报表数据。

4、灵活添加参数 轻轻一点即可指哪采哪

国内首家独创的可视化事件参数埋点,业内尚未有任何一家具备此能力并与之匹敌。

例如,应用界面上的商品价格、商品类型等特定数据,只需拖动鼠标,系统就会智能识别可圈选元素,轻轻一点即可采集:

  • 一方面满足前端业务人员“指哪采哪”的业务分析需求;
  • 另一方面可以让前端非常动态的处理需求变化,而无需开发人员介入。

解决了前后端沟通成本,而且全流程可视化,业务人员可随时完成对各种数据的监控和追踪需求。

5、易测试 数据追踪无遗漏

可视化的数据点测试。您只需在测试设备中轻点各项元素,即可在实时界面中查看到数据产生,从此让数据验证变得异常简单。

6、零代码 解放IT小哥哥的双手 

灵动分析真正做到“零开发、零代码、云配置”架构,颠覆了传统应用统计使用方式,彻底解放了研发人员,无需再为应付琐碎的数据跟踪需求而苦恼,真正把研发时间都用到做好产品上。

7、免更新 自动识别埋点元素

灵动分析可以免去应用更新的种种麻烦,自动识别埋点元素。业务人员只需圈圈点点界面元素来追加数据点,实时生效,无需应用升级


灵动分析+个别事件代码埋点组合出击

综上所述,如果灵动分析已经帮助您解决了80%的埋点需求,那么这里仍建议您采用灵动分析+个别事件代码埋点的方式组合出击,毕竟不是所有用户的交互行为都适用于灵动分析。例如,用户上滑屏幕时内容瀑布流的底部载入新的内容,这种交互用户可以一直进行下去,但没有一个明确的监测点位置,在可视化事件监测设置的界面上找不到这类交互,但这种情况用代码埋点就很容易解决。

因此,采用灵动+代码埋点结合的方式,既能快速满足日常基础数据的收集需求,又能针对个别事件进行多维的数据采集与挖掘,达到整体兼顾数据收集的效率、平衡开发资源、提升运营效率的目标。

TalkingData高铎:数据智能驱动数字经济

8月16日,由IDG主办的以“新时代·数字经济”为主题的“iWorld数字世界博览会”在成都拉开帷幕。TalkingData 副总裁高铎先生在此次峰会上发表了《数据智能驱动数字经济》主题演讲,并与现场嘉宾们分享了最新的行业观点。

TalkingData 副总裁高铎‍

三年前高铎先生提出过一个观点,大家都在讲大数据,但是由于数据的不完备性,大部分企业使用的都是“小数据”;去年在成都的大数据会议上,提出了三个数据孤岛群概念,就是运营商、政府和头部互联网企业(如BAT)的三大数据孤岛群各自难以打通。通过TalkingData几年来在大数据领域的实践,我们认为,大数据开始从概念走向具体应用,同样的在数据治理和数据应用层面,如果能解决好这几个问题,“开放”、“连接”、“智能”和“安全”,那么数据智能将会强烈推动数字经济的发展。

‍建立开放数据的前提认知到数据割裂性‍

  • 第一, 移动应用层数据的割裂性,我们每个人都拥有一台智能手机,手机上少则装了十几款APP,多则上百款,每个APP的数据是割裂的,因为它属于不同的企业。
  • 第二, 跨屏数据的割裂性,我们每个人有4个屏幕,电视、电脑、手机以及车机屏幕,它们相互间是割裂的,它们属于不同的系统,甚至不同的产业。
  • 第三, 场景数据的割裂性,我们在商场里面,在会场,在不同的消费场景里面,都在贡献自己的数据,但它隶属于不同的消费场景。

总之,我们每个人,每时每刻都在生产数据,但是由于数据生产出去之后,分属于不同的企业,不同的机构,不同的场景。它很难关联,很难整合起来给我们提供更好的服务,这就是我们倡议要建立一个开放数据环境的前提。

如何开放数据?数字化、数据在线、数据实时与安全的标准开放协议

放数据,需理解四个概念:

  • 第一, 业务真正是数字化的。原因很简单,如果不是数字化的就没有了大数据的来源。
  • 第二, 业务数据是在线的。数据只有在线,对业务的了解才能全面深刻及时。
  • 第三, 数据是实时更新的,我们想做决策的时候,需要数字化的业务是可以实时回传到调度中心,运营中心以或者控制中心,以进行快速决策。
  • 第四, 开放数据必须建立并遵循安全标准的开放协议。

如何连接数据?ID稳定性、数据可连接、安全机制

大多企业都有这样一个观点:“我有数据,这是我的资产”,但都有一个特点,就是都不愿意拿出去用,却觉得拥有无限财富。真的如此吗?其实并不是,没有应用场景的数据就是一堆字节和服务器,只是公司的成本罢了。但是,如果放出去又觉得不值得、价值低估了、安全有风险了等等。所以我们提一个概念叫数据连接。一旦能建立连接,就可以做联合建模、做深度数据挖掘,实现业务闭环,又避免了企业的各种担忧和敝帚自珍。

数据连接要求:

  • 首先,拥有稳定加密的ID。
  • 第二,数据是可连接的。
  • 第三,健全的安全机制,要保证所有设备信息的安全使用,保证企业业务数据的安全使用。

如何打造 数据智能?数据模型、数据产品、数据场景、数据闭环反馈

在保证数据安全开放和可连接的基础上,我们才能谈数据智能。比如客户要对业务流程进行优化,可以推出针对性的数据模型进行决策;客户有新客获取及老客回流等业务需求,可以推出以目标群体数据画像为主的产品帮助客户营销;在特殊的应用场景中,如风控领域,可以帮助客户更好的区分坏人,更好的对好人的授信额度进行细化。

这里,有一个非常关键的点,我们要认识到,数据的使用是一个闭环,数据应用的过程是螺旋上升的过程。当认识到这一点,在利用数据解决问题的时候,我们才会有耐心,才真正愿意在算法模型上做投入,而不是抱着数据是万能的心思幻想着使用一下就可以毕其功于一役。

‍数据安全贯穿数据生命周期‍

随着大数据的发展,一方面我们享受到了带来种种好处,另一方面也让普通用户有很多质疑,大数据真的安全吗?对我们的隐私做到足够好的保护了吗?

所以我们使用大数据的时候必须要具备安全意识和并落到具体应用的每个环节。

在数据收集端,要收集合规合法的数据;在数据传输端,要做到多层加密;在数据加工端,有相应的脱敏加工机制,和分权加工机制与管理机制;在应用端,也要有相应的安全技术处理,做到各个角度都是不可逆的,不可溯源的,但又是能对业务起到良性帮助的。

‍未来的数字经济图景‍

总结一下,提到未来的数字经济,我们认为,:

首先数据应该是实时在线的,且能够做批量规模化处理,同时在不同的数据源之间有开放安全的标准协议;其次,连接层面有稳定的ID和安全机制,在AI算法上,有能解决具体业务问题的产品或者模型;

  • 再次,应用场景是闭环、且螺旋上升的;
  • 第一, 安全机制贯穿始终,如何强调都不为过。
  • 这是我们从数据和技术层面理解的未来数字经济图景。

产品专栏丨移动运营平台5.0全新改版发布

近日,TalkingData正式发布移动运营平台5.0,本文将从产品的角度回顾和分享TalkingData移动运营平台从2.0到5.0的经验和思考。

一、移动运营领域的经验推动改版

  • 超过6年以上移动端企业级应用的经验
  • 服务用户平均日活>100万的企业级应用
  • 服务金融机构头部用户>60%的企业级应用

TalkingData从2012年就开始尝试大型机构的移动端运营,如今已经保持了行业相对领先的优势,俗话说得好,春江水暖鸭先知,移动运营平台在头部市场这么多年的经验可以帮助我们更好地理解企业需求以及洞察需求的变化。

移动运营的三个阶段:

  • Facts:获取更多更细颗粒度的数据
  • Indication:更快的获取到Facts中间的风险和机会
  • Take Action:尽快地消化数据、规避风险或者抓住商机形成业务结果

在移动运营2.0时代,我们帮助企业获取更多的行为数据补充业务结果,用来解决数据的几个问题:一是时效问题,二是传统企业只能看到结果看不到过程的问题。

在移动运营3.0时代,TalkingData推出“3A3R”理论,帮助企业更好地规整展现数据,简单来说就是:如何看报表。

在移动运营4.0时代,企业的需求逐步从Facts向Indication转型。数据越来越多,颗粒度越来越小,而挖掘机会和规避风险的成本越来越高,于是TalkingData提出无代码埋点帮助业务更快的获取所需数据,推出自定义报表让业务人员按需配置及呈现。

而移动运营5.0时代,是Insight To Action时代。企业越来越关心如何消费数据和ROI,而不是将分析结果看过且过。TalkingData多年来的行业积累、埋点策略和指标体系也逐渐凸显出价值。

因此推动了移动运营平台5.0的全新改版——从统计分析到分析运营的升级!

二、TalkingData移动运营平台5.0做了什么

前文叙述了移动运营的3个阶段:Facts、Indication、Action。接下来,回到运营的本质看移动运营平台5.0都有哪些改进和升级。

移动运营平台5.0的设计框架UIMA:

  • User:强大的人群定义和画像能力
  • Identification:移动运营的场景核心是主路径的定义和识别
  • Marketing:碎片化的交互模式,需要可碎片化的场景触发式营销
  • Analytics:更灵活的采集,更有价值的模板,更方便的ROI归因
  • User: 强大的人群定义和画像能力

首先,来谈下对于用户的定义。移动统计分析平台5.0提供了对于用户的两种定义和选择。传统金融行业的实际业务场景是强账户的登录和交易,因此强账户的业务形态是多平台客户的对应问题。对于电商和零售行业而言,可能存在着多人同时使用一个账号的情况,例如一个家庭只有一个电商类应用的账号,通过账户很难定位用户偏好,因此通过区分行为发生的设备可以更好地定义用户属性和行为特征。

此外,传统的人群分群方式是定义用户属性,但在移动的应用场景中还要关注用户的行为。例如分析信用卡用户可以根据用户的持卡等级以及用户浏览过的分期产品,去定义不同的目标人群,并运用平台的场景触达的能力,编排目标人群的营销策略(Marketing部分会进行详细介绍)。

  • Identification:移动运营的场景核心是主路径的定义和识别

移动运营5.0平台提供了基于用户POI的分析,通过同比和环比的快速切换,即可看到用户分布变化。另外,对于新零售和传统金融机构网点转型的需求,结合TalkingData庞大的移动设备覆盖量,后续将提供更多基于“地图”的分析模块。

至于场景洞察漏斗的分析,将分为两个场景的定义方式:一是主动的场景转化漏斗,二是智能路径。由于现在的应用交互大多仍是界面式交互:一个点击一个页面,因此天然会形成一个路径(游戏除外)。有些产品会设计一些路径,但其实用户可能并没有按照我们的设计去产生行为。

高级转化漏斗可以帮助运营人员观察所涉及的路径的转化情况:有多少用户走了这些路径、转化率情况等。移动运营5.0平台提供了页面和事件混排的转化漏斗,可以一个事件一个页面的去设计漏斗,并且支持漏损人群的下钻,详细分析漏损人群的特征。

如果用户没有走设计好的路径,我们就需要去设计智能路径。设置好页面或者事件的起始点,系统会计算所有用户走过的全路径,并且通过人数、转化率、步骤数量,提示运营人员应该如何优化页面逻辑和页面话术引导。

  • Marketing:碎片化的交互模式,需要可碎片化的场景触发式营销

当完成了对目标用户的定义和对于场景的分析洞察后,会发现很多风险和机会,而移动运营的环境决定了用户在平台上的时间是碎片化的,这是常规触达和运营抓不住的机会。此时可以依靠可视化营销任务编排的能力去实现场景触发式营销,抓住每一次与用户的最好的沟通机会。并且系统会自动记录每一次触达后用户的反馈和对指标的贡献,自然形成数据闭环和业务闭环来优化策略,亦或是为下一次大型营销活动提供基础参照。

  • Analytics:更灵活的采集,更有价值的模板,更方便的ROI归因

基础分析模块,基于多年的企业服务经验及用户分析,移动运营平台将曾经260多个指标精简到了58个,这些核心指标是业务和运营人员经常查看或已经进入业务KPI范畴的。而剩下的指标分析千变万化,因此提供了自定义报表的功能以便业务人员自行梳理业务分析逻辑;此外,还提供TalkingData多年行业服务所积累下来的分析模板,助力业务分析,并将分析逻辑和结果更快的分享到团队内部进行反馈。

在私有化版本的移动运营平台5.0中,同样新增了小程序的分析模块。在社交时代背景下,app的分享目前是受到限制的,但我们可以很容易分享一个小程序或H5。并且,小程序、H5和app之间可以相互调用的趋势已经十分明显。这样,就可以通过分享一个小程序来吸引用户下载一个更稳定和丰富功能的app。

最后,在技术人员不断的技术攻关下,移动运营平台5.0完成了也许是史上最强的无代码埋点。运营人员既不用读懂复杂的SDK集成文档,也不用去理解某个元素是否可以埋点。系统能够自动识别可埋点的元素,并且可视化埋点支持参数的上报,帮助获取“订单金额”、“产品分类”、“产品名称”、“ 交易类型”、“ 交易方式”等等一系列的相关事件的采集。平台还提供“当前元素”、“当前位置”和“同类元素”的采集逻辑,降低了手工埋点的重复性工作。另外,无论是app、h5还是混合模式,都支持在PC端完成一站式埋点,设置足够丰富的参数和埋点逻辑。

三、移动运营平台未来会做什么

看到这里,您可能会问TalkingData移动运营平台未来的发展方向在哪里。我们依然从移动运营的3个阶段来看:

  • Facts: TalkingData本质是大数据公司,我们将逐步输入TalkingData移动端行为数据的绝对优势,帮助企业还原用户画像、洞察潜在价值用户。
  • Indication:挖掘机会和规避风险是有成本的,通过同行业跨企业的经验积累,逐步形成基于模型和规则的预测预警体系。
  • Take action:更多的触达平台和能力对接。

新功能|TalkingData推出线下推广监测服务

随着线上流量成本升高和红利消退,商家们着眼于线下流量挖掘。在线下推广场景中,商家多以扫描二维码的方式作为入口,但此方式无法识别设备ID用于后续归因进而评估营销效果。

线下推广中,依旧被多数商家应用的传统匹配监测逻辑,在多名客户使用同WiFi网络环境或扫码与下载使用不同网络环境的情况下误差率较高,极易因统计误差造成业务人员与商家出现纠纷。

Markdown

为使商家能够精准统计不同业务人员、不同商圈门店的拉新引流效果,TalkingData打破传统归因逻辑,推出了使线下推广统计更精准、商家管理更便捷、效果点更精细,基于注册行为精准匹配方式为归因逻辑的线下推广监测服务。

TalkingData Ad Tracking线下推广监测服务支持以下功能

  • 推广管理者可批量生成推广二维码,实时监测不同实体门店、不同业务人员的推广效果;
  • 推广二维码由推广管理者统一制作后自上而下逐一发放,同时也支持业务人员/实体门店自下而上申请认领,推广管理者可结合场景自由选择;
  • 支持Html5、WeApp、Android和iOS四大平台线下推广监测;
  • Android和iOS多平台推广时,基于EasyLink提供一码多平台智能识别解决方案;

TalkingData Ad Tracking线下推广监测服务适用场景更多元

  • 多商圈实体店推广

此类线下推广,可由推广管理者统一生成推广码,下发至各实体店。待各门店信息完善后,TalkingData Ad Tracking线下推广监测功能将新增数据及其后续转化行为精准归因至各门店,便于推广管理者对各门店指标横向对比和推广优化;

  • 多业务人员地推拉新

在此类场景中,业务人员数量较多、人员分散,业务人员拉新的质和量也与其业绩相关。为了便于推广管理者对业务人员的业绩统计和快速人码合一,TalkingData Ad Tracking线下推广监测功能,支持业务人员通过填写推广管理者提供的短链去完善个人信息,进而生成与业务人员相对应的推广二维码。

业务人员完成推广拉新后,推广管理者可通过TalkingData Ad Tracking后台,查看各业务人员带来新增的质与量,帮助推广管理者对业务员业绩和新增数据进行结算与评估。

如果您存在以下困境,推荐您使用TalkingData Ad Tracking线下推广监测服务

  • 无法准确评判推广业绩;
  • 无法获得线下推广后新增转化的后续行为数据;
  • 多门店/业务员推广统计效果不佳,无精准数据优化推广和完善策略;
  • 同一活动Android和IOS多平台推广,无法二码合一;

以上困境只要有一个与您相关,那么深度了解和使用TalkingData AdTracking线下推广监测服务,就一定会对您有所帮助!

目前,TalkingData Ad Tracking线下推广监测服务已正式上线,开发者可以登录TalkingData Ad Tracking平台了解该服务的更多特点与具体功能。点击即刻申请试用,更多线下推广监测场景应用期待您的发现。

T11 2018数据智能峰会完整注册流程

T11 2018马上就要开始啦,相信很多小伙伴都想问,该如何注册参会呢?本文就教给大家! PC端注册流程

1、复制下方活动链接,并在浏览器中打开

http://www.huodongxing.com/event/1451528267400

2、 点击“我要参加”,选择对应的票种及数量,如有优惠码可进行输入

Markdown

3、点击“使用”进行优惠码验证,点击“我要参加”,验证联系方式(如无优惠码,直接点击“我要参加”,验证联系方式)

Markdown

4、填写报名表单,点击“提交”,进行付款

Markdown

移动端注册流程

1、点击文末“阅读原文”

2、如有优惠码可点击“我有优惠码”进行输入

Markdown

3、点击“确认”进行优惠码验证,点击“立即报名”(如无优惠码,直接点击“立即报名”)

Markdown

关于发票

购票发票(增值税普通发票)将于活动结束后10个工作日内邮寄,开票信息及邮寄信息请发邮件至:T112018@tendcloud.com 注:需附订单截图、预定人姓名及订单号

好啦,以上就是 T11 2018的注册流程,小伙伴们,我们9月11号见!偷偷地告诉你们,后面的文章或互动活动中,小编会发放优惠码和T11门票哟,请持续关注TalkingData公众号!

T11 2018报名参会,请点击

技术专栏 | 集合管道模式(下)

​前一篇文章中,我们了解了集合管道:集合管道是一种编程模式,将一些计算转化为一系列操作,通常情况下每个操作的输出结果是一个集合,同时该结果作为下一个操作的输入,常见的操作主要有filter、map和reduce。,今天我们继续了解集合管道模式的定义等。

二、定义

我认为集合管道是一种指导我们如何模块化和构建软件的模式。和多数模式一样,它经常出现在各种场景中,虽然对此我们习以为常,但是这种模式却别具一格。模式可以解决特定的设计问题,帮助设计者将新的设计建立在以往工作的基础上,复用以往成功的设计方案。

集合管道展示了一系列彼此间传递集合的操作,这些操作的输入输出都是集合,但是其中不包括终端操作,因为终端操作只会输出单个结果。个别的操作可能非常简单,但是你可以使用各种简单操作构造复杂的行为,想象一下现实世界中纵横交错的管道。

集合管道是管道过滤器模式的一个特例,管道过滤器中的过滤相当于集合管道中的操作,之所以没有使用过滤这个词语,因为过滤是一种常用的管道操作名称。从另一个角度看,集合管道是一种组成高阶函数的特殊方式,其中涉及的所有函数均作用于某种形式的数据结构,该模式没有确切的名称,需要使用一个新的术语。

操作彼此间传递的信息在不同的环境中有着不同的形式:

  • Unix 中集合是一个由多行文本组成的文件,各种值通过空格连接组成了其中的行,每个值具体表示的含义依赖于行中的排序。管道操作符可以将某个操作的输出重定向到下个操作的输入,集合由管道操作符组成,操作在 Unix 中表示进程。
  • 在面向对象程序中集合用集合类表示,例如 listarray set 等。集合中的每个元素都是对象,对象可以是普通类或集合类的实例。操作是集合类本身(或基类)中定义的各种方法,可以由方法链组成。
  • 在函数式语言中集合与面向对象语言有些类似,集合元素可以定义复杂的层次结构,操作是函数,可以通过嵌套或者使用形成线性表示的运算符组成,例如 Clojure 的箭头运算符。

这种模式也会出现在其它地方。当关系模型首次定义时,其假定所有数据都表示为数学上的关系,就是说n个集合的笛卡儿积的一个子集,数据可以通过关系演算和关系代数的一种方式来操作,你可以将其视作一个集合管道,操作中产生的中间集合被约束为关系。SQL最初作为关系数据库的标准语言而提出,而在实际上总是违背它。所以SQL DBMS实际上不是真正的RDBMS,并且当前ISO SQL标准不提及关系模型或者使用关系术语或概念,SQL使用了一种类似于推导的方式(稍后我会讨论)。

这样一系列转换的概念是软件构建中常见的方法,这也是管道过滤器模式的设计意图。编译器工作原理相似,将源码转换为语法树,途经各种优化,最后输出目标代码。 关于集合管道的区别:各阶段公用的数据结构是集合,最后限定一组特定的公共管道操作。

三、探索更多管道和操作之 map 和 reduce

到目前为止,涉及的是一些常用的管道操作,接下来通过 Ruby 事例代码,让我们来探索更多的操作。诚然使用其它支持该模式的语言,也会构造相同形式的管道。

统计单词总数(map 和 reduce)

通过统计所有文章单词总数的例子,让我来介绍下两个最重要的管道操作。

第一个 map使用给定的 lambda 表达式,作用于输入集合的每个元素,将 lambda 表达式结果以集合的方式返回。

[1, 2, 3].map{|i| i * i} # => [1, 4, 9]

通过使用 map 将文章列表转换为每篇文章单词总数列表。

第二个 reduce输入集合经过累计运算,最终输出单个结果。具有类似功能的任何函数都可以称作 ReductionReduction 在集合管道中总是以终结者的身份最后登场。通常情况下,可以使用两个入参的 lambda 表达式来定义 Ruby 中的 reduce 函数,一个入参是集合元素,一个是累加器。 reduce 的过程中,使用 lambda 表达式作用于每个元素,累加器会累计每次 lambda 的返回结果。接下来你可以这样求和:

[1, 2, 3].reduce {|acc, each| acc + each} # => 6

之后使用 map reduce 构造两步操作的管道来统计单词总数。

some_articles
  .map{|a| a.words}
  .reduce {|acc, w| acc + w}

第一步使用 map 将文章列表转换为每篇文章单词数列表,第二步使用 reduce 累计求和。

在这点上,值得一提的是管道上的操作你可以使用不同的方式定义,上面使用的是 lambda其实仅使用函数名称也是可以的,例如在 Clojure 中:

(->> (articles) 
     (map :words) 
     (reduce +))

该场景中,你只需要关注函数名称,对于 Ruby 也可以使用同样的风格:

some_articles 
    .map(&:words) 
    .reduce(:+)

通常情况下使用函数名称看上去更精炼,但是你会受限于函数的声明和调用方式。lambdas 可以提供更大的灵活性,但是你需要了解更多的语法。关于使用何种语言构造管道,如果 Ruby,我倾向于使用 lambda,如果 Clojure,则是函数名称。具体使用何种方式,你可以自由选择。

四、探索更多管道和操作之 group-by

统计每种类型的文章数(group-by)


接下来我们会统计每种类型的文章数,依据统计结果输出的形式,需要使用一个键是类型值是文章数的 hashmap

为了解决这个问题,首先我们需要根据类型对所有文章进行分组,这里使用的集合操作就是 group-by,通过使用该操作,会将所有元素射到 hash 中,而索引值依据在此元素上执行给定代码的返回结果。 让我们来看看具体使用的细节:

some_articles
  .group_by {|a| a.type}

然后需要统计每种类型下的文章数。你很可能这样认为,不就是一个简单的 map 操作吗?但实则不然,因为这里需要返回两种维度:分组和数量。这和我们之前介绍 map 的例子有些许联系,但是此时需要使用 group-by 输出 hashmap。

想想开篇中 Unix 的命令行,这个问题在 Unix 中是很常见。集合通常以 list 形式出现,但有时却是 hash,有时候需要在二者之间来回转换。有个取巧的做法是将 hash 视作键值对列表,其中键值对是一种独立结构。关于如何定义 hash 每种语言略有差异,但通常是这样:[key, value]。

Ruby 提供了 to_h 方法可以将数组集合转为 hash

some_articles
  .group_by {|a| a.type}
  .map {|pair| [pair[0], pair[1].size]}
  .to_h

在管道中 list hash 经常这样互转,但是访问 hash 却需要使用数组下标的方式访问,多少有些怪异, Ruby 可以将其解构为两个独立的变量:

some_articles
  .group_by {|a| a.type}
  .map {|key, value| [key, value.size ]}
  .to_h

在函数式编程语言中解构是一种常见的技术,但是传递这些 list-of-hash 数据结构性能上势必会有所损耗。Ruby 的解构语法非常简单,而且足以达到这个简单目的。

同样 Clojure 更是如此:

(->> (articles)
     (group-by :type)
     (map (fn [[k v]] [k (count v)]))
     (into {}))

简明数据科学第九部分:回归模型的相互作用和局限性

作者丨Pradeep Menon

原文丨https://datascientia.blog/2017/08/27/dss-p9-interactions/

译者丨TalkingData 张永超

编者按:

此篇文章结束后,简明数据科学系列算作一个阶段性的结束。虽然数据科学不止这么写内容,但是“温故而知新”,打算回顾一下之前的内容并加以练习,以加深相关概念和内容的理解。什么时候继续进行简明数据科学的内容更新,时间待定。

在之前的文章中,我们讨论了回归模型,费尔南多已经建立了一个多元回归模型,该模型的具体形式如下:

价格 = -55089.98 + 87.34 x 发动机大小 + 60.93 x 马力 + 770.42 x 宽度

该模型通过发动机大小、马力和宽度来预测或者估算汽车的价格。回想之前的内容,多变量回归模型是假定了预测因子是相互独立的,即发动机大小、马力和宽度是不相关的,独立的。但是在实际中,变量之间相互独立的情况很少,如果马力,发动机大小和宽度之间存在关系,该怎么办?这些关系可以模拟吗?

在本篇内容中,将解决这些问题,并解释相互作用的相关概念。

概述

预测因子之间相互独立意味着如果一个预测因子发生了变化,那么目标也会产生影响。这种影响与其他预测因子的存在和变化无关,目标和预测因子之间的关系是相加的、线性的。例如费尔南多的方程式:

价格 = -55089.98 + 87.34 x 发动机大小 + 60.93 x 马力 + 770.42 x 宽度

如果以发动机大小为标准,那么改变一个单位的发动机大小,汽车的价格变化87.34。而这种解释并没有考虑汽车的马力和宽度与发动机大小之间的联系。

难道汽车越来越大,发动机越来越大吗?

根据上述,费尔南多创建了一个全新的模型,其表达形式如下:

价格 = β0 + β1.发动机大小 + β2.马力 + β3.宽度 + β4.(发动机大小.宽度)

第三个预测因子捕获发动机大小和车辆宽度之间的关系,这第三个预测因子被称为交互项。其中 β1.发动机大小 + β3.宽度 称为主要项。发动机大小x宽度为交互项。

上述等式重新组合后,形式为:

价格 = β0 + (β1 + β4. 宽度) 发动机大小 + β2. 马力 + β3. 宽度

现在,如果宽度增加1个单位,β4可以解释为对发动机尺寸的影响。

模型构建

费尔南多根据上述理论重新构建了模型,在统计软件中得到如下的参数:

Markdown

该等式变成:

价格 = 51331.363 – 1099.953 x 发动机大小 + 45.896 x 马力 – 744.953 x 宽度 + 17.257 x 发动机大小:宽度

价格 = 51331.363 – (1099.953 – 17.257 x 宽度)发动机大小 + 45.896 x 马力 – 744.953 x 宽度

让我们来解释这些系数:

  • 发动机的大小、马力和发动机的大小:宽度(交互项)都很重要。
  • 汽车的宽度并不重要。
  • 将发动机尺寸增加1个单位可将价格降低1099.953美元。
  • 马力提高1个单位,价格上涨45.8美元。
  • 交互项很重要,这意味着真正的关系不是叠加的。
  • 将发动机尺寸增加1个单位也会使价格提高(1099.953 – 17.257 x宽度)。
  • 测试数据的调整R平方为0.8358 =>该模型解释了83.5%的变化。

请注意,汽车的宽度并不重要。那么将它包含在模型中是否有意义?这里有一个被称为分层原则的原则:

分层原则:当模型中包含交互时,主要效果也需要包含在模型中。即使个体变量在模型中不显着,也需要包括主效应。

费尔南多现在运行该模型并测试测试数据的模型性能。

Markdown

该模型在测试数据集上表现良好。测试数据的调整R平方为0.8175622 =>该模型解释了位置数据变化的81.75%。

费尔南多现在有一个最佳模型来预测汽车价格并购买汽车。

回归模型的局限性

回归模型是数据科学的主力,是数据科学家工具箱中的一个令人惊叹的工具。当被有效使用时,他们在解决大量现实生活中的数据科学问题方面非常出色。然而,他们确实有其局限性。简要解释回归模型的三个局限性:

非线性关系:线性回归模型假定变量之间是线性的,如果关系不是线性的,那么线性回归模型可能无法按预期执行。

实用提示:使用像日志这样的转换将非线性关系转换为线性关系

多重共线性:共线性是指两个预测变量彼此相关的情况。当有很多预测因子和这些预测因子相互关联时,它被称为多重共线性。如果预测因子彼此相关,则特定预测因子对目标的影响很难被隔离。

实用提示:通过仔细选择预测变量来简化模型。限制选择太多相关的预测变量。或者,使用创建新的不相关变量的主要组件等技术。

异常值的影响:异常值是远离模型预测的值的一个点。如果目标变量中有异常值,模型将被拉伸以适应它们。针对少数离群点进行太多的模型调整。这使得模型倾向于异常值。对于大多数人来说,模型的拟合没有任何好处。

实用提示:删除用于建模的异常点。如果目标中存在太多异常值,则可能需要多个模型。

总结

至此,简明数据科学系列将告一段落,此阶段的主要目的是了解数据科学的基础,以及线性回归模型的从0到1。最后讨论了现行回归模型的局限性,在实际应用的过程中,可能需要进行数据的统计分析来分析数据以及数据之间的关系,如果是线性的,即可直接使用线性回归模型,若非线性,可能要使用其他方法,或者想法设防将非线性转换为线性关系后使用线性回归方法,需要根据实际情况而定。

重磅 | iView 发布 3.0 版本,以及开发者社区等 5 款新品

Markdown

7 月 28 日,我们成功地举办了 iView 3.0 暨神秘新品发布会,这可能是前端开源圈第一次举行线下+线上的发布会。现场座无虚席,线上直播也有超过 2 万人观看。

Markdown

iView 3.0到底有哪些重要更新?5款神秘新品又是什么?接下来就为你揭秘……

View 3.0:更轻量的设计,更强大的组件和功能

我们设计了全新的 iView Logo,维持了原先 i 和 v 的造型,并让颜色更立体:

Markdown

3.x 的版本代号依然沿用 iOS 优秀独立游戏的名称,3.0 的版本代号为两周前刚发布的 RPG 游戏 Battleheart。

全民彩蛋计划

Markdown

为庆祝 iView 两周岁生日,以及 3.0 版本的发布,我们在 iView 文档 (https://www.iviewui.com)中放置了三枚彩蛋,它们埋藏在不同的页面里,可能是一段隐藏的代码,或是一段需要破解的密码等等,总之,聪明的你一定会找到并破译它们。当然,找到三枚彩蛋,你并不能继承 iView 作者的遗产!彩蛋可以兑换大量的 IO 币,详见下文开发者社区(https://dev.iviewui.com)。

设计

许多用户选择 iView,很大的原因是认可 iView 的设计,所以在 iView 3.0 里,我们对 UI 进行了进一步的优化。

iView 的 icon 采用开源项目 ionicons 提供的图标,这次也是将 ionicons 图标库从 2.0 升级至 3.0。 3.0 的图标库在命名上更加的规范,只分为 ios ,md, logo 三种,图标也比以前丰富和好看。 3.0 还新增了属性 custom,可以自定义图标。

Markdown

整体的设计风格趋向于简洁、轻量,去掉了冗余的设计,部分颜色做了调整,看起来更加醒目,比如:

Markdown

Markdown

新组件

iView 的组件是全球同类产品里数量最多,功能最丰富的,3.0 更是增加了 5 个全新的组件。

相对时间组件 Timehttps://www.iviewui.com/components/time

锚点组件 Anchorhttps://www.iviewui.com/components/anchor

面板分割组件 Splithttps://www.iviewui.com/components/split

分割线组件 Dividerhttps://www.iviewui.com/components/divider

单元格组件 Cellhttps://www.iviewui.com/components/cell

相对时间组件 Time 用于表示几分钟前、几小时前等相对于此时此刻的时间描述。相比一个固定的日期时间,它更能体现出最近的状态。

Markdown

锚点组件 Anchor 可以快速跳转到页面指定的位置,经常用于导航文章或文档中的目录结构,随着页面的滚动,它可以自动定位当前浏览区域所对应的标题,点击对应的标题,页面也会跳转到对应的位置。

Markdown

面板分割组件 Split 可将一片区域,分割为可以拖拽调整宽度或高度的两部分区域,并支持嵌套使用。

Markdown

分割线组件 Divider,常用于对不同章节的文本段落进行分割,或者对行内文字/链接进行分割,例如表格的操作列。

Markdown

单元格组件 Cell 在手机上比较常见,在 PC 上则常用于固定的侧边菜单项。Cell 可以是一个简单的菜单项,也可以跳转到其它页面,或者跟 徽标 Badge 或 开关 Switch 等组件一起使用。

Markdown

新特性

iView 3.0 有超过 40 项新特性及功能的优化。 首先是全局配置——

https://www.iviewui.com/docs/guide/global),使用 iView 3 时,可以进行全局配置组件的一些属性。目前只支持配置 transfer 和 size 两个属性。组件会优先使用 prop 设置的属性,如果未设置,再使用全局配置。

transfer:所有带浮层的组件,是否将浮层放置在 body 内,默认为不设置,详见各组件默认的 transfer 值。可选值为 true 或 false。

size:所有带有 size 属性的组件的尺寸,默认为不设置,详见各组件默认的 size 值。可选值为 default、small 或 large。

用法如下:

Vue.use(iView, {

transfer: true,
size: 'large'

});

Button 是 iView 最基础,也是最常用的组件。看似再简单不过的一个组件,其实里面有很多学问。 iView 3 废弃了 type=”ghost”,而是新增了布尔选项 ghost,定义按钮为幽灵按钮,幽灵按钮的背景是透明的,常用于有色背景上面。

Markdown

还新增了 3 个用于跳转的 props:to、replace、target:

Markdown

添加 to 属性后,按钮会以 标签的形式渲染,点击可直接跳转,也支持传入一个 vue-router 对象,iView 会做智能判断。如果使用了 vue-router,会以前端路由的形式跳转,否则会用传统的方式跳转。 replace 属性开启后,跳转不会保存历史记录。 target 的行为和 a 标签类似,比如设置在新窗口打开。 支持 跳转 的组件,除了 按钮组件 Button,还有面包屑组件 Breadcrumb、菜单组件 Menu、以及单元格组件 Cell,这些组件都具有 to、replace 和 target 三个属性,体验也完全一致。后续还会支持到更多组件,比如 Dropdown。

Markdown

router 的编程式导航跳转方便的太多,并且会渲染为带有链接属性的 a 标签,在 SEO 上也更友好。

所有支持跳转的组件,都支持了键盘按键(Mac 为 command,Windows 为 ctrl)加鼠标左键在新窗口打开的特性(无论是否设置 target=”_blank”,这种组合行为都会在新窗口打开,与浏览器原生体验完全一致)。

对话框组件 Modal 新增了三个属性:

fullscreen 全屏

draggable 拖拽

mask 是否隐藏遮罩层

开启全屏属性 fullscreen 后,会铺满整个屏幕,并且只有内容区域可滚动。 开启拖拽属性 draggable 后,会默认隐藏遮罩层,此时拖动 Modal 的标题栏就可以移动了,可以支持同时开启多个 Modal 进行拖拽。

表格组件 Table 新增了两个属性

indexMethod

tooltip

当设置列有 type=”index” 时,可以使用 indexMethod 进行自定义序号了。 给某一列设置属性 tooltip=”true” 时,当该列内容过长,一行无法显示时,鼠标经过会以 Tooltip 的形式显示完整内容。

Markdown

其余的更新内容可以到 3.0 更新日志查看。

开发者社区 iView Developer

这是发布会最劲爆的一款产品了。过去的两个多月里,我们一直在投入社区的开发中,目的就是彻底解决开发者的问题,更好地服务开发者。 社区地址:https://dev.iviewui.com/

一对一提问

遇到编程问题,怎样才能有效解决呢?

QQ / 微信群

SegmentFault / Stackoverflow 等技术社区

问同事

每个人都期望加入大群,但都在小群活跃。QQ / 微信群是程序员很活跃的地方,iView 也组建过官方的 QQ 群,累计有 5000 人左右,每天都沉淀了大量的讨论,虽然我不会一一过目,但偶尔也会快速浏览一下。其中一部分问题是文档中已有的,一部分是比较基础的用法,还有一些相对综合的问题。提问的人很多,解答的人缺少,因为群里的人,绝大多数都是和“你”一类的用户,他们加群也是想解决问题来的,但事实上,并没有得到很好和及时的解决。

Stackoverflow 就不说了,这是一个门槛较高的程序员社区,不过对于高级程序员来说,是寻找答案最好的地方。我们来说说国内的技术社区。以 SegmentFault 为例,我们以往也一直鼓励除了 bug 反馈,都到 SF 提问,因为 GitHub 只适合处理 bug 本身的问题,对于如何使用不适合在上面探讨。

至于问同事和朋友嘛,首先你得有一个懂你的领域问题的同事或朋友,而且,对方得有时间和耐心。

为什么得不到有效解决?

其实理由很简单:

“你”问的圈子的人,也都跟“你”一样,是主动提问型的。

专业问题(比如 iView / Vue.js),不是所有人都知道。

能解决你问题的人,一般都是大牛,而大牛都很忙,根本没空理你。

说的很露骨,但却一针见血。

怎样才能解决问题

如果你想问 iView 的问题,那这个世界上谁对 iView 最了解?当然是 iView 作者本人了,那自然也对 Vue.js 的问题了如指掌。如果作者解决不了的,但基本也没什么人能解决,所以,要想彻底解决问题,就是直接向 iView 作者提问。

所以,一对一提问,是 iView Developer 最核心的功能,也是最能解决你痛点的。

Markdown

高级示例

针对 Vue.js 及 iView,精心编写了大量业务中的高级示例,对 iView 官方文档作补充。比如 Table 的服务端分页及服务端排序、过滤;Upload 的手动上传及七牛云的集成。所有示例都有详细说明、源码及演示,并可以收藏。高级示例会不断增加。

高级示例也是 iView Developer 另一重要的板块,里面会陆续更新丰富而针对性的实例,以 iView 和 Vue.js 为主。高级示例具体到某个详细的问题,比如 Table 组件和 Page 组件联合使用并做服务端的分页、排序、过滤。大量的最佳实践和详尽的代码讲解、浏览体验,对于 iView 使用者来说是很好的补充。

Markdown

每周都会更新一些示例,并提示您,并且可以对示例进行收藏。

除此之外,还有独家写作、商城等功能,期待你的探索!

iView Run:随时随地运行 iView 示例

iView Run 是一个集成了 iView 环境的在线运行 iView 示例的工具,左边写代码,右边预览,可以直接编写一个 .vue 文件,它包含了 template、script、style 三部分。 编写好的示例保存后,会生成一个链接,并可以预览,链接可用于提交 bug,或分享示例给他人参考。

地址:https://run.iviewui.com/

Markdown

iView Run(beta)目前仅支持 iView 环境,暂不支持 Less 和部分 ES6 语法,这取决于你的浏览器。未来将逐步支持,并提供示例共享平台,你可以分享或浏览别人分享的优秀示例。 并且 iView 的文档未来也会集成 iView Run,文档中所有的示例未来都可以直接在 iView Run 中运行。

iView Editor:简约而不简单的 markdown 编辑器

因为在 iView Developer 中,我们开发了一个使用起来还不错的 markdown 编辑器,所以把它单独开源出来。 iView Editor 参考 Github 的设计风格,可以在 markdown 和预览之间进行切换,当然,你喜欢实时预览的话,也是支持的。

地址:http://editor.iviewui.com/

GitHub:https://github.com/iview/iview-editor

Markdown

iView Weapp 2.0

我们在一个多月前发布了微信小程序 UI 组件库 iView Weapp,这次发布会我们带来了它的 2.0 版本。 2.0 文档:https://weapp.iviewui.com/ GitHub:https://github.com/TalkingData/iview-weapp

iView Weapp 2.0 新增了 7 个全新的组件: 索引选择器 Index

吸顶容器Sticky

滑动菜单 Swipeout

倒计时 CountDown

分隔符 Divider

折叠面板 Collapse

页底提示 LoadMore

扫描小程序码,立即体验 iView Weapp 2.0:

Markdown

iView Admin 2.0

iView Admin 2.0 也进行了一波大的升级:

基于 Vue Cli 3.0 重构所有代码 重写重要组件 全新权限方案 多级菜单路由 Mock 请求模拟 全局配置 清晰数据流

体验iView Admin 2.0: https://iview.github.io/iview-admin

GitHub:https://github.com/iview/iview-admin

7月28日也是 iView 的两周岁生日,发布会结束后,我们举行了生日会。特别定制的蛋糕太萌了,大家纷纷拍照留念。

Markdown

以上就是本次 iView 3.0 发布会的核心内容,完整的发布会视频之后会在 iView Developer 发布。

简明数据科学 第七部分:对数回归模型

Markdown

作者丨Pradeep Menon

原文丨 https://towardsdatascience.com/data-science-simplified-part-7-log-log-regression-models-499ecd1495f0

译者丨TalkingData 张永超

在本系列的内容中,我们已经讨论了简单线性回归模型,以及多元回归模型和选择正确模型的方法。

费尔南多现在已经构建了一个很好的模型。

Markdown

price = -55089.98 + 87.34 engineSize + 60.93 horse power + 770.42 width

但是,费尔南多依然有一下考虑:

  • 如何使用常见的比较单位来估算价格变化?
  • 关于发动机尺寸、马力和宽度的对应价格有多少弹性变化?

在本篇内容中,我们将解决这些问题。本文将介绍对数回归模型

概述 为了了解对数回归模型,首先需要理解导数、对数、指数的概念,进而理解弹性的概念。

**导数: ** 导数是一种表示变化的方式 —- 一个函数在一个给定点上的变化量。

如一个变量y是x的函数,则将y定义为:

y = f(x)

则在y上关于x的导数,表示为:

dy/dx = df(x)/dx = f'(x)

而这种表示的含义如下:

y相对于x变化的变化,即,如果x变化,y会有多少变化?

这正是费尔南多所需要的,他想知道的价格正是相对于变量的变化。

之前多元回归模型的一般形式如下:

Markdown

也就是说费尔南多建立以下模型:

price = β0 + β1 . 发动机大小 i.e. 价格是一个关于发动机大小的函数。

费尔南多所构建的模型主要的目标是预测汽车的价格,而其价格方面取决于发动机的大小,其模型也正好表达了发动机大小的变化对应价格的变化的规律。

然而,可能并非如此,线性模型是假定数据是线性关系的,如下:

y = mx + c

如果计算y上的导数,则会给出如下的结果:

dy/dx = m . dx/dx + dc/dx

相对于发动机本身的变化,其值始终为1,例如dx/dx = 1

一个常数相对于任何东西的变化其导数始终为0,因为它是一个常数,例如dc/dx = 0

那么公式就变成了:

dy/dx = m

在发动机大小上应用价格导数将只会关联与发动机大小的系数。

面对这种情况,必须想办法来改变它,那么接下来就看看指数和对数。

指数:

指数是一个具有两个运算符的函数,基(b)和指数(n),被定义为b^n,其形式如下:

f(x) = b^x

基数可以使任何的正数,欧拉数(e)是统计中最为常用的基数。

在几何上,指数关系具有以下的结构:

Markdown

  • x的增加不会导致y的相应增加,直到到达某个阈值
  • 到达阈值后,x每增加一小部分,y会急速的上升

对数

对数是一个有趣的符号。在回归模型中,对数有着个性化的特质,对数的基本属性是它的基数,对数典型的基数是2、10和e。

如下例:

  • 多少个2相乘等于8?2 x 2 x 2 = 8 答案是 3
  • 也可以表示为 log2(8) = 3

可以读作 以2为底的8的对数为3

对数还有另一个共同的基数,被称为欧拉数(e),其近似值为 2.71828,在统计学中被经常使用。以e为低的对数称为自然对数。

对数也有很好的变革能力,对数可以将指数关系演化为线性关系。例如下图显示了y和x之间的指数关系:

Markdown

如果对数应用于x和y,则log(x)和log(y)之间的关系是线性的。它看起来像这样:

Markdown

弹性:

弹性是衡量一个经济变量对另一个经济变量的响应程度。假设我们有一个函数:Q = f(P)那么Q的弹性定义为:

E = P/Q x dQ/dP

dq/dP是P中Q变化的平均变化

**结合在一起: ** 现在让我们把这三个数学角色放在一起,导数、对数和指数。他们的结合规则如下:

e的对数是1,即log(e)= 1

指数的对数是指数乘以基数

log(x)的导数是:1 / x

设想一个函数y表示,如下:

y = b^x

=> log(y) = x log (b)

那么这是否意味着是线性回归模型?我们可以做数学演化以利用导数、对数和指数吗?我们是否可以重写线性模型方程来找出x的变化率呢?

  1. 首先,让我们将y和x之间的关系定义为指数关系。
  2. y = α x^β
  3. 首先将其表示为log-log的函数:log(y)= log(α)+β.log(x)
  4. 方程y = α x^β看起来并不像是回归模型:Y =β0+β1,其中β0= log(α),β1=β。这个等式现在可以重写为:log(y)=β0+β1.log(X1)

但是如何表达弹性关系呢?我们取log(y)和x的导数,得到如下结果:

  • d. log(y)/ dx = β1. log(x1)/dx
  • => 1/y . dy/dx = β1 . 1/x => β1 = x/y . dy/dx
  • β1的方程是弹性。

构建模型

搞清楚了这些概念后,费尔南多重新构建了一个模型,如下:

Markdown

log(价格) = β0 + β1. log(发动机大小) + β2. log(马力) + β3. log(宽)

他希望根据发动机尺寸,马力和宽度的变化来估算汽车价格的变化。

费尔南多最终得到了如下的参数:

Markdown

该模型的方程是:

log(价格) = -21.6672 + 0.4702.log(发动机大小) + 0.4621.log(马力) + 6.3564 .log(宽)

以下是该模型的解释:

  • 所有系数都很重要
  • 调整的R平方为0.8276,说明该模型解释了数据变化的82.76%
  • 如果发动机尺寸增加4.7%,那么汽车价格将上涨10%
  • 如果马力增加4.62%,那么汽车价格将上涨10%
  • 如果汽车的宽度增加6%,那么汽车的价格将增加1%

模型评估

费尔南多现在已经建立了对数回归模型。他评估模型在训练和测试数据上的表现。

回想一下,他已经将数据分成了训练和测试集,训练数据用于创建模型,测试数据是不可见的数据。测试数据的性能是真正的考验模型的地方。

Markdown

在训练数据上,模型表现相当好,调整的R平方为0.8276,说明该模型可以解释82.76%的训练数据变化。为了使模型可以最终被接受,还需要在测试数据方面表现良好。

费尔南多测试测试数据集的模型性能,该模型计算测试数据的调整R平方为0.8186。这意味着即使对于看不见的数据,模型也能解释81.86%的变化。

请注意,该模型估计log(价格),而不是汽车的价格。要将估计的log(价格)转换为价格,需要进行转换。

转换是将log(价格)作为基础e的指数。e^log(价格)= 价格

结语

统计学习奠定了基础,假设检验讨论了空假设和替代假设的概念,简单的线性回归模型使回归简单,然后,进入多元回归模型的世界,然后讨论模型选择方法。在这篇文章中,讨论了对数回归模型。

到目前为止,构建的回归模型只有数值独立变量。下一篇文章将讨论相互作用和定性变量的概念。

相关阅读:

简明数据科学 第一部分:原则与过程

简明数据科学 第二部分:统计学习的关键概念

简明数据科学第三部分:假设检验

简明数据科学 第四部分:简单线性回归模型

简明数据科学 第五部分:多元回归模型

简明数据科学 第六部分:模型选择方法

Markdown

从数据运营到数据变现,TalkingData证券行业实战分享研讨会在深圳召开

2018年7月11日下午, TalkingData在深圳举行了证券行业数据运营实战研讨会,华南地区证券行业的科技部门与网络金融部门的相关负责人参加了本次研讨会,参会者覆盖了华南地区90%以上的证券公司。此次会议以“数据运营实战分享”为主题,探讨了数据场景变现的整体思路,从业务运营指标建设、数据场景变现、精准营销案例、大数据和人工智能应用等方面,面向证券行业用户介绍行业成熟案例和解决方案。

TalkingData从多年的证券行业实战角度出发,认为证券行业的数据运营要升级现有的思路,从客户视角转向用户视角,从获客发展转向存量经营,从产品关注转向用户关注,从投资通道转向财富管理。通过养数据、看数据、用数据的方式,打通内外部数据和行为数据,实现数据资产的统一视图。通过业务运营指标体系建设,帮助证券公司关注用户转化旅程、提升运营效率、降低运营成本、发现数据变现的机会。建设数字营销闭环缩短用户转化旅程,提升客户活跃度和客户价值。

MarkdownTalkingData高级副总裁 支宝才

TalkingData高级副总裁支宝才出席了本次会议。他在开场演讲中指出,现阶段是证券行业实现业务转型的关键时间点。中国证券行业已经完成了体系、指标的建设,在今天,大家更关注如何通过数据运营获得实际的业务收入。随着客户互联网使用习惯的改变,未来的获客、经营、资产提升、业务收益都将更多地转向移动互联网平台,领先的券商已经把移动互联网变成客户运营的主战场。

Markdown国海证券的数据运营专家 蒋愉

作为第一个重量级嘉宾,国海证券的数据运营专家蒋愉分享了国海证券建设指标体系的历程。通过证券行业指标体系的建立和分析来发现业务问题背后原因,根据数据分析结果制定运营策略,建立数据监测优化的闭环式模型,帮助国海证券实现从短期KPI实现到长期目标达成,再到数字化战略部署的提升。蒋愉表示,国海证券的数据化运营分为三个阶段:即探索、实践和精细化运营,而数据指标体系及平台的搭建是从实践到精细化运营阶段的重要基石,其可以帮助证券公司实现从指标洞察到运营优化提升。

国海证券与TalkingData合作搭建的指标系统投入生产之后,其使用率达到了80%以上,有效地帮助产品、运营各线完成了数字化运营的策略制定到落地实施。蒋愉指出,在推进该平台的使用过程中,国海证券通过OKR指标分解和领导层驱动提升了用户使用指标体系平台的频率,通过数据人员对指标价值的案例梳理和演示让大家进一步理解指标价值和应用方法,并通过收集客户需求及敏捷迭代提升了用户体验。

MarkdownTalkingData证券行业咨询总监 赵博

TalkingData证券行业咨询总监赵博从多年证券行业数据运营实战角度,分享了证券行业数字化运营体系建设的思路和案例,主要覆盖券商互联网转型、数据化运营体系建设思路、数据智能平台三大方面。赵博认为证券行业流量已趋于饱和,大型券商仍在跑马圈地布局年轻人群;中小型券商急于在同质化的服务中寻求自己的差异,投资者教育会是新的流量来源。市场上逐渐出现了产品、功能、内容满足客户所有需求的产品,行业垄断态势逐步显现。通过运营平台的建设完成精准服务、提升客户粘性成为未来主旋律。

赵博提出,指标体系是指导运营的底盘,应从指标体系中挖掘用户动向、探索运营场景,并反馈回指标体系持续监控形成业务闭环。有效的指标体系能够连接前端互联网行为数据和后端商业需求,数据运营是全局概念,是数据、运营、产品、推广等部门的多方协作,是一个全策全力的作战体系。证券公司需要建立数据运营和营销中台、以客户为中心进行数据化运营,具备同互联网企业一致的数据运营能力,将流失预测模型与客户体系分类有机结合,使数据和营销产生联动,让营销结果最大化。 Markdown广发证券大数据总监 王永强博士

华南地区领先的证券公司广发证券出席了本次研讨会。广发证券大数据总监王永强博士以“大数据和人工智能助力证券业务创新”为主题,结合自身互联网巨头和证券行业的从业经验,分享了人工智能和大数据发展趋势和广发证券的实践。 王永强博士指出,人工智能在国外的券商业务中已经有典型的应用场景,并从智能证券业务、智能监管以及数据化运营三方面显示了其巨大的价值和潜力。广发证券通过建立数字化平台和大数据平台,展开不同维度的数据分析和与模型分析,利用用户画像和指标分析来完善客户综合体系评估,实现公司的数字化运营能力的提升。最后王永强博士从损益、诊断、风控等多个方面介绍了广发证券在大数据和人工智能方向的探索。

MarkdownTalkingData高级产品总监 刘彬

在接下来的分享中,TalkingData高级产品总监刘彬指出数字化运营已经成为现今互联网业务或偏向互联网业务的核心方法论。现有交易类APP已无法满足O2O的传播和时效性,证券行业数据体量的消化能力、数字化处理能力都亟待提升, 未来需要从用户概念、场景(情景)感知、营销及归因、分析诊断四大方向着手,通过数据的驱动做到自动化业务的闭环。刘彬表示TalkingData的AE系列产品和数字营销闭环平台是为证券行业数据运营开发设计,可以作为证券行业的数据运营和营销的中台,洞察用户行为,优化产品功能,建立营销场景,分析营销活动的ROI,迭代营销方案,实现数据营销闭环。利用数据和模型进行数据试验,不断尝试、试错、总结、学习,最后完成精细化运营。

MarkdownTalkingData首席布道师 鲍忠铁

会议的主持人TalkingData首席布道师鲍忠铁则在分享中强调了数据增长对于企业的重要意义,他提出了证券行业数据增长的组织建设、工具建设、体系建设、数据增长营销平台建设的方法和建议,并总结了证券行业数据增长的八条经验:

  • 数据增长是个系统工程,必须所有团队参与,领导全力支持;
  • 产品是数据增长的基础,产品优化是数据增长首要任务;
  • 多次数据实验才可以形成标准营销方案,经验需要延续;
  • 电商的五次曝光理论仍然成立,单个用户的营销推送不要超过5次/天;
  • 初次数据实验的成功率在三分之一,转化率为1%是一个可以接受的结果;
  • 场景(事件)营销的转化率最高,业务规则和模型应用同样重要;
  • 指标建设是数据增长的基础工作,指标分析的目的 是from insight to action;
  • 营销中台是数据增长和提高产能的有效工具,建立自我强化的闭环。

研讨会上设置了问答环节,证券行业的同仁积极向演讲嘉宾提出疑问、进行互动,深入讨论了证券行业数据运营中的实际困难和解决方法。TalkingData今后也将继续举办此类活动,分享行业实战经验,与企业共同探索、携手成长。

Markdown