構建工具以了解內容性能

已發表: 2020-09-03

內容是推動入站營銷策略的主要力量之一,而搜索引擎優化是實現這一目標的一個組成部分。 通常,這將涵蓋頁面 SEO 的基礎知識:文章結構、關鍵字放置、元標籤、標題標籤、替代文本、標題、結構化數據,以及使用格式在列表和表格中創建非正式結構化數據。

使用 OnCrawl 審核頁面 SEO 作為內容管理的一部分。

當您開始大規模優化或監控時,這屬於技術 SEO 的範疇,無論是通過站點審計還是定期爬網,通過機器生成的自然語言元描述、片段控制標籤或結構化數據注入。

然而,在內容性能方面,技術 SEO 和內容營銷的交叉點更大:我們查看相同的原始數據,例如 SERP 上的頁面排名,或點擊次數、印像數和會話數。 我們可能會實施相同類型的解決方案,或使用相同的工具。

什麼是內容表現?

內容表現是觀眾如何與內容互動的可衡量結果。 如果內容正在推動入站流量,那麼該流量的衡量標準會反映該內容的工作效果如何。 每個內容策略都應基於具體目標定義其特定的 KPI。 大多數將包括以下指標:

  • 內容在搜索中的可見度(SERP 中的展示次數)
  • 相關搜索引擎對內容的看法如何(在 SERP 上排名)
  • 相關搜索者認為內容的搜索列表如何(來自 SERP 的點擊)
  • 有多少人查看內容(分析解決方案中的訪問或會話)
  • 有多少人以促進業務目標的方式與內容交互(轉化跟踪)

到現在為止還挺好。

困難在於放置光標:什麼數字意味著你有好的內容表現? 什麼是正常的? 你怎麼知道什麼時候做得不好?

下面,我將分享我的實驗,以構建一個低技術工具的“概念證明”來幫助回答這些問題。

為什麼需要內容性能標準?

以下是我想回答的一些問題,作為我自己對內容策略的審查的一部分:

  • 就表現而言,內部內容和客座帖子之間是否存在差異?
  • 有沒有我們正在推動的科目表現不佳?
  • 我如何識別“常青”帖子而無需等待三年,看看它們是否仍在吸引每周流量?
  • 我如何識別來自第三方促銷的小幅提升,例如當我們在促銷雷達中發現的新聞通訊中的帖子時,以便立即調整我們自己的促銷策略並利用增加的知名度?

但是,要回答這些問題中的任何一個,您需要知道您正在使用的網站上的“正常”內容性能是什麼樣的。 如果沒有該基線,就不可能定量地說明特定內容或類型的內容是否表現良好(優於基線)。

設置基線的最簡單方法是查看每篇文章發表後每天的平均會話數,其中第 0 天是發表日期。

這將產生一條看起來像這樣的曲線,顯示初始興趣的峰值(如果您沒有將分析限制在僅來自搜索引擎的會話,則可能是您所做的任何促銷的結果),然後是長尾較低的利息:

典型帖子的真實數據:發布日期或發布日期之後不久的峰值,然後是長尾,在許多情況下,最終會帶來比原始峰值更多的會話。

一旦您知道每個帖子的曲線是什麼樣子,您就可以將每條曲線與其他曲線進行比較,並確定什麼是“正常”,什麼不是。

如果您沒有工具來執行此操作,那將是一件令人頭疼的事情。

當我開始這個項目時,我的目標是使用 Google Sheets 來構建概念證明——在承諾學習足夠多的 Python 來改變我檢查內容性能的方式之前。

我們將把這個過程分解成幾個階段和步驟:

  1. 找到你的基線
    - 列出你想學習的內容
    – 了解每天收到的每條內容的會話數
    – 將會話列表中的日期替換為自發布以來的天數
    – 計算“正常”曲線以用作基線
  2. 識別看起來不像基線的內容
  3. 保持最新

找到您的內容性能基準

列出你想學習的內容

首先,您需要建立一個要檢查的內容列表。 對於每條內容,您都需要 URL 和發布日期。

無論您是手動構建還是使用自動化方法,您都可以隨心所欲地獲取此列表。

我使用 Apps 腳本使用 API 直接從 CMS(在本例中為 WordPress)中提取每個內容 URL 及其發布日期,並將結果寫入 Google 表格。 如果您對腳本或 API 不滿意,這仍然相對容易; 您可以在網上找到多個關於如何為 WordPress 執行此操作的示例。

請記住,您需要將此數據與每個帖子的會話數據進行比較,因此您需要確保此表上的“slug”與您的分析解決方案提供的 URL 路徑的格式相匹配。

我發現在上面的 E 列中構建完整的 slug(URL 路徑)比修改從 Google Analytics 中提取的數據更容易。 它的計算量也更少:這個列表中的行更少!

為該站點創建完整 URL 的示例公式:在表格中查找 CMS 提供的類別編號並返回類別名稱,該名稱位於文章 slug 之前,與該站點的 URL 模式匹配 (https://site .com/categoryName/articleSlug/)

如果您無權訪問後端,則可以通過從您的網站本身抓取此信息來創建您的列表,例如,在抓取期間。 然後,您可以導出所需數據的 CSV 文件,並將其導入 Google 表格。

在 OnCrawl 中設置數據字段以從網站的博客中抓取發布日期。

OnCrawl 的數據資源管理器中的數據,包括 URL 和抓取的發布日期,可供導出。

了解每條內容每天獲得的會話次數

接下來,您需要每個內容片段和每天的會話列表。 換句話說,如果一段內容存在 30 天,並且在此期間每天都有訪問量,那麼您希望它有 30 行,以此類推其他內容。

為此,您需要在同一文檔中使用單獨的表格。

谷歌表格的谷歌分析插件使這相對容易。

從包含所需數據的 Google Analytics(分析)視圖中,您可以請求以下報告:

日期指標方面
從 1000 天前
直到昨天。今天的數據還沒有完成,因為這一天還沒有結束。 如果你把它包括在內,它看起來不會像“正常”的完整一天,並且會降低你所有的統計數據。
會話

我們對會話的數量感興趣。

登陸頁面
這會分別列出每個著陸頁的會話。日期
這會分別列出每個日期的會話,而不是給我們一個 1000 天的總數。

在此階段使用您的 Google Analytics(分析)數據片段非常有幫助。 例如,您可以將報告限制為僅包含您有興趣分析的內容 URL 的分段,而不是整個站點。 這顯著減少了生成報告中的行數,並使數據在 Google 表格中的處理更加簡單。

此外,如果您打算僅出於嚴格的 SEO 目的查看有機性能,則您的細分應排除不能歸因於 SEO 工作的獲取渠道:推薦、電子郵件、社交……

不要忘記確保限制足夠高,以免錯誤地截斷數據。

計算發布後的天數

為了計算文章中每個數據點的發布天數,我們必須將會話報告中的數據加入(或者,如果您是 Data Studio 用戶,“混合”)到您的內容列表中的數據.

為此,請使用 URL 或 URL 路徑作為鍵。 這意味著在 CMS 表格和 Google Analytics(分析)報告中,URL 路徑的格式需要相同。

我創建了一個單獨的表格,這樣我就可以在我的分析報告中從登陸頁面中刪除任何參數。 這是我設置列的方式:

  • 登陸頁面
    從 Analytics 報告中的 URL slug 清除參數
    示例公式:

  • 日期
    記錄會話的日期,來自 Analytics 報告
    示例公式:

  • 會話
    記錄會話的日期,來自 Analytics 報告
    示例公式:

  • 發表後的天數
    在我們剛剛創建的 CSM 表的列中查找此 URL 的發布日期,然後從記錄這些會話的日期中減去它。 如果在 CMS 表中找不到 URL,則報告空字符串而不是錯誤。
    示例公式:

請注意,我的查找鍵——完整的 URL 路徑——不是我數據中最左邊的列; 出於 VLOOKUP 的目的,我不得不將 E 列移到 C 列之前。

如果您有太多行無法手動填寫,您可以使用如下腳本複制第一行的內容並填寫接下來的 3450 左右:

 函數 FillDown() {
    var 電子表格 = SpreadsheetApp.getActive();
    電子表格.getRange('F2').activate();
    電子表格.getActiveRange().autoFill(spreadsheet.getRange('F2:F3450), SpreadsheetApp.AutoFillSeries.DEFAULT_SERIES);
};

計算發布後每天的“正常”會話數

為了計算正常會話數,我使用了一個非常簡單的數據透視表,並配以圖表。 為簡單起見,我首先查看了發布後每天的平均會話數。

這是發布後 1000 天內會話的平均值與中位數。 在這裡,我們開始 (?) 了解 Google 表格作為數據可視化項目的局限性:

這是一個 B2B 網站,整個網站的工作日會話高峰; 它每週發表幾次文章,但總是在同一天。 你幾乎可以看到每週的模式。

在這種情況下,出於可視化目的,最好查看滾動的 7 天平均值,但這裡有一個快速版本,自發布以來僅平滑了幾週:

儘管有這種長期觀點,但對於接下來的步驟,我會將圖表限制在發布後 90 天,以便以後保持在 Google 表格的限制範圍內:

尋找異常

既然我們知道了任何一天的平均帖子是什麼樣的,我們就可以將任何帖子與基線進行比較,以確定它是表現出色還是表現不佳。

如果您手動操作,這很快就會“失控”。 除了雙關語,讓我們至少嘗試自動化其中的一些。

每個帖子(不到 90 天)都需要與我們剛剛為 90 天窗口中的每一天建立的基線進行比較。

對於這個概念驗證,我計算了與每日平均值的百分比差異。

為了進行嚴格的分析,您需要查看每天會話的標準偏差,並確定單個內容片段的性能與基線有多少標準偏差。 與平均性能相差三個標準差的會話計數比與當天平均值相差超過 X% 的會話計數更有可能是異常情況。

我使用數據透視表來選擇在此期間至少有一天異常的每條內容(過去 90 天內的會話):

在 Google 表格中,數據透視表不能創建超過 100 列。 因此,此分析的限制為 90 天。

我繪製了這張表。 (理想情況下,我想為每篇文章繪製整個 90 天的曲線,但如果我點擊一條曲線,我也希望工作表能夠做出響應。)

保持最新:自動更新

這裡有三個主要元素:

  1. 基線
  2. 您要跟踪的內容
  3. 這些內容的表現

不幸的是,這些都不是靜態的。

從理論上講,隨著您更好地定位和推廣您的內容,平均性能會不斷變化。 這意味著您需要經常重新計算基線。

如果您的網站有季節性高峰和低谷,則可能值得查看較短時間段或每年同一時期的平均值,而不是像我們在這裡所做的那樣創建合併。

隨著您發布更多內容,您也需要跟踪新內容。

當我們想查看下週的會議日期時,我們不會有它。

換句話說,這個模型需要或多或少地更新。 有多種方法可以自動更新,而不是每次您有興趣查看時都從頭開始重新構建整個工具。

最容易實施的可能是安排每週更新一次分析會話,同時拉出新帖子(及其發布日期)。

我們使用的 Google Analytics(分析)報告可以輕鬆安排為定期自動運行。 缺點是它會覆蓋過去的報告。 如果您不想運行和管理完整報告,可以將其限制在較短的時間段內。

出於我的目的,我發現查看 7 天的窗口可以為我提供足夠的信息來處理,而不會過時。

密切關注 90 天窗口之外的常青帖子

使用我們之前生成的數據,假設可以確定大多數帖子平均每周大約 50 個會話。

因此,無論發布日期如何,關注每週會話超過 50 的任何帖子都是有意義的:

文章按出版時間著色:過去 90 天(藍色)、過去一年(橙色)和舊版(灰色)。 每週總數通過將它們與會話目標 50 進行比較來進行顏色編碼。

分解一周中每天的總會話數可以很容易地快速區分性能相當一致的常綠帖子與性能不均勻的事件驅動活動:

常綠含量(±20/天的持續性能)

可能的外部晉升(短期高峰之外的普遍低績效)

您如何處理這些信息將取決於您的內容策略。 您可能想考慮這些帖子如何轉換您網站上的潛在客戶,或將它們與您的反向鏈接配置文件進行比較。

用於內容分析的 Google 表格的限制

正如您此時可能已經註意到的那樣,Google 表格是用於此類分析的極其強大但有限的工具。 這些限制是我不願與您共享模板的原因:根據您的情況調整它需要大量工作——但您可以獲得的結果仍然只是粗略繪製的近似值。

以下是該模型未能提供的一些要點:

  • 公式太多了。
    如果您有很多(例如,數千個)活動內容 URL,它可能會非常慢。 在我的每週更新腳本中,我會在計算出許多公式後將其替換為它們的值,以便文件在我稍後打開它進行分析時真正響應。
  • 靜態基線。
    隨著我的內容表現的提高,我只是有更多的內容片段“表現出色”。 基線需要每隔幾個月重新計算一次以解釋進化。 使用無監督機器學習模型來計算平均值(甚至跳過此步驟並直接識別異常)很容易解決這個問題。
  • “不准確”的基線。
    基線不考慮季節性變化或站點範圍內的事件。 它對極端事件也非常敏感,特別是如果您將計算限制在較短的時間段內:

統計上不合理的異常值分析。
特別是如果每個內容項每天沒有很多會話,聲稱與平均值相差 10% 就構成了不尋常的表現,這有點粗略。

任意限制為 90 天的分析。
任何任意限制都是一個問題。 在這種情況下,它使我無法理解常青內容的性能,並使我對其性能的任何峰值視而不見——儘管我從谷歌分析知道非常老的文章偶爾會突然引起關注,或者某些文章穩步獲得關注他們老了。 這在工具中是不可見的,但如果您繪製它們的曲線,則它是:

  • 紙張長度問題。
    我的一些公式和腳本需要一系列單元格。 隨著會話報告中的站點和行的增長,這些範圍需要更新。 (但它們不能超過工作表上存在的行數,否則其中一些會產生錯誤。)
  • 無法為每條內容繪製完整曲線。
    來吧,我想看到一切!
  • 與圖形結果的交互性有限。
    如果您曾經嘗試在 Google 表格中的多曲線圖上選擇一個點(或曲線)……您就會知道我在說什麼。 當您在同一張圖上有超過 20 條曲線並且顏色開始看起來都一樣時,情況會更糟。
  • 在沒有會話的情況下忽略表現不佳的內容的可能性。
    使用我在這裡介紹的方法,很難識別始終沒有會話的內容。 因為它從未出現在 Google Analytics(分析)報告中,所以它不會在工作流程的其餘部分(目前)中被提取出來。 持續表現不佳的內容幾乎沒有價值,因此除非您正在尋找要修剪的頁面,否則表現不佳的內容可能不會在性能報告中佔有一席之地。
  • 無法適應實時分析。
    雖然重新運行報告、平均和更新後腳本並不是特別費力,但這些仍然是每週編程更新之外的手動操作。 如果每週更新是在星期三,而你在星期二問我情況如何,我不能只查閱表格。
  • 擴展的限制。
    在此報告中添加分析軸(例如排名或關鍵字跟踪,甚至按地理區域過濾選項)將是繁重的。 它不僅會加劇一些現有問題,而且實現可讀、可操作的可視化也將非常困難。

結論?

在機器學習或編程環境中運行相同類型的計算可以解決幾乎所有這些問題。 這將是對大量數據運行半複雜操作的更好方法。 此外,還有一些優秀的庫使用機器學習來可靠地檢測基於給定數據集的異常情況; 有更好的數據可視化工具。

內容性能要點

內容性能分析,即使使用原始和有缺陷的方法,也會加強內容策略中的警報和數據驅動決策。

具體來說,了解內容性能可以讓您:

  • 了解初始促銷與長尾活動的價值
  • 快速發現表現不佳的帖子
  • 利用外部促銷活動來擴大影響力
  • 輕鬆識別是什麼讓某些帖子如此成功
  • 確定始終優於其他人的某些作者或某些主題
  • 確定 SEO 何時開始對會話產生影響

這些數據推動了明智的決策,以促進內容——以及何時和如何——、主題選擇、受眾分析等。

最後,像這樣的實驗表明,您可以獲得數據的任何領域都可能用於編碼、腳本和機器學習技能。 但是,如果您不具備所有這些技能,則不必放棄製作自己的工具。

開始免費試用