回到文章列表

【數據工程領域】合成數據 (Synthetic Data) 的生成與驗證

作者:子yee
日期:2026-02-02

1. Overview

在許多產品開發的初期階段，特別是對於新遊戲、新應用或創新服務，開發者經常面臨一個核心挑戰：「冷啟動 (Cold Start)」問題。這意味著在產品正式上線並累積足夠的真實用戶數據之前，我們缺乏足夠的資料來訓練推薦系統、平衡遊戲數值、測試後端效能或進行市場分析 [1]。此外，隨著數據隱私法規（如 GDPR、CCPA）日益嚴格，獲取和使用真實用戶數據變得更加複雜和高風險。

為了解決這些難題，**「合成數據 (Synthetic Data)」**應運而生。合成數據是透過演算法生成的人工數據，它在統計特性上與真實數據相似，但卻不包含任何真實世界的個人身份資訊 [2]。這使得開發者可以在不侵犯用戶隱私、不觸犯法規的前提下，獲得大量擬真數據，用於開發、測試、模型訓練和系統優化。

本文件將深入探討合成數據的生成與驗證過程，特別是針對遊戲領域，我們將學習如何利用 AI 技術模擬萬名不同個性的玩家，生成大量的遊戲日誌（Log），並透過這些數據來預先調整遊戲平衡或測試資料庫效能。這不僅能有效解決開發初期的數據瓶頸，更能為產品的長期發展奠定堅實的數據基礎。

2. Architecture / Design

生成高品質的合成數據需要一個結構化的方法，特別是在模擬複雜行為模式（如玩家行為）時。以下是合成數據生成與驗證的架構設計 [3]。

2.1 玩家人格建模 (Player Persona Modeling)

要生成擬真的遊戲數據，首先需要定義不同類型的玩家行為模式。這些「玩家人格 (Player Personas)」將作為數據生成的核心驅動力。常見的玩家人格類型包括：

  • Whale (課金大老)：
    • 特徵：高頻率進行遊戲內購買（In-App Purchases, IAP），追求頂級裝備、稀有物品或快速進度。對遊戲內容的消耗速度快。
    • 行為模式：登入頻率高，遊戲時長可能不固定但單次遊戲時間長，傾向於參與限時活動和 PvP 內容。
  • Grinder (掛機玩家)：
    • 特徵：長時間在線，透過重複性任務穩定產出遊戲內資源，極少進行 IAP。
    • 行為模式：登入頻率高，遊戲時長極長，傾向於 PvE 內容和自動化掛機功能。
  • Casual (輕度玩家)：
    • 特徵：偶爾上線，遊戲行為隨機，對遊戲的投入程度較低，容易流失。
    • 行為模式：登入頻率低，遊戲時長短，可能只參與簡單的日常任務或社交互動。
  • Social (社交型玩家)：
    • 特徵：高度重視遊戲內的社交互動，頻繁與其他玩家組隊、聊天、交易。
    • 行為模式：登入頻率高，遊戲時長中等，傾向於公會活動、組隊副本和社交系統。

每個玩家人格都應定義其獨特的行為機率分佈、資源消耗模式和互動偏好。這可以透過參數化模型來實現，例如定義每個玩家人格的「每日登入機率」、「單次遊戲時長分佈」、「IAP 頻率」等 [4]。

2.2 生成引擎 (Generation Engine)

生成引擎負責根據定義的玩家人格模型，產生大量的合成數據。不同的生成技術適用於不同的數據複雜度：

  • 基於規則的腳本 (Rule-Based Scripting)：
    • 描述：最直接的方法，透過編寫程式碼來模擬玩家的基礎行為和遊戲邏輯。例如，一個腳本可以定義玩家每天登入、完成任務、然後登出。
    • 優點：易於理解和控制，適用於生成簡單、可預測的數據模式。
    • 缺點：難以模擬複雜、多樣化和隨機性強的行為，擴展性差。
  • 機率模型 (Probabilistic Models)：
    • 描述：利用統計學和機率論來生成數據。常見的方法包括：
      • 蒙地卡羅模擬 (Monte Carlo Simulation)：透過重複隨機抽樣來模擬事件的發生，例如玩家在遊戲中遭遇不同事件的機率。
      • 馬可夫鏈 (Markov Chain)：模擬玩家在不同遊戲狀態（例如「戰鬥中」、「城鎮中」、「任務中」）之間的轉移機率，生成連續的行為序列 [4]。
    • 優點：能夠生成更具隨機性和多樣性的數據，捕捉行為模式中的統計規律。
    • 缺點：對於高度複雜、長序列的行為模式，可能難以精確建模。
  • LLM 驅動代理 (LLM-Driven Agents)：
    • 描述：利用大型語言模型（LLM）的強大推理和生成能力，為每個模擬玩家賦予「目標」與「決策邏輯」，使其能夠產生更具語意和脈絡的行為日誌 [5]。
    • 工作原理：每個模擬玩家可以是一個小型 AI Agent，接收遊戲狀態作為輸入，並透過 LLM 決定下一步行動（例如「購買裝備」、「與隊友聊天」、「挑戰副本」），然後生成對應的遊戲日誌。
    • 優點：能夠生成高度擬真、具備複雜語意和因果關係的數據，特別適用於模擬玩家之間的互動和基於文本的行為。
    • 缺點：成本較高，對 LLM 的提示詞工程要求較高，生成速度可能較慢。

2.3 數據驗證 (Data Validation) 體系

生成合成數據後，必須對其進行嚴格的驗證，以確保其品質和可用性 [6]。

  • 忠實度驗證 (Fidelity Validation)：
    • 目的：確保合成數據在統計特性上與真實數據（如果存在）足夠相似，或者符合預期的行為模式。
    • 方法：
      • 統計分佈一致性：比較合成數據與真實數據（或預期分佈）的均值、中位數、標準差、偏度、峰度等統計量。例如，玩家的每日登入次數分佈、IAP 金額分佈等 [7]。
      • 相關性分析：檢查合成數據中變量之間的關聯性是否符合邏輯。例如，遊戲等級與遊戲時長之間應存在正相關。
      • 可視化比較：透過直方圖、散點圖、箱形圖等可視化工具，直觀比較合成數據與真實數據的分佈差異。
  • 隱私性驗證 (Privacy Validation)：
    • 目的：確保合成數據不包含任何可回溯到真實個體的敏感資訊，並符合數據隱私法規。
    • 方法：
      • 差分隱私 (Differential Privacy)：透過數學方法確保合成數據無法回推任何可能的真實個體資訊 [8]。
      • 重合度檢查 (Overlap Check)：確保合成數據不會過度擬合原始數據，避免生成與真實數據完全相同的記錄。
  • 效用驗證 (Utility Validation)：
    • 目的：評估合成數據在實際應用場景中的有效性，例如用於訓練機器學習模型或進行系統測試。
    • 方法：
      • Train-on-Synthetic, Test-on-Real (TSTR)：在合成數據上訓練機器學習模型，然後在真實數據上評估其性能。如果性能接近在真實數據上訓練的模型，則合成數據具有高效用 [9]。
      • 下游任務性能：將合成數據用於遊戲平衡測試、推薦系統訓練或資料庫負載測試，觀察其是否能有效揭示問題或提供有價值的洞察。

3. Prerequisites

要實作合成數據的生成與驗證，您需要具備以下環境和知識：

  • Python 環境：建議使用 Python 3.9 或更高版本。
  • 數據科學庫：熟悉 NumPy、Pandas 進行數據處理，Matplotlib、Seaborn 進行數據可視化。
  • 統計學基礎：理解機率分佈、假設檢定、相關性分析等基本統計概念。
  • LLM API 存取：如果選擇使用 LLM 驅動代理生成數據，需要 OpenAI、Anthropic 或 Google Gemini 等 LLM 的 API 存取權限。
  • 數據庫知識：了解 SQL 或 NoSQL 數據庫，以便將生成的數據匯入進行測試。
  • 遊戲設計或業務領域知識：對需要模擬的行為模式有深入理解，以便設計擬真的玩家人格和行為邏輯。

4. Implementation / Code Example

本節將提供一個概念性的 Python 程式碼範例，展示如何利用機率模型和 LLM 驅動代理的混合方法，生成模擬遊戲玩家的合成數據。

4.1 專案初始化與安裝

mkdir synthetic-game-data
cd synthetic-game-data
pip install numpy pandas openai python-dotenv

4.2 配置 LLM API 金鑰

創建 .env 檔案來儲存您的 API 金鑰：

OPENAI_API_KEY=your_openai_api_key_here

4.3 核心程式碼 (generate_game_logs.py)

import os
import random
import datetime
import uuid
import pandas as pd
from dotenv import load_dotenv
from openai import OpenAI
from typing import Dict, Any, List

load_dotenv()

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

# 1. 定義玩家人格 (Player Personas)
PLAYER_PERSONAS = {
    "Whale": {
        "login_frequency_days": (1, 1), # 每天登入
        "session_duration_hours": (3, 8), # 每次遊戲 3-8 小時
        "iap_probability": 0.8, # 80% 機率進行 IAP
        "iap_amount_range": (50, 500), # IAP 金額範圍
        "activity_types": {"quest": 0.3, "pvp": 0.4, "social": 0.2, "explore": 0.1}
    },
    "Grinder": {
        "login_frequency_days": (1, 1), # 每天登入
        "session_duration_hours": (6, 12), # 每次遊戲 6-12 小時
        "iap_probability": 0.05, # 5% 機率進行 IAP
        "iap_amount_range": (5, 20), # IAP 金額範圍
        "activity_types": {"quest": 0.6, "pvp": 0.1, "social": 0.1, "explore": 0.2}
    },
    "Casual": {
        "login_frequency_days": (2, 7), # 每 2-7 天登入一次
        "session_duration_hours": (0.5, 2), # 每次遊戲 0.5-2 小時
        "iap_probability": 0.1, # 10% 機率進行 IAP
        "iap_amount_range": (10, 50), # IAP 金額範圍
        "activity_types": {"quest": 0.4, "pvp": 0.1, "social": 0.3, "explore": 0.2}
    },
    "Social": {
        "login_frequency_days": (1, 2), # 每 1-2 天登入一次
        "session_duration_hours": (2, 5), # 每次遊戲 2-5 小時
        "iap_probability": 0.2, # 20% 機率進行 IAP
        "iap_amount_range": (20, 100), # IAP 金額範圍
        "activity_types": {"quest": 0.2, "pvp": 0.2, "social": 0.5, "explore": 0.1}
    }
}

# 2. LLM 驅動的行為生成 (用於更複雜的日誌內容)
def generate_llm_driven_log_entry(player_id: str, persona_type: str, current_game_state: Dict[str, Any]) -> str:
    prompt = f"""
    你是一個遊戲中的 {persona_type} 玩家，ID 是 {player_id}。
    當前遊戲狀態: {json.dumps(current_game_state, indent=2)}

    請根據你的玩家類型，生成一個簡短的遊戲日誌條目。例如：
    - 進行了什麼活動？
    - 獲得了什麼物品或成就？
    - 與其他玩家的互動？
    - 進行了什麼購買？

    請以一句話描述，不要包含個人資訊。
    """
    try:
        response = client.chat.completions.create(
            model="gpt-3.5-turbo", # 可以使用較便宜的 LLM 進行數據生成
            messages=[
                {"role": "system", "content": "你是一個遊戲玩家模擬器。"},
                {"role": "user", "content": prompt}
            ],
            max_tokens=50,
            temperature=0.7 # 增加隨機性以生成多樣化日誌
        )
        return response.choices[0].message.content.strip()
    except Exception as e:
        return f"[LLM_ERROR] 無法生成日誌: {e}"

# 3. 合成數據生成器
def generate_synthetic_player_data(num_players: int, num_days: int) -> List[Dict[str, Any]]:
    all_logs = []
    start_date = datetime.datetime(2026, 1, 1)

    for _ in range(num_players):
        player_id = str(uuid.uuid4())
        persona_type = random.choice(list(PLAYER_PERSONAS.keys()))
        persona = PLAYER_PERSONAS[persona_type]

        last_login_date = start_date - datetime.timedelta(days=random.randint(1, 30)) # 模擬初始登入時間
        current_level = 1
        total_iap_amount = 0

        for day_offset in range(num_days):
            current_date = start_date + datetime.timedelta(days=day_offset)

            # 根據登入頻率判斷是否登入
            if (current_date - last_login_date).days >= random.randint(*persona["login_frequency_days"]):
                last_login_date = current_date
                session_duration = random.uniform(*persona["session_duration_hours"])
                current_level += random.randint(0, 2) # 模擬等級提升

                log_entry = {
                    "timestamp": current_date.isoformat(),
                    "player_id": player_id,
                    "persona_type": persona_type,
                    "event_type": "login",
                    "details": {"session_duration_hours": round(session_duration, 2), "level": current_level}
                }
                all_logs.append(log_entry)

                # 模擬遊戲活動
                num_activities = random.randint(1, int(session_duration * 2)) # 根據時長決定活動數量
                for _ in range(num_activities):
                    activity_type = random.choices(list(persona["activity_types"].keys()), weights=list(persona["activity_types"].values()), k=1)[0]
                    activity_log = {
                        "timestamp": (current_date + datetime.timedelta(hours=random.uniform(0, session_duration))).isoformat(),
                        "player_id": player_id,
                        "persona_type": persona_type,
                        "event_type": f"activity_{activity_type}",
                        "details": {"level": current_level, "activity_detail": generate_llm_driven_log_entry(player_id, persona_type, {"level": current_level, "activity": activity_type})}
                    }
                    all_logs.append(activity_log)

                # 模擬 IAP
                if random.random() < persona["iap_probability"]:
                    iap_amount = round(random.uniform(*persona["iap_amount_range"]), 2)
                    total_iap_amount += iap_amount
                    iap_log = {
                        "timestamp": (current_date + datetime.timedelta(hours=random.uniform(0, session_duration))).isoformat(),
                        "player_id": player_id,
                        "persona_type": persona_type,
                        "event_type": "purchase",
                        "details": {"amount": iap_amount, "total_iap": round(total_iap_amount, 2)}
                    }
                    all_logs.append(iap_log)

            # 模擬登出事件 (簡化處理，實際可能更複雜)
            if random.random() < 0.1: # 10% 機率在某天登出
                log_entry = {
                    "timestamp": current_date.isoformat(),
                    "player_id": player_id,
                    "persona_type": persona_type,
                    "event_type": "logout",
                    "details": {"level": current_level}
                }
                all_logs.append(log_entry)

    return all_logs

# 4. 數據驗證 (簡化範例)
def validate_synthetic_data(df: pd.DataFrame):
    print("\n--- 數據驗證報告 ---")
    print(f"總日誌條目數: {len(df)}")
    print(f"唯一玩家數: {df['player_id'].nunique()}")
    print(f"數據時間範圍: {df['timestamp'].min()} to {df['timestamp'].max()}")

    # 檢查各玩家人格分佈
    print("\n玩家人格分佈:")
    print(df['persona_type'].value_counts(normalize=True))

    # 檢查 IAP 數據
    purchase_df = df[df['event_type'] == 'purchase']
    if not purchase_df.empty:
        print("\n購買行為統計:")
        print(f"總購買金額: {purchase_df['details'].apply(lambda x: x['amount']).sum():.2f}")
        print(f"平均單次購買金額: {purchase_df['details'].apply(lambda x: x['amount']).mean():.2f}")
    else:
        print("\n無購買行為記錄。")

    # 檢查等級與遊戲時長相關性 (簡化)
    login_df = df[df['event_type'] == 'login']
    if not login_df.empty:
        player_summary = login_df.groupby('player_id').agg(
            total_session_hours=('details', lambda x: sum([d['session_duration_hours'] for d in x])),
            max_level=('details', lambda x: max([d['level'] for d in x]))
        ).reset_index()
        correlation = player_summary['total_session_hours'].corr(player_summary['max_level'])
        print(f"\n總遊戲時長與最高等級的相關性: {correlation:.2f}")
    else:
        print("\n無登入行為記錄，無法計算相關性。")

    print("---------------------")

# 主程式邏輯
async def main():
    NUM_PLAYERS = 100 # 模擬 100 個玩家
    NUM_DAYS = 30   # 模擬 30 天的數據

    print(f"開始生成 {NUM_PLAYERS} 個玩家 {NUM_DAYS} 天的合成遊戲日誌...")
    synthetic_logs = generate_synthetic_player_data(NUM_PLAYERS, NUM_DAYS)

    # 將日誌轉換為 Pandas DataFrame 以便分析
    df = pd.DataFrame(synthetic_logs)
    df['timestamp'] = pd.to_datetime(df['timestamp'])
    df = df.sort_values(by='timestamp').reset_index(drop=True)

    print(f"成功生成 {len(df)} 條日誌。")
    print("前 5 條日誌:")
    print(df.head().to_string())

    # 執行數據驗證
    validate_synthetic_data(df)

    # 將數據保存為 CSV 或 JSON
    output_filename = "synthetic_game_logs.csv"
    df.to_csv(output_filename, index=False)
    print(f"合成數據已保存至 {output_filename}")

if __name__ == "__main__":
    import asyncio
    asyncio.run(main())

4.4 程式碼說明

  • PLAYER_PERSONAS：這是一個字典，定義了四種不同玩家人格的行為參數。每個玩家人格都有其獨特的登入頻率、遊戲時長、IAP 機率和活動偏好。這是生成擬真數據的基礎 [4]。
  • generate_llm_driven_log_entry：這是一個利用 LLM 生成更具語意和上下文的日誌條目的函數。它接收玩家 ID、人格類型和當前遊戲狀態，然後透過 LLM 產生一句話的行為描述。這使得生成的數據不僅僅是數值，還包含豐富的文本資訊，更接近真實的遊戲日誌 [5]。
  • generate_synthetic_player_data：這是核心的數據生成器。它循環生成指定數量的玩家，並為每個玩家模擬指定天數的行為。根據玩家人格的定義，它會隨機決定玩家是否登入、遊戲時長、進行何種活動以及是否進行 IAP。它將所有生成的事件記錄為日誌條目。
  • validate_synthetic_data：這是一個簡化的數據驗證函數。它會計算總日誌條目數、唯一玩家數、數據時間範圍，並檢查玩家人格分佈、購買行為統計以及遊戲時長與等級的相關性。在實際應用中，這裡會包含更複雜的統計分析和可視化比較，以確保合成數據的忠實度 [6]。
  • main 函數：協調整個生成和驗證過程。它設定了模擬的玩家數量和天數，呼叫 generate_synthetic_player_data 生成數據，然後將數據轉換為 Pandas DataFrame，最後呼叫 validate_synthetic_data 進行驗證，並將結果保存為 CSV 檔案。

5. Parameters / API Reference

本節將基於上述範例，抽象出實作合成數據生成時可能涉及的關鍵參數和介面。

5.1 PLAYER_PERSONAS 結構 (玩家人格定義)

欄位名稱類型描述
login_frequency_daysTuple[int, int]玩家登入的頻率範圍（例如 (1, 1) 表示每天登入）。
session_duration_hoursTuple[float, float]單次遊戲時長的範圍（小時）。
iap_probabilityfloat進行遊戲內購買的機率（0.0 - 1.0）。
iap_amount_rangeTuple[float, float]每次遊戲內購買的金額範圍。
activity_typesDict[str, float]玩家在不同活動類型上的偏好權重（例如 {"quest": 0.6, "pvp": 0.1}）。

5.2 generate_llm_driven_log_entry 介面

參數名稱類型描述
player_idstr模擬玩家的唯一 ID。
persona_typestr玩家的人格類型（例如 "Whale", "Grinder"）。
current_game_stateDict[str, Any]玩家當前的遊戲狀態（例如等級、位置等）。
返回值strLLM 生成的遊戲日誌條目文本。

5.3 generate_synthetic_player_data 介面

參數名稱類型描述
num_playersint要模擬的玩家數量。
num_daysint要模擬的遊戲天數。
返回值List[Dict[str, Any]]包含所有生成的遊戲日誌條目的列表。

5.4 validate_synthetic_data 介面

參數名稱類型描述
dfpd.DataFrame包含合成數據的 Pandas DataFrame。
返回值None輸出數據驗證報告到控制台。

6. Notes & Best Practices

  1. 從簡入繁的建模：從簡單的規則和機率模型開始，逐步引入 LLM 驅動的代理，以模擬更複雜、更具語意的行為。這有助於控制成本和複雜性 [3]。
  2. 迭代式驗證：合成數據的生成是一個迭代過程。每次生成後都應進行驗證，並根據驗證結果調整玩家人格模型和生成邏輯，直到數據品質達到要求 [6]。
  3. 數據模式的捕捉：合成數據的價值在於其能夠捕捉真實數據的底層模式和關係。這包括單一變量的分佈、變量之間的相關性以及時間序列模式 [7]。
  4. 隱私保護的設計：從設計之初就考慮隱私保護。確保生成的數據不包含任何可識別的個人資訊。如果需要從真實數據中學習模式，應使用差分隱私或其他匿名化技術 [8]。
  5. LLM 的應用策略：
    • 選擇合適的 LLM：對於生成大量文本日誌，可以考慮使用較便宜、速度較快的 LLM（如 GPT-3.5-turbo）。
    • 提示詞工程：為 LLM 代理設計清晰、具體的提示詞，明確其角色、目標和輸出格式，以確保生成數據的品質和一致性。
    • 溫度參數：調整 LLM 的 temperature 參數，以控制生成數據的隨機性和多樣性。較高的溫度會產生更多樣的數據，但可能降低一致性。
  6. 數據量與品質的平衡：生成大量數據固然重要，但數據品質（即數據的擬真度）更為關鍵。寧願生成少量高品質的數據，也不要生成大量低品質的數據 [1]。
  7. 可視化分析：利用數據可視化工具（如直方圖、散點圖、時間序列圖）來直觀比較合成數據與真實數據的特性，這對於發現數據中的偏差和異常非常有效。

7. 為什麼選擇這種方式？

在數據工程領域採用合成數據的生成與驗證，特別是在遊戲開發等需要大量用戶行為數據的場景中，具有不可替代的戰略價值：

  1. 解決「冷啟動 (Cold Start)」難題：新產品在發布初期往往缺乏足夠的真實用戶數據，這使得推薦系統、個性化功能或數據分析模型難以有效運作。合成數據提供了一個在產品上線前就能獲得大量擬真數據的解決方案，讓開發者能夠預先訓練模型、調整演算法，從而縮短產品從發布到成熟的時間 [1]。
  2. 規避數據隱私與合規風險：隨著 GDPR、CCPA 等數據隱私法規的實施，處理真實用戶數據變得極其複雜且風險高昂。合成數據不包含任何真實個人身份資訊，從根本上規避了這些隱私和合規性問題，使得開發者可以自由地共享、分析和使用數據，而無需擔心敏感資訊洩露 [2]。
  3. 加速開發與測試週期：透過生成大量的合成數據，開發團隊可以在沒有真實數據的情況下，對遊戲平衡性、新功能、推薦演算法進行充分的測試和迭代。這不僅加速了開發週期，也降低了在真實環境中測試可能帶來的風險和成本 [9]。
  4. 進行極端情況與壓力測試：合成數據允許開發者模擬各種極端或罕見的用戶行為模式，例如「超級課金玩家」或「惡意刷資源玩家」。這對於測試系統的穩定性、擴展性以及發現潛在的漏洞至關重要，例如資料庫的負載能力或遊戲經濟系統的平衡性 [10]。
  5. 降低數據獲取成本：在某些情況下，獲取真實數據可能非常昂貴或困難（例如需要進行大規模用戶調研或購買第三方數據）。合成數據提供了一個成本效益更高的替代方案，尤其是在數據需求量大但對數據的絕對真實性要求不高的場景。
  6. 促進創新與實驗：在沒有隱私顧慮的情況下，開發者可以更大膽地在合成數據上進行各種創新實驗，探索新的數據分析方法或機器學習模型，而無需擔心對真實用戶數據造成影響。

實作心得

剛開始用 LLM-Driven Agent 生成合成數據時，估算 API 費用是最大的衝擊。100 個玩家、30 天、每天平均 5 個活動，大概要打 15,000 次 LLM 呼叫。就算用 GPT-3.5-turbo，費用也比預期多了好幾倍。後來改成混合策略：只有「社交互動」類的日誌才呼叫 LLM 生成文字描述，其他純數值型的事件（登入、購買、等級提升）全部用機率模型，費用直接降到原來的 1/10 以下。

驗證的部分比我想像中難。TSTR（Train-on-Synthetic, Test-on-Real）聽起來很直觀，但要讓合成數據和真實數據的分佈夠接近，Whale 和 Grinder 的行為參數需要反覆調整。最有效的方法是先跑真實環境一週，拿到玩家的實際登入頻率分佈後，再用這個分佈反推 login_frequency_days 的範圍，而不是靠直覺猜。

另一個小細節：生成的 timestamp 要記得加上隨機的秒數偏移，否則同一個玩家的活動會整齊排列在整點，看起來很假，驗證時會被統計工具標記為異常規律的時間序列。這種細節在文章的架構設計中容易被忽略，但對後續的數據分析品質影響很大。

參考資料