Overview

What Are Brand Pages?

Brand Pages are customized landing page experiences that live on your website and showcase specific brand content. They are hosted on your domain and rendered using your UI components.

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.

Example: A user visits yoursite.com/brands/nike and sees a Nike-branded page with Nike products, but it looks and feels like part of your website.

What You’ll Build

As a retailer engineer, you will:

• Add a route for brand page URLs (for example, /brands/{slug}).

📘

Retailers are not required to provision a URL for each Brand Page. URLs are automatically managed by the platform.

However, the Brand Page base URL (including the prefix) must be configured during onboarding (for example, in the Retailer Style Guide). If the complete URL or prefix is not provided, the Brand Page URL will not be populated on the setup page.

• Call the Brand Pages API using the extracted slug.

• Render the returned content modules.

• Implement impression, click, and add‑to‑cart tracking.

• Configure a reverse proxy for first‑party tracking.

📘

This step is only required for client-side tracking.

Your Responsibilities vs. Epsilon's

How Brand Pages Work

End-to-End Flow

📘

Brand page content is configured and previewed in the Epsilon UI. Retailers integrate Brand Pages exclusively through APIs and are responsible for rendering the final experience on their sites.

During the review process, retailers can preview the configured brand page content before approval.

Templates & Modules

During onboarding, Epsilon works with your team to create templates that define:

• 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.).

• Styling that aligns with your brand guidelines.

Brands select a template when creating their campaign, then fill in the content within those constraints.

📘

The Brand Pages API returns content modules and tracking URLs. Retailers are responsible for applying styling using their own UI components and design system.

Examples

The following examples illustrate how brands can populate common content modules when creating a Brand Page. These are sample inputs only and can be adjusted based on the selected template and campaign objectives.

HERO module

• Headline: Discover the Latest Summer Collection
• Subheadline: Fresh styles for every occasion
• CTA: Shop Now

TEXT module

Explore our newest arrivals designed for comfort, style, and performance - perfect for everyday wear.

IMAGE module

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

PRODUCT_GRID module

Use a product grid to showcase top‑selling or seasonal products and drive engagement and conversions.

Module Configuration:

📘

Each configurable element can be set as required, optional (allowed), or disabled, depending on the module and retailer requirements.

Some fields may also enforce maximum character limits when marked as required or allowed.

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.

📘

Important

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.