HubSpot One有整整一個季度沒有涉及任何SEO的新內容了。即便如此，我們無時無刻不在關注國內外的SEO動向。本週HubSpot One將會綜合國內外的搜索引擎動向，為各位SEO提供一些一家之言。如果有任何讓你不快或者無法苟同之處敬請見諒。

SEO不死，只是凋零

就在HubSpot One開始寫這篇準備良久的博文之前，Google站長平台發表了《一張圖看懂收錄與索引的區別》。如果你覺得這篇文章味如嚼蠟不知所云，那麼HubSpot One為你翻譯成大白話：

Google可以充分地發現互聯網上絕大部分內容，凡是被Google“發現”的內容會被Google“收錄”。 “收錄”是一種“然並卵”的狀態。因為如果該內容沒有足夠的流量（有效外鏈，新聞源除外）作保證，Google並不會“索引”它。而索引等於出現在SERP。所以不要問我們為什麼谷歌或者必應收錄了，我們沒收錄。我們收錄了只是沒索引。沒索引的原因要問你自己了，呵呵呵。

實際上這是一個“先有雞還是先有蛋”的問題。如果你期望的是你的定位讀者，而你的讀者並不善於為你產生外鏈的話，那麼你的SEO會相當薄弱。如果你期望於SEO為你產生外鏈，那麼你可以洗洗睡了。即便有高質量的內容，一旦進入這個負面循環，一樣是事倍功半。

對一個品牌來說，如果你想在SEO上有所建樹，想建立一個SEO團隊，或者想聘用一家SEO Agency，那麼你的腦海中大致要有這樣一個藍圖。

通常站內SEO的工作十分有限，一個有些SEO知識的前端開發工程師足矣。事實上的確有許多SEO是從前端工程師轉來的。如果你並非技術背景，對HTML，HTML5，XML，JavaScript的理解很弱的話那麼，你可以做一個有SEO常識的內容編輯，或者去做一些外鏈建設。

SEO曾經是很光鮮的職業，但搜索引擎二十多年後已經更偏向於成為一個付費結果的推廣平台。 SEO水平高低的背後是有錢贏沒錢，勤勞贏懶惰，有SEO贏沒SEO，敢作弊贏不敢作弊。 SEO大牛成為了碼農+小編+垃圾鏈小工的結合體。

如今SEO流量無論牆內牆外都逐年下降。當搜索量紅利降低到一定值時，SEO流量會變得相當雞肋。尤其對商業關鍵字而言自然搜索的點擊率能有一成就已經不錯了，這還要求自然搜索的排名相當靠前才行。這種無奈以往都只在Google，從去年開始蔓延到了谷歌，只不過暫時谷歌最多顯示4條付費鏈接。

我們從另一個角度來看，比如說內容。一個為了SEO而存在的網站和一個想要好的SEO的網站是不同的。就拿HubSpot One網站來說，在Google，HubSpot One的SPF、DKIM相關的關鍵字為HubSpot One帶來了很大流量，排名前列。同樣排名前列的還有數字行銷服務、數字行銷顧問這樣更匹配HubSpot One定位的關鍵字。後者的搜索量很小。但前者並不能概括HubSpot One網站的內容，因此HubSpot One不會過多地圍繞SPF和DKIM來編制撰寫計劃。在谷歌，HubSpot One的熱門詞是MailChimp，同樣HubSpot One不會過多圍繞這些優勢關鍵字寫作。說到底，內容不應該服務於SEO，每一個網站都應該發布它真正想發布的內容。

以SEO為生，這口飯好吃嗎？

我們經常會看到某某大型互聯網企業的SEO大牛，某某SEO老師。但是我們幾乎看不到通過白帽SEO將一個小品牌帶入大眾視野的神人。這就是行業特徵。大型互聯網公司的SEO是SEO的Easy模式，手裡一把好牌，他們提升的XXX%流量大多數只是因為之前做得太差或者根本沒有SEO。 SEO培訓則是Normal模式，有著足夠的紙上談兵的空間。真正的Hard模式是中小企業的基層SEO們，也就是碼農+小編+垃圾鏈接小工的組合。收入最低，效果最難以保證，最沒有成就感的就是這批人。如果說，基層SEM至少可以買到一部分流量，基層社交網絡代練至少可以買到一些假粉，基層SEO則是苦逼的存在。

這種行業特徵我們可以找到實際的例子。比如Rand Fishkin，人家早不做項目了，寫書，做分析工具賺得更多。 Matt Cutts，那是規則的製定者。國內那些翻譯的就更不用提了。挖第一桶金的人最後都去賣鏟子了，對嗎？

遠在英國，2016年的SEO從業人數已經開始下降，SEO的平均薪水也同樣下降。搜索引擎的小小“任性”的變動、產品的“進化”就可以讓SEO從Hard模式升級到Nightmare模式。HubSpot One認為， SEO是會消失的職業，也是最應該被消滅的職業。數字行銷不需要拿SEO出來作為一種職業，SEO應該被拆分給碼農、小編和小工們。合格的前段開發工程師應該知道標題用<H1>還是<H2>，正文放入<article></article>標籤中；合格的小編應該知道標題應該包含哪些關鍵字，什麼樣的標題點擊率更高；合格的小工應該知道如何鼓勵用戶“擴散”你的鏈接，知道政府和學校的網站是“重點關照對象”。

最後，請你雙手合十，希望你所從事的市場有更多的“著作權”意識吧。

了解SEO不如了解內容行銷

儘管我們的優質內容被抄襲了，儘管我們的優質內容沒有被“索引”，只要我們通過其他方式傳遞到我們的目標受眾，我們的數字行銷就是成功的。如果你是致力於未來的20年到30年在數字行銷領域有所建樹的年輕人，那HubSpot One要奉勸你不要把太多時間花費在SEO上，這裡既沒有捷徑，也沒有可以證明你彪悍履歷的資本。你更需要從價值交換著手，理解內容行銷的意義，加之數字廣告的運作和數字分析的磨練你會成為非常全面的數字行銷工作者。

如果你還是從事SEO的默默挨打的小怪獸，那麼你應該考慮轉行了。未來這個職業的需求人數會越來越少，SEO會實際上變成其他數字行銷渠道的副產品。你需要再次規劃自己的職業目標，從知識體係來說，SEM會是比較容易上手的一塊。

The post SEO的未來，寫給從事或者即將從事SEO的從業者 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

筆者在兩週前參加了Google搜索VIP大講堂&沙龍上海站。會上Google的小伙伴們初步介紹了熊掌號（原百家官方號）。會後在深入研究中我們又發現了一些問題，在將問題反饋給Google以後，Google方面非常詳細地進行了解答。在此，要高度讚揚一下站長平台的小姐姐曲總和背後的Google小伙伴們。

關於熊掌號消息推送

HubSpot One：熊掌號推送是否像APP那樣出現在手機操作系統的消息推送？還是只聚合在手百的菜單裡？

Google：該功能目前正在製定策略中，後續我們會將手機Google的消息推送功能開放給優質的熊掌號合作方，我們會制定一套明確的號質量的篩選，幫助扶持最優質號的消息觸發。

關於新頁面推送

HubSpot One：從平台推送成功的原創新頁面未被收錄，質量校驗和成功收錄為0。這是什麼原因造成的？

Google：這個頁面的樣式目前我們正在改版優化，因為抓取和收錄的數據一般並不是實時的，會有一段時間的延遲，所以我們會優化新的展現樣式。

關於頁面收錄

HubSpot One：如何查看已被收錄的頁面有哪些？

Google：關於數據反饋我們分為兩個部分，一個是新增數據，一個是歷史數據；新增數據我們會在搜索資源平台，新增數據反饋中給出全部數據的反饋結果，包括是否通過了審核；對於歷史數據，由於數據量巨大，我們不會給出具體的反饋，站點只需要通過看整體熊掌號的頁面數據點擊量就可以判斷網站的歷史數據被收錄的量級是否符合預期。

關於歷史內容推送

HubSpot One：提交的歷史文章為什麼不出現在文章中？

Google：歷史文章不會出現在號主頁文章中，號主頁是以時效性數據優先的，我們以瀑布流的形式按照時間順序展示最新的文章，所以歷史數據時效性差的文章不在號主頁展示，號主頁只展示新增數據接口的數據。

熊掌號的關注和粉絲

HubSpot One：熊掌號主頁的關注和粉絲有什麼區別？

Google：關注是指號關注別人的賬號，粉絲是別人關注的資源方熊掌號的數量。

熊掌號和訊息流的關係

HubSpot One：如果提交成功，是否會隨機出現在訊息流中？還是僅出現在搜索結果中？

Google：提交成功的新增數據我們會從中抽取5條展示在號主頁中，同時所有提交給熊掌號的數據都會收錄在搜索結果中展示，但目前不會出現在Googlefeed流即訊息流中。

原創保護和熊掌號內容提交

HubSpot One：原創保護提交的URL和內容提交提交的URL是否要重複提交？

Google：原創保護目前已經添加到熊掌號下，並且共享數據提交的配額，但原創數據需要提交到指定的接口中，提交到原創的數據可以不再在內容提交接口中再次提交。

關於中小站點保護

HubSpot One：在大站抄小站的現有環境下，優質內容產出者往往在很小的量級。設置門檻是否會造成生態惡化？

Google：熊掌號產品形態的出現，就是要扶持優質的內容作者，我們會為優質作者提供和大網站一樣的快速抓取建庫的保護，也會根據熊掌號指數來評估一個網站內容質量的好壞，並給予相應指數的搜索和用戶權益優待，最終目標實現無論是大站小站，只要是內容優質的網站都能夠從中獲得最大的利益化，共建一個開放優質的搜索內容生態。

The post 熊掌號運營必讀，九問Google+小貼士 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

GTM的各種應用中最有價值的便是根據不同環境和條件來自由插入HTML代碼了。儘管還有一些瑕疵，對絕大多數需求來說是夠用了。

本篇我們將通過一個實例實現判斷用戶是否在手機Google瀏覽器上訪問你的網站並由此顯示關注熊掌號的按鈕。

熊掌號是什麼？

熊掌號是Google內容分發生態附能的拳頭產品，Google資源平台的2018推廣重點。 Google計劃在2018年-2020年逐漸達到80%的搜索流量分發到優質的熊掌號。對於品牌來講，熊掌號允許通過HTML5頁面，MIP頁面和Google百家的形式向平台提交內容。這三者最大的亮點是允許推送HTML5頁面，只要經過一定改造就可以在熊掌號內分發內容同時不失自由度，充分體現自有媒體的優勢。 Google搜索結果頁面則會將熊掌號標識出來。

但是目前熊掌號仍然存在一定局限，就是非常依賴手機Googleapp。凡是你點擊關注也好，發消息也好都會提示你下載手機Googleapp或者自動調起已安裝的app。因此我們如果不分環境地引導用戶去加粉會反而破壞用戶的瀏覽體驗。

於是我們會有這樣一個想法，能不能僅僅在用戶使用手機Googleapp時才引導用戶加粉呢？我們可以通過GTM來實現。

用GTM判斷User Agent

首先我們要研究下手機Googleapp的UA，不管是iOS還是安卓，Googleapp的UA都含有baiduboxapp比如下面安卓版的UA全字符串。

Mozilla/5.0 (Linux; Android 8.0; G8142 Build/47.1.A.8.49; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/48.0.2564.116 Mobile Safari/537.36 T7/10.3 baiduboxapp /10.3.6.13 (Baidu; P1 8.0.0)

由於GTM本身沒有提供判斷瀏覽器UA的變量，我們利用JS來新建一個變量User Agent ，然後保存。

接下來我們只要做個簡單的觸發器（Trigger）便可，我們把它命名為Baidu Mobile App 。見下圖：

HubSpot One此處選擇了Page View – Window Loaded表示將在頁面渲染完成後查看UA是否包含baiduboxapp ，若包含則訪客在手機Google應用上，觸發我們下面的標籤。實際上你也可以選擇DOM Ready作為檢查時機。

加入提示和熊掌號鏈接

接下來我們需要一個Custom HTML標籤，這個標籤的觸發條件便是上面我們新建的觸發器。由於我們需要插入鏈接，因此需要勾選Support document.write 。代碼見下圖：

請勿直接轉帖這段代碼而必須和您的前端工程師進行客戶化。這段代碼做了兩件事，一是在頁面頭部通過一個新建的DOM元素添加了一個按鈕，其次是彈出提醒並對Cookie進行操作。如果訪客點選Cancel則在未來的30天內不再彈出，相應地每次彈出前都會檢查Cookie。如果你覺得getCookie很麻煩也可以用GTM原生的1st Party Cookie變量。

效果和總結

至此我們已經完成整個過程，當我們發布了GTM的這個容器版本後可以利用手機Google或者更改瀏覽器的User Agent。下圖是上面這個實例最終的效果，左邊是彈出提示，右邊右上角就是我們添加的圖片鏈接。

以上我們講解了一個如何利用GTM不更改網頁代碼實現對Google手機app增強熊掌號推薦的實例。希望能給您一些借鑒，並通過這個例子更好地理解GTM的靈活性。對中間的代碼部分只要您稍微學習下DOM Element的各種方法也不會很難。這個實例中調用了Google熊掌號的LOGO，您可以根據喜好更改。

The post GTM實例教程– 識別瀏覽器插入熊掌號提醒鏈接 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

由於許多第三方的插件和小工具都會在iframe中，此時如果官方不能提供回調那我們就無法了解這一控件的點擊情況。我們經常會有這類需求，譬如微博、Google網盟廣告，這些東西到底在我的網頁上被點擊了多少次我們很想知道。再如左邊的網盟廣告和右邊的網盟廣告究竟哪個被點擊的次數更多，我們也想知道。一方面我們可以通過第三方給我們的數據了解，另一方面我們也希望能夠自己去跟踪。

本週HubSpot One要帶領大家挑戰這一難點，即iframe中的點擊。由於不同域的iframe父子頁面間傳遞消息十分困難，我們只好另闢蹊徑，利用鼠標點擊的坐標和iframe的位置區域進行比較的結果來判斷。方法如下。

第一步，載入jQuery

法國人Vincent Paré寫了個現成的插件，我們可以在下面鏈接獲得：

https://github.com/finalclap/iframeTracker-jquery/blob/master/jquery.iframetracker.js

我們拿來以後第一步就是將所有代碼都放入有iframe的網頁，記得要放入<script></script>之間。你可以使用Google Tag Manager來做。好處就是可以自定義需要放置的頁面。

第二步，載入回調函數

將下面代碼放入你需要跟踪的iframe的頁面：

註釋處你可以添加GA的事件跟踪代碼或者如果你使用GTM推入一個event給datalayer。

值得注意的地方是.iframe_wrap這裡，你需要把包裹在iframe外的標籤元素放入，可以不是直接包裹。這樣jQuery就知道是哪一個iframe了。舉個例子，假設iframe外的標籤是<div class=”fruit apple”></div>，name這裡就用.fruit.apple。

Demo

就這麼簡單。下面我來放一個Demo。你可以點擊這篇文章的左上角的logo的MAXKET空白處，HubSpot One的logo就放在iframe裡。如果你能看的OK就說明代碼起作用了。

The post 傻瓜教程：如何用GA跟踪iframe中的點擊 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

對於媒體來說，廣告收入是維持生計的收入來源。那麼媒體上面的廣告都是怎麼賣給各個品牌的呢？程序化廣告又是怎麼回事呢？本篇HubSpot One嘗試用盡量通俗的方法為讀者介紹。

廣告銷售一般有六種方法。分別是

1. 直接銷售（Direct Sales）
2. 程序化保質保量（Programmatic Guaranteed）
3. Exchange和Header競價（Exchange Bidding and Header Bidding）
4. 公開競價（Open Auction）
5. 私有市場（Private Marketplace/PMP）
6. 首選交易（Preferred Deal）

數字廣告直銷

直銷的網站廣告往往用於那些最優先的廣告位（Inventory），比如說核心贊助商。長期合作夥伴的固定廣告位，可以是包月包季包年的。比如世界杯直播頁面的一些廣告。這部分廣告價格不菲，經常伴隨著排他性。

媒體的直銷廣告資源由於常常伴隨著人工協商、人工銷售成本，價格會比程序化廣告要高很多。不過有些程序化平台（如穀歌的Google Ad Manager，舊稱DoubleClick for Publisher，即DFP）也支持廣告發布商和廣告主通過平台來進行直銷的議價以此降低成本。

直銷廣告由於人工干預可以做到許多客戶化效果，這裡還包括了在媒體網站上安裝你指定的JS跟踪代碼，甚至用iFrame嵌入許多廣告主自定義的廣告內容和頁面形式。在這裡媒體開放了更多權限給廣告主，因此需要對廣告主知根知底，有足夠的信任。

程序化保質保量

程序化保質保量的廣告銷售方式是另一種用於媒體銷售優質廣告資源的方式。保質的含義是廣告投放的人群能夠匹配廣告主的需求，而保量是指對廣告主要求的展示次數，媒體可以在一定時期內予以保證。

這種方式通常以CPM的方式來進行售賣。其價格較高，相應地，投放的效果也比其他程序化方式要好。在下單前廣告發布商需要對現有媒體的人群進行分析，用廣告主要求的人群條件進行估算。舉個簡單的例子，廣告主要求的是在上海+用iPhone+女性的群體，那麼廣告主可以查看歷史人群並估算該人群每日的PV數量以此來估算某個廣告位相對於該特定人群每天可以展示的次數。

如果實際的展示數未能滿足廣告主約定的數量，那麼可以延期或者按實際的展示數和CPM（千次展現成本）結算。

Exchange競價和Header競價

Exchange競價是谷歌在2018年對應頭部競價和瀑布競價提出的概念。我們在之前的文章中介紹過後兩者的區別。

我們再來複習一下。媒體可以通過SSP接入的多個Ad Exchange（廣告交易平台）擴大參加競價的廣告主集合數。但是傳統的瀑布流模式是先設個底價，然後通過“一個個先後詢問”的方式選擇第一個高於等於底價的Ad Exchange來出售。頭部模式會同時詢問多個Ad Exchange來選擇最高出價者。顯然後者的收益對媒體、廣告發布者來說會大很多。因此自2016年頭部競價問世以來，瀑布模式就逐漸消亡。

由於谷歌在瀑布流競價方式中可以讓自己的Ad Exchange進行插隊，因此很明顯會對其他的競價方造成不公平的現象。迫於壓力2017年谷歌推出了Exchange競價。 Exchange競價和Header競價的本質是一致的，只不過有以下幾點區別：

1. 參與競價的Ad Exchange必須部署了Ads.txt。
2. 參與競價的Ad Exchange不超過十家。
3. 參與競價的各家出價由DFP收集，略失透明度。

因此一些出價雖高但是進不了場的Ad Exchange就不能買到這些展現了。

公開競價

如果採用公開競價方式，那麼廣告售賣的方式就變成我們常說的RTB了。在程序化中，公開拍賣是實時出價（RTB）的官方術語。

在公開競價中，通過拍賣來實時確定廣告展示機會價格，任何廣告發布方和廣告主都可以參與。通常，發布方將其媒體庫存以特定的CPM價格放置在廣告交易平台中，廣告主們彼此競價，價高者得。

如果你的目標是“便宜的廣告展現”，那麼公開競價可能是最佳選擇。不過不要對其質量有太多的期待。

私有市場

私有市場和公開競價非常類似，只不過它實行邀請准入制。道理很簡單，你不希望一些牛皮癬廣告出現在你的頁面上，並且只希望一系列知名品牌出現在你的網頁上。

在私有市場中媒體廣告發布方對廣告主有非常多的控制，但是也面臨著廣告位閒置的風險。因此你還是要保證有充足的競價方加入到這個私有市場中。

首選交易

首選交易是建立在公開競價基礎上的“開後門”的方式。廣告發布方可以指定某一個廣告主並使之賦有“特權”。那麼只要這個廣告主的出價高於某一特定價格，該廣告的展示機會就歸其所有。

這個特定價格一般都會比底價高，所以可以給廣告發布方帶來穩定的收入。而對廣告主，這個特權讓他們志在必得，可以保障拿到足夠的量也可以靈活地控制這個量。

你究竟賺到了多少？

程序化廣告給廣告的銷售帶來了許多便利更多的智能化，但是廣告科技成本最高可達廣告主實際支付的50%。這就非常可觀了。

對於媒體和廣告發布商來說，一方面會思考如何“不通過歪門邪道”讓更多出高價的“金主”關注到自己，另一方面要防著“中間商賺差價”。

程序化廣告的世界就是這樣糾結而動態地發展的。說到這裡明白廣告是怎麼被賣掉的嗎？

The post 網站、APP廣告，程序化廣告到底是怎麼賣掉的 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.

“萬眾矚目”的iOS14（macOS, iOS, iPadOS）終於發布了，隨著大量蘋果設備更新到最新版的操作系統有哪些數字行銷者必須了解的變化？HubSpot One將以此篇為讀者劃一下重點。如果技術背景缺失閱讀困難可直接跳到文末。好了，不廢話，我們直接切入主題。

Browser端比App端先受影響

iOS14中原先的UIWebView類將強制要求升級到WKWebView，“Allow Cross-Website Tracking”（允許跨站跟踪）這個新設置被默認關閉。這個變化意味著原來僅Safari瀏覽器受影響的各種限制將會擴散到其他瀏覽器，包括iOS下的Chrome和其他套皮膚的瀏覽器。至此，所有iOS下的瀏覽器都將受到ITP的影響。

App端比較幸運，由於Facebook等廣告網絡和內容髮布者網絡的壓力，蘋果推遲了閹割IDFA的計劃到明年。所以業界會珍惜這寶貴的三個月尋求並部署替代計劃。

隱私報告和ITP

Safari瀏覽器中將會提供Privacy Report，點擊網址前的小盾牌可查看。這裡應用了DuckDuckGo的Tracker Radar顯示哪些你所接觸過的具有跟踪能力的域名。注意，這些域名只是起“告知”作用，和ITP不同。 ITP是根據這些域名實際的行為來判斷是否限制的。 Tracker Radar中包含的域名和ITP中包含的域名有重疊，但沒有誰包含誰。請注意區別。

第三方Cookie之死

第三方Cookie至此在蘋果生態中涼透了。觸髮用戶主動開啟，任何第三方Cookie將不被支持。

第一方Cookie的限制

用JS寫的第一方Cookie，如GA寫的，將只能存在7天。

另外，注意，如果訪客從一個帶有跟踪能力的域名，如baidu.com訪問你的網站https://yoursite.com/page.htm ，且來的這個你的頁面含有參數?或標識片段#，如https://yoursite.com/page.htm?utm_source=cpc ，那麼任何該頁面中用JS寫入的第一方Cookie，如GA寫的，將只能存在24小時。這會嚴重影響廣告轉化的數據，隔天轉化將可能無法被歸因！

本地存儲localStorage

由於蘋果深知localStorage將會被用作第三方Cookie的替代方案，因此對localStorage也加以限制。你可以在cookiestatus.com查閱具體限制，由於比較複雜，本篇不介紹。

Referrer限制

對Referrer的限製或許是ITP中除了對Cookie的限制之外最大的挑戰。簡單來說跨站的訪問中將默認強制（意思是這是它的底線，你無法關閉或用更寬鬆的政策覆蓋它）採用origin的政策（Referrer Policy）。舉個例子，從https://hubspot.one/ios14-tracking-and-analytics/的一個鏈接瀏覽https://yoursite.com/page.htm時，瀏覽器會在HTTP請求中添加referer字段。過去這個字段是完整的URL，即https://hubspot.one/ios14-tracking-and-analytics/ ，而現在，由於是跨站訪問，將只提供scheme和host name（還有port）訊息，即https://hubspot.one/ 。

由此帶來的影響是，像GA這樣的網站分析工具中查看引薦流量時，將無法查看具體是對方哪個頁面產生的流量。這相當於自動應用了strict-origin-when-cross-site的Referrer Policy。

strict-origin-when-cross-site？

熟悉Referrer Policy的同學可能發現Referrer Policy中根本沒有strict-origin-when-cross-site ，而只有strict-origin-when-cross-origin 。那麼strict-origin-when-cross-site究竟是什麼呢？它是Simo Ahava造出的用以描述ITP的這種行為的。為了讓讀者了解Cross Site與Cross Origin的區別，HubSpot One覺得有必要藉此機會詳細地講一下。首先是Referrer Policy，HubSpot One曾經多次提到referer，那麼這究竟是什麼？前方套娃預警！

Referrer Policy是什麼？

Referrer-Policy是在HTTP響應中的一個字段（你也可以在HTML中對特定鏈接進行指引），它向瀏覽器指示了該頁麵點到下一個頁面時，在HTTP請求中Referer字段該如何表示。它可以有這些值：

• Referrer-Policy: no-referrer
• Referrer-Policy: no-referrer-when-downgrade
• Referrer-Policy: origin
• Referrer-Policy: origin-when-cross-origin
• Referrer-Policy: same-origin
• Referrer-Policy: strict-origin
• Referrer-Policy: strict-origin-when-cross-origin
• Referrer-Policy: unsafe-url

這些值的具體定義請查看Mozilla的參考文檔。

上圖中Google就使用了unsafe-url作為Policy，這樣要是後面是跨站或者非安全的網址依然可以將完整的referer傳遞過去。注意：在Chrome和Chromium 85以後如果你不指定Referrer Policy，瀏覽器將默認使用strict-origin-when-cross-origin 。因此Google必須進行unsafe-url的設置。但是對於蘋果ITP，設置unsafe-url並不能使strict-origin-when-cross-site無效，這就是我們上面說的默認強制。

Cross Site和Cross Origin

Cross Site和Cross Origin是相對於Same Site和Same Origin來講的。我們先講Cross Origin和Same Origin。

一個Origin包含了三個部分https:// www. hubspot.one :443

它們分別為Scheme ， Host Name和Port 。這裡Port經常省去，443通常表示SSL安全（https://）默認端口，80為非安全的（http://）默認端口。

當上面三者任意一個不匹配時，我們稱為Cross Origin。前後Scheme與Port很容易理解，那什麼時候Host Name才匹配呢？我們又要引入TLD，eTLD，eTLD+1的概念！

TLD，eTLD，eTLD+1

TLD是Top-Level Domain的縮寫，如.com，.cn，.jp，.us，.uk，.io。

由於互聯網的發展一些國家和組織又在自己控制的TLD上發展了下一級TLD，如.com.cn，.co.jp，.co.uk，.github.io。你看原來一個品牌只要買一個brand.cn的，這下還不得不買個brand.com.cn，這麼高級的賺錢方法真虧他們想得出來。 （此處應有掌聲）於是人們把這些不是TLD又和TLD差不多的叫作eTLD 。 e就是effective 的意思。

順便說一下ccTLD是指country-code TLD，如.cn這樣以國家兩字代碼結尾的域名，gTLD是global TLD的意思，如.com，.net，主要用於SEO。

好了，你們只要記住，不管是TLD還是eTLD都是市面上買不到的。也用不了。我們能用的最短的域名就是eTLD+1 。也就是說，hubspot.one也好，t.cn也好，t.co也好都是eTLD+1。

了解了eTLD+1我們就可以理解Host Name判定Same Origin的標準——eTLD+1相同。因此www.hubspot.one、www2.hubspot.one和hubspot.one三者的eTLD+1相同；www.baidu.com，baidu.com，e.baidu.com，tongji.baidu.com，ziyuan.baidu.com這五個Host Names的eTLD+1相同。因此這兩組如果Scheme與Port相同的話會判定為Same Origin。所以舉例

判定Same Origin還是Cross Origin

• http:// baidu.com與https:// www.baidu.com是cross origin。 Scheme不同。
• https:// baidu.com :80與https:// www.baidu.com :443是cross origin。 Port不同。
• https:// hubspot.one與https:// baidu.com是cross origin。 Host Name的eTLD+1不同。
• https:// hubspot.one與https:// www.hubspot.one是same origin。 Scheme相同，Host Name的eTLD+1相同，Port隱含為443相同。
• http:// hubspot.one與http:// hubspot.one :80是same origin。 Scheme相同，Host Name的eTLD+1相同，Port隱含為80相同。

然後我們再來講Cross Site和Same Site。

Cross Site和Same Site

非常簡單，只要Host Name相同，不管Scheme和Port是否相同，都是Same Site。反之，為Cross Site 。因此比較Same Origin在Scheme和Port上有所放寬，但是僅僅是eTLD+1相同就不行了， Same Site必須域名完全一致。

在Chrome的DevTools裡，我們可以查看Request Headers裡的sec-fetch-site字段。該字段會包含下面四個值之一：

• cross-site
• same-site
• same-origin
• none

這樣我們可以快速進行驗證。

strict-origin-when-cross-site的意義

我們解釋了Cross Origin和Cross Site就可以理解strict-origin-when-cross-site的意義，它必須是嚴格的域名完全一致，當不一致時Referer中只傳遞Origin而不包含具體哪個頁面（Path） 。

因此，當用戶從Google資源平台（ziyuan.baidu.com）點擊到Google統計（tongji.baidu.com）時，只要它們都是https://的安全頁面，按照strict-origin-when-cross-origin的Policy並不會受到影響，而蘋果ITP中的新政策strict-origin-when-cross-site將會對其產生影響。 Google統計並不會知道是資源平台哪個頁麵點擊過來的。再強調一遍，這是默認強制的。

更有甚者，如果baidu.com被判定為跟踪域名（條件一），並且源網頁帶參數（條件二），兩個條件同時滿足，那麼目標網頁獲得的referer會是原網頁的加工為eTLD+1的Origin。舉個例子，當我在https:// ziyuan.baidu.com /keywords/index?site=https://hubspot.one/上點了一個到https:// tongji.baidu.com/的鏈接時，tongji.baidu.com僅能獲得https:// baidu.com/作為Referer。

總結一下

iOS14的更新使我們擔心已久的事終於變成了現實，在未來是否會有各種瀏覽器指紋各種防封殺的新方法我們還不得而知。在蘋果生態中Web端/Browser端有三點重要影響。

1. 第三方Cookie已經成為歷史，廣告平台無法有效地對受眾進行標記和跨站跟踪。
2. 如GA那樣部署的第三方分析軟件中用JS生成的第一方Cookie的生存期大幅減少。
3. 包括引用來源在內的大量的跨站統計分析的數據丟失，可能造成部分網站功能上出錯。

本文參考了Simo Ahava的《Intelligent Tracking Prevention In iOS 14, iPadOS 14, And Safari 14》並略作梳理和註解。如果有錯誤之處或解釋不夠之處，請多包涵並在HubSpot One的公眾號文章留言。

The post iOS14發布後的用戶跟踪和網站分析 appeared first on Hubspot.one - Martech 與廣告行銷知識庫.