Rokt Documentation
  • Documentation
  • User Guide
  • SDK
  • API
  • Third-Party Integrations
  • Help

›Web SDK

Getting Started

  • Introduction

Web SDK

  • Overview
  • Architecture
  • Integrating the Web SDK
  • Integration Examples

    • Confirmation page integration
    • Preparative iframe
    • Page identifier
    • Single page applications
    • Brand conversion integration
    • In-transaction/cart integration
    • Event-based integration
    • Sandbox integration
  • Integration best practices
  • Attributes
  • Security
  • Mobile in-app web pages
  • API

    • Rokt
    • Attributes
    • CartItem
    • Configuration
    • Placement
    • Subscriber
    • TriggerPageChangeOptions
    • Unsubscriber

iOS SDK

  • Overview
  • Version
  • Integrating the SDK

    • Integrating and Initializing the SDK
    • Launching an overlay placement
    • Launching an embedded placement
    • Recording a brand conversion
    • Sandbox integration
  • Attributes
  • Security

Android SDK

  • Overview
  • Version
  • Integrating the SDK

    • Integrating and initializing the SDK
    • Launching an overlay placement
    • Launching an embedded placement
    • Recording a brand conversion
    • Sandbox integration
  • Attributes
  • Security

React Native SDK

  • Overview
  • Version
  • Integrating the SDK

    • Integrating and initializing the SDK
    • Launching an overlay placement
    • Launching an embedded placement
    • Recording a brand conversion
    • Sandbox integration
  • Attributes
  • Security
Edit

Architecture

The Web SDK is composed of four key components. It is designed to reflect best-in-class security practices and not to interfere with your site or your customer experience. Read more about our approach to security.

Launcher

The launcher is responsible for launching Rokt’s solution on a partner’s page. The launcher has minimal logic, allowing a thin layer of integration with the partner and orchestrating iframes on the partner's page. Due to the requirement of managing Rokt’s isolated iframes, the script needs to run on partner’s page outside of the isolated layer of iframes. To minimize the risk associated with the script, it can be reviewed and versioned either by use of Subresource Integrity (SRI) or by being hosted by a partner. Due to an optional versioning, the launcher outsources all possible business logic to the controller. This includes any communication with Rokt’s API. This ensures that changes to the file can be kept to a minimum.

Controller

The controller iframe holds the majority of the non-UI related business logic required to run Rokt’s solution. This allows us to minimize the complexity of Rokt launchers to the bare minimum, ensuring the controller is the only iframe able to communicate with the Rokt backend.

Placement

The placement iframe is responsible for drawing and styling placements on partners' pages. Rokt’s solution may add multiple iframes of this type to the partner’s page, for example a single modal (overlay) and an embedded placement. The placement iframe does not communicate with the Rokt API directly but expects configuration to be received from the controller iFrame. To ensure configuration is not tampered with, the placement and the controller communicate through postMessage restricted to only their own domains.

Reporter

For edge case scenarios when the controller iframe fails to launch, the reporter iframe sends any errors to the Rokt backend.

The following diagram provides context on the components involved in a Rokt Web SDK integration.

Rokt Web SDK integration diagram

← OverviewIntegrating the Web SDK →
  • Launcher
  • Controller
  • Placement
  • Reporter
RESOURCES
DocumentationUser GuideSDKAPIIntegration PartnersHelp
COMPANY
About UsContact UsCareersEngineering Blog
Rokt Documentation
Copyright © Rokt 2021 - All Rights Reserved