本部落格已搬家
點此前往新部落格

新主機測試中...

Your posts match “ facebook ” tag:

社群網站分享顯示優化

這年頭網站的訪客不一定都從搜尋引擎來,Facebook 或一些社群網站也會導入流量,網站自己也都會放一些分享到 FB 之類的按鈕,就跟以前的網站都有「設為首頁』跟「加入我的最愛」一樣。但常常會發生網頁分享出去,摘要跟圖片顯示得異常,為什麼呢? 因為沒設定相關資訊啊!

這裡有兩篇 FB 訊息牆上顯示的新聞,如果你是新北市的居民,可能會點哪則呢?


有人可能會看到左邊的小字有關水門資訊,想點進去看個詳細,有的人可能是標題黨,因為標題比較誘人就點進去,有人可能點有圖片的,有人可能喜歡看蘋果日報,影響使用者點擊的因素是很複雜的。

但實際上很多網站的分享按鈕都只是放心安的,常常點擊分享出去之後,顯示的是一些奇怪的內容,本來想分享產品,結果變成分享笑話。

常見的問題有:

  • 頁面標題未做優化,如甚至每一頁的標題名稱都一模一樣,沒有商品名稱或頁面名稱。
  • 頁面標題未做優化,如甚至每一頁的標題開頭都叫「 OOOOOOXXXXX有限公司 專提供OOOOOOOOOOOOOO 台灣第一OOOOOOOOOOO - 商品名稱」,重要的名稱都在後面,根本看不到。
  • 頁面描述未做優化,有時候是取頁面內容「原始碼」的前幾個字,如果東西是從 word 貼的,就是一堆雜亂的原始碼。有時候取頁面內容濾除原始碼的前幾個字,但是頁面內容是一大張圖或影片,完全沒有字可以顯示...
  • 分享的文章無封面圖顯示,或是顯示的是毫不相干的圖片,如箭頭的圖片,登入按鈕的圖片,網頁橫幅背景...

實際上這些東西是可以人為控制的,這叫做 Open Graph Protocol (OGP,開放社交圖表/开放内容协议)

分享出去的標題與描述,可以使用 og:title 與 og:description 屬性,
如以下範例:

< meta property="og:title" content="【更新】昌鴻來襲「雙北生活資訊」看這裡 | 即時新聞 | 20150710 | 蘋果日報" />
< meta property="og:description" content="昌鴻颱風來襲,預計將給北部帶來強大的風雨,雙北民生資訊目前最新狀況,整理如下。(即時新聞中心/綜合報導)捷運:正常營運。公" />

在搜尋引擎時代,有些網頁從業人員可能都記得 meta title 與 meta 描述的字數,但是在社群分享與行動裝置時代,og:title 跟 og:description 的字數是沒有定則的,因為每個裝置、每個平台上的顯示方式都不一樣!

以 Facebook 為例 (此處範例都先將封面圖片隱藏):

字數設定有這麼重要嗎? 是沒有很重要,只是會鬧笑話而已。例如...

分享出去的縮略圖,可設定使用 og:image 屬性來設定:
如以下範例:

< meta property="og:image" content="http://twimg.edgesuite.net/images/ReNews/20150710/420_1218c79f4e530ca40bfd608e5229b85f.jpg/>"

  • 圖片網址要用絕對路徑。
  • 圖片路徑有符號或中文時,FB 會自動做 utf8 encoding (中文字會變成&#x什麼的),就找不到圖片。所以網站要自己先把網址做 ASCII encoding (中文會變成%什麼的)的處理。
  • 圖片尺寸依各平台規定而不同,如 Facebook 至少寬跟高都要超過 200px 才顯示得出來,而且會依不同圖片尺寸、不同裝置顯示不同版面。
  • 圖片主題請放在中央偏上,以免顯示時被裁切掉

如果到了 Google+,又是長這樣

此處只講基本的,其他還有很多的 Open Graph Protocol 屬性,請詳閱 OFP 公開說明書。

Facebook 的測試與除錯工具 - FB Debugger
https://developers.facebook.com/tools/debug/og/object/
Facebook 在第一次分享後,會把網頁摘要儲存起來,之後其他人再分享,只會從儲存的這邊去抓,不會去讀網頁上的。避免如果有文章被十億人瘋傳,光每次分享時的主機請求就把網站搞垮了。

所以網頁更新後,要去 FB debugger 清除舊快取,這樣分享出來顯示的東西,才會是新的。

test.com/ 、 test.com 、test.com/index.html、www.test.com/、 www.test.com... 其實都是連到同一網址,但有時候會產生不同的摘要資訊,要個別檢查與清除。

其他事項
一些比較進步的 CMS 或購物車程式,通常都支援每個頁面/產品可以設定獨立的 og:image 或 meta 相關屬性,而不是整個網站都吃同一份內容。

OGP 就是一個公開的標準,主流的社群平台基本上都支援,不支援的話會再抓meta 描述或標題的東西。但是如 Twitter 等…各種社群平台又有自己專屬的摘要屬性,各平台為了達到差異化功能所額外訂立的屬性,比如說可以讓縮略圖的地方直接顯示影片之類的。基本上的原則就是針對目標族群常用的社群分享做優化。

但是中國一樣是有自己的社群生態系。Facebook、Google+ 神馬的都是浮雲,要翻牆才看得到,中國大陸的人民都用微博、微信、人人、QQ、貼吧...,這些社交服務通常又有自己的屬性與圖片尺寸,所以說大中華市場是很特別的。

以前國民黨統戰的時候都宣傳說大陸人都只能吃啃樹皮,現在教材應該要換成大陸人都連不上 Facebook、Google+,所以要去解救水深火熱中的大陸同胞。但現在則要說台灣人沒有大陸手機號碼或台胞證,想申請支付寶之類的方便又功能強大的大陸的網路服務來玩玩都不行。


這篇文章有幫助到您嗎? 歡迎 😀打賞贊助


你知道你的網站可能在 InAppBrowser/webview 無法使用嗎?

你知道你的購物網站,可能在 Facebook App 裡面無法結帳嗎?

最近遇到一個案例,購物網站上線後,廠商說許多消費者回報「購物車無法刪除商品」,選擇取貨的超商分店後「無法跳回原本的結帳頁面」。工程師用了幾十年 的 JavaScript confirm() 跟 window.open() 語法,到底會有什麼問題?

一開始以為是資訊界的「顧客整人」理論(註一)。但是深入了解後,終於重現發生問題的情況: 網站主要導流來源是 Facebook 粉絲專頁,只要使用者使用 iOS Facebook app 內的瀏覽器開啟網站,一些 JS 功能就會失效,但如果將連結使用一般的 Safari 瀏覽器開啟,則是一切正常。這種 APP 內的瀏覽器有個專有名詞,叫做 InAppBrowser,或是對 App 開發人員,叫做 "UIWebView"。

註一: 服務業有所謂「顧客至上」理論,不需要任何邏輯,花錢的就是大爺,客人就是神。資訊界則相傳有「顧客整人」理論,程式不會有問題,一定是使用者不會用,或是軟硬體太舊或太新,造成相容性問題。

再找了一些瀏覽器功能支援度的線上測試工具,用這年頭最新的 iOS 9 實機測試,Safari 跟 InAppBrowser 的確會跑出不一樣的分數,證據確鑿! 明明在同一台裝置上,都可以看網頁,但卻是不一樣的東西。

除了那些細部的測試,另外之後也初步條列出幾個常用,但是會在 InAppBrowser 發生問題的語法:

- alert() :無法出現對話提醒視窗,所以「請填寫某欄位」之類的提示通通看不到,假如姓名欄位必填,有個使用者沒填姓名,但是他點送出的時候,網頁也無法提示「請填寫姓名」,使用者只會看到點了送出,怎麼網頁都沒反應?

- confirm() :對話確認視窗無法出現
if(confirm) 的行為通通無法繼續操作。「是否確定刪除購物車內的商品?」之類的確認視窗通通看不到,也無法操作,這是使用者體驗的一大忌,因故完全無法操作,但使用者又無法得知發生了什麼事。

- window.open 或 window.opener:與電腦上完全不同的顯示行為。
會有兩種情況產生,一種是點擊後毫無動作,如果選超商分店之類的 emap 是用 window.open 來做,那使用者是無法選擇超商的。target="_blank"倒是可以用的,沒問題。
另一種是會覆蓋原本的頁面,而不會在新視窗開啟。如果沒有特別作紀錄,將導致使用者剛剛輸入的內容被清除掉,又得重新輸入。

- window.close 或 self.close :失效。
承上,因為頁面已經被覆蓋掉了,所以一些指定視窗跳回的也失效了。程式可以接收到傳回的資料值,但使用者只會看到精美的空白畫面,無法關閉分頁。有些 App 按返回,會直接跳回 App 的文章,而不是網頁的上一頁,不管是卡在空白畫面或是無法回上一頁,等於結帳流程完全被中斷。

但是裡面有內建瀏覽器,而預設不會直接呼叫 Safari 開啟網頁的 App ,不只有 Facebook 呀!
又測試了一些比較常見的 App,檢測以上項目,只要有一項無法操作,就打叉。

  • Facebook (X)
  • Line (O)
  • Plurk (X)
  • Pinterest (O)
  • Pocket (X)
  • QQ (O)
  • Twitter (X)
  • Wechat (O)
  • Whatsapp (O)
  • 新浪微博 (O)

除了上述的社群軟體或閱讀軟體,其實還有掃描 QR code 的軟體要測,但是太多了,先忽略。以上是 iOS 中發生的問題,至於 Android 呢? Android 4.x 跟 Android 5.01 大致上沒發現這問題。

這份問題 App 清單不一定是準確的,因為症狀通常不會同時出現,還有可能某 App 今天沒事,但更新後就有問題了。或是本來有問題,但某天 App 更新後就正常了。還有明明 App 已經修復此問題,使用者卻從來都不知道要更新 App,繼續使用有問題的版本。

解決方案
現在是科學的時代,先把網站的 GA 報表叫出來看看影響層面究竟有多大? 是否真的有需要解決? 但數據表示用行動裝置的比用桌機的還多,iOS user 更是 Android user 的兩倍,所以目標客戶群主要還是拿 iOS 裝置的使用者,這問題是不能不找出解法了。

網站已經上線好幾週了,這種裝置不支援的問題算 bug 嗎? 網頁公司是否要無償去修正?
那 Flash 在手機上面不能看也算 bug 嗎?
XX 銀行的 WebATM 只能在 IE 上使用,不能在 Chrome上面執行,算 bug 嗎?
廠商把責任推給網頁公司,網頁公司把責任推給 Mark Zuckerberg,Mark Zuckerberg 把責任推給 Steve Jobs,所以先準備買機票去美國抗議,使用者的問題最後還是沒解決,事情不是這樣幹的。

這時候要拿出將太的壽司的經典台詞之一:

改程式、跟開設測試機都是要花錢的,先來考察別人都怎麼解決的:

1.網站公告法
用 Google 找了一下,這種「請消費者用預設瀏覽器開啟網站」的說明文還真不少,
隨便舉幾個來瞧瞧:

案例四 - 批踢踢網路創業板 - 緊急分享 fb app更新影響訂單成立

正常的購物行為,不管是明確型還是閒逛型購物,會先去看公告才開始消費的使用者比例其實是不高。如果叫廠商的 FB 小編每次發文時都要加「請消費者用預設瀏覽器開啟網站」,或是「請消費者自己更改 APP 開啟網頁的預設值(這個設定iOS 沒有,只有 Android 的 Facebook app 才有。)」,都是不夠理想的作法,應該只有花不起錢,或是時間有限的廠商才會做這種事。

2.自動提示法
訪客每天嘩啦啦的進來,問題持續存在。如果抱著老公務員心態,遵照一般流程,先寫報價單、等客戶確認簽回、開設測試主機、調整程式、內部測試、客戶驗收,更新正式機,客服人員都崩潰了,應急處置就先來做個提示,判斷如果用 iOS 的 FB APP 開網頁,則會跑出一個「請選擇在 Safari 開啟」的提示。

首先發現從 FB App 進站,會帶來源網址(document.referrer),依不同裝置與不同 App 版本,至少會有 http://m.facebook.com, http://m.facebook.com/, https://m.facebook.com, https://m.facebook.com/, http://lm.facebook.com, https://lm.facebook.com/, https://lm.facebook.com, http://lm.facebook.com/ 這八種,所以我們可以用上述 document.referrer 再搭配 iDevice 的 UserAgent 判斷式,來顯示「請選擇在 Safari 開啟」的提示訊息。

但是後來讀取 iOS FB InAppBrowser 的 UA 字串,發現裡面通常有 FBIOS 的字,所以可以簡寫成
if (navigator.userAgent.match(/FBIOS/i)) {
// show something...
}

以上是針對 FB app 的,那其他的哩? 一樣可以用實機去測 UA,用 UA 裡的字串來做判斷。
只是以後每流行一個新的 app ,就要去查一次 UA,再加一些判斷式嗎? 得找找有沒有治本的方法。

3.更改程式法
台灣是 FB 生態系,網站最基本的需求在 FB 上面要完美,不能分享時顯示一些亂七八糟的摘要,還有購物網站要可以完成購物流程。中國大陸地區則是 WeChat 生態系,H5 頁面最基本的標準是要在 WeChat 裡面可以跑,網路上一樣有許多前人分享血淚史。

去考察一些連小學生都知道的國內外知名購物網站,或是所謂行動開店服務的網站,是怎麼處理上述問題的。赫然發現,瑞凡,已經沒有人在用 alert(), confirm(), 或 window.open() 了!

alert(), confirm() 的歷史悠久,保證絕不出錯,比較不會有詢問視窗還沒按確認,但是程式卻在背後偷跑的情況,也不怕有人關閉視窗,或是繞過去。但是卻有可能有使用者去勾到「防止此網頁產生其他對話方塊」,這樣網站不管執行任何動作,都不會再跳出確認與詢問視窗,造成非常多的問題。每一種瀏覽器的解除法也不一樣,大大增加了客服人員的處理時間。

另一個問題是在每一種瀏覽器、每一種裝置,對話視窗都長得不一樣,如對話視窗的位置,IE 跟 Firefox 在中間,Chrome for PC 在上方,還有按鈕文字也不同,有的「確定」顯示在右邊,有的「確定」在左邊,在 iOS 上面則顯示「好」,帶來完全不一致的使用者體驗。

window.open() 的好用之處在於可以保留原本的視窗,程式不需要先額外記錄使用者原本輸入的東西後再把視窗轉走。但常見問題則是被瀏覽器的攔截廣告彈跳視窗功能擋住,使用者要發現瀏覽器網址列或是某處多了一些紅叉叉或提示訊息,再去按允許,讓網頁重新整理一次,才能看到應該要顯示的視窗。或是開發人員設定了 windows.open 的尺寸,但是在行動裝置上卻不聽話,造成異常大的空白區域。

所以一般大型購物網站是如何排除這些問題呢?

  • alert: 使用另外的 Modal, Dialog, Message 相關元件,如淘寶,91APP。
  • confirm: 使用自製的 Modal, Dialog 元件,或是直接執行動作,但是有個復原按鈕可以按,如 Yahoo 拍賣。
  • window.open/self.close: 選擇超商的視窗時,先把使用者當下輸入的資料記錄起來,然後整頁轉過去,選完之後再整頁轉回來,並把使用者先前輸入的資料塞回去,完全不彈跳額外的小視窗。如 Yahoo 商城。

結論:
資訊業一日千里,一套程式就想用一輩子是不行的,有些程式只能解決古代的問題,無法解決現代的問題。只會吹噓古時候的成功案例,但是無法滿足現代的客戶,是一點用處都沒有的,必須要常常更新才能更上時代。

但是管理階層或業務常會有「這套程式給某大客戶都用得好好的,幹嘛要更新?」「用起來好像沒啥差別呀,重構後的跟舊的差在哪?」 的想法,只能說很容易換了位子就會換了腦袋。

以前高中老師說過,看到一個現象就解釋一個說法,這不叫科學。
但是後來發現常常在做不科學的事,見人說人話,見鬼說鬼話,科學是假的,達成自己的目的才是真的。


這篇文章有幫助到您嗎? 歡迎 😀打賞贊助


Google Analytics 網頁分析做不到的事

Google Analytics (GA) 分析可以做的神蹟,大家或多或少都有聽過。
但在瞬息萬變的商業市場,GA 的實用高嗎? GA 是完美的嗎?

你可能有聽過以下對話:
客戶/老闆/業務 : 「Google 分析可以看到我們網站的 XXX 數據嗎?」
網頁公司/行銷公司/工程師 :
「沒有喔,Google 分析沒有這功能」
「沒有喔,這要另外設定才看得到。」
「沒有喔,這個要另外寫追蹤碼才看得到。」
「我們沒有在分析這個。(白話翻譯:公司裡沒有人會做,或是有做也不跟你講。)」
「行銷公司不是收了你幾十萬嗎? 叫他們做。(把問題推給行銷公司)」
「這購物車程式很爛,很多地方沒有獨立網址,報表會不準。(把問題推給網頁公司)」
「因為使用者用了...所以 GA 裡面看不到。」
「怎麼會沒有呢? 一定是因為使用者...」
「統計工具一定會有誤差,通常是因為使用者...」

本文介紹網路文章不會講,推廣介紹 Google Analytics 的人通常也不會講的東西...就是 Google Analytics 做不到的事,或是誤解 GA 辦得到,但其實沒有的功能。本文僅針對網頁版的 Google 分析追蹤功能作探討,至於 App 版或 Flash 版的 GA 不在本文討論範圍內。

上面有一個 ppt,如果看不到 ppt 請點此連結

內容摘要:
Google 分析是在分析什麼?
簡單來說,經由時間,與各種維度與指標的搭配,
調出想看的數據,或是評估花費成效,或是發掘未知的需求。
Google 分析的原理(analytics.js)

Google 網頁分析做不到的事:

一、要額外花功夫才能得到數據
1.必須另外寫 GA 事件追蹤,用資料收集 API,把資料傳給 GA,才能在 GA 檢視資料:

  • 頁面滾動距離
  • 輪播圖點擊切換
  • 訂購單下載行為
  • 外部出站連結
  • Youtube 播放
  • 消費金額電子商務追蹤
  • 跨網域
  • 社群分享按鈕點擊
  • 族繁不及備載...

2.要在 GA 設定後才看得到:

  • 站內搜尋分類與關鍵字追蹤
  • 客層興趣報表(年齡、性別、職業別…)
  • Google搜尋來源訪客使用的關鍵字
  • 電子商務設定
  • 目標設定
  • 首頁網址設定

3.站內搜尋追蹤
4.轉換率追蹤: 先定義何謂轉換率?
如何用量測工具正確實做網站功能改版? « Blog.XDite.net
5.購物轉換率追蹤
6.會員註冊追蹤

二、看不到搜尋引擎的來源關鍵字 – 加密搜尋
1.加密搜尋 : 更改為HTTPS,而且不再傳遞 HTTP referer 中的關鍵字
Google – 2011 年10 月起 (link)
Yahoo - 2014 年 4 月跟進。
百度 - 2015 年 6 月開始實施。(link)

2.Google 加密搜尋的漏網之魚
3.硬是要看訪客來源關鍵字呢? 請使用 Google Search ConsoleBing webmaster tool
4.付費的搜尋來源關鍵字?

三、GA未提供以下功能

  • 無法直接看到使用者 IP。
  • 沒有訪客獨立個人資訊頁面或「誰來我家」功能。
  • 沒有直接永久刪除報表內某筆錯誤資料或記錄的功能。只有透過區隔或一些篩選工具,「不顯示」某些資料。
  • 沒有動作熱像圖。
  • 沒有即時通知功能,只有通知前一兩天狀況的快訊功能。
  • 沒有主機傳輸量統計。
  • 不喜歡 GA 的圖表配色,想自訂顏色? 得先學會用 Excel,或是 GA 的 API。
  • 競網分析比較。
  • 預測未來、提出建議。
  • 電子商務 API 功能的限制。
  • 報表顯示在地化城市名稱。

有些功能也許未來會提供,有機會的話會再回來更新。

四、瀏覽者環境導致報表產生誤差
1.隱形人(完全不會出現在 GA 裡面)

  • 瀏覽器 JavaScript 或 Cookies 功能被停用。
  • Google 分析的 JS 來不及載入。
  • 拒絕透露資訊的瀏覽器套件。
  • 防火牆或防毒軟體的設定。

2.被辨認為新訪客
3.無法辨識的使用者資訊(not set)。
4.同一使用者使用不同域名瀏覽網站。
5.多人共用一個裝置。
6.一個人使用多個裝置。

五、無法追蹤的訪客來源
1.以下情況都會歸類為「直接來源」:

  • 從電腦或手機的應用程式點進來的 (如 Microsoft Outlook,iOS Mail app, 用 Line 貼連結給別人, skype……)。
  • QR Code 掃描。
  • 瀏覽器的「我的最愛」。
  • 桌面捷徑。
  • HTTPS 的網站來源。

2.來源被處理過,無法明確追蹤:

  • 來源網站會將站外連結轉址。
  • 從 HTTPS 加密的網站連過來的訪客。
  • 投放廣告時設定錯誤。 範例: 如想要追蹤從 Yahoo 搜便利(找店+)連到網站的訪客數量,評估刊登搜便利是否有效。但因為搜便利的網址是 https://tw.ysm.emarketing.yahoo.com...所以在 GA 報表內,從搜便利來的使用者會被歸類為直接流量(direct),且查不到來源網址。

3.折衷解法:
使用網址產生器產生網址,讓網址加上 utm 參數, GA 即可歸類。
FB 有出 https://www.facebook.com/business/google-analytics/build-your-url
Google 也有出 https://support.google.com/analytics/answer/1033867?hl=zh-Hant

應用範圍:

  • 區分網站/公車廣告/產品包裝/名片/等各地來源的 QR code 訪客來源。
  • FB 粉絲頁 PO 文時(非推廣廣告),附上網址產生器產生過的網址,追蹤訪客是從哪篇文章來的。 如上述的搜便利,可以試著刊登附上帶有 utm 參數的網址,讓 GA 可以歸類。

六、未經處理的的野生報表
1.這年頭很多網站都有 FB 註冊、超商取貨功能…
GA報表說:「離開網頁」是購物車頁,「推薦連結來源」是金流成交頁、超商地圖選擇頁?
GA報表說:「離開網頁」是註冊頁,「推薦連結來源」是 FB / Google+ / Yahoo 的認證畫面頁?
2.未過濾公司內部流量與瀏覽行為。
3.未處理特殊符號: 如行動裝置鍵盤內的表情符號,電商追蹤未處裡金額的逗點。
4.未過濾特殊瀏覽行為 (ex.捲動距離配無手機版網頁)。
5.報表裡無所不在的 not set。
6.未過濾垃圾廣告來源。

七、廣告垃圾來源要自己過濾
有人的地方,就有廣告,這是新媒體時代的鐵則。
參照連結垃圾(referer spam)
關鍵字垃圾(keyword spam)
事件標籤垃圾(event spam)

如何過濾:

  • 在 GA 建立篩選器/區隔,但是黑名單更新不完。篩選條件設得不好,可能會連正常的一起擋掉。
  • 比較落後的機器人只會針對 UA-XXXXXX-1 做假流量行為,多開幾組資料檢視,讓網站使用 UA-XXXXXX-2 的追蹤編號,避開大多數的 GA 垃圾廣告。

八、第三方嵌入內容: iframe 嵌入,或JS動態生成的內容要另外寫事件追蹤。
1.影片

  • Youtube - 改用 Youtube Player api 的嵌入語法
  • Vimeo - 事件追蹤套件 vimeo.ga.js
  • 其他: 土豆網、Youku – 障眼法 障眼法範例:在廣告視窗上面做GA事件紀錄,使用者播影片時一定要先把廣告視窗點掉,

2.文書嵌入式內容 -無解,只能用障眼法

  • PPT – Slideshare, Google docs, Office Online
  • PDF - google docs
  • Google 線上表單

3.其他

  • Flash - GA Flash api
  • 社群分享按鈕 Google Plus +1 – 若使用原生嵌入語法,GA 會自動記錄。 Facebook 分享按鈕 - FB.Event.subscribe + GA 事件追蹤 用途: 追蹤網站上的社群分享按鈕使用情況。

追蹤要點1: 不要去 Google 搜尋討論區或部落格的 sample code,很多都已經過期了,請直接看官方文件。
追蹤要點2: 很多轉貼教學寫的 FB「分享」按鈕事件偵測,其實是用在「傳送」按鈕的,避免做白工,請直接看官方文件。

九、哪些網站不適合追蹤?
1.要額外花功夫再設定許多事件追蹤

  • 網站許多功能使用 Flash,或是 AJAX 執行產生,網址不會有變化。
  • 每一個結帳步驟、或每一個註冊流程沒有獨立網址。
  • 網站主要頁面只有一頁。

2.無法追蹤類

  • 網站限定用自己伺服器內的內容,禁用 CDN 、或第三方 JS 、外部連線檔案。
  • 商城型購物車或網站建置系統,不開放外部程式碼置入功能。
  • 內網封閉網路(intranet)。
  • 框架式轉址、被塞在頁框內的網站

3.網站行為分析需求的主要客層?

  • 成效不好的網站。(資料量太低,只能叫個案,不能稱為數據。)
  • 要改版的網站 (但通常之前都沒有掛 GA,無法分析)
  • 砸錢買廣告,但是訂單量沒成長的網站
  • 超級大公司
  • 作為雲端大數據成果展示用
  • 作為 UX 成果展示用

4.不是網站行為分析需求的主要客層?

  • 預算較低/初次做網站的客戶。
  • 覺得網站分析出來也不能賺大錢,把網站預算花在其他地方比較實在。
  • 網站單價低,數據分析需求更低。
  • 成效已經很好的網站。
  • 給的錢不夠多,網頁公司不知道怎麼埋,行銷公司不想幫你埋。

十、不要迷信數字,數字只是傳說
1.膚淺的平均數
台灣主計處 : 國人平均財富 736 萬,平均每戶家庭淨值 1217 萬元。
台灣煮雞處 : 台灣人平均每人有 0.98 顆睪丸。

2.資訊不足的報表導致錯誤的結論。
3.錯誤的數據解讀範例。
4.數據不是用來制定不切實際的目標:

  • 用精美圖片或標題黨騙點擊 : 造成跳出率高、瀏覽時間短。
  • 創造高的訂單金額與成交量 : 用假帳號消費、買評價,訂單量達成了,但退貨率高。
  • 製造推薦來源: 開假部落格、假社群帳號、垃圾廣告連結,造成反感。

5.數據不能只看短期。
6.數據需要統籌宏觀,不同角度會有不同結論。
7.不同型態的網站經營模式,就應該要有不同型態的關鍵數據做分析與解讀。


這篇文章有幫助到您嗎? 歡迎 😀打賞贊助


也來做一下臉書直播統計投票

這個月中突然掀起一股臉書直播熱潮,不只是視訊內容,而是與FB應用程式串接,讓直播心情變成投票,是程式! 這個直播裡面加了程式!而且也有客人在問,不禁也來試玩一下。

其實臉書的直播功能已經推出很久了,只要按一個鈕就可以開始直播內容給別人看,使用者只要煩惱要播什麼內容,還有要去哪找人來看。完全不用管什麼主機流量、網路頻寬、會員機制、負載平衡、影片格式、視訊規格...一些宛若天書的東西,一些"擺老會"可能又要發言了:「我以前幾秒鐘的影片放到網路上就要傳 10 分鐘,還要前一天先轉檔blahblah...」資訊的世界有個法則,以前的經驗常常是無法解決現在的問題的。這些屁話還是留著跟 3.5 磁片說吧。

台灣首發!不會程式設計也能做臉書直播投票 | TeSA 臺灣電子商務創業聯誼會 這篇文章與範例程式,還有之前的直播經驗,輕鬆就達成第一次的粉絲團直播投票測試,觸及數高達......不到 300 人,影片觀看次數不到 100 次,粉絲團人數暴增 0 人。技術問題事小,要去哪找人來看、怎麼從中獲得利益的問題才大啊。

怕原文不見,紀錄一下大致上的步驟:
有需求就有供給,只好來玩一下。話說真的不用懂程式也可以直播投票嗎? 才怪。先不討論客人不知道怎麼用電腦開串流視訊,光是要用 HTML 跟 CSS 把那個直播畫面改成自己想要的,或是申請 FB 應用程式的步驟,一般人就有機會卡老半天了。

1.去網路上抓別人寫好的範例code,看裡面要填什麼。
2.一開始以為 access_token = App Token = 應用程式密鑰,在 FB app dashboard 裡面弄老半天,直播投票數都不會動,看了教學才知道要到存取權杖工具 - Facebook for Developers抓 App Token,兩個是不一樣的東西。
3.到粉絲團>發布工具>影片庫,新增直播,取得伺服器網址與串流金鑰。
4.網頁有更新樣式時,可以再去直播軟體裡面重選檔案,直播影片的畫面也會更新。
5.一開始沒想到內容,拿 Youtube 的 PPAP 影片來直播,結果該直播馬上就被 FB 停掉,要重開一個新的。

update:後來發現有大大做出更便利的工具,畫面的修改彈性可能沒這麼高,但是可以減少整體的操作步驟與開播門檻,可以參考 FB直播按讚小工具 不藏私大公開~【PikoLive 皮克直播】

雖然直播投票這種東西有其戰略目的,其中之一是粉絲團如果有直播,粉絲在一般情況下都會收到惱人的通知。而且在一個發文觸及率與互動率這麼低的年代,不需要準備臨場反應佳的主持人,只要有個議題,改個網頁放幾張圖上去,很快就能開個直播騙關注,向業主證明他的粉絲團操作團隊有在做事,這不是很輕鬆寫意嗎?

雖然我會看臉書上的寵物類直播,或是老皮之類的 Youtube 遊戲實況,但我卻很討厭直播投票這玩意,最近幾天滑FB,每天都一堆粉絲團或是開發者一窩蜂在玩這個,然後臉書通知也一堆「您的好友回應了某某某的直播...」,其實投票題目也都相當無聊,比較想看一些腦洞大開的有趣應用,例如...

網路範例:用心情投票來跳表?

網路範例:用心情投票來決定偶像要幹嘛? (參加投票和嘉嘉一起圓夢)

網路範例:用心情投票來決定2048要怎麼走? Let's play 2048

網路範例:用心情投票來騙讚。 (Q小舖:超療癒小遊戲)

如果不拿來投票,也不拿來發優惠券金額之類的跳表,大概還能用來決定得獎編號?

最後講一個關於直播的笑話:
「遊戲直播? 為什麼有人會喜歡上網看別人玩遊戲呢? 真是搞不懂耶。」
「不講了,我要先去看 NBA 了。」

延伸閱讀: 實況投票的真價值|黑貘來說


這篇文章有幫助到您嗎? 歡迎 😀打賞贊助