ข้ามไปยังเนื้อหา

Webhook

Webhook ช่วยให้คุณสามารถส่งข้อมูล Journey ไปยังบริการภายนอก เช่น ระบบวิเคราะห์, ระบบ CRM และเครื่องมือทางการตลาด คุณสามารถ:

  • แจ้งเตือนระบบภายนอกเมื่อลูกค้าดำเนินการบางอย่างใน Journey
  • ส่งข้อมูลลูกค้าไปยังเครื่องมือวิเคราะห์
  • ทริกเกอร์อีเมล, SMS หรือ WhatsApp ของบุคคลที่สามในเหตุการณ์ Journey ที่เฉพาะเจาะจง

วิธีตั้งค่าองค์ประกอบ Webhook

Anchor link to

เพิ่มองค์ประกอบ Webhook

Anchor link to

ลากและวางองค์ประกอบ Webhook ไปยังผืนผ้าใบ วาง Webhook ที่ใดก็ได้ที่คุณต้องการ โดยคำนึงถึงข้อมูล Journey ที่คุณจะส่งไปยังบริการของบุคคลที่สาม

ผืนผ้าใบ Customer Journey พร้อมขั้นตอน Webhook ของ Amplitude ที่ถูกเลือกหลังองค์ประกอบการเข้าและรอ

ตั้งชื่อขั้นตอน Webhook และระบุ URL และประเภทของคำขอ

Anchor link to

ในช่อง STEP NAME ให้ป้อนชื่อสำหรับ Webhook อาจสะดวกที่จะตั้งชื่อ Webhook ตามบริการที่ส่งข้อมูลไปหรือตามกรณีการใช้งาน

ถัดไป ในช่อง URL ให้ระบุ URL ของคำขอที่จะส่งข้อมูลไป ถัดจากช่อง URL ให้เลือกประเภทคำขอจากเมนูแบบเลื่อนลง REQUEST TYPE: GET หรือ POST

อินเทอร์เฟซการกำหนดค่า Webhook แสดงช่อง URL และเมนูแบบเลื่อนลง REQUEST TYPE สำหรับเลือกเมธอด GET หรือ POST

กำหนดค่าส่วนหัว (Headers)

Anchor link to

ในส่วน HEADERS ให้ตั้งค่าประเภทเนื้อหา

โดยค่าเริ่มต้น ประเภทเนื้อหาคือ application/json หากบริการที่คุณส่ง Webhook ไปต้องการประเภทเนื้อหาอื่น ให้ป้อนประเภทที่เหมาะสมในค่าส่วนหัว Content-Type

ตัวอย่างของประเภทเนื้อหาคือ:

  • x-www-form-urlencoded
  • text/plain
  • text/xml

เพิ่มส่วนหัวเพิ่มเติมหากจำเป็นโดยคลิก + ADD HEADER คุณสามารถลบส่วนหัวใดๆ ได้โดยคลิกไอคอน ‘x’ ที่อยู่ถัดจากส่วนหัวนั้น

เพิ่มส่วนหัวการยืนยันตัวตนใดๆ ที่ endpoint ของคุณต้องการ ตัวอย่างเช่น:

  • Authorization: Bearer <token>
  • X-Api-Key: <key>
  • Authorization: Basic <base64(user:pass)>

รองรับเฉพาะข้อมูลลับแบบคงที่ในส่วนหัวเท่านั้น ไม่รองรับกระบวนการแลกเปลี่ยนโทเค็น OAuth2, mTLS และการลงนามคำขอบนฝั่ง Pushwoosh คุณยังสามารถจำกัด endpoint ให้รับเฉพาะที่อยู่ IP ของ Pushwoosh แทนหรือเพิ่มเติมจากข้อมูลลับในส่วนหัวได้ ดู ที่อยู่ IP ของ Pushwoosh

สำหรับการยืนยันตัวตนแบบ HTTP Basic โดยเฉพาะ ให้ทำดังนี้:

  1. เปิดโปรแกรมแก้ไขข้อความธรรมดาและพิมพ์ชื่อผู้ใช้และรหัสผ่านของคุณโดยไม่มีเว้นวรรค คั่นด้วยเครื่องหมายทวิภาค ตัวอย่างเช่น: <username>:<password>
  2. เข้ารหัสสตริงนี้เป็น Base64
  3. คัดลอกสตริง Base64 ที่ได้ (ตัวอย่างเช่น <base64-encoded-string>)
  4. ในการตั้งค่า Webhook ให้เพิ่มส่วนหัว Authorization ด้วยค่า: Basic <base64-encoded-string> ตรวจสอบให้แน่ใจว่ามีเว้นวรรคหลังคำว่า “Basic”
ตัวอย่างส่วนหัว Authorization สำหรับการยืนยันตัวตนแบบ Basic ในการตั้งค่า Webhook แสดงส่วนหัว Content-Type และ Authorization

ทำเครื่องหมายค่าส่วนหัวเป็นความลับ

Anchor link to

คลิกไอคอนรูปตาถัดจากค่าของส่วนหัวเพื่อปิดบังค่า Pushwoosh จะซ่อนค่านั้นในทุกที่ที่อาจออกจากบริการ: ใน UI, ในการตอบกลับของ API และในประวัติเวอร์ชันของ Journey

รายการส่วนหัวของ Webhook ที่มีค่า Authorization ที่ถูกปิดบังและไอคอนรูปตาที่ปิดใช้งานถัดจากค่า Content-Type ที่ไม่ได้ปิดบังพร้อมไอคอนรูปตาที่ใช้งานอยู่
  • การปิดบังอัตโนมัติ ส่วนหัวที่มีชื่อคล้ายข้อมูลประจำตัวจะถูกปิดบังโดยอัตโนมัติ แม้ว่าคุณจะไม่เคยคลิกไอคอนรูปตาก็ตาม ซึ่งรวมถึง Authorization, Proxy-Authorization, Cookie, Set-Cookie และชื่อใดๆ ที่มี token, secret, password, credential, auth หรือ api-key/api_key/apikey (มีขีดกลาง, ขีดล่าง หรือไม่มีตัวคั่น)
  • เปลี่ยนค่าที่ถูกปิดบัง คลิกเข้าไปในช่องที่แสดง •••••••• และพิมพ์ค่าใหม่ ไม่มีปุ่มสำหรับเปิดเผยค่าที่เก็บไว้ ไอคอนรูปตาจะยังคงล็อกอยู่ขณะที่การปิดบังแสดงอยู่ หากต้องการลบแฟล็กความลับออกจากส่วนหัว ให้พิมพ์ค่าใหม่ก่อน แล้วจึงคลิกไอคอน
  • เปลี่ยนชื่อส่วนหัวที่ถูกปิดบัง การเปลี่ยนชื่อส่วนหัวที่ค่าปัจจุบันแสดงเป็นการปิดบังจะล้างค่านั้น ป้อนค่าใหม่อีกครั้งภายใต้ชื่อใหม่ การเปลี่ยนชื่อส่วนหัวที่ปัจจุบันมีค่าที่คุณเพิ่งพิมพ์จะยังคงค่านั้นไว้

เพิ่มเนื้อหาคำขอ JSON

Anchor link to

ในส่วน DATA ให้ป้อนเนื้อหาคำขอ JSON ของคุณ ตรวจสอบให้แน่ใจว่าเนื้อหาคำขออยู่ในรูปแบบ JSON ที่ถูกต้อง

ตัวอย่าง:

{
"hwid": "{{device:hwid}}"
}

ใช้ข้อมูลไดนามิกและมาโคร

Anchor link to

แผง DATA BUILDER ช่วยให้คุณสามารถแทรกข้อมูลไดนามิก (เช่น ข้อมูลผู้ใช้, อุปกรณ์, แท็ก หรือเหตุการณ์) ลงในเนื้อหาคำขอ JSON ของคุณได้โดยตรง ด้วยข้อมูลไดนามิก คุณสามารถรวมค่าเฉพาะสำหรับผู้ใช้แต่ละรายที่กำลังดำเนินไปใน Journey

สำหรับสิ่งนี้:

  1. เลือก หมวดหมู่ คุณสามารถดึงข้อมูลจากสามหมวดหมู่:
  • อุปกรณ์ (Device): ใช้ข้อมูลอุปกรณ์เมื่อคุณต้องการข้อมูลทางเทคนิคที่ผูกกับอุปกรณ์ของผู้ใช้

  • แท็ก (Tag): ใช้ข้อมูลแท็กเมื่อคุณต้องการส่งข้อมูลที่เก็บไว้ในโปรไฟล์ผู้ใช้

  • เหตุการณ์ (Event): ใช้ข้อมูลเหตุการณ์เมื่อ Webhook ควรส่งค่าจากเหตุการณ์ที่ทริกเกอร์ Journey

  1. เลือก พารามิเตอร์ (เช่น HWID, หมวดหมู่โปรด ฯลฯ)
  2. Pushwoosh จะสร้างมาโครที่มีลักษณะดังนี้:
{{tag:Language}}
  1. คัดลอกมาโครและวางลงในเนื้อหา JSON ของคุณในส่วน DATA

เมื่อ Webhook ทำงานใน Journey ที่ใช้งานจริง Pushwoosh จะแทนที่มาโครด้วยค่าจริงสำหรับผู้ใช้นั้นโดยอัตโนมัติ

แทรกตัวยึดตำแหน่งข้อมูลไดนามิกเข้าไปในเนื้อหาคำขอของ Webhook

พิมพ์ตัวยึดตำแหน่งเพิ่มเติมด้วยตนเอง

Anchor link to

ตัวยึดตำแหน่งคือมาโครที่คุณพิมพ์ด้วยตนเองแทนที่จะสร้างจากหมวดหมู่ DATA BUILDER แผง DATA BUILDER ครอบคลุมเฉพาะข้อมูล อุปกรณ์ (Device), แท็ก (Tag) และ เหตุการณ์ (Event) เท่านั้น พิมพ์ตัวยึดตำแหน่งเหล่านี้โดยตรงในส่วน URL, HEADERS หรือ DATA แทน พวกมันจะไม่ปรากฏในแผง:

ตัวยึดตำแหน่งค่า
{{application_code}}รหัสแอปพลิเคชัน ของแอปที่ผู้เดินทางเป็นสมาชิก
{{traveler:id}}ID ที่ Pushwoosh กำหนดให้กับผู้เดินทางนี้สำหรับการทำงานของ Journey นี้
{{journey:uuid}}UUID ของ Journey นี้
{{journey:name}}ชื่อของ Journey นี้
{{point:uuid}}UUID ของขั้นตอน Webhook นี้
{{point:name}}STEP NAME ของขั้นตอน Webhook นี้
{{event:name}}ชื่อของเหตุการณ์ที่ทริกเกอร์การเข้าสู่ Journey ของผู้เดินทางนี้
{{device:platform}}แพลตฟอร์มของอุปกรณ์ เช่น Android หรือ iOS
{{device:push_subscribed}}ผู้เดินทางสมัครรับการแจ้งเตือนแบบพุชหรือไม่ — true หรือ false
{{now}}วันที่และเวลาปัจจุบัน, ISO 8601, UTC
{{now:unix_ms}}เวลาปัจจุบันเป็นมิลลิวินาทีของ Unix
{{tags:all}}ค่าแท็กทั้งหมดสำหรับอุปกรณ์ของผู้เดินทาง เป็นอ็อบเจกต์ JSON เดียว ใช้โดยไม่มีเครื่องหมายคำพูด เช่น "user_properties": {{tags:all}} การใส่เครื่องหมายคำพูดจะเปลี่ยนอ็อบเจกต์เป็นสตริงที่ถูก escape แทน

รักษารูปแบบของตัวยึดตำแหน่งในเนื้อหา JSON

Anchor link to

ตัวยึดตำแหน่งภายในเครื่องหมายคำพูดจะกลายเป็นสตริง JSON เสมอ ไม่ว่าค่าจริงจะเป็นประเภทใดก็ตาม ตัวยึดตำแหน่งเดียวกันที่ไม่มีเครื่องหมายคำพูดล้อมรอบจะรักษารูปแบบของค่าเองไว้แทน: ตัวเลขยังคงเป็นตัวเลข, true/false ยังคงเป็นบูลีน และรายการจะกลายเป็นอาร์เรย์ JSON ตัวยึดตำแหน่งที่ไม่มีเครื่องหมายคำพูดต้องเป็นค่าทั้งหมดของฟิลด์ — "age": {{tag:Age}} ทำงานได้ แต่ "note": prefix{{tag:Age}}suffix ไม่ได้ เพราะทุกอย่างนอกเครื่องหมายคำพูดจะถูกเขียนออกมาตรงตามที่พิมพ์และอักขระพิเศษจะทำให้ JSON เสียหาย

{
"age": {{tag:Age}},
"age_as_text": "{{tag:Age}}"
}

ที่นี่ age จะส่งค่าตัวเลขของแท็ก (34) ในขณะที่ age_as_text จะส่งสตริง "34" ใช้แบบใดก็ได้ที่ฟิลด์ฝั่งรับคาดหวัง หากแท็กไม่มีค่า ตัวยึดตำแหน่งที่ไม่มีเครื่องหมายคำพูดจะยังคงเป็นสตริงว่างเปล่า ไม่ใช่ตัวเลขหรือ false ดูหมายเหตุใต้ เพิ่มเนื้อหาคำขอ JSON

แมปข้อมูลการตอบกลับของ Webhook กับตัวแปร

Anchor link to

นอกจากการส่งข้อมูลออกไปแล้ว ขั้นตอน Webhook ยังสามารถเก็บค่าจากการตอบกลับที่บริการของคุณส่งกลับมาได้ คุณตั้งชื่อให้กับแต่ละค่า (Attribute) ขั้นตอนต่อๆ ไปสามารถใช้ชื่อนั้นได้เช่นเดียวกับที่ใช้ค่าการตอบกลับของ Webhook อื่นๆ ตัวอย่างเช่น ตั้งค่าแท็กด้วย Update user profile หรือกำหนดเวลา Time Delay จากวันที่ที่บริการส่งกลับมา สำหรับตัวอย่าง Journey แบบเต็ม ดู การใช้ข้อมูลการตอบกลับของ Webhook ใน Journey ของคุณ

ตัวอย่าง: CRM ส่งคืน ID ผู้ใช้ คุณเก็บไว้เป็น Attribute crm_user_id จากนั้น Update user profile จะเขียนลงในแท็ก

ก่อนที่คุณจะแมปอะไรก็ตาม ให้รับตัวอย่างการตอบกลับหนึ่งรายการจากบริการ ถามนักพัฒนาของคุณ หรือเปิดการเรียกที่สำเร็จใน บันทึกการเรียก (Calls log) หลังจากการทดสอบและดูเนื้อหาการตอบกลับ คุณต้องการชื่อฟิลด์จากการตอบกลับนั้นเพื่อสร้าง Path

ในส่วน RESPONSE MAPPING คลิก + ADD MAPPING และกรอกสองช่องสำหรับแต่ละค่าที่คุณต้องการจับ:

  • Path: ตำแหน่งของค่าภายในเนื้อหา JSON ของการตอบกลับ โดยมีจุดคั่นระหว่างระดับ
  • Attribute: ชื่อที่คุณจะใช้ในภายหลังใน Journey
ส่วนการแมปการตอบกลับพร้อมช่อง Path และ Attribute และปุ่มเพิ่มการแมปในการตั้งค่า Webhook

ตัวอย่างเช่น หาก CRM ของคุณตอบกลับด้วย:

{
"data": {
"user": {
"id": "789xyz"
}
}
}
  1. ตั้งค่า Path เป็น data.user.id
  2. ตั้งค่า Attribute เป็น crm_user_id

หลังจากที่ผู้ใช้ผ่านขั้นตอนนี้ องค์ประกอบต่อๆ ไปสามารถเลือก Attribute crm_user_id ได้เช่นเดียวกับที่เลือกค่าการตอบกลับของ Webhook อื่นๆ

Condition split ไม่สามารถใช้ค่าเหล่านี้ได้โดยตรง ค่า Webhook ที่แมปมาไม่มีประเภท บันทึกค่าเป็นแท็กก่อน แล้วจึงแยกเงื่อนไขตามแท็กนั้น ดู เปรียบเทียบค่า Webhook ใน Condition split

สำหรับฟิลด์เดียว Path และค่าจะทำงานดังนี้:

แมปทุกองค์ประกอบของอาร์เรย์

Anchor link to

บางครั้งการตอบกลับของ Webhook ไม่ได้มีเพียงค่าเดียว แต่อาจมีรายการ เช่น สินค้าทุกชิ้นในคำสั่งซื้อ, ทุกรายการในตะกร้าสินค้า หรือทุกผลลัพธ์จากการค้นหา โดยปกติการแมปการตอบกลับจะจับค่าเดียวต่อฟิลด์ ดังนั้นหากไม่มีฟีเจอร์นี้ คุณจะได้ค่าที่แมปมาเพียงค่าเดียวจากรายการนั้น และส่วนที่เหลือจะหายไป

ใส่ * ในช่อง Path ตรงตำแหน่งที่เป็นรายการ Pushwoosh จะดึงค่าจากทุกรายการในลิสต์ ไม่ใช่แค่ตำแหน่งเดียว ตัวอย่างเช่น หากรายการชื่อ items และแต่ละรายการมี item_name ให้ตั้งค่า Path เป็น items.*.item_name

ใน RESPONSE MAPPING คลิก + ADD MAPPING และกรอกสองช่องตามปกติ โดยมี * เป็นเครื่องหมายระบุรายการ:

  • Path: ตำแหน่งของค่าภายในการตอบกลับ โดยมี * ตรงตำแหน่งที่เป็นรายการ ตัวอย่าง: items.*.item_name
  • Attribute: ชื่อที่คุณจะใช้ในภายหลัง สิ่งที่คุณเขียนที่นี่จะตัดสินว่าคุณจะได้รับผลลัพธ์กลับมาอย่างไร:
    • รวม {n} ในชื่อ เช่น item_{n} เพื่อรับแต่ละรายการเป็นค่าของตัวเอง โดยมีหมายเลขกำกับตั้งแต่ 1: item_1, item_2, item_3 และอื่นๆ {n} สามารถอยู่ตำแหน่งใดก็ได้ในชื่อ เช่น item_{n}_sku
    • ไม่ใส่ {n} เช่น item_names เพื่อรวมทุกรายการเป็นค่าเดียว คั่นด้วยเครื่องหมายจุลภาค: Sofa, Lamp, Rug
แถวการแมปการตอบกลับที่ตั้งค่า Path เป็น items.*.item_name และ Attribute เป็น item_{n}

ตำแหน่งรายการใน Path เริ่มต้นที่ 0 (items.0.item_name คือรายการแรก) ชื่อ Attribute ที่สร้างด้วย {n} เริ่มต้นที่ 1 (item_1 คือรายการแรกนั้น) นี่คือการนับเลขสองแบบที่แตกต่างกัน

หากคุณต้องการเพียงรายการเดียวจากลิสต์ ให้ใช้ตัวเลขใน Path แทน * เช่น items.0.item_name

ตัวอย่าง
Anchor link to

หาก CRM ของคุณตอบกลับด้วย:

{
"items": [
{ "item_name": "Sofa" },
{ "item_name": "Lamp" },
{ "item_name": "Rug" }
]
}
  • ตั้งค่า Path เป็น items.*.item_name และ Attribute เป็น item_{n} เพื่อรับค่าแยกกันสามค่า: item_1 คือ Sofa, item_2 คือ Lamp, item_3 คือ Rug
  • ตั้งค่า Attribute เป็น item_names แทนเพื่อรับค่าเดียว: item_names คือ Sofa, Lamp, Rug

คุณสามารถใช้ค่าที่แมปมาในภายหลังใน Journey ได้เหมือนกับแอตทริบิวต์การตอบกลับของ Webhook อื่นๆ:

  • Update user profile: บันทึกค่าลงในแท็ก
  • Time Delay: รอจนถึงวันที่จากการตอบกลับ
  • Dynamic Content: ปรับแต่งเนื้อหาข้อความให้เป็นส่วนตัว

Condition split ไม่สามารถใช้ค่าเหล่านี้ได้โดยตรง ค่า Webhook ที่แมปมาไม่มีประเภท บันทึกค่าเป็นแท็กก่อน แล้วจึงแยกเงื่อนไขตามแท็กนั้น ดู เปรียบเทียบค่า Webhook ใน Condition split

การหมดเวลา, การลองใหม่ และคำขอที่ล้มเหลว

Anchor link to

Pushwoosh จะรอการตอบกลับนานสูงสุด 10 วินาที ขั้นตอน Webhook ทั้งหมด รวมถึงการส่งคำขอและการประมวลผลการตอบกลับ ถูกจำกัดไว้ที่ 30 วินาที

การลองใหม่

Anchor link to

เมื่อได้รับการตอบกลับเป็น 500, 502, 503 หรือ 504 หรือเกิดข้อผิดพลาดทางเครือข่าย เช่น การเชื่อมต่อล้มเหลว Pushwoosh จะลองส่งคำขอใหม่อีกครั้งหนึ่งก่อนที่จะยอมแพ้ คำขอที่หมดเวลาจะไม่ถูกลองใหม่ — ดู จะเกิดอะไรขึ้นเมื่อคำขอล้มเหลว ด้านล่าง การตอบกลับอื่นๆ ที่ไม่ใช่ 2xx ก็จะไม่ถูกลองใหม่เช่นกัน

ขีดจำกัดอัตรา

Anchor link to

Pushwoosh จำกัดจำนวนคำขอ Webhook ที่บัญชีสามารถส่งได้ต่อวินาที ขีดจำกัดนี้ถูกตั้งไว้สูงกว่าปริมาณการใช้งานจริงในช่วงพีค ดังนั้น Journey ปกติจะไม่ได้รับผลกระทบ การส่งคำขอที่เกินขีดจำกัดจะรอสักครู่เพื่อให้มีที่ว่างก่อนที่จะล้มเหลว

การพักใช้งาน Endpoint

Anchor link to

หาก endpoint ล้มเหลวหลายครั้งติดต่อกัน Pushwoosh จะหยุดส่งคำขอไปยัง endpoint นั้นชั่วคราวแทนที่จะลองใหม่กับ endpoint ที่เสียทุกครั้งที่มีผู้เดินทาง โดยเริ่มจาก 30 วินาทีและเพิ่มเป็นสองเท่าเมื่อล้มเหลวอีกจนถึงสูงสุด 5 นาที คำขอที่สำเร็จเพียงครั้งเดียวจะล้างสถานะนี้และกลับมาส่งตามปกติ

จะเกิดอะไรขึ้นเมื่อคำขอล้มเหลว

Anchor link to

องค์ประกอบ Webhook ไม่มีสาขาแยกสำหรับคำขอที่ล้มเหลว กรณีใดๆ ต่อไปนี้จะทำให้ผู้เดินทางออกจาก Journey ณ ขั้นตอนนี้:

สาเหตุสิ่งที่ทำให้เกิด
ที่อยู่ endpoint ถูกบล็อกURL เป็นส่วนตัว, ภายใน, loopback หรือ link-local รวมถึง cloud metadata endpoints
ขีดจำกัดอัตราเกินขีดจำกัดคำขอ Webhook ต่อวินาทีของบัญชีและไม่มีที่ว่างเปิดขึ้นในระหว่างการรอสั้นๆ
การพักใช้งาน Endpointendpoint ล้มเหลวหลายครั้งติดต่อกันและ Pushwoosh กำลังข้ามไปชั่วคราว
หมดเวลาไม่มีการตอบกลับภายใน 10 วินาที หรือขั้นตอนเกินขีดจำกัด 30 วินาที
ข้อผิดพลาดทางเครือข่ายคำขอไม่สามารถไปถึง endpoint ได้เลย
การตอบกลับที่ไม่ใช่ 2xxendpoint ส่งคืนสถานะข้อผิดพลาดที่ไม่ถูกลองใหม่ หรือถูกลองใหม่หนึ่งครั้งแล้วล้มเหลวอีก

ดู ข้อผิดพลาดของคำขอ

หากคุณไม่สามารถปล่อยให้ผู้เดินทางหลุดออกจาก Journey ที่นี่ได้ ให้ endpoint ของคุณส่งคืนการตอบกลับ 2xx เสมอ และใส่สถานะความล้มเหลวใดๆ ไว้ในเนื้อหาการตอบกลับแทน ตัวอย่างเช่น เป็นค่าที่ การแมปการตอบกลับ ของคุณสามารถดึงไปใช้ได้

สิ่งนี้ใช้กับทุกขั้นตอน Webhook รวมถึงขั้นตอนที่สร้างขึ้นก่อนหน้านี้ ที่อยู่ endpoint ที่ตอนนี้ตรงกับกฎที่อยู่ถูกบล็อกข้างต้นจะเริ่มล้มเหลวในลักษณะเดียวกัน

ต่างจากคำขอที่ล้มเหลว การตอบกลับที่มาถึงแต่ไม่สามารถแมปได้อย่างถูกต้อง เช่น JSON ไม่ถูกต้อง, Path ที่ไม่สามารถแก้ไขได้ หรือเนื้อหาเกิน 64 KB จะไม่ทำให้ผู้เดินทางออกจาก Journey ดูหมายเหตุใต้ การแมปการตอบกลับ ข้างต้น

ทดสอบ Webhook

Anchor link to

คลิก Test webhook เพื่อตรวจสอบว่าการกำหนดค่า Webhook ของคุณถูกต้องและคำขอถูกส่งสำเร็จ

หากส่วนหัวยังคงแสดงการปิดบังที่เก็บไว้ Pushwoosh จะเติมค่าจริงที่บันทึกไว้สำหรับคำขอทดสอบ ค่านั้นจะไม่ปรากฏในเบราว์เซอร์ของคุณ

การแทนที่นี้ใช้ได้เฉพาะกับส่วนหัวที่บันทึกไว้ในขั้นตอนนี้เท่านั้น ขั้นตอนที่คุณยังไม่ได้บันทึก หรือขั้นตอนที่คุณเพิ่งคัดลอกมา จะไม่มีค่าที่บันทึกไว้หลังการปิดบัง ดังนั้น Pushwoosh จะส่งคำขอทดสอบโดยไม่มีส่วนหัวนั้น

หลังจากการทดสอบสำเร็จ (หรือการเรียกใช้งานจริง) ให้เปิด Calls log ขยายแถว และเปรียบเทียบเนื้อหาการตอบกลับกับแต่ละ Path ฟิลด์ต้องมีอยู่ตรงตามที่ระบุใน Path หากคำขอสำเร็จแต่ขั้นตอนต่อมาไม่มีค่า โดยปกติแล้ว Path จะไม่ตรงกับการตอบกลับ ขั้นตอน Webhook จะไม่แสดงข้อผิดพลาดสำหรับสิ่งนั้น

บันทึกการกำหนดค่าของคุณ

Anchor link to

คลิก Save เพื่อบันทึกการกำหนดค่า Webhook ของคุณ

บันทึกการเรียก (Calls log)

Anchor link to

เปิดแท็บ Calls log ในลิ้นชักของจุดเพื่อดูว่า Pushwoosh ส่งอะไรไปสำหรับขั้นตอนนี้: เวลา, ผู้ใช้, ผลลัพธ์ และระยะเวลา ย้อนหลัง 30 วัน

กรองตามผลลัพธ์ (Success, HTTP error, No response) หรือค้นหาด้วย User ID หรือ HWID ที่แน่นอน คลิกที่แถวเพื่อขยายและดูคำขอ (เมธอด, URL และเนื้อหา) และขึ้นอยู่กับผลลัพธ์ อาจเป็นได้ทั้งการตอบกลับ (สถานะและเนื้อหา) หรือข้อความแสดงข้อผิดพลาด Duration ครอบคลุมทั้งขั้นตอน รวมถึงเวลาที่ใช้ในการ ลองใหม่ โดยอัตโนมัติ