网站综合信息 webdataanalysis.net
- 标题:
- 网站数据分析 | 通过网站分析与数据分析实现网站优化
- 关键字:
- 网站分析 数据分析 Web Analytics 数据仓库 数据统计 用户体验 Data Warehouse User Expe
- 描述:
- 通过网站分析与数据分析实现网站优化——Web Analytics and Data Analysis for Website Optimization!
- 域名信息
- 域名年龄:14年3个月2天 注册日期:2010年01月27日 到期时间:2022年01月27日
邮箱:DomainAbuse 电话:
注册商:Alibaba Cloud Computing (Beijing) Co., Ltd.
- 服务器空间
- IP:96.126.124.131 同IP网站2个 详情
地址:美国 新泽西州Linode公司
- 备案信息
- 备案号:浙ICP备10018537号 审核时间:2014-01-26 详情
主办单位:吴盛峰 性质:个人
网站名:网站数据分析 首页网址:www.webdataanalysis.net
网站收录SEO数据
域名流量Alexa排名
域名注册Whois信息
webdataanalysis.net
域名年龄: 14年3个月2天注册时间: 2010-01-27
到期时间: 2022-01-27
注 册 商: Alibaba Cloud Computing (Beijing) Co., Ltd.
注册邮箱: DomainAbuse
获取时间: 2020年02月03日 11:55:30
Domain Name: WEBDATAANALYSIS.NET
Registry Domain ID: 1583283685_DOMAIN_NET-VRSN
Registrar WHOIS Server: grs-whois.hichina.com
Registrar URL: http://www.net.cn
Updated Date: 2019-12-16T07:16:51Z
Creation Date: 2010-01-27T12:38:04Z
Registry Expiry Date: 2022-01-27T12:38:04Z
Registrar: Alibaba Cloud Computing (Beijing) Co., Ltd.
Registrar IANA ID: 420
Registrar Abuse Contact Email: DomainAbuse
Registrar Abuse Contact Phone: +86.95187
Domain Status: ok https://icann.org/epp#ok
Name Server: DNS7.HICHINA.COM
Name Server: DNS8.HICHINA.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2020-02-03T03:55:07Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
Domain Name: webdataanalysis.net
Registry Domain ID: 1583283685_DOMAIN_NET-VRSN
Registrar WHOIS Server: grs-whois.hichina.com
Registrar URL: http://whois.aliyun.com
Updated Date: 2019-12-16T07:16:51Z
Creation Date: 2010-01-27T12:38:04Z
Registrar Registration Expiration Date: 2022-01-27T12:38:04Z
Registrar: Alibaba Cloud Computing (Beijing) Co., Ltd.
Registrar IANA ID: 420
Reseller:
Domain Status: ok https://icann.org/epp#ok
Registrant City:
Registrant State/Province: zhejiang
Registrant Country: CN
Registrant Email:https://whois.aliyun.com/whois/whoisForm
Registry Registrant ID: Not Available From Registry
Name Server: DNS7.HICHINA.COM
Name Server: DNS8.HICHINA.COM
DNSSEC: unsigned
Registrar Abuse Contact Email: DomainAbuse
Registrar Abuse Contact Phone: +86.95187
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>>Last update of WHOIS database: 2020-02-03T03:55:29Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
Important Reminder: Per ICANN 2013RAA`s request, Hichina has modified domain names`whois format of dot com/net/cc/tv, you could refer to section 1.4 posted by ICANN on http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.htm#whois The data in this whois database is provided to you for information purposes only, that is, to assist you in obtaining information about or related to a domain name registration record. We make this information available "as is," and do not guarantee its accuracy. By submitting a whois query, you agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to: (1)enable high volume, automated, electronic processes that stress or load this whois database system providing you this information; or (2) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via direct mail, electronic mail, or by telephone. The compilation, repackaging, dissemination or other use of this data is expressly prohibited without prior written consent from us. We reserve the right to modify these terms at any time. By submitting this query, you agree to abide by these terms.For complete domain details go to:http://whois.aliyun.com/whois/domain/hichina.com
网站头文件(HTTP Header)
HTTP/1.1 200 OK 服务器:nginx/1.8.0 访问时间:2020年02月03日 11:55:26 类型:text/html; charset=UTF-8 Transfer-Encoding: chunked 连接:keep-alive 语言环境:PHP/5.6.15 动作:Accept-Encoding, Cookie 缓存控制:max-age=3,必须更新 WP-Super-Cache: Served supercache file from PHP 网站编码:UTF-8
同IP网站(同服务器)
其他后缀域名
网站首页快照(纯文字版)
抓取时间:2020年02月03日 11:55:26
网址:http://webdataanalysis.net/
标题:网站数据分析 | 通过网站分析与数据分析实现网站优化
关键字:网站分析, 数据分析, Web Analytics, 数据仓库, 数据统计, 用户体验, Data Warehouse, User Experience
描述:通过网站分析与数据分析实现网站优化——Web Analytics and Data Analysis for Website Optimization!
主体:
网址:http://webdataanalysis.net/
标题:网站数据分析 | 通过网站分析与数据分析实现网站优化
关键字:网站分析, 数据分析, Web Analytics, 数据仓库, 数据统计, 用户体验, Data Warehouse, User Experience
描述:通过网站分析与数据分析实现网站优化——Web Analytics and Data Analysis for Website Optimization!
主体:
网站数据分析通过网站分析与数据分析实现网站优化菜单跳至内容首页关于(About)文章专题推荐资料库网站地图(Site Map)怎样合理地定义用户流失19 条回复 很久没有更新博客了，这篇再写一些关于“用户流失”的内容。之前发布的网站的活跃用户与流失用户这篇文章对网站的活跃用户、流失用户及新用户流失做了定义，这里修正下对流失用户的英文叫法，一般对流失用户常用的英文为“churn user”，之前用的wastage、away、lost等都不是太规范。后来陆续有做相关分析的朋友问到流失用户的流失时间长度到底选择多长是合理的，尤其是《网站分析实战》这本书出版之后，我在里面有提到如何更准确地定义流失的时间长度，可能解释的比较简单，还是有朋友留言反馈这方面的问题，所以这里再用一篇文章解释一下。流失用户与回访用户 流失用户的定义请参考“网站的活跃用户与流失用户”这篇文章，要解释怎么样合理地去定义用户流失时间段长度的问题，需要先介绍一个新的指标概念：回访用户。这里的回访用户不是指Google Analytics上面的Returning Visitor（与新用户相对，指之前访问过网站的用户再次访问网站），这里的回访用户指流失之后再次访问网站的用户，即用户曾经流失过，满足流失时间期限内完全没有访问/登录网站的条件，但之后重新访问/登录网站。然后，根据回访用户数可以计算得到用户回访率，即： 用户回访率 = 回访用户数 ÷ 流失用户数 × 100% 回访用户率的数值大小间接地可以验证对用户流失定义的合理性。正常情况下，用户的回访率应该是比较低的，从业务的角度考虑，如果对流失的定义是合理的，那么很难让那些对你的网站已经失去兴趣的用户重新来访问你的网站。一般情况下，网站的用户回访率应该在10%以下，在5%左右的数值是比较合理的，对于成熟的网站而言用户回访率会稍高，而新兴的网站的用户回访率通常更低，尤其像手机APP这类用户易流失的产品。流失期限与用户回访率 用户流失的流失期限的长度与用户的回访率成反比，我们在定义用户流失时使用的连续不访问/登录网站的期限越长，这批流失用户之后回访网站的概率就会越低，并且随着定义的流失期限的增大，用户回访率一定是递减的，并逐渐趋近于0。那么如果选择合适的流失期间长度？我们可以设定不同的流失期限长度，进一步统计每个流失期限的用户回访率，并观察用户回访率随定义的流失期限增大时的收敛速度。如果以“周”为单位设定流失期限： 根据设定的不同流失周期的用户回访率的变化曲线，我们可以使用拐点理论（Elbow Method）选择最合适的流失周期。 拐点理论：X轴上数值的增加会带来Y轴数值大幅增益（减益），直到超过某个点之后，当X增加时Y的数据增益（减益）大幅下降，即经济学里面的边际收益的大幅减少，那个点就是图表中的“拐点”。比如上图中流失周期增加到5周的时候，用户回访率的缩减速度明显下降，所以这里的5周就是拐点，我们可以用5周作为定义用户流失的期限，即一个之前访问/登录过的用户，如果之后连续5周都没有访问/登录，则定义该用户流失。 所以，有个这个办法之后，就能更加合理地定义流失用户的统计逻辑，而之前要做的就是选择不同的流失期限分别计算用户的回访率，然后用统计的到的数值生成如上的一张带平滑线的散点图，问题就迎刃而解。本条目发布于 2013 年 8 月 8 日。属于 个人观点分享 分类，被贴了 用户分析 标签。作者是 joegh。网站数据分析的一些问题37 条回复 之前的文章——网站数据分析的一些问题2中主要整理了BI相关的问题，这篇文章主要想整理一些数据仓库相关的问题。因为最近重新在看一些数据仓库的资料和书籍，想把之前以及当前遇到的主要问题提出来（博客中有关数据仓库的相关内容请参阅网站数据仓库这个目录），同时自己也对数据仓库方面的知识进行下重新的整理和认识，而且很久没有在博客发新的文章了，不能让自己过于懒散了。 之前看过Inmon的《构建数据仓库》和《DW 2.0》，而另外一位数据仓库大师Kimball的《数据仓库生命周期工具箱》一直没有时间阅读，最近才有时间看完了大部分，就迫不及待想写点东西了。其实数据仓库领域普遍认为Inmon和Kimball的理论是对立的，两者在构建数据仓库上方向性的差异一直争论不休，谁也无法说服谁到底哪种方法更好。我的Evernote的笔记里面不知什么时候从哪里摘录过来了对两者观点的概括性描述，非常简洁明了而一针见血： Inmon vs Kimball Kimball – Let everybody build what they want when they want it, we’ll integrate it all when and if we need to. (BOTTOM-UP APPROACH) Pros: fast to build, quick ROI, nimble Cons: harder to maintain as an enterprise resource, often redundant, often difficult to integrate data marts Inmon – Don’t do anything until you’ve designed everything. (TOP-DOWN APPROACH) Pros: easy to maitain, tightly integrated Cons: takes way too long to deliver first projects, rigid 其实看了《数据仓库生命周期工具箱》之后，发现两者的观点没有那么大的本质性差异，可能随着数据仓库的不断发展，两者在整体的架构上慢慢趋同。基本上，构建统一的企业级数据仓库的方向是一致的，而Inmon偏向于从底层的数据集成出发，而Kimball则趋向于从上层的需求角度出发，这可能跟两者从事的项目和所处的位置有关。 有了上面这段高质量的概括，第一个问题——你更偏向于以何种方式搭建数据仓库（BOTTOM-UP or TOP-DOWN），分别有什么优劣势？——其实就不用问了，所以下面主要提几个在实际中可能经常遇到或者需要想清楚的问题：Q1、数据仓库的技术解决方案有哪些，这些解决方案的优势在哪，瓶颈在哪？ 随着数据仓库的不断发展和成熟，“大数据”概念的风靡，有越来越多的相关产品出来，最常见的技术解决方案包括hadoop和hive，oracle，mysql的infobright，greenplum及nosql，或者多个结合使用。 其实归纳起来就两类：一是用传统RDBMS为主导的数据库管理数据，oracle、mysql等都是基于传统的关系型数据库，优势就是有更严谨的数据结构，关系型数据库对数据的管理更加规范，数据处理过程中可能出现的非人为误差极小，而且标准的SQL接口使数据获取的成本较低，数据的查询和获取更加灵活和高效；但劣势也很明显，对海量数据的处理和存储的能力不足，当数据量达到一定程度的时候就会出现明显的瓶颈。而是基于文本的分布式处理引擎
最近查询网站