中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

訂單與詳情

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

國內信用卡支付

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

上文提到，我們拿海外 OTA 的庫存，全靠調用 API。美國人的信用卡使用率非常高，因此這家海外 OTA 的支付接口也僅支持國際信用卡，但中國人信用卡普及率低，能海外支付的就更少了，很多用戶填了支付信息結果返回錯誤。那我們為什么不把支付本地化呢？這是因為那時國際酒店不是戰略重點，資源有限，技術上調用 API，ROI 最佳。

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

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

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

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

10% 優惠帶來的改變

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

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

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

搜索的優化

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

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

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

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

著陸頁優化

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

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

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

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

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