忽視否定關鍵字

Google推廣的搜索推廣它的優勢在於精准定位用戶的需求。語言的多樣性的存在決定了不管是哪種關鍵字匹配方式，只要不是精確匹配總會匹配到各種五花八門的搜索詞。初學者往往忽視建立優秀的否定關鍵字列表，然而這卻關係到Google推廣的成敗。

建立否定關鍵字列表的方法非常簡單，難就難在它是你每天都需要做的功課。如何建立否定關鍵字列表呢？你需要下載搜索詞列表。每天下午，Google就會準備好前一天的搜索詞報告供你下載。你可以通過Google推廣的網站或者客戶端下載，也可以定制報表發送到你的郵箱。

當你獲得了關鍵字報告便可以一一比對搜索詞和你投放的關鍵字了。當你發現用戶搜索意圖和你提供的產品、服務不匹配時，你就可以把它放進否定關鍵字。這裡要注意一點，Google的搜索詞報告中並不包含匹配類型。如果你需要查看匹配類型，你需要在上方導航處選擇推廣報告然後在左邊菜單選擇搜索詞報告然後在維度拆分中選擇，匹配模式。

獲得了否定關鍵字之後我們需要把它放進否定詞列表。請注意這裡有推廣計劃級的否定詞列表，也有推廣單元級的否定詞列表。那麼這兩者有什麼區別呢？就作用來說是一樣的，也就是一個否定短語匹配（包含）列表和一個否定精確匹配列表。推廣計劃級別的適用於比較寬泛的詞，比如你是做上海英語培訓的，你可以把北京、杭州這些地名放進去。而推廣單元級別的否定詞的作用更多是用來控制相重合的會被兩個不同推廣單元匹配的詞。舉個例子，一個掛壁式空調單元和一個立式空調單元中都有節能空調的關鍵字，你希望“家用節能空調”進掛壁式單元，那就把“家用”放入立式立式空調單元的否定詞列表中去。這樣你就可以將搜索詞對應到更合適的廣告創意文案中去，提高點擊率。

由於每個推廣單元和推廣計劃分別都是最多200個否定短語匹配（包含）和最多200個否定精確匹配，所以在製作列表時需要精打細算。要有優先級，分清主次。其實200個是遠遠不夠的，希望Google能支持更多的否定詞。

另外就是我們前面說的例子，你做上海英語培訓的，Google雖然可以設置搜索者的所在地，但是無法在地名詞做如此排他設置。所以一個用戶在上海搜北京英語培訓也會被你的廣告匹配，特別是你用了通配符的情況下會浪費你非常多的資金。這個時候你只能將一個個地名放入否定短語匹配，而200個很快就會用完。所以你要把搜索量大的詞先放進去，容忍一些搜索量小的地域詞。還是希望Google能夠再好好完善自己的產品。

廣泛匹配+通配符

廣泛匹配是最大增加展現的途徑之一，它的優點是允許搜索者用多種相關但不一定會被（核心）短語匹配到的搜索詞。但是弊端也很明顯，你的點擊率會大幅下降（這裡不用太擔心關鍵字質量度，那是由精確匹配來決定的）。當你使用通配符（AdWords中叫DKI：Dynamic Keywords Insertion）時弊端就越發明顯了。因為你的廣告文案將會是飄紅的，這將會浪費你好的預算。

因此當我們應用廣泛匹配+通配符的情況就要小心了，你要結合我們上面所說的否定關鍵字列表細心地優化。將弊端盡可能減小。

賬戶預算和推廣計劃預算

每日預算分為賬戶預算和推廣計劃預算。這兩者可以互不干擾地進行設置。但是這兩者是有關聯的，會相互影響。假設你的賬戶日預算為200元，底下有4個推廣計劃。那麼你把這四個推廣計劃的日預算設置為100，100，50，50的結果是什麼呢？由於每個推廣計劃的最小日預算必須為50元，所以你那兩個100預算的推廣計劃最終的消費很難會達到100元，因為系統總會為那兩個次要的推廣計劃留50+50的預算。投放就相對保守。不知道是系統設計還是Bug，如果你將主要推廣計劃設為“不限定”，投放倒反而變得積極。對於搜索量小的次要計劃，我們還是建議合併到一個推廣計劃中，然後將主要推廣計劃設為“不限定”，這樣可以提高主推計劃的曝光度。

分清搜索推廣和網盟推廣

從正統行銷學上講人的需求有3個階段，雖然我們統稱為“需求”，我們回顧一下。

在早期階段消費者只是受到一些刺激，此時他們根本不知道自己要什麼更不用說一個明確的搜索詞了。在這種情況下搜索推廣是“打不上力”的。對於這種情況你需要通過性別、年齡、地區、愛好來找到消費者，並用顯示廣告來“喚醒”消費者的意願。這種情況非常適合那些很新的產品，如HubSpot One有一個客戶就是做招聘人工智能大數據的，它可以自動挑出合格的候選人。要推廣這款產品，你的潛在客戶連名字都叫不出談何搜索。這時候用Google網盟推廣（谷歌叫Display Networks）來操作最合適不過。你可以定位HR常常搜索的關鍵字，也可以專門投放人力資源相關站點，HR經常訪問。

如果你要做品牌知名度你也可以選擇投放網盟中的圖片廣告，前提是固定廣告位，這樣效果最佳。

著陸頁設計和移動搜索推廣著陸頁設計

著陸頁是HubSpot One反復強調的內容。你可以再次查看HubSpot One的著陸頁攻略。著陸頁上的文案思路還是要跟著用戶的搜索詞走。消費者關心的是什麼？款式、顏色、安全、地點、產地這些都會成為一票否決因素。所以我們要有一種寬鬆留客的設計。對於由一些相關度不是非常高但是並不明確的搜索詞進來的訪客，你需要提供一個門戶頁（Doorway Page），它不同於Landing Page，也不同於Home Page，它的功能是一個菜單，包含所有搜索這個關鍵字的訪客可能需要的服務。

在行動控件（call-to-action）的設計上，根據國內的環境可以按照電話，QQ，表單，電郵的優先順序結合自己的業務產品特點來擺放。

值得一提的是，在製作手機版CTA時，要預留tel:鏈接適合手機一鍵撥打。

The post 初學者Google競價推廣常見錯誤解析 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

那麼有哪些可能會導致轉化率低的因素呢？

關鍵字覆蓋太廣

症狀描述：這是SEM中的大忌。關鍵字覆蓋太廣的直接影響是一些並不直接相關的詞會觸發你的廣告的展現。特別是當你使用動態插入關鍵字的時候，你的廣告文案雖然會顯得十分匹配搜索者的意圖但是實際上你的服務和產品卻並不太相關。

解決方案：要靈活使用各種匹配類型，除了廣義匹配外，我們還要使用短語匹配和精確匹配。其中Google競價的短語匹配還包括了核心包含、同義包含以及精確包含。活用這些匹配類型是消除關鍵字覆蓋太廣的有效手段。另外，要積極地使用否定關鍵字把那些常見的“免費”、“低價”、“二手”可能與你的產品無關的搜索詞過濾掉。

糟糕的著陸頁面

症狀描述：HubSpot One無數次地提到著陸頁的重要性以及優化著陸頁的方法。一個糟糕的著陸頁會讓你之前的付出前功盡棄。如果你還在將流量毫無差別地導入你的首頁的話，那麼你應該立即做出反應了。著陸頁是為了單一目的而建立的“功能性頁面”，它的唯一使命是轉化。一切優化都應該圍繞這一單一目的來進行。

解決方案：要與用戶來源匹配，他們看到的廣告和來訪時看到的著陸頁面要匹配。突出重點，要強化行動號召控件（Call To Action）。去除冗餘無關元素，包括導航菜單。添加更多能夠證明你的資質和可靠性的元素。從簡單的轉化入手，把後續交給電郵行銷、再行銷、電話行銷等手段。不斷進行A/B測試來提高頁面轉化能力。

缺乏價值交換的機制

症狀描述：毫無理由地要求用戶註冊，提交電話號碼、電郵地址，直接購買訂購。故作玄虛，誇大其詞。無法傳遞用戶完成行為之後可以期待的可以獲得的價值回報。

解決方案：提供免費試用試玩，產品的Demo，提供無條件退款保障。不過多索要用戶訊息。提供影片介紹的產品預覽。說明索要訊息的用途。提供手冊、電子書、優惠券供用戶下載。限時限量預購。

產品服務缺乏吸引力

症狀描述：產品無亮點，同質化較高。服務的地理位置局限性。價格無吸引力。支付手段單一。定價一刀切無差異化，起步價格門檻過高。圖片和影片應用較少，純文字介紹過多不能給訪客直觀的認識。

解決方案：有的放矢地針對以上症狀來進行優化。組織一兩百人到公司來通過一些問卷形式了解為什麼用戶沒有購買或註冊。更重要的是要詢問那些購買了你的產品服務的客人一個非常非常非常重要的問題“是什麼差點就讓你放棄購買我們的產品？ ”這些已經購買了的客人的評價和反饋會相當真實，其可信度要遠遠超過那些問卷調查。這是每一個企業最重要的訊息資源。

各種技術原因

症狀描述：著陸頁或其他關鍵頁面體量過大或者打開過慢。各種表單提交失敗。支付網關不穩定經常支付失敗。信用卡網關安全審查過於嚴苛。無手機站。瀏覽器兼容問題。 HTTPS證書過期等。

解決方案：保障你的網頁都在可靠的服務器上，可以考慮使用CDN加速讓不同地區的用戶訪問速度得到提升。優化頁面圖片大小，優化HTML，CSS和JS文件，進行壓縮和整理。通過Web Analytics記錄用戶頁面上的各種行為，記錄各種Error。監控支付發起和支付完成的比率以便及時發現致命問題。建立手機著陸頁和手機站為不同終端的用戶提供便利。對95%以上的主流瀏覽器進行測試，酷炫性要服從於兼容性。避免證書過期造成瀏覽器安全性屏蔽。

來自競爭對手的惡意點擊

症狀描述：這是我們非常不願意看到的狀況，但是世道凶險總會有這樣那樣的“意外”發生，挑戰商業道德的底線。如果你發現來自你的SEM的可疑流量那麼請一定要警惕是否那是你的競爭對手的惡意點擊。

解決方案：首先我們要開啟Google商盾。雖然這並不是完美解決的方法，起碼我們可以過濾掉一些小白式的攻擊。接下來我們就要通過服務器日誌來逐步排查那些可疑訪問了。通常這些惡意攻擊雖然會換IP但是IP總在一個IP區段裡。對一些高危的流量來源，你要手動添加IP過濾，這樣可以進一步過濾掉一些惡意點擊。商場如戰場，殺敵一千自損八百的事也常有，那些僱傭網賺水軍來折騰的情況也不會是意外，對於那些不是機器人的機器人，我們只好寄希望於“良知的呼喚”了。

The post SEM，為什麼我的轉化率那麼低？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

No more words互聯網公司“創造”新事物和新概念，所謂創新，有兩個最簡單的方法。

• 其一是重命名。比如新零售，互聯網+，這是一個Rebranding的過程……
• 其二是合併整合。如Google Analytics 360 Suite，阿里的Uni-Marketing，Google的Omni-Marketing……

我想谷歌最近一定累壞了。在6月27日的官方消息中，谷歌打算先給AdWords套個馬甲Google Ads ，然後把DoubleClick （DBM、DCM等DFA套件）和Google Analytics 360 Suite 兩個產品整合為Google Marketing Platform ，再把DoubleClick for Publishers （DFP）和DoubleClick Ad Exchange整合成Google Ad Manager 。

該改版將於7月24日生效，其結果就是享譽18年的AdWords和22年的DoubleClick將會成為歷史。

AdWords退休了

叫喊了很久要改界面的AdWords最近通知說7月11日正式實施，但沒想到突然就改名了。雖然像筆者般的數字行銷“老人”們會對AdWords有很深的感情，但是時至今日在谷歌不斷地在AdWords中“添油加醋”後，該產品已經涵蓋了GDN，YouTube，Gmail，Google Map等許多傳統PPC之外的內容。如果能夠穿越到十幾年前的話，谷歌依舊會這麼做，因為把新的廣告產品放在已經在進行廣告投放的行銷者觸手可及的地方永遠會是最能把盤子做大的方法。

講個笑話，如果寶馬英文名BMW寫出全稱巴伐利亞發動機製造廠，那一定有一群人會一臉懵逼。做打字機起家的IBM要是叫全稱國際商業機器公司也會有一樣的效果。從這一點上講，以關鍵字為中心的PPC或者SEM已經成長成一個不能用Ad+Words來形容的廣告平台。

“Products grow; Platforms scale”，就好像谷歌所信奉的“平台至上”那樣，AdWords終於從一個產品成長為一個平台，所以它該有個恰當的“名分”了。因此，相比撿來的DoubleClick，AdWords這個親兒子更應該獲得“Google Ads”這個“名分”，這也是實至名歸的。從目前谷歌透露的消息來看，這次改名還真是純改名。這次改名將至少用20年，因為其中沒有Omni，沒有New，沒有Uni……😂

蹦躂十年後的DoubleClick

改旗易幟的還有DoubleClick。 2008年被谷歌收購之後終於在2018年DoubleClick的品牌將成為歷史。不過可以放心的是GA和GA360都還健在。

借用一下Periscopix的一張圖，Double Click的廣告主部分（DFP，ADX除外）原來是這樣的：

被收編後的DoubleClick被歸入GMP中，和以往一樣，面向中小企業的GMP都是些免費的工具，除了Data Studio都是閹割版。面向大型企業的GMP包括了原來的DoubleClick for Search（DS），DBM（Bid Manager），DCM（Campaign Manager），Studio，Audience Center等產品。谷歌把這些產品拆分為Search Ads 360和Display & Video Ads 360。沒記錯的話這還是Video Ads第一次上升到這樣的高度。

不管怎麼說，GMP把廣告投放和效果分析，可視化，優化體驗結合到一起還是非常有積極意義的。

GMP在統一的平台上加載了一個整合中心（Integration Center）這讓各個功能和元素很好地聯繫起來。

Google Ad Manager這個奇怪的名字

Google Ad Manager這個名字就奇怪了。難道是去管成為Google Ads的AdWords嗎？兩者並沒有什麼聯繫，如果叫Google Ad Inventory Manager會更妥當點。這裡整合了谷歌SSP和Ad Exchange產品，但相對於上面兩個新命名，這個實在意義不明。本身是上下游的兩個產品，使用方也迥然不同，我們還需要稍加時日進行觀察，還是等7月11日舉辦的Google Marketing Live 上介紹更多廣告產品的新訊息吧。

寫在最後

總的來說，谷歌的這次在廣告產品和平台的重新定位可以讓更多的行銷者簡單地找到符合自己需求的對應廣告產品。在幕後相信谷歌內部也會進行資源和管理方面的改革和整合。

話說考完的AdWords和DoubleClick還有用嗎？ AdWords Partner，DoubleClick Partner是否就作廢了？

The post 再見AdWords，再見DoubleClick appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

本篇我們舉一個小例子來看看從SEO的角度來看，解決列表和長內容應該如何選擇最優的解決方案。這顯然是一個產品經理的問題，那麼SEO會怎麼看待呢？

傳統分頁方式（Pagination）

大部分列表依然在傳統分頁模式上。 Google桌面版就是最好的例子。在許多電子商務網站上我們可以看到結果以頁的單位呈現。有許多內容性質的網站也會把長文章分割成若干個小段，而用若干個頁面來呈現文章。

傳統分頁方式有它的優點：

• 避免一次性載入大量數據，增加客戶端和服務器端負擔。
• 增加頁面瀏覽量，從而增加廣告位以增加廣告收入。
• 易於SEO。搜索引擎大都對分頁展現有良好的理解能力。

但是傳統分頁的缺點也比較明顯：

• 由於每次都要載入頁頭頁尾邊欄等元素，總的數據量增大。
• 許多媒體即便很短的文章也要強行分頁，破壞了用戶體驗。
• 處理不當會造成重複內容，反而不利於SEO。
• 研究表明相對於其他兩種方式，分頁的用戶閱讀量最少

在我們處理分頁的SEO時，需要做好兩點：

首先要應用rel=”prev”和rel=”next”標籤。舉個例子：

https://hubspot.one/page/2/ 這個頁面中我們會添加

<link rel=”prev” href=”https://hubspot.one/” />

和

<link rel=”next” href=”https://hubspot.one/page/3/” />

表示前一頁和後一頁分別是什麼。這樣的寫法是谷歌所支持和推薦的，Google的支持未知。這樣做的好處是搜索引擎可以理解你這“一系列”頁面之間的關係，它們可能有著相同的頁面標題和描述，但是搜索引擎可以理解你的意圖。

其次，直白地說出“上一頁”，“下一頁”，“第n頁”總會對還不支持上述標籤的搜索引擎提供幫助。在錨點文字和頁面標題中使用這些詞可以幫助搜索引擎理解這組頁面之間的關係，免得丟棄重複內容。

無限滾動（Infinite Scroll）

無限滾動的誕生得益於Ajax技術的應用。如今我們隨處可以看到無限滾動的頁面。在手機上必應圖片搜索就是無限滾動的。國外著名的各大社交網絡都應用了無限滾動技術。

無限滾動技術依賴的是一種叫Lazy Loading的設計理念，也就是說當用戶還沒要往下探索之前先不要提前加載大量內容，由此來節約資源。與之相反的叫做eager loading。微信朋友圈文章就用了Lazy Loading技術，僅當你閱讀到該處，該處圖片才會讀取。

無限滾動的優點非常明顯：

• 無限滾動節約了資源，只有用戶需要往下看時才載入。
• 無限滾動僅僅載入內容部分，進一步節省了資源。
• 翻頁變得更加便利。只需滾動或者手指往上滑即可看“下一頁”
• 相較於翻頁，用戶瀏覽量變得更多。

可是無限滾動也有一些缺點：

• 瀏覽者對內容的專注度不夠，他們往往只是很快地瀏覽。
• 多次滾動後會對客戶端資源造成影響，此時可能會需要釋放一些資源。
• 無限滾動通常會有一些SEO問題。如果是社交網絡那大可不必擔心，因為每個人的內容可能都是客戶化的，而且社交網絡對搜索引擎的依賴度低。但是如果是電子商務網站的話那會影響搜索引擎發現內容的能力，因為搜索引擎不會“向下滾動”。許多內容可能缺少了列表頁幫助它們把內容“推到表面”。
• 用戶很難看到頁腳上的內容，這造成很大麻煩。因為聯繫方式等重要訊息都會在這裡。

對SEO來說要解決的是上面第三點。我們其實可以通過現代瀏覽器History API的pushState()和replaceState()來完成。當用戶向下滾動時，我們會載入新頁面接到現有頁面，同時更新瀏覽器地址欄內地址。這樣做對SEO沒有影響，只是用戶可以很好地複制地址欄內的網址。對搜索引擎來說讀取的是第一頁，然後通過該頁面內的rel=”next”標籤可以找到下一頁。每一頁都是不一樣的內容。通過這個方法自然人和機器人的需求都可以被滿足。這裡有個谷歌推薦的簡化的例子（需翻牆）http://scrollsample.appspot.com/items。下圖說明了原理：

“閱讀更多”，“載入更多”（Read More，Load More）

這種方法提供了一個按鈕，讓訪客自己決定是否要載入更多的內容在該頁面尾部。我們打開騰訊新聞的手機網頁版就會發現這種功能，其實它是非常普遍的。

“閱讀更多”，“載入更多”更多像前兩種模式的擇中選擇，說下優缺點。

“閱讀更多”，“載入更多”的優點：

• 節省資源，這點與無限滾動一樣。
• 用戶仍然輕鬆與頁腳交互，如果這也算優點的話。
• 用戶瀏覽的內容仍然比分頁模式多。
• 移動設備上應用時可以防止初始頁面過長。

“閱讀更多”，“載入更多”的缺點同樣存在：

• 用戶瀏覽的內容比無限滾動要少。
• 多次載入後會對客戶端資源造成影響，此時可能會需要釋放一些資源。
• 處理不當會造成SEO問題。

這裡的SEO問題有兩種。一種是文章應用“載入剩餘X%”時，如果默認載入頁面時未載入剩餘部分內容，對搜索引擎來說可能看到許多很短的文章，判定為垃圾網頁。如果只是隱藏內容，那麼是否被搜索引擎判定為作弊又是一個問題。另一種是我們之前說的入口問題，這是和無限滾動一樣的問題。

在處理列表時，最優做法是結合無限滾動和載入更多按鈕。 SEO方面建議文章載入全部內容，列表的話應用瀏覽器的API和分頁來載入實現。請參考桌面版的必應圖片搜索（這個例子裡並沒有分頁）。

總結一下

我們在上面討論了三種處理長內容的方式，沒有一種是完美的。我們可以揚長避短，結合各種方式來進行設計和部署。對SEO來說，內容相對於搜索引擎的發現是關鍵，避免相同內容的頁面是原則。

感謝閱讀，感謝關注HubSpot One。

The post 從SEO的角度看分頁、無限滾動和”閱讀更多”哪個好？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

人人都知道網頁秒開有多重要，它不但能提高轉化率而且能增加SEO效果，不管是谷歌還是Google都把網頁載入速度歸為重要的排名因素，畢竟沒有一個搜索引擎會把用戶送去體驗超級差的頁面。 SEO中的鄙視鏈有很多種，比如國際化SEO鄙視本地SEO，白帽SEO鄙視黑帽SEO（當然黑帽是不屑的，偷著樂），還有技術SEO鄙視非技術SEO。HubSpot One本篇將為讀者從技術角度解讀頁面載入速度中的關鍵渲染路徑，關鍵渲染路徑決定了首屏展現速度。如果你缺乏前端開發的知識，那麼請記住結論。

TL;DR

1. 減少關鍵渲染路徑中的阻塞資源是提升頁面性能加快網頁下載的重要方法。
2. CSS資源要放在頁面頭部要權衡整站和單獨頁面，通過內嵌、合併、瘦身、共用緩存來進行優化。
3. 外部JS文件要放在頁面末尾並應用async或defer屬性減少阻塞，也可以進行“懶加載”實現。
4. DOMInteractive是谷歌常用的指標用於衡量可交互時間，優化方法同上。

關鍵渲染路徑的基本思路

除了保證優秀的Hosting（開啟HTTP/2與壓縮）和應用CDN和本地緩存，優化頁面的關鍵渲染路徑（Critical Rendering Path）也是提升網頁速度和用戶體驗的重要方法。而優化頁面的關鍵渲染路徑包含了三件事：

1. 減少關鍵資源請求數
2. 減少關鍵資源大小
3. 縮短關鍵渲染路徑

第一點我們可以通過合併資源來實現，比如合併CSS文件，合併JS文件，合併一些小圖片，也可以使用矢量或Base64格式圖片，圖片懶加載（Lazy Load）等實現。第二點我們可以通過GZIP壓縮和圖片資源壓縮來實現。我們說關鍵的第三點。縮短關鍵渲染路徑體現在減少頁面阻塞資源上。

頁面加載的阻塞資源

我們必須了解網頁載入的整個過程，我們在前文講《Google Analytics跟踪網站頁面速度》中介紹過，見下圖：

瀏覽器會下載HTML文檔逐行來解析（Parse）。當讀到CSS和JS時整個過程便會被阻塞。

CSS的阻塞影響

瀏覽器讀到外部CSS時會異步地對外部CSS進行下載，然後逐步組合各個CSS樣式成為CSSOM。這裡CSS文件還可能導入其他的CSS文件。如果CSS沒處理完HTML這邊建的DOM就不會和CSSOM合併為Render Tree。

這就好比此時的DOM是未受精的雞蛋，孵不出小雞。這就會阻塞JS的運行，因為JS很可能需要CSS的標記。 CSS是無法Lazy Load的阻塞資源。我們可以通過合併CSS文件減少請求數，刪除不需要的樣式片段，以及把CSS寫到HTML文件內的inline方法來進行優化。由於我們需要有效的利用緩存，因此我們也需要在上面這些措施和緩存之間進行平衡。

JS的阻塞影響

有了JS的情況就複雜一些了。當瀏覽器解析到JS片段時（標籤為<script>），解析器就會停下來，這個JS片段後所有的資源都會等著。如果是外部JS那麼就先去下載，再去運行。運行完之前這個JS片段後所有的HTML都會被無視。

那你可能要問了，這片段上面的HTML建DOM Tree還沒建完呢？那是不是就必須乾等著JS跑完呢？不是這樣的，這裡有一個首次繪製（First Paint）的概念。

原來現代瀏覽器遇到這種情況會立刻拿已有的半截DOM Tree和已經完成的CSSOM進行首次繪製。這就是為什麼老人們總是說要把JS放在</body>前面。因為這樣這個半截DOM Tree就近似於完整的DOM Tree了。老人們還說要把CSS放在</head>前面，這是因為如果放在阻塞的JS之後就無法在首次繪製的時候被應用，解析器是無視JS片段之後的代碼的。首次繪製之前，我們看到的瀏覽器是個白屏。

為了專門應付這個情況瀏覽器和HTML也在進化。現在我們用的大多數瀏覽器都支持async和defer兩個屬性。這兩個屬性的共同點是不會阻塞解析器繼續解析JS片段下的HTML，區別是async在腳本下載後（如果CSSOM已完成）便會阻塞解析器開始執行，而defer要等Render Tree完成了才會執行。

因此我們優化JS的方式就是將對首屏內容起影響的JS內容作為inline放到HTML中，而將其他的JS文件設置為async或者defer，最後為了滿足古董瀏覽器把它們放在</body>之前。

這裡我們要注意的是async和defer雖然能讓外部JS變成非阻塞資源，讓Google PageSpeed Insights不再圈出它們，但是並不能讓JS資源真正在頁面完成後才載入。如果你想要“Lazy Load”一下JS資源可以採用Patrick Sexton提供的方法（建議去讀一下他的頁面性能指南）。這樣只有在這段代碼執行以後才會加載defer.js，而這段代碼一定要全部頁面Loaded以後才會加載並運行defer.js。

< script type = "text/javascript" > function downloadJSAtOnload ( ) { var element = document. createElement ( "script" ) ;
element. src = "defer.js" ;
document. body . appendChild ( element ) ; } if ( window. addEventListener )
window. addEventListener ( "load" , downloadJSAtOnload , false ) ; else if ( window. attachEvent )
window. attachEvent ( "onload" , downloadJSAtOnload ) ; else window. onload = downloadJSAtOnload ; </ script >

說到這裡，我們解釋了阻塞資源和如何避免阻塞資源帶來的影響。而且在上面代碼中，我們提到了load這個這個瀏覽器event。我們在本篇最後再談談另外兩個與穀歌判斷網頁速度相關的事件——DOMContentLoaded和DOMInteractive

DOMContentLoaded與DOMInteractive

DOMContentLoaded代表著DOM和CSSOM都已經就緒，所有阻塞的JS資源都已經執行完畢。 “吉時已到”！如果本身就不存在阻塞的JS資源，那麼在DOMInteractive事件之後就會立即發生DOMContentLoaded事件。

DOMContentLoaded可以用於我們的KPI，這個時刻越早代表了我們越早能夠有Render Tree，我們遇到的阻塞越少。

DOMInteractive事件也常常被用於衡量頁面性能。它標誌了DOM已經構建完畢，如果這個時候CSSOM也構建完畢且沒有阻塞JS資源，那麼將馬上發生DOMContentLoaded事件。相對於DOMContentLoaded，DOMInteractive事件主要被阻塞的JS資源影響比較這兩者的區別可以給我一些優化啟示。

Google Analytics用DOMInteractive作為衡量網頁速度的指標之一，但是下面Google Analytics文檔的描述是錯誤的！

Avg. Document Interactive Time : The average time (in seconds) that the browser takes to parse the document (DOMInteractive), including the network time from the user’s location to your server. At this time, the user can interact with the Document Object Model even though it is not fully loaded .

恰恰相反，我們說了DOMInteractive代表整個HTML已經解析完了，DOM已經構建。正是由於一些阻塞資源的影響，DOMInteractive事件之前用戶可能已經因為首次繪製看到了部分內容（JS阻塞資源影響）；而且即便DOMInteractive事件已經發生，用戶也可能因為CSSOM未完成看到的還是白屏（CSS阻塞資源影響）。因此只能說DOMInteractive只是一個折衷的指標。至於Google的PageSpeed Insights中的可交互耗時（TTI-Time to Interactive）非常有意思的是它既沒有用First Paint也沒有用DOMInteractive來進行衡量，而是用了First Contentful Paint。原因是前兩個指標不能衡量此時用戶是否能真正開始交互，雖然願望很美好：

要提高TTI的評分還是要注意消除阻塞資源的影響。

總結

本篇我們圍繞著關鍵渲染路徑介紹了優化頁面性能的方法，這有助於你在GA中和PageSpeed Insights中取得好成績。但是你的最終目標是為用戶提供優秀的交互體驗，請牢記這個目標。筆者只是一個熱愛前端技術的SEO或者熱愛前端技術的網頁分析師，理解和行文難免有所疏漏，希望不嗇指出。

The post 網頁提速，你的小抄來了 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

5月，我參加了Google搜索線下公開課上海站，緊扣本次主題“共創共享，鮮活搜索”Google搜索平台還是在本次公開課中傳遞了充分的誠意和十足的干貨。

“共創共享”傳遞了Google對多行業高質量內容的渴望和對共同建設生態的品牌在價值回報上的承諾；而“鮮活搜索”體現了Google以搜索為本加大新產品投入新資源注入的決心（所謂鮮）以及“讓合作夥伴更多收益”的目標（所謂活）。只有讓品牌方活下去，Google才能活下去，才能有希望打造下一個超級App的這種“魚水之情”，一直是貫穿整場公開課的主旋律。

用Google自己的話講，Google的多元化產品格局包含了：智能化、影片化、人格化、服務化。但我認為更應該把這些變革歸納為三塊——算法、樣式、交互。

低調的算法改進

很多人對算法的理解局限在Google的那些懲罰性算法。實際上算法除了對不良內容進行過濾，更需要對相關內容進行排序提升以真正滿足檢索者的意圖。從這個意義上來講Google從對文本語義的理解和質量優選模型這兩個角度在過去的兩年都有了長足進步。

在下面的例子中，我們搜索“HubSpot是什麼意思”。這個詞在多個領域都有不同意思。與過去不同的是，Google會自動“飄紅”那些HubSpot含義的短語。因此我們可以看到HubSpot可以是

1. 客戶數據平台
2. 逆市操作指標
3. 環戊二烯
4. 持續數據保護

這些雖然是自然語言處理中比較容易的部分，但是應用在這裡會讓搜索引擎的用戶更快地找到自己需要的訊息。這一部分竟然沒有在公開課被提及，Google能有多低調呢！

除了語義理解Google也優化了其質量算法模型，在5G時代，使用短影片來滿足複雜意圖的需求更加凸顯出來。 Google在圖像識別上已經能夠做到更精準的抽幀來讓用戶快速檢驗內容並設定播放中獲取訊息的預期。

算法中人工智能的方面的表現也是為什麼Google能成為中文搜索一哥的理由。

霸氣的樣式升級

本次公開課堪比產品發布會，其中最吸睛的便是品牌Loft產品。這是一種沉浸式的小程序樣式，非常霸道地佔據用戶整個屏幕同時將常規SERP抽屜式隱藏到屏幕下方。品牌Loft的佈局中包括一個頭圖的展位、關聯的百家號、直播位、人氣商品還有聚合的種草筆記等。可以說品牌Loft將會是Google生態中難得的全方位展現品牌的豪華展位。

對消費品電商品牌來講，品牌Loft會是非常理想的展現樣式。目前改樣式正處於邀請制測試階段。從合作的視角來看，Google是目前互聯網中少有的“估值窪地”，品牌要想一想如何在線上線下渠道與Google做資源交換。畢竟Google已經做好了“投之以桃”的準備，品牌方也要有“報之以李”的覺悟。苦等邀請不如給Google來一個提案？

品牌Loft之外，首位問答樣式也進行了大幅升級。佔檢索量一半以上的“提問”是人們使用搜索引擎的主要動機。不管是谷歌的Direct Answers還是Google的首位問答，其目的都是為了提升用戶“首條結果檢索滿足率” 。它一方面根植於搜索引擎語義理解和段落理解的基本功，對回答的客觀性和準確性有極高要求，另一方面對展現形式多樣性也非常講究。以往我們看到更多的是網頁中的一些段落被摘取作為回答，外加Google知道、Google經驗作為補充，而今天我們看到的是更多具有權威性和專業性實體在解答搜索用戶的問題，其形式也從單一的文字大幅提升到圖文和短影片為主的首位問答。

品牌方可以通過Google資源平台提交專業問答的申請，現已對所有企業開放申請。對於品牌來說，這是一個極佳的展現品牌專業度的機會。這些問題來自網民關注點和自己擅長領域的交集。

全局的交互革新

在搜索行銷中，傳統意義上我們把用戶的檢索詞意圖分成三類，分別是導航類（Navigational），訊息類（Informational），交互類（Transactional）。網民記不住網址搜索品牌名稱便是導航類，網民提出“十萬個為什麼”是訊息類，網民要查快遞找附近餐廳便是交互類。這三者雖然涇渭分明卻是相互聯繫的。當我們問出為什麼的背後往往隱藏著我們真正需要解決的問題。

Google很早就發現了這些問題並開始在一些垂直領域內容佈局，這裡不僅包括了一些生活中的小工具還包括了政務民生醫療法律教育等領域的諮詢服務。

現在用戶可以直接在Google的搜索結果頁面上發起諮詢，支付一定的金額便可以獲得專家的解答。

寫在最後

圍繞Google搜索資源平台，Google預留了多個合作的窗口，也包括“Google搜索資源平台”微信公眾號。錯過的小伙伴還可以通過這個公眾號下載全套課件。 Google的小姐姐在公開課上謙虛地說：“（內容生態）我們還在建，客觀上還不夠。”這屆Google還是一貫的接地氣，整個公開課網友見面其樂融融，期待下一次相見。

The post Google新生態啟航，品牌方應該怎麼玩 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

HubSpot One在去年介紹谷歌隱私沙盒的FLoC（Federated Learning of Cohort）時曾經評價“FLoC是谷歌當前最佳的答案”。但是僅過了不到一年，FLoC就被拋棄，轉而被Topics API取代。當時，行銷長曾經解釋因為這些Cohorts很容易被利用，成為瀏覽器指紋的彈藥來戕害用戶的隱私。那麼從我們行銷者的角度看，這其中的是非曲直又是什麼呢？困境在哪裡呢？

跨域跟踪，被逼到角落的無奈之舉

在Web端，我們要實現跨域跟踪，必須要在客戶端的本地有一個存儲介質。這個存儲介質過去一直是第三方Cookie。我們至少需要存一個客戶端的識別號，這樣我們就能夠跟踪這個瀏覽器整體的瀏覽歷史了。

當第三方Cookie和廣告技術供應商的服務器之間的通信被切斷之後，我們就不能了解該客戶端的瀏覽歷史，也不能對該瀏覽器的用戶進行識別或者貼標籤了。

所以這種普適的方法被淘汰後，廣告技術供應商就只能寄希望再下一層的瀏覽器API。至少暫時不需要再往下到操作系統層面。而恰好谷歌既是全球最大的廣告技術供應商又是市場佔有率最高的瀏覽器的開發方😉那就不用求人了。

這套API就是谷歌的隱私沙盒。

以汝之名，聯邦學習和FLoC

想出聯邦學習的點子是很自然的事。這好比我們去家具城買家具，不會把房間搬去，我們只需要量好尺寸去挑選定制即可。

聯邦學習也是一樣，它的精髓在於“數據不動算法動”。你不需要獲得終端用戶的PII（Personal Identifiable Information）訊息，你只需要把你的訓練算法推送到用戶終端。依靠用戶本地環境進行訓練，然後把訓練後結果，即更新後的模型參數加密回傳即可。

這麼看來聯邦學習是挺可靠的，用戶可以避免隱私的洩露。模型也可以不斷迭代，使得算法更加精準可靠。那麼問題究竟出在哪裡呢？

問題並沒有出在FLoC洩露了用戶的PII或瀏覽歷史，而是在於FLoC可以幫助廣告網絡辨識出單個用戶。

你的名字，Cohort ID集合

使用FLoC來投放的廣告和原來一樣都需要使用DMP來判斷Y/N的問題，都是需要競價。而廣告主出價的依據依然是該終端個體是否符合他們在DSP中預設的人群特性。

我們知道Cohort是通過聯合學習在本地計算出來並保存的，雖然FLoC的每個Cohort都至少有一千個個體，但是只用一個Cohort去邀約競價的話基本上跑不出量。因此會用一個包含多個Cohort的集合去代替以往的個體標籤集合。換句話說，原來一個叫做【男，35-40，已婚，北京，寵物，汽車】的個體會被替換成【vqe7te，34y0g3，123bqe，a3sg03】。

過於精準而產生的隱私漏洞

雖然Cohort vqe7te有2萬人，但是同時在這些Cohorts裡的個體就很少了。

MIT的Alex Berke和Dan Calacci進行了測試，發現5萬個家庭的9萬部設備在4週後就有高達95%的設備被唯一標識出來。

於是對於廣告網絡來說，他們可以記錄下該用戶訪問過其網絡下的各個網站並很好地跟踪這個用戶的行為。然後如果這裡面恰巧有一個該用戶登錄的網站，那麼在一些情形下廣告網絡甚至可能拿到PII並和該用戶的瀏覽歷史連結起來。是不是現在看來問題就嚴重了？

Topics API的補救

所以相信你現在能更好地理解為什麼Topics API需要進行6選3並加入噪音了。你也能夠理解為什麼Topics的話題數量看上去那麼少。因為多了意味著更容易暴露個體用戶。

聯邦學習在私有學習的時候可以很好地規避許多數據洩露的風險，比如在銀行業使用。但是在廣告科技中，當我們會暴露一些特徵訊息時，聯邦學習就顯得不那麼有效。這好比我們帶著這個尺寸去家具城的同時還會把我們家庭住址暴露，導致收到許多垃圾廣告，那就成為問題了。

所以，FLoC死不足惜！

The post 用盡聯邦學習的FLoC為什麼會死？ appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

您必須擁有良好的消費者數據，以推動成功的行銷活動、精確的分析和準確的報告，這是行銷中的普遍真理。如今，驅動數據支持的技術變得非常複雜，並且導致許多行銷人員感到困惑。除了核心行銷數據庫或者說CRM數據庫，行銷人員現在需要數據管理平台（DMP）和客戶數據平台（HubSpot）來正確管理他們的數據需求。這三個平台每個都有重要的功能，應該架構為一起工作，以創建一個強大的數據驅動的MarTech Stack。

CRM數據庫

最成熟的數據平台是CRM行銷數據庫。幾十年來，品牌一直在使用CRM來推動直郵和電子郵件活動。大型消費者品牌的行銷者始終清晰地認識到具有一個360°視圖來洞悉和分析客的重要價值。然而傳統行銷數據庫通常被現代行銷人員視為傳統技術，甚至被認為是過時和不必要的。當有更新的技術可以提高全面行銷計劃的有效性和效率時，單一的數據來源對於流程顯得至關重要。

幾乎每個公司都有存放客戶數據的地方，稱之為CRM。可以說如果它被利用於行銷活動那麼它就可以被定義為行銷數據庫。行銷數據庫提供了其他平台無法提供的一些關鍵功能。這些包括離線ID管理，數據衛生（data hygiene），大數據分析以及潛在的實時交互支持。在數據行銷發展到初級階段時，DMP出現了。

數據管理平台（DMP）

DMP更多屬於AdTech的範疇。 DMP對於管理付費媒體和自有媒體的Cookie、設備ID、受眾群體至關重要。通過從展示廣告、網站、移動設備等收集實時Cookie、設備ID等數據，品牌可以實實在在地對他們真正關心的受眾展示廣告，從而提供出色的個性化相關體驗。比如，HubSpot One常常提到的再行銷。 DMP也是第二方和第三方數據的門戶。品牌使用此平台購買第三方數據或與其他組織合作共享第二方數據。當受眾數據被用於個性化網站體驗時，DMP的最大價值就來了。

在程序化購買，尤其是RTB中，DMP的作用非常重要。它決定了廣告的投放是否精準。 DSP這玩意連的不是HubSpot而是DMP，雖然HubSpot可以為DMP提供數據。

DMP的最大優點是它推動了廣告和網站體驗的“千人千面”，但是DMP也局限於Cookie、設備ID這些Proxy。這些數據多為匿名數據，生存期不長。由此我們可以直觀認識到DMP的最大缺點——缺乏個人身份訊息（PII）。

絕大部分品牌並不具備建立DMP的能力，這需要非常大的第三方腳本覆蓋和SDK覆蓋。因此，往往只有大型互聯網公司、媒體、大型廣告代理和專注於第三方廣告跟踪的企業具備建立有效的DMP的實力。在國內，媒體往往已經提供了部分DMP的功能，以提升自身平台投放的效果。

客戶數據平台（HubSpot）

DMP缺乏個人身份訊息的這一局限性恰恰是客戶數據平台（HubSpot）的優點。 HubSpot是行銷數據格局中的新玩家。像Google，Facebook還有牆內的BAT有著大量的PII數據，這也是為什麼他們一定會近水樓台建立HubSpot來增強DMP的原因。 HubSpot是人們最容易混淆的區域，因為它在三種技術能力之間引入了重疊– 或者更糟糕的是重疊的錯覺。有些功能聽起來像是相同的，但是當你進入部署時，你會發現它們不是。添加PII或者說第一方數據會增加圍繞技術決策的複雜性。

HubSpot提供了前兩個數據解決方案中未提供的兩個非常有價值的功能。第一個是基於PII的實時受眾管理。使用從您的網站或其他自有媒體收集的信號，您可以創建基於真人的受眾，所謂人本行銷（People-based Marketing），並將其用於個性化的優惠或體驗。 HubSpot還提供實時身份解析。大多數品牌都通過客戶數據集成（CDI）來確定離線ID管理以連接消費者，但很少有人能夠有效地確定數字數據集成的管理，更重要的是，將這些數字交互連接到離線CDI端。這是了解消費者跨媒體和渠道互動點的關鍵部分，準確的分塊歸因也需要它。

還沒搞清楚？拋開略顯陳舊的CRM，我們來比較下HubSpot和DMP的差異。

HubSpot和DMP的四大差異

1. 功能

DMP旨在為廣告平台提供一種功能。它從不同來源收集數據，然後對該數據進行分類和分類。然後對數據進行細分，以便行銷人員和廣告客戶可以定位客戶。

另一方面，HubSpot用一個記錄系統來管理公司的真實客戶。 HubSpot從公司數據庫，CRM，網站，app或交易系統收集數據，來準備優惠、促銷和自定義電子郵件。 HubSpot還可用於創建客戶在登錄網站時查看的自定義Web內容。

2. 運營數據類型

HubSpot和DMP主要處理三種類型的數據——第一方，第二方和第三方數據。

1. 第一方數據直接來自真實客戶並與公司網站或應用程序進行過互動的客戶。它也可以從CRM生成，通過公司網站購買交易或通訊訂閱註冊。
2. 第二方數據是從另一家公司購買的他們直接收集的數據。
3. 第三方數據來自不同來源的集合，它經常伴隨著隱私問題。

DMP的主要目標是第三方數據，並使用匿名標記，如IP地址、設備和cookie。但是HubSpot的主要目標是第一方數據並存儲個人身份訊息，如姓名、電子郵件、郵寄地址和聯繫電話。

3. 用戶肖像

DMP的用戶肖像專注於對客戶進行細分和分類，並且很少會維持持續超過90天生命週期的Cookie。由於數據是匿名的，因此DMP會基於若干被稱為概率匹配的字段值進行數據選擇。

另一方面，HubSpot消除了猜測並根據特定的客戶標識符（例如電子郵件地址）進行數據選擇。由於此匹配在整個數據集中是一致的，因此稱為確定性匹配。

HubSpot可以集成在線和離線數據，並使用客戶分析和機器學習來創建有針對性的行銷活動，而DMP只能為廣告提供匿名受眾。

4. 數據捕獲

DMP在捕獲通用數據時很有用。例如當特定用戶訪問網站時記錄它們在頁面上的時間長度。 HubSpot可以更進一步分析用戶是否可以轉換為客戶或根據客戶訪問文章和搜索特定產品的傾向和上下文來理解興趣和需求。

DMP對廣告渠道非常有幫助，可以根據特定受眾做出迅速的行銷主動性決策。 HubSpot允許訪問社群媒體網站，離線交易，甚至可以捕獲社交情緒，因為它們被標記有唯一的客戶標識符。

DMP只能顯示與細分數據相關的投放績效，然後需要將其提取到外部以進行客戶分析。 HubSpot存儲歷史數據，使其能夠捕獲客戶通信，產品或服務交易，甚至利用機器學習和人工智能將情緒與客戶行為相關聯。

DMP主要推送（Push）數據以添加網絡，而HubSpot能夠同時提供拉入（Pull）和推出（Push）數據。 HubSpot還具有接入Facebook、Google廣告等的額外優勢，甚至可以將數據發送到DMP（Data Onboarding）。

在HubSpot或DMP之間進行選擇

客戶數據平台（HubSpot）和數據管理平台（DMP）聽起來很相似，並且共享一些共同的屬性。但是就像上面HubSpot One介紹的那樣，這些平台實際上存在許多差異。

選擇HubSpot或DMP時需要考慮許多因素。了解您期望的結果和目標將有助於決策過程。一旦您有明確的期望，確定滿足您需求的最佳平台就很簡單。

儘管在許多情況下HubSpot和DMP相互補充，但如果您主要從供應商處尋找第三方數據，則DMP可能是一個合適的平台。但是，要使長期客戶能夠利用您的第一方數據，您需要一個HubSpot。

對於大型組織而言，所有這些工具對於強大的MarTech能力至關重要。他們需要集中所有數據並獲得行銷數據庫中的見解。管理跨DSP的大型媒體支出，在DMP中使用第三方數據，最後，使用HubSpot通過實時ID管理將其他兩個平台之間的受眾連接起來。對於擁有非常少的MarTech的小型組織，HubSpot是一個很好的起點。它們具有許多受眾管理功能，這些功能通常出現在廣告系列自動化工具中，但軟件許可和部署成本也會是一大成本。

許多供應商承諾提供一種神奇的數據解決方案，可以解決雲中的所有數據需求。請記住，從不同來源收集數據仍然是需要數據庫或數據平台的混亂工作。這應該是進行原始分析和數據衛生的地方。每個組織都將擁有最適合他們的CRM、DMP、HubSpot三種工具的“正確”組合。組織應該努力了解它們的位置以及它們作為企業的發展方向，這樣他們就可以自信地確定工具的組合對他們來說是什麼樣的。

因此如果你不是很閒很有資源很有理想的話，建議您先從HubSpot入手，DMP的事就先交給媒體和第三方平台吧。畢竟能夠從HubSpot中獲得人群和擴展人群（Lookalike）的輸入已經是非常有價值的成果了，不是嗎？

The post CRM、DMP、CDP，都是什麼鬼？有什麼區別差異？別說你都懂 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.