疑難排解即時動態 troubleshoot-mobile-live

Adobe Experience Platform Assurance中的「已上線活動」檢視可驗證應用程式的設定、檢查活動事件，並可讓您從遠端啟動、更新或結束測試工作階段中的活動。

需求

三個索引標籤

從Assurance開始、更新和結束

啟動已上線活動。 開啟對話方塊以挑選註冊的活動型別、選擇單一或廣播、輸入廣播頻道ID （僅限廣播），以及編輯預先填寫的APS JSON裝載。 如果不符合開始推播權杖、iOS版本或頻道設定需求，按鈕會停用或傳回錯誤。

傳送更新。 從現有活動的Overview索引標籤，傳送更新（推送新內容）或結束事件。 為了統一，外掛程式會自動使用活動的更新Token。 如果是廣播，它會鎖定訂閱相同廣播頻道ID的所有裝置。 裝載必須是有效的JSON，並符合活動的屬性結構描述；否則會拒絕要求。

如需設定和工作階段連線步驟，請參閱Adobe Experience Platform Assurance檔案。

在Journey Optimizer中導覽至您的API觸發的行銷活動，並擷取：

• 行銷活動名稱和ID
• Campaign版本（如果適用）
• 行銷活動型別： 異動 （單一）或​行銷 （廣播）
• 表面設定：用於即時活動的iOS應用程式表面
• 活動型別：在行銷活動中設定的AttributeType結構名稱

發出API呼叫以觸發即時活動時，請儲存：

• API要求裝載，包括設定檔識別碼和即時活動資料
• API回應，包括狀態代碼、訊息ID、請求ID
• 呼叫API的時間戳記
• 使用的端點，例如/campaign/{CAMPAIGN_ID}/execute

從您的API請求中擷取：

• 設定檔名稱空間，例如ECID、電子郵件、客戶ID
• API呼叫中使用的設定檔ID

確定您可以在Adobe Experience Platform中查詢此設定檔。 在Experience Platform檔案🔗中瞭解如何查詢設定檔。

從測試裝置收集下列專案：

• 裝置型號，例如iPhone 14 Pro
• iOS版本
• 應用程式套件組合識別碼
• APNs推播權杖
• 測試時的網路連線狀態

1. 在Journey Optimizer中，導覽至​客戶 > 設定檔。
2. 使用API請求的名稱空間和身分值來搜尋。
3. 如果找不到設定檔，表示設定檔不存在或內嵌未完成。 在觸發上線活動之前，請建立設定檔或等待擷取。
4. 如果找到設定檔，請繼續執行下方的步驟2以檢查推送代號是否已同步。

您可以使用Assurance來驗證Token註冊：

1. 在Assurance中，從​ 事件 ​清單，篩選或搜尋事件eventType = "liveActivity.pushToStart"。
2. 選取​ 事件 ​並檢查裝載。
3. 檢查權杖、appId和attributeType值是否存在。
4. 確認事件是否成功傳送。

您也可以存取Adobe Experience Platform設定檔。

1. 在Adobe Experience Platform中，從您的​ 設定檔 ​存取​ 事件 ​索引標籤。
2. 搜尋liveActivity.pushToStart個事件。
3. 檢查偶數時間戳記和承載。

如果找不到事件，表示您的行動應用程式無法正確呼叫Messaging.registerLiveActivity。 您需要修正SDK整合。

1. 從您的​設定檔，存取​ 屬性 ​標籤。

2. 找到liveActivityPushNotificationDetails。

3. 驗證權杖設定：

   code language-json
   { "liveActivityPushNotificationDetails": [ { "appId": "com.example.myapp", "token": "abc123def456...", "platform": "apns", "denylisted": false, "attributeType": "OrderTrackingAttributes", "identity": {} } ] }

驗證每個欄位：

如果任何欄位不正確：更新行動應用程式，使用Messaging.registerLiveActivities重新註冊，等待5到10分鐘，然後重新檢查。

如果liveActivityPushNotificationDetails遺失： Token尚未同步。 在Assurance中看到liveActivity.pushToStart事件後，請等待5至10分鐘。

1. 在Journey Optimizer中，開啟您的​ 行銷活動 ​並導覽至​ 動作 ​功能表。
2. 檢查您的​上線活動設定。 您必須使用符合設定檔liveActivityPushNotificationDetails中appId的套件組合識別碼，為iOS應用程式設定表面。 例如，如果您的設定檔有"appId": "com.example.myapp"，則表面必須針對相同的應用程式。
3. 檢查促銷活動組態中的​ 活動型別 ​是否與設定檔liveActivityPushNotificationDetails中的attributeType完全相符。 例如，如果您的設定檔有"attributeType": "FoodDeliveryLiveActivityAttributes"，則行銷活動必須指定此相同的活動型別。

透過API執行行銷活動時，請確定裝載遵循正確結構。

單一承載：

{
   "campaignId": "your-campaign-id",
   "recipients": [{
      "type": "aep",
      "userId": "user@example.com",
      "namespace": "email",
      "context": {
      "requestPayload": {
         "aps": {
            "content-available": 1,
            "timestamp": 1756984054,
            "event": "start",
            "attributes-type": "FoodDeliveryLiveActivityAttributes",
            "content-state": { ... },
            "attributes": { ... }
         }
      }
      }
   }]
}

常見承載問題：

嚴重：一律使用最新的時間戳記

• 進行每個API呼叫時，timestamp欄位必須​ 一律 ​為​目前的Unix紀元時間 （以秒為單位）。
• 這適用於​所有事件型別： start、update以及​特別是end。
• 對更新/結束要求的影響：使用過時或舊時間戳記會導致更新及結束要求失敗或被裝置忽略。
• 請​ 不 ​重複使用先前請求的時間戳記，或使用快取的值。
• 為每個API呼叫產生新的時間戳記。

選用欄位（所有事件型別）：

• requestId：追蹤的唯一識別碼（建議）。
• alert：通知物件有title和body （有助於提醒注意更新）。

關於dismissal-date：

• 包含Unix紀元時間（秒）的可選欄位。
• 僅在event: "end"​時相關。
• 指定何時應自動從裝置移除即時活動。
• 如果未在最終事件中提供，則即時活動會維持可見，直到使用者將其解除為止。
• 必須為未來的時間戳記（晚於timestamp）。

確認您的API裝載符合您的iOS應用程式的ActivityAttributes實作。 Adobe SDK的LiveActivityAttributes通訊協定擴充iOS ActivityAttributes，並需要liveActivityData屬性。

驗證對應：

1. 您的ActivityAttributes必須實作Adobe的LiveActivityAttributes通訊協定。 範例：

   code language-swift
   struct FoodDeliveryLiveActivityAttributes: LiveActivityAttributes { public struct ContentState: Codable, Hashable { var orderStatus: String var estimatedDeliveryTime: String } // Adobe SDK requirement var liveActivityData: LiveActivityData // Your custom attributes var restaurantName: String }

   請注意 liveActivityData欄位是Adobe SDK的必要欄位，必須包含在所有實作中。

2. 您的API裝載必須映象iOS結構：

   code language-json
   { "aps": { "event": "start", "timestamp": 1756984054, "attributes-type": "FoodDeliveryLiveActivityAttributes", "content-state": { "orderStatus": "Preparing", "estimatedDeliveryTime": "20 mins" }, "attributes": { "liveActivityData": { "liveActivityID": "order-12345" }, "restaurantName": "Pizza Palace" } } }

驗證檢查清單：

• 在content-state中包含所有ContentState欄位（所有事件型別都需要）。

• 在attributes中包含所有LiveActivityAttributes欄位（僅限開始事件），包括：

  • liveActivityData （必要；通常包含liveActivityID或類似的識別碼）
  • 結構中的所有自訂欄位

• 完全符合欄位名稱（區分大小寫）。

• 符合資料型別（String、Int、Bool、巢狀物件）。

• 保留巢狀物件結構。

常見錯誤：

如需更多範例，請參閱建立即時活動頁面。

使用Assurance驗證API執行和裝載傳送：

1. 開啟您的Assurance工作階段。

2. 執行API呼叫以觸發上線活動。

3. 在​ 事件清單 ​中，檢查：

   • 行銷活動執行事件。
   • 已上線的活動傳送活動。
   • 裝載驗證錯誤事件。

4. 檢閱事件裝載以驗證：

   • 已正確處理承載。
   • 沒有發生驗證錯誤。
   • 已將上線活動傳送至APN。

1. 導覽至您的​即時活動行銷活動。

2. 按一下​ 報表 ​按鈕。

3. 選取​檢視所有時間報表。

4. 檢閱下列章節：

   1. 檢查​ 傳送統計資料 ​量度以瞭解傳送成功：

      table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
      量度	其含義	要尋找的內容
      已鎖定目標	符合對象資格的設定檔數	應該包含您的測試設定檔
      傳送	嘗試的推播通知總數	應該符合您的API呼叫
      已傳遞	已成功傳遞至裝置	與傳送比較以檢視成功率
      傳送錯誤	無法傳送的推播通知	高數字
      傳送排除專案	Adobe Journey Optimizer排除的設定檔	檢查您的設定檔是否已排除

   2. 如果傳送錯誤> 0，請檢查​ 錯誤原因 ​資料表以取得特定的錯誤碼和訊息：

      table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
      常見錯誤	含義	解決方法
      權杖無效	推播權杖無效或過期	從裝置重新註冊即時活動權杖
      找不到語彙基元	沒有與設定檔相關聯的有效權杖	驗證liveActivityPushNotificationDetails是否存在
      已拒絕APN	Apple推播通知服務已拒絕推播	檢查APNs憑證、套件ID、環境
      網路逾時	無法連線APN	暫時性問題；請重試API呼叫

   3. 如果​傳送排除專案 > 0，請檢查​ 排除的原因 ​資料表：

      table 0-row-3 1-row-3 2-row-3 3-row-3
      常見排除	含義	解決方法
      設定檔已選擇退出	使用者已選擇退出通知	檢查設定檔同意狀態
      權杖已加入封鎖清單	標籤為無效的權杖	重新註冊Token或檢查封鎖清單狀態
      設定檔不合格	設定檔不符合行銷活動條件	檢閱行銷活動對象規則

在即時活動行銷活動報告頁面瞭解更多。

1. 導覽至Journey Optimizer中的​客戶 > 設定檔。

2. 搜尋並開啟設定檔。

3. 選取​ 事件 ​標籤。

4. 篩選或搜尋具有eventType = "message.feedback"的事件。

5. 尋找與您上線活動的liveActivityID和event型別相符的意見反應事件。

6. 檢閱下列重要欄位：

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3
   欄位	可能的值	其含義
   feedbackStatus	sent, error, denylist	來自服務提供者的傳遞結果
   serviceProvider	apns/apnsSandbox	應該是iOS Live活動的APN
   errorCode	數值代碼或null	APNs專屬錯誤碼（若失敗）
   errorMessage	錯誤描述或null	人類看得懂的錯誤訊息

7. 若feedbackStatus: "error"：

   • 檢查errorCode和errorMessage是否有特定的APN錯誤
   • 常見的APN錯誤包括過期的權杖、無效的憑證、錯誤的套件組合識別碼

8. 如果找不到意見反應事件：

   • 可能尚未嘗試推播通知
   • 如上述步驟1所述，檢查促銷活動報表中是否排除設定檔。

1. 開啟您的Assurance工作階段，它必須在API呼叫期間作用中。

2. 執行API呼叫（開始、更新或結束）。

3. 在​ 活動清單 ​中，尋找已上線活動傳遞活動。

4. 搜尋與APN推送傳遞相關的事件。

5. 檢查下列指標：

   • 推送要求至APN：確認Adobe已傳送推送要求至Apple的伺服器
   • APN回應：顯示APN是否接受或拒絕推播
   • 傳遞狀態：成功或失敗指示

6. 如果發現問題，請參閱以下常見的APN傳送問題：

   table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3
   問題	Assurance中的症狀	解決方法
   APNs憑證已過期	驗證錯誤	更新及上傳新的APNs憑證
   錯誤的環境（開發環境vs生產環境）	權杖不符錯誤	確保憑證符合應用程式建置型別
   套件組合ID不相符	無效的套件組合識別碼	驗證憑證套件組合ID是否與應用程式相符
   權杖已到期	來自APN的InvalidToken錯誤	重新註冊即時活動權杖
   速率限制	請求次數過多	降低API呼叫頻率

1. 檢查行銷活動報告中的即時活動生命週期量度。

   在行銷活動報告中，檢閱​ 即時活動生命週期 ​區段：

   table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2
   量度	檢查內容
   遠端啟動	應該顯示API觸發的開始計數
   更新	應該顯示更新事件的計數
   結束	應該顯示結束事件的計數
   總計計數	整體已上線活動活動量度

   如果這些量度為零或不符合您的API呼叫，則Adobe與APN之間會發生傳送問題。

2. 如果Adobe顯示傳送成功，但裝置未顯示已上線的活動：

   • 檢查iOS裝置記錄檔中的即時活動錯誤。
   • 驗證應用程式在前景或背景（未終止）。
   • 確認裝置具有網路連線。
   • 在多個裝置上測試以排除裝置特定問題。
   • 確認iOS版本為16.1或更新版本。

如果您已完成所有步驟，但問題仍未解決，請聯絡Adobe客戶服務，聯絡：

必要資訊：

• 行銷活動 ID 和名稱
• 設定檔名稱空間和ID
• 來自API裝載liveActivityID
• API呼叫的時間戳記
• 熒幕擷圖：
• 行銷活動報告（傳送統計資料、錯誤原因、排除的原因）
• 設定檔事件(liveActivity.updateToken， message.feedback)
• 顯示傳遞事件的Assurance工作階段
• 完成API請求裝載
• APNs憑證詳細資料（到期、環境、套件組合ID）

1. 開啟您的Assurance工作階段。

2. 確定工作階段在裝置上開始即時活動時處於作用中狀態。

3. 篩選或搜尋具有eventType = "liveActivity.updateToken"的事件。

4. 選取事件並檢查裝載：

   • 請確認token欄位包含有效的更新Token字串。
   • 檢查liveActivityID是否與您的即時活動執行個體相符。
   • 確認activityType符合您的attributes-type。

5. 如果找不到事件：

   • SDK未產生或擷取更新Token。
   • 檢查使用者是否已授與上線活動許可權。
   • 確認已在裝置上成功啟動上線活動。
   • 確認行動SDK已正確整合以擷取更新Token。

6. 如果找到事件，請繼續進行步驟2。

1. 導覽至Journey Optimizer中的​客戶 > 設定檔。

2. 搜尋並開啟設定檔。

3. 選取​ 事件 ​標籤。

4. 尋找liveActivity.updateToken個事件。

5. 檢查事件詳細資料：

   • 驗證時間戳記是否為最近（符合上線活動開始的時間）。
   • 確認token和liveActivityID是否存在。
   • 請確定activityType正確。

6. 如果在設定檔中找不到事件：

   • 更新Token事件可能尚未內嵌至設定檔。
   • 等待5到10分鐘，然後重新檢查。
   • 如果15分鐘後仍然遺失，則可能是事件擷取問題。

7. 如果找到事件，則表示更新Token已同步。 您可以繼續進行步驟3。

1. 在您的Assurance工作階段中，執行更新或結束API呼叫。

2. 在​ 事件清單 ​中，尋找已上線活動傳遞事件（APNs推播事件）。

3. 檢查事件以指出：

   • 推播通知已傳送至APN。
   • APN的回應（成功或錯誤）。
   • 傳遞確認。

4. 如果APNs傳送事件存在：已傳送推播通知。 如果裝置仍未更新，則問題可能出在裝置端（應用程式未處理推播、網路問題等）。

5. 如果APN傳遞事件遺失：更新Token可能無法正確儲存，或與Adobe系統中的設定檔建立關聯。

6. 如果出現錯誤事件：檢查錯誤詳細資料以找出特定的失敗原因（無效的Token、拒絕的APN等）。

1. 在Journey Optimizer中開啟​API觸發的行銷活動。

2. 導覽至​ 對象 ​區段並驗證：

   • 已為行銷活動選取閱聽眾。
   • 對象ID符合您的API裝載中使用的對象ID。
   • 對象包含預期的設定檔。

3. 導覽至​ 動作 ​區段。

4. 檢查​上線活動設定：

   • 必須使用正確的套件識別碼為iOS應用程式設定設定。
   • 活動型別必須符合您API承載中的attributes-type。 例如，如果您的裝載包含"attributes-type": "AirplaneTrackingAttributes"，則行銷活動必須指定此相同的活動型別。

廣播裝載結構與單一行銷活動不同。 確認您的裝載是否遵循正確的廣播格式。

廣播的必要欄位：

{
   "campaignId": "878a11d4-b519-47bd-8313-fecfee19857b",
   "audience": {
      "id": "8c3dbdea-2957-401f-acf0-3966fba1601e"
   },
   "context": {
      "requestPayload": {
      "aps": {
         "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
         "content-available": 1,
         "timestamp": 1771829292,
         "event": "update",
         "attributes-type": "AirplaneTrackingAttributes",
         "content-state": { ... },
         "attributes": { ... }
      }
      }
   }
}

常見承載問題：

重要廣播特定欄位：

• input-push-channel:

  • 所有廣播Live活動皆需要。
  • 作為此特定廣播執行個體的唯一識別碼。
  • 對象中的所有設定檔都會收到連結至此管道的已上線活動。
  • 必須符合liveActivityData.channelID中的channelID （請參閱步驟3）。
  • 使用者端必須在Apple開發人員入口網站上為appID建立。
  • 只有為特定appID建立的頻道才能用來廣播該應用程式上的即時活動。

• audience.id:

  • 必須參考在Adobe Experience Platform中建立的有效對象區段。
  • 此對象中的所有設定檔都是上線活動的目標。
  • 必須啟用對象，並包含具有有效liveActivityPushNotificationDetails的設定檔。

一律使用最新的時間戳記：

• timestamp欄位一律為每個API呼叫的目前Unix紀元時間（以秒為單位）。
• 此要求適用於所有事件型別： start、update和end。
• 更新/結束的關鍵：使用過時的時間戳記會導致更新和結束要求失敗。
• 為每個廣播API呼叫產生新的時間戳記。

選用欄位：

• dismissal-date：自動解除的Unix紀元時間（僅與end個事件相關）
• alert：通知物件有title和body

如需完整API規格，請參閱Adobe Journey Optimizer傳訊API檔案。

確認承載欄位符合您的iOS應用程式的ActivityAttributes實作，且input-push-channel符合liveActivityData中的channelID。

1. 檢閱您的iOS ActivityAttributes定義。

您的自訂ActivityAttributes結構必須實作Adobe的LiveActivityAttributes通訊協定：

struct AirplaneTrackingAttributes: LiveActivityAttributes {
   public struct ContentState: Codable, Hashable {
      var journeyProgress: Int
   }

   // Adobe SDK requirement
   var liveActivityData: LiveActivityData

   // Your custom attributes
   var arrivalAirport: String
   var departureAirport: String
   var arrivalTerminal: String
}

1. 將iOS欄位對應至廣播API裝載。

對於所有事件，同時包含attributes和content-state：

      {
      "aps": {
         "input-push-channel": "FEt0NgvLEfEAAOqA6AXdIQ==",
         "event": "start",
         "timestamp": 1771829292,
         "attributes-type": "AirplaneTrackingAttributes",
         "content-state": {
         "journeyProgress": 0
         },
         "attributes": {
         "arrivalAirport": "DEL",
         "departureAirport": "MUM",
         "arrivalTerminal": "T1",
         "liveActivityData": {
            "channelID": "FEt0NgvLEfEAAOqA6AXdIQ=="
         }
         }
      }
      }

嚴重： input-push-channel必須符合channelID

• aps根目錄中的input-push-channel值必須與liveActivityData中的channelID完全相符。
• 在上述範例中，兩個值均為"FEt0NgvLEfEAAOqA6AXdIQ=="。
• 此比對會將廣播例項連結至即時活動資料。
• 不相符會導致傳遞失敗。

關鍵驗證點：

• 包含所有事件型別content-state中的所有ContentState欄位。
• 僅針對開始事件在attributes中包含所有自訂LiveActivityAttributes欄位。
• 對於開始事件，liveActivityData.channelID必須符合input-push-channel。
• 欄位名稱會區分大小寫，且必須完全相符。
• 資料型別必須相符（字串、Int、Bool、巢狀物件等）。
• 對於更新/結束事件，請使用與原始開始事件相同的input-push-channel。

常見錯誤：

使用Assurance驗證API執行和裝載傳送：

1. 在屬於閱聽眾的測試裝置上開啟Assurance工作階段。

2. 執行廣播API呼叫。

3. 在​ 事件清單 ​中尋找：

   • 行銷活動執行事件。
   • 已上線的活動傳送活動。
   • 指示裝載驗證失敗的錯誤事件。

4. 檢查事件裝載以確認：

   • 已正確處理承載。
   • input-push-channel已存在。
   • 沒有發生驗證錯誤。
   • 已將上線活動傳送至對象成員的APN。

首先，確認應接收上線活動的設定檔是否實際屬於對象。

1. 導覽至Adobe Experience Platform中的​對象。

2. 使用行銷活動中的audience.id搜尋並開啟對象。

3. 按一下​ 瀏覽 ​或​ 範例設定檔 ​以檢視對象成員。

4. 使用名稱空間和身分值搜尋您的測試設定檔。

5. 如果在對象中找不到設定檔：

   • 設定檔不符合對象條件或區段規則。
   • 檢閱對象定義以瞭解成員資格要求。
   • 更新設定檔資料或對象定義，以包含設定檔。
   • 等待對象評估完成（請參閱步驟2）。

6. 如果在對象中找到設定檔：​請繼續執行步驟2以檢查資料的時效性。

識別對象是使用批次還是串流評估，因為這決定了資料的時效性。

1. 在​ 對象詳細資料 ​頁面上，檢查​評估方法：

   • 批次：依排程每日評估一次。
   • 串流：在發生設定檔更新時即時評估。
   • Edge：在邊緣位置即時評估。

根據評估方法，遵循適當的疑難排解步驟：

如果對象使用批次評估：

1. 瞭解批次對象限制：

   • 批次對象每天評估一次（通常隔夜）。
   • 對象快照可能長達24小時之前。
   • 如果設定檔最近註冊了即時活動權杖，這些權杖可能不會在目前的快照中。
   • 在下次批次評估前不會反映設定檔的更新。

2. 檢查上次評估發生的時間：

   • 在對象詳細資訊中，尋找​ 上次評估 ​時間戳記。
   • 如果設定檔的liveActivityPushNotificationDetails在此時間戳記之後更新，則對象具有過時資料。

3. 解析過時資料：

   1. 選項1：等候排定的批次評估

      • 下一個批次評估將包含更新的設定檔資料。
      • 此作業每天自動進行一次。
      • 最適合非緊急情況。

   2. 選項2：觸發隨選對象評估

      1. 導覽至AEP中的​對象。
      2. 選取您的客群。
      3. 按一下​ 立即評估 ​或​依需求啟用。
      4. 等候評估完成（根據對象人數而定，這可能需要幾分鐘到幾小時的時間）。
      5. 確認設定檔現在已更新對象快照中的資料。
      6. 重試廣播API呼叫。

如果對象使用串流評估：

1. 瞭解串流對象行為：

   • 當設定檔更新發生時，串流對象會即時評估。
   • 新設定檔：如果設定檔符合區段條件，建立後即符合資格。
   • 已更新設定檔：更新後不久即符合或取消資格。
   • 現有未變更的設定檔：除非進行更新，否則不會重新評估。

2. 識別問題：

   • 如果設定檔已存在並符合區段標準，但該設定檔未發生更新，則可能無法將其新增到新建立的串流受眾。
   • 設定檔必須接收更新（任何屬性變更），才能觸發重新評估。

3. 解決問題：

   • 對於新設定檔：如果符合條件，它們會自動符合條件。 不需要採取任何動作。

   • 對於沒有最近更新的現有設定檔：

     • 對設定檔進行微幅更新（例如，更新時間戳記欄位）。
     • 這會觸發串流評估，並將設定檔新增至對象。
     • 替代方案：針對現有設定檔使用批次對象或邊緣對象。

This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.

For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.

• TL;DR: This page provides a systematic approach to diagnose why Live activities fail to appear, update, or end even when the API returns HTTP 200, covering profile and token, campaign configuration, payload, and delivery issues for unitary and broadcast use cases.

Intents:

• Distinguish the unitary (API-triggered Transactional) and broadcast (API-triggered Marketing) debugging paths
• Verify profile existence and Live activity push token sync (Scenario 1)
• Validate campaign surface, Activity type, and API payload structure (Scenario 2)
• Analyze delivery failures via campaign reports and message.feedback events (Scenario 3)
• Diagnose unsynced update tokens (Scenario 4) and check execution status via the GET Message Execution API (Scenario 5)
• Troubleshoot broadcast payload and audience-freshness issues (Scenarios 6 and 7) and query the feedback dataset directly (Advanced)

Glossary:

• Push-to-start token: An APNs token generated by iOS 17+ that allows AJO to remotely start a Live activity without the app being open; registered by the mobile SDK and stored on the AEP profile (product-specific)
• Update token: A per-instance APNs token generated when a Live activity starts; required for unitary update and end events (product-specific)
• input-push-channel: A unique channel identifier created on the Apple Developer Portal for broadcast Live activities; acts as the broadcast update token (product-specific)
• liveActivityData: A required property on the Adobe SDK LiveActivityAttributes protocol; contains liveActivityID for unitary or channelID for broadcast (product-specific)
• Broadcast Channel ID: The value of input-push-channel; must exactly match liveActivityData.channelID (product-specific)
• attributeType / attributes-type: The name of the Swift ActivityAttributes struct; stored as attributeType (camelCase) on the profile and sent as attributes-type (hyphenated) in APS JSON — the same value in different representations (product-specific)
• liveActivityPushNotificationDetails: The AEP profile attribute that stores a device’s push-to-start token, appId, platform, and attributeType (product-specific)
• APS payload: The JSON structure sent under context.requestPayload.aps, containing the event, content-state, attributes, and control fields (product-specific)
• Assurance: Adobe Experience Platform Assurance, a real-time debugging tool for connected test devices; not available for production end-user devices (product-specific)

Guardrails:

• Live activities can only be triggered and managed through API Triggered Campaigns.
• The High Throughput option must not be enabled, since it is incompatible with Live activity.
• Assurance sessions are for test and QA devices only; end-user production devices are not connected to Assurance.
• Requirements: a physical iOS device on iOS 16.1 or later; the Xcode Simulator supports local start only (remote push via APNs is not supported on Simulator); remote start from Assurance requires iOS 17.1 or later, a valid push-to-start token, and a valid channel configuration; Adobe Experience Platform Mobile SDK 5.11.0 or later.
• Batch audiences may be up to 24 hours stale (batch evaluation, once daily); this audience-freshness risk is not applicable to unitary use cases.
• The first time a Live activity starts on a device, iOS shows a one-time permission prompt; the user must tap “Allow” for update tokens to be generated and synced.
• input-push-channel must exactly match liveActivityData.channelID; a mismatch causes delivery failures.
• A feedbackStatus of sent confirms hand-off to APNs only, not device rendering; device-side failures and the 8-hour Live activity duration limit are not observable from the dataset.

Terminology:

• Canonical name: API Triggered Campaign — Acronym: n/a — variants: API-triggered Transactional (unitary), API-triggered Marketing (broadcast)
• Synonyms: “attributeType” = “attributes-type” (the same value; camelCase on the profile, hyphenated in APS JSON)
• Synonyms: “Broadcast Channel ID” = “input-push-channel”
• Do not confuse: “Push-to-start token” (starts a Live activity, per profile) ≠ “Update token” (updates or ends a unitary instance, per instance)
• Do not confuse: “Unitary” (API-triggered Transactional, individual profile) ≠ “Broadcast” (API-triggered Marketing, audience segment)
• Do not confuse: execution statuses “PENDING” ≠ “INPROGRESS” ≠ “COMPLETED” ≠ “FAILED”
• Do not confuse: feedbackStatus “sent” ≠ “error” ≠ “exclude” ≠ “delay”
• Do not confuse: la_event value “remotestart” (recorded in the dataset for initial delivery) ≠ “start” (the event field value in the payload)

FAQ:

• Q: Why does the API return 200 OK but the Live activity does not appear? — A 200 confirms the request was accepted, but delivery can still fail at the profile/token, campaign configuration, payload, or APNs stage; work through Scenarios 1 to 3.
• Q: Can I use Assurance for production end-user devices? — No; Assurance sessions are for test and QA devices only. For production diagnostics, use the dataset queries.
• Q: Why do update and end calls fail after the Live activity started? — The per-instance update token may not be synced; the user must have tapped “Allow” on the one-time permission prompt for update tokens to be generated (Scenario 4).
• Q: How do I check execution status programmatically? — Use the GET Message Execution API; for unitary executions the executionId is prefixed with HUOC-, and the status field returns PENDING, INPROGRESS, COMPLETED, or FAILED.
• Q: What does a feedbackStatus of sent mean? — It confirms Journey Optimizer successfully handed the notification to APNs; it does not confirm that the Live activity was rendered on the device.
• Q: Why are some audience members not receiving a broadcast? — The profile may not be in the audience, or a batch audience snapshot may be up to 24 hours stale; trigger on-demand evaluation or ensure a streaming update occurs (Scenario 7).