seo分析師的頭銜，就是尋找大量免費數據來源，并將其整理成有見地的東西。 為什么？ 因為將客戶的建議基于猜想沒有任何價值。 最好將高質量的數據與良好的分析相結合，以幫助我們的客戶更好地了解對他們而言重要的方面。
在本文中，我將告訴您如何開始使用一些免費資源，并說明如何組合獨特的分析方法，這些方法可以為您的博客文章提供有用的見解（如果您是作家，則是代理機構，如果您是SEO，或者您的網站（如果您是自己進行SEO的客戶或所有者）。
我要使用的方案是我要分析一些SEO屬性（例如，反向鏈接，頁面權限等），并查看它們對google排名的影響。 我想回答以下問題：“反向鏈接真的對進入SERP的第1頁有效嗎？”和“我真的需要在前10個結果中獲得哪種頁面權威評分？”為此，我需要結合起來來自許多Google搜索的數據，其中包含我要衡量的具有SEO屬性的每個結果的數據。
讓我們開始并研究如何組合以下任務以實現此目標，這些任務都可以免費設置：
- 使用Google自定義搜索引擎查詢
- 使用免費的某（可以選擇自己喜歡的 中國或者美國的都可以） API帳戶
- 使用php和MySQL收集數據
- 使用SQL和R分析數據
使用Google自定義搜索引擎查詢
我們首先需要查詢Google并存儲一些結果。 為了保持Google服務條款的正確性，我們不會直接抓取Google.com，而是會使用Google的“自定義搜索”功能。 Google的自定義搜索主要旨在讓網站所有者在其網站上提供類似Google的搜索小部件。 但是，還有一個免費的基于REST的Google搜索API ，可讓您查詢Google并以流行的JSON格式檢索結果。 有配額限制，但是可以配置和擴展配額限制 ，以提供可使用的良好數據樣本。
在正確配置為搜索整個網絡后，您可以將查詢發送到自定義搜索引擎（在我們的示例中是使用PHP），并將其視為Google響應，盡管有一些注意事項。 使用自定義搜索引擎的主要限制是：（i）它不使用某些Google Web搜索功能（例如個性化結果），并且； （ii）如果您包含十個以上的網站，則可能包含Google索引的一部分結果。
盡管有這些限制，但仍有許多搜索選項可以傳遞給自定義搜索引擎，以代理您可能期望Google.com返回的內容。 在我們的場景中，我們在撥打電話時傳遞了以下內容：
https://www.google.com/customsearch/v1?key=<google_api_id>&userIp= <ip_address>＆cx <custom_search_engine_id>＆q = iphone + X＆cr = countryUS＆start = 1 </ custom_search_engine_id> </ ip_address> </ google_api_id>
哪里：
- https://www.google.com/cn/customsearch/v1 –是Google自定義搜索API的網址
- key = <GOOGLE_API_ID> –您的Google Developer API密鑰
- userIp = <IP_ADDRESS> –計算機的IP地址
- cx = <CUSTOM_SEARCH_ENGINE_ID> –您的Google自定義搜索引擎 ID
- q = iPhone + X – Google查詢字符串（“ +”代替“”）
- cr = countryUS –國家/地區限制（來自Goolge的“ 國家/地區名稱”列表）
- start = 1 –返回的第一個結果的索引-例如SERP頁面1。連續調用將使其遞增以得到頁面2–5。
谷歌曾說過谷歌自定義搜索引擎與谷歌.com有所不同 ，但是在有限的產品測試中，我比較了兩者之間的結果，這讓我感到鼓舞，因此繼續進行分析。 也就是說，請記住，以下數據和結果來自Google自定義搜索（使用“整個網絡”查詢），而不是Google.com。
使用免費的某 API帳戶
應用程序編程接口 （API）。 要使用它，您需要注冊一個 API密鑰 ，該密鑰是免費的，但有限制，每十秒鐘一次查詢 。 具有免費的帳戶和API密鑰，然后您可以查詢Links API并分析以下指標 ：
在調用Links API之前，將xxx API代碼添加在一起，如下所示：
www.Apple.com％2F？Cols = 103616137253＆AccessID = xxx_ACCESS_ID＆ 過期= 1560586149＆Signature = <xxx_SECRET_KEY>
結果：
- http://lsapi.xxxx.com/linkscape/url-metrics/“ class =” redactor-autoparser-object“> http：//lsapi.sxxxx.com/linksc ... – API的URL
- http％3A％2F％2F www.apple.com.tw％2F –我們要獲取數據的編碼URL
- Cols = 103616137253 –上表中的Moz API代碼總和
- AccessID = xxx_ACCESS_ID – 訪問ID的編碼版本（可在您的API帳戶中找到）
- Expires = 1560586149 –查詢超時-設置為未來幾分鐘
- Signature= <xxx_SECRET_KEY> – 訪問ID的編碼版本（在您的API帳戶中找到）
將返回類似以下JSON的內容：
數組 （ [ut] =>apple [uu] => <a href="http://www.apple.com/" class="redactor-autoparser-object"> www.apple.com/ </a> [ueid] => 13078035 [uid] => 14632963 [uu] => www.apple.com/ [ueid] => 13078035 [uid] => 14632963 [umrp] => 9 [umrr] => 0.8999999762 [fmrp] => 2.602215052 [fmrr] => 0.2602215111 [us] => 200 [upa] => 90 [pda] => 100 ）
有關使用PHPPerl，Python，Ruby和JAVAscript查詢數據的一個很好的起點，請參閱Github上的此存儲庫 。 我選擇使用PHP。
使用PHP和MySQL收集數據
現在我們有了Google自定義搜索引擎和某 API，幾乎可以捕獲數據了。 Google和某工具通過JSON格式響應請求，因此許多流行的編程語言都可以查詢。 除了我選擇的語言PHP外，我還將Google和xxx的結果都寫到了數據庫中，并為此選擇了MySQL Community Edition 。 也可以使用其他數據庫，例如Postgres，Oracle，Microsoft SQL Server等。這樣做可以使用SQL（結構化查詢語言）以及其他語言（例如R）進行數據的持久性和即席分析。后來）。 創建用于保存Google搜索結果的數據庫表（帶有用于排名，URL等的字段）和用于保存xxx數據字段（ueid，upa，uda等）的表之后，我們就可以設計數據收集計劃了。
Google使用自定義搜索引擎提供了足夠的配額 （每天使用相同的Google開發者控制臺密鑰進行多達1億次查詢），但是某些工具免費API的有上限，如果需要高級的就要購買了。根據計劃和方案的不同，當我只是在探索免費選項時，我設計了代碼，以在2頁的SERP（每頁10個結果）中收集125個Google查詢，使我能夠保持在2500行的配額之內。 至于哪些搜索可以觸發Google，有很多資源可供使用。 我選擇使用Mondovo，因為它們提供了許多類別的列表，每個列表最多500個單詞，對于實驗來說足夠了。
我還引入了一些PHP幫助程序類以及我自己的數據庫I / O和HTTP代碼。
總之，使用的主要PHP構建塊和源是：
- Google自定義搜索引擎– Ash Kiswany使用Jacob Fogg的 PHP界面編寫了Google自定義搜索的出色文章；
- Mozscape API –如前所述，該用于在Github上訪問Moz的PHP實現是一個很好的起點。
- 網站搜尋器和HTTP –在Purple Toolz ，我們有自己的搜尋器PurpleCerzBot ，它使用Curl作為HTTP和此簡單html DOM解析器 ；
- 數據庫I / O – PHP對MySQL具有出色的支持，我將這些教程打包為類。
要知道的一個因素是 API調用之間的10秒間隔 。 這是為了防止免費API用戶過載。
使用SQL和R分析數據
現在該看看我們所擁有的。 有時這稱為數據爭用 。 我使用一種稱為R的免費統計編程語言以及一種稱為R Studio的開發環境（編輯器）。
R因為它是開源的，并且它具有許多第三方庫，這使其非常通用并且適合此類工作。
現在，我有幾個數據庫表，其中包含我在SERPS的2頁上的125個搜索詞查詢的結果（即，每個搜索詞有20個排名的URL）。 兩個數據庫表保存Google結果，另一個表保存Moz數據結果。 要訪問這些數據庫，我們需要做一個數據庫INNER JOIN，我們可以通過將RMySQL軟件包與R一起使用來輕松完成數據庫。這是通過在R的控制臺中鍵入“ install.packages（'RMySQL'）”來完成的，其中包括“庫（RMySQL）”位于我們R腳本頂部。
然后，我們可以執行以下操作來連接并將數據獲取到名為“ theResults”的R數據幀變量中。
library(RMySQL)
# INNER JOIN the two tables
theQuery <- "
SELECT A.*, B.*, C.*
FROM
(
SELECT
cseq_search_id
FROM cse_query
) A -- Custom Search Query
INNER JOIN
(
SELECT
cser_cseq_id,
cser_rank,
cser_url
FROM cse_results
) B -- Custom Search Results
ON A.cseq_search_id = B.cser_cseq_id
INNER JOIN
(
SELECT *
FROM moz
) C -- Moz Data Fields
ON B.cser_url = C.moz_url
;
"
# [1] Connect to the database
# Replace USER_NAME with your database username
# Replace PASSword with your database password
# Replace MY_DB with your database name
theConn <- dbConnect(dbDriver("MySQL"), user = "USER_NAME", password = "PASSWORD", dbname = "MY_DB")
# [2] Query the database and hold the results
theResults <- dbGetQuery(theConn, theQuery)
# [3] Disconnect from the database
dbDisconnect(theConn)
NOTE:注意：我有兩個表來保存Google自定義搜索引擎數據。 一種保存Google查詢中的數據（cse_query），另一種保存結果（cse_results）。
現在我們可以使用R的全部統計功能開始爭吵。
讓我們從一些總結開始，以便對數據有所了解。 我經歷的過程在每個字段中基本上都是相同的，因此讓我們說明并使用Moz的“ UEID”字段（指向URL的外部所有者鏈接的數量）。 通過在RI中鍵入以下內容，可以得到以下內容：
> summary(theResults$moz_ueid) Min. 1st Qu. Median Mean 3rd Qu. Max. 0 1 20 14709 182 2755274 > quantile(theResults$moz_ueid, probs = c(1, 5, 10, 25, 50, 75, 80, 90, 95, 99, 100)/100) 1% 5% 10% 25% 50% 75% 80% 90% 95% 99% 100% 0.0 0.0 0.0 1.0 20.0 182.0 337.2 1715.2 7873.4 412283.4 2755274.0
觀察這一點，您會發現數據由于中位數與均值的關系而偏斜（很大），而中位數與均值之間的關系被較高四分位數范圍內的值（超過觀測值的75％的值）拉動。 但是，我們可以將其繪制成R中的箱形圖，其中每個X值都是從Google自定義搜索位置1-20開始按等級排列的UEID分布。
請注意，我們在y軸上使用了對數刻度，以便我們可以顯示變化范圍很大的所有值！
由Google排名得出的 UEID R中的箱須圖（注：對數刻度）
箱形圖和晶須圖很棒，因為它們在其中顯示了大量信息（請參見R中的geom_boxplot函數）。 紫色方框區域表示四分位間距（IQR），它是觀測值的25％到75％之間的值。 每個“方框”中的水平線代表中間值（訂購時中間的那一條），而從方框延伸的線（稱為“晶須”）代表1.5x IQR。 晶須外的點稱為“異常值”，并顯示每個等級的觀察值集的范圍。 盡管有對數刻度，但我們可以看到中值從排名10上升到排名1明顯，表明股權鏈接的數量可能是Google的排名因素。 讓我們用密度圖進一步探索它。
密度圖非常類似于分布（直方圖），但顯示的是平滑線而不是條形圖。 與直方圖非常相似，密度圖的峰值顯示了數據值集中的位置，可以在比較兩個分布時提供幫助。 在下面的密度圖中，我將數據分為兩類：（i）排名1-10的SERP第1頁上顯示的結果為粉紅色；以及 （ii）在SERP第2頁上顯示的結果為藍色。 我還繪制了兩種分布的中位數，以幫助說明Page 1和Page 2之間的結果差異。
從這兩個密度圖得出的結論是，第1頁SERP結果比第2頁結果具有更多的外部股權反向鏈接（UEID）。 您還可以在下面看到這兩個類別的中值，清楚地顯示了第1頁（38）的值遠大于第2頁（11）的值。 因此，我們現在有一些數字可用于反向鏈接的SEO策略。
# Create a factor in R according to which SERP page a result (cser_rank) is on
> theResults$rankBin <- paste("Page", ceiling(theResults$cser_rank / 10))
> theResults$rankBin <- factor(theResults$rankBin)
# Now report the medians by SERP page by calling ‘tapply’
> tapply(theResults$moz_ueid, theResults$rankBin, median)
Page 1 Page 2
38 11
由此，我們可以推斷出股權反向鏈接（UEID）很重要，如果我根據此數據為客戶提供建議，我想說他們應該尋求38個以上基于股權的反向鏈接，以幫助他們進入SERP的第1頁。 當然，這是一個有限的樣本，需要更多的研究，需要考慮更大的樣本和其他排名因素，但是您可以理解。
現在，讓我們研究另一個比UEID范圍更小的度量標準，并查看的UPA度量標準，即頁面在搜索引擎結果中排名良好的可能性。
> summary(theResults$moz_upa) Min. 1st Qu. Median Mean 3rd Qu. Max. 1.00 33.00 41.00 41.22 50.00 81.00 > quantile(theResults$moz_upa, probs = c(1, 5, 10, 25, 50, 75, 80, 90, 95, 99, 100)/100) 1% 5% 10% 25% 50% 75% 80% 90% 95% 99% 100% 12 20 25 33 41 50 53 58 62 75 81
UPA是提供給URL的數字，范圍為0-100。 數據的表現比之前的UEID無界變量的均值和中位數靠得很近，表現出更好的“正態”分布，正如我們通過在R中繪制直方圖所見的那樣。
莫茲的UPA得分的直方圖
我們將像以前一樣執行第1頁：第2頁的分裂和密度圖，并在將UPA數據分為兩組時查看UPA分數分布。
# Report the medians by SERP page by calling ‘tapply’ > tapply(theResults$moz_upa, theResults$rankBin, median) Page 1 Page 2 43 39
總之，來自兩個 API變量的兩個分布非常不同。 但是兩者都顯示出SERP頁面之間分數的差異，并且為您提供了切實的價值（中位數），可以與您合作并最終為客戶提供關于您自己的SEO或申請SEO的建議。
當然，這只是一個小樣本，不應從字面上理解。 但是，借助Google和xxx的免費資源，您現在可以看到如何開始開發自己的分析功能，以使假設基于而不是接受規范。 SEO排名因素一直在變化，擁有自己的分析工具來進行自己的測試和實驗將幫助您提高信譽，甚至可能對迄今未知的事物提供獨特的見解。
（文：Jason Morphett | 英國電信（BT）的分析師和數據可視化研究人員）
