什麼是 Webhook？

已發表: 2018-06-23

它發生在我們所有人身上。 你在開會，有人拋出了一個感覺很熟悉、聽起來很熟悉的術語——但如果你被放在現場，當著你所有的同齡人的面被問到它的真正含義，你就會被困住直到會議結束或你驚慌失措，拉起火警，然後流著淚逃離大樓。

隨著營銷和客戶參與變得越來越受數據驅動並依賴於技術來發揮其全​​部潛力，感覺這些術語越來越多：SDK、PII 和 API。 今天，我們將快速看一下這些需要知道的術語中聽起來更令人回味的一個，即不起眼的“webhook”。

那麼，什麼是 webhook？

從本質上講，Webhook 是在預選事件之後發生的從一個應用程序或服務到另一個應用程序或服務的通信。 Webhook 是一種 HTTP 回調，有時被稱為“反向 API”，儘管這並不能說明 Webhook 是什麼以及它們是如何工作的。

好的，但您能否澄清一下 webhook 是什麼以及它們是如何工作的？

就像這樣：在互聯網時代，沒有數字系統是孤島（或者，如果是，它不應該是孤島）。 斷開連接的系統會導致斷開連接的用戶體驗，而關心與客戶建立可持續關係的品牌需要通過不同的技術進行有效溝通的方法。

Webhook 就是其中一種方式。

從本質上講，Webhook 是一種基於事件的方法，兩個獨立的系統可以根據實時傳輸的數據採取有效的行動。 應用程序之間的消息不是“支持”的數字版本，而是重要信息的傳遞，這些信息需要為接收系統提供一組關於何時以及如何執行特定任務的指令。 正因為如此，webhook 可以為營銷人員提供對數據和程序化功能的更動態和靈活的訪問，並讓他們能夠設置觸發的工作流和客戶旅程，從而簡化流程。

等等，是什麼讓 webhook 與 API 不同？

API 和 webhook 都用於支持不同數字系統之間的通信，但這些通信是如何進行的，以及它們各自最適合的情況往往略有不同。

當您利用 API 在系統之間進行通信時，它往往是一個調用和響應操作：初始系統對接收系統的 API 端點進行 API 調用，並獲得響應（以數據、圖像或其他數字資產）。 使用 webhook，通信功能更像是一個指令列表——第一個系統告訴第二個系統做什麼（例如，向客戶的航空公司忠誠度帳戶添加 10 個忠誠度積分）以及它應該在什麼時候做（例如當該客戶完成第五次航班預訂時）。 Webhook 的“如果這樣，那麼那樣”方面為它們提供了極大的靈活性，並使它們成為填補客戶品牌體驗空白的強大工具。

在最好的情況下，webhook 可以成為支持自動化營銷實踐的強大方式。 只要有能夠針對該事件採取行動的事件和服務，營銷人員甚至可以使用非應用程序、非網站事件來推動和影響客戶的品牌體驗。 Webhook 可以建立緊密的連接（通常在 API 集成不可行或成本太高的情況下），並且可以幫助確保對您的營銷有價值的技術在最有意義的時間和地點實際上彼此同步.

嗯，舉個例子怎麼樣？

Quizlet 使學生能夠通過抽認卡、測試和遊戲來複習信息。 通過五種學習模式，在線平台希望引導用戶查看他們尚未使用的不同模式和遊戲。 但是，在收集有效開展活動所需的高度細微的數據時，Quizlet 遇到了兩個問題：準確性和數據使用情況。 他們希望為每個用戶的模式使用情況保留全方位的歷史數據，並有效地收集新信息，但在不收集超出他們需要的數據的情況下努力確保數據準確性。

Quizlet 的工程團隊在確定下一步行動時採取了敏捷、協作的方法，向他們的營銷團隊尋求進一步幫助以優化數據收集。 通過相互交流想法，Quizlet 開始使用 webhook 來有效地解決他們的數據問題。

每次 Quizlet 用戶在應用程序或網絡上選擇學習模式（僅限登錄狀態）時，Braze SDK 都會收集該事件並通過 Rest API 發送到 Braze。 該事件觸發了一個基於操作的活動，如果滿足以下條件，該活動又會通過 Liquid 向 Braze Rest API 用戶/跟踪端點發送一個帶有 JSON 對象的 Webhook。 七種學習模式中的每一種都設置了自己的 webhook，並且不允許重新獲得資格，以確保不會為多次使用相同模式的人創建新數據點 - 每個用戶配置文件最多使用七個數據點代表他們可以使用的七種可能的學習模式。

是否有關於何時使用 webhook 的指南？

嗯，是的——當然有。

要記住的一個重要問題：時間就是金錢。 或者，至少，您擁有的客戶數據的價值在它生成的那一刻開始下降——這意味著管理和處理您目前擁有的數據是您的客戶參與有效性的關鍵因素努力。

Webhook 可以成為實現這一目標的關鍵部分。 除了支持通過 Facebook messenger、Line 或 Kik 等 OTT 消息平台發送客戶外展服務外，webhook 還可以成為確保用戶無縫執行基本操作的關鍵工具。

在 Braze，我們從客戶那裡看到的一種常見做法是在用戶執行特定操作時使用 webhook 向他們發送折扣或積分。 借助 Braze 基於行動的參與，品牌可以列出需要提供折扣的觸發事件類型，然後，一旦 Braze 平台收到用戶執行相關事件的通知（可能正在查看某個產品或在手機遊戲中擊敗某個級別或放棄數字購物車），可以將 webhook 發送到客戶端的後端或 Braze API 以處理用戶配置文件更新，自動將適當的信用實時添加到該個人的帳戶中。

請注意，實現這種體驗不需要工程、不需要拉列表、不需要標記附加信息——只需在相關係統之間初始設置 webhook。 當您希望確保有凝聚力的客戶體驗而又不讓您的工程團隊全天候為您提供支持時，這是一個巨大的勝利。

說得通。 還有其他大用例嗎？

還經常看到用於向其他技術或服務器更新發生在其特定權限之外的關鍵用戶操作的 webhook。 例如，如果用戶在電子郵件上單擊取消訂閱（這意味著您不再合法地允許在該頻道中向他們發送消息），那麼設置一個 webhook 來提醒和 ping 其他系統是明智的 - 例如分析數據庫或CRM — 使用相同的信息，確保全面了解用戶的行為。

除此之外，考慮利用 webhook 的基本靈活性——這是一種用於支持廣泛的行動和創造性方法來滿足客戶參與需求的工具。 例如，您不會看到很多客戶參與平台將直郵作為渠道添加，但通過 webhook，品牌可以利用這些平台對有針對性、分段的外展的支持，通過直接向客戶發送明信片或其他直郵Lob 等郵件服務。 通過採用這種靈活性，可以使用 webhook 將您的營銷策略推向新的創新方向，而無需重大的新費用或工程支持。 這是一件大事。

還要別的嗎？

不要忽視是什麼讓 webhook 與眾不同。 與 API 不同，它們不需要初始請求即可運行，而且由於它們不需要輪詢和操作數據庫類型，因此 webhook 可以在新信息可用並觸發操作時真正實時運行。 這些特性使 webhook 可以緊密連接系統，即使您正在使用的技術生態系統沒有像您希望的那樣集成在一起。

當您使用的系統不是為協同工作而構建時，營銷人員經常會發現自己處於由於不完整的上下文或延遲的信息而不得不應付的位置，從而導致其品牌客戶的品牌體驗低於標准或令人沮喪。 除了 API 和 SDK，Webhook 還使營銷人員能夠實時設置應用程序或網站上發生的任何事件並觸發操作。 這可以是變革性的。 這種立即採取適當行動的能力對於品牌與其客戶之間的有效即時互動至關重要，並且可以使 webhook 成為與電子郵件或推送通知等客戶互動的重要渠道。

因此，藉此機會看看 webhook 是否可以幫助您更有效地連接您的系統，並發送必要的數據來支持您夢寐以求的卓越品牌體驗。 您的客戶會感謝您的。