最近讀蘇杰的《淘寶十年產(chǎn)品事》，這本書把電商產(chǎn)品層面的方方面面都點到了。我也曾經(jīng)在一家 Online Travelling Agency 的國際酒店頻道做了 2 年，通過各個團(tuán)隊角色的努力，2 年后轉(zhuǎn)化率提升了 100%。也貢獻(xiàn)幾個相關(guān)案例，時效性至 2013 年 6 月，且出于保密原因，部分?jǐn)?shù)據(jù)不一定真實，但大體的方向是真實的。因為案例本身就不系統(tǒng)，也就不按任何維度來劃分了。

這 2 年做了幾件事情，沒用的事情：訂單頁改版、詳情頁改版；有用的事情：支持國內(nèi)信用卡支付、10%優(yōu)惠、搜索優(yōu)化；效果未知的事情：著陸頁優(yōu)化。

訂單與詳情

其中，訂單頁、詳情頁改版因為沒有解決任何問題而沒有效用。改版是我畢業(yè)后 4 個月接手國際酒店做的第一件事，可能也是很多新手 PM 會犯的錯誤（其實真心感謝當(dāng)時的老大放手讓我作-_-b）。一方面，當(dāng)時我并沒有認(rèn)清 PM 的職責(zé)和優(yōu)化電商網(wǎng)站的關(guān)鍵要素，更多的做一些交互、視覺的工作。另一方面，我能發(fā)現(xiàn)一些用戶關(guān)心的問題，比如國內(nèi)用戶更傾向于在詳情頁選擇“單人間”、“雙人間”預(yù)訂，而不是在首頁/列表頁的篩選項選擇“一人入住”、“兩人入住”；在后者的流程里，很多用戶因為搞不清楚單人間、雙人間干脆就不訂了（那時還 12 年呢，出境游剛熱起來，很多用戶都是初級使用者）。但這個改不了，為什么？一般電商網(wǎng)站都是有自己的后臺的，可我們采用一家海外 OTA 的庫存，直接調(diào)用 API，人家的 API 不支持，我們就做不了。

國內(nèi)信用卡支付

其實在做 2 個頁面改版前，我有分析網(wǎng)站的轉(zhuǎn)化率漏斗，發(fā)現(xiàn)和行業(yè)平均值差距最大、對結(jié)果可能提升最大的是支付成功率。一般電商網(wǎng)站都不會有這個問題，為什么我們會有？為什么不首先解決？

上文提到，我們拿海外 OTA 的庫存，全靠調(diào)用 API。美國人的信用卡使用率非常高，因此這家海外 OTA 的支付接口也僅支持國際信用卡，但中國人信用卡普及率低，能海外支付的就更少了，很多用戶填了支付信息結(jié)果返回錯誤。那我們?yōu)槭裁床话阎Ц侗镜鼗兀窟@是因為那時國際酒店不是戰(zhàn)略重點，資源有限，技術(shù)上調(diào)用 API，ROI 最佳。

但有了前兩次失敗，我意識到，我是在“只能調(diào)用 API”這個既定前提下想解決方案的，但這個前提可能本身就有問題。如果在這個前提下我們難有作為，為什么不打破這個前提呢？我那時對技術(shù)成本沒有概念，于是覺得我們得本地化支付流程，把目前中國用戶使用率高的支付方式都接入進(jìn)來。這個方案不是沒人提過，但一直落實不了。這次內(nèi)因、外因加和，包括我也非常堅定（其實是剛出道想的少），算是立項了。

當(dāng)時公司策略主推信用卡不推支付寶（我居然想都沒想就接受了這個策略，也為后來埋下了隱患），我們就先解決國內(nèi)信用卡支付問題。方案就是我們建立了一張假國際信用卡，加入海外 OTA 的白名單，用戶支付給我們，我們再支付給海外 OTA。流程上的坑就不細(xì)說了，其實作為一個電商系統(tǒng)，我們也沒有兼顧不同的使用者。比如，這個系統(tǒng)不僅需要支持用戶、客服，還要支持財務(wù)和海外 OTA 結(jié)算，所以最小商品單位要一致，因為一開始沒有考慮這個問題，后來需求推翻重寫。

最終總算上線了，確實對轉(zhuǎn)化率有提升。然后那時很多用戶反饋沒有信用卡，為什么不支持借記卡、支付寶？我一開始就覺得應(yīng)該支持，但發(fā)現(xiàn)又坑了。

大家知道，預(yù)付酒店，實際流程是“信用卡預(yù)授權(quán)，等入住后再扣款”，體現(xiàn)在支付系統(tǒng)上，就是“預(yù)授權(quán)–>訂單確認(rèn)–>扣款”。如果在第三方支付上復(fù)用這套系統(tǒng)，就變成了“訂單確認(rèn)–>扣款”。很多時候，你看電商網(wǎng)站下單了，只不過是限時鎖定訂單，等用戶去支付；如果用戶限定時間內(nèi)不支付，就釋放庫存。但由于海外 OTA 的 API 不支持鎖定，我們?nèi)绻麖?fù)用現(xiàn)有流程就意味著要先替用戶支付以下單，而部分酒店庫存是不支持退款的（特價），我們肯定要承擔(dān)損失。由于又要開發(fā)一套支付流程，加上各種外因，這個項目就先暫緩了。

10% 優(yōu)惠帶來的改變

做完支付本地化項目，出境游也越來越熱，公司也開始考慮如何更好的做好國際酒店。當(dāng)時雖然沒啥資源追加，但是老板看到我們在價格上完全沒優(yōu)勢，就允許我們?nèi)W(wǎng)降價 10%。結(jié)果大幅度的提升了轉(zhuǎn)化率！也就在那個時候，我開始想對于電商網(wǎng)站，什么是最重要的因素，首先還是商品。（當(dāng)然也感覺產(chǎn)品經(jīng)理的價值觀“崩塌”了，笑）

別看就是降價 10%，其實也要考慮很多因素：究竟是直接在價格中減去好還是采用亞馬遜給出優(yōu)惠碼的模式？優(yōu)惠用直減方式還是返現(xiàn)方式（后來兩種都用了，原因下文再說）？等等。其實這是個很好的 AB Testing 的機(jī)會，但是一來技術(shù)不成熟，二來我們基數(shù)實在太小了（后來才知道，其實這也是影響 AB Testing 測試時長原因之一），所以就沒做，因此在這方面我也沒什么定論。但是決策還是要做，我選擇了亞馬遜優(yōu)惠碼的方式（小公司的非核心產(chǎn)品線能讓你快速試錯）。因為直接減去的話，用戶很難有直觀印象，OTA 的列表頁首頁結(jié)果又不一樣，怎樣能感受到我們的價格更低呢（其實也有用戶多家 OTA 搜索同一個酒店來比較價格，所以策略最好能做到精細(xì)化）？不如一來就直接告訴用戶全場 10%優(yōu)惠。

10%優(yōu)惠之后，用戶很高興，但是發(fā)生了我預(yù)料不及的問題。品牌酒店總是在各個渠道維護(hù)統(tǒng)一的價格，這是出于品牌形象的考慮。雖然我們不跟海外酒店直接簽合同，但是一些品牌酒店在我們網(wǎng)站看到他們的庫存居然打折銷售，就說要關(guān)庫存。那可不行，品牌酒店在我們的銷量排行榜上可是居前的。在此之前，也是因為技術(shù)資源有限，我首先考慮用戶需求，很多其他利益相關(guān)者的需求都不列入排期。但是這件事情讓我更加深刻的意識到，我們是有上下游的，需要兼顧供給方和需求方的利益才能可持續(xù)。那我們怎樣既給用戶實惠，又幫助供應(yīng)商維護(hù)品牌形象呢？我們先想和酒店溝通一下，聲明不是酒店降價，而是我們公司”出血“，可是酒店也不答應(yīng)。于是就出返現(xiàn)策略。有些酒店返現(xiàn)都不行，沒辦法，就只能不折價僅給用戶N倍積分了。另外，有一類用戶是行政，他們很希望用戶公司的錢原價預(yù)訂，但是返現(xiàn)到自己的腰包里，所以也要求支持返現(xiàn)。雖然經(jīng)歷了返現(xiàn)這個項目的前期種種，但卻不是我落實的，因為那時候我已經(jīng)離職啦。

搜索的優(yōu)化

很多用戶反饋一些目的地搜索不到，于是我們就抓用戶搜索的關(guān)鍵字，系統(tǒng)（其實是人工啊，PM 拉一大批抽樣數(shù)據(jù)，在 Excel 里 Ctrl+F 關(guān)鍵字去對比庫里數(shù)據(jù)啊，血淚史！）的分析了一下。無翻譯（我們使用海外 OTA 的 API，所以很多數(shù)據(jù)都是英文的）、多別名都算小問題，目前大熱門的目的地都可窮舉，哪怕人工解決都可以。真正坑爹的問題有兩個，一個是這家海外 OTA 的特殊性問題，另外一個是行業(yè)的通用問題。

先說第一個問題。香港的歷史比較復(fù)雜，這家海外 OTA 在地理上把香港當(dāng)作一個國家，但是他們的API是不支持以“國家”為搜索維度的。于是，你搜索“香港”，返回的僅僅是香港的某一塊區(qū)域，而你得搜“沙田”、“九龍”才能返回對應(yīng)地區(qū)的酒店。而香港恰恰是預(yù)定量第一的地區(qū)，這種地理位置劃分策略給用戶的直觀感受就是“你們香港的酒店真少”（T^T）。有 2 種解決方案，一種是，我們把大香港下的地區(qū)都挑出來，在前面加個“香港”2字，這樣在關(guān)鍵字“香港”的 suggestion 里，我們也列出了其他區(qū)域供用戶選擇。另外一種是，我們把香港其他區(qū)域下的酒店都關(guān)聯(lián)到“香港”關(guān)鍵字下。而無論哪種方案，目前的 API 都不支持，得我們自己做一個本地數(shù)據(jù)庫，把關(guān)鍵字做一次轉(zhuǎn)化再發(fā)給 API 接口。然后我們就又立項了，方案 1 成本小，做好了先上，然后又上了方案 2。前面說了，我們的基數(shù)小不適合做 AB Testing，所以這次也沒做。因此真正的效用很難說，但可以肯定的是，這 2 年中，國際酒店轉(zhuǎn)化率一直呈平緩的上升趨勢。

上面的問題，引發(fā)我們想到了行業(yè)里的通用問題，就是“如何對應(yīng)地理和酒店的關(guān)系”。比如，在城市層面，你搜索”北京“，大興算不算北京？在地標(biāo)層面，以地標(biāo)為中心返回方圓 X 米（而且，X 定為幾合適呢？）的酒店呢？還是把地標(biāo)定義為一個多邊形（誰來定義？標(biāo)準(zhǔn)又是什么？）返回其覆蓋范圍內(nèi)所有的酒店呢？由于我們之前都是調(diào)用 API，所以海外 OTA 給啥我們就展示啥，但經(jīng)常有用戶質(zhì)疑我們的展示結(jié)果（怎么沒酒店？酒店離地標(biāo)太遠(yuǎn)！等），我們開始想這里是不是有優(yōu)化的空間？

通過我自己去泰國的感受，我感覺?Booking.com?在這個方面做得比較好。比如，搜索素坤逸大街（具體的我記不住了，隨便寫一個說明下意思）的酒店，覆蓋區(qū)域遠(yuǎn)大于真正的行政區(qū)劃，因為 Booking.com 知道，有條快軌穿過這個手工畫出來的區(qū)域，核心區(qū)住宿價格昂貴，但是只要有快軌，我住遠(yuǎn)一點也行呀。但這個問題太復(fù)雜了，也需要兄弟部門、大量數(shù)據(jù)/算法的支持，所以到我離職之前國際酒店也沒有做。

著陸頁優(yōu)化

這個其實是我們當(dāng)時的業(yè)務(wù)經(jīng)理提出來的（對，他很有 PM Sense 的，第 2、3 個項目都離不開他的支持），因為電商很多的錢都給了百度，通過搜索過來的付費用戶當(dāng)然要最大程度好好保留了。然后我照著 Booking.com 的城市頁“揣測”了一下用戶意圖，覺得如果用戶通過百度大搜索目的地過來，那 TA 很可能是個不太知道 OTA 網(wǎng)站的初級用戶，TA 可能希望的不是各種讓人發(fā)懵的搜索項，而是告訴 TA：去這個陌生的海外城市究竟住哪里好呢？這個問題，其實攻略網(wǎng)站有答案，但是非常抵低效，而且和預(yù)訂流程割裂了，那時候我想，能不能打通這個前后環(huán)節(jié)？

其實到現(xiàn)在也沒感覺這個方向大做起來，很可能是內(nèi)容網(wǎng)站數(shù)據(jù)不夠碎片化，而且推薦算法也不成熟吧？攻略網(wǎng)站都希望能通過給預(yù)訂網(wǎng)站導(dǎo)流賺取傭金，目前看得到的是窮游網(wǎng)和 Booking.com 的合作，但具體成交量我也不知道。但在當(dāng)時我們是怎樣解決的呢？我們選取了10個試點城市，人工（全是眼淚）收集編撰了入住指南，可以直鏈地標(biāo)篩選；然給出酒店銷量排行榜。

這個著陸頁究竟好還是不好，沒有定論。因為一些城市的轉(zhuǎn)化率高于普通列表頁，另一些卻低于；跳出率的降低也是良莠不齊；至于增加了排行榜，對單個酒店的提升和對其他酒店的影響，我們也沒有衡量。而且這個頁面最大的問題在于難以量產(chǎn)（內(nèi)容全是人工編撰的么，而且必須要非常準(zhǔn)確、實用才有真正的幫助預(yù)訂的作用），后來也就不了了之了。

然后我2年的職業(yè)生涯就結(jié)束了。想做的太多太多了，做出來的又太少了。

【文章摘自：極客公園 ?； 作者：哞哞張】