我收到一些反饋，上次的解決方案可能並不適合，特別是如果本身已經有在使用了campaign_id。雖然這的確是個問題，但今天我要介紹一個更全面的解決方案，一次性解決ga_session_id的挑戰。

簡單來說，利用SQL，將ga_sesison_id拆分到事件級別。簡單如此。

建立Google Analytics和Google雲端數據管道

配置Google Cloud Function (函式) 以執行SQL

步驟1：導航至GCP Cloud Function (函式)

前往Google雲端平台，導航至 Cloud Function (函式) ，然後點擊“建立函式”。 步驟1

步驟2：創建 Cloud Function (函式)

我的設定如下： 環境：第2代 觸發條件：HTTPS，需要驗證

對於其餘的部分，你可以保留基本設定。建議對你的函式進行身份驗證，否則其他能夠訪問URL的人也可以觸發你的函式。

請記住！複製URL，因為你將在下一節設置排程器時使用它 步驟2

步驟3：編寫你的函式

編寫你自己的函式。或者，複製下面的代碼，將表格地址改為你自己的表格。

from google.cloud import bigquery
from datetime import datetime, timedelta

def create_or_overwrite_table(request): client = bigquery.Client() # Get date two days ago two_days_ago = datetime.now() - timedelta(2) table_name = “events_” + two_days_ago.strftime(‘%Y%m%d’)

# We prepare the SQL
sql = f"""
CREATE OR REPLACE TABLE `YOUR_PROJECT_ID.YOUR_DATASET_ID.{table_name}` AS
SELECT *,
CAST((SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS STRING) AS ga_session_id
FROM `YOUR_PROJECT_ID.YOUR_DATASET_ID.{table_name}`
"""

# We execute the query
job = client.query(sql)  # API request
job.result()  # Waits for the query to finish

return 'Table created or replaced successfully' ![步驟3a](https://billy-kwan.com/assets/images/cloud_etl/cf_step_3a.jpeg)

請記住！更新你的Entry Point

步驟3b

步驟4：更新requirements.txt

更新requirements.txt以確保你的Python代碼可以運行

google-cloud-bigquery
pytz ![步驟4](https://billy-kwan.com/assets/images/cloud_etl/cf_step_4.jpeg)

步驟5：部署

點擊部署並開始！ 再次記住，複製 Cloud Function (函式) URL 步驟5

配置Cloud Scheduler來排程 Cloud Function (函式) 任務

步驟1：導航至Cloud Scheduler

點擊建立工作 步驟1

步驟2：定義排程

對於地區，你可以用基本設定，對於時區，建議遵循你的GA4資源時區。

這裡有個棘手的部分，對於頻率，Cloud Scheduler上使用CRON排程。 如果你對CRON排程不熟悉，沒關係！ 你可以前往 Cronitor 網站，它用一種非常直觀的方式來設置！

對於我的設置，我將它設為00 12 * * *，這表示它將每天下午12點運行 步驟2a

如果你想知道應該設置什麼時間，你可以導航至你的GA4 BigQuery表格。 在你的表格，查看’最後修改’，然後加上三小時作為緩衝。為了安全起見，你甚至可以運行查詢，查看過去90天以獲得更安全的運行緩衝。 目標是確保你的每日表格在我們進行修改之前已創建並完全穩定。 步驟2b

步驟3：授權你的Cloud Scheduler執行

為了完成Cloud Scheduler的設置，你可以按照下面的方式設置其餘部分：

目標類型：HTTP URL：放入你在前一步得到的URL HTTP方法：POST 身份驗證標頭：添加OIDC權仗 服務帳戶：這裡有些棘手，你可以創建自己的服務帳戶，但你需要確保帳戶有足夠的權限來執行 Cloud Function (函式) ，對於我的設置，我使用“預設計算服務帳戶”，其權限類似於擁有者訪問級別。 步驟3

步驟4：保存並運行！

保存工作後，你可以在你的Cloud Scheduler主頁看到已排程的任務，點擊右邊的圖標“強制執行”， 這將立即運行已排程的任務並立即更新你的數據集 步驟4

成果與演示

檢查數據集，如果你按照設置進行操作，恭喜你！你成功獲得了ga_session_id！ 查看你BigQuery上的結構定義，你應該可以看到新增的欄位”ga_session_id” output

重新模擬工作階段計算

現在可以試一下前往GA4 的界面，隨便試抓過去6天的獲客報告 可以看到有10個工作階段 output_ga4ui

試着用SQL查看，得出相同結果 output_sql

結尾與方法論

有其他替代方案嗎？

我們的雲端架構如下：

使用 Cloud Scheduler 觸發工作 –> 執行 Cloud Function (函式) –> 更新 BigQuery 中的表格並覆寫現有的表格。

以下有一些替代方案：

設定 Pub/Sub 主題 –> 讓 BigQuery 審核日誌發布到 Pub/Sub –> 觸發 Cloud Function (函式) –> 更新 BigQuery 中的表格。

這種方法可以監聽 BigQuery 中表格的變化，當每日表格上傳時，可以發送消息觸發雲端功能。優點是我們可以保證每日表格的存在，但是設定和監聽的成本較高。

Cloud Scheduler –> BigQuery 定時工作。

這種方法設定簡單，不需要編寫程式碼。然而，覆寫現有的表格是不被允許的，那你必須創建一個單獨的資料集，這將使存儲成本翻倍。

為什麼選擇 Cloud Function (函式) + Cloud Scheduler？

雖然 Pub/Sub 看起來更可靠，但設置和監聽的成本較高。因為我們知道 GA4 的每日表格相當穩定，設定一個簡單的 Cloud Scheduler 使解決方案更易於管理，更簡單，且更便宜。

需要注意什麼？

假設我們由於以下原因錯過了一天的數據修改：

  1. Google 錯過了每日表格上傳的時間表
  2. Google 系統故障導致整個每日表格遺失
  3. 其他原因導致管道失敗（例如，信用卡達到限額）

想要找出特定日期的問題可能會很困難。然而，你可以去日誌探索器查看Cloud Scheduler是否成功運行，或者確認GA4的每日表格中是否存在 ga_session_id。

在確定哪一天失敗後，點擊 ‘強制運行’ 來手動運行工作，我們應該就可以了！ 你可能需要手動運行你的雲端功能，但簡單的 SQL 和覆寫應該就能完成工作。 不過使用GCP這就是另一篇文章了。

今天就到這裡，希望這個對你們有用！