preg_replace
preg_replace(“/订单号:(\d+)/iu”,”订单号:<a target=_blank href=’orderid=\\1′>\\1</a>”, $item['logcontent']);
预授权完成,下单成功 [订单号:16112211395149] [下单用户:281881182871553
preg_replace(“/订单号:(\d+)/iu”,”订单号:<a target=_blank href=’orderid=\\1′>\\1</a>”, $item['logcontent']);
预授权完成,下单成功 [订单号:16112211395149] [下单用户:281881182871553
http://www.open-open.com/lib/view/open1455610675323.html
python
哈哈哈哈~
最近一个月都在搞数据的事情,搭框架,整报表,现在基本的都搞出来了,回头看看数据,发现做数据也是挺有意思的,但是做基本的数据我已经做了很久,想做的更加高大上一点,这就需要不少的数学知识了,所以这几天在找一些数学知识,想补一些回来,回想当年,曾经也可能往数学的方向走得很远,虽然最后自己放弃了,但是还是在潜意识,把这个方向当成可选的一个,现在,如果有时间有机会,想再拾起一些
本月到6月底,要读4本书哦,去年的阅读计划没有完成,今年要努力的完成,不能偷工减料哦;
最近在写流量魔方的评论,发现几个问题:
1. 新行业、老行业和大客户的行业分类不一致,比如游戏行业:大客户是单机游戏、端游、网页游戏,是按照游戏的类型来分的,算出来每一类每天的pv都差不多,新行业的是游戏开发、游戏运营和游戏周边,按产业链或者其他来分的,但是在已购词中pv分布太不均匀了,游戏运营占了全部流量的98%,其他两个大的二级行业连2%的流量都没有占到,我不知道实际是怎么样的,但是从游戏开发在整体的流量只占了0.06%来看,这个分法是有问题的,还有如网页游戏,这个到底应该是分到游戏运营->网页游戏中,还是游戏开发->网游开发,两种都是可以商量的,相比之下,老行业分类更乱,网游和游戏开发是并列的两个子类,个人觉得大客户的分类方法最好,至少他们分类标准一致,不会出现一个词既出现在a类又出现在b类这种混乱的情况;
这个和我接下来想做的一件事是可以合起来思考的,打算把大客户行业作为一个重要的标准,然后在之上做一些其他的业务分类,就是游戏既可以按照游戏类型分类,如端游、页游,也可以按照产业链来分,如游戏开发、游戏运营、游戏周边等等,但是这些分类是交叉的,一个词既有游戏类型的标签也可以有其他的标签,就和我们看问题一样,是可以从多个维度来思考问题,这个已经开始做了,预期一个月就能看得到一些效果出来;
2. 地域分布还是太明显了;基本上所有的行业流量和消费第一都是广东,然后二三基本上就是江苏,浙江,上海和北京,偶尔会有山东河南这些省份,还有一些有意思的事情,比如博彩游戏第一的是湖北,小游戏第一的是河南,靠海的这一线消费都不错,无线基本上大家都很平均,基本上消费是pc的1/10或者更少一点,pv和uv已经接近一半;
3. 无线的潜力非常大,2012整体的pv超过了1000亿,但是只出了47亿的广告,同时间pc的是2900亿和700亿,这说明什么,只要无线达到pc的一半水平,就能现在的基数乘以3,当然无线有他自己的一些问题,不能简单的乘除,不过确实这一块的潜力非常大,其他还有一些特点,如系统流量是android第一,大概是ios的3倍以上,浏览器ucweb占了1/3的流量,远大于其他的,qq是ucweb的1/3,百度浏览器是ucweb的1/20,增长潜力还是很大的,网络方面2g占了接近一半,也没看出明显下降的趋势;
还有很多其他的,其实做分析是一件很好玩的事情,可以得到很多有意思的结论;但是其实也有最大的一个问题,就是如何把这些和钱结合起来,流量魔方有这个很明显的问题,一个数据接着一个数据往上面放,但是没有收入就没有kpi,没有kpi这个事情的压力就很大,要人没人,要资源没资源,只能不停的往里面塞东西,希望在有一天老大的耐心耗完之前,找到可以增长的地方;
最近精力都放在抓取上,放在pvstat拆库,还有一些杂七杂八的事情上,流量魔方这一块放的少许多,看了一下上个版本发版的时间,3.18,现在下个版本的发版时间大概在5.20日,整整过了两个月,这个速度太慢了;接下来也要总结一下这个问题,为啥这个事情做了这么长时间,和我做快抓一样,一个多么简单的东西,做了两个月,迭代的太慢了;做后台两周,做网站2周,然后改版又两周,最开始做出来别人连怎么用都不会,现在好歹我自己可以很方便的去用这个东西了;
不过anyway,事情总是让人开心的,我们在创造事情,不管做的好或者坏,做的快或者慢,我们在看着一个本来没有的东西,慢慢的慢慢的长大,虽然可能变得臃肿,但是只要我们努力点,他一直在成长,不是么;
我们的产品要做什么事情,一直是很纠结的问题;产品是需要跟着需求来走的,一般来说,我们的用户他们有一些什么样的需求,我们才能知道做一些什么样的事情,如果仅仅是根据自己大脑来推测,很多事情都会做出来成为无缘之木,流量魔方往哪个方向上走,一直是很纠结很痛苦的问题;
第一步,最简单的一步,我想把他做成一个宏观上指导公司方向的产品,我们的很多产品,如dashboard如pulse,做的都是统计分析的事情,或者仅仅是统计,我不愿意魔方只是一个统计产品,这样的事太多人在做了,各个部门都在做,有那么多的数据中心,其实到后面没有一个成为牛逼的东西,我想把魔方做成一个宏观上能够指导方向的这么一个产品,那么必然不仅仅是统计了,还需要分析,还需要预测,这些方面,不仅仅需要有工程能力,我们做的系统能够支持这么维度的统计,另外一方面,需要对业务的理解力,我们的pm我们的rd包括我自己,在这个行业中的从业能力都比较短,资历都比较浅,我们还在高速的学习,这个事情,我们其实也在不停的做,数据挖掘,不仅仅是需要基本功的扎实,还需要对这个行业有更深的了解,第三个方面,就是数据挖掘的基本功了,我们的学习能力都不错,但是这方面还是比较欠缺的,这些都是之后需要不断提高的;
这是宏观的事情,另外一个方面,还有微观方向的事情了,支持做一两个词的分析,支持做一个主题的分析,就是对一些具体的细微的自定义的事情,可以做深入的分析,对这些主题,我们其实也在思考,主题分析走的是第一步,我们先要明白用户想要做什么,首先要明白怎么去定义主题,比如光棍节这样一个事件我们到底怎么怎么去定义了,我们先要明白用户想干嘛,他是哪个行业的,他要在光棍节做一个什么样的事情,这些问题,对一个上海地区卖男装的广告主来做分析和对一个期望利用光棍节流量做资源布局的管理人员来说,他们如何去定义这个事情是不一样的;这些细微的事情,有整个网民的搜索行为,有某一个网民的搜索特征,我们的产品,好多都太简单了,要么就是用户的痛点没抓到,都去做一些别人不想要的东西,要么就把别人真正想要的东西都丢掉了;这些要做的事情,还非常非常之多,我们还刚刚开始;
我想做的就是搭一个平台,让真正需要做这些事情的人,从简单的单调的统计中解放出来,而去做真正的他们想要做的事情;我想做的,接下来可能分为两个方向,一个是工程的,从底层的把这个框架搭起来,类似于淘宝魔方的底层框架,做一个通用的支持框架;另外一个方面,就是在业务上不停的飞快的走,迭代速度快是一个优势,停下来也许这事情就停下来了;
记得上周拿到一张做产品的九步法,我觉得这九步非常的重要,但是只是看貌似没有意义,所以我拿结构化提取来做一个例子;
1. 产品满足用户的哪一个核心需求
答:结构化提取时面对知心这个项目提出来的产品,目标是快速,准确的对具有相同结构的网站进行抓取:主要是解决两个问题:
1.对一个网站能够快速的配置;
2.对于配置能够准确的获取结果
不过核心需求就是快速准确的获取想要的结果,准确是第一位的,快速是第二位的
2. 与同类产品相比你的独特性是什么
1. 支持通用的配置(这一点其实是有疑问的,如果解决通用的需求,这个产品就有问题)
2. 能够快速配置(不出问题),并能进行快速验证
3. 对批量的url能够支持抓取,并在可以忍受的时间内获得结果
3. 分解用户,根据产品的核心价值,将用户分解成不同的群体
1. 一种是一次性的,配置一次,抓取一次,结束,
2. 周期性的进行抓取,这种需求对于一些需要进行观察的网站需要做这些处理
目前主要的需求还是以第一种为主,其实大部分都是第一种的需求,就是一次性的去获取一些数据,然后就是结束了
4. 变成用户,回答一下两个问题:
4.1 该用户为什么会使用这个产品
因为自己去抓太费资源了,也太麻烦了
4.2 该角色如何知晓和到达这个产品
通过发通报邮件告知
5. 确定角色成就,确定产品如何满足不同角色的成就感
需要有成就感这个东西么?
6. 确定用户需求满足过程中的关键点
最重要的点就是不要出错,然后能让用户从头到尾走完
7. 提升关键点的转化率
提升关键点最简单的办法就是用,让我们的用户去用他,让我们自己去用他,只有通过使用才能发现不足的地方,目前就是使用的太少了,包括我们自己都用的太少了
8. 形成闭环
可以自己做一到两款垂搜产品,通过这个来形成闭环,通过自己不断的去提出新的需求,去解决这些问题;
9. 大干快上,快速迭代
今天和一个本科同学聊天,讲到如何创业,说起他们现在在做的一个项目,持续了大概半年,但是一直在纠结的阶段,大家觉得这个事情可以做,但是具体如何做还有很多疑问,有很多困难,也找vc去聊过,但vc的水分也很多,聊到具体的事情,就牵扯到很多细节,自己也没想清楚,就更加说不清楚了,更重要的是,他说现在他们是一个松散的群体,很多事情没办法按照公司的制度去做这些事情,所以很多事情都停在那里;我提出的一些方法和一些观点,他也了解和认同,但是很多确实没办法去实施,我没做过类似的事情,所以打算做做研究之后,再论证他的观点;
但是有些观点至少我现在是清楚的,就和现在做事情一样,一个团队需要分为两拨人,一拨人拼命的卖项目、卖点子,说白了,就是销售,这些人需要把我们的想法项目抽象成客户可以理解的东西,抽象他们的需要,然后让他们买单,这个事情很重要,其实可以说是一个项目能否成功最重要的一点,只有能卖出去的东西才能有活下去的意义,找到卖家,挖掘他们的需求,抽象他们的想法,让他们为我们买单,这是我们做所有事情最重要的一环,比如同样是spider,做成一个自己玩的spider和一个baidu,对最开始架构他的那些人,所得到的成长是不一样的,而至少在当今国内的这个环境里,需求推动才是最关键的;我其实也想像google做的那样,自己去挖掘一些点,然后把这些点去做出来,类似于android,类似于google glass这种玩意,但是实际了,android的老大最近也被干掉了,android事业部也被并到chrome里面去了,说明google董事会的耐心也快完了,想更快的把这个事情变现出来,但是anyway,我还是希望这一点从两个维度去做,一个是尽量让产品活下来,活下来的意思就是做一些迎合需求方的产品,服务于他们,让他们开心;另外一方面我希望我们做的事情会更有意义,会帮助更多的人或者去做我们想做的有意思的事情,即使他没有商业价值,即使短期内他看不到什么意义,但是从长远看,至少是一件有意思的事情;
另外一个方面是工程的事情,工程最重要的就是实现,从两个维度思考这个问题。。。第一、够用;第二、成本,够用的意思就是能够满足业务的需要,淘宝的底层为啥做的很好,架构为啥很牛逼,无非就是需要满足业务的需要,不满足你就完蛋,你就滚人,淘宝每天这么大的交易量,同时并发的后端数据库处理这么多,它的系统不牛逼,就完蛋了,当然,满足了需要的这套系统,就很厉害了;我们的很多系统,其实有方案一方案二方案三,其实哪一套做到后面都没啥问题,只要能满足业务需求就可以了,无非就是扩展性差一点,到时候返工多一点,所以现在我基本上也很难在架构上争了,也会做很多妥协,只要不是原则性的系统设计问题,都会放弃的(当年在这个地方上吃了很大的亏,所以现在看的淡了);性能不行,要机器呗,反正我也能控制机器,和op关系也好,少了机器就多要几台,总能解决的,但是有一个点,够用是一定要满足的;第二个很重要的事情,就是成本了,如果一个系统5台机器,需要两个人两个月做一套系统,使得整体性能提升20%,这样我肯定会选择加一台机器解决这个问题,2个人2个月的成本,一人月2万至少了,就是8-10万的成本,一台机器5000块,差了20倍,人是最重要的成本,把有限的人力放在最重要的事情上,这才是意义;
业务上把东西卖出去了,还没做就能看到前景;工程上把事情做出来了,能满足业务的大部分需求,甚至还有改进,这个事情就成了;
如果有时间,我们再做做,我们喜欢做的事情;