從Foursquare與Gowalla使用者持續下滑再談LBS的經營

昨天在Compete Pulse上有一篇文章「I’m the mayor, So what?」,探討LBS 如Forsqure, Gowalla在每月不重複造訪人數上看到的下滑或膠著情況,探討LBS經營遇到的困境—徽章(Bedge)與市長頭銜(Mayor)的誘因對使用者吸引力不再時,將何以為繼?
評論
評論

昨天在 Compete Pulse 上有一篇文章「I’m the mayor, So what?」,探討 LBS 如 Forsqure, Gowalla 在每月不重複造訪人數上看到的下滑或膠著情況,探討 LBS 經營遇到的困境—徽章(Bedge)與市長頭銜(Mayor)的誘因對使用者吸引力不再時,將何以為繼?

(圖片引用自 Compete

在之前在 Inside 就發表過一篇「你不再 Check-in Foursquare 或 Gowalla 了嗎?–談 LBS 的平台經營」,從使用者的觀點討論 LBS 就平台的經營上從“供需“的角度分別可以從哪些部份去刺激供給(Check-in、Tips),又有哪些事情可以滿足需求(實地資訊、樂趣、社交),試圖提供在可以預見依現有模式很難有所突破的 LBS 一些經營上的意見(是該翻成英文寄去 Foursquare 或 Gowalla 嗎?)。有興趣的朋友可以參考一下 前文

除了在平台模式上的調整之外,LBS 透過與行銷和商業推廣的結合,也許是另一種尋求突破的模式。因為若廣告主把 LBS 作為其行銷活動的一環時,自然會運用其整體行銷資源同時推動此服務,就像是當商家加入了像是 Happygo 這類的積點回饋體系之後,便會用自身的資源為 Happygo 做引介(例如結帳時店員會問“有 Happygo 卡嗎?“,或者在店內張貼 Happygo 的積點或兌換相關資訊)。同樣的,若企業結合 LBS 作為行銷工具,一定對於此 LBS 服務的知名度與使用意願有正面的幫助。

有哪些可以做呢?也許會需要平台先作一些相對的機制設計—

1. 供企業或政府有效匯入大量地點資訊或即時快訊的後台或 API—除了讓地點資訊不再只依靠使用者力量建立外,也滿足使用者 check-in 當下的資訊需求

2. 顯示「官方地點資訊」的標記 —上述企業或政府匯入的地點資訊在呈現界面上可以有特別的標示供使用者辨識。讓“搶市長“所衍生的“一地多名“現象可以得到另一種平衡,以及讓後續的行銷得以展開。

舉一個可能的玩法吧,類似 Groupon 模式,只是改為結合時間、尖離峰、限量、優惠的 Geo-Pon—店家在離峰時段,店內仍有空位時透過 LBS 發送快訊,只要幾分鐘內到達出示 check-in 記錄的客人(且限量)就可以享有特殊優惠(這大概是 2000 年左右就已經被描繪的“網路美麗新世界“景象之一了),當夠多的商家或者一兩家大型連鎖企業如 7-11、麥當勞等都採取這樣的方式促銷時,相信對於 LBS 的使用意願與使用量會帶來另一波動力。

所以,與大型具有業務開發力(例如 Yahoo!、Google 甚至 Goupon)的網站或者與大型的跨國廣告代理商結盟,也許會是 LBS 突破現況的契機?我想 LBS 的潛力不只目前在 Foursquare 或 Gowalla 模式所看到的玩法而已,值得拭目以待。

[Image Credit]


Akamai 服務上新,於邊緣處推動快速創新

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用 Akamai 提供的 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。
評論
評論

在雲計算技術還沒有大規模普及前,絕大部分企業和組織都需要自建數據中心,或通過託管的方式來部署自己的硬體基礎架構,並在此基礎上為員工和客戶提供服務。取決於業務或其他方面的諸多要求,此時需要部署的數據中心可能有很多個,並廣泛分佈在不同地區,藉此為客戶提供流暢的體驗,並透過多個數據中心保障連續性。在發展的過程中,隨著「雲端」的出現,讓各個組織的計算開始集中。

而當在線直播、無人駕駛、智能家電、物聯網等應用開始陸續深入我們的工作和生活,情況又不同了。以往透過雲平台集中運行和服務的模式,因為距離導致的網絡延遲已經對用戶的使用體驗產生極大影響。為了提供更敏捷、靈活、快速、可靠的體驗,企業需要從最貼近用戶的地方提供服務。因此,邊緣計算就成為最有效的解決方法。

透過將數據的收集、分析和處理等工作,由「雲中心」重新分散到最接近用戶的邊緣位置,企業可以就近為用戶提供服務,通過延遲更低的響應打造更出色的用戶體驗。

「無服務器」的出現,帶來計算方式的革新

以前,當組織需要上線一套業務系統時,首先需要採購並部署相應的服務器硬體,並且要負擔服務器日常運維過程中的管理、維護、補丁安裝、配置等繁瑣任務。

上雲前,組織需要在自己的數據中心,以硬體服務器的方式執行這一系列工作;上雲後雖然簡單許多,但依然需要面對雲服務商提供的虛擬服務器,從本質上來看相關負擔仍相當繁重。

無服務器(Serverless)技術的出現,讓組織可以在不需要考慮服務器的情況下,構建並運行由微服務構成的創新式應用程式與和服務。藉此不僅可以省略基礎架構管理任務,還能為幾乎任何類型的應用程式或後端服務構建無服務器應用程序,更方便、靈活地構建出具備極高可用性的應用。

Akamai EdgeWorkers :為創新賦能

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用Akamai 超過 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。

當開發團隊在邊緣開啟代碼時,他們會將數據、見解和邏輯推送到更靠近最終用戶的位置。Akamai 的高性能、可擴展式實施模型,可確保數據和計算不會被延遲問題困擾,進而避免對數字化體驗產生負面影響。

在該服務幫助下,開發者可直接在 Akamai 的全球分佈式平台上快速、迭代地創建和部署新服務,以解決問題和自定義交付。

長期以來,Akamai 在邊緣計算的創新和成功實施皆具有優勢。自 1998 年起,便開始為 Akamai 內容交付網絡(CDN)的客戶推出自定義交付邏輯,其他里程碑還包括 2001 年的 Edge Site Includes 、2002 年的 Edge Java 以及 2014 年的 cloudlet 應用程式。

目前, Akamai 在全球擁有超過 4100 個入網點,為 EdgeWorkers 用戶提供出色的邊緣基礎架構規模和範圍,開發人員可以在靠近最終用戶和他們的數字化接觸點的地方部署代碼,以實現盡可能低的延遲。EdgeWorkers 同樣獨立於雲,客戶可以選擇利用 CDN 供應商或雲供應商平台上的無服務器計算功能。在 Akamai 幫助下,客戶可以在整個混合雲或多雲環境中部署單一的無服務器計算平台。

更多相關資訊:https://www.akamai.com/solutions/edge

本文章內容由「猿聲串動」提供,經關鍵評論網媒體集團廣編企劃編審。