基于证据的合规努力。在法律的其他领域，产生了广泛的社会学、心理学和实践证据，以发展有效和高效的执法，并使法律和实践更紧密地联系在一起。在GDPR合规方面，这些证据基本上是缺失的。出于这个原因，NOYB进行了一项被认为是基于证据的合规方法的起点的调查。调查的目标是数据保护专业人士，他们处于合规工作的最前沿，对控制者和处理者的内部决策过程有独特的了解。以深入了解导致更多GDPR合规性的组织动力因素，提高对最重要的内部和外部因素的认识，并为未来有效的内部合规工作和执法工作得出关键结论。
平均每家公司有74.4%的人承担相关违规行为。超过1000名隐私专业人士回答了调查问卷，他们大多担任大公司的数据保护官（DPO）或内部合规部门。调查显示，在过去五年人们对隐私问题的意识有所提高，但大多数公司仍然没有遵守GDPR。
很难说服内部玩家。造成这种情况的一个主要原因似乎是DPO很难说服公司内部的决策者做出必要的改变，以实现GDPR合规。对于销售和营销部门来说尤其如此，56%的受访者表示很难说服他们实施更高的合规性。相反，这些部门甚至向DPO施压，要求其限制GDPR合规性。此外，51.3%的受访者表示，很难说服非欧洲经济区/欧盟供应商做出改变以符合GDPR，而欧洲经济区/欧盟供应商的这一比例仅为22.3%。38.5%的受访者表示，很难说服高级管理层做出改变；32.3%的受访者甚至表示，高级管理层施加了限制GDPR合规性的压力。虽然普遍认为不需要符合GDPR标准的产品，但只有12.6%的企业受到商业客户的压力，要求他们为了业务利益限制GDPR合规性。
更多阅读：
作为生意参谋联合Quick BI的初次尝试， “自助分析”面向店铺提供自助分析解决方案，支持店铺个性化数据报表制作，同时支持长周期的数据存储和分析，形成店铺专属的数据监控和分析看板，以帮助店铺提升经营效率。
“自助分析功能让店铺的数据统计与分析变得更加简单，” 厨房里的阿芬天猫旗舰店运营负责人宋福翔告诉记者，“过去需要花费1小时完成的数据统计分析工作，现在1分钟就能轻松搞定。”
生意参谋全新功能“自助分析”可自定义搭建多维数据报表
被数据拨正的参考主义
宋福翔负责的天猫旗舰店“厨房里的阿芬”，今年六月才将目光从调味品类转向方便速食市场，目前还处于“万事开头难”阶段。
“过去，店铺一个月能有过百万的销售额，但现在一切得从0开始。”在谈到店铺转型后的销售额时，宋福翔带了些自嘲的意味，但并不是很担心现阶段的“阵痛”。
在宋福翔和团队看来，目前方便速食各品类都进入了产品重新定义、消费新一轮升级的阶段，特别是自热饭细分领域，线上市场已经初具规模，头部效应明显，“对新进入赛道的品牌来说，想要迅速起量就需要有更多不一样的抓手和推广策略。”宋福翔介绍。
然而，中式餐饮的方便熟食口味繁多，团队初期缺乏数据沉淀，只能依赖品牌定位、竞品分析和线下餐饮口味推荐来做参考，宋福翔表示，“我们将目标市场定位在一二线城市白领人群，区分现有自热米饭主流的偏重口味产品，希望以偏咸鲜口精华浓缩“捞汁”为特色的品质捞饭去细分市场，打开局面。 ”
今年天猫618消费季期间，包括迎合大众市场口味的“台式卤肉”“麻辣牛肉”，以及创新口味“鲍鱼”“花椒鸡”共四款口味捞饭商品正式上线。
第一批商品面世没多久，生意参谋就为团队带来了惊喜的商品数据反馈。宋福翔告诉记者，“数据显示，整个6月，虽然鲍鱼、花胶鸡捞饭的客单价相对比较高，但在首轮尝试过程中复购也更高，这两款产品还在多场以单口味形式的直播中被消费者要求返场。”
通过生意参谋，运营团队可以实时查看店铺整体经营数据，同时针对各个商品也能即时调用包括流量、曝光、咨询、成交、售后等整个生命周期的多维数据，依据这些数据，目前厨房里的阿芬已经开始重新梳理店铺SKU策略，并即将推出应季新品“蟹黄风味自热捞饭”，为下半年店铺的持续发力做足准备。
生意参谋数据洞察助推应季新品“蟹黄风味自热捞饭”
自助分析助力店铺经营 1分钟搞定数据分析
厨房里的阿芬天猫旗舰店的成功转型，让宋福翔更加意识到数据对于商品乃至整个店铺运营的重要性。
接触电商第七年，宋福翔其实早早就知晓如何依靠数据去调整店铺经营策略，并养成了每天通过生意参谋查看店铺数据的习惯，“从店铺流量到商品推广，再到交易端、客户体验回评……通过生意参谋的不同模块去查看统计各个端口的数据，整个一套分析下来往往需要1个多小时。”
不久前，生意参谋“自助分析”功能正式上线，作为生意参谋联手阿里云数据中台核心产品之一Quick BI的初次尝试，“自助分析”功能集结了现阶段生意参谋关于店铺的多个维度数据，店铺运营人员在可视化的操作界面，可以同步查看包括店铺流量、商品流量、跳失率等在内的100多个数据指标，并可即时调用，形成满足自身需求的数据报表。
宋福翔表示，过去需要在生意参谋不同模块进行对应数据查看和统计，但现在都能够在“自助分析”中一键选中自定义生成，“对于我们店铺运营者来说，以往需要花1小时完成的工作量，现在基本上1分钟左右就能完成，而且数据统计结果更加准确明了。”
同时针对初次接触报表搭建的店铺运营新手，“自助分析”还提供多个报表模板，可供选择使用。
在膏满堂天猫旗舰店负责人濮正阳看来，目前“自助分析”提供的两大报表类型已经能够满足店铺的大多数数据分析诉求，“生意参谋自带的数据模板侧重呈现整个店铺的核心数据，但是如果聚焦运营场景，比如商品维度、关键词维度等，其实还是需要店铺运营人员去根据自己的实际需求进行数据维度筛选和报表自主搭建，再根据最终的分析结果数据去进行商品链接推广及SKU分布的调整。”
此外，除了可自定义搭建店铺所需的报表外，“自助分析”还提供长周期数据存储能力。
“像现在对于我们店铺来说，是销售大闸蟹的旺季，今年主推的家庭分享款大闸蟹套餐，就需要去年同期相似商品的各项数据做参考，那么之后还有双11、双12、年货节等各种大促场景，自助分析模块提供的这项长周期数据存储能力，是补足了我们做同期数据比较的诉求。” 濮正阳表示。
而才组建新团队完成店铺转型的宋福翔则有更多考虑，店铺运营岗位的流动性比较大，数据交接工作通常比较复杂，“很多数据其实很难进行保存，那么自助分析现在能够为店铺存储近一年半的核心数据，这对我们整个店铺的经营来说，其实是提供了很大保障。”
而在阿里巴巴平台数据产品资深专家逸客看来，全新上线的“自助分析”功能一定程度上还能够拉平不同体量店铺间的数据分析、店铺经营能力，“体量较大的店铺往往很早就开始通过数据指导店铺经营，同时注重数据人才培养和组织建设；相对地，中小商家因为缺少专业数据岗位设置，往往不是特别能够对庞杂多维的店铺数据进行集中统计分析。我们希望通过不断丰富完善生意参谋的功能，并且引入更多专业讲师和分析人才的经验，去帮助更多店铺补齐这项能力，实现店铺经营效率的提升。”
未来，“自助分析”还将逐步上线更多维度数据，实现“一键式”全方位店铺经营数据统计与分析，普惠逾2000万累计用户。
更多阅读：
数据安全软件公司Eress在2019年10月对美国安全专业人士的调查显示，约有一半的受访者表示他们的公司已经或将在今年年底前遵守CCPA。
虽然并不是所有的公司都完全合规，但这并不意味着他们无所事事。2019年11月的一项调查发现，93%的美国IT决策人员表示，他们至少已经采取了一些措施来遵守隐私法规，如CCPA或欧盟的一般数据保护法规（GDPR）。至少有一半的受访者已经采取了一些措施，比如改善现有安全技术，投资于新技术，以及改善数据处理做法。
eMarketer首席分析师Lauren Fisher表示：“就像我们在GDPR中看到的那样，遵守CCPA是大多数公司无法在2020年1月1日的最后期限之前完成的。”
对于公司来说，遵守CCPA可能是一项代价高昂的努力。根据PossibleNoW 2019年8月的数据，35%的接受调查的美国企业表示，到2020年1月1日他们仍无法满足CCPA的要求，因为他们觉得实现合规的成本太高。
但不合规也不便宜。对于每个无意违规的记录，公司可能会被罚款2500美元；对于每个故意违规记录，公司可能会被罚款7500美元。对于那些对数千或数百万条数据记录负有责任的公司来说，罚款总额可能是巨大的。
199IT.com原创编译自：eMarketer 非授权请勿转载
更多阅读：
随着神盾推荐业务场景的不断深入，传统的离线训练+线上计算的模式可以说是推荐系统1代框架，已经不能完全满足部分业务场景的需求，如短视频、文本等快消费场景。下面先简单介绍下传统模式以及其在不断变化的场景需求中的不足点。
传统模式简单介绍
传统模式下，整个推荐流程粗略可分为，数据上报、样本及特征构造，离线训练评测，线上实时计算，abtest等。
• 优点：
系统架构简单
普适性较强，能满足大多数业务场景。
• 缺点：
数据及时性不够。
模型实时性不强。
下面举一个简单例子，来说明这样的问题：
小明同学在微视上看了一个视频，那么在推荐场景下，可能会遇到以上四类需求，并且每种需求对于数据的实时性要求并不一样。从推荐系统功能来看，可以概括为已阅实时过滤、用户行为实时反馈、物品池子更新等。所以如果要满足业务需求，从代码层面来看，这样的需求并不复杂，但是从架构层面或者可扩展性来说，神盾作为一个面向不同业务的通用推荐平台，就需要提供一个能满足大多数业务，对于快速据消费的通用平台。
针对不同业务、不同场景需求，神盾希望构建一个快数据处理系统，旨在满足更多业务场景的快速据消费场景。
任何系统的搭建及开发离不开特定的业务场景需求调查，神盾根据多年业务经验，收集归纳了相关快数据处理的相关需求，具体如下：
我们深入调研、讨论，结合业界实践以及神盾的实际情况，总结为两类系统需求：
• 1、 近线系统。满足业务对于物品、特征、及其他数据类服务的准实时更新。
• 2、 在线学习。满足业务对于模型的准实时迭代更新。
基于以上调研，神盾推出Quicksilver（快数据计算）系统，解决推荐场景下快数据计算及更新问题。
Quicksilver系统是一个集近线及在线学习能力为一体的通用架构系统，我们设计之初，从收、算、存、用四个维度来进行设计，如下：
• 收：数据的收集。目前主要支持基于DC、TDBank数据通道上报。
• 算：计算层。针对不同的数据类型，定义不同的计算模块。不同的计算模块，采样不同的技术方案来实现。例如对于物品池子此类分钟级更新要求的数据，我们采用sparkstreaming，而对于用户行为实时反馈等类数据，我们采用spp实时处理类服务器框架。设计中屏蔽掉用户对于底层实现的细节。
• 存：存储层。针对不同的数据规模及访问频率，神盾采用不同的存储介质来满足数据存储的要求及对线上服务延迟的要求。例如对于物品类特征、池子类数据，神盾采用自研的SSM系统，而对于用户类特征，数据量较大、存储访问实时性要求也较高，我们选型为公司的grocery存储组件。
• 用：使用对接层。通过Quicksilver计算得到的数据，我们均通过神盾产品化来配置管理，降低对于数据使用的门槛，最终可以通过配置，直接与线上的召回、精排、重排、规则等计算单元进行打通使用。
以上为Quicksilver整体架构实现图，主要分为近线系统及在线学习系统。下面详细介绍。
近线系统
近线系统主要为了满足以下几类细分需求：
• 实时召回：
Quicksilver处理物料，经过各通道后到线上 （要求秒级，实际分钟级）
• 实时因子：
Quicksilver统计计算，经过各通道后到线上（分钟级）
• 实时特征：
统计型（物料、行为、场景）：Quicksilver计算，经过各通道后到线上（分钟级）
实时特征（用户）：实时特征构造引擎构造，构造后直接对接线上（秒级）
于是，在选型上，我们针对不同的数据计算模式，选择不同的计算平台，对于统计类型数据，我们选择sparkstreaming来作为我们的计算平台，对于实时性要求较高的数据，如实时反馈类，我们采用spp来进行平台型封装。
数据批处理
数据批处理是基于sparkstreaming实现，如上，有几点说明：
1、对于使用者来说，采用api接口封装，下层通信等均透明化处理。用户只需在处理不同的数据时，选择不同的接口即可，如物品池子接口，特征接口等。使用PB协议进行下层数据通信。
2、底层数据生成后，使用kafka进行缓存。
3、数据线上使用时，统一在神盾产品化上进行配置管理，降低运维成本。
数据实时处理
数据实时处理是基于spp server实现，如上，有几点说明：
1、对于用户来说，希望一次转发，多次使用。Quicksilver通过接入层interface来实现，业务只需要转发到统一的对外L5，即可实现数据一次转发，多次使用，如部分业务可能想即进行特征构造，有可以将数据转发到样本构造，在此即可实现。而所有的这些配置，也通过神盾产品化进行配置管理。
2、对于不同的业务，由于数据上报标准不一样，那么如何实现不同的数据上报标准都可以在Quicksilver上使用，这是实际中遇到的挺头疼的一件事。我们将这样的问题拆解成不同的数据标准，转化成神盾统一的上报标准的问题。于是，在实际代码开发中，只需要留出这样的转化接口，不同的业务实现不同的接口，并可以根据配置选择不同的接口，那么即可解决这一的问题，在这里，反射即可以很好解决这一的问题。
在线学习
在线学习有两方面优点，一是充分利用数据时效性，实时跟踪用户对物品的偏好，比如10点钟上线的新游，在11点的推荐结果中就可以反馈出不同用户对新游偏好情况，使得在尽快适应用户偏好同时，提升了apps转化率；二是在线学习前提是标记数据和特征在线拼接，该操作可以在一定程度上缓解模型离线训练资源不足瓶颈。
以某apps推荐为例，面临效果提升瓶颈，我们分析有两方面原因导致，一是数据源红利降低(新增数据源成本越来越高)；二是高维线性模型遭遇瓶颈，暴力式特征交叉是LR模型提升特征维数的主要手段，它存在两个问题，一方面，做不同特征之间交叉组合需要一定成本，另一方面，无法穷尽所有交叉组合方式。
面对推荐效果提升瓶颈问题，有三种解决方案，一是继续想办法引入新数据源构建特征；二是充分利用现有数据源，尝试更好特征工程方法，比如Stacking集成或者特征工程自动化；三是考虑充分利用数据时效性，引入在线学习方案，实时跟踪用户对apps偏好变化。
Quicksilver在线学习架构设计如下：
整个系统主要细分为5个小模块：
• 样本采样：根据模型的优化目标支持自定义采样方法，同时在后期也需要将场景特征考虑进来，采样的结果作为实时拼接的输入
• 实时拼接：将实时样本的userid 、itemid的全量特征进行拼接，拼接的结果一方面可以作为离线平台的输入，另外一方面也可以作为特征引擎的输入；
• 特征工程引擎：根据各个在线训练算法的特征配置，从拼接好特征的样本中进行特征选择、特征交叉等操作，并将处理的结果写入kafka消息队列，模型训练和模型评估模块消费消息队列里面的数据进行训练和评估；
• 流式训练：消费kafka里面的样本数据，采用onepass或者minibatch的形式进行模型参数更新；
• 模型评估：对模型训练出来的模型实例，从kafka消费实时样本数据对模型进行auc评估。
下面关于几个较重要模块进行较详细介绍：
样本采样
• 使用spp server实现类map、reduce操作，采样的结果支持存储到kafka或者下一个实时拼接模块。
• 采样规则引擎基于flex/yacc设计实现。
• 所有采样的配置信息，均通过神盾产品化实现管理。
特征拼接
实时拼接服务主要是将样本中包含的物品和用户的“全量”基础特征拼接到一起，为下一步实时特征提供原料。 特征来源有是三个不同的地方：
• 用户特征（包括实时用户特征)：目前主要是来自grocery
• 物品特征（包括实时物品特征): 目前主要从SSM中读取
• 场景特征：是在采样的过程中生成。
实时特征拼接后，下一步便是特征工程引擎的环节，目前主要支持内积、外积、笛卡尔积三种模式，在此不详细介绍。
模型训练
• 目前主要实现基于FTRL的lr及fm算法实现，正在调研参数服务器大规模生产环境使用的路上。
• 动态采样：有的算法算法需要控制正负样本的比例，但线上的流式训练与离线的batch不同，不能再训练之前就知道本次训练总样本量是多少，以及正负样本的比例，故需要根据设置的正负样本比例值，根据时间的推移来动态控制，即在训练的过程中动态采样。
• 低特征覆盖：为了提高模型的可靠性，其中方法之一就是在模型中结合场景特征屏蔽掉低覆盖度特征，与动态采样一样，流式训练时，在训练前无法统计提前统计出每个出现的频率，故也需要动态过滤低频特征，此方法不仅可以用在模型启动时，对于新加入的特征同样适用
模型训练后，即效果评估及上线环节，目前主要支持AUC、MAE等主要评估指标，在此不再详细赘述。
对于任何系统设计来说，都不应该脱离实际的应用场景，这是神盾推荐系统一直贯彻的原则。Quicksilver系统也是神盾这么长时间来从实际的业务场景中收集需求、设计、实现的，已经在空间、电竞、手游、动漫、京东等多个业务场景中上线使用，并取得了不错的效果。神盾也不断在实际场景中继续完善、优化其中的相关能力，给业务带来更高的效果提升。
来源：腾讯QQ大数据
更多阅读：
前言
自手Q游戏中心V6.0改版以来，产品形态发生了较大的转变，不再是纯粹通过app列表做游戏分发，而是试图通过内容来带游戏分发，全新的产品形态给推荐算法带来了许多的挑战。截至4月初，算法一期的工作已接近尾声，借此机会写下总结，一方面是将整个游戏中心的推荐逻辑进行梳理，并将其中的一些经验沉淀总结，方便回溯；另一方面也试图在梳理的过程中，整理出遇到的一些挑战，能够更加明确算法二期的一些迭代思路。
背景
手Q游戏中心作为腾讯手游重要的分发渠道之一，既是用户发现感兴趣游戏的重要入口，同时也提供了各手游平台运营的能力。新版游戏中心不再是纯粹地通过传统app列表的方式做游戏分发，而是新增了一系列通过内容（攻略、视频、直播、礼包等）拉下载、拉活跃的场景（如图1所示）。为了更好地提升用户进入游戏中心的体验以及满足平台精细化运营（拉新、拉活、拉付费等）的需求，通过海量用户的行为流水挖掘用户游戏偏好，精准推荐用户感兴趣内容成为了必然趋势。为此，我们设计了全新的个性化推荐框架，给业务带来了显著的转化率提升。
图1：游戏中心个性化推荐场景
为了更好地制定算法二期的迭代计划，本文主要对算法一期的工作做一个简单的复盘，一方面是将项目开展过程中的一些经验进行总结沉淀，另一方面也是想对游戏中心推荐场景中比较有挑战性的问题进行梳理，以便算法二期迭代过程中更加具有针对性。
本节主要结合游戏中心个性化推荐的算法框架（如图2所示）以及工程框架（如图3所示），对项目过程中遇到的一些问题进行总结归纳。游戏中心所采用的推荐框架是业界常见的三段式推荐逻辑：offline—nearline—online。离线层主要负责存储全量用户在游戏中心的流水数据、计算用户长期的行为属性以及训练用户的游戏偏好模型等；近线层主要是为了解决离线层计算周期长，响应速度慢的缺点，通过实时计算用户的短期兴趣，反馈到线上，从而能够对用户在游戏中心的行为做到实时反馈；在线层可以理解为推荐引擎，主要是对业务请求通过一系列的计算，返回最终的推荐结果列表，在线层可以细分为召回层—精排层—重排层结构。
图2：游戏中心个性化推荐算法架构图
图3：游戏中心个性化推荐工程架构图
- 离线层
离线层适用于用户长期兴趣的计算、离线模型的训练、模型参数的实验以及其他对时效性要求不高的任务，因此离线层主要采取HDFS+Spark的工程实现（批处理的计算方式）。业务数据通过DC或者TDBank上报，累计一定的数据量（游戏中心是以每小时为周期）周期性落地到HDFS或者TDW中以库表的形式存在，以Spark为计算引擎，对库表数据进行一系列处理后，将结果数据推送到线上存储，构成线上推荐引擎的重要数据来源。对于游戏中心这个场景，离线层的工作流可以划分为6大步骤：推荐物料的准备、数据处理、样本设计、特征提取、模型训练、数据上线。
1、推荐物料的准备
对于推荐系统来讲，第一个需要确定的就是推荐物料（也就是推荐池子）。游戏中心推荐的物品主要有两大类：第一大类就是游戏app，目前游戏中心接入算法的游戏app主要包括精品游戏、单机游戏，基本上每天变化不大，因此该类物料由业务每天例行上报更新并推送到线上存储即可。第二大类就是游戏内容了，主要包括攻略、视频、直播等，该类物料相对来讲实时性要求会高一些（新游上线当天需要内容同步更新）。目前游戏中心的内容来源数据链路如图4所示，主要来源是一些上游PGC内容的采购，经过自动Tag提取之后进入到标签内容库，算法侧直接从标签内容库获取推荐物料，目前是按小时更新。
图4：内容源数据链路
2、数据处理
熟悉推荐流程的同学可能比较清楚，数据处理过程繁琐枯燥且耗时较长，占据了整个算法开发周期60%以上的时间，贯穿整个开发流程。没入坑之前有些人可能会以为推荐算法工程师是一个高大上的职位，每天舒舒服服地看下paper，研究下算法，做下实验，特别酷。入坑之后就会发现，每天干的最多的活就是处理数据。但这也充分说明了数据处理的重要性，毕竟只有充分了解数据才能更了解业务，才能更加合理地设计你的推荐策略。这儿讲的数据处理主要包括数据验证、脏数据过滤以及数据转换等。下面主要总结一下在数据处理过程中所踩过的坑：
（1）一定要做好数据上报准确性的验证：前端同学有时候可能不是特别了解算法同学对于上报数据的诉求，所以在上报的时候可能会出现目标不一致的情况。常见的情况有：上报逻辑出错（分页feeds曝光只上报了第一条feeds的数据）、上报id错位（曝光的operid报了下载的数据），上报id缺失等。而验证数据上报准确性的常规操作就是打开游戏中心，将每个场景你有可能会用到的用户行为都操作一遍，记下操作时间，一个小时后从流水中捞出你的数据，逐一验证是否合理（噩梦）。
（2）推荐逻辑出现问题时候优先考虑数据的准确性：当推荐结果产生问题或者出现bug的时候，优先检查数据的准确性。模型的鲁棒性以及容错性一般都较高，最可能出现问题的往往是数据环节。通常都是沿着数据链路往上游逐步排查从而定位问题。
（3）对业务流水数据做一层数据中间表做解耦：算法开发过程中，最好不要直接操作operid相关的逻辑，遇上业务改上报id时（比如产品改版换了新的一套operid），改代码改的你头疼。
（4）算法接入后一定要跟产品以及前端同学再三确认算法ID的上报准确性：业务在调用推荐引擎时都会获得一个算法ID，算法ID上报的准确性直接影响效果监控报表的可信度。很多时候上了一个算法策略结果发现线上效果突然下降，排查半天才发现原来部分转化行为的算法ID上报缺失，所以这儿一定要仔细验证清楚。
（5）脏数据过滤是一门玄学：脏数据的定义通常需要根据业务场景来决定，有时候信心满满地将所有脏数据都过滤之后，线上效果反而降了，所以在过滤数据时要留个心眼（什么样才是脏数据？脏数据是不是一定没用？不要想当然，还是用线上效果说话吧！）。
（6）建立完善的报表监控体系：推荐的一个重要环节就是报表监控，不仅仅包括对效果的监控，还包括对池子的监控、核心用户的监控、item场景表现的监控等。只有建立完善的监控体系，才能在推荐结果受到挑战时快速定位问题。
图5：游戏中心报表监控体系
3、样本设计
一般来讲，推荐问题都会转换成二分类问题，也就是判断用户对某个物品是否会产生操作行为（通常一个U-I对就是一个样本），那么要训练出一个看起来合理线上效果又比较理想的二分类模型，正负样本的设计显得极其重要，下面总结一下游戏中心在设计不同场景的样本时的一些经验：
（1）如何正确定义正负样本？在纯icon推荐的场景，咋一看可以理解为用户下载了该app就是正样本，没有下载就是负样本。但仔细一想这样做会产生两个问题，第一个问题就是正负样本极其不均衡（机器学习中经典问题之一），因为用户浏览几十个app可能也就下载1个app，当然，机器学习针对正负样本不均衡问题会有很多解决方法，这儿就不展开描述了；第二个问题就是用户没有下载并不代表就是不喜欢，这儿会有几个值得推敲的地方：1）用户曝光了但是从没有产生过下载行为，可能因为是无效曝光，用户关注的焦点不在这，所以无法判断用户到底是喜欢还是不喜欢；2）用户在游戏icon曝光的场景并没有产生下载行为，但是用户产生了点击行为，从而进入到游戏详情页后产生下载行为，这样是不是可以认为用户其实是喜欢的，产生的也是正样本呢？举这么个例子主要是为了说明，对于每个不同的推荐场景来说，正负样本的设计都应该充分结合业务特性，不然容易产生有偏样本。
（2）设计样本时应保证每个用户样本数的均衡：在app分发或者内容分发场景，容易存在一些刷量用户；该批用户频繁进入游戏中心从而产生多次操作行为，因此在设计样本时应对多次操作的U-I样本对去重，并保证每个用户样本数的均衡，从而避免模型被少数用户所带偏。
（3）样本权重的设计问题：在feeds推荐的场景中，不同推荐槽位所产生的样本权重应该有所不同；比方说首页feeds场景，用户刚进入场景时，注意力会比较集中，产生的负样本应该置信度较高，权重也较高；当用户下滑到后面feeds的时候，对feeds的内容可能会比较乏味了，产生的正样本置信度应该也是较高的，权重应该也设置较高。
（4）适当丰富样本来源的多样性：一般样本都是基于当前场景所产生的用户行为来选取的，而当前场景用户的行为某种程度是受推荐结果而影响的（“你给我推荐了王者荣耀，那么我只能喜欢王者，但是可能我更喜欢你没给我推的吃鸡呢”），随着算法的迭代，越到后面，算法其实是在迭代自身，越学越窄，这也是推荐系统经典的多样性问题。youtube所采用的一种缓解的方法就是从其他没有算法干扰的场景选取部分样本，来避免这个问题，而在游戏中心的样本设计中，都会单独开设一股没有算法干扰的小流量作为干净样本的补充。
4、特征提取
特征决定机器学习的上限，而模型只是在逼近这个上限。可想而知，特征设计的重要程度是多么的高。关于特征设计的方法论有很多，这儿就不具体讨论。这里主要介绍一下游戏中心各个场景在设计特征时候的通用思路以及为了解决首页feeds特征空间不一致时所采用的多模态embedding特征。
（1）通用特征设计思路：如图6所示。这儿需要提一下的是，游戏中心的推荐场景由于涉及平台利益，所以一般情况下，特征设计时都需要考虑特征的可解释性。
图6：特征设计思路
（2）多模态embedding特征向量：首页feeds流分发场景是一个具有挑战性的场景，其中一个比较有意思的难题就是待推荐的内容类型较多。传统的feeds推荐场景要么都是纯视频流、要么是纯文字feeds等，而游戏中心首页这儿待推荐的内容类型有攻略、视频、直播、活动、礼包等，而且每一种内容类型的二级承载页产品形态也不一致，这样会导致可提取的特征空间维度不一致。比方说视频承载页的观看时长与图文承载页的观看时长量级不一致，视频承载页有icon点击等操作而图文承载页则没有。特征空间的不一致会导致模型在打分的时候会有所偏颇，离线实验过程中发现视频由于特征维度较齐全，打分结果整体偏高。因此，为了减缓特征空间维度不一致问题，游戏中心首页feeds流引入了多模态embedding特征向量，该方法在企鹅电竞视频推荐场景已经取得了较好的效果（如图7所示）。多模态embedding特征向量的设计主要参考youtube的论文，从而获得每个user、item的低维特征向量，一方面解决item的原始特征空间维度不一致问题，另一方面也根据用户的历史行为，学习user、item的隐语义特征维度，起到信息补充的作用。
图7：多模态embedding网络
5、模型训练
好了，终于到了别人所认为的高大上的步骤了——模型训练，其实一点都不高大上，尤其是有了神盾推荐这个平台。目前神盾推荐离线算法平台已经集成了大部分常见的推荐算法，包括LR，Xgboost，FM，CF等，因此离线训练只需要准备好样本跟特征，配置好参数，就可以一键点run喝咖啡了（开玩笑开玩笑，是继续搬下一块砖）。傻瓜式的模型训练（调包侠）其实并没有太大的坑，但是有几点经验也在这稍微写一下哈：
（1）注意调参的正确姿势：目前神盾默认是将数据集划分为train跟test，如果盯着test数据集的指标来调参的话，是很有可能出现线下高线上低的情况。因为盯着test指标进行调参的话容易加入个人先验，本身就是一种过拟合的操作，正规的操作应该是将数据集划分为train-test-validation。
（2）同样的业务场景建议共用一个大模型：新版游戏中心目前有9个场景需要算法接入，如果每一个场景都单独建模的话，一来维护成本高，二来浪费人力。适当对场景问题进行归纳，训练通用模型可以有效地节省开发时间。比如说首页分类列表推荐，游戏Tab的热游列表推荐等，其实都是纯icon的推荐，可以用统一的大模型来建模。通用模型首先要考虑的问题就是样本、特征的选取，样本可能比较好设计，汇总所有场景的样本即可，最多就是根据场景特性设计不同的权重；而特征就需要好好斟酌，是分场景提取特征还是汇总后提取、不同场景特征维度不一致如何处理等。
（3）选择合适的机器学习方案：目前首页feeds是将排序问题转化为二分类问题，评估指标选取的是auc，所以优化的重点在于尽可能地将正负样本区分开（正样本排在负样本前面），但对于正样本之间谁更“正”却不是二分类模型的关注重点。神盾近来已经支持pari-wise的LTR算法，可以解决任意两样本之间置信度问题，后续可以在首页feeds场景上做尝试。
（4）选择合适的优化指标：对于视频瀑布流场景，优化的目标可以有很多，比如人均播放个数、播放率、人均播放时长，具体需要跟产品同学沟通清楚。
（5）避免对分类问题的过度拟合：前面已经提过，在推荐场景，经常将推荐问题转化为分类问题来处理，但是需要注意的是，推荐问题不仅仅只是分类问题。分类问题是基于历史行为来做预测，但推荐问题有时候也需要考虑跳出用户历史行为的限制，推荐一些用户意想不到的item，因此，推荐是一个系统性问题，应当避免过度拟合分类问题。
6、数据上线
数据上线可以说是推荐系统中较为核心的环节，其中会面临很多难题。这儿的数据主要指的是离线计算好的物料数据、特征数据（用户、物品）、模型数据等。目前神盾会周期性地对需要上线的数据出库到hdfs，通过数据导入服务推送到线上存储，主要是grocery（用户特征）跟共享内存ssm（物品特征以及池子数据等查询较为频繁的数据）。目前这儿会有几个小问题：
（1）数据的一致性问题：离线模型在训练的时候，会对样本数据跟特征数据做拼接，通常都是将当前周期的样本跟上一周期的特征做拼接，以天为例，也就是今天的样本会跟昨天的特征数据做拼接。但是离线数据的计算以及上线是会有时间延迟的，尤其是特征数据。有可能今天的凌晨0点到5点，线上所拉到的特征数据其实是前天的特征数据，5点之后，昨天的特征数据才计算完并更新到线上。也就是说凌晨5点之前，所产生的推荐结果其实是用前天的特征数据来计算的，那么离线训练的时候，拼接的特征数据就会与实际的数据不一致。
（2）数据的实时性问题：前面也讲了，业务数据一般会周期（按小时）落地到hdfs或者tdw以库表形式存在，基于spark进行数据处理之后又推送到线上存储，这种复杂的数据处理链路导致数据时效性得不到保证（频繁地数据落地以及数据上线所导致）。因此，离线层仅适用于对数据时效性不高的任务，比如长期兴趣的计算等。
- 近线层
前面已经提到，离线层在数据时效性以及数据一致性的问题上面临较大的挑战。本质上是由于数据频繁落地以及上线导致的延迟所引起的，给游戏中心推荐带来较大的困扰。企鹅电竞也面临同样的问题，因此，两个业务联合设计了近线层（如图8所示）。目前整个数据链路已经打通，并且也在企鹅电竞业务上试点成功。整个框架是基于kafka+spark streaming来搭建的，目前主要实现两个功能点：实时特征的提取以及实时样本特征的拼接。由于近线层不需要落地以及线上导数据服务，而是直接对业务流水进行操作后写入线上存储，因此耗时较少，基本可以做到秒级别的特征反馈，解决了离线层计算周期长的缺点，适用于用户短时兴趣的捕捉。
实时样本特征的拼接主要是为了解决数据一致性问题。离线层对样本、特征进行拼接的时候一般都是默认当前周期样本拼接上一周期的特征，当由于特征上线的延迟，有部分当前周期样本的产生其实是由t-2周期的特征所导致，因此为了保证训练数据的准确性，我们在近线层设计了实时的样本特征拼接。当用户请求时，会带上读取的特征数据，拼接到用户的操作流数据上，构成离线层的训练数据。
图8：近线层功能逻辑
- 在线层
在线层是推荐系统的关键环节，直接影响最终的推荐结果。一般分为召回层，精排层、重排层（或者是matching、ranking、rerank）。召回层一般是起到粗筛的作用，对于内容推荐来说，推荐的池子一般都是上万级别，如果直接进行模型打分的话，线上服务压力会比较大，因此，通常都会采用各种召回的策略来进行候选集的粗筛。目前游戏中心所采用的召回策略主要有标签、热度、新鲜度、CF等。精排层所干的事情就比较纯粹了，一般就是模型加载以及模型打分，对召回的物品进行一个打分排序。最后就是重排层，主要是对模型打分结果进行一个策略的调整。游戏中心的重排排层主要有以下几个逻辑：1）分类打散：首页feeds在推荐的时候，如果只由模型进行打分控制的话，容易出现游戏扎堆的现象，也就是连续几条feeds都是同款游戏，因此需要重排层来调整展示的顺序；2）流量分配：游戏的分发涉及平台的利益，每款游戏的曝光量会影响平台的收入，因此需要合理分配每款游戏的展示量；3）bandint策略：主要是用于兴趣试探，feeds场景会涉及多种内容类型，如何在推荐用户历史喜欢的内容类型以及尝试曝光新的内容类型之间做平衡是推荐系统典型的E&E问题，这儿我们设计了一个简单的bandint策略，下面会详细讲一下。4）运营策略：一些偏业务性质的运营策略也会在重排层体现。
推荐系统中会遇到一个经典的问题就是Exploitation（开发） VS Exploration（探索）问题，其中的Exploitation是基于已知最好策略，开发利用已知具有较高回报的item（贪婪、短期回报），而对于Exploration则不考虑曾经的经验，勘探潜在可能高回报的item（非贪婪、长期回报），最后的目标就是要找到Exploitation & Exploration的trade-off，以达到累计回报最大化。对于游戏中心首页feeds而言，一味推荐用户历史喜欢的内容类型或者大量尝试曝光新的内容类型都是不可行的；首先用户的兴趣可能会有所波动，过去可能喜欢视频类型，但是下一刻就可能不喜欢了；其次一味推荐用户历史喜欢的内容类型，可能会让用户产生厌倦。为了平衡两者之间的关系，我们在重排层设计了一个简单的策略，具体如图9、图10所示。
图9：游戏中心bandit策略算法逻辑
图10：游戏中心bandit策略具体实现
目前游戏中心个性化推荐所遇到的难点以及下一步的迭代计划主要如下：
1、外部数据的引入：1）结合第三方数据做推荐：目前游戏中心个性化推荐的依据主要是用户的场景表现、游戏内表现以及一些基础的画像数据，数据来源较为单一。引入更多的第三方业务数据（比如企鹅电竞），一方面可以丰富用户的特征维度，另一方面可以给用户带来体验上的提升（用户刚在企鹅电竞看了个吃鸡的直播，来到游戏中心就给推荐了“刺激战场”）。2）丰富推荐物料：目前游戏中心的内容来源部分存在“同质化”现象，素材类型还不是特别丰富，需要引入更多优质的外部内容。
2、多模态特征提取：游戏中心的推荐内容类型较为丰富，包括了视频、图文、活动、礼包等，如何在同一个特征向量空间对各个item进行信息抽取是目前遇到的难题之一。现有的解决方案是基于youtube的embedding网络进行user、item的embedding向量学习。该网络的输入是无序的，也就是没有考虑用户历史行为的轨迹，那么是否可以用图来表示行为的轨迹，基于graph embedding的方法获得信息更加丰富的item向量？目前业界也有若干基于graph embedding的推荐案例（手淘首页 、阿里凑单 ）。
3、内容元信息的提取：目前游戏中心对于item的特征提取要么是基于统计的特征，要么就是基于item历史行为的embedding特征或者tag提取，对于内容本体信息的提取还较为薄弱，如何有效地提取非结构化内容的信息是下一步迭代需要考虑的问题。
4、模型的快速更新：对于用户兴趣的实时捕捉，不仅依赖于数据的实时更新，同样依赖于模型的实时更新。目前线上的模型是按天例行更新，如何快速地训练模型以及部署模型是后续不可避免的问题。
5、优化指标考虑收入相关因子：当前的优化指标基本是转化率、时长等推荐系统常见的指标，但游戏中心涉及平台收入，需要综合考虑每个游戏的收益（类似广告系统中的竞价）。如何设计合理的优化指标（考虑游戏arpu、ltv等）以及在用户体验跟平台收入之间做平衡也是下一步迭代的关键。
6、流量分配问题：首页feeds场景既涉及游戏流量的分配，也涉及内容类型流量的分配，如何有效地设计流量分配方案，从而减轻重排逻辑的负担也是需要考虑的优化点。
7、拉活还是拉新：如何根据用户在游戏生命周期的不同阶段推荐合适的内容是首页feeds场景需要考虑的问题。
8、新品试探：目前我们只是在内容类型上做了一些简单的策略，后续还需要调研更加成熟的解决方案来解决E&E问题。
总结
本文主要是对游戏中心在算法一期的接入过程所遇到的问题做一些总结，以及梳理下一步迭代的计划。由于算法一期的重心在于算法的快速接入，因此整个个性化推荐框架中所涉及到的策略可能都略显“着急”，希望各位同行大佬多多包涵。关于游戏中心推荐问题，欢迎随时交流。
来源：腾讯QQ大数据
更多阅读：
电子表单
虽然现在市场上有很多优秀的数据处理工具，但是Excel依然是公认最适合初学者的数据处理利器。Excel 软件中的电子表单能够有效地对数据进行结构化整理和分析。OpenNews的 Sandhya Kambhampati 与大家分享了她在使用Excel时的一些经验和心得，点击查看她的展示，并开始属于你自己的数据探索之旅吧。（OpenNews 是由Knight基金会和Mozilla联合支持的一个项目，旨在建立一个包括开发者、设计师，以及数据记者的社群，在开放的网络环境中帮助新闻事业的发展。）
数据抓取
如果在做选题时，遇到网页上有大量非电子表格形式的数据信息，又该如何处理呢？来自丹麦的记者 Nils Mulvad 说，这时你就需要 Import.io 工具来帮你抓取数据。它能够节省你的时间，把你从重复的劳动中解放出来。
数据清洗
有时你遇到的数据可能是非常杂乱的，不过不用担心， OpenRefine 能够有效帮助你清洗、结构化数据，完善数据集。更重要的是，它还是开源的哦。点击查看 Nils Mulvad 的展示，手把手教你使用这款工具。
数据库管理
你准备好和大数据打交道了么？如何处理GB、TB规模的数据集？如何进行更快捷、更综合的数据分析？来自 Vox 的开发人员 Kavya Sukumar 告诉你，这就需要数据库管理的技能了。点击查看她分享的内容吧。
网络搜索
互联网上有大量良莠不齐的信息，我们如今需要更可靠的方法去检索验证，才能避免被信息误导。路透社记者 Irene Liu 与大家分享了网络报道所需的信息核实工具和方法，包括逆向图片搜索，地理位置核实、社交网络检测等等。点击查看关于网络搜索的更多精彩内容吧。
绘制地图
空
间分析能够帮助记者发掘出数据中潜藏的故事线索，地图绘制则能有效地呈现数据。纽约时报记者 Andy Lehren就经常使用美国环境系统研究所公司（ESRI）开发的工具ArcGIS 进行空间分析和地图绘制。点击查看他在大会上的展示，循序渐进地教你地图绘制。
数据可视化
如果你想用酷炫的设计图表来展示你的数据，但是团队中又缺乏一位工程师或设计师，怎么办呢？没关系，印度最大的财经类门户网站MoneyControl 的数据与社交媒体编辑 Sanjit Oberai ，整理了一份数据可视化工具表单，这些工具操作简单，效果拔群。点击查看他的分享吧。
来自：全球深度报道网
编译/程一祥
编辑/Ivan Zhai，梁思然
更多阅读：
那么筛选海量数据集最优的工具是什么呢?我们咨询了一些数据黑客关于他们在数据分析的核心工作中最喜欢的编程语言和工具包。
R 语言
这份名单如果不以 R 开头，那就是彻头彻尾的疏忽。自 1997 年起，作为一门免费的，可替代 Matlab 或 SAS 等昂贵统计软件的语言，R 被抛弃。
但是在过去的几年中，它却成了数据科学的宠儿—甚至成了统计学家、 华尔街交易员、生物学家和硅谷开发者必不可少的工具。 随着其商业价值的不断增长和传播，诸如谷歌、Facebook、 美国银行和纽约时代周刊都在使用。
R 简单易用。通过 R ，短短几行代码就可以筛选复杂的数据集，通过成熟的模型函数处理数据，制作精美的图表进行数据可视化。简直就是 Excel 的加强灵活版。
R 最大的价值就是围绕其开发的活跃的生态圈： R 社区在持续不断地向现存丰富的函数集增添新的包和特性。据估计 R 的使用者已经超过 200 万人，最近的一项 调查也显示 R目前是数据科学领域最受欢迎的语言，大约 61% 的受访者使用 R(第二名是 Python, 占比39%)。
在华尔街，R 的使用比例也在不断增长。美国银行副总裁Niall O’Connor 说：“以往，分析员通常是熬夜研究 Excel 文件，但是现在 R 正被逐渐地应用于金融建模，尤其是作为可视化工具。R 促使了表格化分析的出局。”
作为一门数据建模语言， R 正在走向成熟，尽管在公司需要大规模产品的时候 R 能力有限，也有些人说它已经被其他语言替代了。
Metamarkets 公司的 CEO Michael Driscoll 说：“ R 擅长的是勾画，而不是搭建，在 Google 的 page rank 算法和 Facebook 的好友推荐算法实现的核心中是不会有 R 的。工程师会用 R 进行原型设计，再用 Java 或者 Python将其实现。”
Paul Butler 在 2010 年用 R 构建了一个著名的 Facebook 世界地图 ，证明了 R 在数据可视化上的强大能力。然而他并不经常使用 R。
Butler 说：“由于在处理较大数据集时缓慢且笨拙，R 在行业中已经有些沦为明日黄花了 ”
那么使用什么作为它的替代呢?看下去。
Python
如果 R 是个有点神经质的可爱的极客，那么 Python 就是它容易相处的欢快的表弟。融合了 R 快速成熟的数据挖掘能力以及更实际的产品构建能力， Python 正迅速地获得主流的呼声。 Python 更直观，且比 R 更易学，近几年其整体的生态系统发展也成长得很快，使其在统计分析上的能力超越了之前的 R 语言。
Butler 说：“Python 是行业人员正在转换发展的方向。过去两年里，很明显存在由 R 向 Python 转化的趋势”
在数据处理中，通常存在规模和技巧的权衡，Python 作为一个折中出现了。 IPython notebook 和NumPy 可以用于轻量工作的处理， 而 Python 则是中级规模数据处理的有力工具。丰富的数据交流社区也是 Python 的优势，它提供了大量的Python 工具包和特性。
美国银行利用 Python 开发新产品以及基础设施接口，同时也用于处理金融数据。O’Donnell 说：“Python 用途宽广且灵活，所以人们蜂拥而至”。
然而， Driscoll 也提到它并不是高性能的语言，偶尔才会用于装配驱动大规模的核心基础设施。
JULIA
最主流的数据科学处理语言包括 R、 Python、 Java、 Matlab和 SAS。但是这些语言仍然存在一些不足之处，而Julia 正是待以观察的新人。
对大规模商用来说， Julia 还是太晦涩了。但在谈到其取代 R 和 Python 领先地位的潜力的时候，数据极客们都会变得很激动。 Julia 是一门高级的，非常快的函数式语言。速度上比 R 快， 可能比 Python 的扩展性更高，且相对易学。
Butler 说：“Julia 正在快速上升。最终将可以用 Julia 完成任何 R 和 Python 可以完成的事”。
如今的问题是 Julia 太“年轻”了。 其数据交流社区仍处在早期发展阶段，在没有足够的包和工具之前是不足以与 R 和 Python 竞争的。
Driscoll 说：“Julia 很年轻，但正在积攒力量而且未来很可观”。
JAVA
在硅谷最大的科技公司里，Java 和基于 Java 的框架构成了其底层的技术骨架。Driscoll 说：“如果深入观察Twitter，Linkedin 或者 Facebook，你会发现 Java 是他们公司数据引擎架构的基础语言”。
Java 并没有 R 和 Python 那样的数据可视化的能力， 同时也不是最好的用于统计模型的语言。但是如果需要进行原型的基础开发和构建大规模系统， Java 往往是最好的选择。
HADOOP 和 HIVE
为了满足数据处理的巨大需求，基于 Java 的工具群涌而现。 作为基于 Java 的框架，Hadoop 在批处理领域成为热点。Hadoop 比其他处理工具速度要慢，但是它非常精确且被广泛的应用于后台分析，它很好的融合了 Hive， 一个运行在 Hadoop 上的基于查询的框架。
SCALA
Scala 是另一个基于 Java的语言，和 Java 很相似，它正在逐渐成长为大规模机器学习或高级算法的工具。它是函数式语言，也能够构建健壮的系统。
Driscoll 说：“Java 就像是直接用钢筋进行搭建， Scala 则像是在处理黏土原材料，可以将其放进窖中烧制成钢筋”。
KAFKA 和 STORM
当需要快速、实时分析时怎么办?Kafka 可以帮助你。它已经发展了大概五年时间，但最近才成为一个流处理的流行框架。
Kafka 诞生于 Linkedin 公司的内部项目，是一个快速查询系统。至于 Kafka 的缺点呢? 它太快了，实时的操作也导致了自身的错误，且偶尔还会遗失信息。
Driscoll 说：“在精度和速度之间总需要做权衡，所以硅谷所有的大公司一般都双管齐下： 用 kafka 和 Storm 进行实时处理，用 Hadoop 做批处理系统，虽然会慢一点但却十分精确”。
Storm 是另一个用 Scala 写的框架，且它在硅谷以擅长流处理而受到极大的关注。毫无疑问， Twitter， 一个对快速消息处理有着巨大兴趣的公司会收购了 Storm。
荣幸的提到：
MATLAB
MATLAB 已经存在很长时间了，尽管价格昂贵，但它仍在某些特定领域被广泛使用： 机器学习研究、信号处理、图像识别等领域。
OCTAVE
Octave 与 Matlab 非常相似，只不过它是免费的。然而除了信号处理的学术圈之外很少见到使用。
GO
GO 是另外一个获得关注的新手。它由 Google 开发，与 C 有一定渊源，且在构建稳定系统方面与 Java 和 Python 展开了竞争。
更多阅读：
- 数据处理包括清洗数据、连接数据并把数据转化成可用的格式；
- “诱人的部分”则是数据预测分析和建模。
199IT大数据导航，汇集1000多款与数据相关的工具（http://hao.199it.com/ ），欢迎分享收藏！
更多阅读：
更多阅读：
具体特点分析如下：
一、收入保持稳定增长，增幅有一定回升
今年前5个月，我国软件产业实现软件业务收入8608亿元，同比增长27.2%，增速低于去年同期1个百分点，但比1-4月提高1.2个百分点。其中，5月份完成软件业务收入2087.7亿元，同比增长30.8%，比4月份提高5.6个百分点，环比增长12.5%。
二、运营类服务持续快速发展，嵌入式系统软件增长加快
1-5月，数据处理和运营服务实现收入1480亿元，同比增长38.4%，高于全行业增速11.2个百分点，占全行业比重(17.2%)比去年同期提高1.4个百分点。嵌入式系统软件实现收入1407亿元，同比增长28.8%，高于去年同期2.4个百分点。软件产品和信息系统集成服务增长较为平稳，分别实现收入2864和1774亿元，同比增长24.3%和23.8%。信息技术咨询服务略有波动，实现收入788亿元，同比增长26.3%，增速比1-4月回落5.4个百分点。
三、软件出口和外包服务持续低位增长，5月开始有回升趋势
自2011年下半年以来，软件出口增速始终在20%以下，低于全行业增速10个百分点，今年前4个月增速连续下滑，但5月份开始有所回升。1-5月，软件业实现出口134亿美元，同比增长11.5%，增速低于去年同期9个百分点，但比1-4月上升1.3个百分点。其中，外包服务出口29.4亿美元，同比增长26.4%，增速低于去年同期20.1个百分点，但比1-4月上升2.8个百分点。
四、西部地区增势突出，中部地区下滑明显
西部地区软件业持续高速增长，1-5月完成软件业务收入857亿元，同比增长31.2%，增速高出全国平均水平4个百分点，其中重庆、陕西增速均超过30%;中部地区增长乏力，2011全年仅有两个月增速超过全国平均水平，今年前5个月完成软件业务收入214亿元，同比增长16.5%，增速低于去年同期12个百分点，低于全国平均水平10.7个百分点，占比(2.5%)比去年同期下降0.2个百分点;东部地区和东北三省保持平稳增长，分别完成软件业务收入6717和820亿元，同比增长26.9%和28.1%。
五、中心城市增长较快，服务化发展领先全国
1-5月，全国15个副省级中心城市实现软件业务收入4783亿元，同比增长28.9%，增速比1-4月提高2.2个百分点，高于全国平均水平1.7个百分点。中心城市软件产业的服务化态势更为明显，信息技术咨询服务、数据处理和运营服务收入增速分别达32.7%和36.2%，两项占全部收入比重达到27.2%，超过全国平均水平0.8个百分点。
