如何在谷歌推廣進行再行銷？

在顯示廣告系列中我們可以選取再行銷。之後我們可以通過兩種方式來獲取受眾群體列表（可在“共享庫”-“受眾群體”中查看）。這裡我們解釋下用戶列表，用戶列表是指訪客訪問你的網站時，你按照訪客在你的網站上的特定行為將訪客劃歸為某一類別並通過Cookie技術儲存在訪客的瀏覽器中。

在AdWords中，第一種方式是讓AdWords自己來收集受眾群體列表，這種方法需要你手動將代碼放置到各個頁面中。假定你運營的是一個招聘網站，那麼你可以把所有瀏覽過Java工程師職位的訪客通過他們是否瀏覽過Java工程師職位頁面來進行標記，代碼就會放置到這些頁面中。一般來說我們會在所有頁面中插入一段AdWords跟踪代碼並控制代碼中的參數以區別不同訪客特徵。這樣你在再行銷的基礎上就可以進行再行銷動態廣告。如上圖所示，谷歌會自動為“求職招聘”創建5個自動生成的再行銷列表。此外你也可以自定義一些“基於規則”的再行銷列表。通過這個設置，你就不會為Java工程師推送財務相關的職位了。

第二種方式更加方便，當你將AdWords賬號與Analytics賬號連結後，AdWords會自動獲取你在Analytics中已經定義好的再行銷群體（反過來Analytics也能獲取AdWords中的再行銷列表）。在Google Analytics中你會有更多可以發揮的空間去定義特殊關注群體。在Google Analytics中定義再行銷，只需在“管理”-“媒體資源”中設置“再行銷”即可。但是如需使用“動態屬性”，依舊需要為這些字段設置變量，這會使用到自定義變量。

如何使用Google推廣進行再行銷？

Google推廣中的再行銷兩年前曾經有著一個本地化的名字“回頭客” 。在Google網盟推廣中，新建推廣計劃時，選擇“受眾描述”-“行為”，選擇“到訪過特定網頁”。這樣你就為該推廣計劃開啟了再行銷。接著Google會讓你選擇“創建無代碼人群”，“創建代碼人群”。前者是Google的“黑科技”即Google無時不刻在搜刮的用戶訪問記錄（數據來源可能是搜索，Google瀏覽器等）。後者是和谷歌一樣的通過跟踪代碼來收集。但由於不支持變量，如果有多個標記而不是通過URL來識別時需要反復安裝。 Google也支持自家的Google統計代碼，只是目前也只支持URL。

如何做好再行銷？

如何做好再行銷呢？再行銷渠道來的訪客必定是對你的產品和服務有所興趣，甚至有所了解的。他們或者由於種種原因未能轉化，或者曾經被轉化已經熟門熟路了。這裡我們給出幾種策略：

推陳出新

首先對於曾經被轉化過的訪客，他們的轉化成本往往只有新訪客的七分之一。如果你有新的產品，你要盡量先推送給你“老主顧”。這種推送不單單在於CRM方面的電郵短信或者微信推送，更在於利用再行銷，讓現有的顧客“惦記你”。

永遠要有Plan B

我們不妨把再行銷看作“補考”，上次沒考過這次再去考如果僅僅只會做上次考試的那些題是沒用的。因為題是會變的。我們經常說不要在一棵樹上吊死。如果你曾經把用戶帶到了著陸頁A用戶未能轉化，那麼再花錢把用戶請來還是無法轉化的。這個時候不妨試試著陸頁B。如果第一次用戶看到的是紅色的鞋子，你為什麼不試試同款的其他顏色的鞋子呢？有一個B計劃往往會在主打購買理由、採納理由無效的時候另闢蹊徑獲得不錯的效果。

做到個性化

相對於第一次訪問的訪客，你對回頭客會有更多的了解。譬如說我們剛才舉的例子。你已經知道訪客在尋找Java工程師的職位了，那就不能籠統地用“找工作”來進行廣告推廣了，而要用“找Java工程師職位”來推廣。然後著陸頁使用更多的新的Java工程師的職位來吸引用戶轉化。這才是“二進宮”的真正價值！

降低門檻

在你已經知道原來的策略無效時，你不妨降低門檻。如果你知道用戶想買一個型號的筆記本，那不妨給用戶一些折扣（注意不是給所有用戶，而是給未能轉化的用戶），說不定這次便能轉化呢！

總結

再行銷每個點擊的獲取成本一般只有第一次點擊的十分之一甚至更低。合理運用再行銷是對流量資源的再利用，它是降低用戶獲取成本的重要手段。在搜索引擎行銷中我們常常用到再行銷。其他渠道的行銷我們也可以使用。不管是微博廣告還是電子郵件行銷，只要我們可以在用戶端植入Cookie就可以命中高質量的潛在用戶。如此看來，再行銷技術是每一位數字行銷者的必修課。

The post 再行銷– 降低用戶獲取成本的關鍵手段 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

新的AdWords賬戶級別指標Opti Score

望文生義，Opti指的可能是Optimal或者是Optimization。它代表（相對於）最優化或者優化得分。相對於我們通俗理解的1~10的Quality Score，Opti Score是一個新的指標。兩者的區別如下：

• Opti Score是賬戶級別的得分，它的範圍是1%~100%。其中100%代表最佳。它只是一個評估值，並沒有用作輸入參數。 Opti Score是一個相對值，它表示了你和同行業最佳廣告主之間的差距。 Opti Score越高說明你的賬戶越健康，谷歌覺得你的SEM越成功。
• Quality Score是關鍵字+創意級別的得分，它的範圍是1~10。一般理解在推廣計劃、推廣單元和賬戶級別都具有Quality Score存在。其中10代表最佳。它也是一個評估值，同時它被用作計算最終出價。 QS越高，說明你的必要出價越小，可以為你“省錢”。

值得注意的是，Opti Score是依託於效果來進行打分的。也就是說，如果你需要了解自己的Opti Score，那必須設置轉化目標。如果你不進行轉化設置，而僅僅是將流量送到著陸頁，那麼你的賬戶並不會有這個指標。與之相反，我們通常理解的賬戶級別的Quality Score雖然它的值並沒有表現出來，但是它總是存在的，它的主要決定因素是點擊率。

Opti Score的四大影響因素

Opti Score由四大因素影響。它們分別是廣告預算，出價，創意，以及CPA（單位轉換成本）。我們可以看出，整個Opti Score的討論範疇包括了CPA Bidding。這是Google推薦的模式，Nicolas甚至指出， Micro-manage關鍵字和出價在他看來普遍不如自動化的管理把全部工作交給AI來得好。在這個模式下，你不需要為你的每個關鍵字出價，AdWords會自動學習來滿足（或者盡量接近）你所設置的每個轉化的成本。

下面分別探討各因素的影響：

• 廣告預算– 廣告預算越小，AI的學習週期就越久。你可能會從而丟失許多轉化機會。
• 出價– 出價太高和太低都會造成問題。前者造成浪費，後者丟失機會。
• 創意– 好的創意不單具有說服力還有各種擴展促進轉化（比如site links，call extension）。
• CPA – 當啟用CPA Bid模式後，一個過低的CPA會讓AI非常保守從而錯失機會，而過高的CPA可能又無法讓你的利潤最大化。

Opti Score的參照值

Nicolas稱平均賬戶的Opti Score值為61% 。而每個廣告主都應該盡量讓自己的賬戶Opti Score值達到75% 。這意味著一個健康的賬戶。雖然言下之意是你需要在谷歌花更多的錢，但其邏輯上不無道理。通過上述四個影響因素將Opti Score提升到75%之後，你可以了解下你真正的CPA。這是第二步。

所謂真正的CPA是指你需要更好地跟踪你的客戶旅程，許多時候他們在跨屏瀏覽時一部分廣告消費並沒有加入CPA的計算。此時你需要把這些點擊考慮進去，因為他們也進行了“助攻”。

優化的第三步是利用對於不同的人群採用不同的出價方案，你可以利用GA中收集的人群或者其他DMP來源的數據。好比有的人可能只在你店裡買一包紙巾，有的人可能會買上千塊的商品；對於優質客戶，你可以把CPA放開。

一些感想

冬天我們都喜歡吃暖鍋，不單好吃，保有原味，而且還方便。很快，或許對於我們數字行銷者來說可以做的工作會越來越少，大量的工作會交給機器人進行。一方面谷歌建議我們把工作交給AI，另一方面我們也的確看到許多CPA bid和DSA（Dynamic Search Ads）會比手動管理取得更好的效果的例子。這裡要提醒各位的是Google在去年也上線了行業定投和頁面投放（相當於Google的DSA）的功能。我們應該勇於嘗試。

總的來講，這其實是給我們每個從業者提出了新的要求，即便你在當前的工作中如魚得水，在未來的幾年你也可能丟失你的競爭力。因此，能更好地理解數字行銷方法論，更多接觸新出現的科學技術，更全面地整合各個渠道的數據會成為未來數字行銷人才的關鍵素質。

The post Google引進AdWords新指標Opti Score，人工智能新時代 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

分詞方法方面

谷歌運用的是偏重語義理解的分詞方法。也就是說即便通篇文章沒有出現搜索詞，而僅僅出現接近的語義，頁面依然能夠排名到較好的位置。而Google方面更偏重於完全匹配的優先性。我們在此不討論搜索時運用完全匹配運算符。只要你的關鍵字密度和完全匹配條件能夠滿足，在其他因素相當的情況下，在Google頁面中總會有較好的表現。

比方說有一款著名的遊戲叫《信長之野望》。如果我們在搜索框中輸入“信長的野望”，在兩個搜索引擎中會有不同表現：

Google會告知：以下為您顯示“信長之野望”的搜索結果。仍然搜索：信長的野望

而谷歌會直接顯示“信長之野望”的結果。

雖然兩者的結果都是顯示“之”的結果，但是Google顯然認為這兩者是不同的，是您輸錯了。

結構化數據方面

關於結構化數據我們已經探討過多次。結構化數據SEO是未來搜索引擎優化的主要趨勢之一。但是Google並沒有參加schema.org協議，而是自己弄了一套Google結構化數據。最近Google又在內測數據標註，可以看出處於國情和自身競爭力的考量Google已經有較大的潛在壓力了。

著作權和版權方面

無疑谷歌相當重視著作權和版權，對於抄襲內容和非原創內容谷歌也進行相當大的懲罰。 Google方面則不然前面提到的Google結構化數據中對於在線文檔連作者字段都沒有，這就是一個例子。當然Google也透露開始重視原創內容，將在不久的將來有所動作。

收錄速度方面

兩者都會對部分網站進行優先收錄。谷歌的咖啡因算法就是為了更快地相應訊息的傳播。除了Google大力推的站內搜索可以幫助你的網頁在Google上被更快收錄，在Google上海站長沙龍還發布了一項叫做“新好站”的計劃，不知是否原來的“星火計劃”已經擱淺。就目前所透露的訊息來看，“新好站”同時滿足：

1. 新上線的網站或“有乾爹”的網站（二級域名）。
2. 好網站是“有乾爹”的網站：服務穩定，速度快，滿足用戶特定需求（如何衡量判斷？），有一定社交傳播度（品牌被搜索次數頻率）

總之“新好站”是網站中的“富二代”，“官二代”。這樣理解或許片面，但是HubSpot One真心希望“新好站”不會像“新好男人”和“新上海人”一樣成為一個尷尬的記憶。

人為乾預方面

負面的人為乾預其實都存在，對作弊網站進行干預。正面的人為乾預的Google遠超谷歌。你是GoogleVIP嗎？

社群媒體方面

谷歌對臉書推特和自己G+上被分享的鏈接會較為重視，特別是快速躥升的鏈接。 Google還沒有透露對社群媒體進行參考，估計相當有限。

對於自身內容的態度方面

如果你去Google搜“可口可樂”，是不是Google百科的頁面會在可口可樂官網之上？從商業角度來講這麼做無可厚非，親兒子嘛。但是你能否保證百科的頁面質量永遠高於其他頁面的質量？百科的內容是否又完全是原創呢？

鏈接好惡的理解

谷歌已經可以對鏈接方的態度進行分析。 Google還不能。最近有朋友發現一個政府公示的賣虛假藥品的網站SEO情況良好。原因就是其獲得了.gov.cn的外鏈。

對http和https的優先級

谷歌最近已聲明會對https協議的網頁進行算法排名優化。而Google很少收錄https頁面或根本不收錄https頁面。

外鍊和標籤使用方面

Google才開始支持nofollow，但是還不支持noindex。另外即使是nofollow鏈接，達到一定數量Google還是會將其考慮為排名因素。 Link Farm還是有效的GoogleSEO手段。

本地搜索和移動搜索

對本地搜索，Google使用<meta name=”location” content=”province=北京;city=北京;coord=116.306522891,40.0555055968″>這樣的標籤，谷歌不使用該標籤。

對移動搜索，Google使用<meta name =” applicable-device ” content=”pc,mobile”>，谷歌並不使用該標籤。

對以上兩者谷歌使用的是信鴿算法，並且通過谷歌的My Business實現。另外谷歌可以在其站長平台通過International Targeting設置網站面向的國家。

對搜索廣告的態度方面

數據證明在自然結果和廣告同時存在的情況下只有7%的用戶點擊了廣告。谷歌非常了解用戶體驗方面廣告的破壞性。因此不會在左側主欄目放置更多廣告。相反，Google相當激進地在此為一些熱門關鍵字放置了多達8個廣告，以至於第一屏無法看到自然搜索結果。這幾乎讓GoogleSEO失去了意義。

對新網站的態度方面

谷歌對新站的態度是“人之初，性本善”，Google反之。下圖真實地記錄了HubSpot One從第一個頁面被收錄到被大量收錄的過程，足足有一個半月（在期間HubSpot One每週會發布新文章推送給Google）。

綜上所述

谷歌和Google是兩個生態環境下的產物，谷歌SEO和GoogleSEO所遵循的方法也不經相同。對於谷歌的一些算法方面的介紹，你可以繼續閱讀其他相關文章。

The post 谷歌SEO與GoogleSEO的異同 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

HubSpot One在兩年前，暨robots.txt二十週年時曾經介紹過這個歷史悠久同時又持續發揮著巨大影響力的txt文件。本篇我們將繼續介紹兩個robots.txt的進階應用。

robots.txt使用要點

在介紹進階應用之前，我們先來溫習一下robots.txt的使用要點：

1. 每個域名（不管是不是子域名）都只能最多有一個robots.txt文件，放置於網站根目錄。 yourname.com的robots.txt對abc.yourname.com沒有約束。
2. 每種協議都可以有一個robots.txt。如http://yourname.com和https://yourname.com可以分別有一個robots.txt。
3. 每個端口可以有一個robots.txt。如http://yourname.com和http://yourname.com:8080可以分別有一個robots.txt。
4. 文件名必須為小寫。不能是RoBotS.TXT。
5. user-agent的名稱以及user-agent ， allow ， disallow ， crawl-delay ， sitemap這些指示符的大小寫不敏感。
6. robots.txt所包含的URL為大小寫敏感。分清大小寫才能有效排除索引。
7. allow和disallow的URL必須是不包括協議、域名、端口的路徑。 disallow : http://yourname.com/abc.htm就錯了。改為disallow : /abc.htm
8. sitemap必須包括從http或https開始的完整的URL。
9. robots.txt不是死鏈提交工具，想要刪除死鏈索引還是應該登陸各搜索引擎站長平台提交。
10. robots.txt只做減法，有沒有這個文件的區別即是去不去做這個排除。刪除robots.txt意味著完全開放爬蟲漫遊。
11. robots.txt只防君子不防小人。歷史上發生過多次違反robots.txt的事件。網站要把機密訊息放到登陸後。
12. 要想嚴格不讓搜索引擎索引還是推薦用noindex標籤。但是Google並不支持。
13. crawl-delay並不被谷歌和Google支持，Yandex和Bing則支持。 Yandex還支持host指示符來表示偏好的域名。
14. 符號#用於註釋。後面的內容會被忽略。

看不見的通配符*

這裡要說的是通配符*。它代表任意長度的任意字符。請注意每一行allow ， disallow之後都有一個看不見的*。

也就是說如果你寫了disallow : /cat/ ，那麼下面的內容就會影響到所有以/cat/開頭的URL，比如：

• http://yourname.com/cat/abc.htm
• http://yourname.com/cat/abc.html
• http://yourname.com/cat/abc/

但是也有例外的情況，那就是allow和disallow之後沒有任何賦值的情況。比如這個官方例子

User-agent : *
Disallow : /cyberworld/map/ # This is an infinite virtual URL space

# Cybermapper 可以訪問任意頁面
User-agent : cybermapper
Disallow :

合併多個User-Agent

如果你有多個討厭的機器人在抓取你的網頁消耗你的資源，那你可能會通過disallow屏蔽他們（當然要他們是君子的前提下）。你可以通過user-agent一次性把他們屏蔽。

User-agent : bad-bot-a
User-agent : bad-bot-b
Disallow : /

這種寫法在當你有多個user-agent，每個雖然都比較複雜但是都一樣的情況下顯得很有用。

User-agent : bad-bot-a
User-agent : bad-bot-b
Disallow : /XXX
#以下省略200行，這樣你就可以讓robots.txt變得簡潔。

為每個User-Agent訂製Sitemap

HubSpot One曾經在《International SEO不完全攻略》一文中指出使用目錄進行多語言網站佈局在SEO上的問題。由於Google這樣的中文搜索引擎並不感興趣那些泰語、挪威語甚至英語、法語，讓Google蜘蛛爬行那些非中文的頁面會造成很多資源的浪費，這不單影響索引而且影響排名。為此我們可以使用disallow把其他次要的頁面屏蔽掉。

但是對Sitemap這個指示符來說，它並不針對某一個user-agent 。不管你的Sitemap語句出現在哪裡它對所有的搜索引擎都是有效的。

如果我們想讓某些搜索引擎只訪問特定的sitemap，這種情況下該如何處理呢？除了在站長平台提交網站地圖，我們還可以在robots.txt內實現。別忘了sitemap文件也是一個資源，我們一樣可以用disallow去屏蔽掉。假定我們有一個全語言的sitemap-all-lang.xml還有一個中文內容的sitemap-zh.xml 。我們可以這樣實現：

User-agent : *
Disallow : /sitemap-zh.xml

User-agent : baiduspider
Disallow : /sitemap-all-lang.xml

Sitemap : http://yourdomain.com/sitemap-zh.xml
Sitemap : http://yourdomain.com/sitemap-all-lang.xml

這樣一來中文站點地圖僅對Google可見，而全語言地圖僅對Google之外的蜘蛛可見了。

Sitemap太大了該怎麼辦？

我們知道，一般來說搜索引擎對站點地圖的大小和所包含的URL的數量都有所限制。比如Google對單個sitemap文件的限制是五萬條URL和10MB的文件大小。在這種情況下，你可以在robots.txt中給出多個sitemap文件的URL。除了這種分拆方式，你還可以使用sitemap索引文件，比如下面這個Google站長給出的例子。 （注意：2020年起，Google已不再支持sitemap索引文件，請在Google資源平台逐個提交。）

其他主流的搜索引擎也認這個索引格式。

那麼問題來了，即便是這樣，文件多且大，傳輸會變得非常沒有效率。為了解決這個問題我們可以對站點地圖進行GZIP壓縮。像7-zip這樣的壓縮工具都可以對文件壓縮。需要注意的是在壓縮前你的單個站點地圖文件仍然必須小於10MB並且包含URL數量小於五萬條。

寫在最後

以上就是我們介紹的robots.txt的高階應用，你能夠改進它的寫法來提高效率了嗎？如果你有其他小技巧請通過HubSpot One的公眾號告訴筆者。謝謝！

The post robots.txt進階使用方法 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

工作中接觸過優化網頁優化體驗的同學都知道谷歌Chrome瀏覽器的開發工具DevTools。一些非原生的APP和小程序也需要進行這些優化。谷歌的Chrome瀏覽器每過一段時間就會推出一些實驗功能。今年我們看到的最大的變化可能就是在DevTools中新推出的Performance Insights。

講到這裡你就已經在Chrome中可以按下電腦的F12鍵開始探索了。也可以看看Chrome團隊的新加坡小姐姐的介紹影片。如果想多聽小馬囉嗦幾句請往下讀。

Performance Insights與Performance工具

在過去，我們進行CWV（Core Web Vitals）診斷的時候，都是通過DevTools中的Performance標籤提供的工具的。現在這個標籤的工具依然存在，HubSpot One曾經在去年介紹CWV的LCP優化時介紹過用法。當時是基於Chrome Build88版本，現在經過了一定的更新迭代，界面雖然有些不同，但還是可以正常且有效使用。

Performance Insights的功能更加簡潔，它是面向治療CWV問題的工具。

開始使用Performance Insights之前

在使用Performance Insights之前我們需要做幾件事：

1. 使用incognito模式，關閉會影響速度的Chrome插件。
2. 選定好設備。通常來說，我們更關心手機環境下的CWV。
3. 使用Throttling功能，調整CPU和網絡情況。
4. 禁用緩存。
5. 進行設定，簡化界面。

最後一步準備是在工具的右上角打開菜單，把不需要的那些模塊勾掉即可。

準備好了以後我們便可以開始跑數據了。

查看Performance Insights測試結果

跑完之後我們可以得到上圖這樣的結果。這裡很清晰了，有幾個看點小馬要講一下。

1. 如圖所示，三個關鍵時間點中FCP先於DCL發生，然後是LCP。我們在兩年前的之前《網頁提速，你的小抄來了》一文中曾經介紹過“DOMContentLoaded代表著DOM和CSSOM都已經就緒，所有阻塞的JS資源都已經執行完畢。”現代瀏覽器可以不等DOMContentLoaded完成先畫上一些內容，這可以增進用戶瀏覽體驗。
2. 當我們鼠標移動到右邊序列中的Largest Contentful Paint後，我們可以看到頁面中會指出具體的Largest Content的DOM元素。這可以幫助我們前端小伙伴鎖定問題元素。
3. 上面的例子中並沒有出現Layout Shift，因此CLS（Cumulative Layout Shift）為0。如果出現Layout Shift，你可以根據具體影響的元素來排查，通常是未事先定義長寬大小。然後前端小伙伴就懂了。 👌
4. 至於CWV中的FID（First Input Delay），我們可以通過TTI（Time to Interactive）這個指標來評估，因為FID需要用戶進行Input。 TTI和FID的關係如下圖所示。一個優秀的FID的容忍度是100毫秒，相當低。實踐中我們可以用TTI的時間減去FCP或者LCP的時間，在這段時間內用戶能夠看到內容，但是用戶的輸入瀏覽器尚無法響應。要縮短TTI的還是要注意消除阻塞資源的影響和那些來自第三方引入腳本的Long Tasks。

在每個Insights問題點點擊後可以查看詳情，一些時候還可以鎖定問題代碼片段。這個的確要方便許多。你還可以把你的測試Export出來給前端小哥。記得給那位最Senior的，Junior小哥只管畫出來，不管性能的。

好了以上就是小馬對Performance Insights這個工具的介紹，有收穫嗎？祝你的網站/APP也有優秀的用戶體驗。

The post CWV救星Chrome DevTools Performance Insights appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

幾乎每一個互聯網企業都會發送電子郵件給客戶。電子郵件是一種可以加載豐富內容，易於閱讀，同時也具有法律效力的溝通方式。當我們大量地發送電子郵件後，最要緊的事莫過於跟踪電子郵件的效果。本週，HubSpot One將教你如何設計和跟踪電子郵件並對此進行分析。

郵件送達率

電子郵件的送達率是指發送電子郵件的數量，和實際發送成功的數量。

郵件的送達率完全由發送服務方來考量，如果你自己發送郵件可以自己統計，如果使用第三方來發送則可以要求第三方郵件服務商提供。郵件送達率的高低由退信數來決定。造成退信的原因有多種，如：郵箱地址錯誤或不存在，域名過期，DNS錯誤，郵箱已滿等。在用戶填寫註冊郵件的時候，還是應該請用戶驗證郵件。這對於提高郵件送達率有很大保障。

如果你不定期檢查你的郵件送達率，剔除那些長時間未曾送達的郵件地址，你的其他郵件指標會大打折扣。更糟糕的事，你的郵件發送端的“名譽”也會受到影響，有可能被列入黑名單。

由於你並不知道有多少郵件被送到了垃圾郵件箱，郵件送達率並不是非常準確的指標。不過作為參考它仍然有很高價值。要想避免郵件被歸為垃圾郵件，你可以添加SPF和DKIM驗證。也可以使用像MailChimp這樣的第三方郵件方的服務進行優化。

郵件打開率

郵件打開率是檢驗你的郵件是否被收件方接受的指標。如果收件方對郵件不感興趣，顯然你的郵件打開率不會很高。另外，如果郵件被大量認定為垃圾郵件也會嚴重影響郵件打開率。

郵件打開率除了技術上避免郵件落入垃圾郵件箱之外，優化你的郵件主題和郵件正文頭部也相當重要。郵件主題要吸引人自不必說，郵件正文頭在許多郵件系統中會被當作摘要截取。所以郵件開頭我們就開門見山，不說廢話最好。郵件發送數我們可以用之前的發送數和退信數之差來求得，那麼郵件打開數呢？

大部分第三方郵件服務商會有自己的一套跟踪郵件打開的辦法，如果你要自己跟踪你可以使用下面的方法：

1. 去註冊並開通一個谷歌DFP賬號
2. 新建一個廣告單元(Ad Unit)
3. 上傳一個1×1像素的圖片並開始投放這個廣告
4. 把下面這段代碼加到你的郵件中去

這裡的1234是你的DFP賬戶ID，ad_unit就是你的廣告單元id，12345678可以是隨機純數字字符串。這樣計算郵件打開的原理很簡單，每次打開郵件這個1×1像素的圖片都會被讀取一次，而DFP廣告系統會統計該圖片顯示的次數。你可以針對不同郵件設置不同的廣告單元。

郵件鏈接點擊率

郵件打開後用戶只是閱讀了訊息，如果你希望用戶有所行動你會添加一個按鈕或者鏈接。這裡你自然會想到用URL Builder來生成鏈接，因為這樣你可以方便地在Google Analytics中統計。

如果你發送郵件就是為了讓收件方進行點擊操作，那郵件的鏈接點擊率就是非常重要的考量指標。

郵件新增訂閱數和退訂數

什麼？你沒有留退訂鏈接給訂閱用戶？那將導致他們無情地把你拖進垃圾郵件箱。當如此操作的用戶累計到一定比率，你的“名譽”也將一落千丈。

電子郵件地址會是你重要的資產之一，有了它你隨時可以白手起家東山再起。記錄考察郵件的訂閱數和退訂數是郵件行銷的關鍵。

制定你的KPI

了解了以上這些關鍵的電郵指標，你就可以開始製定你的KPI。每個企業都會有不同的業務和業務目標，不同的目標會決定不同的KPI。

對於驗證郵件地址的電子郵件，它的目的是確定會員的“合法性”；對於提醒購物車未結賬商品，它的目的是完成銷售；對於週報，它的目的是為了打開郵件閱讀。所以你要謹慎地選擇合適自己的指標，制定最貼切的KPI，而這個KPI將是企業整體數字行銷KPI中的一部分。

下週我們將討論如何提高郵件的到達率，打開率和點擊率。

The post 電子郵件的跟踪和數據分析 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

不久前，HubSpot One曾經和讀者討論過廣告屏蔽軟件插件對整個互聯網廣告業造成的巨大影響和未來的發展趨勢。這不？國慶長假期間又爆出了重磅新聞，擁有4000萬用戶的AdBlock插件被收購了！

Michael Gundlach，該插件的作者並沒有透露買家的真實訊息，而只是說參與了一項“可接受的廣告計劃”。這實實在在是被招安了。從另一個側面看，這也是廣告屏蔽軟件舉足輕重影響力的表現。本週HubSpot One並不想過多地和大家分析這個重磅新聞，而想和大家一同探索如何實際了解你的網站訪客裡有多少已經屏蔽了你的廣告。

廣告屏蔽插件是如何工作的？

廣告屏蔽插件只做兩件事，其一是屏蔽瀏覽器內它認為是廣告的內容，其二是保證其他內容不被屏蔽。因此一款優秀的廣告屏蔽插件是否能有效識別廣告內容是立身之本。廣告屏蔽插件通常通過屏蔽含有某些關鍵字的js腳本並通過日積月累的廣告來源庫對你的瀏覽器加載的內容進行過濾。

受Simo Ahava的啟發，我們通過一個“誘餌”腳本來進行測試。

設置“誘餌”腳本

我們首先要新建一個js腳本，這就是我們所謂的“誘餌”。一旦魚咬鉤了，我們就能看到水面的浮標劇烈活動。這裡的魚就是廣告屏蔽插件。為了讓誘餌看上去更好吃，味道更鮮美，我們為它取個名字就叫“advertisement.js”。對，咱們就叫“廣告.js”了。思路是這樣：我們把這個js文件鏈接到我們的頁面中，如果用戶使用了廣告屏蔽插件呢，js中的內容就不會被加載。所以我們在js中寫入：

邏輯很簡單，如果被廣告屏蔽插件屏蔽了noBlocker就不是true了呢！保存為advertisement.js之後我們把它上傳到網站目錄中去。

設置浮標變量

此時你的好朋友GTM（Google Tag Manager）又要登場了，我們需要在GTM中做2件事：首先是自定義一個js變量。其次是將此變量的值返回給你的另一個好朋友Google Analytics。

首先建立一個Custom JavaScript Variable，就叫{{JS – noBlocker}}吧。內容同樣很簡單：

這裡返回值是：如果noBlocker被我們的advertisement.js賦值了的話返回undefined（未定義），如果賦值失敗則返回true。然後你懂的，我們只要把這個值傳遞給GA我們就可以記錄下帶廣告屏蔽插件的訪問了。值得注意的是如果變量是undefined，GA是不會記錄該值的。所以只會記錄true的情況。

Google Analytics上建立自定義維度

既然要賦值，我們就要給每個訪問新開一個維度，也就是報表上多一列。我們到Admin -> Property -> Custom Definition -> Custom Dimension下面新建一個維度。如下圖所示：

我們記錄下這個新建的Custom Dimension的Index，因為我們接下來要回到GTM繼續配置。

編輯GA標籤

我們回到GTM，打開我們的GA標籤。 （什麼？你還沒用GTM部署GA？！）找到Custom Dimension填入我們記錄下的Index並賦值為{{JS – noBlocker}}。這樣每次頁面讀取我們都會把是否裝了廣告屏蔽插件的訊息傳遞給GA。現在萬事俱備，只欠東風了。我們要新建一個標籤調用我們的誘餌腳本。

新建標籤調用advertisement.js

我們新建一個Custom HTML Tag，取名叫SETUP – Link to advertisement.js。

這裡的路徑記得自行更改。我們保存這個標籤後先別忙著為它加觸發器。我們回到我們之前編輯過的GA標籤，在Advanced Settings -> Tag Sequencing中勾選Fire a Tag before XXXXX，接著選擇你剛新建的SETUP – Link to advertisement.js。保存後我們就收工了。

總結一下

當用戶訪問時首先GTM會調用GA標籤，調用GA標籤之前會先去嘗試讀取SETUP – Link to advertisement.js標籤，不管是什麼結果，GA標籤接下去會抓取{{JS – noBlocker}}的值，最後把數據傳給GA。了解了這個步驟你也可以自己繞過GTM試試純GA的順序代碼的解決方案。

一段時間之後你就可以在GA中查看具有AdBlock這個字段的報表了。你可以通過在標準報表中設置Secondary Dimension或者自定義報表中加入AdBlock的Dimension進行查看。怎麼樣？很方便吧。如果你的廣告系統是自己定義的你可以通過這個手段了解更多實施情況。這還對評價廣告點擊率有更好的參考作用。

如果你對HubSpot One的介紹不是太明白，歡迎評論。也可以通過Simo Ahava的精彩博文了解更多。

The post 你的廣告收入被誰偷走了？廣告屏蔽流量的統計 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

下拉菜單是我們在網頁中最常用到的控件之一。許多時候我們不單想要了解用戶提交表單時選擇了什麼，我們還可能想知道那些未提交的表單中用戶都選擇了什麼。上週GTM專家Simo Ahava分享了使用GTM來跟踪下拉菜單的方法，HubSpot One將在本篇進行二次分享。

新建一個Custom HTML Tag

我們在Google Tag Manager中，新建一個Tag。類型選Custom HTML Tag，然後把下面的代碼貼進去。

<script>
(function() {

// 下面可以填入相對應的CSS選擇器
var selectMenu = document.querySelector(‘select#xuanxiang_id’);
//也可以用’select.xuanxiang_class’ 或者getElementsByName(“xuanxiang_name”)[0]

var callback = function(e) {
var selectedOption = e.target.options[e.target.selectedIndex];
window.dataLayer.push({
event: ‘selectionMade’,
selectedElement: selectedOption
});
};

selectMenu.addEventListener(‘change’, callback, true);
})();
</script>

這裡請注意你需要找到你的下拉菜單的id。通過查看HTML代碼，你可以確定其id。比如有下面這樣的下拉菜單：

<select id=”xuanxiang_id” class=”xuanxiang_class” name=”xuanxiang_name”>
<option selected=”selected” value=”1″>初代奧特曼</option>
<option value=”2″>傑克奧特曼</option>
<option value=”3″>賽文奧特曼</option>
<option value=”4″>艾斯奧特曼</option>
<option value=”5″>泰羅奧特曼</option>
<option value=”6″>佐菲奧特曼</option>
</select>

在HTML中就顯示為這樣：
初代奧特曼傑克奧特曼賽文奧特曼艾斯奧特曼泰羅奧特曼佐菲奧特曼

這個下拉菜單的id就是xuanxiang_id。那麼select#xuanxiang_id又是什麼呢？我們在CSS選擇器一文中曾經介紹過，這是一個CSS選擇器，它可以快速定位HTML中的DOM元素。

接下來我們要給它添加一個觸發器，在這個例子中我們只要它在本文觸發。因此這個觸發器看上去這樣：

保存後我們的第一步就完成了，當頁面https://hubspot.one/gtm-drop-down-menu-tracking/載入時，這個Tag就會在DOM準備就緒時加載。

我們來講解一下代碼，這段代碼的作用是為下拉菜單的監聽器附上一段函數，該函數將當前所選擇的下拉菜單的選項推送到數據層datalayer。當下拉菜單的選擇內容改變（change）時，該函數就會被調用。

將數據推送給Google Analytics

既然數據已經到datalayer了，各位老司機一定都輕車熟路了。我們新建一個GA Event標籤。最新版的界面長這樣：

這裡我們用了三個參數。第一個是選項裡的文本InnerText，第二個是選項的value。我們可以按照下面兩圖進行新建。

第三個GA Config僅僅存儲了GA的Property ID，你可以進一步設置。這是GTM新版本搞出來的新花樣，不過挺省力的，今後你可以不必為每個GA屬性設置半天，直接調用這個Config就可以了。

我們需要一個Trigger來觸發這個標籤，這裡就要用到我們先前在代碼中推到數據層的event。下圖顯示了具體的做法：

小結

納尼？你過了GAIQ了？恭喜你，你終於入門了。 GTM為GA帶來了無限可能性和便捷性，今天我們介紹的例子就是其中之一。如果你想要查看效果，不妨用調試工具選擇本文章上面這個下拉菜單（當然在微信推文中不可以哦）。舉一反三，單選框和多選框會做嗎？

The post 如何利用GTM記錄下拉菜單選項 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

在數據行銷中，有效、及時地掌握第一手數據往往是基本中的基本。在電子商務中更是這樣，了解競爭對手的動態可以讓你更好地對自身產品、定價和表現形式進行優化。本篇我們將直奔主題提供一種簡單的抓取天貓店數據的方法。

準備工作

我們將用到的是谷歌Chrome瀏覽器的桌面版，還有Chrome的瀏覽器插件Web Scraper。該插件可以在webscraper.io下載到，完全免費。

我們假設在Windows平台上，按F12 。 Chrome開發者工具會彈出。我們在菜單中選擇最右邊的Web Scraper先放在一邊。至此準備工作已完成。

天貓店鋪鏈接

我們打開天貓店鋪總能看到全部商品分類的選項。我們選中後會帶我們去和下面URL相似的地址。

https://sony.tmall.com/category.htm? spm=a1z10.5-bs.w17695525-15102841353.2.1be86b1ednN0aS& search=y

上面URL中標紅的參數spm並沒有用，有用的是search還有未在上面出現的pageNo 。前者永遠為y，後者為頁數。那麼索尼官方旗艦店的第二頁商品列表的URL就是

https://sony.tmall.com/category.htm?search= y &pageNo= 2

而索尼官方旗艦店產品只有5頁。所以我們先把這個URL規律和總商品頁數記下來。

新建一個爬蟲項目

我們回到Web Scraper。點擊Create new sitemap 。依次填入Sitemap name： sony-tmall和Start URL： https://sony.tmall.com/category.htm?search=y&pageNo=2 。點擊Create Sitemap按鈕。

新建後我們會在有一個Add new selector藍色按鈕的界面。此處我們的位置為_root 。

這裡的selector的意思是CSS Selector即CSS選擇器。我們在之前文章中詳細介紹過。

建立選擇器圈定商品

CSS選擇器的作用是在HTML中定位。我們現在瀏覽器的地址欄中打開我們要爬的頁面。然後點擊剛才提到的藍色按鈕Add new selector 。

我們首先要選的是頁面元素，每個元素就是一個商品的長方形表示區域。在Id中填入item ，在Type中選擇Element後，我們點擊Selector中的Select按鈕。

當你的鼠標此時放到商品區域邊緣時，該區域會高亮，點擊後再按下面的藍色按鈕Done selecting!你會發現Data preview旁邊已經自動輸入了選擇器。

如果此時你跟著行銷長的節奏，你的選擇器看上去會是這個樣子：div.item5line1:nth-of-type(1) dl.item:nth-of-type(2)

啟用Element preview按鈕時，該塊區域會再次高亮，先關閉它。接下去我們點上Multiple這個選框，沒什麼變化，這是因為我們的選擇器只選擇了一件商品。因此我們要手動進行修改，去掉一些過濾條件把它簡化為div dl.item 。

當我們再次啟用Element preview時，就能看到所有商品區域都高亮了。

點擊藍色按鈕Save selector保存。我們的第一個選擇器就完成了。

抓取各商品的屬性

上面我們只是對一個個商品單元做了定位，它們相當於你的數據表中的每一行。接下來每一列就是我們要在商品單元中真正抓取的數據了。我們大概需要抓取商品名稱（ title ）、價格（ price ）、銷量（ sale ）、評價（ comment ）這些數據。於是我們點入剛剛我們新建的選擇器開始新建這些列。此時我們的位置在_root / item 。

上述4個數據元素的選擇器建立方法和我們上面的方法基本一致，為了節省篇幅我們只說一些區別。

1. 類型（Type）不再選擇Element而是Text 。
2. 由於每個單元中只有一個唯一數據源，因此不勾選Multiple。
3. Parent Selectors記得選擇item而不是_root 。
4. 評論的選擇器中添加Regex： [0-9]+這是為了去掉“評價: ”而只保留純數字。

最後我們要建一個產品ID欄—— product_id 。選擇器為_parent_

保存完最後這個屬性後，我們可以看到界面中有這些選擇器，上面略過的所有選擇器都在下圖中列出，可直接使用：

點擊_root回到上一層，然後點擊藍色按鈕Data preview ，我們就可以預覽這個頁面上我們要抓取的內容。

是不是感覺漸入佳境了？你會發現有幾個商品的評論數為null，這是因為那些是頁面底部的促銷樣式，我們可以在導出後在Excel中過濾掉。現在先不用處理。

多頁面抓取和導出

你是否注意到我們只抓了第二頁？別急，我們現在就來補完。你應該注意到頁碼2/5了。沒錯一共有5頁。我們可以點擊菜單中的Edit metadata來更改Sitemap的設定。

我們只要將Start URL改為https://sony.tmall.com/category.htm?search=y&pageNo= [1-5]就可以連續抓5個頁面了，請放心食用。改完保存後就可以點選上圖菜單中的Scrape，然後開始一路抓取。這裡請注意，由於防爬蟲機制如果你未登錄天貓，那麼過不了多久馬爸爸會請你輸入驗證碼。因此建議你保持登錄狀態。 （至於登錄後是不是會封號，請後果自負……）

爬完了點擊refresh就可以看到抓取完的數據了。是不是滿意呢？再次點擊上圖菜單中的Export data as CSV即可導出數據到Excel進行後續的分析處理，這裡不再贅述。

最後，你可以點擊Export Sitemap導出你新建的項目，便於備份分享。

總結+完整代碼

我們的教程就到此為止了，天貓商舖、淘寶店、各種搜索結果都可以用這種方式來爬，只是選擇器不盡相同，讀者可以自己練習摸索。但是登錄後的搜索結果千人千面是否有參考價值也有待商榷。

最後我們分享一下本次使用的實例。你可以通過Import Sitemap直接使用。但是HubSpot One還是建議你對不同的天貓店進行更改，因為店的域名是不同的。

{"_id":"sony-tmall","startUrl":["https://sony.tmall.com/category.htm?search=y&pageNo=[1-5]"],"selectors":[{"id":"item","type":"SelectorElement","selector":"div dl.item","parentSelectors":["_root"],"multiple":true,"delay":0},{"id":"title","type":"SelectorText","selector":"a.item-name","parentSelectors":["item"],"multiple":false,"regex":"","delay":0},{"id":"price","type":"SelectorText","selector":"span.c-price","parentSelectors":["item"],"multiple":false,"regex":"","delay":0},{"id":"sale","type":"SelectorText","selector":"span.sale-num","parentSelectors":["item"],"multiple":false,"regex":"","delay":0},{"id":"comment","type":"SelectorText","selector":"h4 span","parentSelectors":["item"],"multiple":false,"regex":"[0-9]+","delay":0},{"id":"product_id","type":"SelectorElementAttribute","selector":"_parent_","parentSelectors":["item"],"multiple":false,"extractAttribute":"data-id","delay":0}]}

The post 不會玩爬蟲寫代碼，小白是如何爬天貓店抓數據的 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

網站的訪問速度，與用戶的體驗高度相關，從而還影響了SEO的效果。它是網站用戶體驗中最重要的元素。

本篇文章我們將結合Google Analytics，為讀者揭示影響網站速度，頁面加載速度的各種因素，並為您對網站速度的優化提供一些幫助。

Google Analytics是如何監測您的網站速度的？

Google Analytics使用HTML5 Navigation Timing 接口或裝有Google 工具欄的瀏覽器進行對網站速度進行跟踪。也就是說除了Safari，我們現有的Chrome瀏覽器、Firefox 7以上、Internet Explorer 9以上、Android 4.0以上，以及裝有谷歌工具欄的舊版Internet Explorer都可以正常跟踪頁面打開的速度。

請注意，在此我們用的是瀏覽器的API，所以說該偵測速度並不影響您網頁打開的速度本身。換句話說，Google Analytics對網頁速度的監測不會影響您的頁面打開速度，這裡不存在薛定諤的貓的問題。

默認情況下，Google Analytics只會對1%的樣本進行速度檢測。如果你需要更多的樣本，如果你的網站瀏覽的量並不充足，那麼你可以手動調高樣本的比例。當你使用經典的Google Analytics部署方法時，你可以添加下面的代碼，可以自定義樣本率：

ga(‘create’, ‘UA-XXXX-Y’, {‘siteSpeedSampleRate’: 10});

如果你使用的是gtag：

gtag(‘config’, ‘UA-XXXX-Y’, {‘site_speed_sample_rate’: 10});

上面的例子將樣本率提高到了10%。如果你使用Google Tag Manager來部署Google Analytics。那麼你只要在GA設置中添加該參數的設定即可。

頁面打開的整個過程分解

打開頁面是一個非常複雜的過程，我們可以用下面的流程圖進行拆解。

這整個流程可以給我們非常多的啟示：

頁面跳轉會影響我們的頁面打開時間

許多大型網站的內鏈有許多跳轉鏈，也就是說，當用戶點擊一個鏈接以後，需要進行多次跳轉以後才能達到目的頁面，這會影響頁面打開的速度。

在Google Analytics中也會記錄頁面跳轉所用的時間，因此站外的那些鏈接跳轉的時間也會被包含在內，畢竟這些跳轉時間以瀏覽器的API進行記錄。

DNS的解析時間是頁面打開時間的一部分

我們剛才說了，站外的那些跳轉。那些跳轉也需要進行DNS解析，這裡有許多不可控的因素，但是你完全是可以優化自己網站的DNS解析時間的。因此選取優秀的DNS解析服務器，對網站的加載速度有非常大的提升。

許多DNS解析服務會對不同的線路進行優化。如電信、聯通、移動、海外，甚至對於搜索引擎進行不同的優化。

您還可以使用預解析的方法（dns prefetch）加快這一過程。

HTTP連接的建立需要花費時間

大多數瀏覽器在同時只會開啟六個並行的線程進行HTTP連接，而一個複雜的頁面讀取往往需要建立上百個HTTP連接。因此您需要考慮是否使用HTTP2來加快頁面內容的傳輸速度。

HTTPS加密連接需要耗費額外的時間

我們看到HTTPS的連接需要額外的時間，但是我們認為這些時間是必要的，它極大地增強了網站的安全性。

一些大型網站，對於未登錄的用戶使用未加密的HTTP協議；而對登錄頁面和登陸後的用戶使用HTTPS協議，這也是對網站頁面加載速度的考慮。不過這樣的做法可能造成許多重複的頁面，不利於搜索引擎優化。

高性能的服務器，和簡單的程序腳本會提升網頁打開速度

當客戶端進行請求以後，服務器將會根據情況，計算、運行腳本，來獲得返回的內容。

當您使用Server-side-rendering（服務器端渲染）時，需要計算的工作量增加，響應的速度會變慢，但是這樣可以減輕搜索引擎蜘蛛對您網頁內容的理解進行的投入；反之，當您使用Client-side-rendering（客戶端渲染）時，您的服務器的負擔會減輕，返回的速度會變快，但是這樣搜索引擎需要花額外的資源，用CSS和JS去渲染您的頁面，來理解您的頁面內容。

我們需要對這兩種方法進行權衡，於是就有了Dynamic Rendering（動態渲染）和Hybrid Rendering（混合渲染）。篇幅有限，就不在這裡展開了。

DOM過程是頁面加載的重要內容

DOM 是Document Object Model（文檔對像模型）的縮寫。客戶端下載了服務器端傳來的HTML後將會依此建立DOM樹。

DOM樹決定了頁面元素的結構和內容，此外CSS文件還規定了各個DOM元素的展示方法，JS文件會潛在地對DOM樹進行增添和裁剪。

您或許聽說過一句老話，要把CSS放在<head></head>中，把JS放在頁面最後，就是這個道理。我們要最快畫出頁面的樣子，同時要保證JS不會對頁面的渲染，進行阻塞。

但現代的實際操作中，我們也會把部分CSS放在HTML中，這是為了減少請求，最快展示首屏的頁面內容。對字體來說，在字體下載完成前先展示內容，使用@font-face在下載完成後重新畫出頁面也是常用的增進體驗的方法。

Google Analytics中頁面讀取速度各指標的意義

我們再來回顧一下，GA眼中的頁面打開過程如下圖所示：

還有兩個指標無法用上圖解釋，那就是Document Interactive Time（文檔互動時間）和Document Content Loaded Time（文檔內容加載時間）。

文檔互動時間

文檔互動時間就是從開始訪問到文檔可以與用戶互動的這段時間。它對應了流程圖中Navigation Start到DOM Interactive之間的時間。

文檔互動時間越短，客戶實際等待的時間就越短。可以開始互動，意味著用戶可以上下滾動頁面，也可以點擊一些鏈接。但是頁面的下半部分可能還看不到。比如導航出來了，頁腳還沒有出來。

文檔內容加載時間

文檔內容加載時間就是從開始訪問到文檔內容除了延遲下載執行的那些元素之外已經完成的這段時間。它對應了流程圖中Navigation Start到DOM Content Loaded End之間的時間。此時仍然沒有DOM Complete，一些CSS、圖像和子框架可能還沒有加載完成。它的結束通常意味著JS可以開始執行了。

文檔內容加載時間越短，用戶可以看到完整頁面的時間就越早。這意味著用戶可以看到完整的頁面，並與其進行互動。這個時候可能圖片還沒有出來，只能看到圖片的替換文字，因為JS尚未執行幻燈片還是靜態的樣子。

參考這兩個指標，可能比頁面總加載時間更具科學性。

總結一下

本篇我們介紹了頁面加載的整個過程，並順帶講了部分加快頁面加載速度的方法。提高頁面加載速度是個非常大的話題，無法用一篇文章的篇幅來講透。

正如下圖沃爾瑪對頁面加載速度和轉化率關係的分析，我們需要重視的不僅僅是頁面速度與SEO的關係，而是把它看成真正影響你的收入的一個因素。

Google Analytics為我們提供了可靠的頁面加載速度的手段，由於基於瀏覽器，它不會因為GA腳本下載的延遲而發生偏差。你可以自由地調節樣本率，以對指標更好地理解來指導頁面速度的優化。

The post Google Analytics跟踪網站頁面速度 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.