AiReach — AiPower 單元 + Node BFF + React 前端三件套設計方案 v1.3

[!NOTE]
本文件定位為開發參考用的臨時設計稿，協助團隊在正式規格文件發布前對齊架構邊界；待正式規格建立後，可由正式文件取代並移除此參考稿。

〇、架構方向變更(v1.5):AiReach 自建獨立 Backend

〇.1 調整後的整體架構

〇.2 職責搬遷對照

權衡:AiPower 原本白送的「快速建制單元 / 流程、排程、多租戶隔離、欄位建模、AI SDK」自建後需自行選型實現,初期成本與維護量上升;換得技術棧自由與不受平臺節奏約束。

〇.3 全域性口徑替換(適用於下文 §一~§九)

下文多數章節成稿於 AiPower 口徑,在後續版本逐節落地前,按以下規則換算:

• • 「AiPower 單元 / 流程 / 業務單元」→「AiReach Backend Service」
• • 「AiPower 平臺單元 event_inbox / tenant_integration」→「Backend 內的 event_inbox / tenant_integration」
• • 「AiPower OpenAPI」→「Backend API」
• • 「資料與統計 / 工具域」由 AiReach Backend 承載
• • 「業務出站簽名」由 Backend 讀 tenant_integration 直髮 Aile 閘道器
• • BFF、AileAI、Aile / AS、前端 / AIFF 的職責不變

一、命名與定位

1.1 AiReach 應用三件套

1.2 AiReach 與 Aile 的接入身份表

1.3 關鍵邊界

• • Aile 側本期只看到一條 aireach IntegrationApp;入站契約動作(install / webhook / AIFF 註冊)在 BFF;業務後端出站簽名呼叫 AiPower 單元 / 流程直接對 Aile 閘道器發起(BFF 不在業務出站鏈路上)。
• • AiPower 業務單元不感知 Aile 簽名 / 協議細節,只接收 BFF 傳入的「規範化事件 / 命令 + eventId」與發起「規範化出站請求」;冪等去重由 AiPower event_inbox 單元完成。
• • BFF 同時是前端聚合層與 Aile↔AiPower 之間的協議橋。
• • 前端只部署一份 React Web;AileDesktop 中的嵌入由在 AS 側註冊的 AIFF 配置驅動,不需要另打 AIFF 包。

二、架構總覽

2.1 整體部署拓撲

2.2 各元件職責與部署要點

2.3 前端兩種開啟方式

同一份 React 程式碼,只是入口路由不同。

兩種開啟方式都走同一個 BFF 域 + 同一份 React 部署。

2.4 四方全景架構(含 AileAI,Phase 2 引入)

MVP 階段不含 AileAI;下圖為引入 Phase 2 AI 能力後的目標全景。核心口徑:AiPower = 資料與統計/工具域,AileAI = AI 編排域,二者職責解耦;Aile / AS 底座零侵入(不為 AI 新增 OpenAPI)。

職責邊界(四方 + AS):

• • Aile / AS:多租戶客服底座 + 統一認證;群發、點選捕獲、進線、SSO 全部沿用現行能力。
• • AiPower(資料與統計/工具域):業務主資料 + 統計聚合 + 把資料能力工具化為 Tool API(query_metrics / draft_campaign / dispatch_campaign / resolve_audience ...);強制 tenantId / actor 校驗與審計。
• • AileAI(AI 編排域):Copilot Router / 多 Agent / skills / RAG / MCP;不直接拼 SQL、不越權,只能經 AiPower Tool API 取數,經 RAG / MCP 取知識。
• • BFF:在三件套原職責上增加 SSE 中繼(Copilot 流式)與 薄 AI 閘道器(/api/ai/*),不承載 AI 業務邏輯。
• • 前端:新增 Copilot 抽屜 + AI Content Studio / Segment / Insight 入口,複用同一份 React 部署。

三、Aile 整合職責分配(協議層在 BFF)

Aile 與 AiReach 的整合按 spec v1.0 「註冊 → 安裝握手 → 事件分發 + OpenAPI 呼叫」四段實現,協議層統一交 BFF。

3.1 第一段:註冊 IntegrationApp(一次性)

Aile 平臺管理員一次性 POST /admin/integrations/apps 註冊 IntegrationApp:appId=aireach / installBaseUrl 指向 AiReach BFF / supportedEvents 訂閱 spec v1.0 八類資源域。

3.2 第二段:安裝握手 + AIFF 註冊

BFF 處理要點:

• • 個人租戶共享 externalTenantId = aireach_public_tenant,以 ownerId = ailePersonalTenantId 隔離;團隊租戶為每 Aile 租戶在 AiPower 側建一個租戶上下文。
• • 不僅初始化業務單元空間,還初始化 event_inbox 單元(主鍵 (tenantIntegrationId, eventId) 唯一)。
• • webhookUrl 始終指向 BFF 域。
• • 安裝後由 BFF 主動註冊 AIFF(詳 §六),同時允許後期呼叫 PI 介面修改。
• • /update /uninstall /rotate-secret 同樣由 BFF 接收。

3.3 第三段:事件分發(Aile → BFF → AiPower)

事件路由原則:BFF 按 eventType 把 EventEnvelope 規範化為 AiPower 入站命令並下發;冪等去重統一由 AiPower event_inbox 單元承擔(UNIQUE(tenantIntegrationId, eventId) 衝突即跳過),BFF 僅做驗籤 + nonce 檢查 + 透傳 eventId。

3.4 第四段:OpenAPI 出站(AiPower → Aile 閘道器)

架構變更:業務後端(AiPower 單元 / 流程)直接對 Aile 閘道器發起簽名呼叫,不再經過 BFF。BFF 僅承接 install / webhook / AIFF 註冊等協議入口動作,不充當業務出站代理 —— BFF 本質是 AiReach 前端的聚合層,後端不會主動呼叫 BFF。

簽名原子 (與 v1.2 一致):

Authorization: AILE <tenantIntegrationId>:<signature>
raw = tenantIntegrationId + nonce + bodyString
signature = Base64(HmacSHA256(tenantIntegrationSecret, raw))

3.5 BFF 與 AiPower 的整合協議

四、Aile 側為推播場景需補齊的介面清單(MVP)

AiReach 複用 Aile 現行服務號群發能力(已支援「按客戶標籤篩選 → 最多 5 則訊息 → 立即/定時」,本方案在 OpenAPI 層將 audience 欄位擴為 union 形態以支援「名單直傳」承載 AiReach 側已算出的精準受眾)作為推播主鏈;本方案在其上補齊 OpenAPI,讓 AiReach 業務後端可直接驅動群發任務,無需自行實現排程 / 受眾 / 渠道適配。NoticeContent 契約(§4.0)與點選 webhook(§4.4)承載卡片訊息與 Postback 歸因;進線原因聯動(§4.9)為可選擴充套件。

本章共 9 項 OpenAPI + 3 項 webhook 事件 = 12 項,服務號級介面落入字首 /openapi/v1/service-numbers/{snId}/*,租戶級進線原因介面落入字首 /openapi/v1/entry-sources/*,按資源域分別由 aile-service-message / 進線原因服務承載。

發起方約定:群發任務 建立 / 查詢 / 取消 由 AiReach Backend Service 直髮 Aile 閘道器;客戶標籤 列表 / 打標 / 摘標 由 BFF 前端聚合(也可 AiPower 側發起)。

MVP 範圍:合規預檢(原 B 類)、轉化主動回寫(原 C 類)、推播額度、渲染預覽、AI / 高階受眾(原 E 類)本期不實現,後續按業務需要再補齊(章節已刪除,不再保留佔位)。

4.0 NoticeContent 訊息格式契約

AiReach 傳送時直接按 Aile 真實 NoticeContent + Action 結構組合訊息體,隨 A1 群發任務的 messages[] 提交(詳 §4.1);Aile 僅做結構校驗 + 內容安全檢測 + 渠道適配 + 點選捕獲回傳,不維護模板態,不解析 data 欄位的業務語義(除 Postback 必須能解出頂層 appId 與 event 用於路由 / 分支 webhook 外)。

NoticeContent 結構(對齊 Aile 現行卡片模型):

• • type (string,固定 "Buttons")
• • title (string)
• • text / describe (string,卡片正文)
• • image (url,可選)
• • actions (array, 0..N) —— 每項為 Aile Action 物件

Action 欄位(Aile Java 模型):

ActionType 語義與點選處理(本方案使用範圍):

Action.data 的歸屬與點選歸因:

• • data 在 type=Postback 下用作業務引數 JSON 字串:Aile 不解析(除 Postback 必須能解出頂層 appId 用於路由 webhook 外),webhook 原樣透傳;AiReach 自定義業務 schema(歸因 id / 活動 ID / 業務欄位)。
• • 點選歸因載體:
  • • type=Postback(本方案主用):data 頂層必含 Aile 保留欄位 appId + event(取值 "Broadcast" 群發 / "InboundReason" 進線原因聯動,詳 §4.9);AiReach 在其下自定業務欄位(例 taskId / campaignId / bizEventCode / couponId)
  • • type=Url:Aile 僅以 (noticeId, actionIndex) 標識被點選的按鈕回傳

示例 —— type=Postback + type=Url 混合卡片(AiReach 營銷活動典型形態):

{
  "type": "Buttons",
  "title": "限时优惠券",
  "text": "点击领取你的专属券,有效期 24 小时。",
  "image": "https://cdn.aireach/.../coupon.png",
  "actions": [
    {
      "type": "Postback",
      "label": "立即领取",
      "data": "{\"appId\":\"aireach\",\"event\":\"Broadcast\",\"campaignId\":\"cmp_42\",\"bizEventCode\":\"REDEEM_COUPON\",\"couponId\":\"C123\"}"
    },
    {
      "type": "Url",
      "label": "查看详情",
      "url": "https://aireach.example.com/coupon/C123"
    }
  ]
}

Postback data 健壯性約定:

• • data 解析失敗 → AiReach 視為無效點選,記錄錯誤日誌並丟棄,不影響 notice.clicked 事件落庫。
• • data 缺少頂層 appId 或 event 欄位 → Aile 傳送時拒絕(詳 §4.8.2)。

契約面小結(應用 ↔ Aile):

• • AiReach 擁有 Action.data 的業務 schema 解釋權(本方案僅適用於 Postback 型別)。
• • Aile 僅承擔:結構校驗 + Postback 路由(讀 data.appId) + 點選回傳 + 渠道適配。
• • 不需要 Aile 提供「模板列表 / 模板詳情」介面。
• • Postback 強約定:data 必須為合法 JSON 字串且頂層包含 兩個 Aile 保留欄位:appId(固定 "aireach",Aile 據此路由 webhook 接收方)與 event(取值 "Broadcast" 或 "InboundReason",Aile 據此判別處理流程,詳 §4.9;對齊 Aile 現行 event:"InboundReason" 既定格式);缺失任一則傳送時拒絕。

4.1 A 類——群發任務介面(複用 Aile 現行服務號群發,3 項)

對齊 Aile 管理後臺「新建群發任務」UI 欄位(任務名 / 備註 / 傳送渠道 / 1..5 則訊息 / 客戶標籤篩選 / 立即或定時):AiReach 透過 OpenAPI 一次性提交任務,Aile 按現行群發流程完成命中計算、排程、渠道適配與投遞。

Aile 側需配套支援:

1. 1. 群發任務儲存與排程引擎已具備,本期僅追加 OpenAPI 入口。
2. 2. messages[] 允許混合 文字 / 圖片 / 附件 / NoticeContent 卡片,最多 5 則,與 Aile UI 上限一致。
3. 3. 卡片 Action 為 Postback 時,Aile 按 §4.5 鏈路捕獲點選併發 notice.clicked,事件 payload 需攜帶 taskId 用於 AiReach 關聯回任務。
4. 4. 任務建立時按 audience.type 分支校驗:tags 模式校驗 tagIds[] 在該服務號下存在且非刪除態;contacts 模式校驗 contactIds[] 在該服務號下存在、單任務上限 1000(超限直接拒絕),系統自動去重並過濾退訂客戶。
5. 5. 任務執行受 Aile 現行 退訂 / 頻次 / 時間窗 治理保護,被治理攔截的客戶不計入投遞成功。
6. 6. 安全 / 內容稽核沿用 Aile 現行群發流水線。
7. 7. 需追加客戶標籤列表 OpenAPI(詳 §4.5 D1)。
8. 8. Aile 需識別新增 Postback data.event="Broadcast"(對齊現行 event:"InboundReason" 既定格式),路由 notice.clicked webhook 時無需建立 Session;event 欄位缺失或取值未知則傳送時拒絕。
9. 9. 群發任務 audience 欄位擴為 union 型別({type:"tags",...} / {type:"contacts",...}),排程入隊層新增「名單直入」分支跳過標籤反查;OpenAPI 與 Aile UI 解耦,Aile 後臺手工建任務 UI 仍可只暴露標籤篩選不受影響。

4.2 推播 webhook 事件(1 項,統一歸入 spec §10.2 notice.*)

Aile 側只發單一事件 notice.clicked;Aile 透過 Postback data.event 欄位判別處理流程:"Broadcast" = 群發點選,僅發 notice.clicked;"InboundReason" = 進線原因聯動,Aile 同時啟動 Session 建立流程(詳 §4.6)。業務語義差異由 AiReach 自定欄位(bizEventCode / taskId / campaignId / 業務欄位)承載,Aile 不解析。任務級狀態(建立 / 完成 / 失敗)由 A2 輪詢替代,本期不發獨立事件。

scope.serviceNumberId 必填;由 aile-service-message 在 Postback / 跳轉包裝 鏈路觸發時呼叫 EventPublishClient。

事件統一原則:AiReach 在 NoticeContent 組裝時自行將業務事件名編碼進 Postback data(例 data.bizEventCode = "REDEEM_COUPON_CLICK");Aile 僅發一類 notice.clicked,AiReach 收到後按 data 自定欄位路由內部業務流程。如後續需細分(notice.delivered / notice.bounced / notice.complained / notice.converted 等),獨立增列,不在 MVP 範圍。

4.3 D 類——客戶 / 標籤 / 受眾(3 項)

v1.3.9 修訂:D 類介面為 Aile 側客戶標籤的讀寫入口,保留供其他 IntegrationApp 使用;AiReach 自身不呼叫 D 類——AiReach 營銷標籤由 AiPower 單元自管,詳 §4.7。若 Aile 後續推送任何客戶標籤變更 webhook,BFF 直接丟棄,不寫入 event_inbox。

4.4 優先順序總覽(9 項 OpenAPI + 3 項事件 = 12 項)

• • P0(MVP 必備,5 項):A1 / A2 / D1 / D2 / notice.clicked
• • P1(最佳化體驗,1 項):A3
• • P2(擴充套件,6 項;其中 5 項僅在啟用進線原因聯動 §4.6 時所需):D3 / F1 / F2 / F3 / session.created / session.closed

啟用 §4.6 auto 模式時,F1 與 session.created 升為 P0;none 模式下 MVP 僅需 P0 5 項即可上線。

4.5 點選捕獲與 webhook 回傳規則(由 Aile 統一負責)

按鈕點選由 Aile 在兩類 ActionType(Postback / Url)鏈路上統一攔截 + 落庫 + 回傳;notice.clicked 原樣回傳被點選的 Action 欄位(type / data),應用據此自行歸因。進線觸發沿用 Aile 現行邏輯,可選聯動詳 §4.6。

4.5.1 點選捕獲路徑(兩類 ActionType)

4.5.2 Aile 側落庫與回傳約束

• • 傳送時 Aile 將 actions[] 與 (noticeId, actionIndex) 持久化關聯,點選事件回撥時一併帶回 actionIndex。
• • type=Postback:Aile 必須能從 data JSON 解出頂層 appId 與 event,否則傳送時拒絕。
• • 點選事件透傳欄位固定為 action: { type, data },其餘 Action 欄位(label / url / imageUrl 等)Aile 不在 webhook 中攜帶;如應用需要可按 (noticeId, actionIndex) 回查原 notice。
• • 進線 / 會話路由由 Aile 側現行邏輯獨立處理,本方案 webhook payload 不含進線相關欄位。

4.5.3 notice.clicked webhook payload 示例

{
  "eventType": "notice.clicked",
  "scope": { "serviceNumberId": "sn_xxx" },
  "data": {
    "noticeId": "ntc_xxx",
    "actionIndex": 0,
    "action": {
      "type": "Postback",
      "data": "{\"appId\":\"aireach\",\"event\":\"Broadcast\",\"taskId\":\"bcst_xxx\",\"campaignId\":\"cmp_42\",\"bizEventCode\":\"REDEEM_COUPON_CLICK\",\"couponId\":\"C123\"}"
    },
    "contactId": "ct_xxx",
    "clickedAt": "2026-05-22T10:00:00Z"
  }
}

AiReach 收到事件後:

• • type=Postback(本方案主用) → 解 data JSON,按 event / bizEventCode / campaignId 等欄位歸因與路由業務流程(event=InboundReason 額外讀 sourceId,詳 §4.6)
• • type=Url → 按 (noticeId, actionIndex) 歸因

4.6 進線原因聯動(可選)

AiReach 營銷卡片的 Postback 按鈕可選嵌入 Aile 進線原因機制（進線原因規格設計）。粒度 = 每個 Postback Action;同卡片可混用兩種行為。

4.6.1 兩種行為

4.6.2 F 類——進線原因介面(3 項)

F 類介面不帶 service-numbers/{snId} 字首;EntrySource 與服務號透過 channels 陣列關聯,而非路徑繫結。

4.6.3 session.* webhook 事件(2 項,僅 auto 模式訂閱)

EntrySource webhook(session.*)與 IntegrationApp webhook(notice.*)均指向 BFF 統一入口;BFF 按 eventType 區分後下發 AiPower。

4.6.4 Postback data JSON 頂層欄位表(精確化 §4.0)

4.6.5 時序（聯動進線）

4.6.6 關鍵約束

• • 啟用「聯動進線」的 Postback Action 下,F1 必須在 A1 建立群發任務之前完成;sourceId 取得後才能注入 Postback data。
• • 同一 campaign 內可逐 action 決定是否啟用(粒度 = Postback 按鈕):同卡片可同時含「event=InboundReason 的諮詢按鈕」與「event=Broadcast 的領券按鈕」。
• • notice.clicked 與 session.created 是兩個獨立事件,可能不同步到達;AiPower 在 event_inbox 去重並以 (campaignId, contactId, actionIndex) 關聯兩路歸因。
• • 未啟用「聯動進線」的 Postback Action 不呼叫 F 類介面,也不訂閱 session.* 事件;Aile 不會啟動進線流程,卡片表現為純 CTA。
• • EntrySource 與 AiReach campaign 關係約定為 1:1(每個 auto campaign 建立一條 EntrySource,繫結後複用);如未來需多卡片複用 EntrySource,再擴充套件 N:1。

4.7 AiReach 標籤體系與受眾解析(v1.3.9 新增)

4.7.1 標籤邊界口徑

關鍵約束:

• • AiReach 不讀、不寫、不依賴 Aile 側標籤;Aile 也無義務把 AiReach 標籤回寫
• • D1 / D2 / D3 介面(§4.3)仍保留給非 AiReach 整合方;AiReach 實現側不再呼叫
• • 若 Aile 後續推送任何「客戶標籤變更」webhook,BFF 直接丟棄,不寫入 AiPower event_inbox
• • AiReach 標籤按 (tenantId, serviceNumberId) 作用域隔離;跨服務號同名標籤視為不同標籤
• • 標籤來源固定為 aireach_manual(運營手動) / aireach_smart(智慧規則貼標);不存在 aile_* 來源

4.7.2 AiReach 標籤 → A1 audience 解析鏈路

解析時機:

• • 預覽時(FE 受眾估算):實時解析一次,展示命中數 + 可觸達數
• • 傳送時(任務建立):再次實時解析作為最終受眾快照,落入 broadcast_task.audienceSnapshot,後續標籤變化不影響已發任務(對齊 MAAC 「傳送時受眾固化」約定)

4.7.3 超過 1000 受眾的拆分策略

A1 contactIds[] 上限 1000,AiReach 內部按以下順序處理(Aile 完全不感知):

1. 1. 同 campaign 多子任務:AiPower 按 1000 一批,建立多個 A1 任務,以 parentTaskId 關聯;broadcast_task 單元新增 parentTaskId 欄位
2. 2. 子任務排程:schedule.type="immediate" 全部併發提交;scheduled 模式所有子任務共享同一 at;personalized(Phase 2)各子任務按命中人桶分配
3. 3. 彙總聚合:summary / status 在 AiPower 層按 campaignId 聚合多個 task 後回展示給 FE
4. 4. 每個子任務對 Aile 而言就是一次普通 A1 呼叫,無任何新協議

Phase 2 Smart Sending「按 bestSendHour 分桶 → 拆多個 scheduled 子任務」直接複用此基礎設施。

4.7.4 智慧貼標的事件源約束

AiReach 智慧貼標(smart_tag_rule 單元,詳 Phase 2 設計頁 §3.8)只可消費 AiPower event_inbox 已落庫事件,觸發源對映:

貼標記錄可追溯欄位(tag_assignment 單元):sourceRuleId / sourceCampaignId / sourceTaskId / sourceActionIndex / sourceBizEventCode,任一可空。運營在標籤詳情可反查「為什麼這個人被貼上了這個標籤」。

4.7.5 臨時標籤生命週期

• • tag.expiresAt 欄位標記過期時間(可空 = 永久);臨時標籤典型用法:活動期短期沉澱、AI Segment 命中快照
• • 查詢 tag_assignment 時實時過濾 expiresAt > now(),過期標籤不進入受眾估算與命中
• • 每日定時 flow.expire_temporary_tags 掃描並歸檔過期標籤(status → archived),保留歷史 tag_assignment 作為審計與歸因依據

五、AiReach 內部架構

5.1 BFF 模組拆分

關鍵差異 (vs v1.2):

• • 移除 BFF 側 event_inbox 與 Idempotency 模組 → 冪等下沉至 AiPower。
• • 新增 AIFF Registrar 模組,專門維護該租戶的 AIFF 配置生命週期。
• • 嚴格區分 AS Adapter(僅 SSO)與 Aile 閘道器 Client(install / AIFF 註冊 + 前端聚合所需出站)。
• • 業務後端出站簽名由 AiPower 直髮 Aile 閘道器,不經 BFF。
• • 新增 tenant_integration 同步器,將 install / rotate-secret 後的 Secret 推送到 AiPower tenant_integration 平臺單元。

5.2 AiPower 業務單元與流程清單

5.3 資料歸屬

5.4 傳送主鏈完整時序(三件套協同)

六、前端與 AIFF 整合

6.1 AIFF 概念定位

AIFF = Aile 側的前端開發框架(配置 + 協議),不是打包格式。其工作機制:

1. 1. 應用透過 Aile 閘道器上的 AIFF 整合 API(spec v1.0 §9.2 的 /openapi/v1/aiff/**)註冊一份 AIFF 配置,宣告:
   • • 嵌入位置(slot):AileDesktop 的哪個槽位(例:客戶詳情側欄 、服務號工作臺 Tab 、左側主導航 、設定中心子頁等)
   • • endpoint URL:該槽位應載入的頁面入口地址(通常是該應用自己的 Web 路由)
2. 2. 註冊完成後,AileDesktop 根據配置在對應位置自動載入 endpoint(內嵌 webview / iframe),同時透過 AIFF bridge 注入當前賬號 token / 服務號上下文。
3. 3. AIFF 配置由租戶管理員或 AiReach BFF 在安裝握手後呼叫註冊介面寫入,可後續調 PI 修改。

AIFF 整合 API 隸屬 Aile 閘道器下的 AIFF 資源域(spec v1.0 §9.2 路由表),由 aile-service-auth 承載領域邏輯。

6.2 AiReach 的 AIFF 配置策略

AiReach 前端只需部署一份獨立 React Web(無需另打 AIFF 包)。AileDesktop 內的嵌入完全由 AIFF 配置驅動:

6.3 AIFF 配置寫入流程

6.4 AiReach 計劃註冊的 AIFF 槽位(初版)

6.5 前端兩種開啟方式的差異點

一份程式碼,兩種開啟:獨立 Web(/app/* 路由) 與 AIFF 槽位(/embed/* 路由)。差異僅在登入 、上下文來源與外殼:

• • 登入:獨立 Web 重定向 BFF 走 AS SSO;AIFF 槽位讀取 AIFF 框架注入的 token,BFF 校驗後建會話。
• • 上下文:獨立 Web 由 URL / 使用者選擇;AIFF 槽位從 bridge 注入(tenantId / serviceNumberId / contactId)。
• • 外殼:獨立 Web 帶頂欄 / 側欄;AIFF 槽位複用 AileDesktop 外殼,隱藏頂側欄。
• • 適配層:手機抽象 ShellAdapter + AuthAdapter,程式碼上僅一處 if/else 。

七、完整場景走查(MVP 一次活動為線索)

本節按 MVP 推播鏈路展開一次完整營銷活動的關鍵步驟;auto 模式增補步驟標註「opt auto」。

八、開發路線圖

九、關鍵設計決策彙總

十、修改歷程