[QOTD]當一個人習慣使用一個系統, 或者是說對此系
統有一定的概念與差異, 甚者其歷史資料都在
其中而能夠加值的話, 此時的消費忠誠度是相
當高的.
*1
薦書系統語法的須求是被人挑戰出來的, 在做完
關連選購時, 有個姓項的同事問了個問題, 因為關連
選購必須要有一定的數量記錄才會趨於準確, 而我們
不像Amazon 那麼大, 所以至少一本書要達到有足夠
準確的關連選購至少要有50~100筆銷售記錄才行, 而
這個在博客來的單品銷售在不是熱門排行榜中的話,
可能要一至二星期才會有結果, 甚至是一至二個月.
當然當時跑一次關連選購的週期是設定在兩個星
期, 所以兩個星期內的資料一定是空的, 所以在這種
條件下要給使用者最新的資料是不夠的, 且書的銷售
往往有六成以上是新書, 因此若是超過這樣的時效週
期是很可惜的.
因為我去博客來時, 花最多時間的是交友系統,
所以一開始就跟個同事講這樣的概念, 後來就發展成
"遇見一個人", 但當時我在博客來的角色定位還是屬
於一個半空降的狀態, 所以到最後真正的演算法並沒
有用上, 而為了解決關連選購的問題, 我就利用交友
系統的概念做了個薦書系統的系統開發.
最早是在2004年中時, 在博客來做出一個原型
(Prototype), 但後來並沒有上線因為找不到行銷配
合的單位, 而在2005年中時, 我在花蝶系統做出進化
的演算法, 讓原本可能要兩個星期算一次的系統變成
只要一兩天就可以算完, 因此大大的增加其實用性,
而在2005年底左右就做完給花蝶使用的薦租系統上線
使用.
那次使用的架構是後來我應用在 MyZilla 這種
大型系統開發的經驗, 降低I/O數來換取速度, 因為
現在電腦CPU越來越快, 但I/O進步的速度是比較線形
的, 在上線之前, 還把原本是取前20個人行為來推薦
變成為前50個人隨機取20個人來總計, 這個Ideal 是
由Tom 來提出的, 因為他希望每次跑出來的結果都不
要都一樣, 但我也不可能無意義的增加其亂數, 所以
想出這個方法.
比較可惜的因為當時的輸出結果是疊床架屋的狀
況下, 所以浪費了不少I/O, 所以跑一次結果須要4至
8秒鐘, 遠超過我認為人的容許度, 若是能夠有目標
重寫的話, 我相信要在 2 秒內或更快跑完並不是不
可能, 後來這系統終於趕在加盟展前完成了.
事實上這系統應該是用在 Web 端比用在 POS 端
有意義, 若是放在 POS端的話, 最主要是拿來在加盟
展跟其他公司做不同的區格, 因為這樣的系統開發起
來是有很大的 Domain Knowhow 在 Trial and Error
的經驗上, 理論上真正要暴發其價值應該是租書遊戲
來做結合, 這樣才會有意義.
因為這種系統最重要的是跟使用者的互動與回饋
, 然後做到讓使用者的資料變成一個無法離開的忠誠
度系統, 最主要是當一個人習慣使用一個系統, 或者
是說對此系統有一定的概念與差異, 甚者其歷史資料
都在其中而能夠加值的話, 此時的消費忠誠度是相當
高的.
比較可惜的花蝶現在的狀態大概租書遊戲是要無
限期延遲, 不然以這樣的 CRM 系統做加值, 花蝶說
不定會變得更不一樣.
*2
**********************************************
*1
02/20/06 11:52 am, 現在要到竹圍, 但的確是
最近很晚進辦公室的一次, 但還可以跟同事們吃中餐
, 這樣就夠了, 因為早上說要有甚麼工作成果的話,
大概只有開會的份了, 因為工作狀態要進入的話, 至
少也是兩小時, 即使是9:00進辦公室, 11:00到中午
休息時間真的也成不了多少氣候.
*2
02/20/06 12:21 pm, 快到台北車站, 到這邊.
文章定位：
