解决方案:WEB信息发布的"自动采集"方案的研究

　　解决方案:WEB信息发布的"自动采集"方案的研究

　　WEB服务器根据访问者的申请，向数据库服务器申请数据；数据库服务器根据WEB服务器的应用，将数据反馈给WEB服务器；WEB信息发布的“自动采集”方案 WEB信息发布的“自动采集”方案 方案研究总结：目前大部分网站在发布信息时采用类似“留言板”的形式，即人负责发布信息的人员将要发布的信息输入到特定WEB页面的输入窗口中，然后提交到数据库中发布到网站上——信息只能一条一条添加，效率低下。这里作者提出了用程序自动采集信息的思路，并给出了详细的解决方案。关键词：WEB信息发布、逐项添加、自动采集 1、提出问题 现在互联网已经普及，很多单位都有自己的网站。网站上通常会发布一些信息，一般以后台数据库的形式存在。目前，大多数网站在发布信息时采用类似“留言板”的形式，即由负责发布信息的人员将要发布的信息输入到特定WEB页面的输入窗口中，然后提交到数据库中对于在网站上发布的信息，只能逐项添加。现实中，一个单位可能有多个部门要在网上发布信息，但由于“网站”是一种媒体，本单位不会也不应允许各部门自行在网站上发布信息。通常的做法是：先让各部门将要发布的信息汇总到一个“审核部”，由该部门对信息逐条审核后集中发布。

　　在这种情况下，审查部门将有更多的信息发布。如果采用上述“一项一项添加”的方式，效率会很低。而且，手动将文本复制粘贴到WEB页面的输入窗口中——人工操作很容易出错。——这是问题一。另外，采用上述方法，只能发布纯文本信息。当有图文并茂的信息要发布时，往往需要找专业人士将原创

信息制作成网页，然后发布到网上。但这样一来，就很难对图文信息和纯文本信息进行统一的访问管理（如：全文检索、信息删除）——这是第二个问题。2. 初步想法我们的想法是：编写一个常驻程序，让它长期运行在某台电脑（一般是服务器）上，按照一定的周期，定期检索指定目录下要发布的信息，并将它们的分类追加到数据库中. 详见如下方案（如：<图1>）：（注：实际中FTP服务器、数据库服务器和WEB服务器可以用一台物理机实现，这里引用三台功能独立的服务器这里，只是为了方便描述工作流程。）信息发布者将要发布的信息以文档的形式上传到FTP服务器的分类目录中。FTP服务器上的驻留程序定期将获取的信息分类存入数据库服务器；信息访问访问者通过浏览器向WEB服务器申请信息；WEB服务器根据访问者的申请向数据库服务器申请数据；数据库服务器根据WEB服务器的应用，将数据反馈给WEB服务器；服务器将提取的数据组织成WEB页面的形式反馈给访问者的浏览器。

　　

" />

　　FTPWEB数据库 PC信息提供者 PC信息访问者 3.实现 显然，关键在于“常驻程序”。考虑到它需要完成的工作，首先设计数据库结构。1. 数据库设计 让我们来看看通常采集

哪些信息。它们通常包括：标题、正文、发布部门、发布形式、发布日期等。因为数据源是文件，所以文件名可以作为“标题”（这也符合日常习惯）。文本信息包括纯文本信息和带有图形和表格的信息。具体处理方案将在下篇“详解”中详细说明。关于“出版部门”和“出版形式”的信息来源，我们是这样解决的：制定一个目录作为存放信息源的根目录，并在该目录下为所有需要发布信息的部门创建以部门名称命名的子目录，我们称之为“一级子目录”（假设用户是学校，一级子目录可能包括“教务处”、“校办”、“教研室”等），在一级子目录下，再根据信息名称建立“二级子目录”可能使用的发布形式（例如：“新闻”、“通知”、“公告”等）。（例：<图2>）这样，如果某个部门要发布某种形式的信息，

　　同时，该方法还可以方便直观地对“出版部门”和“出版形式”进行增删改查。“发布日期”很容易获得。可以是信息采集到数据库的日期，也可以是信息文件生成的日期。这样数据库就需要有“标题”、“正文”、“发行部门”、“发行形式”、“发行日期”等字段。当然也可以根据需要增加一些字段，比如：“序列号”，作为数据库的唯一索引，用来区分不同的信息（这个字段很有用，后面会提到）；“是否为新信息”用于标识信息的新旧程度；“ 这种方式驻留程序的工作很简单，但是由于数据是由WEB服务器添加到网页中的，浏览器会按照HTML的语法进行解释。进行转换（例如：如果您希望访问者在浏览器中看到“大于”符号，即“>”，则需要将“>”转换为“>”）。

　　

" />

　　这样，只需要在网页中额外添加一段脚本就可以实现这种转换。我们不推荐这种方式，因为每次访问信息都要执行这个脚本，会增加WEB服务器的负担。下面的方法是我们推荐的：常驻程序将文本文件的文本转换为HTML，作为“文本”字段的内容。其实就是把前面方法中在网页中添加的脚本的工作放到常驻程序中去实现。这样每条信息只需要进行一次转换，制作网页时只需要直接引用“文本”字段，也减轻了WEB服务器的负担。至此，我们只解决了纯文本信息的采集。对于用图表采集

信息，我们考虑这种方式。由于带有图文表格的信息一般都是用Microsoft Word和EXCEL编辑的，这两个软件都具有将WORD和EXCEL文档保存为WEB页面的功能。我们要求用户先将图表的WORD和EXCEL文档保存为WEB页面，然后将生成的HTML文档和资源文件夹一起上传到FTP服务器。当常驻程序处理这些信息时，它必须做两件事。1）HTML文档（以下简称“正文”）中“”到“”（不包括“””）部分作为“正文”字段的内容。这里需要注意的是，因为WORD和EXCEL生成的HTML文档中的排版格式都是用“样式”设置的，而引用时不需要这些样式，所以“正文”中的“样式”也必须收录

. 删除所有部分。

　　2）将“资源文件夹”移动到与引用它的WEB页面相同的目录下。这里还要注意一个问题，就是“资源文件夹”可能重名，这就需要用到我们前面讲到的“序列号”字段。因为“序列号”对于每条信息都是唯一的，我们可以将“资源文件夹”的名称改为“序列号”字段的内容来保证其唯一性（当然要修改“资源文件夹”的名称文件夹”，还需要对“正文正文”中原引用的“资源文件夹”中的资源路径进行相应的修改）至此，我们就解决了两类信息的采集问题。4. 总结与补充 经过一段时间的推广，我发现“自动采集

”的方式很容易被普通用户接受。数据采集

过程对最终用户来说几乎是透明的——对于发布信息的人（信息提供者）来说，不需要知道信息是如何在网站上发布的，只要信息文本是“正确交付”；对于网页生产者（信息使用者）来说，他们不需要关心数据库中的信息是怎么来的，只要能直接使用就可以了。这样一来，两者的任务独立，分工明确，相互牵扯较少，整个信息发布过程比以前更加可靠。当然，“自动采集”还可以在功能上进行丰富。非常欢迎有兴趣的朋友参与我们的研究，使这个程序更加完善。注：本文完全原创，不存在任何引用。作者信息：姓名 单位，江苏电大武进学院，通讯地址，江苏电大武进学院——电话，邮箱，WEB服务器发布的WEB信息，根据访问者的申请自动采集

，以申请对于数据库服务器中的数据，数据库服务器会根据WEB服务器的应用，将数据反馈给WEB服务器；

　　事实:掌握数据生命周期：用户行为数据的4个来源

　　数据采集​​是整个数据生命周期的起始环节，嵌入数据是驱动业务的指标，这一切都需要以数据为基础。那么，我们需要采集

哪些数据呢？

　　说到数据驱动的业务，就离不开数据是怎么来的。数据采集​​是整个数据生命周期的初始环节。

　　之前的一篇文章中提到了对数据生命周期的一般介绍。虽然我打算重构文章的部分内容，但是这部分的基本链接并没有太多改动。

　　文章会涉及到很多技术知识，我会尽量减少这部分的细节。相信经过一系列的讲解，你会明白埋藏的数据是如何成为驱动业务的指标的，文章也会提供互联网上的公开数据，帮助你实际操作。

　　采集

的数据可分为四种主要类型：行为数据、网站日志数据、业务数据和外部数据。

　　1. 网络日志数据

　　网站日志数据是Web时代的一个概念。

　　用户浏览的每一个网页都会向服务器发送一个请求，所以不必关注具体的技术细节。你只要知道，当服务端和用户产生数据交互时，服务端会记录这次交互，我们称之为日志。

　　127.0.0.1 – – [20/Jul/2017:22:04:08 +0800] “GET /news/index HTTP/1.1” 200 22262 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/ 537.36（KHTML，如 Gecko）Chrome/60.0.3112.66 Safari/537.36”

　　上图是一个服务器日志，它告诉我们什么样的用户在什么时间段什么时候进行了什么操作。

　　127.0.0.1是用户IP，也就是什么样的用户。不同用户的IP不一致，基本可以通过它来区分和定位人。[20/Jul/2017:22:04:08 +0800]是这条记录产生的时间，可以理解为用户访问的时间戳。

　　“GET /news/index HTTP/1.1”是服务器处理请求的动作。这里认为用户请求访问某个网站路径，/news/index.html。这里省略域名。如果域名是 ，那么用户访问的完整地址，顾名思义，就是用户浏览了新闻页面。那是什么。

　　谁、什么时候、什么构成了用户行为分析的基础。Mozilla/5.0字段是用户浏览时使用的浏览器，其分析意义不如前三个。

　　根据who分析，我们可以知道网站每天的PVUV；根据 when 分析，我们可以知道平均浏览时间和每日访问高峰；what可以知道什么内容比较有吸引力，用户访问的页面深度，转化率等等属性。

　　在上面的例子中，我们使用IP数据来指代用户，但是用户的IP并不是固定的，不利于数据的统一性和准确性。在实际应用中，开发者还需要通过cookie或token获取用户ID，并将用户ID传递给日志。它将是以下形式：

　　127.0.0.1 – 123456 [20/7/2017:22:04:08 +0800]…

　　123456为用户ID，通过它可以关联后台的用户标签数据，进行更多维度的分析。

　　案例的服务器日志记录了用户的浏览数据，是标准的流量分析要素。但是网站上还会有其他的功能，也就是更丰富的东西，比如评论，采集

，点赞，下单等等，这些行为光靠日志是统计不出来的。因此，除了服务器日志，业界还会使用JS嵌入或者后台采集来采集各种业务场景的数据。

　　这里我提供一个在互联网上公开的数据集。比较老了，是一个学生在校园网站浏览行为的数据集。数据原创

格式为log，可以txt打开。需要的同学可以后台发送“日志下载”。

　　它是一个标准的服务器日志文件。对于分析师来说，IP、时间、浏览了哪些网页这三个字段就足以做出一份完整的分析报告。在后面的章节中，我将围绕它进行演练。为了照顾新手，我会同时使用Excel和Python进行演示。

　　从简单的清洗开始。如果是Excel，直接复制内容。文件开头的内容只需要保留第四行Fields信息，就是数据的字段。将内容复制并粘贴到 Excel 中。

　　根据空间整理，初步的数据格式就出来了。

　　如果我们仔细观察cs-uri-stem，会发现很多无用的数据。比如/images/index_r2_c1.jpg，它向服务器请求图片数据，对我们的分析帮助不大。用户访问的具体网页是那些以.asp结尾的网页，比如/index.asp。

　　

" />

　　使用过滤功能提取收录

.asp字符串的内容，只保留日期、时间、c-ip、cs-uri-stem、cs-uri-stem。按照c-ip和时间从小到大排序，这样用户在什么时间做了什么的行为顺序就很清楚了。

　　172.16.100.11这样的访问者在早上30:00访问了网站首页，然后浏览了校园新闻和每周日程相关的内容。整个会议持续了大约半个小时。

　　Python相关的清洗留到下一篇，这里不再多解释。有兴趣的可以先自己练习。

　　2. APP行为数据

　　数据埋点，抽象理解就是记录用户在客户端的关键操作行为，一行数据等于一条行为操作记录。点击“立即购买”，在文章页面停留5分钟，对文章发表评论，退出，在视频网站首页看到10个新视频……有必要，我们都采集

起来。

　　APP行为数据是在日志数据的基础上开发完善的。数据载体虽然在APP端，但也可以抽象出几个要素：who、when、where、what、how。

　　谁唯一标识用户。在移动端，我们可以很容易的采集

到user_id。一旦用户注册，就会生成一个新的user_id。

　　这里有个问题，如果用户没有登录怎么办？如果用户有多个帐户怎么办？为了更好的统一和识别唯一用户，移动端还会采集

device_id，通过移动设备自带的唯一标识码来区分。

　　实际的生成逻辑要复杂得多。Android 和 iOS 是不同的。device_id 只能接近唯一。用户更换设备后数据如何继承，未登录状态的匿名账号如何继承到注册账号，这些都会影响到分析。口径，不同公司的判断逻辑不一致，这里注意踩坑。

　　回到用户行为：

　　when 仍然是动作发生的时间。Where 是行为发生的位置。在手机上，通过GPS定位权限获取比IP更详细的经纬度数据并不难。具体行为是什么。浏览、点赞、评论、分享、关注、下单、举报、打赏都是行为。如何统计取决于分析的维度。如果我们想知道用户的点赞行为，那么我们可以让客户端在用户点赞的时候上报一条点赞消息。

　　如果你只是来这里，就不能称之为埋点，因为点赞本身也会被写入数据库，不需要客户端额外的采集和上报。在这里，引入了一个新的维度：如何。

　　如何点赞，以微信朋友圈为例。大多数点赞都是在朋友圈时间线中发送，但在小部分场景下，允许用户进入好友个人页面，对发布的内容进行单独点赞。服务器/后端不知道类似的事情发生在哪里，iOS 或 Android 客户端需要告诉它。这就是维度的用处。

　　换个思路，如果很多点赞或者评论不是发生在朋友圈，而是发生在朋友的个人页面。是否可以讨论一些产品要求？毕竟朋友圈信息流中的内容越来越多，很容易错过朋友的生活，所以会有一部分用户需要去朋友页看内容. 这里无意深究产品问题，只是说明即使是一样的点赞，场景不同，数据描述的角度也不同：点赞朋友圈的朋友/点赞的朋友朋友的页面。

　　除了场景之外，交互行为方式也需要客户端来完成。比如点击内容图片放大，双击点赞，视频自动播放，屏幕向右点触返回页面……产品体积小，这些细节都是微不足道。产品做大之后，产品会有这些细节需求。

　　行为埋点通常以json格式进行描述和存储，例如根据like：

　　params是嵌套的json，就是如何描述行为，业界通常叫行为参数，event就是一个事件。action_type是指如何触发点赞，page是点赞发生的页面，page_type是页面的类型。现在产品设计，在基于推荐的信息流中，除了首页，还会在top bar上划分子频道，所以page=feed，page_type=game，可以理解为游戏子频道上主页。item_id 是指喜欢具体的内容，item_type 是指内容类型，如视频。

　　以上字段构成了APP端行为采集的how和what。如果我们想的更完整，可以加上who，when等辅助字段。

　　如何设计埋点不是本文的重点（其实要复杂得多，需要大量的讨论和文档等等，以后有机会再说），因为每个公司有自己的设计思路和方法，有的比较复杂。根据控制统计，是无痕埋点。有兴趣的可以上网搜索文章。很多卖用户分析平台的SaaS公司都有文章详细介绍。

　　埋点统计除了行为“点”之外，还包括“段”的逻辑，即用户在页面停留的时间。这也是client-side processing的优势，就不多介绍了。

　　这里有一个不知道是什么内容产品的行为数据源，来自网络。虽然它的目的是作为推荐模型的算法竞赛，但它也可以用于用户行为分析。

　　这些字段是用户行为的基本字段，像deep_view，虽然没有明确说明是什么意思，但也猜测是描述了用户浏览的深度。比如在阅读了50%+的文章内容后，只能在客户端进行正式的统计，而实际的业务场景往往需要这种具有更深层含义的数据。

　　具体分析和实际操作将在下一篇文章中讲解。有兴趣的同学可以自行下载，和网志放在一起。

　　行为数据并非100%准确，在采集

用户行为时，会存在遗漏。对于支付等重要的统计口径，不建议使用嵌入式逻辑。缺乏口径会让人抓狂。相关统计仍依赖支付接口计算。支付相关埋点仅供分析。

　　

" />

　　APP行为数据往往涉及大数据架构。即使是10万DAU的产品，用户对产品的操作也会收录

几十甚至上百次操作。这些行为需要准确报告并收录

在报告中。对技术架构是一个很大的挑战。行为数据的加工处理不是mysql能搞定的，往往需要分布式计算。

　　对于数据源的用户、产品运营和分析师来说，都会有一个权衡的问题。如果我只想知道点赞数和分享数，通过API或者生产库也可以知道。是否需要在行为层面进行详细说明？这是收入的考虑。

　　当然我个人还是建议对分析有兴趣的同学去有用户行为数据的公司去研究。

　　3.业务数据

　　业务数据由生产环境提供。我们获取了用户的user_id，文章或商品的item_id，甚至是APP端的支付order_id，但都只是与用户的行为相关。也就是说，我不知道user_id是个什么样的用户。

　　是男是女，多大了？出生地，你从哪里来？这些人口统计信息不一定收录

在行为埋点中。产品内容订单也是如此。

　　仅仅依靠埋藏的行为数据，我们无法准确描述用户做了什么样的事情，也不知道他们做了什么样的内容。描述性数据/维度是分析的价值所在。男女行为差异和不同城市用户群体的购买习惯构成了分析提炼的基础。

　　业务数据和行为数据的结合，可以简单理解为数据层面的join。例如，将用户行为数据的user_id与存储用户信息的user_id关联起来。形成如下：

　　上图是简化的字段。user_name和sex是从业务数据中获取的用户信息，item_tag也是从内容信息表中的字段中获取的，event是从行为埋点中获取的。三者共同构成了什么样的用户在什么时间什么时候对什么样的内容做了什么。

　　简单的说，很多用户行为的建模就是把各种数据结合起来进行计算。使用user_id的粒度聚合，可以计算出这些用户喜欢哪些文章，使用item_id的粒度聚合，可以计算出哪些类型的用户喜欢这篇文章。它们都是您看待/分析事物的角度。

　　在更深层次上，行为数据还可以被重新加工利用，这是用户标签的基础。以浏览行为数据为例，我们设计了一个埋点，可以知道王二狗看了什么类型的文章。

　　item_tag 是文章的类型，比如游戏、娱乐、科技等。有些用户可能喜欢各种类型，而有些用户的口味偏好更集中。产品可以称为用户偏好，具体指兴趣的集中度。

　　现在拿所有用户的浏览数据，计算他们在不同类型标签下的浏览分布（可以计算上面提供的行为数据，cate_id为内容类型）。比如王二狗90%的浏览是游戏，10%是其他，可以认为王二狗的兴趣集中度很高。

　　这里有一个很简单的公式，1-sum(p^2)，将所有内容类别的浏览率的平方相加，最后减1，计算出用户兴趣的集中度。我们简单看一下这个案例。

　　上图中的李二狗，90%的兴趣都在游戏上，所以兴趣集中度=1-(0.9*0.9+0.1*0.1)=0.18，李三牛的兴趣稍微平均一点，所以1-(0.5*0.5 +0.5*0.5)=0.5，兴趣集中度比王二狗还高。

　　赵四有三分兴趣，所以比李三牛略高，而王舞平衡，所以他是四人中最高的。可能有同学会问，为什么不用标准差来计算兴趣水平呢？它也被计算为波动偏差。这是一道思考题。您可以添加一个新的标签类别并重新计算。

　　1-sum(p^2)接近1，有四种类别，一个平衡用户（四个都为0.25）是集中度0.75，当有十种类型时，一个平衡用户（四个都为0.1）是浓度为 0.9。这个公式的好处是兴趣类别越多，集中度上限越接近1，不能和标准差比较。

　　这里不涉及高深的数学模型，只是用加减乘除快速计算出兴趣的集中度。通过行为数据计算出用户兴趣的集中度，然后就可以在分析场景中使用。它是用户画像的基础，后面会深入讲解。

　　4.外部数据

　　外部数据可以分为两部分，一是行业市场调研，二是爬虫爬取。也可以作为数据源进行分析，比如站外热点内容和站内热点内容，竞争对手的表现和自己的产品，有机会用到的商家不多，就不说了说说吧，我也不是很熟悉。

　　至此，文章主要讲了用户行为层面的数据是怎么来的，更多的是讲了一些基本的概念。但是由于数据来源于互联网，数据的丰富性还欠缺很多。说白了就是业务场景比较弱。希望大家在工作中多多思考。

　　#专栏作家#

　　秦璐，微信公众号：tracykanc，人人都是产品经理专栏作家。

　　本文首发于人人都是产品经理。未经许可禁止转载。