詢問開發人員：myDNA 高級軟件開發人員 Elliott Millar 關於集成 Braze、利用 AWS EventBridge 和優先項目前研究

開發人員在確保我們的客戶能夠順利集成和利用 Braze 平台來支持他們的營銷工作方面發揮著關鍵作用。 為了詳細了解開發人員在 Braze 方面所做的工作以及他們的體驗如何，我與領先的基因健康品牌 myDNA 的高級軟件開發人員 Elliott Millar 坐了下來。 這是他不得不說的*：

你能告訴我們一些關於 myDNA 和你在那裡的角色嗎？

myDNA 是一家位於澳大利亞墨爾本的基因健康公司。 我們根據人們的基因結果為他們提供建議。 我們的客戶只需將他們的面頰拭子發送給我們，我們就會處理他們的 DNA 結果，並為他們提供 DNA 見解和建議，以處理他們的遺傳學問題。

myDNA 從藥物基因組學產品開始，它可以幫助醫療保健從業者更準確地為患者開藥，這對許多人的生活產生了重大影響。 現在有很多豐富的 DNA 研究表明遺傳學如何影響我們的健康方面，例如飲食、運動、睡眠和皮膚老化——僅舉幾例——所以 myDNA 現在也有一個通用的健康產品； 該產品通過我們的 myDNA Unlocked 應用程序為人們提供 DNA 見解和建議，以及基於他們的基因結果的個性化膳食和健身計劃。 這就是 Braze 的用武之地。我們使用 Braze 通過應用程序向我們的客戶提供這種個性化的內容，以幫助他們改變行為並實現他們的健康目標。

我是 myDNA 的高級軟件開發人員。 自 10 月以來，我一直擔任該職位，我領導的第一個項目是將 Braze 集成到 myDNA Unlocked 中。 我是一名全棧開發人員，所以我可以處理我們軟件套件中的幾乎任何事情，無論是訪問 SQL 數據庫、設置我們的 .net 後端、使用 React Native 做事，還是處理 Objective-C。 這並不重要——把我放在任何地方。

你提到集成 Braze 是你在 myDNA 的第一個項目之一——你能談談那個項目的時間表嗎？

嗯，我是在 11 月拿到的，這個過程最終花了三個月多一點的時間，不包括寒假。 一旦項目在我手中，這就開始了。 在我參與之前，有一個入職流程，他們致力於設置使用 Braze 收集哪些自定義事件和自定義屬性，所以當我們開始時，所有這些東西都會準備好。 我想那是在我開始這個項目之前大約六到八週。

在開始 Braze 集成項目之前，您是否進行過任何研究？

我做了很多瘋狂的研究。 我在 LAB [Learning at Braze] 上觀看了大約 20 小時的視頻，並閱讀瞭如此多的文檔頁面——數量驚人——因為我需要了解有關這款軟件的所有信息； 我怎麼知道它是否有效，或者它應該做什麼？ 我還需要從我們的客戶體驗 (CX) 團隊的角度了解一切，因為他們將主要擁有 Braze。 我們將如何實際使用它？ 它如何與 iOS 和 Android 配合使用？ 一開始，我並不確定誰將參與這個項目，如果我正在領導一個項目，我需要了解正在發生的一切，這樣我才能分配工作，弄清楚一切，然後得到適當的估計。

因此，我查看了有關 Liquid 個性化、連接內容、自定義屬性和自定義事件、如何集成、什麼是 IP 升溫以及如何進行、如何處理推送啟動等方面的教程。 學習了很多關於互聯內容需要注意的不同事項，例如破壞您自己的 API 的風險，或者您應該如何使用增量，而不是僅僅因為您的系統中發生了一些事情而咀嚼 4.5 億個數據點。 在文檔中，從如何設置 webhook 到 Braze API 和 SDK 的工作方式，應有盡有。

完成後，我在 Confluence 中創建了一個部分，基本上將我從 Braze 獲得的所有這些信息過濾為其他開發人員的一個很好的消耗格式。 這樣一來，即使他們需要在 24 小時內趕上進度，他們需要的所有信息都集中在一個中心位置。 根據我所做的所有研究，我總是構建一個龐大的文檔，以圖解我們與 Braze 的集成。 所以到了做這件事的時候，我覺得已經做好了準備。

你能談談為什麼決定整合 Braze 嗎？

有了 Braze，商業案例和一切都在我加入 myDNA 之前很久就完成了。 但從我的角度來看，讓我們的 CX 團隊掌權並真正允許他們直接與客戶互動，而無需任何開發人員互動或乾預，這確實有很大的好處。 我們的舊方法需要大量的開發工作來實現和允許新功能發布，這使得 CX 團隊更難控制向用戶發布的交互和內容。

作為該過程的一部分，我們基本上發現，在利用 Braze 時，我們必須弄清楚三個主要接觸點：

• 將 SDK 安裝到我們的移動應用程序中以支持 CX 團隊對消息傳遞的控制

• 通過將 Braze 連接到 AWS EventBridge 來管理快速移動、時間敏感的數據

• 通過將 Braze 與 Hightouch、FiveTran 和其他技術結合使用來處理不太緊急的數據

您能否帶我們了解第一個接觸點，即與 SDK 和消息傳遞相關的接觸點？

好吧，在我們將 Braze 集成到我們的移動應用程序之前，我們一直在使用 Expo，這是我們用來包裝我們的應用程序並將其部署到 Apple 的 App Store 和 Google Play 的工具。 Braze 不支持 Expo，因此在我們與 Braze 集成之前，我們必須退出 Expo 並開始使用裸工作流。 這意味著我們必須處理大量的技術債務，比如建立一個新的構建管道。 另外，在我們的例子中，我們必須集成 iOS 的 Objective-C 和 Android 的 Java，以及 React Native，以便讓一切正常運行。 這是一項很大的工作，但我們內部有一個很棒的團隊來提供幫助並實現這一切。 [注意：Braze 最近更新了我們的 iOS 和 Android SDK 以分別利用 Swift 和 Kotlin。]

我們部署了移動應用程序，一切正常，沒有戲劇性，這很棒。 一旦我們讓 Braze SDK 在我們的移動應用程序中運行，這意味著我們可以使用它來捕獲其中發生的所有用戶參與。 因此，當用戶與系統交互時，它會觸發自定義事件，並且它顯然也接受幫助來通知和支持 CX 團隊正在使用的所有不同消息傳遞渠道，如推送通知、應用內消息、內容卡等那些好東西。

那時，我們能夠將洞察後的旅程轉移到 Braze。 這就是我們所說的在我們的一位客戶獲得 DNA 結果後發生的流程。 我們希望我們的 CX 團隊能夠與這些客戶進行互動，當他們在膳食計劃、鍛煉計劃等所有方面做得很好時，向他們表示祝賀。 CX 團隊正在構建一些令人驚嘆的畫布，以啟動跨推送、應用內消息、內容卡和電子郵件的不同用戶旅程。

起初，我們確實在推送通知方面遇到了一些問題，與世博會彈出有關，但我們設法想出了一個非常棒的方法來使用 AWS EventBridge 解決這些問題。 因此，我們沒有通過 Expo 觸發推送通知，而是通過管道傳輸到 EventBridge 管道中，所以當 Braze 運行時，嘿，我有一個自定義事件要與我們的推送一起發送，消息會以動態內容髮送出去。 這繞過了與 Expo 相關的問題，因為一旦用戶有相關更新，Braze 就會拿起推送令牌，然後他們就走了。 但在將這些洞察前和洞察後的旅程遷移到 Braze 之前，一切都能夠像通過 CRM 一樣繼續工作。

說到 EventBridge，你能談談你是如何將它與 Braze 結合使用的嗎？

好吧，這一切都始於我思考在 Braze 方面我們需要收集哪些類型的數據。 本質上，我們必須弄清楚兩個不同的數據子集。 需要盡快進入 Braze 的真正關鍵的東西是您及時、快速移動的數據。 另一方面，還有其他數據確實不是時間敏感的，但仍需要移植到 Braze 中。 對於緩慢移動的東西，它可以通過我們的 Hightouch 數據同步，我稍後會介紹。 但對於快速移動的數據，我們決定利用 EventBridge。

什麼是快速移動的數據？ 好吧，當有人註冊我們的產品時，我們需要他們盡快收到來自 Braze 的歡迎電子郵件。 我們有一個註冊步驟函數，它處理可以為正在註冊的新用戶激活的不同事物的整個管道。 作為其中的一部分，當在我們的 CRM 中設置用戶時，我們需要將所有信息傳遞給 Braze，以便用戶可以開始接收內容，例如歡迎電子郵件。 所以我們必須想出一種方法來傳遞這些數據。

事實證明，EventBridge 非常適合該用例。 我們創建了一個託管該 AWS 架構的新事件存儲庫，並且因為我們使用 AWS CDK [雲開發工具包] 進行所有設置和部署，所以這樣做非常容易。 我們剛剛在 AWS 中創建了一個 myDNA 事件總線，我們說過如果您想訂閱它，您所要做的就是在您的 CDK 中為您正在運行的特定服務編寫一個新規則，將其附加到該總線，然後對於任何撞到該總線的東西，我們將進行標準模式映射。

通過這種方法，我們運行了一個 Braze 服務，它說，嘿，我想監聽關鍵的用戶事件，比如訂單更新、客戶註冊和一些其他特定的事情，我希望這些數據傳遞給 Braze——但是沒有將所有這些不同的微服務綁定到 Braze。 EventBridge 使這成為可能。 另外，我們有一條雙向街道。 因此，無論我們是將數據移動到 Braze 還是從 Braze 觸發 webhook，它們都可以通過主要的 EventBridge 架構。

我們有一個 Braze webhook 使用的特定 Braze 入口點，它只是向 EventBridge 發送一個事件並說，嘿，我想用這些參數為這個用戶啟動這個特定事件。 然後無論我們坐在那裡的服務是什麼，都可以收聽，然後訂閱，然後啟動他們想要的。

所以現在我們已經建立了這個很棒的架構，我們可以將東西發送到與其他一切分離的 Braze。 所以我們的註冊步驟函數會觸發並說，嘿，我創建了一個新用戶，我們的 Braze 服務將收到該用戶。 它運行一個階躍函數，說，嘿，我要去做 XYZ，然後把它發送給 Braze。 作為其中的一部分，我們有一個回調模式——畢竟，如果 Braze 設置失敗，這是一個嚴重的失敗，因為如果沒有 Braze 創建該用戶，我們就無法成功完成註冊。 這樣，如果 Braze 任務失敗，則整體註冊的 step 函數失敗。 這一切都由 AWS 在後台處理，這很棒。

我沒有提到的是我們需要一個 Braze 的入口點。 我們希望將密鑰交給 CX 團隊，以便他們可以控制在我們的應用程序中觸發的操作。 其中一項行動是發布見解。 那段旅程與我們的 CRM 密切相關——基本上，這是我們的參與活動，在這一天發布此見解，三天后發布此見解，等等。我們希望改變該旅程，讓用戶更有活力.

為了在 Braze 活動或 Canvas 中實現這一點，我們需要能夠向用戶展示個人見解，這意味著要找到一種方法來擊中我們服務中的某個端點以輸入正確的信息。 值得慶幸的是，Braze 有兩個很棒的功能可以實現這一目標——webhook 和 Connected Content。

在集成過程中，我們四處塗鴉，試圖弄清楚如何去做。 我偶然發現了這個來自 AWS 的視頻，這實際上是我們的確切用例——如何從外部服務觸發 Webhook，它會觸發 EventBridge 的事件。 它最終成為一個分步視頻教程，從字面上引導您了解如何創建 API 網關並設置正確的映射模板。 如果您遵循它，這種方法將讓您獲取主體輸入，將其映射到 EventBridge 詳細信息對象，然後將其發送到您的總線，僅此而已； 它現在通過 API 密鑰得到了強有力的保護。 您現在有一個入口點，任何人都可以使用該身份驗證以您想要的格式發送數據，並且它將觸發您的事件總線。 我們就像，“這太完美了。”

關於接觸點三以及您如何使用 Braze 和您的 Hightouch 數據同步，您能告訴我們什麼？

第三個接觸點超級簡單。 它只是使用 Hightouch、Fivetran 和其他一些技術從其他位置收集數據，將其轉換為與數據倉庫兼容的良好格式，然後持續通過管道將其導入 Braze。

這確實適用於我之前談到的緩慢移動的數據； 也就是說，要么擁有很重要但隨著時間的推移不會變得不那麼重要的東西，或者額外的元數據——你知道，比如用戶的年齡組——在某個時候會被使用，但現在不需要。 因為信息不緊急，所以我們設置了它，所以同步開始並只是詢問，基本上，有什麼變化嗎？ 是的？ 太好了，這裡是三角洲。 不？ 然後什麼都不做。

最後的想法

有興趣深入挖掘 Braze 平台的技術方面嗎？ 在Building Braze 產品博客上直接從我們的產品、設計和工程 (PDE) 組織獲取獨家故事、學習和見解，並通過Braze 文檔探索我們產品的細節。

*此轉換已針對長度和清晰度進行了編輯。