B*******1
发帖数: 2454 | 1 How do you implement the following feature which Amazon uses on its website?
"What Do Customers Ultimately Buy After Viewing This Item?"
81% buy this item
10% buy item B
9% buy item C |
r*******g
发帖数: 1335 | |
y*******g
发帖数: 6599 | 3 我一直想知道这个，，在用amazon的时候
website?
【在 B*******1 的大作中提到】
: How do you implement the following feature which Amazon uses on its website?
: "What Do Customers Ultimately Buy After Viewing This Item?"
: 81% buy this item
: 10% buy item B
: 9% buy item C
|
g**********y
发帖数: 14569 | 4 1. Amazon保存了所有用户的browing history和buying history
2. Amazon把书(物品)分很细的类
case 1. 如果该类东西足够多，就把看过那页的用户，和看过之后近期内买了该类东西的用户做个交集，对交集用户，取他们的购买选择计算，统计排行榜，取最高的3～5个显示。
case 2. 如果该类东西不够多，就在父类或祖先里搜索，直到足够多数据。
这些计算量是很大的，我不认为他们是实时生成的，而且也没必要。应该是overnight
在server算出来的。
有意思的是，好象现在Amazon把这个功能摘掉了，换成“Frequently Bought Together
" 和 “Customer Bought This Item Also Bought"
我觉得可能是有厂家不满，这个算法很容易导致马太效应，做得好的，或口碑好一点的
，迅速拿下大部分可以左右的客户。同类的新产品很难与之竞争。
website?
【在 B*******1 的大作中提到】
: How do you implement the following feature which Amazon uses on its website?
: "What Do Customers Ultimately Buy After Viewing This Item?"
: 81% buy this item
: 10% buy item B
: 9% buy item C
|
B*******1
发帖数: 2454 | 5 火鸡可以具体说说每一步具体用什么数据结构实现吗？
thanks |
g**********y
发帖数: 14569 | 6 就我的理解：
1. 用户browse history, 这个用简单database table就可以，保存：user_id, page_
id, browse_time
2. 用户buying history, 这个也可以用简单table, user_id, product_id, buy_time
3. page -> product的link, 用table: product_id, page_id
4. product category, 用table: product_id, category_id
算法实现：
1. find all (user_id, page_id, browse_time) where page_id = xxx
2. for page_id, find product_id, then category_id.
3. for all result in step 1, only keep record who buy same category product
in browse_time + GAP_TIME (for example 1 week)
4. count remaining results, get top 3 product_id
这些计算看上去都是SQL就可以做的，对大规模的数据来说，可能处理时需要技巧，那
是我不熟的。
数据结构都是根据用的算法来选择，我不清楚以上环节哪儿是计算的瓶颈，需要特殊算
法，该用拿种算法，这些都需要实际经验。
【在 B*******1 的大作中提到】
: 火鸡可以具体说说每一步具体用什么数据结构实现吗？
: thanks
|
B*******1
发帖数: 2454 | 7 en. 我也觉得像数据库的东西。
再问一个问题，facebook里面那些friend的mutal friend，或者friend之间的关系，你
觉得是用数据库query出来的，还是graph 算出来的呢？ |
g**********y
发帖数: 14569 | 8 那个是用graph计算，算法上可以简化计算量和存储空间。数据库是没法这样优化的。
【在 B*******1 的大作中提到】
: en. 我也觉得像数据库的东西。
: 再问一个问题，facebook里面那些friend的mutal friend，或者friend之间的关系，你
: 觉得是用数据库query出来的，还是graph 算出来的呢？
|
B*******1
发帖数: 2454 | 9 看到一个面试题，忘记是F还是G的了，A一堆朋友，B一堆朋友，应该用graph里面的哪
个算法算出mutal friend啊？
thanks |
g**********y
发帖数: 14569 | 10 F的，你说的那个应该是算两人的最短距离。一种算法是象画同心圆一样，A, B轮流增
大半径1，直到相交。
【在 B*******1 的大作中提到】
: 看到一个面试题，忘记是F还是G的了，A一堆朋友，B一堆朋友，应该用graph里面的哪
: 个算法算出mutal friend啊？
: thanks
|
B*******1
发帖数: 2454 | 11 这个算法怎么算出公共的friend呢？
可以给个具体点例子吗？
譬如a->b
a->c
a->d
b->d
a和b本身是friend了，距离1，但是d是a和b的mutal friend，现在要算出所有类似d这
样子的mutal friend，似乎算最短距离不行啊
【在 g**********y 的大作中提到】
: F的，你说的那个应该是算两人的最短距离。一种算法是象画同心圆一样，A, B轮流增
: 大半径1，直到相交。
|
g**********y
发帖数: 14569 | 12 公共的朋友直接算不就行了，就是求两个set的交集。
【在 B*******1 的大作中提到】
: 这个算法怎么算出公共的friend呢？
: 可以给个具体点例子吗？
: 譬如a->b
: a->c
: a->d
: b->d
: a和b本身是friend了，距离1，但是d是a和b的mutal friend，现在要算出所有类似d这
: 样子的mutal friend，似乎算最短距离不行啊
|
