ภาพรวม

แบรนด์เพจคืออะไร

แบรนด์เพจเป็นประสบการณ์แลนดิ้งเพจที่ปรับแต่งเฉพาะบนเว็บไซต์ของคุณและแสดงเนื้อหาเฉพาะของแบรนด์ เพจเหล่านี้โฮสต์อยู่บนโดเมนของคุณ และแสดงผลโดยใช้คอมโพเนนต์ UI ของคุณ

Brand Pages are managed separately from standard ad campaigns in the Epsilon platform.
Although they use a similar creation and review workflow, they represent branded landing page experiences on a retailer’s site, not traditional advertisements.

ตัวอย่าง: ผู้ใช้เข้าชม yoursite.com/brands/nike และเห็นหน้าเว็บแบรนด์ Nike ที่มีสินค้า Nike แต่ดูและรู้สึกเหมือนเป็นส่วนหนึ่งของเว็บไซต์ของคุณ

สิ่งที่คุณจะสร้าง

ในฐานะวิศวกรสำหรับผู้ค้าปลีก คุณจะ

• เพิ่มเส้นทางสำหรับ URL ของแบรนด์เพจ (เช่น /brands/{slug})

📘

ผู้ค้าปลีกไม่จำเป็นต้องจัดเตรียม URL สำหรับแต่ละแบรนด์เพจ แพลตฟอร์มจะจัดการ URL โดยอัตโนมัติ

อย่างไรก็ตาม URL พื้นฐานของแบรนด์เพจ (รวมถึงคำนำหน้า) จะต้องได้รับการกำหนดค่าระหว่างขั้นตอนการเข้าระบบ (ตัวอย่างเช่น ในคู่มือสไตล์ของผู้ค้าปลีก) หากไม่ได้ระบุ URL ฉบับสมบูรณ์หรือคำนำหน้า จะไม่มีการกรอก URL แบรนด์เพจบนหน้าตั้งค่า

• เรียกใช้ API ของแบรนด์เพจโดยใช้ส่วนท้ายที่แยกออกมา

• แสดงโมดูลเนื้อหาที่ส่งคืน

• ดำเนินการแสดงผล การคลิก และการติดตามเพิ่มลงในรถเข็น

• กําหนดค่าพร็อกซีย้อนกลับสําหรับการติดตามของบุคคลที่หนึ่ง

📘

ขั้นตอนนี้จำเป็นสำหรับการติดตามฝั่งไคลเอ็นต์คุณเท่านั้น

ความรับผิดชอบของคุณเทียบกับของ Epsilon

วิธีการทำงานของเพจแบรนด์

การไหลจากสิ้นสุดถึงสิ้นสุด

📘

เนื้อหาแบรนด์เพจได้รับการกำหนดค่าและแสดงตัวอย่างใน Epsilon UI ผู้ค้าปลีกผสานรวมแบรนด์เพจเข้ากับระบบผ่าน API เท่านั้น และต้องรับผิดชอบในการแสดงประสบการณ์สุดท้ายบนเว็บไซต์ของตน

ในระหว่างกระบวนการตรวจสอบ ผู้ค้าปลีกสามารถดูตัวอย่างเนื้อหาเพจแบรนด์ที่กำหนดค่าไว้ก่อนที่จะได้รับการอนุมัติ

เทมเพลตและโมดูล

ในระหว่างการเข้าระบบ Epsilon ทำงานร่วมกับทีมของคุณเพื่อสร้างเทมเพลตที่กำหนด:

• The content modules available (such as hero, product grid, text, and images), with module names configurable in the UI to align with your retailer taxonomy.

• The constraints for each module (character limits, image dimensions, etc.).

• การจัดสไตล์ที่สอดคล้องกับแนวทางของแบรนด์ของคุณ

แบรนด์เลือกเทมเพลตเมื่อสร้างแคมเปญของตน จากนั้นกรอกเนื้อหาภายในข้อจํากัดเหล่านั้น

📘

API ของแบรนด์เพจส่งคืนโมดูลเนื้อหาและ URL การติดตาม ผู้ค้าปลีกมีหน้าที่รับผิดชอบในการใช้สไตล์โดยใช้ส่วนประกอบ UI และระบบการออกแบบของตนเอง

ตัวอย่าง

ตัวอย่างต่อไปนี้แสดงให้เห็นว่าแบรนด์สามารถเติมโมดูลเนื้อหาทั่วไปได้อย่างไรเมื่อสร้างเพจแบรนด์ นี่เป็นตัวอย่างการป้อนข้อมูลเท่านั้น และสามารถปรับเปลี่ยนได้ตามเทมเพลตที่เลือกและวัตถุประสงค์ของแคมเปญ

โมดูล HERO

• หัวข้อ: พบกับคอลเล็กชั่นฤดูร้อนล่าสุด
• หัวข้อย่อย: รูปแบบใหม่สำหรับทุกโอกาส
• ปุ่มกระตุ้นการซื้อ: ช้อปเลย

โมดูลข้อความ

สำรวจสินค้าใหม่ล่าสุดที่ออกแบบมาเพื่อความสะดวกสบาย สไตล์ และประสิทธิภาพ - เหมาะสำหรับการสวมใส่ในชีวิตประจำวัน

โมดูลภาพ

• Caption: New arrivals now available
• Alt text: Model wearing the summer collection
• URL: https://example-cdn.com/summer-collection.jpg

โมดูล PRODUCT_GRID

ใช้กริดผลิตภัณฑ์เพื่อแสดงผลิตภัณฑ์ที่ขายดีที่สุดหรือผลิตภัณฑ์ตามฤดูกาล และกระตุ้นการมีส่วนร่วมและการเปลี่ยนแปลง

การกำหนดค่าโมดูล:

📘

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

บางช่องอาจบังคับใช้ขีดจำกัดจำนวนอักขระสูงสุดเมื่อระบุว่าจำเป็นหรือได้รับอนุญาต

Module Tags

Templates may include an optional tags field on each module — a list of short string labels (e.g., ["header"]) that your integration can use for layout decisions, analytics, or mapping modules to your own components.

How tags work in the API response

• When a module has tags, they appear as a tags array on the corresponding item in contentData.
• When a module has no tags, the tags property is omitted entirely from the response - it will not appear as "tags": [].
• Treat a missing tags field the same as "no tags" - do not throw an error if it is absent.
• Tags are also supported on nested modules within SPLIT_LAYOUT - not only on the root split module.

📘

สำคัญ

Tags are opaque labels agreed upon between the retailer and their integration team. They are not related to ad tracking tags or any other system — always refer to these as "module tags" or "brand page module tags" to avoid confusion.

Example response module with a tag

{
  "id": "image-1",
  "contentType": "IMAGE",
  "order": 1,
  "tags": ["header"],
  "imageUrl": "https://example.com/images/banner.jpg"
}

Example response module with no tag (tags property omitted):

{
  "id": "image-2",
  "contentType": "IMAGE",
  "order": 2,
  "imageUrl": "https://example.com/images/promo.jpg"
}

What this means for the API response

The POST /ads/v3/brand-pages response reflects these same rules: a module type only appears in contentData when it is part of the live template and the brand page has configured content for that module.

Fields inside a module may be missing from the JSON, null, or empty when the template marks them optional or disabled, or when the brand leaves them unset - this is expected and does not indicate a defective payload.

Implement rendering with optional types and safe accessors - for example, only render a CTA block when ctaText and a navigation target are present; hide hero media when mediaUrlis absent.

trackersat the page level or on a node may be omitted when there is no trackable interaction. Compose URLs only when you have both an applicable template key from trackingTypes and the corresponding trackers..params, when provided by the API.