Skip to main content
Banners in the Tappd Web SDK are placement-based content units that attach to specific DOM elements on your page. Unlike in-app messages — which are trigger-driven and float above your layout — banners live inside defined HTML containers and support rich targeting, scheduling, frequency capping, and A/B testing directly from the dashboard.

Quick Start

The SDK handles fetching, rendering, and event tracking in a single call:
When you call getBanners(), the SDK automatically:
  1. Fetches eligible banners from the API for the identified user
  2. Renders them inside the target DOM element
  3. Tracks display, click, and dismiss events
Banners use a placement identifier to find the right DOM element. The Tappd dashboard lets you configure each banner’s placement type.
Target an element by its CSS selector. The example below attaches a banner to <header id="header-banner">.

Auto-Rendering (Default)

By default, getBanners() renders banners directly into the target element. You can make this explicit with the autoRender option, and use forceRefresh to bypass the local cache and fetch the latest banner data from the API:
The SDK handles the full rendering cycle for you:
  • Locates the target element using the selector
  • Creates and styles the banner element
  • Injects content (title, message, image, CTA button)
  • Appends a close button if the banner is dismissible
  • Applies the configured animation (fade or slide)
  • Tracks the display event automatically
  • Wires up click and dismiss event handlers

Custom UI Rendering

If you want full control over the banner’s appearance, disable auto-rendering and build your own UI with the returned banner data:

Manual Event Tracking

Use these methods when implementing a custom UI. For auto-rendered banners, event tracking is handled for you.
getBanners() returns an array of objects, each containing a banner and a variant:
Control which users see a banner based on their profile and behavior.
  • Segments: Restrict banners to specific customer segments defined in the dashboard.
  • Custom Rules: Write targeting rules against any customer attribute.
  • Toggle: Enable or disable targeting without deleting your rules.
Banners with targeting enabled are only returned by getBanners() if the identified user matches the criteria.
Define exactly when a banner is active.
  • Start / End Dates: Set a date range for the campaign.
  • Active Hours: Limit display to specific hours of the day.
  • Active Days: Limit display to specific days of the week.
  • Timezone: All schedule calculations respect a configurable timezone.
Prevent banner fatigue by limiting how many times a user sees a banner.
  • Max Displays: The total number of times the banner can be shown to a single user.
  • Period: The cap resets on a session, hour, day, week, or month cadence.
  • Toggle: Disable frequency capping for always-on banners.
Run experiments to find the most effective banner variant.
  • Multiple Variants: Create as many variants as you need per banner.
  • Traffic Allocation: Set the percentage of traffic each variant receives.
  • Automatic Assignment: Variant assignment is deterministic based on customer ID, so a user always sees the same variant.
  • Analytics: Views, clicks, dismissals, conversions, and CTR are tracked per variant automatically.

API Reference

Always call identify() before getBanners(). Without an identified user, the SDK cannot evaluate targeting rules or apply frequency caps.